Yeah, sorry for hijacking the forum once again. But I'm reaching the end of my term, hence different threads for different topics.

I'm a total noob at the frames per second topic. In fact, I have looked at old threads here and followed a tutorial in implementing a timer and all. Thing is, I'm getting a rate of 7-8 frames per second when I move my character. I'm displaying a simple background with scrolling, one enemy moving on its own, and my character through keyboard input.

I'm using my laptop, for which the screen resolution is set at 1920x1200.

I followed this example code in implementing my timer: http://pixwiki.bafsoft.com/mags/12/articles/pong/article.html

I'm gonna show part of my code, maybe I'm doing something obviously wrong?

I know there are a few things I could put in other functions, but making the code neat is my priority after I'm done with this fps part.. unless you guys think it's highly inefficient. This is my first time tackling game programming, and if I had more time, I would've been able to restructure my code; unfortunately, I'll only get to do this after class is over.

Anyway, tia. And no making fun please

Yes. Several. On my first and only skim through that (see item #1 on the list why I won't read it again).

1) For the love of God, choose descriptive variable names!
"if a == 0"?
"if i == 4"?
Gah!

2) You're mixing drawing and logic.

3)

Overriding the existing key[] - not a good idea. Dump the entire keypressed()/readkey() stuff and use the key[] array.

4) Move the "game_time--" out of the ifs.

5)

Even if that executes with no additional slowdown, that alone would give you a theoretical maximum FPS of 14.

6) You're mixing drawing and logic.
Yes, this deserves to be mentioned at least twice.

7)

...
What?

rest(70);

Have you tried decreasing this number? Also, using OpenLayer instead of just Allegro really helps with fps, as it uses hardware (your video card) for processing.

This line: while(game_time<0) ; Should never stop. When game_time gets to 0 it will get out of that big loop, then it hits this line. Well game_time will never be less than 0 as for it is 0.

No, that utterly bizarre loop will never start.

Haha yes woopsies on my part.

Oh and to red-dragon regarding gnolam's post about "descriptive variable names!" Try using:

#define SOMETHING 4
#define NOTHING 0
...
     if(i==SOMETHING)
     {
          i= NOTHING;
          enemy_dir();
     }

See, you can actually read that logically. Get in the habit of saying your code out loud. "If i equals something then set i to nothing then call the enemy direction function."

For starters :
1. Increase cfps only when you blit to the screen.
2. Decrease game_time only when you blit to the screen
3. What is the rest(70) for?

Not sure how much difference this will make to the overall game speed, but it may provide a more accurate FPS figure.

hey everyone,
thanks for the critiques I know I used some horrible variables and I have a LOT of globals, but it's mainly for debugging purposes. Horrible variable names are created from lack of sleep and staring at code for hours. Hey, it's hard for us beginners

Now, I took a step back and remembered that the GPAIO book had a chapter on timers... so now, it seems to be working ok. I had a LOT of rest() that I commented out. The game is running like it's on steroids. What if you want the character to m ove at a slower/faster pace than... the enemy?

Umm, no? Decrease game_time once per logic loop. Drawing shouldn't be anywhere near loic.

Now as for the timing, just set up a nice timer controlled game loop, then you can control the rate at which the characters and enemies move.

For a fixed-time game, (that is, a game where you want the framerate to be specific, like 15, 30, 60, etc.), you generally figure out the framerate you want, then base all the movement speeds of your players, enemies, etc. on their own speed. Thus the player might move 2 pixels a frame, enemies might move 1 pixel a frame.

Beyond that, what you need to do to fine-tune the movement speeds between things is to add either floating point variables or bit-shifted movement. Floating point is easier, bit-shifted is somewhat faster (though the difference is not as pronounced anymore as it once was.)

With floating point, everything has a decimal value, so you could assign a number to have a value of 3.7698, or 1.87658100647, or just plain 5.0. When you move an object, you can then move in smaller increments than a single pixel, such as:

myFloat += 0.25;

Bit-shifting is a little harder, but faster, and doesn't force you to do floating point arithmetic. Basically, with bit-shifting, you are deciding ahead of time how many increments should be between each pixel, and then your positions are decided accordingly, but you must use powers of two. For instance, if you want 64 increments between each pixel, that would be 2 to the power of 6, so you bit-shift by 6 whenever you draw something to the screen.

