Abstracting Graphical APIs

[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