v50 Steam/Premium information for editors
- v50 information can now be added to pages in the main namespace. v0.47 information can still be found in the DF2014 namespace. See here for more details on the new versioning policy.
- Use this page to report any issues related to the migration.
This notice may be cached—the current version can be found here.
Difference between revisions of "v0.31 Talk:Technical tricks"
Jump to navigation
Jump to search
Uristocrat (talk | contribs) (PRINT_MODE info) |
Uristocrat (talk | contribs) (Forgot signiture.) |
||
| Line 5: | Line 5: | ||
== Meaning of the different PRINT_MODES == | == Meaning of the different PRINT_MODES == | ||
| − | Over [http://www.bay12forums.com/smf/index.php?topic=63667.msg1478550#msg1478550 here] is a post on what the different print modes do. The only problem is that it doesn't cover all the different types of 2D modes and it may be slightly dated | + | Over [http://www.bay12forums.com/smf/index.php?topic=63667.msg1478550#msg1478550 here] is a post on what the different print modes do. The only problem is that it doesn't cover all the different types of 2D modes and it may be slightly dated, but I don't think the rest are going to change. It would be good if someone could find more complete data and work the documentation into this article somewhere, because right now, I'm sure most people have no clue what the difference is. |
Just in case that post ever gets archived or something, here's the important part of it: | Just in case that post ever gets archived or something, here's the important part of it: | ||
| Line 15: | Line 15: | ||
* 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. | * 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. | * 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. Doesn't work yet. | + | * 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. Doesn't work yet. [[User:Uristocrat|Uristocrat]] 08:37, 8 January 2011 (UTC) |
Revision as of 08:37, 8 January 2011
directory/name change
Is it just my mind playing pranks on me again, or is this page somewhat difficult to find. I went looking for the available resolution settings (my monitor's maximum resolution didn't work) and it wasn't quickly apparent that I would find it here. Maybe having a configuration file category would make it easier to find. Probably just me though... RAM 06:41, 4 April 2010 (UTC)
Meaning of the different PRINT_MODES
Over here is a post on what the different print modes do. The only problem is that it doesn't cover all the different types of 2D modes and it may be slightly dated, but I don't think the rest are going to change. It would be good if someone could find more complete data and work the documentation into this article somewhere, because right now, I'm sure most people have no clue what the difference is.
Just in case that post ever gets archived or something, here's the important part of it:
- 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. Doesn't work yet. Uristocrat 08:37, 8 January 2011 (UTC)