The float to int conversion’s big mystery

Someone must explain me this thing… I was working on my roguelike, namely the wall collision, when I came across one of the strangest things seen recently. My issue was to convert space coordinate of my @ into 2d matrix coordinate of the map, a bi-dimensional array. My space2map function perform some calculation and give me a x,y values, quite straight.

It seemed to work, but after a bit of testing things began to go wrong… when I was expecting a 2 I get a 1 instead, or the like. For some debugging hours I was sure I was wrong, but in the end I found myself in front of a thing like this:

(0.2 + 0.3) / 0.5 = 0

It was enough to make me think that yes, math is an opinion. A compiler opinion, at least.

After a while google gave me the answer: there is something on the float to int conversion. A really magic function came with the answer, this:

int iround(float x)
{
return (int)floor(x + 0.5);
}

where floor() is the math.h C function.

I tried with this and it works. Then, I wrote a simple program to test this mystery, and this is the result:

The float to int test

For the record, this happens on GCC for Ubuntu 8.04.

Happy new year

Time to spend some days far from computers. I’m just back from mountain, as the picture shows. Here I am in Campo Carlo Magno, Madonna di Campiglio (Italy) on Dolomiti. Beautiful place and beautiful snow.

But now I’m back, and my projects are waiting…

My Own Roguelike: part 2

A little update on development of my roguelike.

A first attempt in creating the floor

In Part 2 I have to deal with the map. First, I started drawing something under my character. I defined my map as the most simple thing: a matrix of uint. I implemented the matrix not as array of arrays but as vector of vectors, using the plain good old STL. After that, I have filled my matrix with 0s and then, in the draw() method, drawed a red square of given width cicling my matrix.

Next, I opened blender and modeled a cube (well, it was pretty easy since a cube is the default mesh as you open blender…). After a bit of UV mapping a texture was applied to my cube.

I decided to maintain the old tile method, but using 3D tiles instead of 2D ones, and so a cube in place of a square. Quite straight, isn’t it?

So I went up with my textured cube. I placed some 1s on my matrix and coded a routine that draws the cube in the right position according to the position of 1 on the matrix.

first blocks of terrain in my world. @ is not alone now!

Ok, shame on me for my graphic skills in doing the texture, but it works. Ah, I also coded the routine to load texture and UV coords from .X files. If someone need of it… maybe I’ll do a post for it.

It’s been a little issue to define a unit of measure in order to make all the same size: the @’s steps and the tiles I mean. In the end I calculated the minx and maxx for the blocks and it gave me their length. After a bit of attempts I came with a correct @ position and step.

Next, It was the time to apply a texture to the floor. Not only: the floor has become made of tiles too. I modeled a simple little plane, scaled it as the blocks and textured. Now, when processing the matrix values I place a floor tile for 0s and a block tile for 1s.

To make possible exploring the map I wrote a routine for the camera to follow the @. But here I have a question: I used the gluLookAt, but in order to appreciate changes I have to switch everytime to projection matrix and call glLoadIdentity on it. This give me an annoying blink effect I would like to avoid, but at the moment I don’t know how.

an entire level textured

Next, to complete step 2, I have to deal with wall collision detection, but this is very simple. Since it’s turn based and movements are steps of predefined lenghts, I can simply use the 2D method: look at the terrain matrix and its 0s or 1s values. I think I’ll do a little refactor after that, ’cause my code is becoming messy in some points.

My Own Roguelike: part 1

So I decided to write my own roguelike.

Fine. In this article on roguelikedevelopment.com I found an interesting starting point.

The author lists 15 steps to develop this type of game. Shortly:

1. Decide to write a game
2. Hello World!
3. It’s a boy!
4. The map
5. Saving/Loading
6. It’s alive! Alive!
7. Interaction
8. Data files
9. Items
10. Magic
11. Simple game
12. Levels
13. Experience
14. Citizens
15. Free at last

Step 1 is rather easy and yet completed. My roguelike will be something about a bad guy named Xarr hidden in the deeper level of his ultra deeper dungeon, the Kingdom of Evil.., and a good guy must reach and defeat him. Sounds original, uh?

Step 2 is quite simple too. I opened my code::blocks, created a new project and imported libraries from Pong to create an OpenGL graphic context with SDL and manage some basic input. Compile, run et voila, my Hello World works without surprises.

Step 3 is the first real milestone. I have to display something on screen, and this something is no less than the player. Yes, the good guy of my plot. The hero. Well, in most modern games this will require a beautiful textured mesh, but in Roguelikes the hero is simply a @, which really simplify life. But, as said in previous post, I want to make this game something between classic ASCII roguelike and modern 3D RPG. So I opened Blender, modeled a @ and exported. Now I have my beauty 3D version of the hero.

Author of the article seems to follow a XP way, because he repeat more than one time to not troubles about planning everything or write the best code from the beginning. Implement only what serves at the moment seems to be the rule, and so I do.

Player class is born, featuring a draw() and move() methods.

The last issue is text. After a bit headache I opted for a temporary solution: using SDL_ttf library. Probably I will look for some other solutions, maybe FTGL.

It’s all for now. Next I will face the map.

The Hero wandering in the empty world

What about a Roguelike?

Next project as I have in mind to deal with is a roguelike.

Yes I know, this is a huge amount of work, and probably it will not end as good as Pong… but I really want to try.

I have an idea about the interface. I would like to keep using OpenGL and the little framework builded for Pong, and so using a graphical user interface instead of text. But I love text-only roguelike, I found them … poetic, while tile-based are often nothing more than… 80ish (maybe because tilesets are always the same in all games, since about 20 years i think!).

