1 reply to this topic

[Bad Sector]

(copied from the page... but i wouldn't say anything else anyway :-P)

Forced Ship a 2D rigid body physics game i wrote. You can get it by clicking this link.
This includes the full source code in C++. You'll need SDL and Dev-C++ to build it.

I'm trying to learn how to implement rigid body physics, so i started with the "easy" case, doing it in 2D. I was playing Quake 4 (very good game - much better than DOOM3, imho) all the morning and i was bored to switch to Linux, so i did the whole thing in Dev-C++.

Also before starting this thing, i knew absolutelly nothing about rigid body physics, except that right body move and rotate in space. So don't expect it to be The Best Thing when it comes to true and correct physics simulation.

Given that i figured out almost everything in this stuff myself, i expect to be incorrect in some cases. But it behaves "normally", so i don't really care. I said that almost everything is figured out by myself. I knew how to do point-based physics, so i started from that. The difference is that instead of using a point, i used a whole "body" as the... place where forces will be applied. I was plainly applying the forces to the body's center, the same thing as i'm currently doing in Undead Engine.

The next thing was to do rotation. Extending the idea of position and velocity (position is the body's position -aka the center- and velocity is a vector that is added to the position in each "step" of the simulation), i added rotation and... rotation velocity. Then i tried by putting random values in rotation velocity and it worked... randomly.

I got stuck at the point of figuring out how to figure out the rotation velocity. I tried some stuff with dot products and other stuff, until i gave up. I thought to stop trying to do it "my way" and read some material on the subject. I had some PDFs in a DVD from Chris Hecker who described rigid body physics. I read them and saw that what i had figured out by myself was very close to what Hecker described; but he also mentioned how to calculate the rotation velocity (rotation is actually called orientation so i renamed all my "rotation" blah to "orientation" blah in a try to be correct... yeah right). However, the methods that Hecker describes seem to me a bit more complex than needed... and i did it my way, again, but now using Hecker's method for figuring out the rotation, erm sorry, orientation velocity.

And it worked! I was able to put forces in a small 2D rigid body (a rectangle actually) and it was moving and rotating. I applied these forces at the left and at the right of that object and the object's behaviour reminded me of an old game, asteroids. So i changed the object's shape to be like a ship (it's still 2D wireframe though) and modified a bit the way forces are applied, to follow the ship's rotation (originally they always were pointing "up").

Soon i was able to control a small ship in my screen. I decided to make it a "real game" (well, as real as a game like that can be anyway - but i assume that it would be a hit in early '80s arcades Razz) and added a goal: to collect some items.

The ship's navigation isn't easy, since you only can turn on and off the left or the right engine (turbine). The left engine pushes the ship from the left at "front" and the right engine pushes the ship from the right at "front". But when the left engine turns on and because the ship's "center of mass" (which is the same as the object's center - heheh) is right from the point where the force is applied, the ship turns right. Similarly when the right engine turns on and because the center of mass is at the left side of the applied point, the ship turns left. By turning both engines on, each rotation cancel the other out, so the ship moves forward.

So using the left and right engines you navigate the ship to collect all the rotating objects in the screen. When you collect an item, your score increases by 3000. The score -in an oldfashioned way- decreases when you use an engine - and decrases in doublespeed when you use both engines.

So i think that that's enough for a simple game. Isn't it?

(if you think that it isn't try to improve it by yourself - the code is in there)

A note about the code... i wrote the code in order to test the algorithms. The code is bad, ugly and slow. Especially the drawLine function which does a square root to figure out the line's length and interpolates both x and y! This is a bad thing to do when you're trying to write fast code - because this is not fast.

However my purpose is to have it running as fast as possible (i mean i wanted to have the code ready as fast as possible) in order to get right into implementing (and messing with) the physics.

If i wanted speed, i could implement Brenseham's algorithm or just use OpenGL (which also provides nice antialiased lines).

[Ed Mack]

This is cool, I'm downloading and having a go at building under Linux. You make me seriously want to do the same and try making a 2d physics sim. :D

If you want a linux makefile, please take:

obj = $(wildcard *.cpp)
obj := $(obj:.cpp=.o)

LD_FLAGS = `sdl-config --libs`
CFLAGS = `sdl-config --cflags`

main: $(obj)
	g++ -o $@ $(obj) $(LD_FLAGS)