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

[Peewee]

Not to be impatient, but any idea when d5 will be released?

I'm betting after Toady One gets back from his enduvdamonth break and starts paying attention to the DF community again. 
He's been working hard. Give a guy a break!

[Baughn]

Well, I made a pesant half way see through.
It made him transparent so I could see the black space behind him but not any items or anything like that.

Yes.. that would be an interesting feature, but it'd also need a lot more work for Toady. I doubt it's a priority.

Still, translucency should let us make much nicer borders on objects in the tilesets. 

[Baughn]

<Toady, re some keyboard stuff> In any case, I'm going to test this out a bit more, then 40d5.

Shouldn't be too long.

[Toady One]

2. Sometimes, when I'm moseying along with shift+arrow, or sometimes just arrow, it goes up one z-level. Sometimes it just keeps going up and up and up and up.

Also, on this one, aside from the stuck-key issue, if you are jamming the keys to make it go faster, and you are using the number pad, you'll also run into shift+5 and ctrl+5, you'll go up or down a level, which is a proper though sometimes distracting result.  (though not ctrl so much, since you don't have as much of a reason to press that)

<Toady, re some keyboard stuff> In any case, I'm going to test this out a bit more, then 40d5.

yeah, stuck in the perpetual link again...  should be up in an hour or two.

edit: no longer linking, back to source again

[Xgamer4]

Just outta curiosity, how long does DF actually take to compile?

[Toady One]

Back to linking.

Xg4, I'm doing a full compile this time, and I started 6:42 PST, so I'll be able to let you know when I'm done.

[Baughn]

Well, he uses link-time code generation to get the maximum possible optimization out of MSVC... as a result, even a single-line change causes the compiler to have to redo 95% of its work.

This isn't the case for debugging, fortunately. MSVC also allows incremental linking and even incremental compilation, so those builds should be relatively fast.. it's just that the resulting executable is a lot slower.

Now, obviously I don't know exactly how long DF takes to link for toady, but with this sort of thing and large projects it isn't uncommon to look at multi-hour build times.

[Baughn]

For the curious, one detail of note: The optimization algorithms in common use in modern compilers aren't linear-time. As a matter of fact, many of them are exponential-time worst-case, and some fairly low but still above 1-base polynomial in the normal case. As a result...

When you use link-time code generation, basically the entire program is optimized at once. That improves speed, sure; it also means that a program composed of, say, fifty functions across two files, takes rather more than twice as long to compile together than separately.

Not using link-time code generation effectively forces compilation times to be linear. DF is quite large, Toady *does* use LTCG. I'll leave the expected result of that as an exercise for the reader.   

[Mel_Vixen]

Compiling - an programmer excuse for doing other shit.

I love long compiling times.

edit: I am curious. Are there any compiler out there that use multicores? I mean at all at once.

[Toady One]

40d5 is up:  Windows Linux

Compile in windows is 13 minutes, link is 18 minutes.  Locks up my computer other than itself, so I'm stuck with the guitar at that time.
Compile in linux is 30 minutes, link is fast. (not using link opts there at this time)
Mac is comparable, but leaves debug symbols in.  XCode doesn't, but g++ does.  Haven't decided what I'm going to do there.

[Ampersand]

Turning partial print on yields a blank screen through the intro movie, and the main menu.

[Xgamer4]

I'll also attest to partial print killing things if it's enabled.

[Peewee]

Ampersand, I saw your first post, and I applaud your username. Welcome to the depths that are the DF forums. (being a dwarf game, depths == good)

Anyway, downloading 40d5 + testing with my trusty 40d init.txt/raws/savegame because nothing else has changed (I HOPE =S) since then.

tests follow;
Windows XP, 2.66GHz processor, 4x4 fort with minor river, 2 yrs in, [SPEED:1] dorfs (no shame), giant size windowed mode (125x50 default font blackspace off)
PARTIAL PRINT OFF, START UP ANIMATION SKIPPED
on start up, anti-virus blocks dwarf fortress.exe from "program library injection"... as usual... everything normal, exit to test PP.
Oh yeah, and the menu doesn't loop over anymore ^.^

PARTIAL PRINT ON (2)
Usual "program library injection" error, prompt for full screen normal...
It looks like the screen isn't updating from black.
If I move the screen around, it takes the image of whatever was there, unless it was already there, in which case nothing happens.
LOL, It still manages to take up 10% of my CPU though!
I'm able to exit by hitting up then enter like I should. I think I MIGHT have seen a flash from the normal menu before it finishes. Yep, I confirmed that, I did see at least a single (graphical) frame before it quit.


Now testing multiple keys in fortress mode with PP off.
Saves/raws are compatible -I always worry about that so phew.
18-25 FPS depending on how many idlers I have 40d5 (will test save in 40d later for comparison)
Ok stable benchmark of 16-21 FPS with all of them working on a rather large paved road. FPS chokepoint seems to be pathfinding as all 27 dwarfs try to path through my 3-tile wide entrance and 3x3 staircase down to a quantum stockpile of stone. (Oh yeah, the stockpile has a single door so that's the choke. I saw 3 of them in the same tile. xD Still 40d5)
No problems noticed going between z-levels, playing as I usually do works fine... noticed that both of the children are referred to as "it"... that's not new though =P
No problems noticed with minimize/restore, though it doesn't have PP on, so big whoop.
Ok then... saving+quitting goes smoothly.

Now testing 40d save for fps comparison. (all other variables held the same)
Partial print off: 15-21 avg 17
Partial print on (2):18-27 avg 22

Data collection complete-no more edits to this mangled post.
I sincerely hope this helps a bit with de-velopment-bugging.

[namuol]

I get a lovely Segmentation Fault when running with PARTIAL_PRINT:YES:2.
The segfault occurs immediately after selecting Window/Fullscreen mode, whether I choose fullscreen or not. It seems to be happening before the window is created/fullscreen mode switch is made.

Turning off the window/fullscreen prompt results in no errors or warnings on the console; let me know if there's any info I can provide to help debug.

Running df_linux 40d5, Ubuntu 8.10.

EDIT: If it wasn't clear, disabling PARTIAL_PRINT prevents the Segfault.

[hermes]

I've never tried changing the PP before, but did a quick test now...
All tests were windowed 1600x1024, no graphic sets, FPS with the wagon at start of new fort

40d
PP:NO ~80 fps
PP:YES:2 ~ 180 fps

40d5
PP:NO ~280 fps
PP:YES:2 ~280 fps

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.
Otherwise no probs with 40d5 at all.

edit: sorry, not vsync... it uses single buffer?  double buffer option??