PDA

View Full Version : lazarus and opengl gui?



laggyluk
01-03-2013, 09:21 AM
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

SilverWarior
01-03-2013, 10:34 AM
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.

User137
01-03-2013, 11:00 AM
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.

phibermon
01-03-2013, 06:30 PM
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 :

112211231124

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!

SilverWarior
01-03-2013, 07:45 PM
Wow! That is impresive. It kinda lowers my motivation for making GUI on my own.

phibermon
01-03-2013, 08:20 PM
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 :)

SilverWarior
01-03-2013, 08:56 PM
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.


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.

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.
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.

phibermon
01-03-2013, 09:16 PM
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!

laggyluk
01-03-2013, 10:07 PM
@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..

User137
01-03-2013, 10:43 PM
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..
That is possible to do. Simply render the UI in perspective mode, instead of 2D :) You can use mouse-ray and polygon intersection to get the cursor coordinates inside the perspective UI. Also, the UI is exactly as good as your drawing skills are, hehe. Fully transparent futuristic green glowy thing, or plain boring Windows style, just for few examples. Drag and dropping is supported in window and scrollbar-components at least. Pagecontrol was left unfinished for now.

laggyluk
01-03-2013, 11:10 PM
cool
biggest advantage of flash menus would be easy creation of layout and animations/transitions for it

phibermon
01-03-2013, 11:12 PM
Scaleform? what an utterly horrid corparate cash-cow designed to retain flash development skills that are otherwise totally defunct (not general art skills of course).

You wouldn't need scaleform if flash provided a sane interface for parsing the per frame content

Flash became popular not for it's graphical capabilities (Fantavision was doing that on the Amiga when I was a child) but it's extensive and highly optimized mechansims for compressing that data down for web use - a feature that is not needed in a game already spanning 20gb, it's only about making use of existing flash developers and I use the term developer very, very lightly.

The truth of the matter is if some company came out with somthing as good flash tomorrow but actually licenced the source code, then both flash and scaleform would die a quick death. But they never do come out with somthing as good as flash, because they always decide that a 3D flash is the future, totally forgetting that 90% of artists don't do 3d.

Sorry - off topic I know but scaleform really angered me. Scaleform converts a horse into a car by putting a car body onto the horse and painting wheels on it's hoofs, and all because the company that sells the horse refused to give you the reigns. or somthing like that.

laggyluk
01-03-2013, 11:19 PM
still looks like an easiest way to have a fancy looking menu?

phibermon
01-03-2013, 11:45 PM
Given the content tools available and assuming you can afford it all then yes, without a doubt the easiest way to do fancy menus and the such, have access to a world of artists that are familiar with the tools etc I can't deny that.

But Flash itself is a blight on this civilization.

the utterly abysmal code quality has resulted in somthing like 10 of the 10 greatest zero day hacks ever.

It would be best for all of humanity if Flash were scorched from the surface of the earth, ironically, in a blinding flash.

If Flash were a man, I'd pity that man, I'd walk over to him and push money into his hand so he can get a good meal and a bed for the night.

WILL
02-03-2013, 12:21 AM
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.....

Anyway, I'll stop with the hard sell now and present some screen-shots :

112211231124


Hey, nice GUI! :)

SilverWarior
02-03-2013, 01:17 AM
Why in hell would you like to include flash code into pascal application? This would only introduce more problems if for instance end users won't have necessary runtime libraries to run this flash code on their computers. Not to mention the fact that you would be forced to seperately debug pascal and flash based code.

Creation of layouts and animations in OpenGL isn't as hard as it seems.
Example of how to create slidable menu:
1. Render the whole menu to special texture usually refered as RenderTexture.
2. Create Quad with desired dimensions.
3. Render the Menu texture onto the Quad either using scaling (streching efect) or partial rendering (sliding efect).
Verry similar process is used in FireMonkey. But the biggest probem of FireMonkey is that every controll is seperate single texture rendered on a Quad. That's why when you ZoomIn on FM panel the othervise few pixel thich borderline becomes several milimeter thich black line on the screen (verry ugly by my opinion).

As for UI layout it is only up to you how will you make it.

Since most graphic engines nowadays do have support for RenderTextures you can use theese for optimizing the RenderingRoutine. How?
Lets say that you want to have your games UI divided into several sections where each of this sections is actually created from many small componets (pictures). If theese sections doesn't change often it would be more eficient to render seperate sections into RenderTextures and then update this texture only when necessary. So if section is othervise composed from 10 pictures you can save upto 9 "DrawPictureHere" cals when this section hasn't change from last frame.

Many 3D games make use of RenderTextures for rendering dynamic content on ingame Monitors (survalience cameras, computer screens, TV's, bilboards, mirrors, etc).

laggyluk
02-03-2013, 08:55 AM
In my opinion the biggest problem with firemonkey is that it's bugged like hell.

Chromium has it's own dll with flashplayer. Not sure how smooth interfacing menu to the game would go though ;) On other hand my game is all cubes and flat sprites so maybe I'll just keep it simple.
thanks for the tips guys