I fear that I'll have to write my own gui controls like checkboxes and buttons for my engine ;0
Maybe there is some way to avoid this? Like copying canvas of usual form with buttons to bitmap, display it in opengl and pass clicks to it? sort of offscreen rendering
I don't think that is a good idea. Why? Becouse you will be still limited by slow VCL in Delphi or in your case LCL in Lazarus rendering.
And what is worse is that both VCL or LCL use main applications thread for being rendered and could therefore cause significant slowdowns on your OpenGL part.
There are some existing Pascal GUIs out there which could probably be integrated with your graphical engine. Theese GUIs usually folow two principles of how they are rendered.
One is sprite based approach where GUI just takes care to render necessary sprites (pictures) on corect positions. Theese usually make use of BitFonts (fonts which are actually comprised from many small pictures each representing a leter).
An the other is vector based approach where GUI is actually rendered from series of quads and triangles which can use just one color or have texture rendred on them. This one usually also make use of vector based fonts. The biggest advantage of the second one is the fact that it is easily scalable.
I myself am developing my own GUI library which would hopefully provide an easy way of creating VCL or LCL like controlls in any graphical engine. But unfortunately as with all my other project development is quite slow due to my limited time. So I can't even give you an estimation when it might be compleeted.
There is actually working UI classes in nxPascal, that use OpenGL, rendering quads and texture-based fonts. Actually all the components themselves use textures. Problem is actually building the UI. You can do that manually with code to get the most out of it, but easier way is to use the existing UIEditor. It's just somewhat limited, and has no access to events, which you would have to assign manually anyway. For example onClick events on button, unlike Lazarus that generates such things automatically, you have to write them on your own, search the button by its name and assign the event.
Overall for simple games it's surely easier to just manually draw button graphics on your own, but if you need scrollable TMemo's to for example console window, or dropdown lists, then the UI components can become much easier.
I'll be releasing my engine in the next few months, part of the source that I'll might be making available is my GUI which is as feature rich as any realtime OpenGL GUI currently available. It even surpasses fire-monkey in several key areas (which lets be honest, is not exactly difficult). Treeviews, listviews, time-line track control (like you'd see in animation packages), HSV colour, all manner of buttons, drop down lists, radio groups, right click menus etc basically all standard widgets and a few unique widgets that are graphics related.
It goes a lot further than that however, it's actually a full window manager in that it manages 'applications' and all interaction between client-code and GUI can be serialized over a network connection.
Anyway, I'll stop with the hard sell now and present some screen-shots :
Image3.jpgImage4.jpgImage5.jpg
I will be discussing the actual engine in the next few months, it allows for mixed mode region concepts, so you can nest BSP levels inside terrains, or voxel chunks etc and all interaction (physics, path finding, steering etc) is abstracted for each type of region allowing for seamless operation of engine functionality across regions.
There's still a lot of work to be done however, I'm currently working on optimizations for the renderer for visibility culling (so for example, culling terrain based upon frustum projected out of a BSP portal as well as line of sight optimizations between voxel chunks and terrain geometry etc)
Yes, it was called over ambitious by my friends 5 years ago, but the trick is to never give in, never surrender!
Last edited by phibermon; 01-03-2013 at 06:33 PM.
When the moon hits your eye like a big pizza pie - that's an extinction level impact event.
Wow! That is impresive. It kinda lowers my motivation for making GUI on my own.
Oh there's plenty of room for more GUIs. Mine is locked into it's design now and arguably has more overhead due to it's WM like functionality plus the additonal complexity whilst giving flexibility in a classic 'desktop' sence does force the user to use the GUI in a very specific way.
A GUI for a game would be designed very differently, it'd focus on skinning and would be more streamlined, not have the need for drag and drop handling or other such overheads.
Plus there are other design methodologies when it comes to GUIs, the classical desktop approach is clearly what I favour but again, there's a whole world of touch orientated interfaces that I've not 'touched' on.
I'm working in a tree like methodology where you have a program, it's window, it's widgets etc and it's all designed to work just like that. if you want just a button for example you have to add it within the context of a JUIElement (base class) essentially, it'd need it's own container window (the window manager itself is actually a full screen container so you can actually just add a button)
This means that even if you wanted just a single button, you'd have to do so within the context of the entire window manager (as you would with any classic OS gui)
And my Engine is OpenGL 3.x+ only, so I've not bothered to write renderers for the GUI for anything else.
A game GUI can have a much looser and flexible design, you don't need a message sub-system, you're not constrained by the rules of the system.
IE an awesome game GUI would have say, a compass mini-map and other specialized widgets, it'd have focus on overlay rendering for the game scene (so say stats or other such information rendered on top of the main display) not to mention compositing coolness like 3D effects on window/widget transitions.
Edit : Not to mention some form of game menu aspect to a GUI and other specializations like functionality for rendering conversation trees in an RPG game, widgets for player Inventory management etc
Thinking about it, let me stress that my UI, although it renders in OpenGL; is an application UI. it's clear that a game GUI can be and should be done in a totally different way
There's always room for new GUIs
Last edited by phibermon; 01-03-2013 at 08:50 PM.
When the moon hits your eye like a big pizza pie - that's an extinction level impact event.
While I sad that it lowes my motivation I didn't say that it kills my motivation. I won't just give up so easily as I already have plans of using my GUI in one of my upcoming programs/tools and several of my game ideas.
Also in the end I plan on making my GUI in a way so it could be easily used with different graphic engines offcourse if everything will go as planned.
My plan is actually to integrate some message subsystem into it since I don't only plan on using it in games but also in programs. Well in one program athleast.Originally Posted by phibermon
So can you give me any pointers on this. I would like to have messaging system which is also capable of exchanging messages between different threads if necessary. Using of OmniThread library is out of question as I plan on making my GUI to be platform independent.
More than happy to discuss designs etc and share code. A thread safe message sub-system is actually surprisingly easy, you can have a back-bone system like windows (one big message pipe that you hook into and 'listen' for messages) or you can do the actor style model where every entity within the system has it's own message queue (which is a little overkill for a GUI but as I've found the overhead is well worth the flexibility)
You can go into some really deep univeristy grade concurrency issues here, lock free message queues and all that jazz but truth be told they are about getting the absolute most out of the system. if you don't mind being a teeny weeny little bit slower than optimal then you can effectivly utialize all cores in your system in a manner that doesn't lock up the user experience (or at least noticeably by human eyes) just by using mutex protected message stacks.
Let me know your preferred IM or some way we can discuss stuff and I'll be happy to furnish you with the knowledge and code examples you need, it's not an easy topic to find good information on so hopefully I can save you a lot of the tedious googling of my past!
When the moon hits your eye like a big pizza pie - that's an extinction level impact event.
@phibermon that's some gui you've got there ! I'm lazy so for my editor I just used bunch of forms around central one with opengl context on it but for the game itself I'll need to do something
@User137 thanks, I'll check it out. so far your engine gave me few hints how to go around things
too bad there's no some scaleform equivalent for lazarus
or maybe there is? with delphi firemonkey it's possible to put a chromium browser on a 3d layer, load flash movie in it and voila..
Last edited by laggyluk; 01-03-2013 at 10:13 PM.
That is possible to do. Simply render the UI in perspective mode, instead of 2Dtoo bad there's no some scaleform equivalent for lazarus
or maybe there is? with delphi firemonkey it's possible to put a chromium browser on a 3d layer, load flash movie in it and voila..
Last edited by User137; 01-03-2013 at 10:48 PM.
Posting Permissions
Reply With Quote
Bookmarks