Code: Gui module or include file

Hi folks,

one thing we will need, no matter which game we will decide on, is a GUI module or include file which provide the following functionality:

1) Setup a grafical interface (via OpenGL/TBGL), based on images and dynamically build elements
2) Save and load functionality from/into XML files
3) an editor to create the gui on screen
4) React on mouse, keyboard and controller input
5) Work independantly from the rest of a game

GUI elements should be at least ...

- Window
- Button
- Checkbox
- Radiobutton
- Label
- Textbox (mayber scrollable)
- Frame

It would be nice if this gui would be skinable but if it would totally dynamic then I would say it would be great too.

If someone would like to work on this or allready have something like this in the pipeline, then please let us know.

Michael

Hi Mike,

I know you might not like my idea :), but what about using skinned UI window to do the job for load / save / options screens? I attach very basic example. This way we will get all the comfort UI provides, and still can influence the look of dialogs a bit.

In the example just press ESC to access menu.


Petr

Petr,

adding the following code will be also possible to move dialog:

In global space:
[code=thinbasic] DECLARE FUNCTION ReleaseCapture LIB "USER32.DLL" ALIAS "ReleaseCapture" () AS LONG
[/code]

In dialog calback
[code=thinbasic]
CASE %WM_LBUTTONDOWN
CALL ReleaseCapture
dialog send cbhndl, %WM_NCLBUTTONDOWN, %HTCAPTION, %NULL

case %WM_MOVE
TBGL_ClearFrame
TBGL_SceneRender(%sScene)
TBGL_DrawFrame

[/code]

Eros

Hi Eros,

when the dialog would be moving, it would call render function.
But in most games the dialog is just centered in window and you cannot move it.


Petr

Quote:

---

Originally Posted by Psch

when the dialog would be moving, it would call render function.

---

oh, thanks.
Amended above code works fine.

Your idea seems an elegant and easy to use solution that can bring all the functionalities of UI module to manage game options.

I ment a solution for using inside a game screen. But thanks anyway, I'll check your code later.

Mike,

I know you meant rendered GUI, but I choose now to work on particles.
Once I have them done, I can check out this, but not sooner, to not split "powers" too much.


Petr

Petr, I didn't expect you to work on all of these things. :) You should leave something to the others too, you know ;)

Ok, I had a look with your sample. I'm my oppinion it works only if you want to have a dialog with regular windows controls. And then you still have regular looking controls, just the background is skinned.

Yes Mike,

that is true ... when I think of it this fact could make a strange contrast for the game, we will see.


Petr

From scanning through the contest rules, it also seems that the point of the contest is to show what a language can do and also have code to look at, so perhaps having an include file would fit better and no need to iron out a module in little time. I do think a GUI module will be nice for thinBasic in the future however :)

No, we don't have to show the code if we don't want to. It's not a requirement.

Hi,

I think that for now, for the contest, an include file it's the right way. although the module could be great for the future. ;D

Petr if you need some help for this and for particle engine i can try to help you.

Ciao,
Simone

I had a play with Petr's menu.

Its late and my computer is in the bedroom and the wife has just gone to bed so I better stop.

Its very rough but it gives ideas.

Where do I download the 1.7 version? I just get the list of what is in it at the webpage, but no link to download, thanks for any help.

I tried running both scripts for the gui, no errors appeared, but nothing ever showed up as a running application either. I figured it has to do with not having 1.7. Thanks again.

Ken,

1.7.0.0 is downloadable only on request. We are still working on it.
Anyhow, I send you a PM.

Ciao
Eros

I forgot to mention

Press ESC for menu
move mouse over each box to see what happens
click on top of exit to close menu.

Right mouse to quit.

@Petr. As you can see I use TBGL_EntityCreateBox i know I can use display lists but it was for speed of writing but I notice that textures are repeated rather than wrapped. Can I have a new option on the TBGL_EntitySetTexture or maybe a new keyword TBGL_EntitySetTextureStyle.


thanks

Hi Abraxas,

thank you very much for your GUI test!

By default the texture coordinates for box are generated based on dimensions. If you want to stretch "options" texture on button with format 2:1, just create cube as 1, 1, 1 and then use TBGL_EntitySetScale( scene, entity, 2, 1, 1) for example.

Maybe we could create a base model for button with round corners for example, with correct general purpose UV mapping, and then force texture with text for it ( possible right now ).

I am adding your "texture style" request to my TODO list too.

For now I think the modeled button is not that bad way, as it would mean good skinability too - all button models would be said to have center at 0,0,0, but we can detect model bounding box dimensions right now which is good for this kind of thing. I think :)


Petr

