January 19, 2014
On Sunday, 19 January 2014 at 07:42:26 UTC, Adam Wilson wrote:
> On Sat, 18 Jan 2014 21:39:14 -0800, Tofu Ninja <emmons0@purdue.edu> wrote:
>
>>> In general, it's preferable to use 2D API's for 2D graphics. Yes, you can do 2D with OpenGL but it's significantly harder to get it right. The most obvious example is that in 2D we use pixels as coordinates and have no perspective to worry about, with 3D the your coordinates have to be carefully calculated every time the window or perspective changes.
>>
>> It seems like you have never done 2d with openGl. Doing 2d in openGl is just a simple problem of using the correct transform matrix. Using pixel coordinates for your primitives is 100% possible and easy. The only difference between opengl in 2d and opengl in 3d is the transform.
>
> You are correct, I haven't done it in a modern version of OpenGL, I did it about a decade ago in DirectX and I wanted to cry...
>
> That said, I am not against creating the 2D components of Aurora using a 3D API. Although I do want to note that it will probably be quicker to prototype using a 2D library. And I don't want to rule it out it for production use either, we can have more than one backend after all.

That seems reasonable.
January 19, 2014
On Sat, 18 Jan 2014 22:02:12 -0800, Kelet <kelethunter@gmail.com> wrote:

> On Sunday, 19 January 2014 at 05:23:24 UTC, Elvis Zhou wrote:
>> https://github.com/Zoadian/aurora
>> Oops, I thought this is the official repo!! It's a new package added to code.dlang.org yesterday.
>
> Doh, I made the same mistake.
>
> On Sunday, 19 January 2014 at 03:38:30 UTC, Adam Wilson wrote:
>> System      2D API   / 3D API
>> Linux       X11      / OpenGL 4.3
>> Android     Canvas   / OpenGL ES 3.0
>> OSX         Quartz2D / OpenGL 4.3
>> iOS         Quartz2D / OpenGL ES 3.0
>> Windows     Direct2D / Direct3D 11
>> Windows RT  Direct2D / Direct3D 11
>
> My thoughts:
>
> ARM support is abysmal in D, IIRC. This rules out most of the mobile devices until that situation is relieved. In the meantime, the code should be tested on LDC and GDC regularly. Once ARM support is mature on one of the aforementioned backend, it shouldn't be difficult to finalize support.
>
> I'm not convinced of two things:
> - OpenGL should not be used for the 2D API
> - Direct3D should be a backend
>
> Ideally, 2D and 3D graphics should be a specific case of a generalized system which utilizes OpenGL. Thus, there is no need for a separate backend API for 2D graphics. I've done 2D in OpenGL and it was not very painful, although it was not a substantial project.
>
> I've used a ton of OpenGL software on a lot of hardware running Windows and never encountered a problem or major deficiency which is not present in Direct3D, hence I don't know why extra effort should be expended to support it as a backend.
>

It may be true of simple implementation on the same hardware but consider that the OpenGL API is implemented entirely by the GPU vendor, this invariably results in the same command producing different results in some cases, and the cases will change between vendors and API versions. It's a maddening problem because while it looks right on your GPU it might look different on another or it might not, this means testing on as much hardware as possible, which is something that will take a LOT of time as user reports bugs on their own hardware. See the last paragraph in this citation: http://en.wikipedia.org/wiki/Comparison_of_OpenGL_and_Direct3D#Availability

DirectX does not have this problem, granted it does so at the expense of cross-platform ability, but given the pluggable nature of Aurora backends I fail to see the harm in using DirectX given it's uniformity on at least Windows.

> Backends in order of importance, IMO:
> - OpenGL 2.0
> - OpenGL 2.0 ES
> - OpenGL 1.1
> - Software
> - OpenGL 4.3
>
> There are a surprising amount of people still on OpenGL 2.0 and 1.1. For everything else: Software backend. It wouldn't hurt to have a 'state of the art' OpenGL 4.3 backend either, but only after all else is done.
>
> However, my forays into graphics are mainly hobby game development so I may be missing some elements here.
>
> Regards,
> Kelet

I picked OpenGL 4.3 primarily because it is compatible with OpenGL ES 3.0 which will make porting to iOS/Android easier. There is nothing stopping Aurora from having a backend built on an older version, but keep in mind that Aurora's front-end sets the required features, and I don't think OpenGL 1.0 can meet them without a rather large assist from handmade CPU algorithms, which will inevitably mar performance over the newer API's.

Another backend I'd like to serious consider is AMD's Mantle API, which is even lower-level than OpenGL and DirectX but supposedly 45% more performant. There is no sense not building as much performance into Aurora as long as it doesn't interfere with the ease-of-use goal.

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator
January 19, 2014
On Sunday, 19 January 2014 at 07:55:03 UTC, Adam Wilson wrote:

>
> I picked OpenGL 4.3 primarily because it is compatible with OpenGL ES 3.0 which will make porting to iOS/Android easier. There is nothing stopping Aurora from having a backend built on an older version, but keep in mind that Aurora's front-end sets the required features, and I don't think OpenGL 1.0 can meet them without a rather large assist from handmade CPU algorithms, which will inevitably mar performance over the newer API's.

I refrained from making any comments on backends precisely because they're pluggable. I'd /prefer/ to see a baseline of D3D9 and OpenGL 3.2, simply because of Windows XP, which DMD supports, and because Mac support for GL 4.x is not very widespread and likely will not become mainstream for a while yet. Even looking two or three years out, OpenGL 3.2 will allow us to cover a broader user-base than 4.3. But it's not big deal, really. Whatever we don't start with can be added later.

I do support the idea of a D3D backend on Windows. The OpenGL situation there is better than it used to be, but there are still headaches that crop up now and again as a few minutes with Google can show. SDL2 and Allegro5 both have D3D renderers by default on Windows for good reason. That said, I would put priority on the OpenGL renderer, since it runs on all of the platforms DMD currently supports.

Here's something to consider, though. The Steam Hardware & Software Survey [1] gives a good baseline for the gaming market (what used to be called the "hardcore" market, but I think it's more than that now). However, I wouldn't consider it anywhere near mainstream. Among that market, D3D11 (OpenGL 4.x) penetration is only 54%. Fast-forward to a year from now and you're probably looking at somewhere between 80-90%. Cut that in half for the wider market and you've got a rough baseline for the mainstream computer user.

>
> Another backend I'd like to serious consider is AMD's Mantle API, which is even lower-level than OpenGL and DirectX but supposedly 45% more performant. There is no sense not building as much performance into Aurora as long as it doesn't interfere with the ease-of-use goal.

Yeah, that would be a good one. Down the road :)

[1] http://store.steampowered.com/hwsurvey

January 19, 2014
On Sunday, 19 January 2014 at 07:55:03 UTC, Adam Wilson wrote:
> It may be true of simple implementation on the same hardware but consider that the OpenGL API is implemented entirely by the GPU vendor, this invariably results in the same command producing different results in some cases, and the cases will change between vendors and API versions. It's a maddening problem because while it looks right on your GPU it might look different on another or it might not, this means testing on as much hardware as possible, which is something that will take a LOT of time as user reports bugs on their own hardware. See the last paragraph in this citation: http://en.wikipedia.org/wiki/Comparison_of_OpenGL_and_Direct3D#Availability
>
> DirectX does not have this problem, granted it does so at the expense of cross-platform ability, but given the pluggable nature of Aurora backends I fail to see the harm in using DirectX given it's uniformity on at least Windows.

How about the angle project? You were asked for shader compatibility too.
January 19, 2014
On 2014-01-19 04:38, Adam Wilson wrote:

> Since Aurora has a pluggable backend for rendering I feel that it will
> be prudent to use the low-level API's that are best suited to each
> platform. This will Aurora to support each platform as best as possible.
> As I currently can tell the following list represents
>
> System         2D API   / 3D API
> Linux          X11      / OpenGL 4.3
> Android        Canvas     / OpenGL ES 3.0
> OSX            Quartz2D / OpenGL 4.3

