Print

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

Faster than 40d, no problems

42 (26.1%)

Faster than 40d, problems

72 (44.7%)

No slower than 40d, no problems

14 (8.7%)

No slower than 40d, problems

16 (9.9%)

Slower than 40d, no problems

2 (1.2%)

Slower than 40d, problems

3 (1.9%)

Doesn't work (please explain)

12 (7.5%)

Total Members Voted: 160

[Baughn]

I did, but as I have no idea how to find the refresh rates on linux or OS X, I'd rather not make things more heterogenous. Besides, the default of 50 is lower than any monitor out there (or at least not higher), so if you just don't increase it..

The G_FPS multiplier lock has been switched out for a dynamic one, as I mentioned earlier. There should be no further issues with than in 40d5.

[Thndr]

Note entirely sure if this is part of the simultaneous keypress crash or not, but could be related. Whenever I hit CTRL+ANY KEY it exits//crashes immediately, but only if the focus is on DF itself.

But so far, from Dwarf Accelerated 40d to 40d4, my 75 population 3x3 fortress has an increase of 7-10 fps! (from 37-45FPS to 44-52FPS)

[Veroule]

I did a little bit of searching to see if I could come up with andything for Linux or OSX regarding detecting the refresh rate.  Sadly I could find anything the had a clean API, and most of the web pages I looked at tripped all over my javascript security.  I am very strict, using document.write for your whole page is just dumb.

Anyhow it seems like only Windows provided a mechanism to get monitor refresh rate information, and even though I would like to see more proper states used I agree that it has to be consistently implemented on all platforms.  I will just never use full screen since any invalid display state can lead to a graphics driver instability.  Such instability often results in the driver partially crashing and running in a crippled mode until a system reboot.

[xylo]

Interesting bug.  I can crash it sort of the same way.   If I press Shift+M it crashes every time.

Problem signature:
  Problem Event Name:   BEX
  Application Name:   Dwarf Fortress.exe
  Application Version:   0.0.0.0
  Application Timestamp:   4957a0a2
  Fault Module Name:   MSVCR90.dll
  Fault Module Version:   9.0.21022.8
  Fault Module Timestamp:   47313dce
  Exception Offset:   0006c955
  Exception Code:   c0000417
  Exception Data:   00000000
  OS Version:   6.0.6001.2.1.0.256.1

  Locale ID:   1033
  Additional Information 1:   cada
  Additional Information 2:   35e498a46227a4acf7990f01cc94951d
  Additional Information 3:   575c
  Additional Information 4:   dc5385b7f94ccc1bddd79f350e07770a


As far as i can tell, DF calls something and we fault into this:

_CRTIMP void __cdecl _invalid_parameter_noinfo(void)
{
    _invalid_parameter(NULL, NULL, NULL, 0, 0);
}

Before that in DF:

00955BAE  mov         eax,dword ptr [esi+4]
00955BB1  cmp         byte ptr [eax+15h],0
00955BB5  je          00955BBB
00955BB7  call        edi 
00955BB9  pop         edi     <----- fault here(?)

[Xgamer4]

That's the "Shift makes everything die" bug I mentioned above. Shift + Anything (heck, just shift on its own) makes DF crash. It's aggravating, to say the least.

[Savok]

...oh god. I've got an 8x11 embark region with ~64 z-levels, a pit, a cave, a magma pool, HFS, (35 visible creatures), a brook, and a terrific waterfall, but temp and weather off. I'm getting 180fps. I'm getting one hundred and eighty frames per second.

Given that I used to get that on a ~35 z-level 4x4 embark region with nothing but magma, a small brook, sand, and more sand, that's pretty fricking awesome.

[codezero]

In my 150 dwarf fort there's no discernable difference in speed between 40d and 40d2 (~35fps) and 40d4 is less than half that. Started the fort in 40d2.

GFPS:8
PP:NO
dualcore 1.6ghz
integrated card
1G ram

[PTTG??]

I've tested this with a migrated save from the previous "real" release. I got about twice the frame rate, and some slight stuttering when scrolling.
Unfortunately, it crashed when I attempted to designate a ramp under a staircase, but that may have been a fluke. I'm testing a regular game now.

EDIT:
I've tried out a new game with a new world and it crashed when I tried to designate some trees to be cut down. This looks like a pattern here; both times where just after I pressed enter to start designating. This needs more testing before I'd say that was the case.

[Andir]

It does run under 64-bit Debian using ia32-libs, an extracted libSDL_image-1.2.so.0 link and the libSDL_image-1.2.so.0.1.5 file from libsdl-image1.2_1.2.6-3_i386.deb  I got the .deb from the Debian package site: http://www.debian.org/distrib/packages#search_contents I just had to search the contents for the filename above.

[Narmio]

EDIT:
I've tried out a new game with a new world and it crashed when I tried to designate some trees to be cut down. This looks like a pattern here; both times where just after I pressed enter to start designating. This needs more testing before I'd say that was the case.

OK, I've done some testing with the new version and found out some more stuff about this simultaneous input crash bug. 

What happens for me is that if I press Shift + any other key, DF crashes as soon as I release the keys.  I thought at first it had something to do with keyrepeat and scrolling, but I've duplicated the shift+anything behaviour everywhere, even on the main menu just after launching DF.

Oh, and I'm on Vista64.

[Deto]

I'm runnin 40d2 still. I haven't myself had any issues so far.

In 40d I had approx 15-24fps after first year on 4x3 or 4x2 map.
On 40d2 I have 80 fps on 6x6 map (I got fps limited to 80)

On selfmade ~40 tile wide waterfall down 4 z-levels straight in to a aquifer... it dropped to 50 fps

My comp has decent amount of ghz, good amount of memory, but very very very bad onboard 3D card. The accelerated DF really improved everything on me.

[Mithaldu]

Read in the dev notes that there is an issue with start-up delay in key press repeating. Had the same problem with lifevis and solved it with this call:

    glutIgnoreKeyRepeat(1);

Maybe SDL has something similar?

[Baughn]

It does, but if I set that it becomes pretty much impossible to do anything /but/ scroll, as the keys repeat almost instantly. You keep getting doubles.

There are solutions, but they're along the lines of "reimplement key-repeat"

[Baughn]

In my 150 dwarf fort there's no discernable difference in speed between 40d and 40d2 (~35fps) and 40d4 is less than half that. Started the fort in 40d2.

GFPS:8
PP:NO
dualcore 1.6ghz
integrated card
1G ram

Try with PP YES:0. You might get flickering, but that's fixed for d5, and the framerates should be representative.

[Baughn]

I've tested this with a migrated save from the previous "real" release. I got about twice the frame rate, and some slight stuttering when scrolling.
Unfortunately, it crashed when I attempted to designate a ramp under a staircase, but that may have been a fluke. I'm testing a regular game now.

EDIT:
I've tried out a new game with a new world and it crashed when I tried to designate some trees to be cut down. This looks like a pattern here; both times where just after I pressed enter to start designating. This needs more testing before I'd say that was the case.

I can't reproduce that one, but basically everything related to pressing keys is unreliable in d3/d4, subject to tiny variations in STL and the way it handles a buggy class. Let's hope it goes away in d5 too.