www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Aurora Graphics Library Initial Design Discussion

reply "Adam Wilson" <flyboynw gmail.com> writes:
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!

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator
Jan 18 2014
next sibling parent reply "Kiith-Sa" <kiithsacmp gmail.com> writes:
On Sunday, 19 January 2014 at 03:38:30 UTC, Adam Wilson 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!

GL ES 3.0 is a subset of some 4.x version AFAIK, so it may be enough to only target that instead of separately targeting GL 4.3 . Also, why not OpenGL for 2D on Linux (and possibly elsewhere) ? Also - I think there should be a possibility to switch between e.g. GL and D3D on Windows (I assume that's intended?)
Jan 18 2014
parent Mike Parker <aldacron gmail.com> writes:
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.
Jan 19 2014
prev sibling next sibling parent "Mike Parker" <aldacron gmail.com> writes:
On Sunday, 19 January 2014 at 04:26:48 UTC, Kiith-Sa wrote:

 Also, why not OpenGL for 2D on Linux (and possibly elsewhere) ?

+1. Anywhere you're using OpenGL, you can use it for both the 2D and 3D renderers. That will also allow a lot of shared code between the two. The same holds for D3D, actually. It would be convenient to wrap D2D for the 2D renderer, but you'll cut down on the amount of code by using D3D for both.
Jan 18 2014
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Sat, 18 Jan 2014 20:26:47 -0800, Kiith-Sa <kiithsacmp gmail.com> wrote:

 On Sunday, 19 January 2014 at 03:38:30 UTC, Adam Wilson 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!

GL ES 3.0 is a subset of some 4.x version AFAIK, so it may be enough to only target that instead of separately targeting GL 4.3 .

It may well be, but I don't want to rule out the possibility that something may be easy under OpenGL 4.3 and slightly more difficult but not impossible under OpenGL ES 3.0. In that case you could make a case for supporting different backends. One of the main goals of Aurora, is to make the backend produce the results Aurora demands, not the other way around, so letting the backend API dictate the front-end runs against that goal.
 Also, why not OpenGL for 2D on Linux (and possibly elsewhere) ?

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.
 Also - I think there should be a possibility to switch between e.g. GL  
 and D3D on Windows (I assume that's intended?)

Yes, you would just have to specify the OpenGL backend. Aurora will default to the best backend for the platform, but if you know that something else is available you are welcome to use it. For all practical purposes though the system default will be the best. The only reason to use OpenGL on Windows is ideology, Aurora will render the scene graph identically to DirectX. -- Adam Wilson GitHub/IRC: LightBender Aurora Project Coordinator
Jan 18 2014
prev sibling next sibling parent "Elvis Zhou" <elvis.x.zhou gmail.com> writes:
On Sunday, 19 January 2014 at 04:45:30 UTC, Adam Wilson wrote:
 On Sat, 18 Jan 2014 20:26:47 -0800, Kiith-Sa 
 <kiithsacmp gmail.com> wrote:

 On Sunday, 19 January 2014 at 03:38:30 UTC, Adam Wilson 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!

GL ES 3.0 is a subset of some 4.x version AFAIK, so it may be enough to only target that instead of separately targeting GL 4.3 .

It may well be, but I don't want to rule out the possibility that something may be easy under OpenGL 4.3 and slightly more difficult but not impossible under OpenGL ES 3.0. In that case you could make a case for supporting different backends. One of the main goals of Aurora, is to make the backend produce the results Aurora demands, not the other way around, so letting the backend API dictate the front-end runs against that goal.
 Also, why not OpenGL for 2D on Linux (and possibly elsewhere) ?

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.
 Also - I think there should be a possibility to switch between 
 e.g. GL and D3D on Windows (I assume that's intended?)

Yes, you would just have to specify the OpenGL backend. Aurora will default to the best backend for the platform, but if you know that something else is available you are welcome to use it. For all practical purposes though the system default will be the best. The only reason to use OpenGL on Windows is ideology, Aurora will render the scene graph identically to DirectX.

Oops, I thought this is the official repo!! It's a new package added to code.dlang.org yesterday.
Jan 18 2014
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Sat, 18 Jan 2014 21:23:23 -0800, Elvis Zhou <elvis.x.zhou gmail.com>  
wrote:

 On Sunday, 19 January 2014 at 04:45:30 UTC, Adam Wilson wrote:
 On Sat, 18 Jan 2014 20:26:47 -0800, Kiith-Sa <kiithsacmp gmail.com>  
 wrote:

 On Sunday, 19 January 2014 at 03:38:30 UTC, Adam Wilson 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!

GL ES 3.0 is a subset of some 4.x version AFAIK, so it may be enough to only target that instead of separately targeting GL 4.3 .

It may well be, but I don't want to rule out the possibility that something may be easy under OpenGL 4.3 and slightly more difficult but not impossible under OpenGL ES 3.0. In that case you could make a case for supporting different backends. One of the main goals of Aurora, is to make the backend produce the results Aurora demands, not the other way around, so letting the backend API dictate the front-end runs against that goal.
 Also, why not OpenGL for 2D on Linux (and possibly elsewhere) ?

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.
 Also - I think there should be a possibility to switch between e.g. GL  
 and D3D on Windows (I assume that's intended?)

Yes, you would just have to specify the OpenGL backend. Aurora will default to the best backend for the platform, but if you know that something else is available you are welcome to use it. For all practical purposes though the system default will be the best. The only reason to use OpenGL on Windows is ideology, Aurora will render the scene graph identically to DirectX.

Oops, I thought this is the official repo!! It's a new package added to code.dlang.org yesterday.

Yea, that's not it. It's an odd choice for name though since we've been using Aurora for the past couple of weeks here on the forums. I wonder if he has been keeping track of the forums, and if he has it's kind of a silly thing to do... The link to the Aurora project being discussed here is: https://github.com/auroragraphics -- Adam Wilson GitHub/IRC: LightBender Aurora Project Coordinator
Jan 18 2014
prev sibling next sibling parent "Tofu Ninja" <emmons0 purdue.edu> writes:
 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.
Jan 18 2014
prev sibling next sibling parent "Kelet" <kelethunter gmail.com> writes:
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. 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
Jan 18 2014
prev sibling next sibling parent "Kelet" <kelethunter gmail.com> writes:
On Sunday, 19 January 2014 at 06:02:13 UTC, Kelet wrote:

 My thoughts:

 ARM support is abysmal in D, IIRC.

Realized I may have used strong wording here when a lot of fine work is currently being done. My apologizes, I'm not well-researched into this area of D. Regards, Kelet
Jan 18 2014
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
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. -- Adam Wilson GitHub/IRC: LightBender Aurora Project Coordinator
Jan 18 2014
prev sibling next sibling parent "Tofu Ninja" <emmons0 purdue.edu> writes:
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.
Jan 18 2014
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
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
Jan 18 2014
prev sibling next sibling parent "Mike Parker" <aldacron gmail.com> writes:
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
Jan 19 2014
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
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.
Jan 19 2014
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
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
Jan 19 2014
prev sibling next sibling parent reply Xavier Bigand <flamaros.xavier gmail.com> writes:
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.
Jan 19 2014
parent Paulo Pinto <pjmlp progtools.org> writes:
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
Jan 19 2014
prev sibling next sibling parent "Zoadian" <github zoadian.de> writes:
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
Jan 19 2014
prev sibling next sibling parent "ponce" <contact gam3sfrommars.fr> writes:
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.
Jan 19 2014
prev sibling next sibling parent reply "ponce" <contact gam3sfrommars.fr> writes:
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.
Jan 19 2014
parent Mike Parker <aldacron gmail.com> writes:
On 1/21/2014 4:49 AM, Adam Wilson wrote:
 On Mon, 20 Jan 2014 05:09:14 -0800, Matt Taylor <taylorius gmail.com>
 wrote:

 On Monday, 20 January 2014 at 00:23:37 UTC, Adam Wilson wrote:

 Aurora will not be exposing any low-level API to the front-end, that
 would be a pretty serious encapsulation violation and could have some
 pretty bad consequences for the rest of the API.

Fair enough, it sounds like decisions have been made. :-) Personally, I think its a shame - it's not at all clear to me that abstraction and encapsulation deserve such primacy, at the expense of so many other things - but it is what it is. I look forward to seeing how the API shapes up. Cheers Matt Taylor

Well, one of the things that is being discussed is wrapping the low-level API's into an abstraction layer then using that abstraction to build the retained mode API. This would give you access immediate mode rendering, and it would be easier to expose the rendering context to that API than it would be the retained mode API.

In order to have pluggable renderers, the low-level APIs have to be abstracted anyway. The renderer hides the low-level, and the higher-level renders through that interface. Whether or not the renderer API is exposed determines what sort of flexibility you have with the API design at that level. As long as it's hidden, you can make changes and adjustments as necessary. If it's intended to be exposed, then the design has to be fairly rock solid up front and it becomes more difficult to adapt in the future because of backwards compatibility.
Jan 21 2014
prev sibling next sibling parent "Matt Taylor" <taylorius gmail.com> writes:
On Sunday, 19 January 2014 at 17:44:57 UTC, ponce wrote:
 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.

My vote would be for selectable back ends, with OpenGL availability across the board. This opens up the possibility to do some cross platform 3d graphics with some d binding of OpenGL, using aurora's rendering context. I know it's not what aurora is for, but it would be useful, and wouldn't cost much to allow. Cheers Matt
Jan 19 2014
prev sibling next sibling parent Paul O'Neil <redballoon36 gmail.com> writes:
On 01/18/2014 10:38 PM, 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

 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.

The choice of X11 (as it is generally used now) / Wayland seems to be the wrong layer of abstraction to me. While X11 has drawing privimitives, my understanding is that they are generally not used. This is one of the motivating reasons for developing Wayland. Applications draw their content, then send it to X to display on the screen. Wayland is designed around this path. Choosing X11/Wayland as a backend is fine, but it would require that there be something filling up the framebuffer (Cairo, OpenGL, whatever). On the other hand, choosing a renderer (Cairo, OpenGL...) doesn't specify how the content gets to the screen, so I think there's really 2 choices here: rendering backend and windowing backend. The 3D API will still need to depend on X11/Wayland to get a window on screen. I have no knowledge of how input works in either X11 or Wayland. Writing Aurora to render to some kind of buffer is future-proof enough against Wayland, I think. Likely, the initial set-up and input would have to be rewritten, but the rest would be OK. Caveat: I'm only ~80% sure about all of this. My GPU only supports OpenGL 3.x... maybe it's getting old. Paul
Jan 19 2014
prev sibling next sibling parent "develop32" <develop32 gmail.com> writes:
On Sunday, 19 January 2014 at 17:44:57 UTC, ponce wrote:
 I think you should target D3D9 instead of D3D11 on Windows.

I have to disagree, I doubt it that Aurora will use D3D11-only features, I imagine any gpu that supports Feature Level 9 will be fine, the only requirement for user is to have OS newer than Windows XP.
Jan 19 2014
prev sibling next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.

What kind of retained mode API is being considered? Is this indicating a possible change of direction in favour of a scene graph model?
Jan 19 2014
prev sibling next sibling parent "Tofu Ninja" <emmons0 purdue.edu> writes:
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.
Jan 19 2014
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
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. -- Adam Wilson GitHub/IRC: LightBender Aurora Project Coordinator
Jan 19 2014
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Sun, 19 Jan 2014 13:31:08 -0800, Ola Fosheim Gr=F8stad  =

<ola.fosheim.grostad+dlang gmail.com> 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 =


 easier for developers that are unfamiliar with writing graphics code =


 express their intent.

What kind of retained mode API is being considered? Is this indicating a possible change of direction in favour of a scene=

 graph model?

I am not sure yet, probably a scene graph though or some hybrid thereof.= = They have the advantage of being easy to understand and use. -- = Adam Wilson GitHub/IRC: LightBender Aurora Project Coordinator
Jan 19 2014
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Sun, 19 Jan 2014 11:47:11 -0800, Paul O'Neil <redballoon36 gmail.com>  
wrote:

 On 01/18/2014 10:38 PM, 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

 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.

The choice of X11 (as it is generally used now) / Wayland seems to be the wrong layer of abstraction to me. While X11 has drawing privimitives, my understanding is that they are generally not used. This is one of the motivating reasons for developing Wayland. Applications draw their content, then send it to X to display on the screen. Wayland is designed around this path. Choosing X11/Wayland as a backend is fine, but it would require that there be something filling up the framebuffer (Cairo, OpenGL, whatever). On the other hand, choosing a renderer (Cairo, OpenGL...) doesn't specify how the content gets to the screen, so I think there's really 2 choices here: rendering backend and windowing backend. The 3D API will still need to depend on X11/Wayland to get a window on screen. I have no knowledge of how input works in either X11 or Wayland. Writing Aurora to render to some kind of buffer is future-proof enough against Wayland, I think. Likely, the initial set-up and input would have to be rewritten, but the rest would be OK. Caveat: I'm only ~80% sure about all of this. My GPU only supports OpenGL 3.x... maybe it's getting old. Paul

As I understand it there will always be an X11/Wayland dependency to get the window but to be honest I would like to keep the usage of X11 to a minimum. I have a feeling that the 2D portions of the backend for Linux will be written in OpenGL. -- Adam Wilson GitHub/IRC: LightBender Aurora Project Coordinator
Jan 19 2014
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Sun, 19 Jan 2014 11:46:22 -0800, Matt Taylor <taylorius gmail.com>  
wrote:

 On Sunday, 19 January 2014 at 17:44:57 UTC, ponce wrote:
 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.

My vote would be for selectable back ends, with OpenGL availability across the board. This opens up the possibility to do some cross platform 3d graphics with some d binding of OpenGL, using aurora's rendering context. I know it's not what aurora is for, but it would be useful, and wouldn't cost much to allow. Cheers Matt

Aurora will not be exposing any low-level API to the front-end, that would be a pretty serious encapsulation violation and could have some pretty bad consequences for the rest of the API. -- Adam Wilson GitHub/IRC: LightBender Aurora Project Coordinator
Jan 19 2014
prev sibling next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 20 January 2014 at 00:15:01 UTC, Adam Wilson wrote:
 I am not sure yet, probably a scene graph though or some hybrid 
 thereof. They have the advantage of being easy to understand 
 and use.

Sounds like a good idea as it allows you to implement a standard extensible UI on top of it. If done right you could use it for UI/HUD on top of a 3D engine too by setting the zbuffer value close to the eye. 1. draw 2D UI with close z-value or stencil 2. draw 3D beneath it/or video etc This could be very useful for both creating media tools/editors and games. (Creating a 2D platform that allows you to do evolutionary design of a UI layered on top of other media.)
Jan 19 2014
prev sibling next sibling parent "Tofu Ninja" <emmons0 purdue.edu> writes:
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.
Jan 19 2014
prev sibling next sibling parent reply "Adam Wilson" <flyboynw gmail.com> writes:
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
Jan 19 2014
parent Jacob Carlborg <doob me.com> writes:
On 2014-01-20 01:53, Adam Wilson wrote:

 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

Thanks for lowering the requirements. -- /Jacob Carlborg
Jan 19 2014
prev sibling next sibling parent "Tofu Ninja" <emmons0 purdue.edu> writes:
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...
Jan 19 2014
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
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
Jan 19 2014
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
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
Jan 19 2014
prev sibling next sibling parent "Tofu Ninja" <emmons0 purdue.edu> writes:
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.
Jan 19 2014
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
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
Jan 19 2014
prev sibling next sibling parent "Jeremy DeHaan" <dehaan.jeremiah gmail.com> writes:
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
Jan 19 2014
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
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
Jan 19 2014
prev sibling next sibling parent "Jeremy DeHaan" <dehaan.jeremiah gmail.com> writes:
On Monday, 20 January 2014 at 06:11:45 UTC, Adam Wilson wrote:
 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.

Actually, that's isn't a bad point. One thing I forgot to mention(though I suppose it is a little moot to bring it up now), is that OpenGL depends on what the video card supports, so even on Windows XP, someone could still access OpenGl 3+, which is increadibly common these days. That might be something to consider. That aside, I'm pretty excited for this. I have many, MANY, ideas for things that I will be making once this is up and running. I work on the D binding for SFML, so I have a tiny bit of experience when it comes to some of these things. I would love to help in any way that I can!
Jan 19 2014
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Sun, 19 Jan 2014 22:43:30 -0800, Jeremy DeHaan  
<dehaan.jeremiah gmail.com> wrote:

 On Monday, 20 January 2014 at 06:11:45 UTC, Adam Wilson wrote:
 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.

Actually, that's isn't a bad point. One thing I forgot to mention(though I suppose it is a little moot to bring it up now), is that OpenGL depends on what the video card supports, so even on Windows XP, someone could still access OpenGl 3+, which is increadibly common these days. That might be something to consider. That aside, I'm pretty excited for this. I have many, MANY, ideas for things that I will be making once this is up and running. I work on the D binding for SFML, so I have a tiny bit of experience when it comes to some of these things. I would love to help in any way that I can!

We'll we're happy to have you on board! I think it would be good to point out that WinXP is End-Of-Life in 3 months and IIRC DMD is planning on dropping WinXP shortly after EOL because of the shabby TLS support. So for the most part I don't think WinXP is worth supporting going forward. -- Adam Wilson GitHub/IRC: LightBender Aurora Project Coordinator
Jan 19 2014
prev sibling next sibling parent "ponce" <contact gam3sfrommars.fr> writes:
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.

SDL does something like that: http://wiki.libsdl.org/CategorySWM It can be very useful, for example in SDL 1.2 it can allows to implement drag-and-drop or use a particular DirectX version.
Jan 20 2014
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Sun, 19 Jan 2014 23:49:02 -0800, Jacob Carlborg <doob me.com> wrote:

 On 2014-01-20 01:53, Adam Wilson wrote:

 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

Thanks for lowering the requirements.

You're welcome. I was initially trying to target something that was uniform at the API level, because, as near as I can tell OpenGL 4.3 and OpenGL ES are completely compatible. But I hadn't been able to dig information on what platforms and hardware were actually supported because apparently my Google-fu wasn't good enough. I do agree that we need to build for something that works on all platforms, if not all versions of each platform, so I figured, which is why I asked for help with that list. :-) -- Adam Wilson GitHub/IRC: LightBender Aurora Project Coordinator
Jan 20 2014
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Sun, 19 Jan 2014 17:38:26 -0800, Tofu Ninja <emmons0 purdue.edu> wrote:

 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.

Ok, I see were you are headed now, and it's not an all bad idea. Although it will introduce a layer of abstraction, however thin, that will negatively affect performance. If that is acceptable to the community I am fine with that since we've never claimed that Aurora was going to set any speed records, nor are we trying to. It won't make for the best gaming performance, but it should allow for reasonable performance in most scenarios. I'll put this on the list as tentative pending community approval. :-) -- Adam Wilson GitHub/IRC: LightBender Aurora Project Coordinator
Jan 20 2014
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Sun, 19 Jan 2014 05:34:46 -0800, Zoadian <github zoadian.de> wrote:

 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

I think because of timezones I keep missing you. I live on the US West Coast so we're a few hours apart. I do apologize for the naming confusion. Walter and I picked the name a few weeks ago without any knowledge of your work at the time. If you would be willing to rename your engine that would be very appreciated. As for combining efforts, it would mean that you'd have to conform to the goals of Aurora, and I don't know that you'd want too. And it might actually be better to have your engine separate as more of purpose-built game engine where Aurora is targeted at a more general graphics audience. Those are my thoughts, what are you thinking? -- Adam Wilson GitHub/IRC: LightBender Aurora Project Coordinator
Jan 20 2014
prev sibling next sibling parent "ponce" <contact gam3sfrommars.fr> writes:
 On Monday, 20 January 2014 at 01:15:26 UTC, Adam Wilson wrote:

 Ok, I see were you are headed now, and it's not an all bad 
 idea. Although it will introduce a layer of abstraction, 
 however thin, that will negatively affect performance. If that 
 is acceptable to the community I am fine with that since we've 
 never claimed that Aurora was going to set any speed records, 
 nor are we trying to. It won't make for the best gaming 
 performance, but it should allow for reasonable performance in 
 most scenarios.

 I'll put this on the list as tentative pending community 
 approval. :-)

Hi Adam, There is an interesting project at github: https://github.com/bkaradzic/bgfx I think their API is retained mode like you suggested. Maybe it's worth looking at their back-end abstraction.
Jan 20 2014
prev sibling next sibling parent "Matt Taylor" <taylorius gmail.com> writes:
On Monday, 20 January 2014 at 00:23:37 UTC, Adam Wilson wrote:

 Aurora will not be exposing any low-level API to the front-end, 
 that would be a pretty serious encapsulation violation and 
 could have some pretty bad consequences for the rest of the API.

Fair enough, it sounds like decisions have been made. :-) Personally, I think its a shame - it's not at all clear to me that abstraction and encapsulation deserve such primacy, at the expense of so many other things - but it is what it is. I look forward to seeing how the API shapes up. Cheers Matt Taylor
Jan 20 2014
prev sibling next sibling parent "Zoadian" <d d.de> writes:
On Monday, 20 January 2014 at 08:34:47 UTC, Adam Wilson wrote:
 On Sun, 19 Jan 2014 05:34:46 -0800, Zoadian <github zoadian.de> 
 wrote:

 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

