Topic: FotF: Dwarf Fortress 40d19 (Read 163279 times)

Meteorswarm · « **Reply #150 on:** March 06, 2010, 02:23:57 pm »

Quote from: shadow_slicer on March 06, 2010, 02:16:38 pm

@Meteorswarm: I think you can go ahead and try head. Your problem might be because the posted df was linking to ncurses instead of ncursesw. Baughn has supposedly fixed this in head.

If that still doesn't work, you could try tricking df into using ncursesw:
"LD_PRELOAD=/lib/libncursesw.so.5.7 ./dwarffortress.exe"

After applying the head, I now get an error:./dwarfort.exe: error while loading shared libraries: libjpeg.so.8: cannot open shared object file: No such file or directory

I have libjpeg62 installed, which is the only package in the repos that seems to include libjpeg. Furthremore, I have libjpeg.so and libjpeg.so.62, but not libjpeg.so.8. I don't know much about how the libraries work, so I can't diagnose further.

Also, how do I use that LD_PRELOAD line? Where do I put it, or do I run it in the shell?

Rafal99 · « **Reply #151 on:** March 06, 2010, 02:35:34 pm »

Just did some intensive testing of 40d vs 40d19_2 with different modes.
I was loading the same save with a screen pointed at an area with many moving dwarves and many items, and was watching the FPS counter for about a minute or two for each mode.
G_FPS_CAP was set to 25.
In case of 40d19_2 the number in brackets always stayed close the cap (24 or 25), so I won't post this number below.

40d:
PARTIAL_PRINT:NO
19-24
PARTIAL_PRINT:YES:5 (any number less than that flickers, and even this starts flickering sometimes)
40-55

