Oh don't feel pressured or anything, I've got so much work to do on the engine and now with PCDCE as well that I doubt I'll be releasing anything for at least a yearAnd in terms of respect? You care about the community as much as anybody could, you do your best to help people, you're polite, courteous and objective when it comes to ideas. If PGD had a dozen of you it'd be one of the best programming forums let alone the best Pascal forum. You have my fullest respect
Yes I intend to release the UI with the engine, it's as capable as any tool-kit GTK etc and has full window management like any OS/Window manager. While the Game engine is openGL only the framework it sits in has a built in 2D engine that has abstracted renderers for Win32/Graphics32, OpenGL, Quartz and a VESA optimized renderer (I was hoping to get it running on CoffeeOS but it'll be a while before that's possible). JUI (the UI) relies on a few parts of the framework and is concidered an add-on like the game engine is. The framework on its own is basically a pascal equivalent to SDL. The UI can render in single-buffered region invalidating mode, direct render, double-buffered with renderbuffers per window (or control), double-buffered direct and a hybrid double-buffered invalidated mode that's optimized for real-time rendering with a number of windows. It times how long it takes to render any region, window control etc and selects the quickest render-path from various buffer/direct schemes for subsequent renders.
The UI also has an 'App' class container to allow it to operate on an OS like level. You can use taskbars/lists for running apps, you can define app dependencies and triggers (for example in my engine tool (JinkEd) if you delete, for example, a camera entity with a camera view app open, the view app will be destroyed as the camera entity is destroyed) the apps can be entirely scripted, directly coded and run in separate threads (and render in separate threads with certain paradigms although on fast GL hardware this render-path is rarely chosen by the manager and is more an optimization for software rendering). It's possible to run any window or indeed any control in it's own thread. Not that you would, but you can. Because scripts are isolated and can run any block in a separate thread it's possible for just a button to crash and the rest of your app to carry on working. (This is also the case with hard-coded elements although writing in this multi-threaded crash aware way is not for the faint hearted)
As well as all the usual menus, drop downs, listviews, treeviews, buttons, radio-groups, sliders, labels, edit boxes etc I've also written some specialized widgets for use in my engine and music studio such as a fairly advanced time-line control for piano rolls (also used for editing the timing/lifespan of mutators in my particle systems) and more uncommon add-ons like widgets for docking and stacking apps into toolbars. It's all unicode and it supports drag and drop internally (trees to lists etc etc) as well as file path drops from windows/linux and osx.
It has anchors for all elements, splitter controls etc. So any layout/resizing scheme you've ever seen in an app can be achieved. Naturally all item and header classes will scale according to the font used, border properties etc You can use different fonts, colours and themes/skins for every single control or window.
It supports custom rendering of any element so you can have skinned interfaces, it includes both square and rounded geometric base classes you can customize and yes it can do all of the silly firemonkey like animation stuff, it can spin and scale any window/button smoothly. Transparency fully supported, 3D rotations, explosions blah blah blah. I really didn't want to add such superfluous things but it's there should anybody really want to use it.
It's primarily designed for OpenGL. It has a pure vertex rendering mode and a customizable shader that allows you to render a very complex UI with thousands of controls without using any GPU memory beyond the loaded shader (you can easily plug it into one of your existing shaders if you have something suitable to save that last little bit of memory) or if memory isn't at a premium you can allow it to create buffers in graphics memory for increased rendering performance. You get to balance performance against memory use as much as you like. I did write a full VBO mode with a past UI that drew everything (including text) but I found that even on really old hardware with thousands of buttons, there was only a marginal performance gain over just using a VBO packed with a few primitives that you reuse to draw everything. Optimized rendering is therefore handled with the buffering/region invalidating raster methods.
The region invalidation works with a special type of widget I have called a Viewport which is used to render 2D/3D custom stuff (so a game for instance). If you decide to handle the callbacks you can have a realtime 3D window that will only re-draw visible portions by way of sending the viewport/camera projection data to the render-pass for the given visible regions
Because it's primarily designed for real-time rendering it also has frame-limiters etc you can use for viewports and you can have Pseudo double-buffering in a single-buffer context so if the user decides to make use of it, one window can be maxed out at 5fps (or locked while a complex scene is rendered) while another window can be churning along at 60fps.
It has primarily been coded on demand while creating a real-time 3D game engine tool that is similar to Blender/Lightwave in capabilities so if you're looking to create a front end to a ray-tracer or want to make the next blender, it's very well suited to the task.
Oh and it can render on a 3D surface inside the game engine itself, either directly with vertex/texture data or purely buffered on a texture. So you can use it to create computer interfaces on doors AKA Doom/Alien Isolation (I suppose the animation effects would be more suitable in such a context) You can also create a GL context and have it aligned with a software rendered window allowing you to encapsulate any GL engine which wasn't designed for or overrides scissors/viewports.
The one thing it doesn't do which I wanted is a client mode where each JUI window is created as a window in the OS, hiding the window frame and using the JUI controls instead. It's possible but I've not written it (yet) you can however hide your window frame and link resizing etc with callbacks to a single JUI window. Dialogs would be better as seperate windows (to be more 'compatible' with Oses like windows) so I may add it eventually.
All in all, I wish I'd never started on the UI. I'd of finished the game engine by now
Reply With Quote
Bookmarks