Low fps

[Phytotron]

AA 0.2.7.1 -- OS 10.2.8 -- 600 MHz G3 -- 256 MB -- ATI RAGE 128 Ultra

I'm just curious as to why I get such a low framerate playing this game. The highest I'll hit playing locally, with no AI, is 50 fps. And that's spectacular compared to playing online, where I'm lucky to hit the mid-20's. If the number of players goes over, say, six total, then I usually drop to the 4-9 fps range.

And this is with every detail setting and whatnot turned all the way down or even off (with exception to the defaults which I leave as is). No other apps running. First thing I run when I startup the computer, even.

This isn't meant as a slight to the developers, but this seems absurd. I have a few games on here that are more graphically advanced and they're a lot smoother. Armagetron seems to be fairly simple graphically. I would think my computer could handle it. And I know other people with comparable machines get higher framerates. So...huh?

I'm just curious why this is and what, if anything, I can do to make it better (without upgrading, heh). I don't mean to come off like I'm nagging/complaining/whatever, just confuzzled.

[dlh]

Turn off sparks, if you haven't already. The latest version from cvs seem to give me a 20-30+ fps boost, so the next version will be really good for the low fps'ers. Other than that, I've found that any resoloution under 640 by 480 really doesn't give any fps boost.

[Phytotron]

Yep, they're off. Just in case, I clarify something: by defaults I meant those settings that after the particular setting in the list, after the colon, where it says "default." The little fade-in instructions say it's best to keep those as-is, so I do.

[Lucifer]

Tweaking is definitely called for. I figure your computer should outperform the one I used to play on, which is 800mhz Duron, TNT2 32MB video card, 256MB DRAM, 60-90 fps

Turn off floor texturing if you haven't already. Turn off mirroring. resolution set to 640x480. I play with sparks on, I find the floor is a big enough hit that I can have sparks or floor, but not both (the computer I use now is fast so I have lots of effects on now).

Ok, set the walls to inifnity and see. ON my system (Linux blahblah) that's worth 5 fps right there. Turn off the sky (another 5fps), and so forth.

What you wind up with is still a good-looking grid, but all the frills (for me the low wall and sky interfere with gameplay) are off.

[dlh]

Tweaking is definitely called for. I figure your computer should outperform the one I used to play on, which is 800mhz Duron, TNT2 32MB video card, 256MB DRAM, 60-90 fps

no way, that ibook graphics card is terrible.

[Lucifer]

Tweaking is definitely called for. I figure your computer should outperform the one I used to play on, which is 800mhz Duron, TNT2 32MB video card, 256MB DRAM, 60-90 fps

no way, that ibook graphics card is terrible.

Worse than a TNT2?

[Z-Man]

I've heard several times that the Mac version performs poorly compared to the PC version. Could the Mac folks check whether, perhaps, we distribute *debug* builds? They appear to be pretty fat downloads as well (10Mb compared to less than 2Mb for the Windows build with the same content).

[Jonathan]

I'm trying to download the snapshot but the download is quite slow. I suspect at least debug symbols.

[Tank Program]

Yes, it seems that many people have had this issue with the high fps locally and low fps over the network...

[dlh]

I'm trying to download the snapshot but the download is quite slow. I suspect at least debug symbols.

Yes, debug symbols, no optimizations. But then again this is not an offical releases. :\

The mirror always seems to choose luke's site, which is slow. Download it from generalconsumption.org/armagetron/builds

[iceman]

does the network and graphics rendering code run in parallel or does the rendering only happen after waiting for network data ?

parallel is the way to go so that fps dont suffer

[Z-Man]

All official builds have the performance problem that the network syncing code is doing way too much unnecessary work; it mostly affects servers, I think, but clients suffer from it, too. The next build won't have that problem.

Iceman: If you mean that the App should not wait for network data, you're right (and of course that's not done during a round, only before the round starts to get everyone in sync). If you have only one processor, the order of handling the network data (and user input) and rendering is quite irrelevant. Doing things in parallel even costs some performance because you have to do all kinds of syncing or deal with extremely interesting bugs. So no, rendering and networking are not currently handled in parallel.

However, when I get to it, there will be the rendering switch that will stop the CPU to wait for the GPU to finish every frame, on systems with a modern GPU this will gain some FPS by the improved CPU/GPU parallelism at the cost of a loss of synchronization between keyboard input and display (we're talking about something in the range of 1/200s here).

[Jonathan]

Note about the no glFinish delay: The better framerate will actually decrease the delay. After all the delay is probably about the same but with much better framerates.

[Z-Man]

Jonathan: this may be true for you, but I've seen HUGE delays build up because the GPU was keeping 1000 (no exaggeration!) simple frames worth of rendering in its buffer and the application did not wait for them to flush, so there was a delay of about ten seconds between input and application reaction. Ok, this was a TNT2 back then using Direct3D and not OpenGL, but the principle is the same. If sensibly implemented (keep no two glSwap() commands in the buffer), this does not happen, but I don't keep my hopes too high for it to work for me.

[Jonathan]

I meant in case it actually works.