Print

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

[miauw62]

DF is about ten years old. Code ages. Perfectly serviceable code five years ago may be an unexpandable and overly complex mess five years later. I just rewrote a system in another game that falls into this category, actually.
There's very probably a lot of "bad" code that used to be good, but just lacked the foresight required to remain good for a decade.

E: also the rewrite I did had tons of tiny bugs that I've been fixing over the last month. Mostly minor typos and things, so yeah.

[Two]

Code doesn't age, but programmers learn.

[miauw62]

Code doesn't age, but programmers learn.

Yes, yes it does. Other code is added around and to it, making it progressively messier until it's rewritten.

[Two]

That would be organic code growth.

[Dirst]

Code doesn't age, but programmers learn.

Yes, yes it does. Other code is added around and to it, making it progressively messier until it's rewritten.

No, I distinctly remember that Flynn got older and CLU didn't.

[miauw62]

Code doesn't age, but programmers learn.

Yes, yes it does. Other code is added around and to it, making it progressively messier until it's rewritten.

No, I distinctly remember that Flynn got older and CLU didn't.

Hue. But CLU isn't exactly developed or used anymore, is it? c:

[Putnam]

What we need to do is get Toady one of those "time turner" things Hermione had so he can implement all the things he wants as well as all the things the players want in an hour.

That would wreak hell on whatever version control software he uses.

Toady doesn't use version control software.

[GavJ]

64 bit addressing mostly allows a larger embark area.

Huh?

Yes, it would allow this, but I've never seen a single person ever complain about not being able to embark large enough. 16x16 embark tiles = 146 acres! And for the vast majority of people, they're already processor-limited in simulating it long before that anyway, even if they have 64 bit systems, so it wouldn't matter if they wanted more in the first place.

(I have seen many requests, on the flip side, for native support for 1x1 embarks!)

What would 64 bit actually practically do for the huge majority of players of DF?

[BoredVirulence]

64 bit addressing mostly allows a larger embark area.

Huh?

Yes, it would allow this, but I've never seen a single person ever complain about not being able to embark large enough. 16x16 embark tiles = 146 acres! And for the vast majority of people, they're already processor-limited in simulating it long before that anyway, even if they have 64 bit systems, so it wouldn't matter if they wanted more in the first place.

(I have seen many requests, on the flip side, for native support for 1x1 embarks!)

What would 64 bit actually practically do for the huge majority of players of DF?

16x16 embarks come dangerously close to the standard memory limit, and on some worlds will crash. I've had that happen.
Now I agree there is no reason to do a 16x16 embark, you don't need that much space or resources and its just a huge drain on your FPS. Still, most memory issues can be fixed by being LAA.

I agree, we don't really gain anything by being 64-bit. And the conversion to 64-bit shouldn't cause any problems unless he's doing some weird things with memory, which (as a C++ guy [don't hate me]) is awful design 90% of the time (and awesome code 10% of the time).

As to the state of the code-base, Toady isn't a programmer by trade, he's a home-brew, self-taught programmer. When this project started his code probably wasn't very good, and although he's learned, supporting a long lived project filled with placeholders because there was never a complete design is simply awful. Its safe to say the code is probably pretty awful. Of course he doesn't need to make it readable to other people, but he does need it to be readable to himself, if you've ever worked on a long project, stumbled on an old piece of code, and claim to always know exactly what it does you're either lying, or comment too much. It just makes DF more of an amazing feat.

[Bloax]

As the amount of things to keep track of will increase, and likewise the memory usage will rise - would you rather prefer maximum embark sizes shrivelling up to spending a lot of time actually making DF catch up with the times?

[jonadab]

The bigger question is, "What does a 64 bit compile buy other than a slight slowdown?".

My question would be, "What is the point in bothering to compile a 32-bit version, in 2014?"  32-bit hardware hasn't been sold for what in computer time amounts to an aeon now, and 32-bit operating systems have become a niche only slightly more popular than Itanium.  Sure, everyone running a 64-bit OS can *theoretically* get a 32-bit game to run, but it's a royal pain.  (What do you /mean/ you can't find libSDL_image-1.2.so.0?  It's right here, /usr/lib/libSDL_image-1.2.so.0.)  If there are three people left in the community who really have to have 32-bit because they haven't upgraded their ancient hardware, let them compile it themselves.

I think the only 32-bit software on my system is the Flash plugin, which I absolutely hate (to the point where it's installed in a special non-standard location specifically so that most of my browsers can't find and won't use it -- not that most of them would be able to anyway, because it's 32-bit).  Oh, and now there's also Dwarf Fortress, which I haven't quite managed to get actually running yet, because of dependency issues, because it's 32-bit.

[jonadab]

DF is about ten years old.

NetHack is much older.  In fact, I believe even the latest official release of NetHack is older than ten years.  (There's a "leaked" version that's much more recent, plus of course variants, including NH4...)  The codebase is so old, it has a lot of pre-ANSI K&R C features.  That's first-edition K&R.

Yet it does pretty well on 64-bit.  I think there was *one* known bug specific to x86-64, and it was also port-specific (particular to the Windows tiles port, IIRC).

Granted, this may be partly because NetHack was always multi-platform.  Supporting both x86 and x86-64 is probably easier than supporting everything from PDP to ARM.

[cerapa]

Sure, everyone running a 64-bit OS can *theoretically* get a 32-bit game to run, but it's a royal pain.

Seriously?

I assume this is a linux specific problem.

[jonadab]

Sure, everyone running a 64-bit OS can *theoretically* get a 32-bit game to run, but it's a royal pain.

Seriously?

I assume this is a linux specific problem.

It's a dynamic-linking problem.  If the software were statically linked with any libraries it uses (e.g., SDL), then the problem would go away.  So that would be a workaround.

The really correct solution, however, is to just compile the software for the correct hardware architecture.  In the Linux world, most software accomplishes this by shipping a source tarball and letting each distribution package it for every architecture it supports.  I don't know exactly how it's usually handled in the Windows world.

[My Urist Eternal]

Is this a Linux thing? I have no issues running DF on my 64-bit Windows box.