Print

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

Faster, no (unknown) problems

Faster, problematic

Same speed, no (unknown) problems

Same speed, problematic

Slower, no other (unknown) problems

Slower, problematic

Doesn't work at all

[blunted2night]

I was not aware of the additional registers in 64 bit mode, that make sense, thanks for the info.

[Baughn]

x86_64 has 16 general-purpose registers, x86 has 8. Given that one of those is taken by a stack pointer and another usually by a frame pointer, the difference is even bigger than 2x.

[CobaltKobold]

*considers question* Nah, the PC is ob'iously not a GP-register.

[Baughn]

Which has not prevented people from storing data in it, at times. There was a trick you could do, back in the MS-DOS days.. its memory architecture allowed the same memory to appear at multiple locations...

[Zhentar]

Internally, the processor will use register renaming to use more than 8 registers for 32-bit code (and I imagine substantially more than 16 in 64-bit code as well), so I would be somewhat surprised if that were the main reason- although I'm not sure how clever the renaming is about skipping stack operations.

I was also very surprised, and at first thought something had gone horribly wrong. My initial version always used 32-bit mode, but then when we were integrating it with Khazad, I noticed that it ran around 5 times faster in Khazad than by itself . I initially thought I had messed something up, but it passed all of my unit tests. I went through all the differences between the two and then compared the compilation options. I was finally able to replicate the speed increase by compiling my version in 64 bit mode. It was actually very frustrating  .

If you could post both the 32-bit and 64-bit versions with debug symbols, and know which functions are the most performance intensive, it would be interesting to disassemble them and see how the compiled code differs.

[StrongAxe]

Running On Ubuntu Jaunty Server (32 bit/x86).  Running in ncurses/text mode over ssh.  It works, and seems to be fast, but there are text overwriting issues.  For example, when using the site finder, the map symbols still appear around the menu text.

[Xardas]

Hi Baughn it's me again 

I have 2 news, good and bad one:

1) The good one: after your remark about the segfaults I decided (two, three days ago) to dl the latest source and build libgraphics myself: although it wasn't a breeze for a linux newbie like me (missing zlib and glu .pc files which I had to create myself - it turned out to be easier than I have thought it would be), it seems to have solved the problem - no segfaults at all (hooraay)

On a side note: just out of curiosity I have used the "world-gen" command-line command to generate new world. After the generation, it created "world_map-region2-300-1.bmp" (which was broken - expected) and a strange map http://yfrog.com/0sworldgraphicregion23001j (strange for me because such map was never created before while exporting map images from in-game generated worlds or in map export in Legends).

2)The bad one: today I've downloaded newest source and tried to compile it (of course before that I did "scons -c" to clear everything). It has thrown out loads of warnings (mostly about some enum "states" not being handled by switch func), but it compiled successfully. Then I'm typing standard "./df" in terminal and I get this:

./dwarfort.exe: symbol lookup error: ./dwarfort.exe: undefined symbol: musicsound

Could somebody give me an advice on what to do with this? Thanks in advance

[darius]

I use 64bit linux (when not on win) and last time i tried compiling 40D* head on linux 32bit dependencies broke my linux...

[Baughn]

That can happen, if you're not careful.

I use a chroot. It seems safer.

[Quatch]

So let's see..

- I've already altered -head so both ^? and C-h are treated as backspace. Since there is no line editing possible, that should be a sufficient solution.
- (In d19_2_win) I fixed the ATI shader compilation, but not the shaders themselves, since I don't have any modern ATI hardware to test on. It should be possible for someone who does to finish the job, now.
- Did d19_2 solve any problems for anyone? It stopped it crashing on /my/ windows installation, at least..
- The game is indeed supposed to be linking to ncursesw, not ncurses. Actually, according to ldd it /is/. Can you provide the full ldd dwarfort.exe output?
- My current plan for the FPS counter is to search for unused space and move it around accordingly. Grumblerumble.

EDIT: Oh, I see what's going on. I must have forgotten to mention ncursesw properly to toady.. grab d19-head, and it should work.

Having trouble on OSX on a laptop. The secondary scrolls are not present on my keyboard, and I can't remap without a backspace key. I don't understand the hints in this thread as to what to do. I'd just edit the interface.txt file, but the keys I want to use -=[] dont seem to work: the - is already [BIND:SECONDSCROLL_UP:REPEAT_SLOW]
[KEY:-]
on the numeric. What should I use to get the one that is minus/underscore?

Finding the specific key I want to change in the listing is still difficult. Search would be ideal, but it is looking better than just the straight list. Normal sentence case capitalization would probably help readability.

Thanks,

[Kaelem Gaen]

When you say that Adventure Mode is to be broken until DF2010, do you plan to release a final 40d## with the Adventure mode fix (if it is something that can be fixed on your end of the programming.) Even though there will be the new DF out?  So people don't have to give up any adventurers they managed to keep alive in 40d16?

Can't you just move your adventurers back to 40d16 (or 40d11 or 40d)?

Do mind that d16's still got the "death lockup", so go back farther.

Put me down for "sharp edges".

I've maybe got that once or twice, but usually it was cause I hit space to clear the announcements as my Adventurer got massacred, if you see your dwarf burried and can't seem to move, just hit esc before clearing the space bar and you can finish the game.

On a sidenote,  adventure mode seems to let you move longer before it lags and you have to wait for your adveturer to stop moving to see if you went to far.  (with the OpenGL stuff) so I'd just hope to have a AM with a longer movement before lag thing.

I understand that it might be something on the end that Baugh (he's the guy working mainly on the OpGL/SDL stuff right?) can't access,   But if it is/was something Baugh can fix, It'd be nice to see it fixed for whatever ends up being the final in the 40d## series

[jellow belly]

I don't know if this was already reported, frankly I don't have the endurance to read an 18 page thread, but on the linux version in adventure mode the game sometimes ignores all input completely and sometimes it ignores everything except escape but then works perfectly in the escape menu.

Damn that was a long sentence.

Anyway I use all the same init options as I did in the original 40d (ran great on wine) and [PRINT_MODE:VBO]. I haven't played fortress mode in this version yet and this is my first opengl version (I downloaded it yesterday). I'm saying this because I checked some pages in the thread and didn't notice any linux reports (open source is dieing I tell you).

[Baughn]

There's a generic "Adventure mode is totally broken" disclaimer in the first post, though. 

[Quatch]

WRT delete/backspace, does this: "Since there is no line editing possible, that should be a sufficient solution." mean line editing where you move the cursor?

Oh and yes, it would be ideal if the mac version didn't conflict with the defaults for expose/spaces (only used f1-f8).

[Baughn]

Yes. As for mac keybindings, I expect we'll just ship a different interface.txt for macs - once the format is settled.

(Well, it pretty much is, but you never quite know.)