On Monday, 20 January 2014 at 00:12:45 UTC, Adam Wilson wrote:
> On Sun, 19 Jan 2014 14:35:29 -0800, Tofu Ninja <emmons0@purdue.edu> wrote:
>
>> On Sunday, 19 January 2014 at 03:38:30 UTC, Adam Wilson wrote:
>>> ...
>>>
>>> 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.
>>>
>>> ...
>>
>> I am not sure why you feel the need to be one way or the other, why can't aurora support both retained and immediate mode style graphics. From what I can tell, all of the proposed back ends will be immediate mode, so why not just first build nice immediate mode api over the back ends and then build the retained mode on top of that? Both can be exposed to the end user as different ways to get the same thing done. One is not better(or easier) than the other, just suited for different things.
>>
>
> Actually the design I've been working on passes a retained mode data structure to the backend. This gives the backend as much  flexibility as possible to render the command as best as possible given the capabilities of the API the backend is using. But doing it this precludes exposing an immediate mode. The best we could do here is expose a rendering context but it's just going to be a void pointer since the API can't expose the API specific low-level context. Aurora must not leak any low-level backend details to the front-end since that would violate the encapsulation of the low-level API.

That is simply a description of a specific implementation, not a real reason why one would be more beneficial than the other. It is obvious that you want this to be as accessible as possible to the largest range of people posable, so I don't understand why you would insist on limiting the library to just one design style. That will only limit the overall use cases.

On Sat, 18 Jan 2014 19:38:29 -0800, Adam Wilson <flyboynw@gmail.com> wrote:

> 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!
>

So I've reworked the default backend API's list.

System		 2D API   / 3D API
Linux		  X11      / OpenGL 3.2
Android		Canvas	 / OpenGL ES 2.0
OSX		    Quartz2D / OpenGL 3.2
iOS		    Quartz2D / OpenGL ES 2.0
Windows		Direct2D / Direct3D 11
Windows	RT     Direct2D / Direct3D 11

I want to note that I am NOT including D3D9 because Windows XP is EOL in 3 months. Yes DMD still supports Windows XP but as I recall it was decided to deprecated Windows XP support at EOL or shortly afterwards becuase of XP's hacky TLS support. Either way, WinXP is usage is going to start sinking off after EOL and I suspect that by the time Aurora is Beta in a couple of years it will be under 5%. Also since Vista usage is under 5% already I have skipped DX10. That said, I doubt that Aurora will actually need the new capabilities of D3D11, however I can't guarantee that since the shaders aren't written yet. :-)

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator

On Monday, 20 January 2014 at 00:47:54 UTC, Tofu Ninja wrote:
> That is simply a description of a specific implementation, not a real reason why one would be more beneficial than the other. It is obvious that you want this to be as accessible as possible to the largest range of people posable, so I don't understand why you would insist on limiting the library to just one design style. That will only limit the overall use cases.

Possible, not posable, little typo...

On Sun, 19 Jan 2014 02:07:07 -0800, Mike Parker <aldacron@gmail.com> wrote:

> 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
>

Actually those numbers for D3D11 are probably pretty close to accurate since it's OS dependent. WinXP is current 20%-28% depending on the method and Vista is 4%. Since D3D11 is on Windows 7 it is quite widespread. I suspect that with the WinXP EOL in 3 months and the shabby TLS support on XP that DMD will be relatively quick to deprecate WinXP as well. And I also suspect that many people will upgrade away from WinXP quite quickly over the next year.

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator

On Sun, 19 Jan 2014 16:47:49 -0800, Tofu Ninja <emmons0@purdue.edu> wrote:

> On Monday, 20 January 2014 at 00:12:45 UTC, Adam Wilson wrote:
>> On Sun, 19 Jan 2014 14:35:29 -0800, Tofu Ninja <emmons0@purdue.edu> wrote:
>>
>>> On Sunday, 19 January 2014 at 03:38:30 UTC, Adam Wilson wrote:
>>>> ...
>>>>
>>>> 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.
>>>>
>>>> ...
>>>
>>> I am not sure why you feel the need to be one way or the other, why can't aurora support both retained and immediate mode style graphics. From what I can tell, all of the proposed back ends will be immediate mode, so why not just first build nice immediate mode api over the back ends and then build the retained mode on top of that? Both can be exposed to the end user as different ways to get the same thing done. One is not better(or easier) than the other, just suited for different things.
>>>
>>
>> Actually the design I've been working on passes a retained mode data structure to the backend. This gives the backend as much  flexibility as possible to render the command as best as possible given the capabilities of the API the backend is using. But doing it this precludes exposing an immediate mode. The best we could do here is expose a rendering context but it's just going to be a void pointer since the API can't expose the API specific low-level context. Aurora must not leak any low-level backend details to the front-end since that would violate the encapsulation of the low-level API.
>
> That is simply a description of a specific implementation, not a real reason why one would be more beneficial than the other. It is obvious that you want this to be as accessible as possible to the largest range of people posable, so I don't understand why you would insist on limiting the library to just one design style. That will only limit the overall use cases.

