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
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 parent reply "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
next sibling parent reply "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.


https://github.com/Zoadian/aurora
Oops, I thought this is the official repo!! It's a new package 
added to code.dlang.org yesterday.
Jan 18 2014
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.


 https://github.com/Zoadian/aurora
 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 parent reply "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
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 parent reply "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
next sibling parent reply "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
next sibling parent reply "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
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 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 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 parent reply "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
parent reply "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
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 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 reply "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
parent reply "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
parent reply "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
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 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
next sibling parent reply "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
parent reply "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
parent reply "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
parent reply "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
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 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 reply 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
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 reply "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
parent reply "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 =




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?


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
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 reply "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
parent reply "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
parent reply "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
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 parent reply "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
next sibling parent reply "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
parent reply "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
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 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 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 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
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 parent reply 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
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 reply "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
parent reply "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
parent reply "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
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 parent reply =?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
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