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

[Ampersand]

So far I haven't had any crashes with the new version. Frame rates are significantly better than before. As an experiment I designated a few hundred stones to be dumped some fifty or so tiles away 15 z levels away, with 50 dwarves in the fortress. The frame rate was consistently between 100 and 200, with the max frame rate set to 200.

The only thing that struck me as odd is that occasionally the frame rate would stick precisely to 100 for a few seconds as if it were the cap, and then switch back to 200.

[CobaltKobold]

d5 Seems to do 20-30 fps just same as 40d on 80+ dwarf 8x8, in window at normal 800x600 (Was down about 10 when 100 and gobbos were in.)
Or at 1680x1050(grid 168x42).

40d seems to load quicker. d5 seems to take less memory.

Mouse designation behaviour is still changed from 40d (and mouse cursor's different, what's up with that?)-
 (d)(i)-up/down stairs.
press and hold right mouse button on square
Press and hold shift+. for > to go down to bottom level
40d result: All squares under mouse from initial level to bottom (minus bottom since up/down can't be designated on bottom) are designated.
40d5 result: Only first click designated, other levels (where mousebutton is held, but not edge-triggered) do not get designated.

Further testing reveals: 1. Time still does funky things while paused. Cats can adopt people during mouse-designations, I imagine diplomat meetings still progress. Known bug, I know, probably not in here.
2. Changing z-level and moving the mouse with mouse-button held won't draw either. A new depression of mousebutton is needed. *UNDESIRED NEW BEHAvIOUR* (Similarly if you hit a key to change what you're designating- it changes to, say, channelling but stops the drawing.)
Theory : Pressing keys makes it forget that the mouse1 is down.
Supporting evidence: Changing designation type by key similarly stops designation

To compare: 40d doesn't stop designating when you hit h, but it also doesn't change the designation. But it does change z-level when you hit >, and continues designating.

3. Once, just drawing for a while it stopped designating without any obvious event- not reproduced on another try...

[Veroule]

Toady, regarding the Mac compiliation with g++ containing debug symbols: Add the option -s to the linker parameter list.  This is the strip executable option and will remove some extra data.  If your IDE doesn't let you turn of the use of debug symbols anywhere, then you will have to use a custom make file.  To get rid of the debug symbols look for the parameter -g#, where # is a digit.  Removing that parameter from both the compilation and linker commands will cause it to not generate the debug information.

I also tend to use a custom optimisation list with g++.  This list does the maximum optimisations minus a few that I found to be of questionable value and slow compilation.  It also turns off some of the stuff that just makes the finished file bigger.

Spoiler (click to show/hide)

-O2 -finline-functions -funswitch-loops -frename-registers -fno-align-jumps -fno-align-labels -fno-align-functions -fno-align-loops -fno-reorder-blocks -fpeel-loops

Hope it helps, and doesn't error.  g++ actually allows and disallows some optimisations based on target machine, I am pretty sure none of the ones I listed are machine specific.


Baughn, I saw somewhere that you went to single buffered in order to try and make PP work.  Obviously many graphics cards don't like that, and in fact refuse to do it.  I am not too sure on how SDL handles setting it, but what you should be looking for is in the documentation on the pixel format descriptor. http://msdn.microsoft.com/en-us/library/ms537569(VS.85,robot).aspx Specifically you want to select PFD_SWAP_COPY. The default behavior in Windows is an exchange, which tend to get intpretted by the drivers and becomes a single pointer switch.  When the copy method is selected the actually copying is usually handled by the drivers and GFx CPU, so it doesn't generally slowdown the SwapBuffers function.  This should actually simplify the PP code in that even a triple buffered card will work with PP:YES:1.

[jarathor]

Alright just installed the new fix.
The previous ones all worked for me, and so does this one - except when I turn PP on. I had the settings to PP:YES:2, and it said I was getting about 25 fps (on a 120 dwarf fort in its 10th year), but the screen only seemed to refresh about twice per second, and there's an odd... flickering (tiles go black for about a second or two) that affects large chunks of the screen while scrolling - Does this have anything to do with what Veroule just posted? The same thing happens on the intro movies. My G_FPS and FPS are set to the default of 50 and 100 respectively.

I have a NVIDIA GeForce 8500 GT graphics card and I'm running Windows XP.
If there's any other information I could give, let me know.

[Toady One]

Toady, regarding the Mac compiliation with g++ containing debug symbols: Add the option -s to the linker parameter list.  This is the strip executable option and will remove some extra data.

The problem is that in g++ that came with the Mac, in 10.4, this option seems to be broken.  I haven't found a lot on the internet, but there were some rumblings that way.  If you ask it to strip, it causes a 'lazy pointer' error when you try to run the executable.  I had that part happen to me, but I'm not sure of the cause (aside from it being triggered by -s).  I'm not sure if I'll have to try to set up an XCode project, where I'm not really sure where to start as far as SDL goes, or if I need to get a g++ upgrade, or an OS upgrade.

[Veroule]

Bah, Apple never really made dev easy, that is probably why I never got into coding anything for Mac's.  At least they are trying slightly more then they used to.  After reading through numerous crappy documents in a few different sites the best I can come up with is to upgrade your version of XCode.  It seems this is the only way to get a newer Apple specific build of the GCC.

