Yeah, in QBasic I didn't understand subroutines, so I used them purely to seperate my code (everything was global).

Good job on the completed game! Don't try this anything too big, though, though I made a whole platform engine in Qbasic without ever making a function.

EDIT: You will want to have time-based movement. Search it.

I was told SDL_framerate would take care of that. It will make sure each loop is the same length and if it goes too long one time, it make the next one shorter. The only time it isn't the case is if the CPU can't keep up with drawing.

Quote:

Original post by Daniel MillerEDIT: You will want to have time-based movement. Search it.

SDL_framerate locks the framerate. Time-Based movement moves all objects by a certain amount depending on how much time has passed.

Say you want to move an object 1 pixel every millisecond a certain key is pressed. Then in your game loop you would do something like:

int dx = 0;
while(Game_Not_Over)
{
start_time = Get_Time();
....
//Time to move objects
player->Move( dx );// <-- 1*dx Pixels per Frame Here, but it could be Anything*dx
//move other objects by a certain factor
end_time = Get_Time;
dx = end_time - start_time;
}

Now if the computer took 10ms to run that frame, then the object would move by 10px. If the computer took 20ms, then it would move by 20px. This way, over a given amount of time, an object will move the same distance on any speed computer.

The purpose to time-based movement, is 1) Smoother Framerate for fast computers 2) Allows slower computers who do not meet the ideal system specs to play your game 3) probably other reasons I can't think of right now

But that is what happens in min only in a defferent way. The loop will happen 100x per second so that's 1 frame every 10 miliseconds. Since the ball is always moving at 8 pixels in one direction or another I can say it moves 0.8 pixels per millisecond. And if it doesn't move like that, SDL_framerate will make up for it by making the next loop quicker or slower.

Quote:

Original post by Yamian But that is what happens in min only in a defferent way. The loop will happen 100x per second so that's 1 frame every 10 miliseconds. Since the ball is always moving at 8 pixels in one direction or another I can say it moves 0.8 pixels per millisecond. And if it doesn't move like that, SDL_framerate will make up for it by making the next loop quicker or slower.

For a simple game such as Pong, most people would not have any problem keeping up with the fixed framerate. However, imagine that a 500Mhz Intel Celeron is playing your Pong Game, and it consistently takes the CPU at least 100ms to process one frame of your game. SDL_framerate will never be able to make up for the extra time each frame. However, if your game is time-based, then instead of moving 8px, the Celeron would move the ball 80px per frame. However, locking the frame would cause the Celeron to move the ball only 8px each frame - resulting in a v e r y s l o w game.

I think that (for practical purposes), time-based is unecessary for your Pong-clone. However, if your making a game that is some-what CPU intensive and you want lower-end machines to be able to play -even if they suffer a choppy framerate- then time-based would most likely be the way to go. Do you understand what I was trying to say?

Sorry, I don't see that he had used that.

I suppose, I ran it on an old 98 that couldn't keep up with the drawing, pretty choppy.

Ran your pong game, its great so far, suggest keeping track of score, zoom out a bit, and add graphics to the interface, and maybe simple one player AI (ie, the right paddle moves as the balls y axis moves.


Functions have two uses, repeating commands, and organising code.


I use time keeping, instead of framerate locking: (Code by Marius of http://cone3d.gamedev.net/)



I'm wondering if its worth to also use SDL_framerate to keep the program running in time.

I'm now at version 0.5.3. I added score keeping!!! Again same link for source and for actual game.

Quote:

Original post by Citrus There are programs which will pack dlls into the exe file, but usually using one of these violates the license of most lgpl type libs (ie SDL).

That's not what the license text says. If you link against LGPL code, then you have to make available a link kit such that someone could re-compile the LGPL part, and re-link the executable, using whatever tools you used (i e, there's no rule the tools have to be free).

Thus, you could just put up all your EXE and DLL files in a separate "link kit" download, and include a make file or instructions for how to add the appropriate SDL DLL and run the tool to re-generate the final executable, and this would comply with the LGPL -- at least, that's what I've been told. I'm not a lawyer. If you want legal advice, you have to go ask one (and pay him money, no doubt).