Advertisement

Test my iso engine?

Started by January 22, 2000 04:49 PM
81 comments, last by Toom 24 years, 7 months ago
57fps on a pIII500

cool iso engine
quote: Original post by ZomeonE

It seems that many people are getting 59 fps. Why is that?
They are all using different computers.


Perhaps their monitor refresh rates are at 60 Hz and their graphics cards sync to that?

//TOOM
Advertisement
59 fps on my machine (500 mhz PIII, TNT2 ultra w/32meg)

I think that people are seeing 59 fps because most monitors default to a refresh rate of 60hz or 60 fps.

The frame rate can be tied to monitor refresh rate when double buffering is being used. If the DirectX Flip function is being used to flip the front and back buffer, Flip will wait for the VBlank interupt before performing the flip to avoid any tearing or shearing in the displayed image.

If the monitor is refreshing at 60 fps that means that a flip can only happen every 16.66 miliseconds. The tiling engine is then limited to no more that 60 fps, even if the engine can draw a scene in 10 miliseconds, making it theoreticly capable of 100 fps. If you increase monitor refresh rate, you will increase fps to a point. After that point you then begin to see fps slashed in half. If the engine should take longer than it takes the monitor to refresh a single frame, then the frame rate would be cut in half because the engine would miss out on an opportunity to flip buffers on every other frame.

Now how do you solve the problem of being limited by monitor refresh rates? Triple buffering. In a triple buffer scheme you don''t have to wait on a back buffer that is busy because the flip operation has not completed (due to the wait for the monitor''s VBlank). You can just draw to the second backbuffer and keep the engine working.

Anyway my point is this, don''t look at frame rate as an indicator of a gfx engine''s speed (2d or 3d), instead measure the amount of time it takes the engine to draw a complete frame in miliseconds. This, along with fps can help you decide if triple buffering your display will improve your engine.

I hope this helps someone out. I feel like I am rambling
I got an undaunting 34 fps on a p233 (genuine intel) with 64 megs of ram and a diamond moster fusion. I would have an upgraded sys, but I traded my xmas gift for school books (damn education, ruining my right to live in ignorant bliss).

Was wondering though, since bstach mentioned it, what are the pros and cons of triple buffering?

Write more poetry.http://www.Me-Zine.org
quote: Original post by bstach

Now how do you solve the problem of being limited by monitor refresh rates? Triple buffering. In a triple buffer scheme you don''t have to wait on a back buffer that is busy because the flip operation has not completed (due to the wait for the monitor''s VBlank). You can just draw to the second backbuffer and keep the engine working.



Thanks for the tip. I was using double buffering. I changed it to triple buffering and although I still get 85 fps on my machine, a machine at work jumped from 59 fps to 74 fps!

//TOOM
quote: Original post by INVERSED

I got an undaunting 34 fps on a p233 (genuine intel) with 64 megs of ram and a diamond moster fusion. I would have an upgraded sys, but I traded my xmas gift for school books (damn education, ruining my right to live in ignorant bliss).

Was wondering though, since bstach mentioned it, what are the pros and cons of triple buffering?



Well the Pro is that a gfx engine has an easier time reaching its theoretical max speed without monitor refresh rates being a bottleneck. Typicaly slower machines are more prone to run into this problem, since thier frame rates tend to be lower anyway. So being able to maximize the use of the processing power of the machine you have is a big plus.

The Con is that a 640x480x16 screen uses aprox 614k bytes in a single buffer mode, aprox 1.2meg in double buffer mode, and aprox 1.85meg in triple buffer mode. So memory is the biggest con.

If you let DirectX take care of the details it is as simple to use as double buffering. It does not take a whole lot of extra work to implement it yourself if you need to.
Advertisement
tried to boost the refresh rates some. now running at 78 fps instead of 59..yay
Cool engine. If you haven''t already, check out that article "Tile/Map-Based Game Techniques: Handling Terrain Transitions" here on gamedev.net. Could prove useful if you can figure out how to apply it to an iso engine.

116 fps on a Celeron 366 with 64MB and Voodoo3 2000.

Very likely related to the refresh rate thing, because this is faster than other posts, including one with a Voodoo3 card and a better system. Also may be somehow related to the L1 cache (which is full speed, on-die on Celeron and Coppermine PIIIs, but not older PIIIs or PIIs and not yet for Athlons). Speculation only.

Of course it doesn''t matter much... it''s how smooth an actual game runs with all the game logic, sound, etc. In which case the frame rate would likely get bumped down if the whole frame can''t be composed in one vertical refresh... and all that "other" processing would probably make the affects of L1 cache less noticable)

Re: Triple-buffering

When double-buffering, you have your screen and the surface you are rendering to. When you flip() there is a bit of time where you are waiting for the vsync before flipping. During this time, you can''t draw to the surface. With tripple buffering, you can start working on the next frame while the displayed and soon to be displayed surfaces are both tied up. In DX, you specify 2 back-buffers and assuming there is enough video ram, it just works.

Most games will do the game logic and other non-graphics stuff, do the graphics stuff, flip and then loop. The game logic is processed during the time when you can''t draw to a surface in a double-buffered scenario... so in an actual game, triple buffering may not make as much of a difference...

- n8

Hey TOOM!

Haven''t try your little program yet but from the code I can already see where your FPS problem is. Your doing a frames++ after every flip. Now I am assuming you''re doing a DDFLIP_WAIT. So your program will wait for a vertical refresh which will take places 60 times per sec if you''re having 60 hertz. That''s why some many people get fps of 58-60. You''d have to switch off vsync to get the real frame. Some of you guysprobably did that.
On my Pentium 166 (16 MB) I got 14 FPS. My video card is a Trident with 1 Mb (!!!).
Nice job. I hope you deliver the source for the people.

Raul Fragoso
Metanóia

This topic is closed to new replies.

Advertisement