Topic: FotF: Help test the output code for the next version of DF (40d13) (Read 376461 times)

Soldats · « **Reply #60 on:** December 21, 2008, 07:08:05 pm »

ok redid some of the tests but still had the g_fps issue where if it is above 43 total fps will be capped at 43

Standard plus 1000 fps cap, 20 g_fps cap
fps=860-853 Very stiff fps still it really just jumps between the two number
thats about a 30 fps improvement though

Standard plus 1000 fps cap, 30 g_fps cap
fps=804 Very stiff fps too it almost never fluctuates
about 70 fps improvement

ok these next tests I did just for the hell of it and i was very surprised
Standard plus 10000 fps cap, 20 g_fps cap
Fps=......are you ready? 10000 very stiff never fluctuates.....

Standard plus 10000 fps cap, 43 g_fps cap
Fps=10000 not so stiff but it is hard to tell since battles are over in .5 seconds but the lowest i saw was 8000....

Standard plus 5000 fps cap, 20 g_fps cap
fps=5000 very stiff

well i kept testing to see where exactly I started to experience the fps loss and narrowed it down to some where between 2470 and 2490. If I set the fps cap between those numbers i get weird fps behavior where it will flash between a number much lower than the cap (like 1900) and then one slightly higher than I have set( like 2485 when fps cap was set on 2470) but for 2490 and above it remains pegged at the cap

Note that I cannot seem to exceed 10000 fps despite the cap limit but I assume that that is a hardcoded limit to prevent my machine from exploding

Baughn I dont know how much you about hardware but it should be noted that I have a rather high end machine the ati hd radeon 4870 gpu is currently Ati/amd flagship gpu and to put that in Nvidia terms it currently rates somewhere around a GTX 280/260 no offense intended

. Also I kept an eye on my cpu usage its pegged at about 50% for each core during battles without ever reaching 100% I also messed with setting some core affinities which would max out one of the cores but all that really didd was hurt my fps some so i stopped messing with it

EDIT: I will be out for dinner soon so I may take some time to respond to any further posts

Greiger · « **Reply #61 on:** December 21, 2008, 07:15:50 pm »

Still fails...but at least it takes a bit longer for it to, and it outputs a wall of text first.

Spoiler (click to show/hide)

Maybe my stuff is just plain too old. If that's the case it probably wouldn't be good for me to keep this from going anywhere unless others are still having issues. Can't have fast code compatible with everything I suppose.

bhelyer · « **Reply #62 on:** December 21, 2008, 07:18:16 pm »

I have an altogether different angle to my co-conspirator here; linux support (which is why I ported it to SDL). So any comments regarding linux experiences would be great. I see that SDL_image is now a dependency due to the OpenGL stuff, which is fine, but it means it won't work OOTB with a plain Ubuntu install for example. I also don't know exactly how these binaries were compiled, but I'm assuming that a newer GLIBC will be required (I would be interested to see how many are running with glibc 2.3 or older. People using CentOS and Debian Stable I suspect.) My setup is a single core, 32 bit, single monitor, ATI environment, so I can't do all the testing myself.

Thanks guys.

bhelyer · « **Reply #63 on:** December 21, 2008, 07:26:10 pm »

~~What are your specs Greiger? In particular, make and model of your GPU, please.~~

Edit: I can read.

Baughn · « **Reply #64 on:** December 21, 2008, 07:26:54 pm »

Quote from: Xgamer4 on December 21, 2008, 06:50:08 pm

I tried running it on my laptop. ATI Radeon X1100, I believe. It's running the Omega drivers. It pops up the BC screen and shows a bit of red text, as if it's trying to display something, and then the screen goes black. The console output is this:

*snip*
What were the other things you wanted me to run?

That looks bad. I've updated the build with yet more error checking, though (at this rate, I'm going to end up with error checks after every single OpenGL call); could you try again?

It won't work, but the output will help.

Baughn · « **Reply #65 on:** December 21, 2008, 07:32:18 pm »

Then again, why not?

Now it *does* check every single call, individually.
If you've already read my last message and downloaded, please do it again.

Exponent · « **Reply #66 on:** December 21, 2008, 08:23:28 pm »

Quote from: Baughn on December 21, 2008, 05:43:55 pm

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:

Quote

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;
}

Xgamer4 · « **Reply #67 on:** December 21, 2008, 08:57:19 pm »