I think because of timezones I keep missing you. I live on the US West Coast so we're a few hours apart. I do apologize for the naming confusion. Walter and I picked the name a few weeks ago without any knowledge of your work at the time. If you would be willing to rename your engine that would be very appreciated. As for combining efforts, it would mean that you'd have to conform to the goals of Aurora, and I don't know that you'd want too. And it might actually be better to have your engine separate as more of purpose-built game engine where Aurora is targeted at a more general graphics audience. Those are my thoughts, what are you thinking?

As we have no interrest in interfering with your efforts, we have decided to rename our engine. The new name - three.d suits us well and I believe that way both sides can be happy. Our engine will be implemented with performance in mind which unfortuntately contradicts with your design ideas. Zoadian
Jan 20 2014
prev sibling next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 20 January 2014 at 08:29:32 UTC, Adam Wilson wrote:
 Ok, I see were you are headed now, and it's not an all bad 
 idea. Although it will introduce a layer of abstraction, 
 however thin, that will negatively affect performance.

Actually, a scene graph can be reasonable efficient if you provide caching hints on the nodes, but the underlying engine should match up to the hardware on mobile units. OpenGL is not sufficient. So keep that in mind if you want to create a shared abstraction layer. (I think you will be better off not using one.) Just to give you an idea of different characteristics (not entirely accurate): A tiled mobile GPU has: - slow shaders - shaders should draw every pixel in a triangle - slow CPU - less non-GPU memory (it might share with CPU though) - possibly fast CPU/GPU connection (if using the same memory) - slower texturing/memory - fewer texturing units - wants few triangles of a particular size and do all the sorting for you whether you want it or not. A discrete desktop GPU has: - fast shaders - shaders can abort drawing some pixels in a triangle - fast GPU memory - relatively slow connection to CPU (PCI) - lots of non-GPU memory - takes any triangle config, but you have to do the sorting yourself CPU integrated GPUs may get - much faster draw calls so you don't have to bundle (AMD Mantle) - may have shared cache with CPU (fast CPU/GPU communication?) - somewhere between discrete/mobile GPU in terms of shaders/texturing
 never claimed that Aurora was going to set any speed records, 
 nor are we trying to. It won't make for the best gaming 
 performance, but it should allow for reasonable performance in 
 most scenarios.

