I''m reluctant to begin searching for a weird bug in my game that appeared when I downloaded a newer version of DJGPP and Allegro... That''s why I''m hanging around the boards

If I stay here long enough, them maybe I''ll join the squabble to give out useful HTML information to newcommers the fastest as well!!! Thanx guys.

thx for all your responses.. could we get a little bit back on topic but?

anyway, what i was doing exactly was this:

    //main loop://draw background//get input//draw objects//calculate fps and amount to move objects by, which looks like this:int CClock::CalcFPS(){	//this function ends the frame and calculates the FPS	if(this->Frames & 999)	//dont update every frame	{		//Recalculate the FPS		this->TotalTime		= GetTickCount() - StartCount;		this->FPS			= this->Frames * 1000 / TotalTime;		//Recalculate FrameTime - amount to move objects by		this->FrameTime		= (this->FrameTime + (GetTickCount() - this->StartFrameTime)) / 2;	}	this->Frames++;		return 1;}    

could someone shed a bit more light on threads? i''ve never used them before..



and im still trying to figure out #2 (smooth scrolling), what thrump said seemed a little vague(although it is 10 to 4 in the morning )

anyway, back to #1, is what im doing ok?
it doesn''t seem right somehow..

To clarify answer for #2:

In main memory I have a 2D array of numbers, like this
000000020
000111000
000101000
000111000
000000000

0=grass
1=wall
2=whatever

now, I have a buffer slightly bigger than the screen resolution, (bigger by one tile to be exact)

let''s say our resolution allows us to display a 3x3 tile array on the screen. my buffer would be 4x4 tiles big. So, if bigX was 1 and bigY was 1, I would bitblt the following to the buffer.
0011
0010
0011
0000
(do you see where I''m starting in my big 2D array?)
(these are actual graphics, not number representations...)

If smallX is 5, I bitblt 3*tileSize x 3*tileSize size area to the screen, with my sourceX in the bitblt call set to 5. Now if the player moves to smallX 6 (very small move, only one pixel), I bitblt with sourceX = 6. When the player reaches sourceX == 32, sourceX becomes 0 and bigX becomes 2. (it was 1 before)

then I have this in my buffer
0111
0101
0111
0000
but smallX is 0, so when we blit it looks smooth...

(ie,
smallX=32
bigX=1
is the exact same thing as
smallX=0
bigX=2
)

if you need more instructions, just say so...

3. I''ll second Thrump''s suggestion here, a Linked list is the best solution. If you want to remove enemies out of the list (The player killed them or something) or add enemies (They were revived or something ) during run-time, using a linked list will make your life alot easier. It''ll take a while to get it working, but It''s worth it

2. Again, as Thrump said you need to basically calculate the offset of your position in the map.
Based on that offset, you determine what tiles need to be drawn on screen. If you need more help with this feel free to email me.

1. Your doing 10 * Clock.FrameTime / 100
That''s the same as doing Clock.FrameTime / 10
No?
Try Ksero''s idea about the acceleration, it might work.

One last thing, about threads
A thread is another "job" or "work" (however you want to call it) that runs in parallal with your program.
So you can do all of your stuff in the main loop, like moving the char, drawing the bitmaps and in the same time the thread will draw missiles on the screen.



- Goblineye Entertainment
The road to success is always under construction

Unless Ksero put a typo into his source for acceleration or left out some important details, it is not very usefull. He is cutting your acceleration in half.

The second this->YVel does nothing.

Try creating a standard initial y velocity. Then modify the initial y position by a fraction of the y velocity for the first frame. If you do not have a consistant initial y velocity, you can not possibly have a consistant max y position.

The choice of using a different thread or not is something that everyone needs to decide for their own game. Having a seperate thread simplifies the math, because you no longer need to use a variable timestep, but it introduces some complexities in terms of code, and making sure that everthing stays in locstep. For example, if you have your drawing code in the main loop, so that you draw as fast as you can but only update every 1/100th of a second, its entirely possible that in the middle of drawing the current frame, the locations of the objects will change (the other thread goes active and services the physics), causing an odd discontinuity in object locations. Attempting to lock out the other thread until drawing is done will reintroduce timing problems.

I believe most games are made single-threaded just to simplify the programming. For instance, in Unreal Tournament, you can tell that the netcode is not in a seperate thread from the game loop -- how? Because when the game takes a long time to render the graphics for a frame, your ping increases. This is very apparenty on a LAN, where 10ms pings are common, if the computer is slow and hits a complex scene the ping will easily jump into the hundreds of milliseconds until the time it takes to draw the scene again drops down. If the network code was on a seperate thread, it should respond much more responsively to a game packet. (IMHO, networking is actually a very good area to use multithreading in, as you want to acknolwedge the packets as soon as they arrive)

Argh, lost my previous responce to the god of bad internet browsers.

Ok, now on to how to jump: We''ll look at a jump as an instantaneous act, ie, your feet hit the ground like a hammer and change your momentum instantly. I would write your code like follows:

    If jump key is hit {  Yacceleration = GRAVITY; // this is a negative CONSTANT!  Yvelocity = JUMP_SPEED;  // JUMP_SPEED is a positive CONSTANT  jumping = 1;}If jumping {  Yposition += timestep * Yvelocity;  Yvelocity += timestep * Yacceleration;  If Hit the ground {    Yvelocity = 0;    Yacceleration = 0;    positionY = correctedgroundposition;    jumping = 0;  }}    

Notice how the actual act of jumping is instantaneous, and thus does not have any timestep correction -- only the physics that occur over time will have a dT (timestep) term.

That does bring up a thorny issue though -- that is, we''re integrating extremely simplistically, and thus this only approximates the actual movement. If you look at this code, and plug in a bunch of different timesteps, you''ll find that the velocity will always be correct, but because the position varies on the velocity, and often it might be acting on an inaccurate velocity, the position may get a fair bit off for a high timestep. Despite what I said a second ago about multi-threading , I think you might indeed be better off doing that than attempting to come up with a better numerical integrator. Or, you can chop your timestep down, by looping a few times within the frame with a timestep half or a quarter of the total frame time. This will drastically improve the accuracy, and make it so that they all will behave pretty similar. This is probably the easiest solution. So you''d do something like :

If jumping {
for (i = 0, newtimestep = timestep/4; i < 4; i++) {
Yposition += newtimestep * Yvelocity;
Yvelocity += newtimestep * Yacceleration;
}
...

although if you''re doing any heavy-duty calculations, this can get a bit ridiculous.

Let me know if it helps!

oh, and to Antknei:

I think that code was an attempt at a better integrator -- do half of a timestep, updatelocation, then do the rest. So its not incorrect per se.

I believe that you are right Anonymous that there was an attempt to make a better integrator in Ksero''s post, but his code snippet is not correct.