Print

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

[CobaltKobold]

I wonder how tricky it'd be to get a nati'e 16-bit 'ersion.

Don't know for sure but i think it's impossible because of memory limitations in 16bit mode and DF sometimes eats more than 500mb on my system.

Far pointers used 32 bits to store address; it 'ertainly shouldn't be impossible. Might be tricky though. Rather like living without the letter C.

[Baughn]

I'm working on an ncurses-based output mode, so one day (Like, friday?) it'll all be as flexible as nethack.

[rmin]

I wonder how tricky it'd be to get a nati'e 16-bit 'ersion.

Uh, would there be a reason for this?

[Baughn]

Pretty sure it was something called a joke.

[Jamp]

Oh yeah. Fandango on core.

That's not a backtrace, unfortunately.. strcat, assuming it really is the culprit, seems to have overwritten it. 

Should I report this as separate bug to bugs section?

[Baughn]

Hm. Is this still the "starting with a too-large window crashes DF" bug?

[Grax]

Will there ever be a native 64-bit dwarf fortress? There's something like a 10-30% speed improvement to be found there.

But multithreaded pathfinding would give us 100% speed improvement per each additional core. 

[Footkerchief]

But multithreaded pathfinding would give us 100% speed improvement per each additional core. 

Anyone thinking of making a serious reply to this -- take it to one of these threads instead.

[StrawberrySuigi]

Far pointers used 32 bits to store address; it 'ertainly shouldn't be impossible. Might be tricky though. Rather like living without the letter C.

Only 21-bits are used in the far pointer though, hence the 1MB limit of old 16-bit DOS, without the use of EMS, XMS, or 32-bit protected-mode extenders.

A 32-bit DOS version could be done using a 32-bit P-MODE compiler, like Watcom C/C++ or DJGPP.

[Jamp]

Hm. Is this still the "starting with a too-large window crashes DF" bug?

Actually its embarking and entering some other screens (thoughts and preferences, some parts of help), but yes 

[madman]

But multithreaded pathfinding would give us 100% speed improvement per each additional core. 

Of course - but do both, and get 120-160% speed improvement instead of 100%! (or 230-290% instead of 200%, or whatever).

Multithreaded coding is hard (particularly if the code is not designed for it from the start, or someone isn't familiar with writing multithreaded code, (see Footkerchief's link for discussion of this), compiling for 64-bit is (probably*) easy.

* If Today has done lots of things that assume 32 bits, like storing pointers in ints (occasionally I catch myself thinking about doing this, despite all my code being written for multithreading and 32/64 bit), then 64-bit becomes very messy as well, and will probably never happen.

Edit: this discussion probably belongs in Suggestions forum: http://www.bay12games.com/forum/index.php?topic=49307.0

[CobaltKobold]

Pretty sure it was something called a joke.

Compatibility!

Far pointers used 32 bits to store address; it 'ertainly shouldn't be impossible. Might be tricky though. Rather like living without the letter C.

Only 21-bits are used in the far pointer though, hence the 1MB limit of old 16-bit DOS, without the use of EMS, XMS, or 32-bit protected-mode extenders.

A 32-bit DOS version could be done using a 32-bit P-MODE compiler, like Watcom C/C++ or DJGPP.

Since most any game used an extender, that's kind of what I'd expe't.

[kutulu]

LD_LIBRARY_PATH is not set by default in Ubuntu 9.10* (64-bit version here), so the line:

Code: [Select]

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:"./libs" # Update library search path.
is pretty useless on many people's system. I had to change it to:

Code: [Select]

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/lib32:/usr/lib32/:"./libs" # Update library search path.
for it to work, but if you want things to work automagically this is not the way to go.

Wow.  It's very, very wierd that you had to do anything like that.

LD_LIBRARY_PATH is a god-awful horrid ld.so hack that's only useful for pre-compiled binaries, so it's almost never set on a Linux system.  It certainly shouldn't be used for system library paths.  The paths you specified should be in the system-wide /etc/ld.so.conf -- it should have been put there by whatever set up your 32-bit environment.

At any rate, edit /etc/ld.so.conf, put /lib32 and /usr/lib32 in (one per line) and run ldconfig, all as root, and you shouldn't need to mess with the LD_LIBRARY_PATH in the script.

--K

[kutulu]

It'd require Toady installing a 64-bit linux distribution, and additionally managing to compile a 32-bit version on it. Beyond that, there's a good chance it'd just work; I haven't seen any code that would fail from that switch.

Totally irrelevant plug: Gentoo's crossdev tool makes this super easy

--K

[Andir]

Posting to keep track of thread.