Print

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

Higher speed, no problems

Higher speed, problems

Same speed, no problems

Same speed, problems

Lower speed, no problems

Lower speed, problems

[snooptodd]

B) is a possibility, since my computer is from oh, 2005 and I don't even know what an OpenGL driver is. Just thought I should report the results

Yeah, you probably need new graphics drivers.  Go to the website where your hardware vendor provides software updates, or right click on your (Windows) desktop, hit Properties, go to Settings, look for a phrase that starts with "ATI" or "Nvidia," and type that phrase into Google along with "drivers."

or "Intel" or "VIA"

some links to help out

Intel drivers
Nvidia drivers
Ati drivers
VIA drivers

[Jude]

I'll have to look into this. My computer obviously has some kind of video card, it can run...let's see, it runs Morrowind decently, and XIII very well and...that's probably the newest game I've tried on it. But damn if I know anything about the hardware.

Not much of a computer buff.

Also, about the screen ratio thing...I pasted my init file into d16, but I noticed in d16's init file, it doesn't have the thing to specify screen size, and it just opens up as 1/3 of the screen like DF used to back before the fullscreen update. What's with that?

[Footkerchief]

I'll have to look into this. My computer obviously has some kind of video card, it can run...let's see, it runs Morrowind decently, and XIII very well and...that's probably the newest game I've tried on it. But damn if I know anything about the hardware.

I gave instructions above for determining what video card you have.  It should take about 30 seconds.

Also, about the screen ratio thing...I pasted my init file into d16

Your 40d init file?  Oh dear.  Don't copy your init file over, as a rule.

Get 40d16 again and don't obliterate its poor init file.  You can tweak resolution, or (new feature!) you can just drag the corner of the game window.  It's smart enough to figure out grid size itself now.  Also, the 40d16 init file explains how to tweak the PRINT_MODE parameter.  Try that.  I don't know what experimentation you did before, but it was probably doomed by the copied file.

[Jude]

I gave instructions above for determining what video card you have.  It should take about 30 seconds.

I'm not actually at that computer now.

Your 40d init file?  Oh dear.  Don't copy your init file over, as a rule.

Get 40d16 again and don't obliterate its poor init file.  You can tweak resolution, or (new feature!) you can just drag the corner of the game window.  It's smart enough to figure out grid size itself now.  Also, the 40d16 init file explains how to tweak the PRINT_MODE parameter.  Try that.  I don't know what experimentation you did before, but it was probably doomed by the copied file.

osnap

But yeah, I figured pasting over the init might be a problem...I'm pretty sure I tried the "vanilla" d16 with my savegame to test FPS but I'm not 100% sure. I'll have to go back and doublecheck.

Actually now that I remember, I just pasted the sections of the init files where it asks for graphics, since I didn't feel like typing out "guybrush_squares.png" six times

[ArneHD]

I'm having a bit of trouble with the latest release. Although it works fine, I have a 16:9 ratio screen and so the screen is squashed horizontally, and it is really annoying to look at.

Is there any way to change the graphics in this release? It is getting really annoying to have squashed tiles.

[Peteł]

About that hq4x filtering: there is a modified SDL.dll floating around the net which offloads the scaling to your gfx card..
http://www.syntax-k.de/projekte/sdl-opengl-hq/

[Baughn]

DF uses SDL purely for keyboard input and to get an opengl context; it does not use it for video output.

If you want to use hq4x, run the scaler over the tileset, then use the pre-resized tileset. That should work fine.

There's also nothing in 40d16 that cares whether your screen is 4:3 or 16:9; I've got a 16:10 display myself, and it works fine. If it seems squashed, that's most likely due to using the default (squashed) tileset.

[Footkerchief]

There's also nothing in 40d16 that cares whether your screen is 4:3 or 16:9; I've got a 16:10 display myself, and it works fine. If it seems squashed, that's most likely due to using the default (squashed) tileset.

Yeah, I often use a 16:10 external monitor with my laptop.  I love how the game seamlessly adapts to resolution changes now.

