Abstracting Graphical APIs

[phibermon]

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 year And 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

[SilverWarior]

And 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 do care about comunity greatly. Why? As a self taught Delphi programmer I know how hard it can be when you don't know where to turn to get help. When I started learning to program in Delphi its popularity was already in slow decline (that was short before Borland gave up on Delphi). And the only comunity that I was present at the time was Delphi-si comunity which was mostly populated by expirienced busniess programmer who had verry litle intention to try and understand what wild ideas I was trying to do and then help me out.
And boy did I had some wild ideas then (making shell replacment for windows, creating my own drivers for a custom controller - steering wheel that I made, DJ mixing software, etc). When I think about theese ideas now they don't seem so crazy becouse my programming knowledge is probably good enoigh to finish athleast some of them but then my programming knowledge was still far to weak to do anything like that.
So yes becouse I know how hard it can be at start I try to help whenever I can even to total newbies.

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)

This is also one of the planned feature of my UI.

All in all, I wish I'd never started on the UI. I'd of finished the game engine by now

Don't say that! While you are probably not aware of it I'm willing to bet that doing both at the same time actually lead your into making both UI and game engine better as you would do it othervise. Why? Becouse by doing it so you ran to various quirks and difficulties that are specific either for UI or for graphical engine and adjust the designs of both JUI and your game engine to either avoid them or solve them.
Why I think like this? When I started working on my UI library I thought that all I will have to do is write a few methods which will fire several combinations od draw procedures and that is it. But soon I realized that for making of a UI library much more is required like:
1. Input handling: Without ability to handle user input your UI is not Ui but jst a graphical interface
2. Rendering loops: In order fto render you UI in proper way you need to learn about rendering loops
3. Sceene managment: While this might seem unimportant at first look it is quite important especially if you don't want to draw your whole UI right from scratch every rendering cycle. Reusing of already rendered or should I say composed scenes that hasn't changed from previous rendering cycle is the main way of optimizing your rendering cycles.
4. Resource managment: Again at first this might even seem as not neede at all but you quickly realize that it isn't so. When I'm saying resource here I don't only have graphical resources in mind (texutres) but also any other data that you require for your UI like controll positions, controll states, etc.

Anywhay we are getting a bit off topic here. I just hope that we haven't scared Anton with to much information here

@Anton
How ever you decide I'm sure you can count on the help from more knowlegable pepole here on PGD when you will need it.
Unfortuantely I can't count myself into that group but if you will need any help in working with classes I belive I could be usefull as I belive I have pretty god knowlege about them. Not so much about interfaces but that is mostly becouse I myself don't see the need to use them. So far I have always managed to solve everything with classes alone.

[phibermon]

Yes I do care about comunity greatly. Why? As a self taught Delphi programmer I know how hard it can be when you don't know where to turn to get help. [...] So yes because I know how hard it can be at start I try to help whenever I can even to total newbies.

I try to as well, it's good to have others working towards the same goals

This is also one of the planned feature of my UI.

it's cool isn't it? I have a tech demo for my engine where there's a computer on a desk and the computer is 'running' a cut down version of the music sequencer I'm writing for the engine. I wrote a 3D front end for mame many years ago that was a room filled with arcade cabinets and each arcade machine would be running a seperate MAME emulated arcade game. At the time I lacked the 3D modeling experience and ability to work with C++ code to make it anything other than a proof of concept. But the whole idea of a system within a system in that way is very cool

Don't say that! While you are probably not aware of it I'm willing to bet that doing both at the same time actually lead your into making both UI and game engine better as you would do it othervise. Why? Becouse by doing it so you ran to various quirks and difficulties that are specific either for UI or for graphical engine and adjust the designs of both JUI and your game engine to either avoid them or solve them.

This is true, I can't say I've created the best UI but I can definitely say that my UI is suitable for use with a game engine!

1. Input handling [...] 2. Rendering loops [...] 3. Sceene managment [...] 4. Resource managment

Yes All have been key considerations and the design of the both the UI and game engine would be different if it wasn't for the existence of the other. The game engine developed in tandem with the UI and scene editing tool has resulted in a design that can be what you need it to be with the bare minimum of effort on part of the user. There's nothing in the engine that can't be controlled with UI elements, it's forced me to implement a consistent and simple interface.

Same with the UI, the way input is handled between the two, the way it renders, specifics that don't come into play with standard UI development (managing the depth buffer, minimizing texture memory use, self optimizing render paths etc) - Many things are the way they are because it's best for using the 3D hardware along with a 3D engine.

Yep and off topic, my apologies, I do tend to ramble

[SilverWarior]

it's cool isn't it? I have a tech demo for my engine where there's a computer on a desk and the computer is 'running' a cut down version of the music sequencer I'm writing for the engine.

I don't have anything as fancy as you. Not yet anywhay. But when I manage to finish my UI ... Let just say that I already have a few dozens ideas about how I could use this

Yep and off topic, my apologies, I do tend to ramble

I sometimes also have huge urge to share my thoughts so I'm guilty aswell