Show me how it could be done in a Low-Level API Agnostic way without violating encapsulation (don't leak the low-level API to the front-end) and we'll consider it. If the user must import a Low-Level API (DX/OGL) to work with Aurora under all use cases to get Aurora to compile then we've failed. There might be a way to do it with a special package for that purpose, but it'll have to be carefully built. I still like returning the context as a void pointer for people who know what their doing.

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator

On 1/20/2014 2:37 AM, ponce wrote:

>
> Yeah, when looking at Steam Hardware & Software Survey, you have to be
> aware that it best represents the hardcore gamer segment. The indie and

There was a time when the massive majority of Steam users were hardcore gamers, but I don't believe that quite holds true anymore. Still not an accurate representation of computer users as a whole, but closer than it used to be.

On Monday, 20 January 2014 at 01:15:26 UTC, Adam Wilson wrote:
> Show me how it could be done in a Low-Level API Agnostic way without violating encapsulation (don't leak the low-level API to the front-end) and we'll consider it. If the user must import a Low-Level API (DX/OGL) to work with Aurora under all use cases to get Aurora to compile then we've failed. There might be a way to do it with a special package for that purpose, but it'll have to be carefully built. I still like returning the context as a void pointer for people who know what their doing.

Almost all the backends support the same set of tools, so a proper abstraction over the backends to make an immediate mode api is not farfetched at all. Once that was complete, the retained mode api could be built on top of that without any need to know what was underneath. All I proposing is that an extra layer of abstraction be put in that will greatly increase the flexibility of Aurora.

On Sun, 19 Jan 2014 16:53:31 -0800, Adam Wilson <flyboynw@gmail.com> wrote:

> On Sat, 18 Jan 2014 19:38:29 -0800, Adam Wilson <flyboynw@gmail.com> wrote:
>
>> 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!
>>
>
> So I've reworked the default backend API's list.
>
> System		 2D API   / 3D API
> Linux		  X11      / OpenGL 3.2
> Android		Canvas	 / OpenGL ES 2.0
> OSX		    Quartz2D / OpenGL 3.2
> iOS		    Quartz2D / OpenGL ES 2.0
> Windows		Direct2D / Direct3D 11
> Windows	RT     Direct2D / Direct3D 11
>
> I want to note that I am NOT including D3D9 because Windows XP is EOL in 3 months. Yes DMD still supports Windows XP but as I recall it was decided to deprecated Windows XP support at EOL or shortly afterwards becuase of XP's hacky TLS support. Either way, WinXP is usage is going to start sinking off after EOL and I suspect that by the time Aurora is Beta in a couple of years it will be under 5%. Also since Vista usage is under 5% already I have skipped DX10. That said, I doubt that Aurora will actually need the new capabilities of D3D11, however I can't guarantee that since the shaders aren't written yet. :-)
>

This should read:
Linux		 OpenGL 3.2      / OpenGL 3.2

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator

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




This is tricky for WinRT, which doesn't support OpenGL, but I
think that we should use OpenGL for both 2D and 3D on as many
systems as possible. Not long ago, Valve had a blog post[1] about
how, even on Windows, OpenGL has faster calls. It also keeps the
code under the hood roughly the same despite the system.

Also, if you are looking for an example of using OpenGL for 2D on
multiple systems, take a look at SFML[2]. It's graphics package
is 2D only, but it runs on Windows, Linux, OSX, and the Android
and iOS parts are nearly finished. Definitely more geared towards
games, but it could make a good starting point.

[1] http://blogs.valvesoftware.com/linux/faster-zombies/
[2] https://github.com/LaurentGomila/SFML

On Sun, 19 Jan 2014 21:59:57 -0800, Jeremy DeHaan <dehaan.jeremiah@gmail.com> wrote:

> 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
>
>
>
>
> This is tricky for WinRT, which doesn't support OpenGL, but I
> think that we should use OpenGL for both 2D and 3D on as many
> systems as possible. Not long ago, Valve had a blog post[1] about
> how, even on Windows, OpenGL has faster calls. It also keeps the
> code under the hood roughly the same despite the system.
>
> Also, if you are looking for an example of using OpenGL for 2D on
> multiple systems, take a look at SFML[2]. It's graphics package
> is 2D only, but it runs on Windows, Linux, OSX, and the Android
> and iOS parts are nearly finished. Definitely more geared towards
> games, but it could make a good starting point.
>
> [1] http://blogs.valvesoftware.com/linux/faster-zombies/
> [2] https://github.com/LaurentGomila/SFML

I understand the speed argument, and I keep seeing it, however, Aurora is not primarily about speed, it's about ease of use and working well on a multitude of platforms. As Mike Parker has mentioned more than once, OpenGL on Windows is not quite as consistent in it's rendering of the same command as it is on other platforms due to the fact that GPU vendors are required to implement all of OpenGL instead of just the driver interface. This invariably leads to rendering "bugs". DX doesn't have this problem. So on Windows, for the sake of consistency, Aurora will be using DirectX as the default backend. Note that Mike is primarily responsible for SDL in D so he does know what he is talking about it. I won't stop anybody from writing an OpenGL backend for Windows, it just won't be the default.

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator