Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Alkyon]

So, what's the difference between the new graphics modes?  I mean, in general terms, how do STANDARD, FRAME_BUFFER and ACCUM_BUFFER and the 2D modes work and differ?

I'm just kind of curious generally which modes are faster under what general conditions.  For example, what would be fastest on a dual-core CPU Windows 7 Machine like mine.

Also, a lot of customization data seems to have been left out of the new init.txt file.  I would love to have my flow-values back on liquids, and a regular seasonal auto-save function.  Especially if some of the faster graphics modes are unstable.

Anyways putting this here because it's been bugging me since I set up my init, and I thought that other people might benefit if it's put up here.  The DF Wiki only has information about the old, reliable partial print last time I checked.

[Narmio]

I'm not too certain about the different graphics modes, and am very interested in an answer from someone more knowledgeable.

But I can tell you that init.txt got split into init and d-init, which contains all the game stuff like backups and flows.

[Alkyon]

Oh, I hadn't even looked at d-init.  I had no clue what it was so I left it alone.

Edit:  Trying out FRAME_BUFFER now.  It seems to "Think ahead" a bit and predict the next few moves your dwarves and the physics will make the best it can when you've got the game paused, building up a buffer of frames.

[voneiden]

Oh, I hadn't even looked at d-init.  I had no clue what it was so I left it alone.

Edit:  Trying out FRAME_BUFFER now.  It seems to "Think ahead" a bit and predict the next few moves your dwarves and the physics will make the best it can when you've got the game paused, building up a buffer of frames.

Nope, PRINT_MODE is only about the way graphics are displayed, 'predicting' anything would require access to the game engine itself and a big load of memory (Storing one second ahead on 100fps would need 100 framebuffers, we're talking about 7,6MB per frame on 1600x1200 resolution, so 760MB of video memory? Oops, no go.)

Here's some OpenGL specifications on it http://www.opengl.org/documentation/specs/version1.1/glspec1.1/node102.html

Probably the PRINT_MODE simply decides what method SDL will use to communicate with OpenGL on the rendering.

[shadow_slicer]

Probably the PRINT_MODE simply decides what method SDL will use to communicate with OpenGL on the rendering.

Actually SDL doesn't communicate with OpenGL. All it does is create an OpenGL compatible drawing surface, and leaves everything else to the program itself. The difference between the modes is how OpenGL is used (if at all).

The 2D modes do not use OpenGL. They use SDL to perform the rendering in software. These modes don't support zooming since DF doesn't implement its own texture scaling. These modes should work on any system, but may be somewhat slow. For this reason, you probably only want to use it if you graphics driver/ graphics card is buggy or broken.

The Standard mode uses normal OpenGL and clears and redraws the entire screen each frame. Since it is redrawing the entire screen it may be slow.

The Partial mode relies on the screen not being cleared or corrupted between frames. Because it assumes the screen hasn't changed, it only has to draw the parts that changed. This should be faster than standard, but will result in corruption if the screen actually is altered.

The FrameBuffer and AccumBuffer modes each use different OpenGL extensions to preserve the previous frame and then only draw the parts of the screen that changed. Note that if your graphics driver either doesn't support these extensions or has a nonstandard implementation they may produce flickering or display garbage. Also if the hardware doesn't support these extensions, the driver may still tell DF it does support it and then use software to emulate the FrameBuffer/AccumBuffer (which will be really slow).

When looking at the rendering performance it is important to understand how the current version differs from the previous version in how it displays frames. In the previous version the fortress and the graphics ran in the same thread, so there was no benefit from multiple cores. In the current version the graphics runs somewhat independently from the fortress. When the fortress runs it adds graphics frames to a queue at a fixed rate (set by the graphics cap). The graphics thread takes them off the queue and displays them when they become available. The frames are actually not too large since only the tile type and foreground and background colors are stored (so it is the same order as the grid size, not the screen size).

Ideally the queue should always be nearly empty, but if the graphics thread is much slower than the fortress thread, the queue becomes longer and longer. Since the graphics thread displays them in order, this means there is more delay between when things actually occur in the fortress and when they appear on screen. There is a limit to the queue length (at which point it starts dropping frames), but the latency from the full queue is probably noticeable. Reducing the graphics rate should improve this.

*Note: I am basing this explanation on the code from d19 and the comments Baughn made towards the end of the d19 FotF thread. Since Baughn made significant changes to the code after d19 and before 0.31.04 and I haven't looked through the code since then, some of this may be incorrect.

[Narmio]

Thanks Shadow_slicer, that's really good stuff to know.  So I guess the summary is: Assuming you have a modern system, try Partial:0, if not try Frame or Accum buffers, if not try Standard, then one of the 2Ds if all those fail.

I was using Baughn's accelerator hack with partial:0 and no flickering or corruption.  I'm hoping that means that the same will be the case with .04.

[Baughn]

PARTIAL:0/Accelerator is basically equivalent to STANDARD, just slower, so if you had luck with that you should just use STANDARD.

And the threading works quite differently today. Unless something is broken (which may well be the case; Toady basically went at it with an axe to make it work, and I haven't had time to fix it properly yet), the renderer thread controls the simulation thread, not the other way around.

Basically, it works like this. Renderer thread is -, simulation is *:
- Signal the simulation thread to build the UI.
* Finish the current simulation frame, then look at the messagebox. Build UI. Signal renderer thread.
- Wait for the signal, grab the built UI, convert indexed colors to RGB (..and some of toady's other code converts RGB to indexed, earlier...), print the result to screen.
- Check how long it's been since the last time we got to this point, calculate how many frames the simulation thread should have done since that time (floating-point), then signal it with a message telling it that number.
- Sleep until the next frame should be drawn.
- Check for keyboard input.
- Loop to start.

While this is going on, the simulation thread runs frames as quickly as possible, but maintains a count of how many frames it's supposed to have done, and pauses if that hits zero. It's allowed to fall one second behind, giving it a sufficient buffer without letting it overrun the FPS limit for longer than one second at a time. Works well, overall.

Oh, and the newest code is up on http://github.com/Baughn/Dwarf-Fortress--libgraphics-/ if you want a look. Doesn't actually compile at the moment, though. (The code in question is in enabler.cpp, look for async_loop)

[voneiden]

Thanks for the details, it was interesting to learn more about how that stuff works. Only things I've ever done with SDL were with pygame, and now that I rechecked, right, it does have seperate bindings to SDL and OpenGL.