FPS when rendering nothing

Heh, kinda hard to optimize that.

Anyway, since you're doing nothing but clearing an already cleared color buffer (maybe DX is smart enough to know it doesn't need to bother), and thus you're not hindered by a fill rate, the performance you're seeing should be entirely dependent on your processor (and the tiniest bit on your memory as calling functions does have a bit of memory overhead).

All in all I wouldn't say it's outrageously low. If you're concerned, though, that there's a problem, I would ask what hardware you're running on and how you're doing the FPS check.

Hope this helps!

The FPS you get when rendering nothing is completely irrelevant.

I'm running on a 2.2 GHZ Athlon with a TI4600 3d card and 512mb of ram. So it's a decent machine.

1300 FPS just seemed low to me for rendering nothing. Is that a normal FPS under those circumstances? I'm running a game I made but I commented out all the game logic and rendering other than start and begin.

I want to know if anyone else knows their FPS drawing a blank screen in DX so I can compare :)

Well it's not completely irrelevant because if I got a low FPS rendering nothing I'd know there was something slowing my app down.

Quote:

Original post by xegoth Well it's not completely irrelevant because if I got a low FPS rendering nothing I'd know there was something slowing my app down.

No, it really is. At speeds like that the tiniest change will give you what appears to be a huge difference in speed. If you want to try to benchmark something, render something representative and check the speed.

Quote:

Original post by xegoth I'm running on a 2.2 GHZ Athlon with a TI4600 3d card and 512mb of ram. So it's a decent machine. 1300 FPS just seemed low to me for rendering nothing. Is that a normal FPS under those circumstances? I'm running a game I made but I commented out all the game logic and rendering other than start and begin. I want to know if anyone else knows their FPS drawing a blank screen in DX so I can compare :)

It isn't a decent machine and performance when doing nothing except clearing the buffer is unimportant at all. Profile you program if you get low performance when actually doing anything half-important.

1300FPS its ok. Maybe its your PC max but its a good number for your confiuration.

Just remember something. "Early optimization is the source of all evil".

That means: Forget about FPS and make your game. If you see you have too low FPS (say you are running at about 10FPS), then its time to start debugging and optimizing and hardware testing. No sense to do it before.

Luck!
Guimo

Thanks. :)

I get about 1300FPS too (I can't remember exactly, and I'm too lazy to make up a somaple program :P), on my AMD 2600, 512Mb RAM, GeForce Ti 4400.

1300FPS is perfectly fine.

How are you measuring it, anyway? 1300FPS works out at 0.77 milliseconds per frame; I don't know of any standard timers that give you accuracy below 1 millisecond.

Just a remark:

A guy I know wrote a program in FreeBASIC (used a wrapper for SDL that wraps DirectX) and it featured a single pixel whizzing around the screen. It got up to about 532,000 FPS on my machine, and that's a Dell inspiron 600m, Centrino 1.5 ghz, 512mb of RAM, and a ATI Radeon 64mb vid card. Apparently a guy with a nice system got speeds of around 1,000,000 FPS!

I don't know about you, but I think that's pretty darn fast!


If you get your hands on the executable, and try it, then you will REALLY know how good your system is! I don't have the link on hand, but I'll put it in this post when I get it compiled.

One other thing: the program used lookup tables and got those high speeds. Without lookup tables, it only ran about 20 000 FPS. So if you're going to optimize early (not really a good idea) I would recommend using lookup tables for stuff like SIN and COS.

Quote:

Original post by Oberon_Command A guy I know wrote a program in FreeBASIC (used a wrapper for SDL that wraps DirectX) and it featured a single pixel whizzing around the screen. It got up to about 532,000 FPS on my machine, and that's a Dell inspiron 600m, Centrino 1.5 ghz, 512mb of RAM, and a ATI Radeon 64mb vid card. Apparently a guy with a nice system got speeds of around 1,000,000 FPS!

If the FPS displayed was "532,000", then there are 2 possibilities:
1) The ',' is used to indicate the decimal point. i.e. It's 532 FPS. This is feasible.
2) It means 532000, which simply means the frame-rate calculator is totally borked. 532000 means 1.8796992481203007518796992481203e-6 seconds, or 0.0018796992481203007518796992481203 milliseconds, or 1.8796992481203007518796992481203 microseconds. Read superpig's comment about timers above.

1,000,000 is really only understandable as 1000.000. You can never reach such a frame rate with an idle loop that just clears the screen.

Quote:

One other thing: the program used lookup tables and got those high speeds. Without lookup tables, it only ran about 20 000 FPS. So if you're going to optimize early (not really a good idea) I would recommend using lookup tables for stuff like SIN and COS.

Lookup tables for sin and cos, on our modern CPUs, are useless - they'll probably come out slower than a direct sin/cos. Today's CPUs have sin/cos instructions. Use them.

Quote:

Original post by superpig How are you measuring it, anyway? 1300FPS works out at 0.77 milliseconds per frame; I don't know of any standard timers that give you accuracy below 1 millisecond.

doesn't the QueryPerformance functions give 1 micro second accuracy?
I'm not sure about them being standard timers, though.

Apologies for any misunderstanding.

Quote:

Original post by yapposai Quote: Original post by superpig How are you measuring it, anyway? 1300FPS works out at 0.77 milliseconds per frame; I don't know of any standard timers that give you accuracy below 1 millisecond. doesn't the QueryPerformance functions give 1 micro second accuracy? I'm not sure about them being standard timers, though.

Whoops, you're completely right. I guess I misread 'microsecond' as 'millisecond' at some point in the past [smile]

Thanks, I didn't know about the QueryPerformance functions.

From MSDN:

Quote:

If a high-resolution performance counter exists on the system, you can use the QueryPerformanceFrequency function to express the frequency, in counts per second. The value of the count is processor dependent. On some processors, for example, the count might be the cycle rate of the processor clock. The QueryPerformanceCounter function retrieves the current value of the high-resolution performance counter. By calling this function at the beginning and end of a section of code, an application essentially uses the counter as a high-resolution timer. For example, suppose that QueryPerformanceFrequency indicates that the frequency of the high-resolution performance counter is 50,000 counts per second. If the application calls QueryPerformanceCounter immediately before and immediately after the section of code to be timed, the counter values might be 1500 counts and 3500 counts, respectively. These values would indicate that .04 seconds (2000 counts) elapsed while the code executed.

It seems that even on my crappy work computer I can get an accuracy of
( 1 / 3579545 )s .

You don't need a high precision timer to tell when a second has passed, having kept a count of the number of frames rendered.

Quote:

Original post by bakery2k1 You don't need a high precision timer to tell when a second has passed, having kept a count of the number of frames rendered.

Exactly what I was going to say. It all depends how you calculate it.

Strange.. I get 96000 FPS..

Back to the original question though, the FPS when doing nothing IS meaningless... don't put any stock into it what-so-ever.

Once your FPS gets over 500 or so, even it is pretty useless since the most minor jumps in frame render time will appear as huge leaps/falls in FPS (due to the nonlinear nature). Stupid things like drawing the FPS on the screen start to dominate the actualy frame rendering time!

This has been mentioned before, but for profiling you should be looking at frame TIMES, not frames per second. The latter is nonlinear in processor time and thus it often confuses people, who subsequently optimize the wrong parts of their programs.