Print

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

[FutureSailor]

This is probably a dumb question, but I couldn't find an answer with a quick search on google or in this forum. I realize that this is mainly an issue for linux users, because we have to download a bunch of extra compatibility packages, and linux is probably a very small percentage of players, which is reason enough.

But, purely out of curiosity from an amateur programmers point of view, why is DF still just 32 bit? There aren't very many times you'd want to optimize something at the assembly level, but pathfinding in DF might be one of them. And that could make a 64 bit version require tons of rewriting. Or is it just to reduce the number of versions to keep track of? Or maybe even the performance gain from smaller address spaces or whatever?

[King Mir]

Toady has said that he plans to try "a 64 bit test" in the august report, so it may be that the only thing stopping a 64 bit release is Toady hasn't tried it.

[SimRobert2001]

This is probably a dumb question, but I couldn't find an answer with a quick search on google or in this forum. I realize that this is mainly an issue for linux users, because we have to download a bunch of extra compatibility packages, and linux is probably a very small percentage of players, which is reason enough.

But, purely out of curiosity from an amateur programmers point of view, why is DF still just 32 bit? There aren't very many times you'd want to optimize something at the assembly level, but pathfinding in DF might be one of them. And that could make a 64 bit version require tons of rewriting. Or is it just to reduce the number of versions to keep track of? Or maybe even the performance gain from smaller address spaces or whatever?

It started out as 32 bit.  Its probably a lot of work to make it all 64 bit.  In addition, he would likely have to maintain two versions of DF at all times, as a 64 bit program will not run on a 32 bit program.  This will be particularly problematic for those of us on 32 bit operation systems, and don't want/can't upgrade windows or MAC. Loosing your fanbase to appeasea GROWING portion of them is never a good thing.

[Pidgeot]

If a program is not coded to be 64-bit ready, then it needs to be changed, of course. There are a lot of small things to keep track of that you can easily forget to do if 64-bit is not on your mind (e.g. stuffing a pointer into a 32-bit integer), and it can take a long time to find all of those problems if you didn't keep it in mind. Compilers usually do a pretty good job of finding most of these if you ask them too, though.

It started out as 32 bit.  Its probably a lot of work to make it all 64 bit.  In addition, he would likely have to maintain two versions of DF at all times, as a 64 bit program will not run on a 32 bit program.  This will be particularly problematic for those of us on 32 bit operation systems, and don't want/can't upgrade windows or MAC. Loosing your fanbase to appeasea GROWING portion of them is never a good thing.

The only added work would be compiling more releases, and I assume most of that is automated by now. The exact same codebase can be used for both 32-bit and 64-bit; it's just a matter of writing the code correctly.

[tonnot98]

I'd assume that a 64 bit version would only be released for each version once it reaches it's "Stable" version like 34.11 was considered stable.

We might be seeing new releases for 40.xx for a while.

[King Mir]

I'd assume that a 64 bit version would only be released for each version once it reaches it's "Stable" version like 34.11 was considered stable.

We might be seeing new releases for 40.xx for a while.

No reason to think that. A 64 bit test is one of the things Toady mentioned was on the list of non-bug fixing tasks that may be mixed in with bug fixing

[Orange Wizard]

It's worth noting that Toady does not prioritise anything, other than what he happens to be interested in at the time, and things that make the game unplayable.
Hoping for anything other than that is a crapshoot.

[mnjiman]

I think it would be best to assume that a 64 version may be tested once ToadyOne is done his major bug fixing, works on content he wants to add, bug fixing after that, then with a stable version try it.

[Two]

Theoretically he just has to pull a switch and its 64. In praxis however it is possible that some (badly written) parts of the code might behave differently afterwards.

And then there is the question: why spent time on checking 64-bit compatibility that gains nothing in the end, if that time could as well be spent on fixing bugs and adding relevant features?

[Orange Wizard]

That's pretty much it. Toady has also said that his code is absolutely terrible, so there's that.

I'm not saying there's no hope, mind. I am, however, saying "don't get your hopes up".

[ShadeJS]

That's pretty much it. Toady has also said that his code is absolutely terrible, so there's that.

I'm not saying there's no hope, mind. I am, however, saying "don't get your hopes up".

If his code was *ACTUALLY* terrible he wouldn't still be releasing DF. It would have collapsed under it's own complexity long ago. It sounds like he writes non-idiomatic Cish C++ that works for him. Given that he's (mostly) a one man show when it comes to the code that's not as much of a problem as it sounds. The bigger question is, "What does a 64 bit compile buy other than a slight slowdown?". More address space... Most people here like short histories, on small, lower population worlds, with smaller embarks 'for the FPS', so that's not much of a gain. Given the lack of big video, big textures, big models, and big audio I'm quite sure that a lot of the stuff that lives in memory now doesn't need to be there permanently if an actual problem with the amount of memory needed does (regularly) emerge (that's not a bug).

If making a working 64 bit compile requires more than some trivial find and replace, maybe helped with some short scripts, it's probably not a great use of his time. (Though Toady should do what he wants with his time, so 'Yay!' if he does it I guess.)

[Jake]

It might be handy for some of the more ambitious mods like Dwarf Chocolate though, especially now that worldgen has much more direct impact on gameplay in Fortress Mode.

[Two]

If his code was *ACTUALLY* terrible he wouldn't still be releasing DF. It would have collapsed under it's own complexity long ago.

There are several states of "bad code", one of them is what you describe. A more common state is the "working by chance" state, in which the main functionality is working okish, however random bugs constantly appear, like crashes, low fps, strange behavior. Also a common side-effect of that is the lengthy time it takes for even minor updates, as a huge amount of time needs to be spent on testing, bugfixing and trying to figure out what that strange undocumented piece of unreadable code was supposed to do (and what breaks if you change it).

More address space... Most people here like short histories, on small, lower population worlds, with smaller embarks 'for the FPS', so that's not much of a gain. Given the lack of big video, big textures, big models, and big audio I'm quite sure that a lot of the stuff that lives in memory now doesn't need to be there permanently if an actual problem with the amount of memory needed does (regularly) emerge (that's not a bug).

And the game can actually handle that rather fine with the memory it has now, so more memory won't change a thing, except that more memory = more calculations = lower fps.

[ShadeJS]

There are several states of "bad code", one of them is what you describe. A more common state is the "working by chance" state, in which the main functionality is working okish, however random bugs constantly appear, like crashes, low fps, strange behavior. Also a common side-effect of that is the lengthy time it takes for even minor updates, as a huge amount of time needs to be spent on testing, bugfixing and trying to figure out what that strange undocumented piece of unreadable code was supposed to do (and what breaks if you change it).

If DF was 'working by chance' it still would have long ago fell into the complexity void. Given the number of twiddly little complex interactions in the game the fact that it's working as well as it is this close to the end of a long development cycle is something of a miracle. Well documented classes with tests could help with that, but that also takes time... So Cish C++ that's non-idiomatic is what it is... (And frankly even if he followed Google's cooperate style guide for C++ best practices it's not it would be a magic fix for bugs. Writing idiomatic code is as much about making it possible for others' to grok your code as anything else. Given that it's more of a one man show it's more important that he's self consistent and leaves the notes he needs for future reference.)

And the game can actually handle that rather fine with the memory it has now, so more memory won't change a thing, except that more memory = more calculations = lower fps.

Not so much more calculations as data structures taking more memory, promoting more cache misses, and taking more time to allocate, on a system wide scale... x86-64 was successful precisely because it didn't try to 'fix' the x86-32 instruction set. If compiled x86-64 code is executing way more instructions than it's x86-32 equivalent you should probably check the compiler or it's settings (though good luck noticing that in the general case).

[SimRobert2001]

If DF was 'working by chance' it still would have long ago fell into the complexity void. Given the number of twiddly little complex interactions in the game the fact that it's working as well as it is this close to the end of a long development cycle is something of a miracle. Well documented classes with tests could help with that, but that also takes time... So Cish C++ that's non-idiomatic is what it is... (And frankly even if he followed Google's cooperate style guide for C++ best practices it's not it would be a magic fix for bugs. Writing idiomatic code is as much about making it possible for others' to grok your code as anything else. Given that it's more of a one man show it's more important that he's self consistent and leaves the notes he needs for future reference.)

Actually, there's been SEVERAL features that have been accidentally removed, like the diplomats.  In the .34 release, caravans came at the opposite end of the season they were supposed to.  There's been several times on the journal where he's written something along the lines of "I went ahead and rewrote the code for xxx. It was a much bigger job that I thought it would be." A current example would the the mood rewrite, in which he stated that he's glad that he left it for after the big release. It isn't that its was complex, it is a symptom that his code is more "Jury-rigged" than he first thought.  Yes, there IS a "working-by-chance" state, though in all honestly, its not ruly "working by chance." Its more of a "Working in a way that that he wouldn't do with his experience today."