Print

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

[mifki]

Just for clarity though, will the multilevel version also have non-square tileset functionality, or do I have to download another build for that? What exactly does nextgen do? I'm a bit confused^^

Eventually there will be single version with all features. I wasn't sure non-square tiles are possible to implement nicely, and even now there's a chance that DF2014 will contain some significant code changes that will make non-square tiles impossible. So there's a separate nextgen branch with non-square tiles but with some things like multilevel rendering missing for now.


There's new build of multilevel branch, 3.15, that fixes shadows rendering in some situations, has new "multilevel" command to control number of levels, see readme, and is compatible with r5 on Windows.

[molkemon]

Ok, I tested the multilevel release on windows r5 a bit, it generally works. FPS impact is noticeable if theres actually additional levels drawn (so if your current screen spans across levels, fps will drop. multilevel 15 is very resource intensive. The FPS in the fort I tested it in were bad to begin with though. And it looks very nice.

For me, mapshot produces a very corrupt image (the game zooms out correctly for a second to encompass the entire map, but the .tga file looks like a completely distorted broadcast image or sth like that. Screen: http://i.imgur.com/svQyKzF.jpg
At the very bottom you can see a road I built into the mountain, and which is actually there, so it is actually doing something right... very weird

When I went up to a z-level in the sky where no layers would be rendered at all, Dwarf Fortress crashed.

That's it for now. Generally very nice, the main functionality is working nicely^^

Massive optimization idea: I am very bad at coding and what I say now is probably nonsense, BUT: as far as I understand how this works is that you look at the game memory to where what should be and then tell the renderer to render something different than it normally would. Now my idea: Would it be in anyway possible to take that same information from memory, replace it with basically NOTHING and instead use an external executable for rendering? So you make an executable which displays what should be rendered, it would look exactly like being rendered in DF itself, all input would be relegated to the df main executable. The advantage of this would be that the OS would automatically assign this second executable it's own cpu thread/core. And if you replace whatever DFs rendering should show with nothing, that should free up a LOT of cpu for the main exe to do other stuff (pathfinding etc), in theory drastically boosting FPS.

At least the part where you just replace all rendering with nothing/black squares should be somewhat easily testable just to look how much FPS would increase if rendering would not be done on the same cpu core.

[scamtank]

Eventually there will be single version with all features. I wasn't sure non-square tiles are possible to implement nicely, and even now there's a chance that DF2014 will contain some significant code changes that will make non-square tiles impossible. So there's a separate nextgen branch with non-square tiles but with some things like multilevel rendering missing for now.

There's new build of multilevel branch, 3.15, that fixes shadows rendering in some situations, has new "multilevel" command to control number of levels, see readme, and is compatible with r5 on Windows.

You're dear to us, don't forget that.

I can also confirm the sky crash. It happens from multilevel 1 to multilevel 15, on crowded mountain forts and fresh meadow maps. As soon as there's nothing on the same Z-level, it goes down.

[mifki]

Sky is fixed in 3.16. Also I'm aware that mapshot produces corrupt image on Windows, have no idea why

Also there's a build of nextgen branch (with non-square text tiles) that works on Windows. However on r5 only it makes dwarfmonitor plugin crash the game. Please read readme, likely to contain bugs, blah blah... Oh, also for OS X there's a build of multiscroll-nextgen to complement twbt-nextgen.

[scamtank]

Sky is fixed in 3.16. Also I'm aware that mapshot produces corrupt image on Windows, have no idea why

Also there's a build of nextgen branch (with non-square text tiles) that works on Windows. However on r5 only it makes dwarfmonitor plugin crash the game.

Damn, you're quick.

[fricy]

For me, mapshot produces a very corrupt image (the game zooms out correctly for a second to encompass the entire map, but the .tga file looks like a completely distorted broadcast image or sth like that. Screen: http://i.imgur.com/svQyKzF.jpg

Works ok on OSX

When I went up to a z-level in the sky where no layers would be rendered at all, Dwarf Fortress crashed.

Yepp, it crashes. Not at the absolute top of the map, but when there are no lower levels to render on the displayed proportion of the map, even if off the screen the map is high enough. This crash is new to 3.15.ok, fixed in 3.16. damn, you're fast.

Massive optimization idea: /snip

AFAIK the graphics engine (and maybe dfhack too) already runs on a second core, so: no, it wouldn't give the performance advantage you expect. The proper way to do multilevel rendering is proposed in this thread, the big problem is that it requires Toady's support, and he is not into the problem at the moment, so the only way to achieve the sameish result is to do it with dfhack.

[mifki]

Sky is fixed in 3.16. Also I'm aware that mapshot produces corrupt image on Windows, have no idea why

Also there's a build of nextgen branch (with non-square text tiles) that works on Windows. However on r5 only it makes dwarfmonitor plugin crash the game.

Damn, you're quick.

I don't want anyone to notice stupid mistakes I sometimes make in my code

[mifki]

Massive optimization idea: /snip

AFAIK the graphics engine (and maybe dfhack too) already runs on a second core, so: no, it wouldn't give the performance advantage you expect. The proper way to do multilevel rendering is proposed in this thread, the big problem is that it requires Toady's support, and he is not into the problem at the moment, so the only way to achieve the sameish result is to do it with dfhack.

Actually I need to find the place in DF rendering code where it tries to render treetops and all such things for lower levels and disable it. Then I need to further optimise my code so that it renders the least possible area for each level. And then it would be quite close to what can be achieved with "proposed" way in most cases.

[molkemon]

I am 99% sure that neither dfhack nor the graphics engine runs on a second core.

This can be easily observed with Windows Task Manager, as I'm having a Quad-Core CPU and the dwarffortress.exe process constantly takes up 25% cpu (unless paused). dfhack does not have a seperate process at all.

Edit: After reading some threads in the forum, it seems that everyone is claiming that graphics already use a second core, but as I mentioned before, I have never ever seen DF.exe exceed 25%, which would contradict this statement.

[fricy]

I am 99% sure that neither dfhack nor the graphics engine runs on a second core.

This can be easily observed with Windows Task Manager, as I'm having a Quad-Core CPU and the dwarffortress.exe process constantly takes up 25% cpu (unless paused). dfhack does not have a seperate process at all.

As I said, I'm not sure about dfhack running on a second or third core, but graphics does utilize multithreading.

[lethosor]

I am 99% sure that neither dfhack nor the graphics engine runs on a second core.

This can be easily observed with Windows Task Manager, as I'm having a Quad-Core CPU and the dwarffortress.exe process constantly takes up 25% cpu (unless paused). dfhack does not have a seperate process at all.

Edit: After reading some threads in the forum, it seems that everyone is claiming that graphics already use a second core, but as I mentioned before, I have never ever seen DF.exe exceed 25%, which would contradict this statement.

DFHack and the graphics engine run in separate threads, not separate processes. CPU usage of these threads is negligible, although you may notice an increase when moving around the map rapidly, for example. DFHack suspends DF when performing most tasks, so you won't usually see more CPU usage than DF when running something like 3dveins. I'm not sure how to determine this on Windows, but on OS X and Linux, DF uses 8-9 threads on the main menu and around 14 when using DFHack. (You can also test this by typing in the DFHack console when loading a game - DF won't respond, but the console will.)

[mifki]

You are both somewhat right.
First we need to distinguish between rendering of the current game screen into some buffer, including cpu-intensive rendering of the world map (let's call it screen rendering) and rendering of this buffer onto screen (which can be via OpenGL, text-only, "2D" mode, let's call it graphics rendering).

In the game there are two threads. On the second thread graphics rendering is performed along with some preparations, depending on the rendering mode. Also for example, overrides in my plugin are processed on this thread. In general this thread uses little CPU resources because most work is done by GPU.

However screen rendering is performed on the first thread, which also runs the game itself. Technically, graphics rendering thread sends a message to the main thread to call current screen's render() method. This is simply a synchronisation measure - world must not change while we're rendering it.

So, in short, it's multithreaded but that doesn't help much.

[Meph]

Not sure if this has been reported yet, but creature sprites are not displayed across z-levels. It uses creature tiles, when shown on a different z level:

[molkemon]

Exactly, screen rendering seems to actually make up more than 40% of the total core usage. (Out of 25% total cpu usage which DF has unpaused, it still needs ~10% when paused, and the only thing that actually needs cpu then is the screen rendering). This drops to around 5% if I go to a layer with nothing but a staircase in it or up in the sky with nothing to render at all.

As I said, my idea was to use twbt to make the screen renderer in the game process render NOTHING and instead having the screen rendering done by a seperate process which can run on a different cpu core. Seeing as the screen rendering takes ~10% of the total 25% available, this could potentially almost double fps in any scenario.

I also checked with process explorer, DF in windows uses 10 threads, most of them seem to do nothing at all though. One of the threads is being relegated to my ATI/AMD device driver, presumably that's the opengl rendering, it uses less than 1% cpu and also runs on a different core as mentioned before.

[mifki]

As I said, my idea was to use twbt to make the screen renderer in the game process render NOTHING and instead having the screen rendering done by a seperate process which can run on a different cpu core. Seeing as the screen rendering takes ~10% of the total 25% available, this could potentially almost double fps in any scenario.

The problem, as I said, is in synchronisation. You don't want a dwarf to appear twice on screen because while your rendering thread was rendering tile by tile, another thread moved that dwarf to another tile. That's why rendering thread pauses main loop while it's rendering, and this will have to be done regardless of whether it's a separate thread, process, whatsoever.