Print

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

Faster, no problems

Faster, problematic

Same speed, no problems

Same speed, problematic

Slower, no other problems

Slower, problematic

Doesn't work at all

[Darkond2100]

For users on Linux and OS X, run the df script, don't run the dwarfort.exe executable directly.

To simply put it, do you see the file called "df" in your Dwarf Fortress file? Use your terminal to open it. It should run the entire Dwarf Fortress game.

DO NOT RUN DWARF FORT.EXE! It will not work.

OK, I tried. It just says "There is no default application specidied to open the document "df"". What now?!?! I DOES give me a little option to "Choose Application"

You need to use the "Choose application" and from there you will need to change "recommended applications" to "All Applications"

Then find Terminal and select that and open it.

A little window should pop up as it runs through the basic programing code to run the file and then from there the game should then open.

Thank you very much, it worked perfectly. Now I'm working with the init and raws before I start a fort. Is that mean old cat bug still there?

[lizard]

Looking at the d17 thread, I see that specific fonts are required for ncurses mode.  However, adjusting konsole to terminus or the font specifically made for df from that thread http://dffd.wimbli.com/file.php?id=1854 doesn't fix my display problem.  Do I have to somehow reconfigure ncurses?

[RantingRodent]

[PRINT_MODE:VBO] Crashes immediately
[PRINT_MODE:FRAME_BUFFER] Smears the top and right edges of the screen. The smaller the window size, the more of the screen gets smeared. Was unable to read FPS with this setting due to this problem, but visually did not appear different from ACCUM_BUFFER

I ran my tests with the default init files, at the default windowed size, as well as windowed, maximized. My desktop resolution is 1680x1050.

The fresh embark I used is a 6x6 region with a bottomless pit and a river.

In each case, the FPS numbers are Menu/Reinhammers/Fresh Embark

40d18
[PRINT_MODE:STANDARD]
Maximized 18 / 5 / 6
Default 98 / 7 / 90

[PRINT_MODE:ACCUM_BUFFER][SINGLE_BUFFER:NO]
Maximized 18 / 5 /  12
Default 98 / 8 / 100

[PRINT_MODE:ACCUM_BUFFER][SINGLE_BUFFER:YES]
Maximized 18 /  2 / 12
Default 99 /  8 / 100

[PRINT_MODE:PARTIAL:0]
Maximized 18 / 6 / 4
Default 99 / 8 / 100

[PRINT_MODE:2DASYNC]
Maximized 9 / 4 / 7
Default 99 / 7 / 68

40D
[PARTIAL_PRINT:NO:2]
100 / 10 / 90

[PARTIAL_PRINT:YES:2]
100 / 10 / 100

[PARTIAL_PRINT:YES:0]
100 /  11 / 100

DXDIAG excerpt

Spoiler (click to show/hide)

Code: [Select]

------------------
System Information
------------------
Time of this report: 2/22/2010, 22:29:31
       Machine name: ANDREWSDESKTOP
   Operating System: Windows XP Professional (5.1, Build 2600) Service Pack 2 (2600.xpsp_sp2_gdr.091208-2028)
           Language: English (Regional Setting: English)
System Manufacturer: System manufacturer
       System Model: System Product Name
               BIOS: Phoenix - AwardBIOS v6.00PG
          Processor: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+,  MMX,  3DNow (2 CPUs), ~2.2GHz
             Memory: 1536MB RAM
          Page File: 1738MB used, 6226MB available
        Windows Dir: C:\WINDOWS
    DirectX Version: DirectX 9.0c (4.09.0000.0904)
DX Setup Parameters: Not found
     DxDiag Version: 5.03.2600.2180 32bit Unicode

---------------
Display Devices
---------------
        Card name: Radeon X1600/X1650 Series
     Manufacturer: ATI Technologies Inc.
        Chip type: ATI Radeon Graphics Processor (0x71C2)
         DAC type: Internal DAC(400MHz)
       Device Key: Enum\PCI\VEN_1002&DEV_71C2&SUBSYS_01701043&REV_00
   Display Memory: 512.0 MB
     Current Mode: 1680 x 1050 (32 bit) (60Hz)
          Monitor: Plug and Play Monitor
  Monitor Max Res: 1600,1200
      Driver Name: ati2dvag.dll
   Driver Version: 6.14.0010.6925 (English)
      DDI Version: 9 (or higher)
Driver Attributes: Final Retail
 Driver Date/Size: 7/21/2009 10:54:20, 325120 bytes
      WHQL Logo'd: Yes
  WHQL Date Stamp: n/a
              VDD: n/a
         Mini VDD: ati2mtag.sys
    Mini VDD Date: 7/21/2009 11:30:48, 3565056 bytes
Device Identifier: {D7B71EE2-3282-11CF-FE68-7A21A1C2CB35}
        Vendor ID: 0x1002
        Device ID: 0x71C2
        SubSys ID: 0x01701043
      Revision ID: 0x0000
      Revision ID: 0x0000
      Video Accel:
 Deinterlace Caps: n/a
         Registry: OK
     DDraw Status: Enabled
       D3D Status: Enabled
       AGP Status: Enabled