But my roguelike will use 3d graphics in a nice way. I’ll keep the classical @ and other symbols, but they’ll wander in a 3d dungeon with textured walls and floors.

This is my Colombo’s Egg. I always wanted to develop an RPG but 3d modeling or even 2d graphics always represented a big obstacle. Maybe this time I’ll be able to move some more steps into this dream!

3D Pong collision detection: the simple way

As said in previous posts I’m actually working on a Pong clone in OpenGL, SDL and C++.

Topic of this post is Pong’s collision detection.

In a 2D environment this is quite easy and deserve of a very poor math, since we have a defined screen resolution, defined objects size and a perfect 1 to 1 relationship between units and pixels. We simple need of some x,y calculations.

But what in a 3D env? First, we don’t have relationship between pixels and units. Second, object can be translated and scaled, which means their size can change.

There are quite a few algorithms for 3D collision detection, I know of their existance but I master only one of them at the moment: Bounding Spheres.

Anyway, I tried with bounding spheres (which probably will be topic for another post) but I realize this is not the best suitable alg for the cause. In Pong we have to deal mostly with stretched cubes, and a sphere is not the best geometric figure to surround them. What we need is probably a Bounding Box version of the algorithm but… wait a moment.

Maybe what we really need is only a 3d adaption of our old, plain 2D algorithm.

Sure, we can’t tell how long or how fat is our racket or our ball, but we can calculate where object is on the 3D space, and with a little effort we can tell which vertex is the more up, the more right, the more left and the more bottom.

We can do that simply passing through all our object’s vertexes and locate the one with the higher y value, which will be the most up, then the one with the lowest y, the most bottom and so on with the x values.

At the end we have 4 vertexes for every object in the scene describing their borders.

But the ball is moving, and the rackets too. We need to keep update this borders with the object’s translations. But this is simple: if object translate up (0,1,0) we translate up all 4 border vertexes by the same values. Vertexes follow the object movements, of course.

And if the object scales? Well, we scale the borders too in the same way.

So, here we are with our vertexes. And now? Eheh, now the easy part. Each loop we only have to  check ball borders with rackets and field opposite borders in order to detect collisions.

For example: if ball’s right border is major or equal to player 2 racket’s left border (assuming player 2 is the one on the right) we have a collision.

if( ball.maxX() >= player2.minX() ){

ball.collideRight();

}

Easy, isn’t it?

SDL: SDL_KeyboardEvent too slow?

Once again my OpenGL Pong clone gave me a chance to dig more into the common game programming issues.

This time the problem is SDL and its way to manage user keyboard input: SDL_KeyboardEvent.

The scenario is the following: I have my ball bouncing from one side of the game field to the other and my racket that should move up and down according to some key press events. Really simple. But…

The racket moves too later. I press the key, wait for about a second, and then that white rectangle of pixels decide to obey. Too, too too late.

So what? SDL is slow? No, once again computer is right and I’m wrong.

The issue is on my fps. Scene is rendered too speedy, more than 900 times per second. My handleInput() routine is placed at the very beginning on the game loop and no one knows when exactly the “key pressed” event is fired and catched. I have to tell the truth: I don’t know exactly why this happens, but happens. And I found the trick that solve it.

Delay.

Simply reduce in an artificial way the loop speed and the magic will happens: the keyboard response becomes immediate.

How to do that? Using SDL_Delay and SDL_GetTicks to force the fps below to a maximum rate.

At the beginning of the loop you take the current number of ticks and at the end do the same. Then check the difference with a costant of your choice and delay the loop of the difference. Something like that:

Uint32 start = SDL_GetTicks();

/* do graphic stuff and all the game loop logic */

Uint32 end = SDL_GetTicks();

if(end – start < MAX_FPS_RATE){

SDL_Delay(MAX_FPS_RATE – (end – start));

}

I’ve used 33 as MAX_FPS_RATE to have about 30 fps and all the inputs works great.

OpenGL: how Display Lists can improve performaces

I’m actually working on a 3D version of Pong, using OpenGL via SDL and coding in C++ under my linux Ubuntu.

This simple game is a great exercise and I’m using it to develop some common routines such as a mesh loader for .x files and related mesh renderer. So I’m having the opportunity to face a serious performance issue.

My scene is composed of about 2500 polys (a plane, 2 rackets and the ball), really low count, but enough to reduce my frames per second (fps) to 3 or 4. Ugh! My ball is moving really bad.

But OpenGL is fast! where is all the power? Well, the reason lays in my way to render polys.

My utility was rendering all the scene’s polys, one a time, between glBegin(…) and glEnd() commands.

This way, I was invoking glBegin() one time for every poly. Definitely not good.

What I did was change my rendering routine in order to use Display Lists.  This gave me a real boost of performances!

Now my fps are about 1000 and I have to face the opposite issue: too fast! But the real message is that OpenGL’s display lists works!

Windows Mobile and the “unknown publisher” exception

A few days ago I was deploying a new version of a software of mine on a PDA running Windows Mobile 6.0 and I have had to deal with a boring “unknown publisher” prompt. My new compiled dll was not recognized as trusted. What to do to get rid of this nuisance?

Well, I found this helpful link where the guy explains how to do but lacks of some important details so that I was obliged to surf again to fix. At the end of the story, I found a way.

To get rid of the message we have to edit a registry key. My app was in .NET (C#), and here is the code that fix the problem:

string keyname = “0000101a”;
RegistryKey securityKey = Registry.LocalMachine.OpenSubKey(“Security”)
.OpenSubKey(“Policies”).OpenSubKey(“Policies”, true);
object val = securityKey.GetValue(keyname);
securityKey.SetValue(keyname, 1, RegistryValueKind.DWord);

Hope this helps.