Duplicate type names in different modules

Started by col, October 20, 2017, 12:44:12

Previous topic - Next topic

col

Is there a module scope resolution syntax for ng to identify types with a duplicate name which are in different modules.?

Something like


SuperStrict

Import sdl.glsdlmax2d
Local driver:GLMax2DDriver = [...]
[...]

if SDL.GLSDLMax2D.TGLMax2DDriver(driver) then
if BRL.GLMax2D.TGLMax2DDriver(driver) then


https://github.com/davecamp

"When you observe the world through social media, you lose your faith in it."

TomToad

#1
problem here is that driver is defined in several modules.  You will have to use scope resolution to choose the correct driver, but in order to do that, you need to know which driver is being used.

Fortunately, Max2D has a function to return the correct driver to your program.  Then your scope resolution will work
Code (blitzmax) Select
SuperStrict
SetGraphicsDriver GLMax2DDriver()
'SetGraphicsDriver D3D9Max2DDriver()
'SetGraphicsDriver D3D7Max2DDriver()

Local driver:TGraphicsDriver = GetGraphicsDriver()
If brl.GLMax2D.TGLMax2DDriver(driver)
Print "Is TGLMax2DDriver"
Else If brl.d3d9max2d.TD3D9Max2DDriver(driver)
Print "Is TD3D9Max2DDriver"
Else
Print "Is Something Else"
End If
------------------------------------------------
8 rabbits equals 1 rabbyte.

Derron

I think it would be better to have a generic "GetIdentifier()" function in these modules.
Why? For now you need to import all modules to be able to access "brl.GLMax2D.TGLMax2DDriver(driver)" (and the likes).

Would be better to check versus a string (I know, this is less "strict" then as it allows for spelling errors and is error prone when a driver gets renamed).


PS: It is good to see on what you _might_ work currently... I smell R2T-NG-support :-). Glad I fiddle with r2t currently (just thought about continuing my halloween-project)

bye
Ron


col

#3
Quoteproblem here is that driver is defined in several modules.
Uh huh, that is the problem, except your example doesn't show that  ;)

QuoteYou will have to use scope resolution to choose the correct driver, but in order to do that, you need to know which driver is being used
Yes, I do know exactly which modules that they are in, and their expected scope(s).


To use your example to demonstrate the issue... What if TGraphicsDriver is defined in 2 modules?

QuoteI smell R2T-NG-support :-)
;D

There already is the
QuoteGetGraphicsDriver().tostring()
command. I can use that I guess, but like you say it's not as robust. Lets hope that names don't change hehe [EDIT] Or be duplicates ::) Which they are in the SDL drivers  ::)
https://github.com/davecamp

"When you observe the world through social media, you lose your faith in it."

Derron

#4
What you could do is - at least in this scenario:


Code (blitzmax) Select

?win32
  import "myfile_win32.bmx"
?not win32
  import "myfile_generic.bmx"
?

Within that files you can do more OS-specific things. So non-win32 will not have DirectX but might have OpenGL.

Also you could add _more_ conditionals in that files again. This keeps it compatible with vanilla (which does not allow "complex conditionals" while NG also allows for "?win32 or (linux and not android)").


In this specific case you could have a "myfile_vanilla.bmx" and a "myfile_ng.bmx" which might then individually handle OSses again.


bye
Ron

Derron

#5
Regarding duplicates:

what about using "reflection" to retrieve the classname?

Code (blitzmax) Select

local name:string = TTypeID.ForObject( GetGraphicsDriver() ).name()


edit: ah, ok, they share that name - maybe it would be good to rename the sdl one then.

edit2: isn't the SDL one called TGL2Max2DDriver compared to the TGLMax2DDriver of vanilla?

bye
Ron

Derron

#6
Something untested:

Code (blitzmax) Select


Type TMyType
   field runDefaultEngineHandler(driverName:string)

   Method runEngineHandler()
      local driverName:string = TTypeID.ForObject( GetGraphicsDriver() ).name().toLower()

      select driverName
         'normally you would do the following case-statement in an extra file,
         'so you could then do vanilla-compatible checks like
         '?android
         '?raspberry
         '...
         'in that file
         case "TGLMax2DDriver".ToLower()
            '
         ?bmxng
         case "TGL2Max2DDriver".ToLower()
            '
         ?win32
         case "TD3D7Max2DDriver".ToLower()
            '
         case "TD3D9Max2DDriver".ToLower()
            '
         ?
         default
            if runDefaultEngineHandler
               runDefaultEngineHandler(driverName)
            endif
      end select
   End Method
End Type


'when adding a new engine the engine must handle the "handling"
'on its own by hooking into and doing whatever is needed then
'
'of course one should store the function hooks for each "registered" engine
'so better use a TMAP with "enginename"=>functionWrapper
'functionWrapper is a simple type containing the function hook to call
'on execution


