Print

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

[Baughn]

DFA has been superceded by DF v0.28.181.40d2; see http://www.bay12games.com/forum/index.php?topic=28841.0 for details.

No further updates will be posted.

==== Old contents ====

Right. Like it says in the topic - I've rewritten DF accelerator somewhat more cleverly, and the new version works for everything.

Want graphical tilesets? You can have them.
Want 200x200 grids on an 640x480 screen with a 16x16 tileset? You can have them.
Want a 13x17 tileset, and no black space? Go ahead.
Want all of the above, on a ten-year-old computer with a geforce 1? That works too, assuming you have halfway decent drivers.

Some people have been downloading dwarfort.exe. This is incorrect. It won't work. Read the entire post.

So, without further ado: The URL: http://brage.info/~svein/df_accelerator/bin/. Read on, though.

If you're on a macintosh, you want the opengl.dyld and run.sh files. Put both in your DF directory, and start DF by typing "sh run.sh" in a terminal window, in that directory. It will print debugging info to said terminal.

If you're on windows, you want opengl32.dll. Put it in your DF directory, next to dwarfort.exe. This is all you have to do; do not download dwarfort.exe from that directory.

If you're on a ppc mac, I can't make a binary for you. It should still work, in theory, though I haven't tested it; to compile it, do the following:

Note: The official source tree is at http://brage.info/~svein/df_accelerator/, and is updated much faster. You'll need darcs to download it properly, however.

- Download and install xcode from developer.apple.com, if you haven't already. It's free.
- Download df_accelerator_source.tar.gz from the earlier link, and put it in the DF directory
- Run the following code in a terminal:

Code: [Select]