OS X 10.9 supports up to OpenGL 4.1. OS X 10.8 and 10.7 support up to OpenGL 3.2. It would be very nice if Aurora would work on OS X older than 10.9. Here are two lists indicating the support of OpenGL in OS X:

https://developer.apple.com/graphicsimaging/opengl/capabilities/index.html

http://support.apple.com/kb/HT5942 (10.9)

> iOS            Quartz2D / OpenGL ES 3.0

OpenGL ES 3.0 is only supported on iOS 7 on some deceives. Here's a list for iOS:

https://developer.apple.com/library/ios/documentation/DeviceInformation/Reference/iOSDeviceCompatibility/OpenGLESPlatforms/OpenGLESPlatforms.html

> The reason for targeting relatively new low-level API versions is that
> by the time we actually complete the bulk of the work, they won't be new
> anymore.

I think you need to lower your requirements a bit. At minimum we need to support something that works today. OpenGL 4.3 doesn't work on OS X today. Preferably it would be nice to support OpenGL 3.2, to be able to run on OS X 10.8 and 10.7 as well.

> I've noticed that Android and iOS seem to have many
> options for 2D graphics, none of which I've had a chance to evaluate
> rigorously, any recommendations would be appreciated.

Talking about iOS, as far as I know it has only one library, Quartz2D. Here are a couple of libraries/terms that can be confusing:

* Core Graphics - a framework that Quartz2D is part of
* Quartz Extreme - a term for hardware accelerated graphics
* Core Image - library used to apply effects on images and videos

-- 
/Jacob Carlborg
January 19, 2014
Le 19/01/2014 04:38, Adam Wilson a écrit :
> Hello Everyone,
>
> Based on the previous thread I think we have enough to start laying out
> the design and writing code for Aurora.
>
> The choice that I would like to clarify is that Aurora will be a
> retained mode API. I understand that this is not the best choice for
> speed and that not everyone will be happy with this choice. However,
> retained mode API's are typically much higher-level, which will make it
> easier for developers that are unfamiliar with writing graphics code to
> express their intent. Given the stated goal of Aurora I feel that this
> is the best choice.
>
> The next is that Aurora will have a pluggable backend rendering system.
> This will allow us to support any rendering system capable of meeting
> the requirements of Aurora's frontend. And when combined with the
> retained mode API you could, in theory, swap renders on the fly.
> Although I wouldn't want to be the first one try it!
>
> Since Aurora has a pluggable backend for rendering I feel that it will
> be prudent to use the low-level API's that are best suited to each
> platform. This will Aurora to support each platform as best as possible.
> As I currently can tell the following list represents
>
> System         2D API   / 3D API
> Linux          X11      / OpenGL 4.3
> Android        Canvas     / OpenGL ES 3.0
> OSX            Quartz2D / OpenGL 4.3
> iOS            Quartz2D / OpenGL ES 3.0
> Windows        Direct2D / Direct3D 11
> Windows    RT     Direct2D / Direct3D 11
>
> The reason for targeting relatively new low-level API versions is that
> by the time we actually complete the bulk of the work, they won't be new
> anymore. If anyone has a suggestion for a 2D API on Linux that has the
> ubiquity of the X11 but is easier to use, please mention it! I would
> like to have a Wayland backend but that API is still very new and not
> widely adopted. I've noticed that Android and iOS seem to have many
> options for 2D graphics, none of which I've had a chance to evaluate
> rigorously, any recommendations would be appreciated.
>
> As has been widely suggested, Aurora will be split into a number of
> packages that are loosely coupled. In theory this would allow us to pull
> the more broadly applicable packages in to Phobos as they mature and
> then depend on those in Aurora. The tentative list of packages is as
> follows:
>
> aurora.application
> aurora.primitives
> aurora.graphics2d
> aurora.graphics3d
> aurora.text
> aurora.image
> aurora.math
> aurora.animation
>
> Hopefully, this break down will allow the user to pull in only what they
> need for their project, without confusing them with choice. Naming
> suggestions are welcomed!
>
> Finally, I've have set up a GitHub organization for Aurora, which can be
> accessed at: https://github.com/auroragraphics I haven't posted any code
> yet, but I am working on aurora.application for Windows. The aurora repo
> is the master repo and all other package repo's are submodules of it.
> The aurora repo will consist primarily of the scripts required to build
> Aurora. This is to make it easier for the newbies to get started while
> enabling maximum flexibility for the development team.
>
> In the famous words on Andrei ... Destroy!
>

