Print

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

[Max™]

The poll on bitness suggests that 3% (at most) run on a 32 bit OS, which goes along with my hunch that literally nobody is using a 32 bit CPU, just a few weirdoes like our chaotic firelizard are sticking with a 32 bit version of an OS for some reason.

Spoiler alert: 32 bit W7 is already ran into the ground. :p

Mostly because some of us derps happen to have got a computer that came with Windows 7 64-bit, but not enough RAM for it. :V

You play on a toaster with 1 GB of RAM?

As for linux, I have never noticed fmod ex in any dependencies or anything. The natively built packages don't include the g_src folders or anything, just data, libs, and raw.

[Shonai_Dweller]

The poll on bitness suggests that 3% (at most) run on a 32 bit OS, which goes along with my hunch that literally nobody is using a 32 bit CPU, just a few weirdoes like our chaotic firelizard are sticking with a 32 bit version of an OS for some reason.

Spoiler alert: 32 bit W7 is already ran into the ground. :p

That was a poll on bitness of computer, not OS. There's still quite a few people running 32 bit Windows on their 64 bit computers. Almost no-one is using an actual 32 bit computer these days (and should therefore all install Linux to play 64 bit DF with..)

[Max™]

Oh I know it was supposed to be a poll on the computer bitness, but I would be surprised if 5 people* were actually using Pentium 4 era chips still, as that gen was the last 32 bit processor cycle for PC's, so I figure it is far more likely that they equated 32 bit OS with 32 bit CPU.

*Yes, even including everyone who didn't take the poll, trying to get any OS capable of running modern software, much less df itself, on a chip that old is a Sisyphean feat.

[Random_Dragon]

You play on a toaster with 1 GB of RAM?

2 GB. It was enough for most purposes, but certain games (Hexen 2, Quake 2, Doom 3, and others) disliked trying to start. Strange given fucking Borderlands ran with no such issue. Since I was able to procure the 32-bit version, that solved it. And since then I've literally only had one game throw a hissy fit specifically because I don't have 64-bit (ARK: Survival Evolved).

[lethosor]

Another thing - some people use VMs to play (or at least test DF, mods, etc.), and I know some people choose to use 32-bit OSes because they tend to require less memory to virtualize, at least sometimes. (It doesn't make a huge difference when running large worlds in DF, but it does make a difference, although there probably aren't a lot of people doing that.)

I assume my SDL is 32-bit specific as well.

There are 64-bit versions here (SDL 1.2 and versions of SDL_image and SDL_ttf that work with SDL 1.2):
https://www.libsdl.org/download-1.2.php
https://www.libsdl.org/projects/SDL_image/release-1.2.html
https://www.libsdl.org/projects/SDL_ttf/release-1.2.html

You'll have to update the Linux and Mac libraries too - the current Linux one is just i386 (32-bit), and the OS X one is i386 and PowerPC, neither of which will work with a 64-bit DF.

In theory, changing -m32 to -m64 (or adding -m64) in the compiler flags should work when it comes to compiling a 32-bit DF with GCC, but there will probably be many linker errors as a result.

I also recommend OpenAL, mainly because it's used already on Linux and comes with the system on OS X (and is open-source and maintained!). It might be a good idea to distribute it anyway, though, since I don't know exactly which versions of which OSes distribute it by default.

[mifki]

edit: or maybe it's worse than that.  I'm getting a new group of linker errors for SDL...  yeah, zlib and SDL aren't working either.  It looks like the legacy version of fmod and zlib are fine, but the new ones are 32 only.  I assume my SDL is 32-bit specific as well.

ZLib will need to be recompiled, http://stackoverflow.com/a/26500082/991806

EDIT: And here are 64bit fmodex libraries http://www.fmod.org/download-previous-products/

[lethosor]

I suspect that FMOD Ex library has the same issue as the current one, though.

[NCommander]

I suspect that FMOD Ex library has the same issue as the current one, though.

I went fishing for an updated FMOD ex, and found one with ZDoom. Same problem, also linked against older runtimes. I rather not sign up for a FMOD account, but if they offer a Visual Studio 2015 build, that should work. In general, pure C libraries can be used as is, anything that using C++ needs a specific VS2015 build.

That being said, to make sure only *one* C runtime is required, its probably a good idea just to build all the dependencies against VC2015 32/64-bit. If memory serves, freetype needs a brick to the head though to build against VC2015.

[DeKaFu]

Oh I know it was supposed to be a poll on the computer bitness, but I would be surprised if 5 people* were actually using Pentium 4 era chips still, as that gen was the last 32 bit processor cycle for PC's, so I figure it is far more likely that they equated 32 bit OS with 32 bit CPU.

*Yes, even including everyone who didn't take the poll, trying to get any OS capable of running modern software, much less df itself, on a chip that old is a Sisyphean feat.