Phew, I am happy all works fine with 1.7. It is nice to see the nice gui examples working. It is fun to see what looks like 2D turn into 3D with the mouse over it and a good way to show mouseover effect for feedback to the user.

The Windows bitmapped GUI worked really well too. I would say 2 thumbs up for both approaches as it seems the GUI is something that you guys got under "control", sorry for the pun :)

As I think that an openGL gui function set would give us more freedom about the look of the game I started to work on one. Here is the start so far so you can imagine where this is heading too. I won't be upset if this will not be used as I know I will use it in one of my next game projects developed with thinBasic. This is text only right now, but will include the ability to use images.

Hi Mike,

this looks very nice, thanks for your work.
Worked very well for me!

Few thoughts:
- it seems the corrdinate system for GUI is sticked to lower-left corner. You can pass parameters to TBGL_RenderMatrix2D to make it the same as in Windows - 0,0 in top-left corner.

- maybe it would be nice to have "Align" for whole dialog, so with changing resolution the dialog would be still present in bottom right corner, just smaller of course ( is this understandable :) ? ). Like anchor.


Petr

No Petr, the defination of the gui elements are top, left, width, height. So for creating a gui it uses a "normal" corrdinate system with 0,0 at teh top-left corner. I just transfer this inside the code. but of couse, there are many roads to rome. :) thnaks for your hint.

Plus, this is far form being finished. I just wanted to show you how it is basically working.

Quote:

---

Originally Posted by Psch

- maybe it would be nice to have "Align" for whole dialog, so with changing resolution the dialog would be still present in bottom right corner, just smaller of course ( is this understandable :) ? ). Like anchor.

---

I envision the following. You can create the gui, and of course it needs to be saved, using XML for it. It stores also on which resolution this gui was saved. When you load the gui, it will automatically rearange/resize(optional) all the gui elements.

Yes,

I just did not wanted to have fixed resolution game.

So the idea was - to have dialogs designed via fixed dimension way ( like in Windows in common, you change resolution and everything gets smaller ), but when I need main menu to be centered, I want it to be centered at any resolution.


Petr

Yes, that is the design goal. Dimension independant.

If you want to try my gui version, please go here and download the temporary thinCore.dll, which includes new commands for memory allocation.

http://community.thinbasic.com/index...15262#msg15262

thanks Mike

I like it, seems very complicated.

Quote:

---

Originally Posted by Abraxas

thanks Mike

I like it, seems very complicated.

---

You mean the two user commands it has so far or the whole gui coding?

Sorry, i will now give you a proper answer.

I Like the look and easy of creating the windows and buttons/frames on it, I ment the routines to build it take a bit of reading to understand. The more I look at it the easier it seems though.

Is there anyway Petr could build that into TBGL or is that overkill and not worth it?

to sum up very nice

When they are finished and Petr would like it, I would be happy if he builds them into it. That would mean more speed anyway.

Hi,

if Mike would allow it, I would be very happy.
It is very easy to use, looks good. We will see which possible problems we will encounter with using it in our project ( if any problems ) and then would add it to TBGL arsenal, giving the credit to Mike of course. Recoding it to PB is detail once we have syntax for commands done and approved.


Petr

I got it to work finally after getting the thincore.dll from the linked post.

That looks really nice and worth a future into tbgl :)

Right now I'm working on a bitmap font implementation. For something like a textbox I need to know how wide a word is and if I have to wrap a sentense into the next line so I have to calculation this before display. I think I should be done or at least close to it by the end of the month.

Hi folks,

I decided to stop working on this for the game as I read that Jason/Kent have different ideas about using perspective and their method could be used for a 3D gui implementation. At least that was what I understood.

No need to waste time on something that is not compatible or not needed.

Michael

The field-of-view thing was specific to the game... (45 degrees is not a race-game field of view. Gives tunnel-vision.)

I only mentioned it in the sky-box, due to the unity of player-view, and the skybox... But... now you have me thinking.

This (your code), could be used to setup 3D objects as a full 3D interface. (Without having to code all the boxes and lines and mappings.)

Even as-is... could be used to create the "BMP" imposed onto a 3D in-game GUI. AKA, the %sINFO, and use elements from the game as part of the display... the %sCRAFT and %sACC and %sTRACK...

Those rendered BMP's would be imposed on elements you create as a "VIEW-SCENE"... passing the %sTRACK rendered BMP to you... and this displays it on one of the flat surfaces. (Not sure if I am explaining that right.)

Though... the comments about a full 3D display sounds cool too. Boxes for buttons, 3D shadow-box hologram wire renderings of the 3D scenes %sCRAFT, %sTRACK... etc... Ok.. I'll stop... Looking at code again.