Like some other I think you can only use openGL as backend, and took a lower version like openGL 2.1 (and shader version 1.40) which is completely compatible with openGL ES 2.0.

In practice I don't think there is performance difference between openGL and DirectX under Windows if both backend have the same level of optimization. The only bad point of openGL under Windows is the bad compatibility of drivers of Intel integrated chipset. Some don't provide equivalent openGL functions supported by the DirectX version of drivers notably when it concern shaders.
Fortunately today Intel provide all necessary functions in openGL drivers. There is also the possibility to use Angle library.

January 19, 2014
uh, i do read the forums from time to time. But I never read anything about project aurora. I inititally thought this thread is about my project.
'aurora' was the name for my engine for years. (i do have a working deferred rendering engine, the published one is just my ongoing rewrite to clean up the existing one and add tile based rendering).

Having two 3D engines with the same name is stupid indeed, so we have two choices:
1. I rename my project. (name suggestions are welcome)
2. We combine effort.

please contact me on github or irc (#d or #d.de)

Zoadian
January 19, 2014
Am 19.01.2014 13:08, schrieb Xavier Bigand:
> Le 19/01/2014 04:38, Adam Wilson a écrit :
>> Hello Everyone,
> [...]
> Like some other I think you can only use openGL as backend, and took a
> lower version like openGL 2.1 (and shader version 1.40) which is
> completely compatible with openGL ES 2.0.

GLSL is not compatible though.

>
> In practice I don't think there is performance difference between openGL
> and DirectX under Windows if both backend have the same level of
> optimization. The only bad point of openGL under Windows is the bad
> compatibility of drivers of Intel integrated chipset. Some don't provide
> equivalent openGL functions supported by the DirectX version of drivers
> notably when it concern shaders.
> Fortunately today Intel provide all necessary functions in openGL
> drivers. There is also the possibility to use Angle library.
>

You also have to consider OEM boards, that tend to only have DirectX drivers delivered with them.

--
Paulo
January 19, 2014
On Sunday, 19 January 2014 at 10:07:08 UTC, Mike Parker wrote:
> Here's something to consider, though. The Steam Hardware & Software Survey [1] gives a good baseline for the gaming market (what used to be called the "hardcore" market, but I think it's more than that now). However, I wouldn't consider it anywhere near mainstream. Among that market, D3D11 (OpenGL 4.x) penetration is only 54%. Fast-forward to a year from now and you're probably looking at somewhere between 80-90%. Cut that in half for the wider market and you've got a rough baseline for the mainstream computer user.

Yeah, when looking at Steam Hardware & Software Survey, you have to be aware that it best represents the hardcore gamer segment. The indie and casual gamers typically have an Intel GPU much more frequently that the survey would lead to believe. Even in 2013, OpenGL games requiring OpenGL 2.1+ might have lots of problems on release.

January 19, 2014
On Sunday, 19 January 2014 at 03:38:30 UTC, Adam Wilson wrote:
>
> Since Aurora has a pluggable backend for rendering I feel that it will be prudent to use the low-level API's that are best suited to each platform. This will Aurora to support each platform as best as possible. As I currently can tell the following list represents
>
> System		 2D API   / 3D API
> Linux		  X11      / OpenGL 4.3
> Android		Canvas	 / OpenGL ES 3.0
> OSX		    Quartz2D / OpenGL 4.3
> iOS		    Quartz2D / OpenGL ES 3.0
> Windows		Direct2D / Direct3D 11
> Windows	RT     Direct2D / Direct3D 11

I'm not really sold on the 2D API not written on top of the 3D API.
Either way, I don't think X11 should be used instead of OpenGL.
I think you should target D3D9 instead of D3D11 on Windows.