Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  

Author Topic: Printmode performance redux  (Read 474 times)

ChairmanPoo

  • Bay Watcher
  • Send in the clowns
    • View Profile
Printmode performance redux
« on: January 30, 2020, 01:21:19 pm »

Whatīs the current consensus on the performance of the different print modes? There was a post on the subject 10 years ago (more below), but I donīt know to what extent things have changed in the interim.

OLD (pre-2010s) consensus
Quote
2D: Use 2D graphics (SDL) for everything. This works everywhere; SDL deals with any double-buffering that needs to be dealt with. Kinda slow, though. Otherwise works basically like partial:0.

STANDARD: Actually, rendering the entire screen every frame isn't that slow, if you do it via OpenGL and have reasonable code. That's what this mode does.

PARTIAL: On some setups, just rendering the tiles that changed worked. Partial does just that; PARTIAL:2 renders each changed tile three times, in consecutive frames, to cover triple-buffering. Unfortunately many newer GPUs discard and overwrite the frame-buffer between frames, and then this doesn't work.

ACCUM_BUFFER: Uses the ancient glAccum call to save and restore the contents of the window between frames, working around the driver's discarding its contents. Usually the slowest mode of all, but some people have had good results. Presumably the others are even slower for them.

FRAME_BUFFER: Basically the same thing, but using newer GL frame-buffer extensions to render to a texture instead, and blitting that texture to screen once a frame. It saves at least one copy vs. accum-buffer.

Both frame-buffer and accum-buffer use partial:0 under the covers, they just wrap that method appropriately in order to avoid flickering.

VBO: A variant of STANDARD that uses vertex buffer objects to explicitly tell the GPU what data doesn't change between frames, namely the location of the various tiles. This marginally improves performance vs. standard, if it works, which it should.

SHADER: Dumps the entire DF graphics array to GPU memory, and programs the GPU to interpret it on its own. Dramatically improves performance, but basically only works on geforce 8000-series and above, or the equivalent ATI. I think there's some 7000-series card (7950?) that also supports such shaders, though.
Logged
Everyone sucks at everything. Until they don't. Not sucking is a product of time invested.

Robsoie

  • Bay Watcher
  • Urist McAngry
    • View Profile
Re: Printmode performance redux
« Reply #1 on: January 30, 2020, 02:13:45 pm »

Unless one is using some really very high resolution tiles and tilesets, i wonder if the print mode has actually a noticable effect ?
The performance problems seems more linked to the CPU having to calculate so many things, pathfinding, AI, temperatures of every tiles, moving stuff, things growing, truckloads of units etc... (without counting possible bugs increasing the cpu load needlessly)
Logged

PatrikLundell

  • Bay Watcher
    • View Profile
Re: Printmode performance redux
« Reply #2 on: January 30, 2020, 03:59:33 pm »

Well, there's definitely a display performance issue: the FPS drops significantly when viewing the surface during a siege compared to viewing a layer of unmined rock during that same siege. However, I have no idea of the extent to which print mode selection affect this.
Logged

ChairmanPoo

  • Bay Watcher
  • Send in the clowns
    • View Profile
Re: Printmode performance redux
« Reply #3 on: January 31, 2020, 06:00:32 am »

In older versions it certainly had an impact. In particular, the TEXT output was the most fluid by quite a bit back then. But ... kind of ugly.
Logged
Everyone sucks at everything. Until they don't. Not sucking is a product of time invested.