Print

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

Faster, no (unknown) problems

Faster, problematic

Same speed, no (unknown) problems

Same speed, problematic

Slower, no other (unknown) problems

Slower, problematic

Doesn't work at all

[Mel_Vixen]

does thatb mean we get another d# version too? I would like to see your code in action.

[PencilinHand]

However, your conclusions isn't without merit.  The Window's 7 64-bit install base is growing at ~2.5 times the 32-bit install base, and I suspect the Linux community has an even higher 64-bit install base.  However, the more practical consideration of maintaining and troubleshooting the extra release versions is likely to be the biggest determining factor.  32-bit programs operate well(generally) in a 64-bit environment, while the reverse is not true.

What it boils down to, in the (possibly very) long run, is that the 32-bit install base will, at some point in the future, be so marginally small that supporting it becomes pointless.

However, at that point in time, starting a 64-bit build would take even longer to do than it would now, as the code base will have grown enormously and the probability for there to be issue with porting will be much higher.

"Starting...now..." 
Dude, it has been 18 MONTHS sense the last release.  There is no way Toady is going to take on the extra code maintenance he has to perform and reduce his development time just for the convince of a minority of his users and donors.  A couple years from now, when 64-bit hardware+OS is +90% of the install base he will probably do it.

It is, however, Toady's decision.  But if he did make a 64-bit Linux version, I would probably dual boot for it.  I have been meaning to get into Linux anyway.

That it is Toady's decision is without question, but from what I can tell Baughn and the rest of the d# development team have a (somewhat) bigger influence on decisions Toady makes in that regard, thus I was merely pointing out that Baughn might want to rethink his position on NT 6.x 64-bit builds. (NT 5.3 [XP 64-bit] builds being rather pointless at this point, as people are rapidly migrating away from it due to the numerous issues with it.)

The d# development team is Baughn.  Everyone else just offers, admittedly quite useful, opinions and suggestions on how to write the code different or better.

Although that build(d19) works very fast, save from d16 seems to work fine, BUT i CANNOT link floodgate..:E

Spoiler (click to show/hide)

I mean i can select floodgate linking option, but cursor is lost, also i cannot choose that specific, new floodgate manually - path is ok..

Scrolling through floodgates is weird, screen jumps into places where no floodgates are present.....

upd: but function works(i just cannot see cursor in proper place - it is visible while mechanisms are choosed).

winxp,
[PRINT_MODE:STANDARD]
[SINGLE_BUFFER:NO]

It is a known bug and only Toady can fix it.
"- Bridge linking is broken."
Bridge and floodgate linking are basically the same.

[NoahTheDuke]

It's going to cause a lot of extra work for toady. I'd have preferred to avoid it, but there was literally no choice. :/

But thankfully, once Toady's gotten past the extra work, it'll smooth over the rest of the development process for the game, right? I mean, what you're building is a solid graphics foundation that Toady can use for the next handful of major versions. It'll take work, but the payoff will be greater.

Noah

p.s. Am I totally off-base? I don't wanna sound too much like a jack-ass. :-P

[A for Anonymous]

Baughn:
Since this is still in a relatively early implementation state, I have a request to you for the Windows platform, please take a look at these articles at MSDN and take them into consideration when coding (In case you haven't already, of course! :

http://msdn.microsoft.com/en-us/library/ee417693%28VS.85%29.aspx
http://msdn.microsoft.com/en-us/library/ms684247%28VS.85%29.aspx (Only for NT 6.x, since MMCSS isn't available in NT 5.x. See also here.)

Both are relevant for DF, the first even more so than the second. Especially since you have now started implementing multithreading. I have done some testing, and using this service (normally intended for Source game servers):

http://www.gascot.plus.com/demos/fmmtimersvc.zip
(Original source: http://forums.srcds.com/viewtopic/4665)

to force the lowest possible kernel resolution timer (in my case 0.5 ms, default being 10 ms) - instead of having DF request it - provides quite a speed up for DF. I think this could also be very relevant for the simulation part of DF, but I assume Toady would have to answer this.

As far as I know, this can also be done on Linux, but (from what I found from a short Google session) can not be requested by an application and has to be done by recompiling the kernel. :-/

I will do some tests later with savegames of huge forts, instead of testing with my tiny forts.

[Footkerchief]

It's going to cause a lot of extra work for toady. I'd have preferred to avoid it, but there was literally no choice. :/

But thankfully, once Toady's gotten past the extra work, it'll smooth over the rest of the development process for the game, right? I mean, what you're building is a solid graphics foundation that Toady can use for the next handful of major versions. It'll take work, but the payoff will be greater.

That's the idea, but it's possible (with "Full graphics support" at #6 on Eternal Suggestion Voting) that these improvements will become obsolete in the near future.

[Ygdrad]

The last version I tried was 40d12.
I noticed a ton of options are missing from the init file in this version, is there a reason for this?

[i2amroy]

The init file has been split into two files, init and d_init. Make sure that you are checking both.

[NoahTheDuke]

That's the idea, but it's possible (with "Full graphics support" at #6 on Eternal Suggestion Voting) that these improvements will become obsolete in the near future.

Then what are they/we/Baughn actually working on right now? I thought they were messing with the "core" graphical elements of the code. Are they not? Have I totally gotten it backwards? Cuz if they are, then even if Toady adds all sorts of flair, he'll be building on these optimizations. He'll /have/ to be.

Noah

[Baughn]

Anonymous: I'd like to avoid writing any code specifically for windows, especially as I can't test it. If such things are useful, they should go into SDL in some way, not into DF.

As for Linux, modern distributions tend to use tickless kernels with a standard resolution of 1ms, which should obviate the need for such hacks.

[Andir]

As for Linux, modern distributions tend to use tickless kernels with a standard resolution of 1ms, which should obviate the need for such hacks.

Doesn't the tickless kernel pretty much mean their is no resolution but the system speed?  Pretty much all timers are high resolution... I mean, really the tickless aspect of it means that if you tell it to sleep for 1ms or .1ms it will (and not at the kernel resolution... because there isn't one.)

It still means that you don't need Windows like "hacks" but it doesn't really set a system resolution because that depends on the processor speed.

[Veroule]

In order to build the matrix branch on windows you can use the find_files.cpp from the BC build.  Just remove the 2 existing includes and include enabler.h.

I just finished building it and will play with some of the options and see what bugs I can find.

[Baughn]

Andir: Not quite. It's mostly true, but there are some parts of the system that still care about HZ; drivers that need to poll in certain situations, mainly.

[A for Anonymous]

Anonymous: I'd like to avoid writing any code specifically for windows, especially as I can't test it. If such things are useful, they should go into SDL in some way, not into DF.

Except SDL isn't intended to handle this, I'm afraid. :-/ That, and the fact that the code you'd have to implement is very small and pretty much doesn't require testing, as it just passes on to the OS scheduler "here, do this".

But never mind.

[Veroule]

I am finding a pretty consistent lockup when using PRINT_ASYNC:YES.  In order to get it to happen set the FPS_CAP to 45001 and GFPS_CAP to 50.  Launch matrix, give it a second or 2 then supply any input.

It looks like it is locking up at the SDL_SemWait in quiesce_async_loop.

I have gotten it to occur with different combination of fps & gfps caps, and have had it successfully handle a few inputs then lock up later.  The specific combination mentioned was the most consistent on my system.

[Andir]

I actually just now started it up using the linux + head (last version I tried was 18) and um...

...am I supposed to be getting over 100,000fps on the menu?

Spoiler (click to show/hide)

... and paused?

Spoiler (click to show/hide)

Of course, un-pausing is another matter...

Spoiler (click to show/hide)