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

[assimilateur]

So far this version has performed promisingly. Where on d18 and d19 I have gotten around 15 fps, with d19_2 I'm now in the twenties to low thirties. And that's only after preliminary testing, so here's hoping I'll get it to run faster with a couple more tweaks.

Now, I'm only puzzled in regards to two things:
1. Where my FPS counter used to be in the top left corner, it's now a bit to the right off-center. That might not sound like much of a deal, but it's obscuring the date in my status menu, among others.
2. Right now my FPS counter looks like this: n (m) / k. I figure that n stands for the number of frames being processed per second, m stands for graphical frames per second, but I have no idea what k is supposed to stand for.

[Qiu]

So far this version has performed promisingly. Where on d18 and d19 I have gotten around 15 fps, with d19_2 I'm now in the twenties to low thirties. And that's only after preliminary testing, so here's hoping I'll get it to run faster with a couple more tweaks.

Now, I'm only puzzled in regards to two things:
1. Where my FPS counter used to be in the top left corner, it's now a bit to the right off-center. That might not sound like much of a deal, but it's obscuring the date in my status menu, among others.
2. Right now my FPS counter looks like this: n (m) / k. I figure that n stands for the number of frames being processed per second, m stands for graphical frames per second, but I have no idea what k is supposed to stand for.

the n is an average of the FPS over a few seconds (forgot how many)
the k is the old FPS counter which is a bit more optimistic than the other and keeps jumping all around the place.

[assimilateur]

the n is an average of the FPS over a few seconds (forgot how many)
the k is the old FPS counter which is a bit more optimistic than the other and keeps jumping all around the place.

Thanks for clearing that up.

[Ranzear]

The smoothed FPS counter is very slick for figuring out whats bogging down your fort. Drawbridge smash a few hundred items or cage up your catsplosion and you get a good look at your FPS slowly rising back up.

[Baughn]

According to toady (or so I interpreted it, anyway), a large part of why having more items makes things slower is temperature. Try turning that off, and it should be much less of a problem.

That might only apply to DF2010, though.

[Veroule]

I have been thinking more about the threaded display model, and did an interesting test.  I set dummy loops in both Matrix::logic and render to simulate a much heavier processing load such as would occur during actual game play.  The result was that both settings for PRINT_ASYNC came out equal on a single core machine.  I believe that if it is set up perfectly then there would be no reason not to have the threaded model be the default and possibly even remove the option for a user to use a single threaded model.

That said I have thought up a few ways to make threading run smoother and completely eliminate the possibilty of SDL losing an event.  At the same time it can be made so that with minimal insertions into Toady's existing code the current worst offenders (stocks->stone, and game saving) could display progress indicators.

Also there is one race condition in the code I sent you.  It wouldn't cause any lockup but could cause the game to run an extra frame or 2.  I can't see any way to eliminate that particular condition using the controls SDL provides, but we could eliminate the extra game frames with a slight overhead.  I don't really think it is worth it.

[Baughn]

The reason the toggle is there is because the code is currently untested. You're right that it could probably default to on, I'm just not confident in the code yet.

Also, I'm taking a different approach entirely now.. well, you'll see. I think it should be fine.

[monkeyfetus]

Walls and floors of CERTAIN area at z-3 became visually...dwarven corpses and coffins.
"k" still named these as walls and floors, but damn, it looked as coffins and dwarven bodies.
I quitted and reloaded, same situation, changing display engine did not help.

Your copy of Dwarf Fortress is haunted. I suggest you get a priest to exorcise your computer.

[N3X15]

I've been off doing college related stuff for a while, so excuse me if I've missed a lot and I ask a lot of stupid questions.

I'm unable to get Ubuntu Jaunty to compile this.  It complains about needing clang++.  I have LLVM installed, but I still get the error.

nexis@RAGE:~/df/Dwarf-Fortress--libgraphics-$ scons
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
clang++ -o g_src/KeybindingScreen.bc -emit-llvm -pipe -c -Dunix -DGLEW_STATIC -O2 -D_GNU_SOURCE=1 -D_REENTRANT -Ig_src/fmodexinclude -Ig_src/glext -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/SDL -I/usr/include g_src/KeybindingScreen.cpp
sh: clang++: not found
scons: *** [g_src/KeybindingScreen.bc] Error 127
scons: building terminated because of errors.

I'm wary about screwing up my compile environment for my other apps, so are there other options or is clang++ required?

[Fictionpuss]

Does clang++ conflict with g++ on ubuntu?  I just linked it from g++ and it compiled successfully.  Of course, I ran into another problem to do with having created a 64bit library for a 32bit executable.. I left it there though as I don't have time to climb the learning curve of cmake, or set up a 32bit compile environment.

[N3X15]

How did you get it to use g++ instead of clang? Editing the SConscript file or is there some special commandline option that I haven't noticed?

edit:  I now feel really stupid.

--- a/g_src/SConscript
+++ b/g_src/SConscript
@@ -14,7 +14,7 @@ optimize = True
 debug = False
 profile = False
 
-clang = True
+clang = False

Compiles fine, buthad to add an additional step:

Code: [Select]

$ sudo ln -s /usr/lib/libjpeg.so /usr/lib/libjpeg.so.8


[madman]

What it boils down to, in the (possibly very) long run, is that the 32-bit install base will, at some point in the future, be so marginally small that supporting it becomes pointless.

However, at that point in time, starting a 64-bit build would take even longer to do than it would now, as the code base will have grown enormously and the probability for there to be issue with porting will be much higher.

"Starting...now..." 
Dude, it has been 18 MONTHS sense the last release.  There is no way Toady is going to take on the extra code maintenance he has to perform and reduce his development time just for the convince of a minority of his users and donors.  A couple years from now, when 64-bit hardware+OS is +90% of the install base he will probably do it.

A for Anonymous, I don't think anyone is seriously expecting a 64-bit version with the next release. However, if the code is clean from silly assumptions about pointer sizes, it's probably not a great deal of effort to port sometime afterwards, and very little effort to maintain once ported (it's not nearly as bad as another whole OS). It would need compilation and testing near release time and could be largely ignored the rest of the time. I write a lot of code that is designed to run on both 32 bit and 64 bit Linux - it's not hard.

I also disagree that waiting would make it that much harder - as long as Today is aware to not use any 32-bit specific coding practices, it should be easy to port any time. I hope not to have to wait two years though, as running 32-bit code on a 64 bit Linux system can be a real nuisance, especially when it is as library dependent as Dwarf Fortress.

[koitsu]

Code: [Select]

$ sudo ln -s /usr/lib/libjpeg.so /usr/lib/libjpeg.so.8


Please don't do this.  I've already explained why once already in this thread.  References:

http://www.bay12games.com/forum/index.php?topic=50514.msg1070455#msg1070455
http://www.bay12games.com/forum/index.php?topic=50514.msg1070555#msg1070555

[vyznev]

Code: [Select]

$ sudo ln -s /usr/lib/libjpeg.so /usr/lib/libjpeg.so.8


Please don't do this.  I've already explained why once already in this thread.  References:
http://www.bay12games.com/forum/index.php?topic=50514.msg1070455#msg1070455
http://www.bay12games.com/forum/index.php?topic=50514.msg1070555#msg1070555

To be more specific, do this instead:

Code: [Select]

$ ln -s /usr/lib/libjpeg.so df_linux/libs/libjpeg.so.8

Or just install a package that actually provides libjpeg version 8, if one exists for your distro.

[microMOOSE]

I tried to run a maximized window for fun and it crashes in about <1 minute constantly.  I don't see why it's not working properly.

I'm using shader mode with a 260gtx and 196.34 drivers.

Everything works fine as long as I don't resize the window strangely.

Spoiler (click to show/hide)

Event Type:   Error
Event Source:   Application Error
Event Category:   None
Event ID:   1000
Date:      3/24/2010
Time:      3:39:03 PM
User:      N/A
Description:
Faulting application dwarfort.exe, version 0.0.0.0, faulting module nvoglnt.dll, version 6.14.11.9634, fault address 0x000a01d8.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 41 70 70 6c 69 63 61 74   Applicat
0008: 69 6f 6e 20 46 61 69 6c   ion Fail
0010: 75 72 65 20 20 64 77 61   ure  dwa
0018: 72 66 6f 72 74 2e 65 78   rfort.ex
0020: 65 20 30 2e 30 2e 30 2e   e 0.0.0.
0028: 30 20 69 6e 20 6e 76 6f   0 in nvo
0030: 67 6c 6e 74 2e 64 6c 6c   glnt.dll
0038: 20 36 2e 31 34 2e 31 31    6.14.11
0040: 2e 39 36 33 34 20 61 74   .9634 at
0048: 20 6f 66 66 73 65 74 20    offset
0050: 30 30 30 61 30 31 64 38   000a01d8
0058: 0d 0a                     ..