From KruelWiki

Image:Eon sdlgui v2 structure.png

Astro's Notes

• setAspectScale() and setDimensions() are 2 functions Im not sure we need/want whatever.. I figure we can off this normalisation stuff which looks SHIT with textures anyway.. particularly if they arent mipmapped. We should just do pixel for pixel stuff with all the widget shit etc so buttons and stuff get smaller and less obtrusive on higher resolutions which they are supposed to anyway because thats WHY you have higher resolutions so you can see more in-game real-estate rather than fugly buttons.

• Textures will start out as nice high-resolution bitmaps, and have the aspect ratio of the button/widget shape they are part of. We will have to decide upon a max-resolution such as (1600x1200)x2? for backgrounds etc. Depending upon the resolution the user runs their machine at and the scale that they want the interface to be, eg 1.0 at 800x600 or 1.28 at 1024x768 to keep the interface physically the same size on the screen at both resolutions. Textures will be scaled down more for lower resolutions producing nicely scaled (we will need to fiddle with textures that scale well) per pixel textures for that resolution.

• TextureGenerator is an aspect of TextureManager, used to generate textures from unit stats and fonts etc.
• TextureGenerator needs to be able to take a string and generate a nice alpha texture from it in realtime. Shouldnt take much time to generate a texture from a string and TTF in realtime as the string is being typed. Would be nice to be able to configure fonts etc.
• aspectRatio is inherent in the screen resolution. eg 640x480 is 4:3. Background textures will be clipped and scaled automatically using their own aspect ratio to fit the screen. With a nice algorithm that scales per pixel rather than using OpenGL to render large scaled textures(slow and ugly).
• TextureGenerator should be able to produce nice textures with perlin noise and glowing lines and text etc based upon a simple description of a button. Perhaps we should build a lib for this that can be used in future games etc, depending upon how much we want to reduce disk space taken up by textures.

• Panels will accept various types of widgets, and widgets will be able to accept various textures.
• Input is generated by SDL, goes into a queue, then handled by an InputManager. InputManager asks the widgets if they want this input. If the widget accepts the input it then tells the InputManager to add a particular event to a processedQueue. The processedQueue is then passed onto a list of objects that accept input and do stuff that changes values in the game.

eg: click -> InputManager -> gameScreen (accepts) -> generates processedEvent based upon what was actually clicked on eg: move a unit -> InputManager -> tells the Communications object to tell the server to move this unit to here. - perhaps this is too complex/messy, and it will just go as far as a widget that accepts the input and does something.

• Panels have a list of widgets contained within them, input is passed to the currently active panel which passes the input onto the widgets which then use that input contextually. Buttons are simple, the in-game screen would need to be rather complex to accept andd process input itself. Rather than widgets or listeners, processing can be done by a big fat object that processes the Queue of widget-generated events or even a list of seperate processors.
• still too complex.

• SDL inputEvent -> InputManager (basic filtering) -> activePanel -> widgetList -> widget (change values).
• We can just make the widgets do the work. Its simple, widgets can be complex, but they are abstracted versions of a very simple widget anyway which will make them easy to use. Its configurable enough. Just abstract widgets more and more if there are common functions to say a few types of button. What actually holds the values that the widgets manipulate? the widgets themselves I guess. When they are rendered they show their guts off to the world.

• All buttons etc should be able to access TextureManager without having it explicitly defined.
• TextureManager will have the resources organised and generate textures for setText() style lines.
• there are a zillion options that could be added to a texture generator

Button *quitButton = new Button();
int quitTexID = TextureManager.generateButton(x, y, borderColour, bgColour1, bgColour2, bgStyle, textColour, "Quit");
quitButton->setTexture(quitTexID);

• In 2D OpenGL (ortho mode), we can organise the viewport to have the same dimensions as the screen pixel dimensions, say 1024x768. This would allow us to pick nicely a clean value for the x/y position so that our per-pixel scaled textures etc will not be placed off by half pixels. This will reduce visual artifacts and allow buttons etc to be moved around by pixel values rather than 0.8 etc. Floating point values will still be used to setup initial positions, such as 0.5 halfway across the screen, but once its translated to a pixel dimension then the work is done and buttons/widgets can be placed accurately by pixel dimensions.

Panel *gameScreen = new Panel(TOP_LEVEL);

Widget *gameWindow = new GameWindow(location, size);
Widget *miniMap = new MiniMap(location, size);
Widget *chatBar = new ChatBar(location, size, bufferlines...);
Widget *rightClickMenu = new Menu(POPUP_ON_CLICK);

Widget *AttackOpt = new Button(location, size, text...);
Widget *RepairOpt = new Button(location, size, text...);
Widget *teamOpt = new Button(location, size, text...);

rightClickMenu->add(AttackOpt);
rightClickMenu->add(RepairOpt);
rightClickMenu->add(teamOpt);

gameScreen->add(gameWindow);
gameScreen->add(miniMap);
gameScreen->add(chatBar);
gameScreen->add(rightClickMenu);

• What happens when a button on the menu is clicked? How does the action in that button affect whats happening elsewhere in the code? Do we generate an event to push onto a queue which is then read by something else that does virtually all the work? Or a bunch of somethings that do all the work? Or should we just give that button access to the related variables that needs to be modified?
• I figure it would be simple to use the events path, as buttons will be linked to panels etc and they will have a direct effect in the gui. But buttons that actually change stuff in the game, will go right back to passing messages to the server anyway. So we have a queue processor for messages that need to go back to the server. All other work is relatively simple and will only affect the pane or the buttons themselves that the button/widget is aligned with, so that is nice and clean enough to implement.

Sko's Ramblings

I'd like to be able to bind the inital buttons like:

Panel* mainMenu = new Panel(TOP_LEVEL);
Panel* joinScreen = new Panel(TOP_LEVEL);
Panel* optionScreen = new Panel(TOP_LEVEL);

mainMenu->setBackground(resource["background"], CLIP_IMAGE); //Center V/H & clip image

Button* joinGame = new Button("Join");
joinGame->linkPanel(joinScreen);
joinGame->setSize(200,50);   // W x H ... scaled by master UI scale factor
joinGame->setYRelative(0.7); // same as setY(mainMenu.getHeight() * .7);
joinGame->setXRelative(0.5); // centre

Button* options = new Button("Options");
options->linkPanel(optionScreen);
options->setYRelative(0.8); 
options->setXRelative(0.5); //centre

Button* quit = new Button("Quit");
quit->setAction(QUIT_APPLICATION);

// add(widget);
mainMenu->add(joinGame);
mainMenu->add(options);
mainMenu->add(quit);