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.

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

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

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.

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

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

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.