Community game developing culture and challenging competitions


so you want to seed srand with a different number ONLY ONCE every time you run the program. http://www.cplusplus.com/reference/cstdlib/srand/ Dont call srand with tv1 as a parameter - use something like the system time: srand(time(0)); and that will give you a different seed every time the program is run.
I disagree with this. There are times you want, and times you need, to reseed. For example, in my Freecell game, you reseed at the start of every game with the game number, same with CyRacer.
Thanks. I should have been more specific. In THIS program you only want to srand() once, before the game loop.
 
Well I tested just now to blank out the following 2 srand() calls, and it does work here now like I originally thaught, that multiple calls to rand() gives different values, cos when I first tested the function some time ago I got the same number all the time, unless I fed a different value to srand() in between...

Ok I tested with lower scale and I still get different values every time, I also learned that if you type rand()%5+5 the numbers will be in range 5-9, but if you type rand()%(5+5) the numbers will be in 0-9.

I should have been able to figure out it meant bits not bytes, it was because C++ webpage list the data types it lists in bytes... But the use of the Uint8 here is to give a 256 range of numbers, same as an unsigned char, 1 byte = 8 bits, but then the question is why didnt they code the function to want a char? Cos it may be a letter?
 
edit: fixed my own stupidly broken C++ headers


edit2: you should use proper indentation


edit3: your frame rate limiting code is broken - game updates as fast as SDL can draw the box. I fixed this and a couple other minor things:


#include "iostream"


#include "stdlib.h"


#include "SDL/SDL.h"


using namespace std;


int main(){


SDL_Init(SDL_INIT_VIDEO|SDL_INIT_TIMER);


SDL_Surface* dis=SDL_SetVideoMode(200,200,24,SDL_SWSURFACE);


//SDL_Surface* dis=SDL_SetVideoMode(200,200,24,SDL_SWSURFACE|SDL_NOFRAME);


SDL_Event game;


SDL_Rect playersprite,background;


Uint8* key;


int quit=0;


Uint8 r=255,g=255,b=255;


int currentTime,oldTime,framerate = 15, framemillisec;


cout<<framemillisec<<", "<<currentTime<<", "<<oldTime<<endl;


int xp=80,yp=80;


int change_color=0,change_color_pressed=0;


//set the dimensions of the playersprite and backgorund window rectangle


background.x=0; background.y=0;


background.w=200; background.h=200;


playersprite.x=0; playersprite.y=0;


playersprite.w=40; playersprite.h=40;


//seed random number generator


srand(currentTime);


framemillisec = 1000/framerate; // calculate frame delay in milleseconds based on desired framerate


oldTime=SDL_GetTicks(); //initialize first timestamp for framerate calculation


while (quit==0){


// while (SDL_PollEvent(&game)){}


SDL_PollEvent(&game);


key=SDL_GetKeyState(NULL);


if(key[sDLK_q]){quit=1;}


if(key[sDLK_a]){change_color=1;}else{change_color_pressed=0;}


if(key[sDLK_UP]){yp-=2;}


if(key[sDLK_DOWN]){yp+=2;}


if(key[sDLK_LEFT]){xp-=2;}


if(key[sDLK_RIGHT]){xp+=2;}


if(xp<0){xp=0;}


if(xp>200-40){xp=200-40;}


if(yp<0){yp=0;}


if(yp>200-40){yp=200-40;}


playersprite.x=xp; playersprite.y=yp;


if(change_color==1&&change_color_pressed==0){


r=rand()%255; g=rand()%255; b=rand()%255;


cout<<"R = "<<(int)r<<", G = "<<(int)g<<", B = "<<(int)b<<endl;


change_color_pressed=1;


}


change_color=0;


SDL_FillRect(dis,&background,SDL_MapRGB(dis->format,0,0,0));// CLEAN THE SCREEN.


SDL_FillRect(dis,&playersprite,SDL_MapRGB(dis->format,r,g, B) ); // Draw player rectangle


SDL_Flip(dis);


// Pause execution until next frame is finished


currentTime=SDL_GetTicks();


// cout<<framemillisec-(currentTime-oldTime)<<", "<<currentTime<<", "<<oldTime<<endl;


if(currentTime-oldTime<framemillisec) {


SDL_Delay(framemillisec-(currentTime-oldTime));


} else


cout<<"game too slow for desired framerate"<<endl;


oldTime=SDL_GetTicks();


}


SDL_Quit();


return 0;


}

game.zip
 

Attachments

  • game.zip
    1.2 KB · Views: 137
Last edited by a moderator:
I am thinking this thread is going from a GENERAL thing about coding competitions...into discussion about a VERY SPECIFIC program.

Perhaps you guys should keep this up in a PM and let this topic go back to general about coding competitions...or I can break it off into a different topic for you.
 
I think there was some discussion to turn it into an Article.. Binky is working on it.
 
