Print

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

Faster than 40d, no problems

42 (26.1%)

Faster than 40d, problems

72 (44.7%)

No slower than 40d, no problems

14 (8.7%)

No slower than 40d, problems

16 (9.9%)

Slower than 40d, no problems

2 (1.2%)

Slower than 40d, problems

3 (1.9%)

Doesn't work (please explain)

12 (7.5%)

Total Members Voted: 160

[Baughn]

Well, the error code is telling - "no such operation". You don't seem to have 3D support - at all, not even software rendering.

At this point, you should talk to other users of your distribution about how to set it up right.

[Macuyiko]

I've tried d8 on my Ubuntu laptop. It works fine, but I have to turn off Compiz (the desktop effects), which is a bit annoying. I'm using an integrated Intel 945M chipset, and I'm almost sure it's not a driver problem.

I've tried this will all sensible partial print-buffer combinations. The best I got was an initial drawing of the screen, but parts which needed to be redrawn (e.g., scrolling through the main menu) just turned that portion of the screen black.

If I disable desktop effects, everything works fine. Other SDL/OpenGL games work fine though. I will try again later today with d9 and will  post some screenshots.

Yes, I've had several reports of this; screenshots would be nice.

Compiz doesn't seem to be very transparent; it makes assumptions about how applications work. I'd look up any documentation on how to deal with it, but I can't find any.

EDIT: Well, apparently it's a fundamental problem with Compiz and DRI1. There's no way to fix it, and if any opengl apps at all work for you, that's unusual in itself.

This is correct - the only cards that overlay Compiz with other OpenGL apps in windowed mode correctly are the nVidia closed-source drivers, because they don't actually use the DRI1 subsystem.

Good news about your Intel card though - the Intel DRI2 drivers using GEM are already out in an alpha of the next version of xorg. Easiest way to get it if you're running Ubuntu is to upgrade to the Jaunty Jackalope alpha using "sudo update-manager -d"

Note: I am not an Ubuntu developer. This is a development release of Ubuntu, so be prepared to submit bug reports if and when something goes wrong. It is your holy duty as a knight of the Alpha.

Okay, I've got some screenshots up...

Spoiler (click to show/hide)

This is DF running out of the box, strangely enough, the framecounter background comes through:


This is after some thinkering with the partial print/framebuffer settings: the screen only gets drawn once (see menu items):


I've noticed that other games which use SDL to create a OpenGL surface don't work like they should as well - Neverball for example works, but has weird corrupted textures. True OpenGL games however, work fine, example:


This is pretty strange, what is Compiz not liking about OpenGL trough SDL :S...

DRI2 with GEM will indeed be a real help here I believe, so I guess I'll just disable Compiz until Jaunty is final. I don't want to run a Jaunty beta on this machine at the moment. Thanks for the responses.

[Calessa Lynn Orphiel]

Haha, crack attack ... I remember fiddling with that in college.

I noticed a behavior similar to your first screenshot (with the FPS counter background showing and nothing else) when I first upgraded to Windows 7, but it eventually would draw in the rest of the elements.  For me, I had to do a driver update.

After the driver update, the same settings were easily the fastest settings.

I don't know if that's really useful, but I figured I'd put it out there.

[Jurph]

If all of the 40d versions (40d through 40d8) run at ~25 FPS on a large-ish fort, should I bother trying 40d9?  I'm using an nVidia GeForce 6600GT, and I suspect I've maxed out my framerate on my current hardware.

[Veroule]

I have begun work on many optimisations in the published BC code.  While I can't be sure what code is actually used by DF I suggest staying tuned to this topic for faster verisons of DF.

My goal is to optimise everything I can find a faster way for in the BC code.  Some of that code is directly used by DF which is the entire point of this project and topic.  Other parts may provide Toady and idea about how to do things better in DF.

*toast* Here is to a better DF.

[Baughn]

If all of the 40d versions (40d through 40d8) run at ~25 FPS on a large-ish fort, should I bother trying 40d9?  I'm using an nVidia GeForce 6600GT, and I suspect I've maxed out my framerate on my current hardware.

No. There haven't been any performance enhancements since 40d7 (or was it d6?), though Veroule is working on some now.

[bhelyer]

*toast* Here is to a better DF.

Damn straight.

[Malek Deneith]

Not sure if the input matters still, but I tried it finally and for me, sadly the new output code is a downgrade. I meddled around with a ini options, and this new version ran sliiightly lower fps on average, and the fps seemed less stable. Trying out Single_Buffer messed the graphics for me. Also I am slightly annoyed with the fact that DF window doesn't remember it's screen position, but I figure it has to do with hasty implementation, rather than the output upgrade itself.

[Jurph]

Bad News: the latest version of the ForceWare drivers (181.20) report that "display driver files from different (incompatible) versions of the driver have been detected.  NVIDIA OpenGL acceleration is disabled in order to maintain system stability."  The error box suggests updating drivers, but I recommend reverting to an earlier version.  I'm dialing back to 178-point-something and restarting.  Back with more info ASAP.

(For those of you curious, I upgraded despite Baughn's post in order to use the latest Dwarf Manager.  I updated video drivers to verify that they worked.)

[Ascii Kid]

I was having trouble getting the earlier versions to work but the newest one seems to do the trick.  Just for fun I left the frame rate cap at 500; while I havn't tested fortress mode yet (as it'll take awhile to build anything that represents a greater strain) but adventurer mode runs smooth as silk with none of the old "ghost key presses" that spelt disaster for so many brave and hardy souls.  While walking through a bustling human town the rate was roughly 110-115, but while conversing it's up in the 490's+.  Bravo.  =->

[Khyron]

I've got the 181.20 drivers and am having no problems with the new (40d9) version of the program, however when I loaded the old version by accident all I got was a black screen.

[Ogantai]

My goal is to optimise everything I can find a faster way for in the BC code.  Some of that code is directly used by DF which is the entire point of this project and topic.  Other parts may provide Toady and idea about how to do things better in DF.

Unfortunately BC doesn't have DF's pathfinding code, right? That seems to be where the real bottleneck is for those of us with decent graphics cards. Any chance Today could release a BC-like program with pathfinding?

[Mel_Vixen]

I dont know how much the pathing code evoilved since then but maybe the Pathing algorithm of AKQ is similiar to the algorithm in DF.

[Kholint]

Any chance Today could release a BC-like program with pathfinding?

This would be my ultimate DF-wet dream. If that happened I wouldn't sleep until I had written a super awesome, multithreaded efficiently-cached BC pathfinding algorithm.

[slaguth]

Well, 40d9 is now about twice as slow 40d on the same settings (PP:YES:2, FB:YES). (And just for reference, 40d7 was almost twice as fast.) This is on Windows XP with a nVidia 8800 card.

EDIT: Well, the same settings, except that 40d obviously doesn't support the frame buffer option.

Also, (and I've noticed this one since at least 40d7), the intro movie now looks rather strange to me. Here is a screenshot:

Spoiler (click to show/hide)

Note the black lines between squares, and colored lines sticking out of the solid blocks.

Keep up the good work!

Well, yeah, 40d doesn't support the frame-buffer option.
So how does it look/act if you turn that off?

Sorry about the noise; on a closer evaluation I believe the slowdown resulted from map size not graphics, and I can't find a smaller-but-still-substatial map to test on.

Other issues:

Did you look at the screenshot in the spoiler above? You didn't comment on it in your reply.

It would be nice if Toady could release a 64-bit Linux binary. I keep getting "wrong ELF class" errors because I have 64-bit compiled libraries on my system. I am attempting to get my hands on the 32-bit binaries, but somehow I keep missing dependencies...

Code: [Select]

~/Desktop/df_linux$ ./df
/usr/lib/gio/modules/libgioremote-volume-monitor.so: wrong ELF class: ELFCLASS64
Failed to load module: /usr/lib/gio/modules/libgioremote-volume-monitor.so
/usr/lib/gio/modules/libgiogconf.so: wrong ELF class: ELFCLASS64
Failed to load module: /usr/lib/gio/modules/libgiogconf.so
/usr/lib/gio/modules/libgvfsdbus.so: wrong ELF class: ELFCLASS64
Failed to load module: /usr/lib/gio/modules/libgvfsdbus.so