40d19_2:
STANDARD
35-50 / 30-55
PARTIAL:0 (this only worked with SINGLE_BUFFER:YES, with NO it was flickering until I set the <number> to 2)
45-55 / 40-65
2D and 2DSW (both gave similar results)
35-45 / 30-50
ACCUM_BUFFER (this only worked with SINGLE_BUFFER:YES, with NO it was flickering)
45-55 / 35-60
FRAME_BUFFER (top half of the screen was filled all with one color, I couldn't even load a game)

VBO (not working for me, only some colorful lines on screen)

I tested all these modes with SINGLE_BUFFER both YES and NO, and for all of them except PARTIAL and ACCUM_BUFFER it didn't make any noticable difference.
My graphics card is quite ancient (Radeon 9600 Pro) so I didn't even try the SHADER mode.

I haven't played an actual game in 40d19_2 yet, but 40d18 was stable for me.

Also in case I haven't said that already: Thank you for all of your great work!
The PARTIAL and ACCUM_BUFFER modes work the fastest for me, and are already better than 40d.
And all the other awesome changes in these releases... I especially love the zooming!

guebstrike · « **Reply #152 on:** March 06, 2010, 02:54:16 pm »

My PC:

Spoiler (click to show/hide)

I did three rounds of tests. The first was watching 7 dwarves wrestle for a few minutes in their new barracks. Set to fps cap: 100(10).
40d19 has strange new graphical weirdness. When graphics is turned on, in all modes, the dwarves, their pets, and enemies that were on the screen at the time appear in the menus. They stay there even when I save and exit to the main menu. They go away after I load a save. It really isn't a problem, and is kind of useful when trying to spot Dark Gnomes. 40d19_2 did not change this.
Also, when set to PROMPT, 40d19 and 19_2 go to windowed mode when you select fullscreen. Fullscreen works when you set it to NO.
ARB_SYNC always crashes before loading.
Since a lot of these pinged out at max frame rate, I redid many of the tests with fps cap 200/10 and the results were the same. The 100s are really the fps.
Tested all of the modes using Ranting Rodent 1.07a graphics. I re-did many of the tests using a clean install with Mayday raws and art only, because I was worried that the language files required for Ranting Rodent would not be compatible. But, the results were the same. I also retried many of the tests in fullscreen versus windowed, and with graphics on or off, these really didn't make a difference.
40d19:
Standard: fps: 75-96 (9-10)/74-102
Partial:1: 80-95 (9-10)/80-102
VBO: 91-100 (9-10)/89-102
2D: 34-38 (9-10) In all 2D modes, and also in 40d18, no matter what the windows settings are, the right side of the screen is cutoff just beyond "FPS: ##(##)". This cuts off about half of the tab map window.
2DHW: 37-40 (9-10)
2DSW: 19-42 (9-10) The Print mode instructions now say "2DSW" instead of "2DHW"
2DASYNC: 37-42 (9-10)
ACCUM_BUFFER: 95-100 (9-10)/80-102 (Fast, but it now has weird colorful static in the black space. It didn't affect the game. 40d19_2 cleared most of this static.)
FRAME_B: 97-100 (9-10)/85-104 (VERY FAST)
FRAME_B, single_Buffer: YES (the only mode where single works): 85-95 (9-10)/80-100
40d19 NO graphics: Flickers horribly in fullscreen.
40d19 NO graphics, standard, windowed 88-93(9-10)/88-99 (people and animals don't show up in menus with no graphics.)
40d19 clean install with no additional graphics: standard: 85-96(9-10)/80-100

40d18 clean install (except for the save game) with Ranting Rodent 1.07a graphics, fullscreen: (no dwarves or animals in menus like in 40d19)
Standard: 74-84(9-10)
Partial:1 74-88(9-10)
2D: 8 ( 8 )
2DHW: 8 ( 8 )
2DASYNC: 8 ( 8 )
ACCUM_BUFFER: 75-82(9-10)
FRAME_B: 74-82(9-10)
VBO: crashes on start
Standard, Fullscreen, no graphics: (Does not flicker like 40d19) 79-82(9-10)

40d clean install with Ranting Rodent 1.07a graphics, fullscreen (no dwarves or dogs in menus)
P_P:NO:2: fps: 83-98
YES:2: crazy flicker
windowed, YES:2 85-102
fullscreen, YES:10 85-102

I redid some of the tests using a different save with 87 dwarves and Mayday raws and art in new folders. For this save I watched the default position which was over the busy fort entrance.:
40d19:
Standard: fps: 24-31 (9-10)/25-32
Partial:1: 26-29 (9-10)/27-31
VBO: 26-30 (9-10)/28-32
2D: 10-12 (9-10)
2DASYNC: 9-12 (9-10)
FRAME_B: 25-32 (9-10)/20-33

40d18: Standard fps: 22-25 (9-10)
Partial:1 18-25 (9-10)

40d: P_P:NO:2 25-31 fps
P-P:YES:2 25-31

At this point, 40d19_2 was released, and the link to Reinhammers was posted so I redid most of the tests with Reinhammers. I let the view rest on the saves starting location, which is on the bottom level with no activity. After a minute, I recorded fps then switched to the surface, where I zoomed all the way out so that the fps numbers were just barely readable then I made a second fps reading.
I used Mayday raws and art.
40d19_2 clears up the static in Accum_B mode, but the dwarves, dogs, etc are still visible in the menus.
40d19_2: Standard 5-7 (5-7) / 5-7 (in Reinhammers, all #s were consistent like this, so I'm just going to call it 5-7.)
Standard, no graphics 5-7
Partial:1 5-7 fps (zoomed out on surface: 3-4)
Partial:2 5-7
Partial:9 5-7 (4-6 zoomed out)
VBO: 4-7
2D: 4-5
2DHW: 4-5
2DSW: 4-6
2DASYNC: 4-6
Accum_B: 5-7 (4-6 zoomed out)
Frame_B: 5-7 (average 7!) (5-6 zoomed out)
Frame_B, single buffer: 5-7 (average 6) (4-7 zoomed out)

40d18: Standard 4-6 (3 zoomed out)
Partial:1 5-6 fps (zoomed out on surface: 3-4)
Partial:2 5-6 (zoomed out on surface: 3-4)
Partial:9 5-6 (zoomed out on surface: 3-4)
VBO: crashes
2D: 3-4 (average 3)
2DHW: 3-4
2DSW: 5-6
2DASYNC: 3-4
Accum_B: 4-6 (3 zoomed out)
Frame_B: 5-6 (3-4 zoomed out)

40d: (this time around I noticed 40d doesn't like Mayday's dfg21's raws so I used dfg16's raws instead)
Partial_P:NO:2 6-8
YES:1 6-8
YES:2 6-8
YES:9 6-8

40d19 is faster than 40d18 across the board, and is equivalent to or a fraction slower than 40d. Keep up the good work!

Untelligent · « **Reply #153 on:** March 06, 2010, 03:10:07 pm »

On the subject of the annoying FPS counter: since it apparently wasn't bothering anyone before you changed it, would it be possible to add init options to 1) move it back to the place it used to be and 2) only show the GFPS (or also only show the other FPS, I suppose)?

I suggested this a thread or two ago, but I don't think it went anywhere.

Wh1tefang12 · « **Reply #154 on:** March 06, 2010, 03:32:45 pm »

I found a glitch im using d18 but i also had it happen in d19 (switched back to 18 after the glitch happened) If i press enter while on the farm plot with nothing selected the game crashes, im not sure if it matters what month but this time around i know it happened when selecting for winter.

Veroule · « **Reply #155 on:** March 06, 2010, 04:52:31 pm »

Just a general little piece of coding knowledge:

Quote from: darius on March 06, 2010, 02:04:17 pm

int bold = min(max(int(texelFetch(data, offset_tile+3).a), 0), 1);

Will come out to something like this in assembly:
push @data
push @offset
call texelFetch
cmp eax,00
jge :max
mov eax,00
:max
cmp eax,01
jbe :going
mov eax,01
:going

int bold = (int(texelFetch(data, offset_tile+3).a)!=0);
Will come out like this given a compiler that recognizes 0 for what it is. Some rare compilers will do this with just a bool type cast.
push @data
push @offset
call texelFetch
test eax,eax
sete eax

The shader is speed critical coder and shaving those clock cycles off will add up. If you can count on 0 meaning no bold and any other value meaning bold then it works perfectly. I am not sure how any of the shader compilers do it but the assembly produced should be quite similar.

You can also spell it out for the compiler, with about a 90% chance it will get optomized to a single test, set pair:
int bold;
if (texelFetch(data, offset_tile+3).a) bold=1;
else bold=0;

Baughn · « **Reply #156 on:** March 06, 2010, 04:57:23 pm »

I'm not saying I know how that works - I'm very definitely not much of a shader writer, fortunately the gpu load isn't all that high anyway - but I do know that the last thing you want is an if. Well, unless it's one that can be compiled to a non-if instruction, which that may be.

So - how sure are you that clamp doesn't compile to a single instruction?

DrD_AVEL · « **Reply #157 on:** March 06, 2010, 05:14:55 pm »

Core2Duo E8600 @ 3.0 GHz
ATI Radeon 5770 ( catalyst v 10.1, supports DX11)
Windows XP SP3 (x86)

classic size of window = 1280x400 => 80x25 tiles,
map = reinhammers,
every run I press F1 to move screen to the same location of fortress.

40d16
---

[PRINT_MODE:STANDART] 18-20 (15 min .. 22 max)

[PRINT_MODE:PARTIAL 20-22
[PRINT_MODE:ACCUM_BUFFER] 21-24
[PRINT_MODE:FRAME_BUFFER] 19-21
[PRINT_MODE:VBO] - game is not start.

40d19_2
--------

[PRINT_MODE:STANDART] - 21-25 FPS (18 min .. 32 max), normal colours

[PRINT_MODE:2D] - 21-25 FPS , mismatch of tileset colours
[PRINT_MODE:2DSW] 22-23 FPS , mismatch of tileset colours
[PRINT_MODE:2DASYNC] 21-24 FPS , mismatch of tileset colours
[PRINT_MODE:ACCUM_BUFFER] 24-27 FPS, normal colours
[PRINT_MODE:FRAME_BUFFER] 23-25 FPS, normal colours
[PRINT_MODE:VBO] = 24-26 FPS, normal colours

[PRINT_MODE:SHADER]= CRASHES with error:

Spoiler: "errorlog.txt" (click to show/hide)

Veroule · « **Reply #158 on:** March 06, 2010, 05:33:27 pm »

First test for d19_2: turned off sound, intro, and mouse, turned on fps counter.
Main menu: FPS 103(20)/160ish 99% cpu usage

Set FPS cap to 0 for max speed test
FPS 150500ish(20)/170000ish, now I expect 99% cpu usage and get it.

Still not sleeping right, I will look over the code again.

Regarding the shader.vs and my assembly comments. My assembly comments are mostly a general programming thing. I no idea what the shader compiler produces, and know it may be different with each manufacturer and driver version.

I am guessing that the GPU uses a mostly similar instruction set to x86. I am also going to guess that "clamp(x,y,z)" is a macro for "max(min(x,y),z)"; and "max(x,y)" is a macro for "x>y?y:x", as a matter of basic logic that would be an if. That would make clamp 2 if's.

Try a few different things, and see what is fastest on your system.

koitsu · « **Reply #159 on:** March 06, 2010, 05:34:10 pm »

Quote from: Meteorswarm on March 06, 2010, 02:23:57 pm

Quote from: shadow_slicer on March 06, 2010, 02:16:38 pm
@Meteorswarm: I think you can go ahead and try head. Your problem might be because the posted df was linking to ncurses instead of ncursesw. Baughn has supposedly fixed this in head.

If that still doesn't work, you could try tricking df into using ncursesw:
"LD_PRELOAD=/lib/libncursesw.so.5.7 ./dwarffortress.exe"

After applying the head, I now get an error:./dwarfort.exe: error while loading shared libraries: libjpeg.so.8: cannot open shared object file: No such file or directory

I have libjpeg62 installed, which is the only package in the repos that seems to include libjpeg. Furthremore, I have libjpeg.so and libjpeg.so.62, but not libjpeg.so.8. I don't know much about how the libraries work, so I can't diagnose further.

This means dwarfort.exe is linked against libjpeg.so.8 (run ldd -v on dwarfort.exe and you'll see it mentioned). You need to install whatever package on Ubuntu provides libjpeg.so.8. I'm guessing there's a "libjpeg8" package that exists somewhere. Contact your OS distributor/vendor for assistance here.

Quote from: Meteorswarm on March 06, 2010, 02:23:57 pm

Also, how do I use that LD_PRELOAD line? Where do I put it, or do I run it in the shell?

Avoid using LD_PRELOAD or LD_LIBRARY_PATH. I'll happily flame the hell out of anyone who recommends otherwise -- the only time it should be used is by developers who are familiar with the repercussions/risks.

ELF (read: ld.so) configuration utilities on present-day OSes (FreeBSD, Linux, OS X, Solaris 8 onwards) should be used, not environment variables. Each OS has its own way of configuring the ELF loader; FreeBSD uses ldconfig and libmap.conf. Linux uses god-knows-what (probably ldconfig). OS X uses ldconfig and something similar to libmap.conf. Solaris uses crle.

Be aware that even running any of the above configuration utilities can in fact break your system. Read man pages and online docs before considering running any of them.

Glad to see Baughn fixed the library linking problem (re: now using libncursesw not libncurses). :-)

xax · « **Reply #160 on:** March 06, 2010, 05:41:53 pm »

Quote from: Meteorswarm on March 06, 2010, 02:23:57 pm

After applying the head, I now get an error:./dwarfort.exe: error while loading shared libraries: libjpeg.so.8: cannot open shared object file: No such file or directory

I have libjpeg62 installed, which is the only package in the repos that seems to include libjpeg. Furthremore, I have libjpeg.so and libjpeg.so.62, but not libjpeg.so.8. I don't know much about how the libraries work, so I can't diagnose further.

I got that same problem too, at first, and I... symlinked libjpeg.so.8 to libjpeg.so.62. After that, it worked fine! Just... remember to remove that before upgrading your libjpeg package in the future.

(there's no package in Debian that has libjpeg.so.8, and I suspect it might be the same way in Ubuntu at the moment.)

Phwoar · « **Reply #161 on:** March 06, 2010, 05:47:43 pm »

I believe the 2d version could be sped up by creating an algorithm that combines tiles close to each other into one blit.. preferably with an input that lets you specify (after experimentation) the best blits:blit-size ratio for your processor/gpu.

For example, consider this splice:

Code: [Select]

 ` M . , , ,

 . , ` M ` .

 . d ' , . `

If the dog moved to the right, we'd have to draw a comma where he was, and replace the apostrophe with a d. I expect in the vast majority of cases, it would be quickest to draw these to an intermediary bitmap and send it to the screen in one blit.

Code: [Select]

 ` M . , , ,
             
 . , ` M ` .
  +---+        
 .|, d|, . `
  +---+

If the dog moved diagonally, you would have to re-blit a four tile area to show two new tiles.. and that's where you get to the point of having to choose the most efficient blit size to new data ratio.

Code: [Select]

 ` M . , , ,
  +---+          
 .|, d|M ` .
  |   |      
 .|, '|, . `
  +---+

If the mule (or whatever it is) also moved, would you do it as one big blit, or two smaller ones? Eight tiles for four new ones in one blit, or Six tiles for four new ones in two blits?

Code: [Select]

 ` M . , , ,
  +---+---+       
 .|, d . M|.
  |       |  
 .|, ' , .|`
  +-------+    

 ` M . , , ,
  +---+---+       
 .|, d|. M|.
  |   +---+  
 .|, '|, . `
  +---+        
  
  or even

 ` M . , , ,
    +-----+       
 . ,|d . M|.
  +-+-----+  
 .|,|' , . `
  +-+

Unfortunately, struggling to recall what this process is called, or I'd provide some reference links.. Does anyone else know off-hand? Anyone have the smarts/time to look at implementing/testing this?

mostevil · « **Reply #162 on:** March 06, 2010, 06:04:58 pm »

Seems a little faster to me.
However on a complex fort in all modes if I maximise the window the frame-rate drops of massively. (big monitors, about 12 * the number of tiles)

On a complex fort with all the trimmings, When paused its framerate is maxed out at the default window size, when I maximise the screen it drops to a rather poor 10FPS.

I'm assuming pausing shuts off most of the simulation. It doesn't seem like there should be anything like enough drawing to cause so significant a slowdown, I've not been source diving but it seems calculating what to display is looking overly expensive. Needs profiling really, but for my money there may be much more to be gained from things like spacial partitioning of the object data than reworking the drawing.

(if that is correct running the display in a different thread to the sim would have a potentially serious impact too.

- sorry)

There are a few undrawing related things happening that I'd not noticed in 40d. Some jobs don't seem to get done anymore, e.g. carpenters and smiths won't build animal traps.

Malicus · « **Reply #163 on:** March 06, 2010, 06:19:34 pm »

I forgot to mention it, but 40d19_2 maxes out a core on the title screen for me, too. It did this in earlier d# versions, but not in 40d16.

Quote from: mostevil on March 06, 2010, 06:04:58 pm

There are a few undrawing related things happening that I'd not noticed in 40d. Some jobs don't seem to get done anymore, e.g. carpenters and smiths won't build animal traps.

Trappers are the ones who make animal traps, oddly not the dwarves who would NORMALLY use that workshop. It's been like that since before 40d#.

Exponent · « **Reply #164 on:** March 06, 2010, 06:55:19 pm »

Quote from: Phwoar on March 06, 2010, 05:47:43 pm

I believe the 2d version could be sped up by creating an algorithm that combines tiles close to each other into one blit.

Unfortunately, struggling to recall what this process is called, or I'd provide some reference links.. Does anyone else know off-hand? Anyone have the smarts/time to look at implementing/testing this?

Off the top of my head, perhaps you're thinking of dirty rectangles?

News:

Poll

Having tested both 2D and STANDARD, how is 40d19 compared to 40d?

Author Topic: FotF: Dwarf Fortress 40d19 (Read 163279 times)

Meteorswarm

Re: FotF: Dwarf Fortress 40d19

Rafal99

Re: FotF: Dwarf Fortress 40d19

guebstrike

Re: FotF: Dwarf Fortress 40d19

Untelligent

Re: FotF: Dwarf Fortress 40d19

Wh1tefang12

Re: FotF: Dwarf Fortress 40d19

Veroule

Re: FotF: Dwarf Fortress 40d19

Baughn

Re: FotF: Dwarf Fortress 40d19

DrD_AVEL

Re: FotF: Dwarf Fortress 40d19

Veroule

Re: FotF: Dwarf Fortress 40d19

koitsu

Re: FotF: Dwarf Fortress 40d19

xax

Re: FotF: Dwarf Fortress 40d19

Phwoar

Re: FotF: Dwarf Fortress 40d19

mostevil

Re: FotF: Dwarf Fortress 40d19

Malicus

Re: FotF: Dwarf Fortress 40d19

Exponent

Re: FotF: Dwarf Fortress 40d19