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

[Andir]

Heh, I've never even heard of SFML before.  I've only done a quick glance around the forums, but it seems that SFML still has a fair number of bugs to work out.  There's no need for us to try to separate SFML bugs from the DF bugs, at least not right now.

You don't know what you're talking about.

The author said it himself in this thread:
http://www.sfml-dev.org/forum/viewtopic.php?t=644

Its public interface is still evolving a lot and is not stable enough yet. In other words, there's no minor version of SFML, only major ones.

This basically means that you'd have to recompile SFML with every distribution of DF as well as updating the function calls if he decided to change them.  He even states (in the same thread...):

No, I'm sorry to tell you that SFML is not a mature and stable API. It's still young and will be improved a lot in the future. Maybe the 1.x versions should have been 0.x

Pretty much admitting that it's not really ready for more than just experimentation yet.

[jaked122]

if you complain about SDL why don't you go into SDL and remove the "massive ancient blocks of code" yourself seeing as you're such an expert

[Baughn]

Regardless of whether the performance problem is real or not, it's also irrelevant.

We use SDL only for setup. DF uses it to grab an opengl context, and.. that's it. Yes, and okay, it shoots off timer events twenty times per second or so; the inefficiency would have to be truly stunning for that to be noticable on any hardware made after 1990.

EDIT: And keyboard and mouse input, and... eh, no matter. That's not exactly performance-critical either; you press keys rather less than twenty times a second.

[Toady One]

The new stuff has been faster than 40d for people and in the absence of clear alternatives, I don't think anything else matters aside from it functioning at all, which we've been working on for those that have had issues.

