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

[Kishmond]

This is great and all, but what is it for? Testing graphical improvements? If so it works great. I once had 9 armies in one battle and it never got lower than 250 FPS.

Not actual size, my screen is 1280x1024.

Spoiler (click to show/hide)

[Greiger]

I had lost all hope...but now it works for me too. 

Awesome.

[savanik]

Hey guys. On Ubuntu 8.10, nVidia 8800 GTX. Not sure on libraries - if someone can tell me how to figure that out, I'd appreciate it.

When running from the terminal, I noticed this output:

Code: [Select]

E: shm.c: shm_open() failed: Read-only file system
E: shm.c: shm_open() failed: Read-only file system

(bc.exe:5811): GLib-GObject-WARNING **: instance with invalid (NULL) class pointer

(bc.exe:5811): GLib-GObject-CRITICAL **: g_signal_handlers_destroy: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed

(bc.exe:5811): GLib-GObject-WARNING **: instance with invalid (NULL) class pointer

(bc.exe:5811): GLib-GObject-CRITICAL **: g_signal_handlers_destroy: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed
E: shm.c: shm_open() failed: Read-only file system
E: shm.c: shm_open() failed: Read-only file system
I'm not sure exactly what this is - I don't know enough about code. But it appears to be related to the 'shared memory' functions. It's possible that this code is written to assume that it has Administrator permissions and it attempt to open a device it doesn't have write permissions to?

It doesn't really seem to impact the functioning of the application any, though I'm worried if it might affect trying to save games in Dwarf Fortress proper.

Sincerely,
Savanik

[bhelyer]

The glib stuff can be ignored, but I haven't seen the shm_open errors before. Can you write to the directory bc is in (try 'touch hi' or something)?

[Doomduckie]

