Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » Magical number..

This thread is locked; no one can reply to it. rss feed Print
Magical number..
type568
Member #8,381
March 2007
avatar

The number is: 63.

It is the frame rate, of a game. A lot of games. THE game had been working at around 100fps. (fps limit was set to 96..). than it dropped to 63. And LOCKED, on any computer checked: 2.4, 3.0 x2(2 different systems), Duo 6600. I didn't change anything related to the frame rate in the game, i had this frame rate in some other visual "games".. (A twisting pentagram with circling palette i.e.).

Also, in a commercial game, Counter Strike (v1.6..) I had this issue(FPS locked at 63, and never went above this).

In all cases, the computers are using Nvidia graphic cards. 6600-7900.

I used this program to compare performance. In some cases i had above 400FPS. Not 63!!!

I don't know what to do.. I don't want 63FPS. I want more.

Thanks..

Tobias Dammers
Member #2,604
August 2002
avatar

Quote:

In some cases i had above 400FPS. Not 63!!!

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.

---
Me make music: Triofobie
---
"We need Tobias and his awesome trombone, too." - Johan Halmén

ImLeftFooted
Member #3,935
October 2003
avatar

Quote:

I don't know what to do.. I don't want 63FPS. I want more.

Less is more.

Kris Asick
Member #1,424
July 2001

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

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

type568
Member #8,381
March 2007
avatar

The monitor refresh is 75Hz. Of course, frame rate would drop if i add something more moving than a circle and few lines. I don't need 400 anyways, but i would like to have around 100. I did not add Vsync. In Counter-Strike Source, my frame rate is 80-300, depending on a lot of things, in fastest case above 300. I don't see see the refresh, which is above 75Hz, but higher FPS decreases delay- Faster program reaction time.

The only slow thing here, is an almost full screen blit, at a 32bit depth.

I am not worried about the performance of the game- it runs great, I just don't understand the phenomenon.

About video card refresh limit: where can it be, I tried but didn't find it.(Nvidia driver, pretty new..) Also, i am sure i didn't touch it.

The number is 63, I am sure. It calculates frame rate taking average of 10 frames.

Kris Asick
Member #1,424
July 2001

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

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

Tobias Dammers
Member #2,604
August 2002
avatar

Again, the physical retrace rate is the absolute maximum, no matter what any FPS counter tells you. If your monitor is set to 75 Hz, that is the fastest refresh rate you can ever get. If the FPS counter gives you higher results, you will not be able to see or feel the difference - because there is none. It's just a higher number, and it probably means that the game could run at that refresh rate in theory, if the monitor were able to keep up.

Quote:

The number is 63, I am sure. It calculates frame rate taking average of 10 frames.

Maybe post some code? How about this:

1#include <allegro.h>
2 
3volatile int sec_counter = 0;
4 
5void my_counter_func() {
6 ++sec_counter;
7}
8END_OF_FUNCTION(my_counter_func)
9 
10int main() {
11 int frames = 0;
12 int fps = 0;
13 int c = 0;
14 
15 allegro_init();
16 set_color_depth(32);
17 if (set_gfx_mode(GFX_AUTODETECT, 800, 600, 0, 0)) {
18 allegro_message("Error: Could not set screen mode!\n");
19 exit(-1);
20 }
21 install_timer();
22 install_keyboard();
23 
24 BITMAP* backbuf = create_bitmap(SCREEN_W, SCREEN_H);
25
26 install_int(my_counter_func, 1000); // 1 tick per second
27 
28 while (!keypressed()) {
29 ++c;
30 if (c > 255)
31 c = -255;
32 ++frames;
33 if (sec_counter) {
34 fps = frames / sec_counter;
35 frames = 0;
36 sec_counter = 0;
37 }
38
39 clear_bitmap(backbuf);
40 rectfill(backbuf, 200, 200, 599, 399, makecol(abs(c), 255-abs(c), 0));
41 textprintf_ex(backbuf, font, 10, 10, makecol(255, 255, 255), -1, "FPS: %i", fps);
42 blit(backbuf, screen, 0, 0, 0, 0, SCREEN_W, SCREEN_H);
43 }
44 destroy_bitmap(backbuf);
45}
46END_OF_MAIN()

Which frame rate does this display for you?

---
Me make music: Triofobie
---
"We need Tobias and his awesome trombone, too." - Johan Halmén

type568
Member #8,381
March 2007
avatar

Quote:

If the FPS counter gives you higher results, you will not be able to see or feel the difference

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.

1void timer_ms(void)
2 {
3 t568++;
4 }
5END_OF_FUNCTION(timer_ms)
6 
7//main, and keyboard input loop, the LOCK_ and all init
8 
9 while(!keypressed() && !mouse_b)
10 {
11 debuff(&settings,&t568);
12 move(&objects,&settings); //physics of the game
13 showme(&objects,&settings,&t568); //visual drawings to
14 //bitmaps
15 }

ALL the function debuff()

1void debuff(Settings* settings,volatile long* t) the delay..
2 {
3 blit(settings->sc_component, screen, 0, 0, 0,0,SCREEN_W,BOARD_END_LiMiT);
4 if(settings->menu!=0)
5 {
6 blit(settings->sc_menu, screen, 0, 0, 0,BOARD_END_LiMiT,SCREEN_W,SCREEN_H);
7 settings->menu--;
8 }
9 clear_to_color(settings->sc_component,makecol(BGR,BGG,BGB));
10
11 int tmp=SEC/FPS_MAX-(int)(*t-settings->tracker);
12 settings->tmpfps=tmp-SEC/FPS_MAX;
13 if(tmp>0)
14 rest(tmp);
15 settings->tracker=*t;
16 }

