• entries
26
30
• views
34043

Software development and life.

## Entries in this blog

I missed Gaiiden's scroll for a day. Too bad! I've been sort of busy *ahem*

I've been making some more tiles to see what this thing can do. I also added the ability to add tilesets to levels and save and load such levels.
Moved the character's controlling logic to Lua and it seems to work just fine.

From here I should start thinking about implementing "collectables" and enemy AI. The idea is after having the basics for a platformer start thinking about level design, and maybe some story telling devices to spice things up some more.

Getting a modern video card could also help a little. But to do that I need to buy a new PC cause this one doesn't even have PCI express.

This video shows loading 2 levels one of them portraying the new "tileset". And the character running and jumping some.

[media]
[/media]

## Bringing the tools together

It all started with the UI library. Then it followed the skeletal animation loader. After that the model visualizer. The scene partitioning and the level editor.

Then there was a little lapse to implement lua scripting.

As the "game" is going to be "tile" based I'm needing to also make a tileset editor. At this point, having a model visualizer, a level editor and a tileset editor being three different apps makes little sense in relation to "handyness" so I decided put them all together in one app.

In the UI library there is a new control called "panel" which is simply a window without decorations. In order to have three different sections in the "Game Editor" I need three of those that should get activated, say by pressing the Fs keys. F1: Level Editor, F2: Tileset Editor, F3: Model Visualizer.

So the application module in the Lua script would look something like this:

[source lang="cpp"]

----------------------------------------------------------------------
--
-- Application
--
----------------------------------------------------------------------
dofile "lua_section_level.lua"
dofile "lua_section_tileset_editor.lua"
dofile "lua_section_model_editor.lua"

------------------------------------------------------------------
-- Configure
------------------------------------------------------------------
function application_configure()

end
------------------------------------------------------------------
-- Init
------------------------------------------------------------------
function application_init()
owl.set_clear_color(0.5,0.5,0.5,1.0)

gui.screen_viewport:set(0, 0, screen_width, screen_height, -1.0, 1.0 )
gui.root:resize (screen_width, screen_height)
gui.default_font = gui.fonts:get("zekton", 11)

level:init()
tileset_editor:init()
model_editor:init()
end
------------------------------------------------------------------
-- Update
------------------------------------------------------------------
function application_update()
gui:update(app.clock:get_ticks());
end
------------------------------------------------------------------
-- Draw
------------------------------------------------------------------
function application_draw()
owl.set_foreground_color(1.0,1.0,1.0,1.0)
owl.clear_color_buffer();
owl.clear_depth_buffer();
gui:draw()
end
------------------------------------------------------------------
-- Key Press
------------------------------------------------------------------
function application_keypress()
key = input.keyboard.key

if (key==27) then -- ESC
app:quit()
elseif (key==282) then -- F1
level:visible(true)
tileset_editor:visible(false)
model_editor:visible(false)
elseif (key==283) then -- F2
level:visible(false)
model_editor:visible(false)
tileset_editor:visible(true)
elseif (key==284) then -- F3
level:visible(false)
tileset_editor:visible(false)
model_editor:visible(true)
else
print(key)
end
end
------------------------------------------------------------------
-- Initialization
------------------------------------------------------------------
app:on_configure("application_configure")
app:on_init("application_init")
app:on_update("application_update")
app:on_draw("application_draw")
app:on_key_press("application_keypress")
[/source]

And the "sections" initialization something like

[source lang="cpp"]

------------------------------------------------------------------
-- Init
------------------------------------------------------------------
function level:init()
level.panel = owl.create_panel(script, gui.root)
level.panel:resize(gui.root:get_width(),gui.root:get_height())
level.panel:on_update("level::update")
level.panel:on_draw("level::draw")
level.panel:on_key_press("level::key_press")
level.panel:on_key_release("level::key_release")
level.panel:focus()
level.panel:background_color(0,0,0,255)
level.world = owl.create_world()

[/source]

So far it's coming along quite nicely. I'm getting stuck at making the tile picker control as I'm afraid I'm going to have to write a special c++ class to handle that and I'm not sure where in the library to put it, as everything in it is directly game-related and not for tools. I might create a sub-namespace for game::tools but I haven't decided it yet.

On the dark side of the story, the SWIG c++ interface output file is becoming a HUGE monster (2.5 MB of source code!) and while I now can code stuff without recompiling, compiling times have increased pretty bad. I might split the interface file in little pieces but that would add complexity at the time of compiling too. I need to think of this deeply and try to make a good decision.

The video shows nothing new except for the three things working together in the same app.

[media]
[/media]

On another note, this blog has become my personal rubber duck to help me look at the project from another perspective. It has become helpful too in the sense that having to post some progress on a weekly basis makes it feel like a sort of dead line and pushes me forward at achieving results. Please keep reading so I can keep advancing! And Thanks!

## Let me introduce you: "Teh" LEVEL Editor (lol I can't think anymore

I think my brains are just gonna asplode!

I've been coding this thing for 24 hours straight, with the help of 48 cigarettes, lots of (diet) coke, cookies and sandwiches.

Most of the work was interfacing all my framework with Lua. The interface file is more than 50.000 lines of code (auto generated of course) but I got it. The entire UI, the rendering routines, the world data and the input management is now all accessible from scripts which is a blessing because I don't have to re-compile anymore!

I've coded a big deal of the level editor. I know it from head to toes but I still gotta learn to use it.

As always, I recorded a little video. As always, it is slow as hell but to counter that I resampled it to 76 FPS

[media]
[/media]

## Aww, I love my Lua!

app = owl.get_app()function btn_new_game_click() print (app.clock:get_fps())end-- Create Button New Gamebtn = owl.create_button(app.gui.root)btn:text("New Game")btn:move(200,200)btn:resize(600, 40)btn:on_click(app.script, "btn_new_game_click")btn:center_horizontally(app.gui.root)label = owl.create_label(app.gui.root)label:text("FPS:")label:foreground_color(255,255,255,255)label:move(100,100)label:resize(100,20)

## If it don't take two..

I've been fighting with the character's movement for the last two days. I got stuck at trying to apply gravity in a time based manner like for a day, after which I decided to cap the character's movement and collision detection to 36fps which isn't THAT bad after all, at least for now.

Because of the update limit I had to re-tweak all the velocities that were time based to frame based and that brought up a few problems with collision, that were still pending so I solved most of them.

I modularized the character's movement management in such a way that I can add as many of them as I want and let them be controlled by the user or by a still non-existent AI.

This morning I woke up just to discover that the GForce 6200 would refuse to work for more than two minutes straight so I was forced to go back to my extremely legacy Geforce2 440 MX and work with that. In a way, it's gonna help me optimize as much as I can to keep up the FPS I was getting with the 6200 without much effort.

A video, if only to entertain the eye:
[media]
[/media]

(Note the FPS lol)

## Octreezing the world

Got it. I made the octree class and I'm able to push the meshes geometry into it. The algorithm for character collision against the world is something like this:

• Get character's AABB.
• Set's character's AABB position to current character's position.
• Add velocity vector to character's AABB position.
• Pass the character's AABB and an empty std::set to the octree.
• Collide the character's AABB with the octree nodes, when in a leaf, collide the meshes's AABB there with the character's AABB again and get those that overlap.
• Iterate the std::set we got from the octree and collide the character's ellipsoid with each mesh geometry.
This added quite a lot of complexity to per-frame processing but framerate increased notoriously because the data to be processed (mesh geometry) got reduced A LOT.

Now I need to do the same for drawing only what's visible which will increase framerate quite a bit as well.

The following video shows a level composed of 54 meshes with 54 faces each. At all time, I'm colliding only with +-1.6 meshes per frame. At the top right you can see the number of tiles that are subject to collision. The wireframe represents the octree's nodes.

[media]
[/media]

## Finding data structures that make sense

Last time I was showing how I managed to load a big mesh for the level and to wrap the character model inside an ellipsoid and make both collide using Kasper Fauerby's Swept Sphere collision algorithms. Since then I've been working in the data structures necessary to organize the level components a little better.

I needed to be able to make little parts of the level with a 3D modeling program and then being able to select from a program of my own which one of them to include in a game level and where. For this I came up with the following classes:

