S.A.D.: a space project

Just a couple of screenshot from my latest project, S.A.D. (Seek And Destroy), a 3D shooter in which you are a rookie that have to shoot down the vicious spy-satellites of an unknow alien force.

This is the first time I face moving free across an empty 3d space… it’s not as simple as it sounds!

But, well, here are the pictures:

Models are self made and these are also my really first non-cube models! I used Blender for them, but I have not textured and also lights are turn off, so I render them as wireframe (for the player ship) or plain solid (the sat and the terrain).

I’m also using FTGL for the text rendering, I found it very simple and immediate (and pretty fast).

a spy sat in sight

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.

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?

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!