Print

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

[peasant cretin]

I'm trying the 64-bit OSX version now. Running two versions. One in a new small world and the other involves my old save from the 0.43.04 32-bit OSX. Both adventure mode. Haven't noticed anything odd yet.

[soulsource]

@Toady: Regarding the 32bit Linux libraries:
I hope nobody has written this yet, I've just skimmed through the thread...

You definitely need just one version of the -dev packages, as those contain architecture independent headers and should therefore be the same for amd64 and i386.

For getting a 32bit libsdl 1.2, you could just try to directly install libsdl-image1.2:i386 and let apt-get resolve the dependencies. (sudo apt-get install libsdl-image1.2:i386). Once the 32bit libraries are installed, the linker should™ find them automatically when linking 32bit programs (actually, it will just ignore libs of the wrong architecture and keep searching).

[mifki]

You definitely need just one version of the -dev packages, as those contain architecture independent headers and should therefore be the same for amd64 and i386.

That's just not true.

[lethosor]

It's not true for everything, but I don't think SDL headers vary across architectures (which is why OS X frameworks work with just one set of headers embedded in them).

[mifki]

It's not true for everything, but I don't think SDL headers vary across architectures (which is why OS X frameworks work with just one set of headers embedded in them).

Specifically the problem Toady had was caused by libpng -dev packages for different archs conflicting. I found a bug report and the problem is that its headers contain some arch-specific code. Not sure if it's the same problem and if it's fixed in any newer Ubuntu version. But it's mostly a package management issue.

Other than that, i386/amd64 -dev packages can be installed at the same time (definitely there are separate packages), but it just may be easier to have a separate 32bit vm/docker/whatever than to resolve this and any other conflicts.

[Shonai_Dweller]

A bit late, but I'm also seeing a big improvement in speed in Adventurer playing Windows 64 bit.
Wandering round a big city (population over 10,000), there's loads of "!" all around but they all seem to update instantly as I move about instead of pausing for several seconds every step as it used to be in 32-bit.
Also, there's no pause any more when requesting a mission from a hearthperson. Best update ever.

[lethosor]

Is that in the same fort?
There's really no good reason for 64-bit DF to be that much faster. Is the new 32-bit version also faster? It could have something to do with the new compiler, which also happened since 0.43.03.

[Shonai_Dweller]

Is that in the same fort?
There's really no good reason for 64-bit DF to be that much faster. Is the new 32-bit version also faster? It could have something to do with the new compiler, which also happened since 0.43.03.

What do you mean 'same fort'? As I said I'm playing Adventurer in a massve city. Will quickly try 43.03 and 42.06 as I have both installed with worlds generated at the moment.

[lethosor]

I mean the same world. If the worlds aren't the same, a lot of things could be causing different performance.

[Toady One]

Burned most of the day trying to fix the worlds with the same seed that produce different results...  it's hard to tell when it has been narrowed down.  I turned off trade and it went away, but that doesn't mean trade is responsible -- it could be something in how the goods are produced, or how the resource types are decided, or the populations creating the goods (those all seem not to be the cause, but it only happens 1 out of 4 times once trade is off, so it's difficult to pick up the right problem).   And so on.  It's hard to nail these down, but hopefully I can find the root cause and sort it out.  Presumably there's some difference in initial conditions, some outside factor (like a clock call), or some out-of-bounds situation somewhere, but I haven't found anything obvious yet.

I looked at the chroot stuff...  and it just said "then you build the kernel as usual".  I never did that (installed Ubuntu from an iso), so I don't really know what to do.  I'm not sure I'm Linuxy enough to accomplish any of these methods.

[mifki]

I was wrong

[Random_Dragon]

Burned most of the day trying to fix the worlds with the same seed that produce different results...  it's hard to tell when it has been narrowed down.

And yet again, since I've had to point this out to someone else already: you DID already rule out Orographic Precipitation, right? To quote the wiki:

Turning it off should result in more controllable, less complex rainfall conditions based on rainfall parameters as it adds a random element which can distort or otherwise mess up the climates on a pregenerated map.

I can't recall if that other person confirmed whether or not they got more consistent results after disabling. All I recall is they couldn't wrap their head around WHY that would affect history gen, instead of just testing it to rule out a setting already alleged to cause that.

[mifki]

I looked at the chroot stuff...  and it just said "then you build the kernel as usual".  I never did that (installed Ubuntu from an iso), so I don't really know what to do.  I'm not sure I'm Linuxy enough to accomplish any of these methods.

The words about kernel in that post because the question was about building the kernel. You just "build df as usual".

[Toady One]

And yet again, since I've had to point this out to someone else already: you DID already rule out Orographic Precipitation, right? To quote the wiki:

Turning it off should result in more controllable, less complex rainfall conditions based on rainfall parameters as it adds a random element which can distort or otherwise mess up the climates on a pregenerated map.

That's what the orographic precipitation is supposed to do, unless something else is going on.

The words about kernel in that post because the question was about building the kernel. You just "build df as usual".

Ah, good.  I was afraid I was entering a total nightmare instead of a half-nightmare.  I'll try pressing the buttons and see what happens.  Maybe it will just work.

[Shonai_Dweller]

I mean the same world. If the worlds aren't the same, a lot of things could be causing different performance.

I don't carry over worlds from save to save so that's a hard one to test.

A city of 10,000 (star shape on map) and a dark fortress will slow down my adventurer without fail in previous versions. New version isn't slowing down (as much).

The pause as hearthpeople consider kill quests is long and visible in 42.06 and not now. Will test new 32 bit version too.