FPS calculation for display:

1if(settings->show_fps)
2 {
3 if((settings->cnt++)%DiSPLAY_FPS==0)
4 {
5 settings->current=settings->current1/DiSPLAY_FPS;
6 settings->current1=0;
7 }
8 if((*t-settings->fps)>0)
9 {
10 settings->current1+=1000/(*t-settings->fps);
11 settings->fps=(*t);
12 }
13 textprintf_ex(settings->sc_component,font,1,1,makecol(FPSR,FPSG,FPSB),0,"FPS %d",settings->current);
14 }

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 :)

Quote:

Which frame rate does this display for you?

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

Tobias Dammers
Member #2,604
August 2002
avatar

Quote:

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.

Not true. It is physically impossible to display more frames than your monitor can handle, therefor the minimum reaction time to user input is always 1 / retrace_rate. If your monitor is set to 75 Hz, you always wait at least 1 / 75 sec, which, by the way, is way below the human time slice (13.3 ms; we humans consider everything happening within ~20 ms to be simultaneous).
Drawing more frames than what your monitor can handle is nothing but a waste of cpu time, and in extreme cases, it will DECREASE the program's responsiveness.

What you really want to do is separate logic from drawing, and use the extra time for logic.

For the profiling part, the FPS on a fast computer doesn't say much about that of a slower computer, because a number of factors go into the equation. If a 2000 MHz CPU can render 400 fps, that doesn't automatically mean that a 500 MHz CPU can do 100. The only way of knowing is to test.
Also, you might want to use a high-resolution timer, and profile the various parts of the game (input, logic, rendering, flipping) independently so you know where your bottlenecks are.

---
Me make music: Triofobie
---
"We need Tobias and his awesome trombone, too." - Johan Halmén

gnolam
Member #2,030
March 2002
avatar

Quote:

I disagree. Higher FPS will decrease the program reaction time to my input.

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

--
Move to the Democratic People's Republic of Vivendi Universal (formerly known as Sweden) - officially democracy- and privacy-free since 2008-06-18!

type568
Member #8,381
March 2007
avatar

Oh, thanks about the info. I couldn't compile your program. About FPS compare: If i checked it already, and 1 computer does 99 fps, other 33. I assume that improving the frame rate to 120 on the fast, would improve to about 40 on the slow..

Of course, there are a lot of factors except for CPU.. i.e. FSB of the CPU, as well as ram buses, and dual channel technology.

I shouldn't but i did. I don't get the connection though. I'll try to separate that.
By the way, the visual frame rate calculation at my opinion is in the right place, since it's the visual part of the program.

Tobias Dammers
Member #2,604
August 2002
avatar

Quote:

I couldn't compile your program.

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:

1#include <allegro.h>
2 
3volatile int sec_counter = 0;
4 
5void my_counter_func() {
6 ++sec_counter;
7}
8END_OF_FUNCTION(my_counter_func)
9 
10int main() {
11 int frames = 0;
12 int fps = 0;
13 int c = 0;
14 
15 allegro_init();
16 set_color_depth(32);
17 if (set_gfx_mode(GFX_AUTODETECT, 800, 600, 0, 0)) {
18 allegro_message("Error: Could not set screen mode!\n");
19 exit(-1);
20 }
21 install_timer();
22 install_keyboard();
23 
24 BITMAP* backbuf = create_bitmap(SCREEN_W, SCREEN_H);
25
26 install_int(my_counter_func, 1000); // 1 tick per second
27 
28 while (!keypressed()) {
29 ++c;
30 if (c > 255)
31 c = -255;
32 ++frames;
33 if (sec_counter) {
34 fps = frames / sec_counter;
35 frames = 0;
36 sec_counter = 0;
37 }
38
39 clear_bitmap(backbuf);
40 rectfill(backbuf, 200, 200, 599, 399, makecol(abs(c), 255-abs(c), 0));
41 textprintf_ex(backbuf, font, 10, 10, makecol(255, 255, 255), -1, "FPS: %i", fps);
42 blit(backbuf, screen, 0, 0, 0, 0, SCREEN_W, SCREEN_H);
43 }
44 destroy_bitmap(backbuf);
45 return 0;
46}
47END_OF_MAIN()

main() should of course return something.

Quote:

I assume that improving the frame rate to 120 on the fast, would improve to about 40 on the slow..

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.

---
Me make music: Triofobie
---
"We need Tobias and his awesome trombone, too." - Johan Halmén

type568
Member #8,381
March 2007
avatar

Oh, all right. Thanks for the info again.

Now, about the input.. If the input from the keyboard is read at the frequency of 75Hz. (monitor's refresh rate..)

Than, for my program to react to my input, it needs:

1) Input.
2) wait for the moment to get the input to the read buffer.. (what did Tobias mean input can't read faster than refresh rate?)
3) wait until end of my game loop, to take the input.

Now 3), is affected by the fps, if it's 400 will be faster than 75.. Am I wrong?

Quote:

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

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

Do this where? :|

Tobias Dammers
Member #2,604
August 2002
avatar

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.

Quote:

Do this where? :|

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

---
Me make music: Triofobie
---
"We need Tobias and his awesome trombone, too." - Johan Halmén

type568
Member #8,381
March 2007
avatar

window+r / cmd -know.

Can't compile your program though. And, i understood. If the game loop is smart(the 1 you showed me, or the one i was referred to before..), works good. In my case it doesn't, as i have a fixed delay.(Well, it varies depending on the last frame performance time..) I just had an own idea, that generally does work..

And.. So what is it? rest(0) or rest(1)?

Go to: