Print

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

Faster, no problems

Faster, problematic

Same speed, no problems

Same speed, problematic

Slower, no other problems

Slower, problematic

Doesn't work at all

[Quietust]

3. I turned on the pause on load and autosave but it pauses at everything. If I build a building it's in pause when I come out. If I check to see if my trader is finally coming, it pauses when I exit. A lot of the time I'm looking at a paused screen waiting not realizing that the game stopped.

That seems to be the same as the issue I described in my post on page 1 - any time you exit from a non-fullscreen menu by pressing Space, it acts like you hit Space a second time, pausing or unpausing the game (depending on whether it was unpaused or paused to begin with).

[Cespinarve]

On my Mac, there were issues with it not recognizing key commands such as F9 in the opening menu, and unexpected un-responsive pauses during world-gen. But movement itself was very fast (although it may be because I am not used to playing without Mayday's tileset- ugrgh, please tell me one will be out for the new version).

Also, Adventure mode issues, but as that is completely broken, I'm unconcerned.

[Cespinarve]

Wait, an early reply said it was possible to run this with Mayday... how'd you install it without overwriting all the files in the original game folder?

[avari]

For what it's worth, for me this version (d18) is again slightly faster than the previous one I used (d14), as has been the case with all the "d" versions I've tried. Compared to ye olde 40d the speed increase is very significant by now, so I'd like to say thank you very much to Baughn for all the hard work :)

I didn't notice any problems, and actually I've had no problems with any of the versions so far. The exception is the toggle-pause-on-menu-exit problem in the current version which is described above, which is slightly irritating but hopefully easy to fix :)

(Windows)

[guebstrike]

Hate to ask, but do other opengl games work fine for you?

Yes, as far as I know.

I didn't realize there was a patch, and I re-downloaded d18. The double type thing seems to be gone.

[Kerrz]

Wait, an early reply said it was possible to run this with Mayday... how'd you install it without overwriting all the files in the original game folder?

How to Install the Mayday Pack with d18.

Install d18 to a fresh folder. Leave it as it is.

Go to your old Mayday folder.

Grab the RAW folder, copy it.

Go to the d18 folder. Paste it. Overwrite everything in the d18's RAW folder.

Go back to the Mayday folder, go to data/save, copy that over to the d18 data folder.

Go back to the Mayday folder, go to data/art, copy that over to the d18 data folder.

Go back to the Mayday folder, go to data/init, OPEN and READ the init.txt. Figure out which settings were important to you, and remember them. Keep this file open as reference.

Go to the d18 folder, go to data/init. There are now TWO init files. d_init.txt and init.txt. Most of the settings are the same as before, but they've been split up into the two different files. Compare them visually to your original from Mayday and set things back up the way you want them.

You will have to redo your key bindings within the game, which should be trivial unless you muck around with a LOT of key bindings.

[Baughn]

I didn't realize there was a patch, and I re-downloaded d18. The double type thing seems to be gone.

There wasn't. d18-head's only change only lets you remove the FPS cap, nothing else, and.. anyway, aren't you on windows?

..are you sure you actually tested d18?

[Baughn]

Hm, it is not running for me on Ubutu 8.10. I linked my libjpeg.so into the libs folder as libjpeg.so.8, as I did it for d17. But I get the following error:

Code: [Select]

./dwarfort.exe: /usr/lib/libjpeg.so.62: no version information available (required by /home/xxx/Desktop/dwarffortress/df_linux/libs/libtiff.so.4)
Loading bindings from data/init/interface.txt
Error: Dimensions set to zero, aborting opengl initialization
Error: Dimensions set to zero, aborting opengl initialization
render called without gl being initialized
render called without gl being initialized
render called without gl being initialized
render called without gl being initialized
render called without gl being initialized
...

Is a newer version of libjpeg neccessary than 62?

That's not a libjpeg problem; actually, the libjpeg version is totally irrelevant as it isn't used.

Looks more like opengl isn't initializing at all. What does "glxinfo | grep direct" say?

(The two errors are normal and more or less harmless. I'm still tracking down their source, but those won't affect gameplay.)

[Macuyiko]

A few remarks:

2D modes work here on Ubuntu 9.04. I had to create a softlink in /libs to libjpeg.so.62 to make ./df work however.

The 3D modes return the same as Bergelmir:

Error: Dimensions set to zero, aborting opengl initialization
render called without gl being initialized

Direct rendering is on here by the way:

direct rendering: Yes

I believe this has something to do with desktop effects (Compiz) being on...