The Flash scene graph performs quite well. Largely because you provide caching hints to the engine (stating whether a drawing is likely to change between frames or not). Cocos2D and most other gaming scene graphs follow the same model, I believe.
Jan 20 2014
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Mon, 20 Jan 2014 05:09:14 -0800, Matt Taylor <taylorius gmail.com>  
wrote:

 On Monday, 20 January 2014 at 00:23:37 UTC, Adam Wilson wrote:

 Aurora will not be exposing any low-level API to the front-end, that  
 would be a pretty serious encapsulation violation and could have some  
 pretty bad consequences for the rest of the API.

Fair enough, it sounds like decisions have been made. :-) Personally, I think its a shame - it's not at all clear to me that abstraction and encapsulation deserve such primacy, at the expense of so many other things - but it is what it is. I look forward to seeing how the API shapes up. Cheers Matt Taylor

Well, one of the things that is being discussed is wrapping the low-level API's into an abstraction layer then using that abstraction to build the retained mode API. This would give you access immediate mode rendering, and it would be easier to expose the rendering context to that API than it would be the retained mode API. -- Adam Wilson GitHub/IRC: LightBender Aurora Project Coordinator
Jan 20 2014
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Mon, 20 Jan 2014 08:24:25 -0800, Zoadian <d d.de> wrote:

 On Monday, 20 January 2014 at 08:34:47 UTC, Adam Wilson wrote:
 On Sun, 19 Jan 2014 05:34:46 -0800, Zoadian <github zoadian.de> wrote:

 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

