I've been moving some code around, rearranging stuff so that my game runs at the correct speed, regardless of the machine. While working on this, I stumbled upon a problem.

I make use of a counter that updates the screen at the refresh-rate, and I moved some blits into the function that is associated with that counter. But my screen was acting funny, so I figured out that I had two copies of the blits and forgot the delete the old ones. So to make sure nothing gets screwed up further, I comment-out the two lines that are my blits.

Now when I run the program, it seems to do it's normal thing, but there's something weird going on. When I move the player around, his Y velocity stays zero AT ALL TIMES. He can ride on air and never fall.

Now if I uncomment the two blits I have, suddenly the YVelocity works and the player becomes platform driven again.

Can anyone make any sense of this? Why is my YVelocity counter not working because of the original copy of the blits not being there? It's as if there's some memory problem and something is modifying my YVelocity counter without me telling it to...

With some code we will see more of your problem.
Post it using the Code Tags, and if it is a smart bug, perhaps somebody could help.

Well here's my timer function:

void RefreshUpdate(void)
{
    static int last_retrace_count;
    if(Closing == 0 && last_retrace_count < retrace_count)
    {
        masked_blit(objPlayer1.Layer, objPlayer1.LayerB, 0, 0, 0, 0, X_RESOLUTION, Y_RESOLUTION);
        masked_blit(objPlayer1.LayerH, objPlayer1.LayerB, 0, 0, 0, 0, X_RESOLUTION, Y_RESOLUTION);
        blit(objPlayer1.LayerB, screen, 0, 0, 0, 0, X_RESOLUTION, Y_RESOLUTION);
        clear(objPlayer1.LayerH);
        last_retrace_count = retrace_count;
        Refresh++;
    }
}
END_OF_FUNCTION(RefreshUpdate);

And here's where I've setup the counter and such in the main() function:

LOCK_VARIABLE(Refresh);
LOCK_FUNCTION(RefreshUpdate);
install_int_ex(&RefreshUpdate, BPS_TO_TIMER(/*get_refresh_rate()*/70));

And here's the section of code there I commented-out two blits (because I put them in my timer function):

if(CompMode == 0)
{
    while(Tic == 0);
    Tic = 0;
    ++FrameTic;
    //masked_blit(objPlayer1.Layer, objPlayer1.LayerB, 0, 0, 0, 0, X_RESOLUTION, Y_RESOLUTION);
    //masked_blit(objPlayer1.LayerH, objPlayer1.LayerB, 0, 0, 0, 0, X_RESOLUTION, Y_RESOLUTION);
}

And as for what changes the YVelocity variable, that's in my CheckTopCollision function. I would show you that, but the code is on my other computer right now and that's a lot to retype, and because there's a lot to it, I make use of a lot of code that probably wouldn't make any sense to anyone (lots of math specific to the collision detection and engine). But at the moment at least, I can tell you that the function does update the YVelocity and is in no way associated with the timer I created.

I should note that the YVelocity variable is part of the objPlayer1 structure which has many other variables, including the Layer, LayerH, and LayerB bitmaps.

I should also note that while trying some profiling by adding the -pf option to GCC, I found that the YVelocity wouldn't update then either... unless I gave one of my variables a 'register' class type. I don't know why, but somehow 'int' made YVelocity always zero and 'register int' made YVelocity work just fine.

I've never seen anything like this before. If anyone still doesn't know by the time I can get my code over to this computer, I'll post it here and hopefully we can go from there.

Move the blitting code out of the timer function! Actually, the timer function should be as short as possible.

Apart from that, did you make sure the timer will be installed after a gfx mode is set and all bitmaps valid? On a similar note, did you make sure that the timer will stop executing once either gfx mode is reset or any of those bitmaps destroyed?

Mind that last_retrace_count is uninitialized!

But don't bother about these things, because you should really move the drawing stuff out of your timer.

There is a reason ...

Well I understand everything you've said, but I want to disagree that that has anything to do with what's causing the problem, because as I mentioned, the YVelocity remained zero in the case where I used the 'pg' option to compile/link, unless I made one of my int values a 'register int'. Then suddenly YVelocity would change like it was supposed to. So I'm not really seeing how it would explain that.

To confirm some thing, the 'Closing' variable is initalized at -1 until I get my bitmaps and such loaded, then it is set to 0 so that my timer will work. When I begin shutting down, it is set to 1 so that it won't try to blit while closing allegro and deleting the bitmaps from memory.

It's perhaps some brackets you have badly positioned ?
Attach a zip file with the whole code, and if you want i'll give it a test and post my feedbacks/error founds/ if there are any.

Alrighty, I finally got around to getting some files uploaded.

Complete engine:
http://www.shadowsoft-games.com/saxman/Engine.zip

MAIN.EXE source code:
http://www.shadowsoft-games.com/saxman/Code.zip

The only file I excluded from Engine.zip was a file called NewDrug.ogg. I am not sure if the engine will run without this file or not... if not, you can just grab any random OGG file and put in it's place.

Also, I'll tell your ahead of time that I'm a sloppy coder. I took about 20 minutes commenting several parts of my code to try and make it easier to understand, but I don't know if that was enough. I also realize that half of the code should be split up into several source files -- I'm not very good about getting that to work for some reason (I don't know much about linking one source file to another), so I've been holding off on that and working in one file for now.

I moved the blits out of the timer since that seemed to improve performance a thousand-fold anyway, and although the YVelocity works now, it still stops working under specific conditions:

- When I compile the source using the "-pg" option
- When the steel reinforcement object comes into view (you'll know when this happens because the player will glide on air)

In fact, you can use Object.exe to delete the steel-reinforcement object out of the level, and you'll see that the YVelocity suddenly works again.

Oh, and one final note -- when you load the engine, it will ask for what I call a 'prefix'. Just type "EHZ" (without the quotes) and press enter. It should work just fine. Otherwise, it will give you an error saying files can't be found.

I have download the whole thing and i'm under testing.

EDIT: For sure it's strange, but it's for sure something inside the code !

I smell faulty dealing with memory (this would be my first guess), but I haven't looked at the code, so I can't tell for sure (obviously ).

Anyone happen to have any ideas yet? I know Gull was under testing. I agree that it's probably a memory leak of some sort. I just wish I could figure out what I did wrong >_<