I got 40d2 working properly on Leopard (as far as I tested it anyway, which isn't much), and it seems to be stripping the exe properly.  There are some general patches to apply, so I think I'll be putting up the Mac with 40d9 with the win/lin ones, probably tonight.

[Lemnx]

I haven't seen DF run this fast since I had it on my OC'd gaming P.C. I am getting that same speed on my laptop now...

I wonder what it gets on the PC now... hmmm...

[Areyar]

wow. the versions almost fly by as fast as the reported framerates here!

Your truly working like a champion miner in sandstone, Toady1.

't was a bit dispiriting a few months back, when progress made was largely invisible.
Now that each bit of significant progress leads to  a new (unbroken saves) version again, I'm sure the donations will pick up again too.
In spite of economic worries: even escapism can be a force of progress.

[corvvs]

Don't the Unreal Tournament series of games use SDL? At least the first UT did, I'm pretty sure - I remember Loki or Epic or somebody open-sourced that part of the code to get improvements from the community...

Sure enough, the info I was looking for is on sourceforge. http://openut.sourceforge.net/howto-utlokicvs.html

If it's good enough for a very latency-sensitive AAA FPS game, it's at least worth considering. SFML might be the bee's knees, but you can't say SDL is total crap in comparison without benchmarks and a stable API.

Edit:
(for clarity's sake, I'm responding to this post)

The biggest mistake of this thread is in assuming that SDL is in any way acceptable for decent performance.
SDL is a totally obsolete. It uses massive ancient code paths for what can be done in a few lines of code.
It's really poorly put together with major performance problems internally.

http://www.sfml-dev.org/forum/viewtopic.php?t=43

I just looked at the thread you link to on the SFML forum too - the initial benchmark looks impressive but is very flawed (as is pointed out in the same thread if you read past the first post). When you actually use SDL correctly it gets better results than SFML (again, according to the thread you linked). Of course, these results are from a few months ago, so improvements could have been made on either side. But at the time of that thread it seems that SDL was actually faster than SFML.

[bhelyer]

if you complain about SDL why don't you go into SDL and remove the "massive ancient blocks of code" yourself seeing as you're such an expert

Or port BC to SFML and blow us away with the performance improvements. But just complaining helps nobody. And as Baughn points out (as well as the developer of SFML: "I don't think so. OpenGL with GLUT, SFML or SDL will just be OpenGL ; in this case the library is used only to create a valid context, there's nothing to benchmark after initialization other than OpenGL calls."), we don't do 2D rendering with SDL, just get an OpenGL context.

(All that said, I will have to take a look at SFML and have poke around for my own stuff, where ABI/API compatibility isn't a big deal, and see what it's like)

[QuinRiva]

I know a few people having been asking for the guy who reported it doesn't work to explain what's wrong, well I have already posted 3 explanations in this thread but to reiterate:

In the first two instances I have used the same saved game:

• World is Medium 129x129
• Region is 5x7
• The region contains a brook
• The region contains a volcano
• There are approximately 90 dwarves
• There are approximately 65 animals
• FULLGRID:120:75
• FULLFONT:SL_square_16x16.bmp
• FULLSCREENX:1920
• FULLSCREENY:1200

I have tested various version including BCd2, DF 40d5, DF 40d6 and DF 40d7 of various different configurations:
Machine 1: Opteron 165 @2.4GHz, 8800GTS 512Mb (G92 Core) 180.48 drivers, 2Gb RAM
OS1: Windows XP SP3 - nLite Custom Build

• 40d - runs - averages 33-42fps mean-fps ~ 37, framerate in menus - 57fps
• 40d5 - executing causes 50% CPU usage (on a dual core machine) dwarffort.exe shows up in the process list, nothing else happens
• 40d6 - executing causes 50% CPU usage (on a dual core machine) dwarffort.exe shows up in the process list, nothing else happens
• 40d7 - executing causes 50% CPU usage (on a dual core machine) dwarffort.exe shows up in the process list, nothing else happens

OS2: Ubuntu AMD 64 Desktop version

• 40d7 - runs -  averages 28-33fps mean-fps ~ 32 - framerate in menus 360fps

Note that although the framerate in the menus is sifnificantly faster in 40d7 on Linux compared to 40d on Windows, the framerate ingame is actually marginally slower.  Also note that I am having some screen flickering problems in the initial menu that maybe associated with dual monitors.  I have Twinview enabled and it seems to flicker between the centre of Screen 1 and the combined desktop centre (i.e. sometimes the game is fullscreen on screen 1, sometimes it's fullscreen 1920 x1200 across my two monitors with half showing up on the left of monitor 1 and the other half showing up on the left of monitor 2).  This only happens in the menus.

For those of you on 64bit linux here's instructions for installing the necessary 32bit libraries:

Code: [Select]

dpkg-deb -X libsdl-image1.2_1.2.6-3_i386.deb libsdl-image1
cd libsdl-image1/usr/lib
sudo cp libSDL_image-1.2.so.0.1.5 /usr/lib32/libSDL_image-1.2.so.0.1.5
cd /usr/lib32
sudo ln -s /usr/lib32/libSDL_image-1.2.so.0.1.5/usr/lib32/libSDL_image-1.2.so.0
The latest version of the package can be downloaded from http://packages.ubuntu.com/ and search for "libsdl".
Obviously change the version number to what ever is the current version (i.e. .6-3 and .1.5)

Machine 2: Pentium M @1.6GHz, Intel 845 chipset, 1Gb RAM
OS: Windows XP SP3 Tablet Edition - nLite Custom Build

• Small World
• 3x3 Region
• No features (i.e. river, aquifer, magma pipe, etc.)
• 6 Dwarves (the start of the game)

• 40d - runs - Averages 0 fps (probably about 0.3-0.6 fps) - completely unplayable
• 40d5 - executing causes 100% CPU usage, dwarffort.exe shows up in the process list, nothing else happens
• 40d6 - executing causes 100% CPU usage, dwarffort.exe shows up in the process list, nothing else happens

Machine 3: AMD Athlon 64 3000+, 6600GT 180.48 drivers, 512Mb RAM
OS: Ubuntu i386 desktop version

• 40d6 - runs - playable (nothing else tested)

Machine 4: Intel Q6600 @ 3.0GHz, HD4870 (current drivers), 4Gb RAM
OS: Windows XP SP3

• 40d7 - runs - playable

The game clearly has unlisted dependencies in the Windows environment. It may be that it relies on services that I have disabled, but I have a number of games on my computer all of which run fine (everything from old school game like Myth II: Soulblighter, to new games like X3: Terran Conflict).  I write programmes in Visual C++ and .Net so all of those packages have been installed (as well as python for some of my other stuff).

Basically the current build of DF using Baughn's code quite simply does not work on my Windows machines, where the old version, 40d does work.

If there is anything that I can do to help identify the problem let me know.

[Baughn]

Hm. Well, since you're a developer:

Get the newest git version of BC, and compile that in debug mode. It should print *something* helpful; at least, there's a lot more debugging and logging code then.

EDIT: If possible, identify exactly what code is going wrong / where it gets stuck. I can't do that from here; most likely the problem is caused by some interaction between SDL and nLite, seeing as none of the commercial games you mentioned use SDL. (Then again, none of them use opengl either..)

As for the linux version being slower, that's somewhat inevitable. MSVC supports link-time optimizations; gcc doesn't, and while you can get the speed back by swapping out gcc for llvm-gcc, Toady hasn't gotten around to that yet.

[Shades]

For those of you on 64bit linux here's instructions for installing the necessary 32bit libraries:

Code: [Select]

dpkg-deb -X libsdl-image1.2_1.2.6-3_i386.deb libsdl-image1
cd libsdl-image1/usr/lib
sudo cp libSDL_image-1.2.so.0.1.5 /usr/lib32/libSDL_image-1.2.so.0.1.5
cd /usr/lib32
sudo ln -s /usr/lib32/libSDL_image-1.2.so.0.1.5/usr/lib32/libSDL_image-1.2.so.0

Just so you know you can use apt-get to get getlibs and then use getlibs to install libSDL_image-1.2.so

Code: [Select]

sudo apt-get install getlibs
sudo getlibs -l libSDL_image-1.2.so.0

This basically just does the same thing though.

[Impaler[WrG]]

I'm trying to run the 40d7 linux version but don't get anything but a terminal that pops and immediately dies with no sign of anything on it.  I am presumably missing a library of some sort but need an error message to determine which one it is.   How can I get an error code to spit out?

[Baughn]

To begin with, first start a terminal and then start df from the terminal. That will allow you to see any errors that pop up.

[Blank]

System:
Core 2 Duo T5500 @ 1.67 GHz, 2MB L2
2 GB DDR
Vista Business (32 bit)
Intel 945GM with hacked drivers that let it preform at the level of a 960 with certain games (224 MB of shared memory)

40d:
[PARTIAL_PRINT:YES:2]
[FPS:YES]
[FPS_CAP:800]
[G_FPS_CAP:60]

FPS hovers between 130 and 250 in a fresh fort, too fast for my tastes. It drops as low as 30 at times, but it's in the three-figures 95%+ of the time.

Adventure mode stays at 800 when not moving, runs continuously at 300ish, doesn't lag in the slightest! I had a lot of difficulty with lagging in earlier releases. It would stop and hiccup, dropping the FPS to 16 every few minutes. *shrugs*

40d8:
Copied 40d init, which crashes d8. Music plays, window is created, no errors thrown, won't respond, won't close, must be taskkilled. Picture. (dur, new options were added. Go me.)


[PARTIAL_PRINT:NO:2]
[FRAME_BUFFER:NO]
[SINGLE_BUFFER:NO]
[FPS_CAP:800]
[G_FPS_CAP:50]
Replace all files with d8 RAR, painstakingly reset all settings to match those of 40d. Crashes, same result as when copying the whole init.

NO, YES, NO: Same results.
NO, YES, YES: Heh, heh. Same results, but the black background is no longer redrawn and so it does cool stuff with its transparency. Behold!
YES:2, NO, NO: Same results.
NO, NO, NO in XP2 compatibility: Same results.
NO, NO, NO disabling themes and whatnot: Same results.
NO, NO, NO 256 color mode: Same results.

Out of curiosity, since the thing is functioning but not displaying right, I mashed enter until I, um, embarked (?). Neat.

Wa ha ha! I successfully predicted this situation. I'm not sure what it is, Baughn, but good luck diagnosing it? If you need me to try more things, give this thread a shout.

[bhelyer]

Does it work when you use the stock 40d8 init?

EDIT: Didn't see the hacked drivers thing. That's what my money's on.