DDraw Test Result: Not run
 D3D7 Test Result: Not run
 D3D8 Test Result: Not run
 D3D9 Test Result: Not run


[fourthgeek]

Hey everyone,

I had a suggestion for future attempts to improve the speed of DF.

At the software level, what happens is you send some commands to OpenGL and when they are done you begin the next frame. Speedup/slowdown can be measured linearly: if it takes twice as long to render a frame then it's twice as slow. This can be measured as seconds/frame.

Frames per second, however, is frames/second, an inverse function. A doubling of FPS is not necessarily a doubling of speed. Since the whole point of these 40dX updates is to improve the rendering pipeline, you should perhaps consider measuring it this way in the future. Calculating milliseconds/frame is also easier than frames/second (just time it). This way you can more quantitatively measure exactly by what % this version is faster or slower.

[Shoku]

I had a crash after assigning embark points and hitting e.
I had to assign keybindings to allow the embark screen to move the local selection around instead of hopping around to the next screen.
Did river tiles always redraw themselves when it's paused in a cursor mode and you're moving it around? (I usually play with numbers so probably.)

My starting 7 zip about at 270 fps but it still does the 20 second slowdown thing, however two 50 fps or so now. So nice increase except for that part I don't like.

[i2amroy]

This is just a thing that popped up for all of those mac people out there who are not quite so good with the command window. Someone created this file back in d11 so that if you place it in the same folder as the .exe file then you can click on it and it will run the same as if it were a normal application on macs. This means you don't have to use the command window at all. I have been using this and just thought that it might be time to re-upload this. I did not create this, but since the old forum posts were deleted it was no longer accessible.

Link: http://dffd.wimbli.com/file.php?id=1882

[guebstrike]

After discovering my init.txt mistake, I re-tested with a clean d18 folder with no graphics. The results were similar to my first results.

In the 2D modes I get 9 ( 9 ) FPS, above a new wagon and in the menus. Except that this time it doesn't break the graphics...since there are none.

Using a clean install of 40d, I get 198-202 fps above a new wagon with Partial_Print:YES:2, and 175-202 fps with P_P:NO:2.

[RantingRodent]

After discovering my init.txt mistake, I re-tested with a clean d18 folder with no graphics. The results were similar to my first results. In the 2D modes I get 9 ( 9 ) FPS, even in the menus. Except that this time it doesn't break the graphics...since there are none.

What window size do you play at? I found it made a huge difference.

[guebstrike]

After discovering my init.txt mistake, I re-tested with a clean d18 folder with no graphics. The results were similar to my first results. In the 2D modes I get 9 ( 9 ) FPS, even in the menus. Except that this time it doesn't break the graphics...since there are none.

What window size do you play at? I found it made a huge difference.

My cheap monitor only gets 1024x768 so that might be part of the problem.
I tried 2D mode windowed 1024x768, and fullscreen 1024x768 and 0x0. It was always the same.

[Veroule]

So far I have to say D18 is a definite speed improvement.  The change in the FPS counter eliminating the complex loop helped.  I believe it can still be made better.

Memory usage can get a little bit high for such a simple thing.  Also the usage of a queue with all of its dynamic capabilities is overkill.

I would suggest a small circular buffer of 8 integers for each of the fps counters.  Instead of recording timings record a count frames done in a given second; dropping from the count as they are expired and adding the latest to the count.  If you keep the buffer size on a power of 2 you can avoid divisions and won't need any sort of index counter beyond the time.

Rough code for doing this:

Spoiler (click to show/hide)

int frame_count[8]={0,0,0,0,0,0,0,0};
int frame_sum=0; int last_time=0; int cur_frames=0; int calculated_fps=0;

void do_update_fps(...localize the globals...) {
 cur_frames++;
 int now=SDL_GetTicks()/1000;
 if (last<now) {
  //have to loop to cover large delays for things like stone stocks
  do {//if this loop is long the user is already unhappy before we got here
   frame_sum -= frame_count[last&7];
   frame_count[last&7]=0;
   last++;
  } while (last<now);
  frame_count[last&7]=cur_frames;
  cur_frames=0;
  calculated_fps=frame_sum>>3;
 }
}

One of the benefits of this method is that the number will only change once per second.

Another small thought, don't calculate the FPS when the counter won't be displayed.

Edit---looked at the wrong commit and made inaccuarate comments.  All fixed now.

[Veroule]

Regarding PP and speed.  In graphics.cpp at lines 251-260 you transfer the screen data from one buffer to another.  You can eliminate these lines if you make the graphicst class use a pointer to a buffer, and swap the pointers with each call of graphicst::display.  Remember that specific buffer does not require any information retained from one frame to the next.

Doing it only requires changing where the arrays are defined, and adjusting graphicst::display to preform the swap. Such a change will improve speed and also make things easier for having a dynamically sized array at a later date.

[Narmio]

I've tested this on an eight-core Xeon X5472 at 3Ghz, with an NVidia GTX 285 and Vista.  If it matters, this is a Mac running under Boot Camp.  I'll try it on the OSX side some time to compare.

