Qube's Game Framework - The dreaded GUI

[blinkok]

Super awesome. Really looks neat. Do you do that with the scissor command or render to a canvas?

[Qube]

Super awesome. Really looks neat. Do you do that with the scissor command or render to a canvas?

Thanks - It's with the scissor command which is a pain as the container also needs a scissor command to allow for window dimensions that are larger than the container and you can't have a scissor within a scissor so it took a little faff about to work smoothly.

Writing a GUI really needs some form of OOP but AGK doesn't have OOP. When I set about this I didn't want to have any part of the GUI in a DIM or have any limits on the amount of windows or gadgets. So what was the solution?. AGK does have Types which in a way can act like a sudo OOP for referencing, so I can have things like window.xpos window.ypos etc etc. Granted types only return things like integers, floats or string etc, but it offers enough to allow you to create a dynamic system with no hard limits or crazy DIM usage.

Insert a few lookup routines and you have a close enough OOP system to create a fully dynamic no limits GUI system

[blinkok]

I was thinking of using separate apps for each window and using comms to pass the data. That way no worrying about windows as such and the panels could be dragged onto another screen

[Qube]

I was thinking of using separate apps for each window and using comms to pass the data. That way no worrying about windows as such and the panels could be dragged onto another screen

That sounds like an odd complex idea. What's your thinking behind it rather than in-app where each and every data is easily accessible?

[blinkok]

Mostly for the ability to drag the windows outside the primary window. If you look at any IDE now days they have that functionality (which is great for multiple screens). It also separates out most of the processing from the main app. So all you are doing is passing data from one app to another which would be super easy with json strings. The window would have a very low FPS so as not to drag on the CPU and less chance of conflict with data names within the main app

[Derron]

You could just use the widget system of your desktop. This is like an ingame gui.

Bye
Ron

[Qube]

Tonights work was adding interaction between windows and GUI gadgets. This is super easy to code in a fixed environment but not so much when it comes to a more dynamic GUI. The below video is boring but at the same time shows a working interaction that can be applied to any amount of windows.

[blinkok]

It looks very very smooth. very nice work

[Qube]

It's that exciting time again

Moved on to GUI code creation \o/ - This video shows creating a basic window, editing the gadgets and the outputted code with event handlers. Not all events will be needed so I'll just delete the ones I don't want.

Creating a GUI designer was a lot more work than I first thought. I've never done one before but it's going to be a great time saver when it comes to whipping up GUI bits for the upcoming tools adventure.

Here's the video ( ooops, spelling mistakes included )

[iWasAdam]

text:align - you deserve a medal none of that Taxt:gravity rubbish!

[Derron]

In my bitmapfont-class I have a "DrawBlock" function too - and you can align text with simple "0-1.0" values with "0.5" meaning "center". That way you could even do something like "bouncing texts" within a given boundary.
"left, center, right" are then just constant values.
"ALIGN_TOP_LEFT" is then a vector (0, 0)
"ALIGN_CENTER_LEFT" is then a vector (0, 0.5)
...

This is needed as you most probably WILL land in the situation in which you need to align multi-line-labels to some widgets - and this is not always "top left".

Sometimes it would even be needed to access "font baseline" (so not the bottom of "Qg" in "Quaagg" but the bottom of the letters "uaa"). But this is advanced stuff which could be added when really needed.



@ gui designer
Yes it is heavy stuff. Writing GUI/editor code is what I find most time consuming too. Which is why we have no DB-Editor for TVTower yet, it is just too complex what you need to pack into the editor - all the interaction code (events), editor effects (add an entry needs to update lists and other elements). I kind of dislike it ;-)



bye
Ron

[Qube]

text:align - you deserve a medal none of that Taxt:gravity rubbish!

You made it that far into the video, congrats

Sometimes it would even be needed to access "font baseline" (so not the bottom of "Qg" in "Quaagg" but the bottom of the letters "uaa"). But this is advanced stuff which could be added when really needed.

The text function I wrote for this handles font kerning too ( as can be seen at the end of the video when it shows the generated source code ). I could of cheated and used the built in text commands but they don't allow for bitmap fonts which are kinda key for games.

@ gui designer
Yes it is heavy stuff. Writing GUI/editor code is what I find most time consuming too.

It turned out to be a lot more work than I first thought and a lot harder to write a flexible GUI but as I'll be writing many game based tools it'll be a big time saver in the end. Oddly enough the source code generation side turned out to be a piece of cake and I thought that would be the hard part.

Lots to do yet but at least it's finally taking shape. Just have to power through till all the gadgets are coded up and then off I go

[Qube]

Small update... Couple more days and I should have the GUI and GUI designer finished \o/ \o/ \o/ \o/ \o/ \o/

It's been a long hard slog and some parts of the "behind the scenes" code isn't as elegant as I'd like but from the user end it all works pretty smoothly. As this is my first full on GUI plugin it miraculously worked better than I thought it would as going into this I wasn't too sure where the pitfalls would be.

The GUI designer ended up being a whole heap more work than anticipated but worth doing as it'll save loads of time when it comes to doing the GUI for the upcoming game based tools.

As always, once you've done something for the first time you always have a better approach for the next time. I've coded simple GUI's before but they've always been very ridged and fixed with a bunch of user based code to handle things. This time around I wanted a much more flexible GUI ( and GUI designer ) and sheesh, they are a lot of work and way more than first thought.

I'll shove up another video soon showing the final result of the GUI + designer + the source code generation + making apps with it. I know GUI's are boring stuff but just wait till you see my map maker / level editor in a couple of months time

[Derron]

Welcome in the GUI coder club ;-)

And glad you experience the GUI-lib-user moments of boring repetitive grunt work when setting up a designer or editor. It is not my cup of tea either.
Nonetheless it is a good test for your lib and you surely spotted bugs here and there while developing the editor.


Bye
Ron

[Qube]

And glad you experience the GUI-lib-user moments of boring repetitive grunt work when setting up a designer or editor. It is not my cup of tea either.

That's the perfect phrase "boring repetitive grunt work". I tried to streamline parts but each gadget can have it's own unique bits and pieces so I just decided in the GUI designer to handle each gadget separate ( just in case ).

Nonetheless it is a good test for your lib and you surely spotted bugs here and there while developing the editor.

Yup, quite a few issues popped up during the coding of the GUI designer as that's the main app to interact with the GUI lib. Kind of worked out good to do the GUI designer as that ended up showing up logic errors with the GUI library.

While mind numbing repetitive stuff always being deep in code I'm determined to get this side finished so I can move on to more exciting things