Duplicate type names in different modules

[Derron]

@ should be compatible
Col is talking about emscripten-support (NG->html5) as this needs or might need a special handling as WebGL is not strictly compatible with/to OpenGL. OpenGL ES (eg. Android) should work with the current implementation.

Col's R2T-type is (imho) superior to the other solutions as it has the same interface for DX and OpenGL - so you do not need to use 2 solutions (the one for DX, the one for OpenGL - like Klepto's or yours) and this makes it easier to _maintain_ compatibility with NG and OS as everything is in "one place".

bye
Ron

[GW]

I didn't notice the webgl reference earlier.

Col's R2T-type is (imho) superior to the other solutions as it has the same interface for DX and OpenGL - so you do not need to use 2 solutions (the one for DX, the one for OpenGL - like Klepto's or yours) and this makes it easier to _maintain_ compatibility with NG and OS as everything is in "one place".

true, but mine and klepto's version don't require any modifications to the brl modules. Just drop in and go.  For me, I don't mind manually binding the texture.

[Derron]

The _current_ implementation of Col should not need modifications too. Modifications are needed once you want to use it with NGs new targets (and SDL).


Your's cannot be used for NG's SDL.mod at all. If you only use it for OpenGL then of course it would work - but I am aiming for flexibility, so people should be able to use DX or OpenGL on Windows, OpenGL/BufferedOpenGL on Linux, OpenGL on Mac - and OpenGL ES / WebGL on other targets. Especially with older GPUs you still have performance penalties for DX _or_ OGL (depends on driver).


The "unification" for DX/OGL/other-targets is what it makes "superior" to yours and Klepto's - but I do not want to say that they are useless -  they just do not fit that nicely into what I am looking for.




bye
Ron

[col]

Thanks for the link GW,

Hehe, both of you need a little correcting 

@GW
Unfortunately your solution doesn't work for full screen modes, hence...

@Derron
For full screen mode rendertarget support you need a modified d3d9graphics file.

Clears that little bit up 

[col]

The modifications that I've made to d3d9graphics allows frameworks outside of BRLs code base to control the lifetime of any objects that need to persist through the 'device lost' state, for eg when Atl-Tabbing in full-screen. It doesn't control the allocation and destruction of those objects, but provides a mechanism to do so in your own code.

On top of which this modification also paved the way as a foundation architecture for d3d9 shader support when used in full screen modes

[col]

I had a proper look into the sdl.mod this afternoon, is it me or are none of the graphics drivers actually using the sdl library for the underlying graphics context and texture creation?

[Derron]

If you use "gl2sdlmax2d" module you will use "OpenGL ES" on platforms requiring it (eg. android).


So the drivers are there to allow "hooking in" of such things without alteriing brl.mod/*






bye
Ron

[col]

No worries.
I thought that GL ES is a limited subset of a shader based GL?

My confusion comes because as the module is named 'SDL*' I was expected a whole ton of SDL_**** commands all over the place in the graphics modules. Instead I see references to the original gl and direct3d functions and interfaces.

I can see plenty of sdl references in the system components. Maybe I've misunderstood how much of sdl is being used?

[Derron]

Cannot help you with this now. This is a subject for "BAH" to answer :-)


I assume the whole thing is already interlocked somehow - so graphics use the SDL subsystem (like SDL events and SDL-timer class).


If that wasn't the way, shouldn't then the "gl2sdlmax2d"-thing be portable to use vanilla brl.*stuff instead of sdl.mod*-stuff?




bye
Ron

[col]

If that wasn't the way, shouldn't then the "gl2sdlmax2d"-thing be portable to use vanilla brl.*stuff instead of sdl.mod*-stuff?

I don't know as the system side of the module looks to use SDL quite extensively, which I imagine is doing all of the heavy lifting for the various platforms system stuff. The graphics side looks tied to the system at 'window' and 'input' points of the code. I am just curious as to why the SDL graphics stuff isn't being used too. I have no doubt that there is a fundamental reason that's not so obvious at first glance - the kind of thing where you get 90% done and then realise... 'ahhh that's why'   

Queue BAH...

[Derron]

Once your module is "NG-SDL"-ready I could try to compile my compo entry for android. So ... hurry up ;-)

bye
Ron