I do love the new text mode though! However, there's a small problem with it, some keys are pressed twice instantly, especially in menus. E.g. selecting a workshop and pressing 'a' (add) automatically adds the first item with 'a' (armor stand) to the build list, instead of showing the menu. Toying with the KEY_MS values does not help. This makes the text mode impossible to use for me currently. This problem does not occur with the 2D mode.

[Beardless]

Specs first: G4 iMac (CPU speed 700 MHz) running OS X 10.4.11.

My experience with d18 is mixed. I thought it was going faster at first, but then I went back to 40d and couldn't tell the difference. (No, I can't compare FPS. The counter doesn't work for Macs in 40d. In d18, I got up to 2 FPS from time to time, so that might be an improvement?)

The wierd thing is that while the dwarfs seem to be running at about the same speed, the interface itself is slow as hell. This was particularly evident in the Designation menu. The game took roughly a third of a second to respond to each and every keypress. Another oddity: Saving the game seemed to go much faster for some reason. I am at a loss as to why this might be--the graphical interface shouldn't have anything to do with saving, should it?

I wanted to try PRINT_MODE:TEXT as well, but couldn't figure out how to get it to do anything but spew colorful question marks across the screen.

[Baughn]

Pretty sure I know what the problem is with text-mode there. I'll fix that tomorrow.

The interface takes a third of a second to react.. at *two FPS*? I think you have your problem right there, frankly. Might want a more powerful processor.. 700MHz is a bit silly for DF.

[Qmarx]

During worldgen offloading, framerates shoot up to over 1200!
Using 2dasync

[ShadeJS]

Darkdragon, my experience is that nvidia's drivers are far better for anything written to standards, while ATI does a lot of work making theirs work with particular games. Seeing as ATI is never going to check them against DF, you're out of luck there. I prefer to stay away from them.

Regardless of your opinion toward a company, it's best to work on ways to make a game perform on both types of graphics cards available.

But if that's your opinion I guess I won't be donating any time soon.

I kinda get the sense you're jumping to conclusions. As it stands, you're the only person with an ATI card, that I'm aware of, that has complained, so that immediately points to some form of problem on your end. And complaining that the game doesn't work on ATI cards isn't accurate, either. It runs, just not as well. And you can't really fault Baughn for using OpenGL's standard, or at least I'm assuming he is. It's not his fault if ATI cards don't have great support for OpenGL. And changing engines isn't really an option. DirectX limits the game to Windows.

Outta curiosity, what are your system specs, anyway?

On that note, I've run the D series exclusively on ATI cards on my Desktop Linux Box (my ancient intel / intel laptop would melt) and I've had good luck with the native builds vs R600 integrated (3xxx) and R700 discrete (4xxx) class ATI / AMD cards with the closed FGLRX driver and the new open RADEON driver in Debian Unstable.

Here's my specs:
OS:
-Using Debian Unstable, currently with the open RADEON driver (I believe FGLRX is in a PITA state in Unstable ATM).
HW:
-A dual core Athlon 6000+, with 2 GB of DDR 2 800, with an ATI/AMD Radeon 43xx passively cooled video card.
FORT (D18):
-A 6x6 site with moving magma, a brook, populated underground river, pit, and still hidden HFS, a population of 40, with 20 pets, and a fair bit of wildlife, will run at about 50 (14) FPS on STANDARD with a GFPS of 15 while 'windowed and maximized' with 16 x 16(?) tiles.

I consider the performance 'acceptable' even though it is lower than I recall with the FGLRX (closed) driver. ATI's closed driver actually advertises support for 'very recent' open GL versions, and historically, on Linux, the problem hasn't been ATI's Open GL, but version matching Xorg and the Kernel, combined with grossly slow desktop rendering, hard lockups, and chronic bugs.

I say this once to Linux ATI users: ONLY USE FGLRX UNTIL THE OPEN DRIVER IS ADEQUATE ON YOUR HW. Unless you really need ATI's Open GL performance, and you don't for DF, run away from FGLRX as fast as you can. The next round of distro releases should have good open support for everything up to about R700 class cards / chips.

[guebstrike]

..are you sure you actually tested d18?

If I didn't, I am now.

Anyways, I'm having a problem with the Link up a Door menu on my lever. I have 20 doors in my fort, and when I try to link one, the display zooms to the wrong door, so when I select the third door on the list the display might zoom to the fourth one. I think the blinking cursor goes to the right door but the zoom doesn't always go with it. This makes it very difficult to build the fort's well, since it took 20 tries to find the door adjacent to the river.

[Baughn]

A bit unfortunate, but that falls under "things Toady will have to fix, before DF2010".