Quote from: Baughn on December 21, 2008, 07:26:54 pm

Quote from: Xgamer4 on December 21, 2008, 06:50:08 pm
I tried running it on my laptop. ATI Radeon X1100, I believe. It's running the Omega drivers. It pops up the BC screen and shows a bit of red text, as if it's trying to display something, and then the screen goes black. The console output is this:

*snip*
What were the other things you wanted me to run?

That looks bad. I've updated the build with yet more error checking, though (at this rate, I'm going to end up with error checks after every single OpenGL call); could you try again?

It won't work, but the output will help.

Ok, here's the result. It looks like it dies somewhere in Frame 5:

Spoiler (click to show/hide)

And yeah, that's after you updated it to error check after every OpenGL call. And I'm not exactly technically illiterate, so if there's any settings you want me to toy with in my drivers I'll gladly help ya test.

Baughn · « **Reply #68 on:** December 21, 2008, 09:06:07 pm »

Nah, 5 is just the highest frame number it'll actually print, in order to reduce spam.

Odd, though. if it survives that long, it shouldn't die at *all*.. unless something is terribly wrong inside the drivers.

Which those errors suggest is probably the case.
Something is breaking horribly when I try to use VBOs, despite your drivers claiming the card supports them. I'll go add an option to the config file if disabling them helps; to test that, please try the version I just uploaded, which has them hardcoded as disabled.

Xgamer4 · « **Reply #69 on:** December 21, 2008, 09:15:51 pm »

Works perfectly. FPS cap is 10000, GFPS is 10. At menu I alternate between something like 6000 and 8000, in battle I get 1700ish.

Spoiler (click to show/hide)

Soldats · « **Reply #70 on:** December 21, 2008, 09:41:48 pm »

well I just downloaded the version you got up now and all my problems have disappeared got a solid 10000 fps with 50 g_fps, double grid 160:50, and double res size 1280x600

Im happy

Thanks

Mu. · « **Reply #71 on:** December 21, 2008, 10:04:38 pm »

Where can I download toady's original, unoptimized version (for comparison)?

Salbrismind · « **Reply #72 on:** December 21, 2008, 10:06:42 pm »

Edit:
I feel like a noob posting this but:

1. How does Battle Champs have anything to do with Dwarf Fortress? Did I download something wrong?
2. How do I change all these things like
-Fps
-Screen Size
-Tile size

I tried things like "windowsizex = ####"
But when i made it large the words and game became really small and stuck to the top left corner. How do I make the game render lots more units at once?

Aside from that on default settings the game runs fine. What info do you need from me?
I tried it on Max Fps at 100000, 800x600 size and it runs at 250+ fps in battles and about 500 at title.

Karlito · « **Reply #73 on:** December 21, 2008, 10:08:47 pm »

The original Battle Champs can be found here. Just scroll down to Toady's second post.

Mu. · « **Reply #74 on:** December 21, 2008, 10:11:00 pm »

Quote from: Karlito on December 21, 2008, 10:08:47 pm

The original Battle Champs can be found here. Just scroll down to Toady's second post.

Thank you.

News:

Poll

After experimenting with the options, how is 40d13? Problems only count if the defaults don't work.

Author Topic: FotF: Help test the output code for the next version of DF (40d13) (Read 376461 times)

Soldats

Re: Future of the fort: Help test the output code for the next version of DF

Greiger

Re: Future of the fort: Help test the output code for the next version of DF

bhelyer

Re: Future of the fort: Help test the output code for the next version of DF

bhelyer

Re: Future of the fort: Help test the output code for the next version of DF

Baughn

Re: Future of the fort: Help test the output code for the next version of DF

Baughn

Re: Future of the fort: Help test the output code for the next version of DF

Exponent

Re: Future of the fort: Help test the output code for the next version of DF

Xgamer4

Re: Future of the fort: Help test the output code for the next version of DF

Baughn

Re: Future of the fort: Help test the output code for the next version of DF

Xgamer4

Re: Future of the fort: Help test the output code for the next version of DF

Soldats

Re: Future of the fort: Help test the output code for the next version of DF

Mu.

Re: Future of the fort: Help test the output code for the next version of DF

Salbrismind

Re: Future of the fort: Help test the output code for the next version of DF

Karlito

Re: Future of the fort: Help test the output code for the next version of DF

Mu.

Re: Future of the fort: Help test the output code for the next version of DF