[DrazharLn]

See edit

Slower than 40d (~52 vs ~65 fps), no problems.

Tested on an 8x8 map with 29 dwarves (deliberately stress testy). Game freezes less than standard (non-fatal freezes lasting half a second or so, probably due to map size) but is otherwise indistinguishable, save the intro running at the fps set in init.txt, not 100 as in 40d.

Oh yeah, running at 100:65 grid size (probably), at 1680x1050 res, fullscreen.

I copied over the 40d init file, if that affects fps, then my results are invalid.

EDIT: Turns out the init file does have an effect, with the (slightly modified) original init file fps was a slightly faster 65-70 fps.

Please subtract one vote from slower no problems and add one to faster, no problems

As the init file seems to make such a difference, perhaps you should note somewhere that you absolutely should NOT copy your 40d init file over, for those that it does not occur to (I thought they would be identical).

EDIT2: Using VBO print mode causes DF to crash on start. The sound is played, but the game immediately crashes. I'll test on my linux laptop later (unintentional alliteration!) to see whether it is just windows or this PC.

[Xgamer4]

As the init file seems to make such a difference, perhaps you should note somewhere that you absolutely should NOT copy your 40d init file over, for those that it does not occur to (I thought they would be identical).

Yeah, you really should note this somewhere. Like at the very top of the init file. It might seems obvious to you guys, but to most of the players it doesn't really seem like there should be much of a difference.

[Footkerchief]

Yeah, you really should note this somewhere. Like at the very top of the init file. It might seems obvious to you guys, but to most of the players it doesn't really seem like there should be much of a difference.

Agreed.  We've seen enough people attempting it that Measures Should Be Taken.  Putting a warning in the init file itself is a great idea, and it might also be good to include it along with other compatibility warnings (you can copy saves from version X, you can't copy raws, you can copy graphics, you can't copy init, etc.)

[Baughn]

The init.txt parser needs to be rewritten. Failing that, there should be a launcher that takes care of all this.

Say.. would anyone like to volunteer to write one? 

[Kobold6]

Okay, so I hit the scroll wheel and it zoomed out a bit. Awesome, except now my hard disk is being thrashed and D16 isn't running anymore.

Anyone had a similiar problem.

[DrazharLn]

Zooming works fine for me.

Can we have more of an explanation of the modes used in print mode?

VBO mode doesn't work for me, but I don't know what it is either, so that may or may not be surprising.

[Baughn]

Right, quick explanation.
In all modes, there are four arrays involved.
- Vertex array: Tells OpenGL where on the screen the tiles are
- Texture coordinate array: Tells it what to draw in a given tile
- Foreground/background color arrays: Which color to blend into the tiles

Each of the print modes handle these arrays differently.

Standard mode: All arrays start in system memory, are copied through the PCI bus, and are fully rewritten every frame. The entire window is redrawn every frame. This is faster than you'd think, and very reliable.

Partial mode: Unless there is reason to think the whole window must be redrawn (detecting this is slightly buggy), only the tiles that have changed are drawn. It otherwise acts as standard mode.

Accum mode: A GL extension is used to copy the entire window to GPU memory after it's been drawn, and copy it back at the start of each frame. This makes partial printing more reliable, but is unfortunately usually pretty slow; your card (or PCI bus) needs to be *really* slow for this to be a win. Partial printing is on, and locked to 0 redraws.

Frame-buffer mode: A (newer) GL extension is used to draw to an off-screen texture instead of the window; that whole texture is then drawn to the window every frame. Partial printing is on, and locked to 0. This is usually slower than actual PARTIAL:0 mode, but more reliable.

VBO mode: This acts like standard mode, except that a GL extension is used to keep the (never-changing) vertex array in GPU memory. Partial printing is off. A lot of cards, particularily older cards or ATI cards, implement this badly. It is in theory slightly faster than standard mode, but in practice anything that can use it runs either code path in approximately zero time.