GP2X Re:... Drawing The Road On A Top Down 2d Racer


twojame

Member
Joined
Dec 27, 2005
Messages
120
Website
my-cognatus.co.uk
Just have a quick query on a project that i'm working on and i'm hoping to get the communities input if possible.

gameDemo.gif
(demo image... it doesn't do much :) , it's drawing the car, processing the input and capping the frames to 60fps)

My question is to do with do with drawing a road for my monaco game. I've contacted Lazy Foo with the following question....

<<<<My first project is a top down 2d racer somewhat like spy hunter/monaco gp.? I'm not sure if I should use a tile based approach like you're lesson 29 and scroll that some how or if I should use one big image and scroll that like you're lesson 22.? I was wondering if you had any thoughts on this or might recommend a technique?? So far I've got the input mechanics working which moves the car on screen.? So I'm very happy with that>>>>

Lazy Foo felt that a tiling engine would be more flexible and use less RAM than one big image...

I'm just wondering what everyone elses thoughts on this are. I've decided to go with the tiling engine approach as it would be more flexible I feel and I hope to define level maps to draw the road. I've worked out the algorithim to read in a map and loop through the array drawing each part of the road.

The only issue that's worrying me is that currently with just drawing the car and processing the input mechanics i'm getting circa 45 fps (note the screenshot is from windows). Obviously i've still got optimization to do so that should improve. Which approach would be better for fps? The tile based approach or scrolling one big image?

Anyway if anyone has some thoughts on this that would be cool.

All the best...

<edit:
mongp3.gif
I think this image of the arcade game shows the tile based approach... I don't think that they would scroll one huge image...

This is a mockup on the screen using the tiles that i've now created and which are defined in a map file (01.lvl)..., each tile is numbered... i.e. 01.bmp, 02.bmp
demoGraphic.gif

>
 
I would think tiles is better. I think you can do much more with them instead of one static image.
How do you store the tiles?
How do you process them? Do you draw all of them or only the ones that are viewable in the screen?
 
Pickle said:
I would think tiles is better. I think you can do much more with them instead of one static image.
How do you store the tiles?
How do you process them? Do you draw all of them or only the ones that are viewable in the screen?
hi there,...

I think you're right regarding the tiles... I can just plug in new images by changing the file.

The tiles are stored within a comma delimited text file then I intend on reading that into a 2d array. I will then have another function that loops through the array and picks up the correct image...

For instance this text file

04,01,02,02,02,03,04,04
04,01,02,02,02,03,04,04
05,01,02,02,02,03,04,04
04,01,02,02,02,03,04,04
04,01,02,02,02,03,05,05
04,01,02,02,02,03,04,04
04,01,02,02,02,03,04,04

is what defines the image I shown above. 04 means 04.bmp... I will only draw what's onscreen... Each image is 40pixels by 40 pixels so the above map is slightly bigger than the gp2x screen ( he says :) ). So what i'll try and do is adjust the offset by the speed of the car which should give the illusion that the road is moving. I never done this before so stay with me here :-D

I think that should work :) ...Just worried about the framerate...

J
 
Last edited by a moderator:
twojame said:
... Each image is 40pixels by 40 pixels...
Typically, trying to display an image whose dimensions are not a power of two (32, 64, etc) tend to take longer than those who are. I'm not certain that's true for the GP2X :gp2x , but it's typically true of, say, SDL for instance. At least on other platforms.

-E
 
Last edited by a moderator:
atari_eric said:
twojame said:
... Each image is 40pixels by 40 pixels...
Typically, trying to display an image whose dimensions are not a power of two (32, 64, etc) tend to take longer than those who are. I'm not certain that's true for the GP2X :gp2x , but it's typically true of, say, SDL for instance. At least on other platforms.

-E


Ahh right... thanks...I'll take that into consideration.. It's going to be interesting to see what the fps is once the whole screen is drawing

The fps is currently 45, but i'm sure with some tweaks I can get it moving quicker.
 
Last edited by a moderator:
I guess im still in disbelief that your program is only showing 45 fps.
You must have a very timeconsuming section of code or your frame calculation isnt right.

