Jump to page: 1 26  
Page
Thread overview
Aurora Graphics Library Initial Design Discussion
Jan 19, 2014
Adam Wilson
Jan 19, 2014
Kiith-Sa
Jan 19, 2014
Mike Parker
Jan 19, 2014
Adam Wilson
Jan 19, 2014
Elvis Zhou
Jan 19, 2014
Adam Wilson
Jan 19, 2014
Kelet
Jan 19, 2014
Kelet
Jan 19, 2014
Adam Wilson
Jan 19, 2014
Mike Parker
Jan 19, 2014
ponce
Jan 20, 2014
Mike Parker
Jan 20, 2014
Adam Wilson
Jan 19, 2014
Kagamin
Jan 19, 2014
Tofu Ninja
Jan 19, 2014
Adam Wilson
Jan 19, 2014
Tofu Ninja
Jan 19, 2014
Jacob Carlborg
Jan 19, 2014
Xavier Bigand
Jan 19, 2014
Paulo Pinto
Jan 19, 2014
Zoadian
Jan 20, 2014
Adam Wilson
Jan 20, 2014
Zoadian
Jan 20, 2014
Adam Wilson
Jan 19, 2014
ponce
Jan 19, 2014
Matt Taylor
Jan 20, 2014
Adam Wilson
Jan 20, 2014
Matt Taylor
Jan 20, 2014
Adam Wilson
Jan 21, 2014
Mike Parker
Jan 19, 2014
develop32
Jan 19, 2014
Paul O'Neil
Jan 20, 2014
Adam Wilson
Jan 20, 2014
Adam Wilson
Jan 19, 2014
Tofu Ninja
Jan 20, 2014
Adam Wilson
Jan 20, 2014
Tofu Ninja
Jan 20, 2014
Tofu Ninja
Jan 20, 2014
Adam Wilson
Jan 20, 2014
Tofu Ninja
Jan 20, 2014
Adam Wilson
Jan 20, 2014
ponce
Jan 20, 2014
ponce
Jan 20, 2014
Adam Wilson
Jan 20, 2014
Adam Wilson
Jan 20, 2014
Jacob Carlborg
Jan 20, 2014
Adam Wilson
Jan 20, 2014
Jeremy DeHaan
Jan 20, 2014
Adam Wilson
Jan 20, 2014
Jeremy DeHaan
Jan 20, 2014
Adam Wilson
Jan 21, 2014
Nordlöw
Jan 22, 2014
bioinfornatics
Jan 22, 2014
Tofu Ninja
January 19, 2014
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
January 19, 2014
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?)
January 19, 2014
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.

January 19, 2014
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
January 19, 2014
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.
January 19, 2014
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
January 19, 2014
> 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.
January 19, 2014
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
January 19, 2014
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
January 19, 2014
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
« First   ‹ Prev
1 2 3 4 5 6