In this scenario, something at coordinates 640,384 is actually at pixel coordinates 10,6, because your drawing operation looks like:

draw_sprite(buffer,mySprite,spriteX>>6,spriteY>>6);

And by having the larger numbers you can now move objects with more precision. You just have to remember that if you want to set something based on pixel coordinates, you have to bit-shift the other way. For instance, if you want to place something at pixel coordinates 40,87 you would do:

spriteX = 40 << 6;
spriteY = 87 << 6;

The reason you use bit-shift operators ( << and >> ) instead of multiplication ( * ) is because multiplication is much slower in terms of CPU time.

Note though that you cannot bit-shift floating point numbers, only integers.

--- Kris Asick (Gemini)
--- http://www.pixelships.com

I know it's important, as everybody says it, but what is actually wrong with mixing drawing and logic?

Because, you (should) run the logic at a fixed rate and draw in the free time. If you mix it, you have no way of controlling the speed of the logic, as you then depend on the frame rate.

Oh, I see.

Err, yes, correct. I wasn't thinking properly when I wrote that bit.

Kris Asic,
thanks man. I was looking fora nice detailed explanation like that

Now, I had set my game to about 30 frames per second. Now, I do want to base the movement of my enemies around that. I think my player will be ok.

Now, for enemy movement, I incremented it by a float inc = 0.25;
So, if enemy is going right, enemy->x += inc; But this means that now I have to change the int x, y (coordinates for enemy) to floats too, right? Or it might get truncated. Anyway, even an slight increment seemed too fast.

For my temporary fix, I've made a new variable, which is incremented and decremented each game loop from 0 to 1. Then if it's 1, I update the enemy movement. It seems to slow the movement a bit more, so I'll be tweaking this.

I'll have to reread about bit shifting, I've never done it. I believe there was a project regarding this in one of my courses, and I didn't get to do it

Anyway, thanks for the post, and let me know if something here I said is wrong. Actually, thanks to everyone

Kris,

I'm not sure if I completely follow the bit shifting explanation. Here's my understanding so far. I'd appreciate if you (or anyone who does understand it properly) can comment:

Still with your example of 64 increments between pixels, if the movement is updated 128 per second, after one second the co-ordinates have changed by 2 pixels (assuming there's a continuous updating of co-ordinates).

Would that mean the right most position for a 640x480 screen will have an x component of 40960 (640*64)?

If you want one object to move at twice the speed of another, you bit shift one more (i.e. x_postion << 7 or x_position >> 7)?

And if you want something to move at 1.5 times normal, you'd bit shift by 6 and then add the original value bit shifted by 5?

Or am I totally off the path and down a cliff?

hmm,
ok, while I've been successful at slowing down the enemy, I can't seem to do it for link.

i.e. when attacking (spacebar), updateattacksprite() is called, where the proper frames are updated and then displayed.

To slow down enemy, here's exactly what I did (this is main at the moment):

        enemy_delay++;
        if(enemy_delay==5)
        {
                       update_enemy_sprite(green_plant);
                       checkcollisions();
                       move_plant_enemy();
                       enemy_delay = 0;
                       draw_enemy();
        }

Ok, so it slows down the enemy.

So, I tried something similar with link's updatespriteattack().
First, original code:

else if((key == 1) && (a != 0))
{       
             a--;
             updateattacksprite(link);
             draw_link();  
                           
             //attack();
}

Ok, yeah, I know a is a horrible variable name, let's get past that though.

Ok, modifying it like I did with enemy...:

The point is for the frames to move by slowly. It happens so quickly that all I see is the last frame. Even with this code. Notice though, there is no move_character() here because he doesn't actually move..... only frames change. Hope that makes sense.

Any suggestions?

EDIT:
With the if(attack_delay == 4) modification, link also flickers now.

red-dragon: You don't have to do all that. Remember that you can make floating point values as small as 0.000000001, or more. Sometimes you'll need to go that low to really see any differences. (Maybe not that low, probably close to around 0.001.) And yes, if you use floating point for one thing you pretty much have to use it for everything else that's related.

HardTranceFan: You've pretty much got it, except you only ever need to bit-shift when drawing to the screen and when setting to pixel-coordinates. For everything else, you treat it as its own coordinate system with no bit-shifting.

--- Kris Asick (Gemini)
--- http://www.pixelships.com

Kris Asick,
Will go back and go with a really low floating point number. That post I just made; I put in debug statements and realized that the updatesprite wasn't correct.... so now, I can see that all the frames ARE coming into play.

------------------------
Ok, just did more debug statements for variable a. The debug statement reveals that a starts as 10, as intended, then when spacebar is hit, it goes to 9 and stays there no matter what. No wonder the frame animations aren't all "automatically" displaying.

Once again, relevant code, in main,:

I found out int which_key was being declared within the while loop, which meant that it was being declared every game loop, so I changed it as a global. However, the debug statement still shows after 10, it goes to 9 and then doesn't change. Does whichever key you pressed last get reset every game loop??

EDIT: Yep, which_key resets to 0 every game loop. Can anyone explain why? And what can be done about this, please?
Anyone? Someone? Helllloooo? <echos> heh. C'mon.

Think of it this way, red-dragon: If the keys didn't reset every frame, how would you know when someone let go of a key, or parse between hitting different letters to type something?

When you work with animated sprites, what you need to do is make those animations independent of your input handling. In other words, you probably want something more along the lines of this:

Thus while a = 0, no animation occurs, and then when you press the key you expect, a is set to 10, and while a is over 10, regardless of if a keyboard key is pressed, a decreases until it finally returns to 0.

--- Kris Asick (Gemini)
--- http://www.pixelships.com

Hi Kris,
Appreciate your help. I woke up this morning and had a similar idea. So, I have it like you suggested, but something is still not right. I will show relevant code first:

Ok, so now with your help with code, I have this:

updatespriteattack... I only have sprites for attacking up and down, not left and right..YET. So, up and down attacks both have 5 frames. Hence, a = 5 when spacebar is pressed in main while loop.

restore_frame... after the whole 5 frames, it is called. If before sword attack, Link's previous direction was, say, 4 (down), then his normal south (without holding a sword) frame appears.

What are the problems?
Little bug 1: It seems that hitting spacebar sometimes does not yield 5 frames necessarily; I know this because sometimes his last frame is, say frame 13 or 19, instead of them being 16 and 21. I don't know why this is happening, but it doesn't look good. He seems to start/stop on whatever frame.

I fixed something else as well. I have one more "bug" after this, but this has to be resolved first. TIA.

You know, there is a point where you should be resolving your own problems and I think you've reached it for now. Experimentation will be a much better guide now than me telling you what to do because you're on the right track and I don't want to derail you with my own style of coding.

There are bugs in your code as you posted, but you should be able to spot them easily with a bit of scrutiny. One is in your IF statements, the other has to do with the fact that you are tracking TWO animation frame variables to do just one animation. (Use "a" or "spr->curframe" to time your animations, not both.)

The only other piece of advice I have for you is to eventually separate all your animations into separate arrays, then have your sprites simply run a pointer to the animation you want to use. Pointers are something you're going to have to really learn sooner or later to get the most out of C or C++, and once you understand them, things like animations will become a whole lot easier.

--- Kris Asick (Gemini)
--- http://www.pixelships.com

Kris,
Regarding "You know, there is a point where you should be resolving your own problems and I think you've reached it for now. Experimentation will be a much better guide now than me telling you what to do because you're on the right track and I don't want to derail you with my own style of coding."

I didn't mean to come off as "here's my problem, fix it and tell me". I'm catching quite a few bugs myself and sometimes silly stuff is escaping me. That is all.

i like to do it like this.
linkdelay = 10;
npcdelay=20;

link will move twice as fast as the NPcs

Don't worry, you're not coming off that way. I'm just saying that not every problem has an immediate solution and that it may be more helpful to you to figure that particular problem out yourself.

For instance, there have been times when I've spent half an hour or more trying to solve a bug only to realize that all I had to do to fix the problem was change a '+' to a '-'. One of my friends once spent two hours on that exact same problem actually.

Sometimes the simplest problems are also the hardest to find and the search can be a good workout because it helps you learn to find that same kind of mistake again if you happen to make it again in the future.

--- Kris Asick (Gemini)
--- http://www.pixelships.com

In those situations, you end up going through your code with a fine tooth comb, refining bits and pieces, and on the whole making the whole program more efficient and stable.

HardTranceFan,
yes, you're right. I'm finding little things that need to be fixed