Hi,
I am going to write map editor in my game. I want to write it GUI Independent, so I can use it like desktop app (eg. with wxwidgets) and like in-game level editor (with some in-game gui).
What is the best way to ensure this behavior?
I have been thinking about writing some abstract gui system used by my app so I can put any gui system behind it.
But this is imho too hard (thik up my own abstract gui system).
Please, show me the way.
L.
GUI-independent app
If you want to decouple component X from component Y, you put an interface between them and avoid programming to a specific implementation. There's nothing special about the case when component X or Y is a GUI.
Hi liquidones
Use an existing lib or create a new one (if you must), but to make one abstract to cover any existing gui... it's madness. It's like saying:
"I'm going to create a new abstract planet to cover for any existing planet"
Good luck chap.
Use an existing lib or create a new one (if you must), but to make one abstract to cover any existing gui... it's madness. It's like saying:
"I'm going to create a new abstract planet to cover for any existing planet"
Good luck chap.
Look in to the model-view-controller design pattern. Basically build your level editor such that it doesn't do any gui or inputs at all. This will be the model. Then you can build and attach different GUIs as necessary(view ) and build abstract input handling (controller) that you can hook up to whatever you are using for input.
An approach we have looked at lately is using embedded browser systems. They're kind of in their infancy but they are usable.
Way it works is this -- you have a browser engine. It'll basically draw a HTML/JScript/Flash page into an output. We used a bit where they'll draw to what are effectively Cairo canvases.
The canvases can then be used either in the game environment by drawing them as textures into 2D quads or they can simply be drawn as is into system windows using bitblt or X11 image rendering.
They need to be passed keyboard and mouse events but that can be handled with a fairly thin layer that sends stuff to the right place.
They can then be set up to do callbacks from javascript, or even to pass whole namespaces to C functions for resolution -- so we have a REST api which the javascript can talk to in the app which will do the work.<br><br>This way, you can then just do everything in web widget sets.<br><br>Most of this stuff is based on Chrome/Webkit and is hence pretty cross platform as well.<br>
Way it works is this -- you have a browser engine. It'll basically draw a HTML/JScript/Flash page into an output. We used a bit where they'll draw to what are effectively Cairo canvases.
The canvases can then be used either in the game environment by drawing them as textures into 2D quads or they can simply be drawn as is into system windows using bitblt or X11 image rendering.
They need to be passed keyboard and mouse events but that can be handled with a fairly thin layer that sends stuff to the right place.
They can then be set up to do callbacks from javascript, or even to pass whole namespaces to C functions for resolution -- so we have a REST api which the javascript can talk to in the app which will do the work.<br><br>This way, you can then just do everything in web widget sets.<br><br>Most of this stuff is based on Chrome/Webkit and is hence pretty cross platform as well.<br>
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