cd wherever-you-put-DF
tar xzf df_accelerator_source.tar.gz
cd df_accelerator
make
cp opengl.dyld run.sh ..
cd ..
sh run.sh
Incidentally, df_accelerator.tar.gz is updated manually, basically whenever I remember to do so. If you want more up-to-date code (it probably won't matter, most of the things I fix are windows-specific anyway), get the unpacked source code from the link in the next post. With darcs, preferably.

In case of trouble:

On a mac, post all the output from that terminal in a post in this thread, and I'll get back to you.

On windows, download dwarfort.exe from the download directory, overwrite your old version, and repeat whatever caused the problem - this is a special debugging version of DF. 40d, by the way; don't mix with older installations. It will create a terminal window with debugging output that you can post; if you can't copy and paste, just write down the last two or three lines manually.

(Well, that's the idea. You may need to manually start DF from a terminal for it to work; use start->run->cmd to get one.)


Known bugs

- The mouse texture is not supported. Apparently nobody uses it, though.
- The intro movie is *really* not supported, and likely to mess things up horribly. Turn it off.
- There have been reports that using a 32x32 tileset glitches, leaving half the screen undrawn. 16x16 and below do work.

- When using a graphical tileset, the screen can will become corrupted when DF loads the graphical tiles. To clear this up, toggle fullscreen mode once or twice. Fixed.
- The game may or may not crash after generating a new world; I'm looking into it. It will work fine after restarting it, however. This has been fixed.
- Under some circumstances, the accelerator can be confused into thinking the grid has an impossible size like 1x3 or something. It will then crash, though usually not immediately. This can be worked around by turning off partial-printing, and will be fixed in the future. Hopefully fixed.
- When you export a map from world-gen you just get lots of images of the current screen pasted into the file where the map ought to be. Thoroughly fixed.


Tips and tricks

- For higher performance, use [PARTIAL_PRINT:YES:0] in init.txt. Even if this hasn't worked before, it will now.  Case matters. "yes:0" won't work; "YES:0" will.
- On Windows Vista or a macintosh, you may get higher performance by running it in fullscreen. Probably not measurably so, however.
- The benefit of DF Accelerator seems to be larger the older your computer is. Don't expect a 20FPS jump if you have a Geforce 8800GTX.


Feed the author

I'd be happy to hear success stories - tell me if you get large FPS increases. I wouldn't be happy to hear that it slows you down, but if that happens I need to know, so tell me that too.

[Baughn]

Technical details
The only reason this hack is needed at all is because DF does a lousy job at rendering. To put it simply, its printing algorithm works as follows:

For each tile, draw its background color. Then draw the actual tile, in the foreground.

Afterwards, flip the buffer so they actually go on-screen. (This is a problem - they should not go on-screen before, and depending on the driver it may be storing an awful lot of details for later use.)

Well, the algorithm's not really a problem in itself. The problem is that it uses immediate-mode opengl rendering to do this, which was deprecated somewhat over a decade ago and is now horribly slow on all but the best drivers. As gamers who don't buy workstation boards, we don't have the best drivers. There are, of course, better ways to do this, but DF doesn't use them.

Furthermore, partial-printing, while it does reduce the number of calls a lot, fails to reduce the number of glColor calls; this stays up there, at something like eight million per second. Fortunately they're not the most expensive ones.

Solution: Write a library that shimmies between DF and OpenGL, intercepts DF's calls, figures out what they are trying to draw, and draws them using better techniques. That's what I'm doing.

To be more specific, I'm building a tile catalog to upload as a single texture (as opposed to the single-tile-per-texture scheme used by DF), and collecting all the tile drawing calls into an array I can send to opengl all at once.

This reduces the number of opengl calls to something like twelve per frame, as opposed to the 60,000 I often saw from DF before, as well as fixing partial printing through having opengl entirely redraw the screen every frame. (It's good at that, so long as you use efficient code.)

Any questions?

You could also look at the source code; it's at http://brage.info/~svein/df_accelerator/.

[Sean Mirrsen]

I use the mouse texture, oddly enough, and I liked it...

I still don't understand what this proggie does, except altering the graphics output... How can it "accelerate" DF?

*addendum: Unless you reverse-engineered the executable, which I find unlikely enough to withhold any accusations, and even then it's not part of the standard package you suggest. I don't really understand the purpose of this, other than maybe playing on an Eee...

Why does the opengl32.dll link point to an opengl32.exe?

[Baughn]

It allows some people to use partial-printing that otherwise wouldn't. It also works as a layer between DF and OpenGL that, in case of bad opengl drivers, can reduce CPU usage from graphics output by quite a bit.

It won't make a difference with good drivers, though; in this case the overhead from DF calling to opengl (whether to my version or the real one) dominates the time actually spent in opengl. If it was part of DF, that'd be a different story.

Edit: It doesn't. Perhaps you should have your browser checked. Nor is it, in fact, a link.

[Duke 2.0]

 I have an old laptop with overheating troubles thanks to a bad power supply. This only causes trouble when using very intensive programs, like DF, so I wonder to myself:

 Will this reduce the strain on my computer, or will it use more resources that would otherwise not have been used?

[Baughn]

Neither. It may reduce CPU load from DF's graphical output, but unless that causes it to hit the FPS cap, it will just go on sucking up 100% of your cpu in a vain attempt to get there. Might get a bit closer.

[Sean Mirrsen]

Well, I use Opera. And it tries to save the .dll from that page the link you posted leads to, as an "opengl32.exe".

[Baughn]

Opera has an odd tendency to unpack archives and such. Perhaps it's detecting it as an executable (it is) and thereby deciding that it should be called opengl32.exe (it shouldn't).

Regardless, it must be named opengl32.dll to work, so you should try renaming it back.

[Footkerchief]

Linking OpenGL
Failed to link glDisableClientState

Am I missing something?  This is in XP, by the way.

[Stravitch]

On my work machine (can post specs if you need) I get this output after using the debug exe you provided. 

C:\df_28_181_40d>dwarfort.exe
Linking OpenGL
Failed to link glGenBuffers

This is after trying to run it normally in windows XP both with and without partial print.

I'll try it again at home in 40 minutes or so.

[Drunken]

Footkerchief, that problem is fixed now just dl again.

Also just for feedback here it made no appreciable change with my framerate but I had messed with partial print and finally found a number that works ok. It also stopped the issue with minimising the window causing partial print artifacts. So I can vouch for this program in that anyone who is having issues with partial print will find it helpful

[Footkerchief]

Footkerchief, that problem is fixed now just dl again.

That was with a fresh download.  Just re-downloaded it, same thing.

[Baughn]

Linking OpenGL
Failed to link glDisableClientState

Am I missing something?

An updated driver. That function is part of OpenGL 1.1, and there's basically no way whatsoever for the shim to work if it isn't around.

However, it may be a simple bug in wglGetProcAddress, which is fixable.. check back tomorrow, as I'll try a more robust method for the functions that can use one - which includes that one.

EDIT: Make that "in half an hour"; might as well get it over with. I'll post when it's done.

[Baughn]

On my work machine (can post specs if you need) I get this output after using the debug exe you provided. 

C:\df_28_181_40d>dwarfort.exe
Linking OpenGL
Failed to link glGenBuffers

This is after trying to run it normally in windows XP both with and without partial print.

I'll try it again at home in 40 minutes or so.

That problem was recently fixed; re-download the dll.

[Footkerchief]

My drivers are only about 3 months old but I'll try new ones.  If that doesn't work, I'll sit tight.  Thanks for your work on this BTW.