I think because of timezones I keep missing you. I live on the US West Coast so we're a few hours apart. I do apologize for the naming confusion. Walter and I picked the name a few weeks ago without any knowledge of your work at the time. If you would be willing to rename your engine that would be very appreciated. As for combining efforts, it would mean that you'd have to conform to the goals of Aurora, and I don't know that you'd want too. And it might actually be better to have your engine separate as more of purpose-built game engine where Aurora is targeted at a more general graphics audience. Those are my thoughts, what are you thinking?

As we have no interrest in interfering with your efforts, we have decided to rename our engine. The new name - three.d suits us well and I believe that way both sides can be happy. Our engine will be implemented with performance in mind which unfortuntately contradicts with your design ideas. Zoadian

Thank you for being understanding and flexible with us. I think that name works quite well, it's most appropriate for 3D engine in D. I look forward to seeing what you guys build up as 3D game programming was my career track of choice in school. :-) -- Adam Wilson GitHub/IRC: LightBender Aurora Project Coordinator
Jan 20 2014
prev sibling next sibling parent =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:
Adam D Ruppe has done some initial work on a GUI library for D at

https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/minigui.d

with backends for XWindows and MS Windows C API.

Maybe you could get some input/ideas from there?

/Per
Jan 21 2014
prev sibling next sibling parent "bioinfornatics" <bioinfornatics feforaproject.org> writes:
On Tuesday, 21 January 2014 at 10:30:21 UTC, Nordlöw wrote:
 Adam D Ruppe has done some initial work on a GUI library for D 
 at

 https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/minigui.d

 with backends for XWindows and MS Windows C API.

 Maybe you could get some input/ideas from there?

They had A nice gui lib named rae Written With opengl http://www.dsource.org/projects/rae
Jan 21 2014
prev sibling parent "Tofu Ninja" <emmons0 purdue.edu> writes:
On Tuesday, 21 January 2014 at 10:30:21 UTC, Nordlöw wrote:
 Adam D Ruppe has done some initial work on a GUI library for D 
 at

 https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/minigui.d

 with backends for XWindows and MS Windows C API.

 Maybe you could get some input/ideas from there?

 /Per

One thing to remember about Aurora is that it itself is not a gui library, it is a graphics library.
Jan 21 2014