No, you did not. No monitor money could buy can display such a high frame rate. 63fps is fine.
You might want to check your video card settings; if the refresh rate is set to 63 Hz, and you force vsync, then naturally 63 fps is as much as you will ever get.

You probably added an Allegro command in your code that's vsyncing. Some of the palette commands do that, as will page flipping code. Triple buffering will cap your framerate at the monitor refresh.

63 is probably a miscalculation too. It's more likely 60, as that's the refresh rate of many LCD monitors.

400 is unreasonable with a non-hardware accelerated Allegro application. All you have to do is add a few more graphical commands and that number will drop like a stone. And as was already said, no monitor on the face of this planet can actually show a framerate of 400. (The highest my monitor goes is 120 at 640x480 or lower, and most LCD's can only hit 60, 75 or 85 at 640x480.)

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

If you added any rest(1) statements, that could be it too. You could always try rest(0) instead. (Passing 0 to rest() is usually better. I used to do rest(1) instead to get around certain I/O issues, but I'm perhaps one of the only people to experience them and rest(1) actually degrades performance considerably on lower-end systems, so I'm not so concerned about that anymore.)

To find the maximum refresh rate capable of your video card, try the box it came in. If your video card came with the computer, finding out the limits may be trickier. One method you can try is to go to your advanced display properties and look for a combo box dealing with refresh rate. That drop down should show all compatible refresh rates of your video card + monitor for your current resolution.

In either case, if the framerate drop was immediately after compiling certain changes to your code, try commenting those changes out until you get your framerate back, then narrow down exactly what you're doing that's dropping the framerate.

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

I disagree. Higher FPS will decrease the program reaction time to my input. Also, as I see the true FPS, I can know the approximate FPS that a weaker computer would get.

I will try this program, thanks Tobias.

About the code: My project is attached.

ALL the function debuff()

FPS calculation for display:

The program is ~700 lines, too big to paste here. but is uploaded.. heavy because of images. Actually 1 image,which is the "about".

Attachment stuck at uploading, i will try again.
Upload successful

The program doesn't get threw compilation. (VS6)
D:\nvm\C\tst1\tweste.cpp(45) : error C4716: '_mangled_main' : must return a value

No, since you shouldn't be mixing logic and drawing.

I could.
Copy & paste the code into a file called "proggy.cpp" and do this:

g++ proggy.cpp -lalleg -o proggy.exe -W -Wall

What does it say?

...oh dear, forgot one tiny detail myself:

main() should of course return something.

I'd say you shouldn't be assuming.
In your example, you know that the current version of your code takes 10.1 ms per frame on the fast computer, and 30.3 ms on the slower one. However, you don't know where the bottleneck is. If for example the rendering is cheap on both machines (say, 2 ms and 6 ms respectively), and the flipping on the slower machine is expensive due to a very slow graphics card (1 ms and 20 ms), then doubling the rendering speed would decrease the frame time by 1 and 3 ms respectively, giving you 9.1 and 27.3 ms, or 109.9 and 36.7 fps.
Add to that possible non-linearities: For example, if your game needs 400 MB of RAM (just an example), and you run it on a decent machine, you have no problem, but run it on one that only has 512 MB, and some more apps running, you'll dive into swap space and kill performance.
So unless you know exactly what the individual components of the final figure are, you can't assume anything.

You are wrong. It doesn't work like this at all. Rather:

while (!end_of_game) {
  read_input();
  while (timer > 0) {
    logic();
    --timer;
  }
  if (must_redraw)
    redraw();
  else
    rest(1);
}

So what happens when you press a key is this:
- If the engine is currently rendering a frame, the key stays in the input buffer until drawing finishes.
- Input is read.
- Logic will be updated as often as necessary, and it will include the changed input.
- If necessary, the scene is drawn.

There is no additional delay here; the only delay is in the drawing, and there is no way around that. You can't read and process input in mid-frame, and it would be silly to do it, since you can't change the frame anyway.
The delay between your input and the actual visible response is always, I repeat, ALWAYS, something between input latency and input latency + frame time. You can't change input latency (and you don't need to, because it's typically so tiny you can't notice), and you can't change the mechanism.

Oh dear.
What's your compiler? Do you know how to fire up a console (a.k.a. "DOS box")?