Aurora Graphics Library Initial Design Discussion

[Adam Wilson]

On Sun, 19 Jan 2014 16:47:49 -0800, Tofu Ninja <emmons0 at 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 at 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