• Core Model: Loads all the elements of a model into an OpenGL VBO's.
• Model: It's an instance that points to a specific Core Model. It processes the vertices and updates the VBO during animation.
• Collision Mesh: Is used for meshes that have no animation. It holds the triangles in system memory, an AABB encompassing them and the location in World Space.
• Tile: It's the structure that represents static objects in the level to collide with. It contains a Model and a Collision Mesh.
• Contents: It holds lists of Core Models, Models, Tiles and the Tile references composing the Map.

There is a XML file describing how a Level is composed. It defines which Textures and Models to use and which of those each Tile should use. Also the size of the map and where the Tiles must be located.

There is only one Model per Tile type (hence just one VBO). All these unique tiles are hold in an array and when the Map is drawn they are referenced by their location in the array.

The vertices in the Collision Mesh (which are in model space) are transformed into world-ellipsoid space at the time of collision according to the tile's position. It'd be better to convert the ellipsoid position to Mesh space but it was easier to do it this way right now.

The only reason I created the Tile class was to keep the classes used for collision decoupled from the ones used for drawing.

The next step is to implement an Octree and push all the tiles in it. Then collide the character's AABB with the Octree each frame and test for collision only with those Tiles that are near.

[media]
[/media]

## Samsara, a word I've been hearing a lot lately..

According to Wikipedia:

[quote]a [font="sans-serif"][size="2"]term which translates as "continuous movement" or "continuous flowing", which, in Buddhism, refers to the concept of a cycle of birth (j?ti), and consequent decay and death (jar?mara?a), in which all beings in the universe participate, and which can only be escaped through enlightenment.[/font][/quote]

This excerpt of Buddah's view of Samsara got me thinking (contrasting I'd say) for a while:

[quote]What do you think, monks: Which is greater, the tears you have shed while transmigrating and wandering this long, long time, crying and weeping from being joined with what is displeasing, being separated from what is pleasing or the water in the four great oceans?

This is the greater: the tears you have shed while transmigrating and wandering this long, long time, crying and weeping from being joined with what is displeasing, being separated from what is pleasing, not the water in the four great oceans.

Long have you repeatedly experienced the death of a father... the death of a brother... the death of a sister... the death of a son... the death of a daughter... loss with regard to relatives... loss with regard to wealth... loss with regard to disease. The tears you have shed over loss with regard to disease while transmigrating and wandering this long, long time, crying and weeping from being joined with what is displeasing, being separated from what is pleasing are greater than the water in the four great oceans.

Why is that? From an inconstruable beginning, a beginning point is not evident, so, beings hindered by ignorance and fettered by craving are transmigrating and wandering on. Long have you thus experienced stress, experienced pain, experienced loss, swelling the cemeteries enough to become disenchanted with all fabricated things, enough to become dispassionate. Enough to be released.[/quote]

How many times I've been (and still I am) wandering around (hindered by ignorance and fettered by craving) looking up for things that could give my life a meaning or at least provide me with some perdurable happiness, finding them and then losing them in the hands of tragedy or the unstoppable flow of time just to start over looking up for them again or remaining in total despair for having losing them.

I understand now (of course not completely, but certainly more than some time before), that becoming "disenchanted" and "dispassionate" doesn't mean becoming oblivious and uninterested but to start comprehending how everything is temporary and circumstantial and that I do not need to remain tied to these "fabricated things" in order to be in peace. That being released from the things of life doesn't mean being released from being alive or being able to contemplate what's good. That abandoning the perpetual motion of Samsara doesn't mean to stop moving towards one's own end with joy. Whatever that may be...

...

With some luck I'll be writing about the progress on this game I'm making before Sunday. I just need to stop thinking about these things and start coding that freaking AABB code to partition the level stuff.

[color="#333333"][font="Arial, Verdana, sans-serif"][size="2"]????? ???????? ??? ????[/font][/color]

## Collision is gameplay, that's what a guy said.

And it's true. I'm now playing with different configurations for the character to run, jump and respond to collisions.

Ideally, the collision would be against the current character's skeleton pose. In reality I'm still unable to figure out how to make that work.

So, for what is worth, this is how it is looking so far:

[media]
[/media]

I made a bigger scenario to test different angles to collide with. There is a little issue when colliding with slopes from the bottom as the ellipsoid will try to slide and that simply makes no sense. I need to detect when the ellipsoid is sliding against the ceiling and make it react as expected.

Cuack!

## Nicotine, Caffeine, Platformer and Collision Detection

Well yeah, I've come to the realization that I cannot code without nicotine. And I must code if I plan making some money out of my programming job. I'm also trying to save some cash thus I'm not going out neither. What's left? Well...

I managed to make two animations with Blender3D for my rag-doll, one for running and another one is intended for jumping but it ended up looking more like "freaking out while falling". I exported them to my format and got them ready to be loaded in a test application.

On the other hand I've been adapting the swept-ellipsoid collision detection to be used in my engine. It was mostly a copy paste from that example that has been online for years. It does the job.

What else.. Oh yes, I blew the dust off my joypad and connected it to try it out with SDL. It worked like a bliss too.

Then I made a sort of level with Blender (just one mesh) to stress test the collision detection. I attached the rag-doll to the ellipsoid, coded some basic input for a platform game and here the result.

[media]
[/media]

As always, the capture frame-rate I'm getting with CamStudio sucks. Mostly because this computer is old and I had quite a few programs running in the background.

Among the quatrillon pending issues the ones that follow are:

• Space-partitioning, which would involve gluing some code I wrote SEVERAL years ago.
• Detecting when the rag-doll isn't standing on the floor to avoid having it jumping near walls in mid-air.
• Time-based movement and physics.
• Making the player input management independent from the device the input is coming.
Let's see what happens. See you next time!

## Toying with animations

I'm currently researching how to implement Cal3D animated models *Properly*.
So far I managed to make 2 animations with Blender. Next step will be loading them in a test program and making them execute on a user action.

A screenshot of the Action Editor in Blender

Enda video of two animations inside my model editor:
[media]
[/media]

## Lua scripting with SWIG - Calling a Lua function from C++ and passing parameters to it

As I said in my last entry SWIG is a very easy and straightforward way of exposing your C++ functions, data structures and instances to Lua scripts. If you're not interested in learning the prestidigitation that occurs behind such an act SWIG is the library you're looking for.

Yet not everything in life is easy. There always seems to be a catch and this time the catch is that while SWIG is great for letting you access your stuff from Lua it doesn't seem to provide an easy way of calling your Lua stuff from C++. So at the end, you gotta get into the realm of lualib and find a solution for that.