...Even if those 5 people were wrong, though, it doesn't mean there aren't another 50 who are actually running a 32 bit OS on their 64-bit processor and were savvy enough to answer the poll correctly. It doesn't prove anything one way or the other.

Both of my DF-worthy computers are still running Windows XP, and there's several others who have posted in this thread that they were using 32-bit XP or 7. It's a non-negligable part of the user base. Not everyone who uses an older computer or OS does so by choice, so I really hope there's no plans to abandon them.

[Shonai_Dweller]

32 bit users are going to have to be cut off eventually. Or does everyone really imagine they'll be playing DF 1.0 on a 30-40 year old computer?

It depends on how much management it needs, but if it's enough to impact the schedule it'd be insane to keep ensuring 32 bit compatibility for the next 20 years. Why bother going 64 bit in the first place if there's no plans to ever take advantage of it?

Well, hopefully someone will eventually hack up a 64 bit XP clone for those insistent that it can't be beaten.

[Gwolfski]

Oh I know it was supposed to be a poll on the computer bitness, but I would be surprised if 5 people* were actually using Pentium 4 era chips still, as that gen was the last 32 bit processor cycle for PC's, so I figure it is far more likely that they equated 32 bit OS with 32 bit CPU.

*Yes, even including everyone who didn't take the poll, trying to get any OS capable of running modern software, much less df itself, on a chip that old is a Sisyphean feat.

Me sitting here with a spare laptop with xp and above chip running df just fine thankyou very much

[NCommander]

32 bit users are going to have to be cut off eventually. Or does everyone really imagine they'll be playing DF 1.0 on a 30-40 year old computer?

It depends on how much management it needs, but if it's enough to impact the schedule it'd be insane to keep ensuring 32 bit compatibility for the next 20 years. Why bother going 64 bit in the first place if there's no plans to ever take advantage of it?

Well, hopefully someone will eventually hack up a 64 bit XP clone for those insistent that it can't be beaten.

32-bit compatibility isn't going anywhere for the vast majority of things. There are tons of businesses with legacy DOS or win16 applications which can't run on 64-bit Windows which will keep it going for far longer than anyone would like.

On XP, There is a 64-bit version of Windows XP. "Windows XP Professional x64 Edition". (not to be confused with Windows XP for 64-bit Machines). x86_64 has some disinct advantages over 32-bit x86_32 because of the increased number of general availability registers that make programs faster.

However, in general (aka !x86), larger memory sizes cause slower performance; this is why you things like ARM THUMB mode for 16-bit code, or Thumb2 which allows mixing of 32-bit and 16-bit.

That being said, Windows XP is over a decade old. It's already put out to pasture. At some point, people either need to upgrade, or migrate.

[Shonai_Dweller]

32 bit users are going to have to be cut off eventually. Or does everyone really imagine they'll be playing DF 1.0 on a 30-40 year old computer?

It depends on how much management it needs, but if it's enough to impact the schedule it'd be insane to keep ensuring 32 bit compatibility for the next 20 years. Why bother going 64 bit in the first place if there's no plans to ever take advantage of it?

Well, hopefully someone will eventually hack up a 64 bit XP clone for those insistent that it can't be beaten.

32-bit compatibility isn't going anywhere for the vast majority of things. There are tons of businesses with legacy DOS or win16 applications which can't run on 64-bit Windows which will keep it going for far longer than anyone would like.

On XP, There is a 64-bit version of Windows XP. "Windows XP Professional x64 Edition". (not to be confused with Windows XP for 64-bit Machines). x86_64 has some disinct advantages over 32-bit x86_32 because of the increased number of general availability registers that make programs faster.

However, in general (aka !x86), larger memory sizes cause slower performance; this is why you things like ARM THUMB mode for 16-bit code, or Thumb2 which allows mixing of 32-bit and 16-bit.

That being said, Windows XP is over a decade old. It's already put out to pasture. At some point, people either need to upgrade, or migrate.

And...these companies need to run Dwarf Fortress. Because...?

[NCommander]

And...these companies need to run Dwarf Fortress. Because...?

Solitaire isn't hardcore enough.

(you make a good point)

[Toady One]

Things were looking well for SDL...  then the link failed at the last moment with a "not enough space" error attached to the Dwarf Fortress.ipdb.  Whatever that is.  The .ipdb is 623MB.  The drive isn't close to full, but mem usage during link is around 66% on a second attempt and climbing.  Maybe I ran out.  So this'll be a continuing adventure.

edit: Yeah, it was hovering around 2GB, then it apparently tries to load this 600MB file and the memory shoots up to 2.5GB before it quits.

edit2: Looks like I might have to cut out some of the new compiler optimizations?  As far as I can tell, this is related to incremental link-time code generation, but I won't know if turning some of that off changes the RAM usage until I give it a shot.  Which'll probably have to wait until tomorrow, since I'm behind on my B12 duties.  Hopefully we can get the RAM usage down without affecting the actual speed of the exe (rather than the compile time, which is partially what this stuff is for apparently).