Im my program im doing many more tile's than you are and ive never gone below 60 unless I had a serious bug.
 
Pickle said:
I guess im still in disbelief that your program is only showing 45 fps.
You must have a very timeconsuming section of code or your frame calculation isnt right.

Im my program im doing many more tile's than you are and ive never gone below 60 unless I had a serious bug.
I think I know what it is... I'm loading in the image of the car each frame! doh! :blink: ... It should only load that in once before the main game loop... perhaps some kind of load resourcesIntoMem function. I'm finding that it's good fun looking at my game loop and seeing where to improve things. This is all taking me back now. The last time i've done game programming was using AMOS pro on the amiga...

On the pc without the frame cap it runs at like 190fps...

I'll change that then see what i'm getting...

thanks
 
Last edited by a moderator:
twojame said:
I think I know what it is... I'm loading in the image of the car each frame! doh! :blink: ... It should only load that in once before the main game loop... perhaps some kind of load resourcesIntoMem function. I'm finding that it's good fun looking at my game loop and seeing where to improve things. This is all taking me back now. The last time i've done game programming was using AMOS pro on the amiga...

On the pc without the frame cap it runs at like 190fps...

I'll change that then see what i'm getting...

thanks
Definitely load the image just once when your program starts.
I do not have much experience with racing games programming, but back in the DOS games I created sort of a Jet Ski clone (water jet ski simulator). Back then I used a large static image exactly the size of the screen.. yes, I know, no scrolling. But blitting this image was faster then splitting it into tiles. I also had a shadow map, which was a copy of the whole image yet drawn in only a few colors. This map was used for collision detection, so that I knew when the jet ski entered shallow water (and got slowed down) or downright hit land (and was stopped). Also it was handy for placing checkpoints, terrain levels etc.
The other approach was going to be used in my Dizzy clone, where I used tilemaps. It was on the GamePark32 and the handheld was managing rather a good speed. The game never got to any advanced stage of development, but the engine worked with Dizzy happily walking and jumping around :) For collision detection (which you may be going to need too) I, once again, had a copy of the tileset yet in black and white to allow pixel perfect collision detection. You then choose a few points in the sprite (the car in your case, for example the four corner points in the simplest case) and check them against the black-white tileset.
If you just want the car to go upwards and the screen is only going to scroll down, you may be happy with the fastest bouncing-boxes collision detection for which you need no shadow map. And going for tilemaps is probably the best approach as it is easier to make modifications to the background and, as has already been stated, consumes less memory.
 
Last edited by a moderator:
WhiteFalcon said:
Definitely load the image just once when your program starts.
I do not have much experience with racing games programming, but back in the DOS games I created sort

snip...
Thanks WhiteFalcon, some great points here...

I'm already starting to think forward towards collision detection. It's not something I’ve done before as a business applications programmer :) ...So you're advice is very much appreciated...

It's really good when you're excited about a project and just want to run at it. I'm going to try and get the road up and drawing over the weekend then post my results.


J
 
Last edited by a moderator:
LET THERE BE ROAD! :D .... better late than never...

I've finally figured out how to a) read a comma delim file in, and then B) spool it back out from the array onto the screen.

now need to make the speed of the car determine how fast the road moves.... hmm, this is something i've not done before... any ideas chaps? I'm thinking that would I shift the start offset of where i'm drawing from and then loop it back around...

It's theses forums that keep inspiring me to continue with this work...cool!



J

demo.gif
 
Do you have vertical top-down scrolling implemented? If so, start simple:

scroll x pixel lines per frame, where x is the car's speed (0, 1, 2, ...)

After you get that working, you can refine it by scrolling x pixel lines per frame, where x is the car's speed divided by 16. (0, 1/16, 2/16, etc)

Good luck!
 
Alex. said:
Do you have vertical top-down scrolling implemented? If so, start simple:

scroll x pixel lines per frame, where x is the car's speed (0, 1, 2, ...)

After you get that working, you can refine it by scrolling x pixel lines per frame, where x is the car's speed divided by 16. (0, 1/16, 2/16, etc)

Good luck!
ahh...cool, thanks i'll try that.

