Print

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

[Blade_Train3r]

Well, not really, been playing since the last couple 40d releases, but I'm a lazy sod who avoids forums normally I do tend to avoid Fun simply because as of yet I've avoided any fancy projects. Guess I should change that >,<

Anyway, quick question on a more technical note, my computing knowledge is generally decent on practical and bad on theory, so I want to know the differences in the way in which the different openGL render modes work. FRAME_BUFFER I guess loads all the characters as textures in the frame buffer, but I honestly can't make a guess at how accum_buffer and VBO work. Standard is non intuitive since all I know is that it's a combination between the standard CPu-only 2d mode and opengl acceleration?

On that note, does anyone know if there are any plans to put the SHADER render into DF2010? I know it was glitchy but it gave me very good performance.

Dankie baie
Blade

[Qiu]

On that note, does anyone know if there are any plans to put the SHADER render into DF2010? I know it was glitchy but it gave me very good performance.

I think it already is in no?

[Blade_Train3r]

"Available modes are 2D, 2DSW, 2DASYNC, STANDARD, PARTIAL:<number>, ACCUM_BUFFER, FRAME_BUFFER and VBO"

Although I would understand if there weren't plans, it wasn't fully developed by the time 2010 came out and it's not like the other renderers don't offer good performance on a far wider range of PCs.

[Turambar]

What are the differences between all the modes, and which one runs fastest?

[Blade_Train3r]

Well that's kinda what I'm asking (the difference between the modes). As far as I know the 2d/2dasync/partial modes are purely CPU driven, with no non-tectual graphics involved. The rest are pure opengl or, in the case of standard, a mix of gfx card and CPU use. 2d is the "classic" DF renderer, 2dasync splits the frames between multiple cores (I THINK) and partial redraws only unchanged squares in frames to save on CPU useage.

Of the remaining 3, I find Frame_buffer to be decent for both compatibility and speed purposes, it's basically the same rendering method any Windows before Vista uses - all (2d) screen output is put into one big texture which is loaded into video memory. accum_buffer seems to run slightly slower and tends towards less compatibility (or at least won't run on the old 945 intel series graphics chipsets) and VBO is to me both slower and buggier than either of the above forementioned.

I have tried all the rendering modes on multiple systems, if not a wide range (3 systems - a netbook, a 3.0GHz P4, and my gaming PC), and my experience with performance is reasonably consistent with them.

Edit: On a side note, I finally know where Baughn's avatar comes from! It's 100% correct.

[Turambar]

I have a geforce 8800 Ultra.  Where's the mode that lets me run the entire game on my gpu?

(mostly joking here.  It might be possible with a lot of time, liquor, and CUDA, but mostly I just want the one that's most likely to take advantage of all the power)

[Baughn]

All rendering is always offloaded to the second core, which leaves 2DASYNC somewhat pointless, but I haven't bothered to take it out yet. 

2D does everything in software, via SDL. This uses lanczos resampling for zoom, which basically means it's the best-looking mode.

All the opengl modes do some variation of creating a grid of triangle pairs, which is then rendered to the screen per-frame. They use opengl's linear filtering for zoom; that's nowhere near as nice as lanczos, and adding lanczos-based mip-mapping for that is likely to happen eventually.

Standard does exactly the above.

Partial creates a grid of just the triangles that were changed since last frame, or nTH last frames for partial:n, and draws those.

Frame-buffer works like partial:0, but draws to a frame-buffer which is then blitted to the screen per-frame.

Accum-buffer uses glAccum, but does basically the same thing as frame-buffer. Less efficiently.

VBO works like standard, but explicitly stores the grid (which only changes when you resize the window) in graphics memory, and should be very slightly faster.

[Blade_Train3r]

Yarr thanks for the informative response Baughn

The VBO explanation gives me a reason for the fact that plain 2D was faster than it on the P4 - I had set the shared graphics memory to 8MB on that PC, might simply not have been enough to hold the whole grid (although DF doesn't take up THAT much VRAM, does it? )