okay, so, it now works on my machine (you'll see my error log back on page 3 or 4. Not sure which update fixed it save that the latest one works.

I'm getting about 1100 FPS in menus and battles with Partial Print 2, standard grid size. The original got about 400, 500, occasionally 600 in battles and 1000 on Menus with the same settings. Good job!

It still notes there's a power of two error and such- should I be noting what the console says for you?

[Baughn]

Not if it works. Well, I guess all's good then - is anyone still having problems?

About the shm_open errors:
A number of linux applications expect to be able to open temporary files in /dev/shm/, which should be a directory like /tmp except using a ramdisk, not the actual HD. Your system appears to have the wrong permissions for that mount; it should have all permissions set (777), plus the sticky bit. Like /tmp.

As you can see, though, it falls back nicely to, presumably, /tmp, so no big deal.

EDIT: The power-of-two thing isn't actually an error, but it does mean the tileset takes up more VRAM than it should. Sadly, that happens mostly on older cards that also have low maximum texture sizes, which means graphical tilesets are mostly out.

There is hope, though. Right now the code treats every tileset as if it's 32x32 or larger, in order to accomodate the 32x32 mouse texture, but that code is pretty much placeholder. With a smarter algorithm, the texture catalog should get a *lot* smaller.

[bhelyer]

I would appreciate if people (linux users in particular) could copy the sound files from DF's data/sound directory to BC's data/sound directory - the music should play on the title screen.

If linux users want/need to muck around with the sound system used, the flag to pass is -sound_output, with three possible values:  ALSA (default), OSS, or ESD.

[PolliMatrix]

The new version is working for me as well and it's a lot faster than the old one.

On the title screen I get 10000 fps and about 4500 during battle and in the options menu.
In the old version it's between 300 and 350 fps on the title, between 350 and 400 during battle and about 3800 in the options menu.

[Sinergistic]

Not sure if this is useful, but:

Averaging about 6600-6700 FPS on the ... continents screen? The main one.

Battles(I guess, lots of stuff scrolling across the screen) I've seen it drop as low as 1000 FPS, but it generally hangs out around 1200 or so for most of the fight and then JUMPS up to around 4000 near the end, and then back to 6600.

[WINDOWEDX:640]
[WINDOWEDY:300]
[FONT:curses_640x300.bmp]

[Baughn]

I've fixed the texture catalog tiling. It's still not quite ideal, but it saves some ~70% of the texture memory compared to the old one - given that the best possible (actually, it's probably impossible) would save ~74.8%, I'm satisfied.

Now, then.

I'm working on the last fixups before I submit this to Toady. This will take another day or so.
As such, if anyone is still having problems, this is the time to speak up; I'm assuming everyone who did has had them fixed.

(Although, it should be said, I can probably submit bugfixes later)

[Haven]

My issue was fixed. Running on standard settings, the lowest I've dipped during a battle is about 5k+. Most of the time though, I'm hitting my 10k FPS cap.

[Xgamer4]

Just outta curiosity, any idea why it was dying on the VBO's?

[Baughn]

Driver bugs.

[userpay]

EDIT: Basically, Windows is *unable* to sleep for less than ten milliseconds, so instead I'm having it busy-loop. This should ensure that you get the maximum possible framerate, unless there are still vsync-issues; it should also cause your CPU to stick at 100% no matter what.

From MSDN:

To increase the accuracy of the sleep interval, call the timeGetDevCaps function to determine the supported minimum timer resolution and the timeBeginPeriod function to set the timer resolution to its minimum. Use caution when calling timeBeginPeriod, as frequent calls can significantly affect the system clock, system power usage, and the scheduler. If you call timeBeginPeriod, call it one time early in the application and be sure to call the timeEndPeriod function at the very end of the application.

I suspect on some (perhaps many) machines, the smallest allowable time is lower than 10 milliseconds; its just that the default value is 10 milliseconds.  On my machine, it claims that the smallest is 1 millisecond.  I tried out a quick program (shown below) and it was able to run through 10000 calls to Sleep(1) in under 20000 milliseconds, so while it wasn't quite the 1 millisecond it claimed, it was still five times better than 10 milliseconds.  (I'm guessing that there are hidden costs to calling Sleep(), due to all sorts of OS mechanics and such, no surprise there.)

Spoiler (click to show/hide)

Code: [Select]

#include <iostream>
#include <windows.h>
//also add winmm.lib to the linker dependencies

int main()
{
TIMECAPS timeCaps;
timeGetDevCaps(&timeCaps, sizeof(timeCaps));

std::cout << "Min:  " << timeCaps.wPeriodMin << std::endl << "Max:  " << timeCaps.wPeriodMax << std::endl;

timeBeginPeriod(timeCaps.wPeriodMin);

DWORD begin = timeGetTime();

for (int i = 0; i < 10000; ++i)
{
Sleep(timeCaps.wPeriodMin);
}

DWORD end = timeGetTime();

timeEndPeriod(timeCaps.wPeriodMin);

std::cout << static_cast<double>(end - begin) / 1000.0 << " seconds" << std::endl;

#ifdef _DEBUG
system("PAUSE");
#endif

return 0;
}


This is c++ right? I've done a brief class in c++ and I just finished another class (equally brief) in python with java programing in the second semester. What exactly does this program do? I'm curious.

[Exponent]

This is c++ right? I've done a brief class in c++ and I just finished another class (equally brief) in python with java programing in the second semester. What exactly does this program do? I'm curious.

It was just to demonstrate that a call to Sleep(1) is not always equivalent to a call to Sleep(10) on Windows (that is, Sleep(1) does not always last at least 10 milliseconds).  That is the default behavior, but this behavior can be changed on any system that supports a timer resolution smaller than 10 milliseconds.  The short program I listed simply finds out what the smallest timer resolution the computer supports is, tells the machine to use this timer resolution, and then finds out how long it takes to call Sleep(1) ten thousand times.  Optimally, it should take a little over 10 seconds to execute.  On systems that only support 10 millisecond sleeps, it should instead take around 100 seconds.