Results 1 to 10 of 17

Thread: lazarus and opengl gui?

Hybrid View

Previous Post Previous Post   Next Post Next Post
  1. #1

    lazarus and opengl gui?

    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

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

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

  4. #4
    PGD Staff / News Reporter phibermon's Avatar
    Join Date
    Sep 2009
    Location
    England
    Posts
    524
    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.

  5. #5
    Wow! That is impresive. It kinda lowers my motivation for making GUI on my own.

  6. #6
    PGD Staff / News Reporter phibermon's Avatar
    Join Date
    Sep 2009
    Location
    England
    Posts
    524
    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.

  7. #7
    Co-Founder / PGD Elder WILL's Avatar
    Join Date
    Apr 2003
    Location
    Canada
    Posts
    6,107
    Blog Entries
    25
    Quote Originally Posted by phibermon View Post
    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 :

    Image3.jpgImage4.jpgImage5.jpg
    Hey, nice GUI!
    Jason McMillen
    Pascal Game Development
    Co-Founder





Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •