(from the comments, but I’m copying and pasting it here. — N.)
Two people have asked so far: will there be a 64-bit Linux version of Dungeons of Dredmor?
Short answer: “Maybe.”
Longer answer: “Sure, but only if you’re okay with an EXE where you can’t save. Fortunately, this is a roguelike.”
Longest answer: I’m still looking into this one.
Dredmor itself is a very, very 32-bit application. We started developing it back in about 2005 or so, before this 64-bit thing took off. As a result, we use standard ANSI C types without bit-size qualifiers, and there are going to be a few places in the game where this will cause a 64 bit executeable to just blow up. If we simply built Dredmor with the 64-bit compiler flags and tried to run it, save games certainly wouldn’t work, and I’d also say it’s a safe bet that the animation loader will die horribly as well.
Ultimately, it depends on two factors. The first is demand, and the second is how much time this is going to take. The plan is to get the first release out the door as soon as we can, and that will mean that we will ship a 32-bit ELF, same as on OS X and Windows. Then, we can look into the 64-bit situation to see if it’s worth doing a native build. If this is something where I can patch it in a couple of days and get an ELF out the door that is 64-bit, then I’m okay with that. If it’s going to be two months of pain, suffering, and grumbling at Icculus, then it will depend on what percentage of the Linux using, game buying population wants a 64-bit build and is incapable of getting the compatibility mode working. The other deal-breaker will be external libraries. I think SDL is pretty good about such things, but I don’t know about its dependencies. I’m also not confident that our XML parser will be happy being recompiled as a 64-bit application. So you may have to end up just lumping it and using ia32-libs.
On a side note: back when I was working for Loki in 2000, we got requests for builds of things like Civ:CTP on PPC machines, DEC/Alphas, and all sorts of other ridiculous requests. (Various forms of BSD?) Despite a very vocal minority of people who wanted these things, the actual majority of Loki’s clientele bought the x86 versions of the products and used them cheerfully and happily. The existence of PPC ports of Civ:CTP and so on and so forth has more to do with the fact that certain Hacker-Minded Individuals thought it would be a fun way to spend a couple of weeks as opposed to anything that made business sense. (Then again, who knows? Loki is out of business.)
Well silly games like nethack and dungeon crawl stone soup work on my 64-bit linux but some games like dwarf fortress made me install some extra libs.
We bundle everything that isn’t standard with the application. It *should* be fine; the plan is that any reasonably sane Linux distribution will have everything set up such that Dredmor can just run out of the box.
So if I create my own distro with libraries and things that my friend made and it technically doesn’t qualify as Linux…you’re saying I’m not sane?
(It’s ok because I would never do anything like that)
Btw, may you be punished for making us wait longer.
Nicholas, why don’t you just use static analysis to substitute all occurrences of int with uint32 or the like? I think that’ll get you at least 90% of the way there, provided you don’t have any pointers being saved into save games or craziness like that. So long as it’s clean C (ie: you don’t assume size of pointer) should be fine.
If by static analysis you mean emacs search and replace, then that’s the starting point. As you said, it will probably get me 90% of the way there.
There *are* unclean pointers in the save system. I don’t think there are any design decisions that will cause trouble, but I will have to do some search and replace. Fortunately, I think searching for 4, 1, fp); will resolve most of my issues there. 🙂
Here’s a good one!
So I bought the game! I wanna install it on my 64 bit linux and my 32 bit…or if I was someone inclined to use that OS named after the air/light holes in a house, would I be able to download a copy for each…OR would I need to purchase two copies to get a 64 bit download (or windows download) and a 32 bit linux download, etc.
Did I make sense? I’m tired.
I need to be careful what I promise here, because some of this may well be out of my hands (read: a limitation of distributor platforms) but ideally if you buy the desktop version of Dungeons of Dredmor you will get to play it on whatever desktop platform you choose. Again, some of this is possibly a limitation of the delivery platform. Things will be clearer after Business Acumen.
(I say Desktop Platform because any port of Dredmor to a non-Desktop Platform – iPad/iPhone, Android, online stores, arcade machines, digitally controlled toasters, etc. – will require a significant rework of much of the game and content as opposed to a mere recompile; as such, it will be a new thing with its own codebase and that’s where I, personally, draw the line. I’m not saying that ports for any of these alternate platforms exist yet – because they don’t – but they might. We’ll have to see.)
I can’t see why we would have to charge you twice for 64-bit and 32-bit Linux builds, even in the worst case scenario. If Ryan’s FatELF project had gotten off of the ground – as FatELF is almost *precisely* what we need for this – we could have guaranteed this. Consequently, if there IS some reason why we can’t ship both ELFs or provide patches or whatever, I suggest you blame Ulrich Drepper and Alan Cox. Please direct hatemail to them, and if you’re sending it to Alan I suggest that you do so in Welsh. 🙂
I’d also like to express my interest in a 64-bit build.
It’d be nice if you could look into it. Even nicer if you could get it done at the same time as the regular release.
Or if you could at least tell us at release, whether we also get the 64-bit version, if we already bought the 32-bit version.
So that one can buy right away instead of waiting and hoping.
As I said above: if there is a 64-bit version, the plan is that anybody who gets the 32-bit version will not have to pay again for a 64-bit version. Said 64-bit version will be made available free of charge; the only way I can see this not happening is if we end up with a Linux distributor that doesn’t allow it… but that seems highly unlikely. That reminds me, I gotta get on that.
Seriously, though: is this really actually a big deal? Again, I wouldn’t think that it would be, but then I’m spoiled by developing for operating systems that have working 32-bit compatibility. Most indie games are still being developed as 32-bit applications, as are most commercial games. If Linux’s binary compatibility can’t handle running a 32-bit application in 64-bit mode, or if the process isn’t sufficiently hassle-free, the next two years for Linux are going to be… very, very dry.
Personally I got a 32-bit chroot for 32 bit application that I need to run. Since every other possibility (e.g. 32-bit compatibility libraries) is just a huge pain and becomes a even bigger pain once you have to add some more exotic libraries to the mix.
Then again. If a game has all the libraries it depends on hardlinked, then it’ll just run in many cases. But I doubt that there is a single game which really comes with all required libaries. (it’d also be pretty crazy)
I still prefer to be able to use the game without having to change to the chroot first.
Sure. It’s just 1 more command in the shell. But if you don’t want to start your game through the shell, things get more complicated/insecure again.
I’m always really happy, if an application comes natively for 64-bit.
It feels like it fits right in, and not like an alien program.
Also as a side note. I’d like you to consider to release the source code of DoD, once it has come to age/ once you don’t expect any further revenue.
Because with old binary releases, it’s sometimes a huge pain to get them to run. One example for this would be “Theocracy”: No error messages whatsoever. It’s was pretty hard to figure out, why exactly it won’t run. And it’s so old, that I’m guaranteeing, that there won’t be any significant revenue anymore. (well, in this case, none at all, since you can only buy it used these days.)
(a timeframe for this which I have in mind is 3-5 years, depending on how well it sells.)
We link against everything that isn’t glibc via the usual method of setting LD_LIBRARY_PATH with a shell script and then providing dynamically loaded DLLs for everything else…. so, basically, what all of the recent commercial releases have done. If you have ia32-libs installed, you won’t need anything else. (That I am aware of.)
Regarding open source: I think I said this in another post (the “commercialization of roguelikes” one?), but chances are that an open source Dredmor release will happen at some point. Chances are also pretty good that, in order to get that release to happen, two things will have to happen:
1. Timing. I’m not doing it for awhile. (Even then, there’s some bad stuff in the codebase that I want to clear up before it sees the light of day.)
2. Profit. Chances are pretty good that any sort of open-source release for Dredmor will require sales of Dredmor (or the next game) to hit some sort of arbitrary point before we do the release. This is similar to what the Humble Bundle folks have been doing, and that seems to work reasonably well. (Heck, who knows? We may even end up IN a Humble Bundle. Nothing is impossible.)
Just from by experience of running x64 gentoo and the humble bundle games, some did it well without a 64-bit binaray (shadowgrounds) and some did poorly like crayon physics that only seems to work on 64-bit Ubuntu and almost no other 64-bit system. (It wanted the pulse sound library rather than something sane like the SDL mixer or OpenAL). If you do it well I don’t think you’ll get a whole lot of complaints
Pingback: TuxPlay – Linux Games » Dungeons of Dredmor – premiera w maju bez wersji 64 bitowej