I didn't really see anything in any of the release notes subsequent to the version that ships with OS10.4 to indicate the bug was fixed.  You can always leave out the -s option, finding and removing the -g should get rid of the debug information.

The best spot I found to get the update is http://www.macupdate.com/info.php/id/13621/apple-xcode
You will have to sign up with Apple's ADC program, but this is a free download.

Looking through some of the other documentation you would have to make seperate builds of DF if you want to support older MacOS versions. 10.1 and earlier requires the use of a specific compile option in order to build for them.  So you should make sure to set the required OS version in your build project.

[Veroule]

Baughn, I finally got around to reading through the SDL documentation.  They of course do not provide anything remotely similar to what I mentioned in my last post.  It is yet another case of least common denominator.  If I didn't have 3 other programming projects taking up all my hobby time I would try to come up with something else to handle getting the PP stuff simpler.  Sadly it would involve me spending quite a bit of time with the Mac API docs, and the little bit of time I spent poking around those this morning made we want to skip work, get castrated, have my eyes gouged out, and finish by being immolated.


I did find that you could use SDL_ListModes to gather information about available modes for doing the full screen switches cleanly with the best useable space.  I haven't seen many people reporting it as an issue, but it would be good to get right.

[bhelyer]

Sadly it would involve me spending quite a bit of time with the Mac API docs, and the little bit of time I spent poking around those this morning made we want to skip work, get castrated, have my eyes gouged out, and finish by being immolated.

I could arrange that. >_>

(My poison is the GTK documentation. I just can't stand the way it's arranged.)

[codezero]

On 40dx:
I haven't had any speed increase over 40d for any other flavour, and a decrease after 40d2. Today I upgraded my video card from integrated to 9600gt, and there was no speed increase for DF (tho i can increase the gfps now), so my bottleneck is the cpu.

Anyway I was doing some testing after I installed the card and noticed I was getting around 35-45 fps in 40d2 in my 150 dwarf fort. (No significant difference from b4 the new card). But then I came to b12 and saw d5 was out. I migrated the save from d4 to d5, then after testing in d5 i copied the save to d4, d2 and d.
Here are the results;
d5:~20fps
d4:~20fps
d2:~20fps
d :~20fps

about the same as I was getting when I first tested d4.(1-2 days ago). Unfortunately I didn't back up the d2/d save, so I can't prove it, but i think the save from d4 or d5 has somehow compromised my fps.

I've tried rebooting and deleting all the other dfs(in case of dependency reasons), but d is still slower now.

Another note: copying the init from d5 to d makes d unrunnable for me.

[Baughn]

For partial printing, please note that you should primarily try it with YES:0. The integer is the number of redraws DF should do of each tile, which without double-buffering is pointless.

..I'm looking into reports of partial-printing stopping *anything* from being printed, but it, er, doesn't happen here. Need to get windows back on a machine to test on...

[Baughn]

Oh, and codezero, savegame compatibility is just slightly messed up between 40d and 40d5. You should probably just generate a new world.

[Baughn]

Baughn, I saw somewhere that you went to single buffered in order to try and make PP work.  Obviously many graphics cards don't like that, and in fact refuse to do it.  I am not too sure on how SDL handles setting it, but what you should be looking for is in the documentation on the pixel format descriptor. http://msdn.microsoft.com/en-us/library/ms537569(VS.85,robot).aspx Specifically you want to select PFD_SWAP_COPY. The default behavior in Windows is an exchange, which tend to get intpretted by the drivers and becomes a single pointer switch.  When the copy method is selected the actually copying is usually handled by the drivers and GFx CPU, so it doesn't generally slowdown the SwapBuffers function.  This should actually simplify the PP code in that even a triple buffered card will work with PP:YES:1.

It doesn't. I'd have to hack SDL to do that.

Given that your link claims it's only a hint, not necessarily supported, would it really be worthwhile?

[Baughn]

Hm. I think, instead, I'll work around it by using framebuffer objects. Then I get exactly the buffer behaviour I want, without any flickering, ever, thank you very much.

It's the Final Solution.

[bhelyer]

Hm. I think, instead, I'll work around it by using framebuffer objects. Then I get exactly the buffer behaviour I want, without any flickering, ever, thank you very much.

It's the Final Solution.

The way you capitalise that reminds me of, well...

 http://en.wikipedia.org/wiki/Final_solution

0_o;

Seriously though, I want to say thanks to Baughn, because if you haven't figured it out by his posts in this thread, or by tracking the BC repository, the man has put a lot of work into this.

Cheers, mate. :]

I'm playing a fort with PP:0, and am really stoked at the frame rate I'm getting. ;]

[Baughn]

There were two discernable differences; 40d5 seemed to be blockier scaling the chars up (rather, an irregular blockiness whereas 40d looked more solid), and with PP on there was more flickering, I didn't turn on VSync but I assume this might be more of a necessity with the higher fps.

I'll deal with that flickering, oh yes I will. It will rue the day it darkened my screen.

As for the tileset blockiness, that is an unfortunate consequence of using a texture catalog - we can't rely on opengl to scale it and still get the right results, so it only uses nearest-pixel "scaling". Long-term, scaling in software would work - bicubic scaling, perhaps - short term, you need to use a tileset that doesn't need scaling.