For the moment I belong to the group of guys not really interested in learning to do by themselves what SWIG does without their help, so I tried to keep my incursion into lualib as simple as possible. As I mentioned in the last entry I resorted to a sort of functor from which I inherit each time I need to pass different values to the Lua function I need to call from C++. This is the base class that does the general stuff:

 class callback { public: void init(owl::script::script& s, const std::string& obj, const std::string& func) { L = s.L; lua_getglobal(L, obj.c_str()); // Get the table instance r_obj = luaL_ref(L, LUA_REGISTRYINDEX); lua_rawgeti(L, LUA_REGISTRYINDEX, r_obj); // Get the object instance lua_getfield(L, -1, func.c_str()); // Get the function r_func = luaL_ref(L, LUA_REGISTRYINDEX); lua_pop(L, 1); } void init(owl::script::script& s, const std::string& func) { L = s.L; lua_getglobal(L, func.c_str()); // Get the function r_func = luaL_ref(L, LUA_REGISTRYINDEX); lua_pop(L, 1); } virtual ~callback() { luaL_unref(L, LUA_REGISTRYINDEX, r_obj); luaL_unref(L, LUA_REGISTRYINDEX, r_func); } void call() { lua_rawgeti(L, LUA_REGISTRYINDEX, r_func); int s; if( (s=lua_pcall(L,0,0,0)) != 0) report_errors(); } protected: void report_errors() { std::cout << "-- " << lua_tostring(L, -1) << std::endl; lua_pop(L, 1); // remove error message } int r_obj; int r_func; lua_State *L; };

The improvement in relation to the last version is that now I'm keeping an index to the Lua function I want to call instead of the string that represents the function's name. I also wrote a wrapper for the Lua State (the running script) and now I give the callback a pointer to it so it knows where to store the index I'll need to call later. The wrapper for the lua script is actually really simple:

 class callback; class script { friend class callback; public: bool init(); bool init(script* s); bool load(const std::string& file_path); void close(); protected: void report_errors(lua_State *L); lua_State *L; }; bool script::init() { // Initialize lua L = lua_open(); luaL_openlibs(L); luaopen_owl(L); // load the wrappered module return true; } bool script::init(script* s) { L = s->L; } void script::close() { lua_close(L); } bool script::load(const std::string& file_path) { // Load script int s = luaL_loadfile(L, file_path.c_str()); // execute Lua program if ( s==0 ) { s=lua_pcall(L, 0, LUA_MULTRET, 0); if (s!=0) { report_errors(L); return false; } } else { report_errors(L); return false; } return true; } void script::report_errors(lua_State *L) { std::cout << "-- " << lua_tostring(L, -1) << std::endl; lua_pop(L, 1); // remove error message }

For the script to be able to tell C++ which lua_State to use for storing the reference to the Lua function I needed to have a way of getting the lua_State from C++. The only way I could come up with so far was to make the app instance global, writting a function for getting that instance and having a reference to the lua_State in it (it's actually wrapped in it's own class) so I can access it from the script later.

In short, this:
app* the_app = new app();app* get_app(){ return the_app;}

class app{ public: owl::script script;};

So for the sake of an example I want to be able to create an UI button from Lua and call a Lua function each time the button gets pressed.

I've inherited a class from the callback class that has a string as a member that is going to hold the value I want to pass back to the script when calling the Lua function. In this example the delegate I'm calling doesn't have parameters so I'm making up the value in the constructor. I could just as easily have gotten it from the delegate. I just don't wanna right now OK?

 class callback_button : public callback { public: void register_click(owl::render::gui::button_ptr obj) { obj->click += fd::delegate(&callback::call,this); } callback_button() {value = "hola";} std::string value; }; typedef callback_button button_callback_t; typedef boost::shared_ptr callback_button_ptr;

I also wrote a couple of helper functions to create instances of the button and the callback:

static callback_button_ptr create_callback_button(){ return callback_button_ptr(new callback_button());}static boost::shared_ptr create_control(owl::render::gui::object_ptr parent){ boost::shared_ptr ctrl = boost::shared_ptr(new T); if (parent) parent->add(ctrl); return ctrl;}

Then the infamous interface file SWIG needs in order to write C++ for your (my actually) lazy arse:

%module owl%{#include "gui.h"// and any other required headers%}%include %include "gui.h"%template(button_ptr) boost::shared_ptr;%template(create_button) create_control;%template(btn_callback_ptr) boost::shared_ptr;// and all the data types you wanna interface with Lua

Then you run from the command prompt:
> swig -c++ -[INTERFACE_FILE_NAME]

The resulting cpp file should be part of your project. Then you build your app.

The lua script is quite simple:
-- // Get the app instanceapp = owl.get_app()-- // Declare the function we want to call from C++function btn_new_game_click() print (btn_new_game.handler.value)end-- // Create Button New Gamebtn_new_game = {}btn_new_game.btn = owl.create_button(app.gui.root)-- // Create the callbackbtn_new_game.handler = owl.create_callback_button()btn_new_game.handler:init(app.script, "btn_new_game_click")btn_new_game.handler:register_click(btn_new_game.btn)

And that's it. Of course this might seem a little convoluted for some programmers, but it works.

Any questions or comments let me know.

Beam me up, Scotty! *WOOSHHHHHES*

## Lua scripting and quitting cigs

I always wanted to be able to add scripting capabilities to my programs but it was the kind of subject that always lead me to procrastination.

I've been without smoking for 3 weeks and 3 days and I'm doing quite fine. I'm already starting to feel a lot better (and smell better). I went totally cold turkey on this so the first days were a real nightmare. I still have some smoking flashbacks and dreams but compared to the first week I'm almost over it.

One of the challenges of not smoking anymore was to still being able to sit on the computer and think; so adding scripting to my engine became the excuse for such training.

As I started completely clueless I had to do some research, and after trying a few languages and a few libraries for each I decided that the best option for me would be Lua and that I'd connect it to my C++ programming using SWIG.

Why did I chose SWIG over other options (LuaBind, OOLua)? Well, mostly because it was the first that allowed me to do what I needed in almost no time and requiring me to code nothing but a few lines in a special interface file it needs to compile to generate the c++ source code that will bind my engine to the scripting. It also comes with interfaces for the standard library and a pletora of other stuff I'll probably never use.

The most important things I wanted from scripting were obviously the capability of exposing my classes to Lua and being able to callback Lua functions (in the script files) from my engine. The latter I'm still working on understanding how it works.

So far I've come to the following solution:

As I mentioned in my previous entries, one aspect of my engine is that it has it's own UI. The UI element events get fired through delegates that require function pointers being passed to them on initialization. This is exactly one of the things one cannot do with scripting. So I was forced to add a layer between the two. This layer is functors (that is classes which their instances are meant to work as functions).

So, when a UI button needs it's click event set I do the folowing from Lua:

btn = owl.create_button()btn.text:set("rename")btn:move(200,200);btn:resize(100, 40);app.gui.root:add(owl.button_to_object(btn));--// create a functor for this eventbutton_event = owl.button_click_handler("btn_rename_click")button_event:register_event(btn)--// This function will be called back from the functorfunction btn_rename_click() print ("this wont work")end

In C++ the functor is pretty lame. It looks like this:
class button_click_handler{ public: button_click_handler(const std::string& func) { m_func = func; } void register_event(boost::shared_ptr btn) { btn->click += fd::delegate(&button_click_handler::on_event,this); } void on_event() { std::cout << "on_event" < lua_getfield(L, LUA_GLOBALSINDEX, m_func.c_str()); int s; if( (s=lua_pcall(L,0,0,0)) != 0) report_errors(L, s); } protected: std::string m_func;};

What I like about SWIG and the functor solution is that I can code everything that is related to scripting in separated source files in such a way that the engine is never aware that it is actually being scripted.

As always, a screenie for the voyeurs:

## Art. Or about how I cannot make it.

I'm currently fighting against 3D modeling, animations cycles, proportions, imagination, style, drawing-skills in order to see if I can make up a decent load of artwork to start pushing some sort of game on the road... And It's becoming a really hard task.

Destiny doesn't seem to accompany my weak motivation cause when I was in the middle of modeling some 3D stuff (after several crashes on Blender3D's part) a blackout left me right in the dark for like 5 hours. I did not even have candles FGS!

Yet I managed to make a fairly decent ragdoll to start testing animations and world-collision with my programming. Possibly tomorrow I'll try to master walking, running and jumping cycles and start making something that resembles a game.

The fruit of my effort (lol):

## Model Editor - Custom File Format

After a week or so of great procrastination I finally made some progress with the model editor.

As the title prays, it is now capable of loading xsf, xmf and xaf files (Cal3D XML) and saving them in binary format in a custom file of my own.

The file format I implemented is actually quite naive:

FILE_TYPE (1 byte) { 0=skeleton, 1=mesh, 2=animation, 255=eof }
FILE_SIZE (4 bytes)
FILE_DATA (FILE_SIZE bytes)
[repeat per file]
{eof}

As I'm using PHYSFS for loading my files into memory buffers I needed to save the binary files separately first (using Cal3D routines that don't use PHYSFS), then load them into different buffers, deleting those files from the disk and then memcpy the type, the size and the data of each buffer into one big buffer which is the final one that gets saved.

As always, even when it doesn't really makes sense here, the video:
[media]
[/media]

Cheers!

## Model Editor - Animations

Hello gamedevers!
The thing keeps going, now it can add animations and play them at will.

I'm having problems understanding what's the logic behind blender3d rotating my models depending on if it has a skeleton parented or not... I'll eventually get it I guess.

Videooooo
[media]
[/media]

## Model Editor - The Beginning

I woke up this morning like 7am (after sleeping the hangover for almost 18 hours) and I must admit I felt quite well.
I dreamed a lot. One of these dreams was about a house I used to live in some other town. I was re-building the front wall with high quality bricks. My entire family was there, including my daughters and my ex. I think there even were some pets (kittens I think...)..

So I woke up, made some coffee. I read the mails and then opened the last CodeBlocks project I was working on and sat there watching at the code feeling ZERO like coding something. The last thing I made was the dialog for opening files and supposedly the next step was giving it a use but I really didn't want to do anything... And then I started copy pasting some stuff here and there and after half an hour or so I managed to have a very basic Cal3D model loader.

I even made a video for you to watch. The framerate is fixed to my vsinc of 75hz but the program I use to capture cuts it down very badly.
[media]
[/media]

## GUI Update - File Dialog

I made some little more progress on the GUI library. The file select dialog is now fully functional.

I've divided the GUI in 3 layers: Children, Floaters and Dialogs.

• Children is the tree that holds most of the controls.
• Floaters is where things like drop-down lists, menus and tool-tips go. This was necessary as each control sets it's own viewport and sometimes menus would get clipped out if a control is small.
• Dialogs is where only the top-most control (usually windows) go. When a dialog is visible all other controls will be disabled excepting floaters.
[media]
[/media]

And of course another Tarja Turunen's karaoked song. heh

## Journal Update: More KARAOKE.

Yep. The guy is still on sleep deprival and karaoke.

I could have picked an easier one but well, who cares!

Teh Horror!

## What to do after you're 35+ hours awake: KARAOKE

That's right. You borrow someone else's computer microphone, find a song you like with the vocals removed on the internet and then you sing like a dying dog! If you feel like playing "Music Producer" you can get some free sound editing app to make sure everyone can witness how much you suck at it!

Without further ado, my stolen masterpiece. I got it on in just one take:

[media]http://www.reverbnation.com/tunepak/3148445[/media]

Game programming? Bah!

I love teh media sharing feature lol
[media]
[/media]

## GUI: I think I'm done for now + video

I finished coding the ListView and ComboBox controls. It was really hard cause I started procrastinating real bad. I was like blocked or maybe just sick of thinking how these controls could be done easily and efficiently. As if that wasn't enough last night and the night before I went to the bar so there was no chance I could program a thing, but tonight I decided I'd finish it and I must admit that most of the work was done at a subconscious level.

Here the screenshot for the posterity:

As I'm bored I also made a video. The program I used for capturing dropped my framerate to the abyss but well...

Teh Video:
[media]
[/media]

## GUI update

I've been making some more progress with my OpenGL based GUI. I got the Textbox control to properly handle unicode characters though I couldn't make tildes to work yet. I'm guessing that maybe it won't be possible with SDL and I'm gonna have to do it char by char myself (which would suck).

I also finished coding the ScrollBars, added a Mouse Over effect to buttons and also the possibility to add a centered image to buttons (I needed it for the ScrollBar arrows).

Now I'm going for the ListView. After I finish it ComboBox will be a walk in the park. And I think that will be it for now. With those controls I'll be ready to begin working on tools to edit Models and Levels. Once I get that up, the only thing that is left is the game itself.

Some pictar:

## Comments on my entries weren't visible

I think I've got ghosts on my gdnet account! I had my blog settings set to "Approve all comments" and for some reason they weren't visible. Some minutes after I approved them by hand they became visible. This felt something like when I can't find my keys.

Update:

[font="arial, verdana, tahoma, sans-serif"][size="2"]Well it's solved now thanks to Gaiiden. He explained to me what I was doing wrong.

In the Blog Settings, when you select "Approve All", it means you GOTTA approve them all yourself. If you want all comments to be approved by default you must select "Approve None".[/font]

Now, where are my keys?...

## My OpenGL-SDL GUI

Yes, after years of hanging out at night, tons of gallons of beer and a couple of hundreds of women I'm back at my project.

Here a screenshot:

What you see here is an OpenGL-SDL based GUI from my own kitchen. In the background there is a skeletal animation of a 3D model using the Cal3D library.

So far I've coded MenuBar, Context Menu, Dragable Window, Textbox, Checkbox, Button and Label controls. It makes use of VBO for everything and it supports reloading of video resources on display mode change.