Advertisement Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views


Sign in to follow this  


Okay, so I've been tinkering around with OO representations of mathematical expressions. And I think I'm going to make some simplifications for my prototype parser/renderer, but I can deal with that (details to follow).

Given the expression

x^2 + y^2 + z^2 = 1

You should immediately notice that this describes the unit sphere (dur), which isn't a function. One of the many methods I'm considering using to cripple this is to limit the input to functions, such that for any pair (x,y) there exists only one output z.

Thus, the above expression becomes

f1(x,y) = ( 1 - x^2 - y^2 ) ^ ( 1/2 )
f2(x,y) = - ( 1 - x^2 - y^2 ) ^ ( 1/2 )

The most obvious disadvantage to this is that our nice little expression for a sphere becomes this distorted crazah set of equations. So yeah. Deal with it for now I guess.

That said, the parser consists of three main "ideas"/components.

  • Values - a construct which represents a value in an expression, whether its a variable or a constant, or whatever.

  • Expressions - a pair of values and/or expressions combined with an operation.

  • Statement - a list of expressions and/or statements which operate on one another.

Taking f1 from above, we can parse it like -

f1( x, y ) = // defines a statement f1.

That's nice and clean, but the rest of it gets ugly. Very ugly. Even by my standards -

( ( ( (1) - (x^2) ) - (y^2) ) ) ^ (1/2)

parses to

expression( expression( expression( value(1) minus expression( value(x) power value(2) ) minus expression( value(y) power value(2) ) ) power expression( value(1) divided by value(2) )

Which, although it does seem kind of easy to parse since I've passed it nicely organized input with all the order-of-operations laid out for it. It shouldn't be _that_ hard to parse it without - just search left-to-right looking for operators.

Which is exactly the part I'm not looking forward to - searching around a string looking for yummy details to parse. We'll see what happens...

[ ^_^ ]/[ O_o ]
Sign in to follow this  


Recommended Comments

Assuming that GUI bugger runs on pure SDL, when do we get to steal - I mean, learn from, source code?

Share this comment

Link to comment
It (hypothetically) can be rendered with any API for which an adapter can be written. An "adapter" in this context is defined as a class which implements some really low-level drawing functions (*digs up docs*):

  • Some methods to get the current screen size:
    int screenW();
    int screenH();
    pawn::math::Rect<int> screenDim();

  • Some stuff with clipping regions, which aren't really used for much:
    void setClipRegion( int x, int y, int w, int h );
    void setClipRegion( pawn::math::Rect<int> dim );
    void clearClipRegion();

  • The bulk of the coloring operations are done with simple rect blitting buggery:
    void fillRect( ColorType color, int x, int y, int w, int h );
    void fillRect( ColorType color, pawn::math::Rect<int> dim );

  • And a generic function for making your user-defined color type out of RGBA:
    ColorType makeColor( int r, int g, int b, int a = SDL_ALPHA_OPAQUE );

  • Finally, a method to draw text (unfinalized)
    void drawText( std::string text, ColorType color, int x, int y );

In addition to all that, your graphics adapter has to define the following typedefs -

ColorType - the type that you use to represent colors. My SDL adapter uses an unsigned int because that works well with SDL, but I might make it a real color struct when I write the OGL adapter.

SizeType - the type that represents locations. Since the smallest renderable amount in SDL is 1.0 (ie, 1 pixel) I just use ints for this.

I'll write up some better docs on it tommorrow and throw most of the stuff into a *.zip with some sample code. I'm still debating changing some of the requirements for the graphics adapter, namely the way the fonts work. Some indecision on how much control to give regarding fonts, but the GUI should at least be able to decide on the size of the font to be rendered.

Other notes; pawn::math::rect is essentially the same thing as SDL_Rect; I wrote my own struct because I didn't like being completely dependant on SDL stuff.

Oh, and I forgot. You'll also need an event adapter to gather events - I don't have the API on that though. I'll include my dummy SDL adapters in with the code tommorrow just to show how everything works.

As a final tidbit, here's a dump of the code currently in my sandbox, showing how the pieces fit together in code and such:

#include "SDLAdapters.h"
#include "GUI.h"
#include "Button.h"
#include "Window.h"
#include "TextBox.h"
#include "BSOD.h"
#include "Label.h"

#include <iostream>
#include <string>

#pragma warning (disable: 4101) // unreferenced local variable

bool running = true;

struct Listener : public pawn::gui::WindowListener {
virtual void onCreate( pawn::gui::WindowEvent ) { }
virtual void onDestroy( pawn::gui::WindowEvent ) {
running = false; }
virtual void onMaximize( pawn::gui::WindowEvent ) { }
virtual void onMinimize( pawn::gui::WindowEvent ) { }
virtual void onMove( pawn::gui::WindowEvent ) { }
virtual void onResize( pawn::gui::WindowEvent ) { }

int main( int argc, char* argv[] ) {
pawn::sdl::SDLGfxAdapter driver;
pawn::sdl::SDLEventAdapter events;

Listener myListener;

pawn::gui::GUI< pawn::sdl::SDLGfxAdapter, pawn::sdl::SDLEventAdapter > gui( &driver, &events );
pawn::gui::Button< pawn::sdl::SDLGfxAdapter > button( &driver );
pawn::gui::Button< pawn::sdl::SDLGfxAdapter > buton2( &driver );
pawn::gui::Window< pawn::sdl::SDLGfxAdapter > window( &driver );
pawn::gui::Window< pawn::sdl::SDLGfxAdapter > subwin( &driver );
pawn::gui::TextBox< pawn::sdl::SDLGfxAdapter > text1( &driver );
pawn::gui::BSOD< pawn::sdl::SDLGfxAdapter > bsod( &driver );
pawn::gui::Label< pawn::sdl::SDLGfxAdapter > label( &driver );

pawn::gui::DefaultStyle< pawn::sdl::SDLGfxAdapter, 0 > hStyle;
hStyle.setBorderSize( 1 );
hStyle.setTitleBarSize( 20 );
hStyle.setHighlightColor( driver.makeColor( 255, 255, 255 ) );
hStyle.setForegroundColor( driver.makeColor( 220, 220, 220 ) );
hStyle.setBackgroundColor( driver.makeColor( 200, 200, 200 ) );
hStyle.setShadowColor( driver.makeColor( 0, 0, 0 ) );
hStyle.setBorderColor( driver.makeColor( 255, 255, 255 ) );
hStyle.setTitleBarColor( driver.makeColor( 0, 0, 255 ) );
hStyle.setTitleTextColor( driver.makeColor( 255, 255, 255 ) );
hStyle.setTextColor( driver.makeColor( 0, 0, 0 ) );

button.setPos( 10, 40 );
button.setSize( 50, 20 );
button.setCaption( " ^_^ " );
// note the nasty spacing there - I need to add
// a method to center text and stuff.

buton2.setPos( 70, 40 );
buton2.setSize( 50, 20 );
buton2.setCaption( " O_o " );

window.setPos( 100, 100 );
window.setSize( 130, 90 );
window.setTitle( "Washu Watcher" );


Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!