Hooks are there to allow for 3rd-party integration (X amount of engines which handle these things on their own - while you only prepared the "known" ones).


Another Idea is to do it similar to the "driver()"-approach of max2D (or audio). Means you provide some drivers doing the render2texture and is up to the user to load the driver corresponding to the graphics renderer driver..

As brl.mod and pub.mod are open source I think it should be possible to add render2texture "officially". And then add the new functionality to sdl.mod too ? In that case the "stub"-functions/methods should contain throw("implement function xyz") so new drivers/engines are aware of missing functionality.




bye
Ron

col

Easiest is best :p

For the time being I changed the names in the SDL drivers, so now I have

[From BRL modules]
DirectX7
DirectX9
OpenGL

[From SDL modules]
SDLDirectX9
SDLOpenGL
SDLOpenGL2

etc.
If it all works out I'll submit a pull to the repo when I've finished what I'm doing.
https://github.com/davecamp

"When you observe the world through social media, you lose your faith in it."

Derron

#8
Just a personal reminder (to myself):

If Brucey kept names that way by intention:
- add "GetFamily:string()" and "GetFamilyVersion:string()" to the basic driver
- directx returns "directx" and "7" (or "9" or "11")
- opengl returns "opengl" and "" (or "sdl")
...
That way an identification would be still possible (if there is some kind of "auto-replaceability check" is planned).


@ easiest is best
My approach above (with the hooks) is there to avoid dependencies. No need to import Brl.glgraphics if you run directx only...

But of course: first make it run, then you can always optimize things.

bye
Ron

col

I appreciate the ideas :) thanks!!

Yeah getting it run first is priority.
The problems come when needing to instantiate the required types, so those modules will need to be included anyway. I wonder if its possible to write code so that gcc will optimize out types that aren't actually instanciated?

I have duplicate types in places:

TD3D9ImageFrame in brl.d3d9max2d and sdl.d3d9sdlmax2d
TGLImageFrame in brl.glmax2d, sdl.glsdlmax2d and sdl.gl2sdlmax2d.

I've opened a can of worms already haha.
Nothing that some easy renaming won't fix though 8)

Maybe I'll make the originals as base types and extends from them... just in case people are using those 'base' types.
https://github.com/davecamp

"When you observe the world through social media, you lose your faith in it."

Derron

GCC wont optimize out ... why? Because reflection allows for instantiation by "strings": fetch the TTypeID of the corresponding driver class and create a new instance via reflection.




@ base types
Yes, good idea. One can never have enough types - TVTower's game source is full of them (classBase, classSimple, class...)


Also base types allow for easier "stubbing" (creating empty functions which you fill in the real types). Just to avoid "interfaces" (NG only, not available in vanilla).




bye
Ron

col

#11
Just for the record...

I have 'render to texture' working in NG 0.87 for brls d3d9 backend for x86 and x64 :-)
There's a couple of module changes to be made, some of the lower level back end function parameters too.

It was easy to keep to the original architecture going after I'd changed the driver names to unique names
[glsdlmax2d.bmx]TGLMax2DDriver -> TGLSDLMax2DDriver
[gl2sdlmax2d.bmx]TGLMax2DDriver -> TGL2SDLMax2DDriver
etc

SDL drivers are next. I have a feeling some of NGs targets won't support rendering to a texturs? Am I correct?

But it's time for some 'me time'. A relaxing game of golf with some pals and tons of fresh air  :D
https://github.com/davecamp

"When you observe the world through social media, you lose your faith in it."

Derron

Which targets should fail? Graphic "engines/drivers" are (at least I think so):


       
  • directx 7,9,11 (Windows)
  • opengl (Windows, Linux, Raspberry PI)
  • opengl es (Android, IOS)
  • webgl
So the only special handling seems to be needed for webgl: "WebGL Lesson 16 – rendering to textures"
http://learningwebgl.com/blog/?p=1786


For me this sounds "possible" and as long as emscripten is not working properly with NG (the issue about "too many setjmps" is still open) the webgl-support is not that needed.


@ golf
Have fun outside with the buddies.


bye
Ron

col

I was mainly thinking of the web based stuff, but it looks like thats covered too nowadays.
Thanks for the link!!
https://github.com/davecamp

"When you observe the world through social media, you lose your faith in it."

GW

Quote from: col on October 22, 2017, 10:33:37
Just for the record...

I have 'render to texture' working in NG 0.87 for brls d3d9 backend for x86 and x64 :-)
There's a couple of module changes to be made, some of the lower level back end function parameters too.


I put up a DX9 render to texture class a while back in the archives.  Maybe it's helpful, should be NG comapatable.
https://www.syntaxbomb.com/index.php/topic,559.0.html