Oh, interesting website and games you've got there. I've been trying them today on my gp2x.
 
Last edited by a moderator:
I would use tiles to build one large image to scroll - but you probably know better than to listen to me. I have yet to try a scrolling game.

It is looking good. Any progress since your last post ? I hope you have time to keep us updated - (so I can steal your techniques).
 
I'd try the concept of the viewport, the speed of the car is how far you make the viewport jump and tie the tiling of the physical screen image relative to the screen size viewport of your large virtual track and countryside. That yellow might be a bit too bright, I think the car should stand out above all else. Maybe consider changing the angle of the view in the next version, like say 85 degrees behind and above the car? 2d doesn't have to be 2d. Lovely looking car there. Got a working title yet? If you do 32 bit color in transparent png you won't need to use pink and can alpha blend.
 
Hi there chaps and thankx for the responses....

Sphinxter said:
I'd try the concept of the viewport, the speed of the car is how far you make the viewpoint jump and tie the tiling ...snip
this is what i'm currently trying to wrestle with. I've unfortunately not had much time to work because i've just come out of a short stay in hospital, but i've used that time to work on a camera system similar to you're method above. :)

...Basically the way i thought about it is that a car has a vector, i.e. PixelsPerSecond and direction. It also has acceleration. When a user presses up on a key it takes the acceleration and creates a vector which contains pixels per second and direction. I think that should do it.

Then I would need to somehow map that vector to actually move the camera (I think that's what you refer to as a viewpoint)... Ahmmm(brain hurts).. So then the render function knows that the car is moving north at a rate of x pixels per second. Then it knows what number of pixels to move the road by.

I'll also need some code in there to loop the road if the level is very short. Not sure how that will be done yet...

QUOTE

It is looking good. Any progress since your last post ? I hope you have time to keep us updated - (so I can steal your techniques). ...snip



So far i've got a little level text file created and it's little block graphics. 01.bmp etc. I've got the game loop spinning and the input mechanics working with a frame capping system.

I've figured out how to read in the text file and transpose that to a 2d array of Tile objects of a class type. I think that my rate of progress is slow due to the language barrier still causing me problems.

I'll try and get the road scrolling with the camera system and real arcade graphics...Monaco GP sega 1979. Then i'll post a build. just to warn you chaps it's no where near the quality of Jaba's work or some of the other quality homebrew on here... :D

Jaba; i've posted below the file i/o level parsing code. It's of a very cheeky early beta standard, but it works for my early purposes :D

CODE


bool load_files() //...should only ever call once
{
bool blnRetVal = true;

//Load the required resources...
sfc01 = load_image( "_resources/01.bmp" ); //note: we're not doing any clipping here...
sfc02 = load_image( "_resources/02.bmp" );
sfc03 = load_image( "_resources/03.bmp" );
sfc04 = load_image( "_resources/04.bmp" );
sfc05 = load_image( "_resources/05.bmp" );

//If there was a problem in loading resources
if( sfc01 == NULL || sfc02 == NULL || sfc03 == NULL || sfc04 == NULL || sfc05 == NULL )
{
blnRetVal = false;
}

//If everything loaded fine
return blnRetVal;
}

//takes the level file data and converts it into an array...
bool fnLoadTilesFromLvlToArray( Tile *inTiles[] )
{
bool retVal = true;
bool blnOk = true;

//get level data...
std::ifstream map( "_resources/01.lvl" ); //todo: make dynamic for multiple levels

//validation...
if ( map == NULL)
{
blnOk = false;
}

int intX = 0, intY = -240;
string strTileType = "";//...begin with invalid
string valX = "";
string valDebug = "";
int intTileCnt = 0;

for ( int intT = 0; intT < 12; intT++ ) //12 rows of data...0 based!
{
strTileType = "";//...reset
valX = "";

//Read tile from map file
map >> strTileType;

for (unsigned int intL = 0; intL<=strTileType.size(); intL++) //this would get "xx,01,etc"...step thru each char!
{
char varTest = strTileType[intL];

if (varTest == ',') //ensure buff isn't ","
{
//NOP...
}
else
{
valX = valX + strTileType[intL];

if (valX.size() == 2)
{
//...todo:create tile, cast string to int
int intTile = -1;
intTile = cIntEX( valX );

inTiles[ intTileCnt ] = new Tile( intX, intY, intTile );

string valFQN = "";
valFQN = valFQN + gCNST_Resources + "/0";

std::eek:stringstream out;
out << intTile;
valFQN = valFQN + out.str() + "." + gCNST_IMGExt;

inTiles[ intTileCnt ]->set_Image( screen, valFQN );

intTileCnt = intTileCnt + 1; //increment tilecount...

//reset valX
valX = "";

//Move to next tile spot
intX += gcnstTILE_WIDTH;

//If we've gone too far
if( intX >= gcnstLEVEL_WIDTH )
{
//Move back
intX = 0;

//Move to the next row
intY += gcnstTILE_HEIGHT;
}
}
}
valDebug = valX;
}
}

retVal = blnOk;
return retVal;
}

void sbDrawTiles( Tile *inTiles[], int inYStartPos ) //...draw the tiles for intYStartPos
{
inYStartPos = -240; //...to 0 to +240... sdl screen starts from the top zero to x positive integer
int intXYEndPos = 240;

for( int intArrPtr = 0; intArrPtr <= (gcnstTOTAL_TILES - 1); intArrPtr++ )
{

inTiles[intArrPtr]->show(screen);

}
}



edit: still getting hold of original arcade graphics... currently have sound samples from mame


Rgds
J
 
Last edited by a moderator:
Let there be scrolling and a level designer! (called notepad) :D

Had some fun and games with this one chaps. The first build was a pc killer. After 1 minute of running on my brothers pc the memory usage was 1gig :D ... Anyway i've fixed the memory leak.

Anyway...at the moment this is just to demonstrate that the tiling system works in concept. just simply change the numbers in the "01.lvl" and the graphic shall appear in the game. Providing that you keep the level file in the same format it will work.

I've quickly knocked together 100 ish screens to show how the graphics might look, but I'm pants at designing the actual levels to be honest (cough...cough...) :) . Just place the monaco folder and contents on the pc or gp2x and tap up a few times to start the car moving...

