looking forward to seeing it! I wish you'd release itOriginally Posted by SilverWarior
I've not released mine specifically so I don't step on your toes
looking forward to seeing it! I wish you'd release it
When the moon hits your eye like a big pizza pie - that's an extinction level impact event.
Wait what? Did I read this right? Are you realy waiting with the release of yours as to give me a batter chance of sucsess?looking forward to seeing it! I wish you'd release it
More because you showed such passion for creating a multi-purpous UI and had so many ideas that I didn't want to detract from your work. There's no decent existing UI like you've got planned available yet and if I were to release mine you might lose some potential users simply because they'd integrated mine before you'd had chance to finish even though yours may very well be better for them.
My passion is for my game engine
When the moon hits your eye like a big pizza pie - that's an extinction level impact event.
Wow! I don't know with what did I earned such respect from you but I'm honored you think that way about me. I just hope I won't disapoint you in the end.
Anywhay you don't need to wait for me with publishing of you UI library. The main reason is that I have no idea when it will be finished. It may take a while especially if development will be as slow as it was in the last year.
Anywhay if I achieve desired quality of it I don't think it would matter much wheter it is published first or not. Besides I may even get some good idea from looking at yours.
But the main two reasons why you shouldn't wait for me is:
1. Now that I know you are waiting for me it makes me feel presured which I don't like. Why? When I'm presured I tend to rush things. And when I rush things I tend to make many silly mistakes becouse of which the development takes even longer than it would othervise. This is one of the reasons why I didn't decided to join you in development of your UI library when you invited me to.
2. Based on feedback from many indy game developers that I'm in contact with (mostly giving suggestion on improving their games) I can tell you that most of them are quite frustrated by the fact that even good game engines usually come without decent UI library. Most of them only support verry basic UI library which usually isn't good enough for making decent good loking game UI. So many of them actually had to ither exted those basic UI libraries that come with the game engines they use or make their own. And this is another reason why I'm trying to develop my UI library in such way that it could be used with as many graphical engines as posible.
You say that your pasion is your game engine. Well including your UI library in your game engine would inprove its value greatly and therefore also its sucsess.
So don't wait for me and take care about your sucsess first. Especially since in the end I'm thinking about opening the source for my UI. But I won't do this now becouse I'm afraid that doing so I might be caried away from my initial idea too much.
And for those wondering yes I do intent to shift the focus of my UI library to fully support PGDCE first. But I first need to do another partial rewrite to support another feature that wasn't planned in the beggining but I have seen it requested by some pepole on the internet and my overal design alows pretty easy implementation of it.But I do need to implement it first before I write a design document of what exact capability is needed from the grapgical or game engine so that my UI library can be used with it.
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
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
Last edited by phibermon; 03-02-2015 at 04:23 PM.
When the moon hits your eye like a big pizza pie - that's an extinction level impact event.
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 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
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.
This is also one of the planned feature of my UI.
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.All in all, I wish I'd never started on the UI. I'd of finished the game engine by now
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.
I try to as well, it's good to have others working towards the same goals
it's cool isn't it?
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!
Yes
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
Last edited by phibermon; 03-02-2015 at 04:55 PM.
When the moon hits your eye like a big pizza pie - that's an extinction level impact event.
Posting Permissions
Reply With Quote
Bookmarks