Current next step is finding out what Mjohansson thinks of the idea (also see thread in mods' area)
 
Oh and mjohansson, reducing the bit depth to 16 doubles the speed I get here


SDL_Surface* dis=SDL_SetVideoMode(SCREENX,SCREENY,16,SDL_FULLSCREEN|SDL_DOUBLEBUF);
 
:D

The framerate function wasnt broken, but it wasnt explained either I can understand how it must look, that I wanted a framerate of 10 fps... But its the value I divide with 1000, that means framerate in this case would be 100fps! I didnt see that, cos screen refresh on Pandora is supposed to be limited to 60 fps, so my value should have been 16. I used to have a comment after that, and its a prime example of naming a variable wrong and missleading, and the problem of copy/pasting code instead of rewriting it, obviously that comment had fallen off sometime after a billion different copy/paste into many source codes.

But Im not sure about the double in framerate after using 16bit color, I cant remember specificly but I think someone said SDL used to be twice as quick with 16bit color before they updated to a new version of SDL were something was fixed? Are you compiling with a new version of CDEVTOOLS or are you using an older version or an old SDL with crosscompiler?

I like the idea of an easy to find article, but then we can use this thread to create the best possible version, cos Im doing a lot of errors and bad things, not to mention spelling errors. Anyone who would like to be a part is welcome to change the text in any way to make it better, its meant to make anyone be able to understand WHY things work they way they do because of the hardware, and WHAT terminology refers to in terms of hardware. I think most guides try to teach C++ as if it were a high level language and people had no idea what the hardware is or how it works, I find abstract languages frustrating and difficult, wich is why I feel strongly for a different approach. 

But I didnt learn with the official C++ webpage tutorial, I find that one to be exceptionally good, mayby much better then my attempt anyway, I only found that there was tutorials and information available for free on the internet after I started looking for awnsers to questions I didnt find in my book. I think it might be true for many others aswell that they wouldnt expect good tutorials to be found free on the internet, considering everyone is always recomended some fat brick of a book that cost 9999 dollars to purchase, and then ends up being very complex and still not explain how things relates to the hardware and why...
 
Also klapse, youre putting things into the code wich dosnt have to be there, like playersprite and background for example, this way of doing things is something the person trying to learn can figure out on their own later, in the beginning here and now it only obfuscates things and adds confusion, the most simple direct relations are the best clarity and therefor easiest to figure out how they work and why.
 
Also klapse, youre putting things into the code wich dosnt have to be there, like playersprite and background for example, this way of doing things is something the person trying to learn can figure out on their own later, in the beginning here and now it only obfuscates things and adds confusion, the most simple direct relations are the best clarity and therefor easiest to figure out how they work and why.
It does not make sense to redefine the width and height of "temp" every time you go through the loop. Splitting the temp variable into background and playersprite makes the code more readable, since it is clear to the reader what each variable MEANS, plus it runs faster, since you do not needlessly reinitialize the temp variables to two different constants during every game loop.

Look at other changes as well. For e.g., your empty while loop for getting sdl key events:


while (SDL_PollEvent(&game)){}


Normally you would put your input key processing within the brackets http://sdl.beuc.net/sdl.wiki/SDL_PollEvent , but since we are only interested in keypresses, we can simply eliminate the while loop and grab the first keypress off the stack.


Also, I wrap all tests for keyboard input into if (game.type == SDL_KEYDOWN) { ... }, this way there is no wasted processing every game loop when no user input is pressed.


SDL_PollEvent(&game);


if (game.type == SDL_KEYDOWN) {


key=SDL_GetKeyState(NULL);


if(key[sDLK_q]){quit=1;}


if(key[sDLK_a]){change_color=1;}else{change_color_pressed=0;}


if(key[sDLK_UP]){yp-=3;}


if(key[sDLK_DOWN]){yp+=3;}


if(key[sDLK_LEFT]){xp-=3;}


if(key[sDLK_RIGHT]){xp+=3;}


if(xp<0){xp=0;}


if(xp>SCREENX-PLAYERW){xp=SCREENX-PLAYERW;}


if(yp<0){yp=0;}


if(yp>SCREENY-PLAYERH){yp=SCREENY-PLAYERH;}


playersprite.x=xp; playersprite.y=yp;


if(change_color==1&&change_color_pressed==0){


r=rand()%255; g=rand()%255; b=rand()%255;


cout<<"R = "<<(int)r<<", G = "<<(int)g<<", B = "<<(int)b<<endl;


change_color_pressed=1;


}


change_color=0;


} // end if SDL_KEYDOWN


Hope you don't mind some constructive feedback.

game.zip
 

Attachments

  • game.zip
    1.1 KB · Views: 128
Last edited by a moderator:
Unless youre running it on a C64 I dont think the speed difference will be even measurable at all. 

And I still think its a bad idea for a learning program to complicate the logic, the person trying to follow what goes on will be able to figure out how to improve it design wise for easier programming, its part of building experience. Let everything be as bare and clean as can be here. 

The while loop I missed, again by copy/paste, but I removed a line from it, I guess it never occured to me that the while itself wasnt needed.
 
But it is wrong to teach people to waste cpu when, by simply rearranging code, cpu is not wasted. It is important to think about what you are asking the cpu to do. If you are asking it to repeat the same calculations for no purpose, this is wasteful and shouldn't be taught in a tutorial, because this teaches bad coding. It doesn't really matter if the waste is small in this instance.


You are a beginner programmer who is writing code by cutting and pasting. I think you can learn a lot if you don't get offended by feedback.
 
Im not offended, I simply disagree.

I think this first graphics display goes through some functions and some of the basic needs of SDL to get things up and running, they will still be getting familiar with variable processing in the first place, this is something to build on and modify for experimentation. Its not here were you teach optimization or need to worry about good coding practise, its good coding practise thats the problem with most tutorials probably, its something that will come naturally with time anyway it dosnt have to be thaught unless saught after specificly, and it certainly dosnt need to be thaught at such a early stage.
 
FYI, the SDL_FillRect supports a NULL in the rect if you want to fill the screen. Then you only need to set the rect once - for the player sprite.

That's less complicated and less wasteful
 
Here is a really small game that I am trying to learn the code for. It gets about 140 fps on my N900.


http://olofson.net/mixed.html


"pig-1.0.tar.gz - 660k


Fixed Rate Pig was intended as an SDL programming example, to demonstrate the use of a fixed virtual logic frame rate together with interpolation, also known as "tweening". However, it turned into a (sort of) playable platform game, so it's more of a how-it-all-fits-together example."


mrjohansson are you interested in continuing your tutorial? maybe illustrate loading a bitmap and animating multiple sprites?
 
Back
Top