This is my first gp2x project so it's just taking me time to get started... Don't rib me too much :D

done:
tiling level function that reads from file to display tiles
beta level 1 with 100* gp2x screens high
sorted out input mechanics..use x to speedup
fixed lockup when going back to menu
beta sounds
volume controls
50 fps

todo list:
gameplay
an actual game
menu
ai
all the other good stuff
ensure 60 fps


....download link
monaco download (I cannot be held responsible for any issues when running these binaries...)

..........sample images from pc build
demo20.gif

demo22.gif

demo23.gif

demo25.gif

demo26.gif

demo27.gif
 
Hi chaps.

Quick question if I may please...

I'm at the point of building the sound for my car. Now then now then... My car can have 20 gradients of speed from 1 to 20... 1 being slow and 20 being fast. I'm split between 2 ways of doing the sound either a) 20 individual sound files which would be played using Mix_LoadWAV... so within the game loop I would say, if (car.speed = 3 then play spd03.wav... Or B) use one engine sound file eng.way, and tie the pitch of the audio to the current car speed. Not sure if that's possible with SDL? Sorry quite new to game dev... any thoughts on this chaps? Method b sounds easier if it's possible within SDL. I want the sound to go urrrrRRRRGGRRRR! (err yeah ok enough of that)...

I have the following original sounds from the arcade.

acar.wav (fast)
accHA.wav
accHB.wav
accHD.wav
accLD.wav (slow)



J
 
Unfathomable Depths said:
I used the first approach (loads of wavs) as I couldnt find a way of altering the playback frequency through SDL.

Thats not say there isnt someway of doing this.
thanks... Do you know if Audacity is capable of doing this?

J
 
Last edited by a moderator:
If you mean pitch shift the wav file, yes it can.

How I did it was -
Get the lowest sound. Pitch shift by some small amount. Save it. Undo pitch shift. Pitch shift by some small amount x 2. Save it. Undo. Pitch x 3 etc etc

Pretty boring but it didnt take that long (I had 16 to do).
 
Back
Top