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!

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

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

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.

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

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

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

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

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

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