DF is set to 200x100 tiles. Haven't touched anything else except to set sound and intro movies off.  I've embarked on a 6x6 area encompasing a human town just to get some movement and activity happening.  Tests are from a new save, just letting the game run for a minute without giving any orders.

I'm assuming the second number in brackets after the FPS is the GFPS.  It's left at the default 20.

Standard/No:  95-115 FPS.  20 GFPS. 
Standard/Yes:  Screen doesn't appear to be updating.  I can get the menu to appear after clicking a few times, but nothing is rendering at all. 

2D/No: 13 FPS & GFPS.
2D/Yes: 13-14 FPS & GFPS.
2DASYNC/No: 13 FPS & GFPS.
2DASYNC/Yes: 14 FPS & GFPS.
2DHW/No:  13 FPS & GFPS.
2DHW/Yes: 13 FPS & GFPS.

So, pretty consistently atrocious on all the 2D modes for me.  Any way I can get you more data on what might be happening with those?

PARTIAL:0/No:  105-115FPS.  20 GFPS.   No flickering at all, so I won't test with higher partial:N numbers.
PARTIAL:0/Yes: Same lack of rendering problem as with STANDARD.  This happened with all the 3D SINGLE_BUFFER: YES options so I've omitted them after this.
ACCUM_BUFFER/No: 105-117FPS.  20 GFPS.
FRAME_BUFFER/No: 105-110FPS.  20 GFPS.
VBO/No: Crash on startup.

So, for me, all the 3D modes bar VBO seem to give basically the same consistent results as STANDARD. No flickering, no noticable artefacts.  All very playable. Paused framerates in all the working 3D modes shot up to 1000, the cap, so I didn't include that. I did notice that when I moved the viewpoint deep underground to where there were no revealed tiles the framerate climbed up to ~145 or so, which seems (to me) to indicate that there's still some slowdown coming from the rendering - remove the creatures and structures to render and the simulation speed goes up, despite the simulation itself being unchanged.

Hope my data is helpful.  I was wondering, though, could we see an updated and complete description of what each of the 2D and 3D modes does?  In the OP of this thread or in the init file itself?  I've sort of cobbled together an understanding of most modes from reading the progress of this project, it's something I'd like to see all in one place.

[Qiu]

Hi.
PowerPC mac with os X 10.4.11 here.
I'm sorry to report that 40d18 is much slower than 40d10 (the fastest version for me so far)

using the same savegame 40d18 is at 11fps while 40d10 is between 40 and 50fps, a really big difference indeed

the weird thing is that 40d18 seems to deal with the *paused* mode differently, as it gives me around 14fps while paused whereas 40d10 gives me 370fps! (with fps cap at 400).

Hope this helps somehow  good luck and thanks for the hard work 

PS: GFPS is at 20 for 40d18 and 25 for 40d10.

edit : oh, and using accum_buffer for both as it is the fastest for me.

[Veroule]

Still working through all the recent commits and getting better aquianted with where new bugs may lie. 

Looking at the commit from 2/14 regarding implementing mod state tracking since SDL's is broken:

First no wonder I could never figure out what was the cause of the old Alt-Tab bug.  Glad you found it.
Second you have this comment

// However, since SDL ignores(?) ctrl and alt when translating to
// unicode, we want to ignore unicode events if those are set.

It isn't actually ignoring any of them, but it also is not taking into account which are used to generate that unicode value.  If you press Ctrl+c for a unicode binding it properly reports 0x03 as the unicode value.  If you press Shift+c it properly reports 0x47 as the unicode value.  I can't think of any standard Alt ones right now since most of them require multiple presses with retained VKEY's.

The Windows API supplies both forward (VKEY+mods->unicode) and reverse (unicode->VKEY+mods) translations.  I am sure other platforms have similar bidirectional functions.  The right way to do it is to run the current keyboard state through the forward translation, then run the unicode through the reverse, and finally mask the current mods with those that the reverse translation reported as being used.

Unfornately SDL does not provide access to such an API call, and makes no attempt to use such a call on any platform.  Perhaps you should contact the SDL dev team about improving this.
Finally, you aren't taking CapsLock into account.  Seems to be an oversight, but maybe it is intentional since SDL is somewhat weak on reporting the actual state of the lock.

[Kerrz]

Hi. I'm not testing too thoroughly because I have too much fun actually PLAYING the game, but I just want to chime in on a few things.

I, too, have the cat_mouth bug that has been mentioned. When I load up my saves from d16 from Mayday, I get the following error message, which crashes out the program:
"Missing Creature Body Definition: CAT_MOUTH"

Also, some of the tiles seem to have shifted. My turtles are showing up as gemstones, and my magnetite (which used to be butterflies) is now the same as sand.

Now, this is important, so I'm going to bold it and all that:
If you are upgrading from Mayday's and having issues, go back to your original Mayday zip file and extract ONLY the RAW folder overtop of the new one from d18. Replace everything in the raw folder.

Mayday's uses a set of modified raws. Version d18 does not. So you must modify the raws or your saves won't work.

Go forth and have fun.