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

[Veroule]

My testing report on 40d7. 
OS: Win XP SP3.
1GHz Athalon
ATI Radeon 7200, AGP 4x, Omega 2.6.87

Each test is cumulative.

Unzip to new folder
Test 1:

Spoiler (click to show/hide)

Launch DF
Select Windowed from the popup
Watch intros for a short bit
Press space through the rest
Listen to music at the main menu
Quit

Result: perfect

Set FPS display YES in init
Test 2: Repeat of Test1
Result: perfect

Set FPS_CAP to 10000
Test 3: Repeat of Test1
Result: Movies are not properly capped at 100 FPS

Set WINDOWED to YES
Set INTRO to OFF
Set SOUND to OFF
Set MOUSE to NO
Test 4: Main menu
Result FPS 1100 to 1400
Comparative 40d FPS 1500-1600

Set PARTIAL_PRINT to YES:0
Test 5: Main menu
Result FPS 1700-1800 FPS
Comparative 40d FPS 1700-1800, but with more in the 18xx range

GRID set to 112:50
Test 6:
Result FPS 390-440
Comparative 40d FPS 420-430, with odd highs and lows
Visibility identical

Test 7:
Bring any other window to the front, the task manager window works best
Click and hold on the title bar of the other window
Drag the other window over the DF window repeatedly, rapidly dispaying and obscuring portions of the DF window.
Result: all text of the main menu is improperly drawn (textures are torn horribly), latency whitespaces appear, FPS drops to 30-40
Comparative 40d: all text is properly drawn, refreshes are smooth, FPS drops to 60-90

Test 8:
 Click the main X for the window
 Press SPACE
 Result: DF becomes locked in the option menu
 Comparative 40d, pressing SPACE returns to the Main menu

Set WINDOWEDX:896
Set WIDNOWEDY:600
Test 9:
Result FPS 399-43x
Comparative 40d, 430-44x

Set G_FPS to 10
Test 10:
Result FPS 430-440
Coparative 40d, 440-450

So far my tests of 40d7 are showing it as having a slower overall draw rate on my system.  Also my tests 7 and 8 show bugs in the display.  In every case I repeated each of these tests multiple times in a row to make sure that stable numbers were reported for each version of DF.  No secondary loads could be called into account, and all tests starting with test 3 did utilize all of my processor.

[Soralin]

Well the intro movies run faster   Up to nearly 250fps for me.

The sky's the limit again while unpaused. With partial print on for both, the differences for me while running are rather negligible.  I tried watching both several times, but the natural variations on the FPS swamped any actual differences in speed, 40d7 might be 1 fps faster or so at best, in the 30-34fps fort.  The frame/single buffer stuff seemed to have negligible effect.

Although one thing I did try out, 40d7 with partial printing off is much faster then 40d with partial printing off, I was getting around 150-170 on 40d, and 300 on 40d7 with partial printing off on both, whereas with partial printing on and set to 0, I was getting around 350ish with both.  Although I didn't have any problems with partial printing on with either, so that doesn't affect me much.

You're right about the keys, but it was that, or risk the sticky keys bug from 40d. Which would you rather have, a requirement to re-press the scroll keys, or scrolling you can't turn off?

Well since I didn't have that problem with 40d, I'd go for the one that didn't affect me.

[Mephansteras]

I now get a 10 FPS boost with Partial Print on, with or without the Frame Buffer. Single buffer gives me weird ugly lines.

[dwarfed one]

Last patch did it for me (laptop with Intel built-in card).
(NO:2,NO,NO) running crazy fast - more than 240 fps in intro and about 180 in my small fort.
Problem is (YES,NO,NO) and (YES,YES,NO) cause insane fast flickering now. I could see all possible buffers same time.
(YES,NO,YES) just as it was before - mild flicker of black diagonal waves. Speed rather faster than (NO,NO,NO) - jumping from 210 to 280. Looks like it restricted now only by path finding.

[Baughn]

Veroule: Okay, how about in-game?

[Davion]

With 40d7 and partial print on at the default I'm getting about the same frame rate as I did with 40d so that's cool (180-200). That's the settings I have on 40d as well.

Only problem I experience now is when I minimize and restore the window everything flickers/shakes for a second or two and then goes back to normal. That's the only time I've seen it do that.

[Baughn]

Davion: Yes, that's an unfortunate consequence of using partial-printing without framebuffers. It's a trade-off, as always; framebuffers ensure there are never any such problems, but often produce slower output.

Veroule: I've solved the stuck-in-escape-menu problem you saw when attempting to close the window. The game was generating an artificial SDL_KEYDOWN event instead of just pushing an esc event, and it'd never see a corresponding KEYUP event.

[Davion]

Not that big of a deal for me since it only lasts for a second and goes back to normal.

[Baughn]

Not that big of a deal for me since it only lasts for a second and goes back to normal.

Hee. Try setting partial-print to YES:0; that's what some unlucky people get all the time.

[Veroule]

In game testing was to be my next series of test.  Continuing from where I left off in my last post.

I copied 2 different fortress games from 40d.  Both are pocket worlds generated with 40d, and have various amounts of play on them.  I end each test by using task manager to kill the active DF version, and then reset the save data from a clean backup.

Set MOUSE:NO
Set PAUSE_ON_LOAD:YES
Set TEMPERATURE:NO
Set WEATHER:NO
Set INVADERS:NO
Set SHOW_FLOW_AMOUNTS:YES
Test 10:
 Load game "a game"
 Watch it paused
40d7: FPS 2200-2300, with odd spikes as low as 1900 and highs of 5000.  This spikes are a tiny flicker, but they with a periodic consistency of every 2 seconds.  Processor usage 60% memory 84Mb

40d: FPS 1975, 2011-2050.  The 1975 number tends to be consistent for periods of 2 seconds, then the FPS moves through the 2000 range breifly then returns to 1975.  Processor usage 10 - 20% with the same pattern as the FPS. memory 79Mb.

 Press z
40d7: FPS 300-360, processor 100%
40d: FPS 370-386, processor 100%

 Press space
 Press tab until menu is gone
40d7: FPS 2380-2480, processor 70%
40d: FPS 1975, with fluctution like above, processor 10-20% but holds more on the 20%

 Move display to completely unrevealed area
40d7: FPS 1900-2000 processor 50-60%, the CPU numbers look like 40d behavior here
40d: FPS 1975, almost flat minor spiking, processor 0-10% mostly holding at 10%

Test 11:
 Load "main"
 Watch it paused
40d7: FPS 2800-2900, similar spiking, and I even saw it jump to the 10K range once.  Processor 70%, memory 72Mb

40d: FPS identical to test 10.  Processor 20%-30% same behavior as test 10, memory 65Mb

 Press z
40d7: FPS 345-363, processor 100%
40d: FPS 350-383, processor 100%

 Press space
 Press tab until menu gone
40d7: FPS 2800-2900, processor 67-71%
40d: FPS 1975, with small fluctuations into 2000's, processor 20-30% mostly hanging at 30%

 Move to unrevealed area
40d7: FPS 2100 range, processor 60% with occasional drops as low as 50%
40d: FPS 1975 with small fluctuations into 2000's, processor 10-20% mostly hanging at 10%

These tests are all with the game paused so we shouldn't be looking at pathfinding, flow calculations, or any real dwarf activity.

I did check a few other views such as the units, jobs, and options screens, they all resulted in FPS numbers like the stocks screen.  This indicates there is something Toady really needs to optomize with these views.  These numbers are the same as my main menu results below.  This indicates that the problem with these views is not affected by whether a save is loaded.

Looking over all the numbers from a more statistical standpoint we see a processor usage that is consitently 3 times higher with 40d7 then 40d.  The best FPS gain was 50%, with an average gain of 20%.  Using that much more processor for such a small gain is a less then optimal result.  An optimal result would be 3x processor nearly equals 3x FPS.

Of course neither version reached the FPS_CAP of 10K that I had set, and this is likely because of the Windows Sleep inaccuracy.  The code in 40d7 is definitely pushing more FPS through, and making greater utilization of my system.  It comes closer to doing what I have asked it to do, and the only reason I am aiming for such maximum numbers is limit testing.  Working with a more reasonable limit would likely show 40d superior due to its already more optimal code, and lower memory footprint.

I can move on to actually unpausing the game if anyone feels it is needed for comparative purposes.

[Baughn]

It would be interesting, but at this point I think I can conclude that you won't be getting any speedups from 40d7.

On the other hand, at more reasonable framerates you shouldn't be getting noticable slowdown either, so that's okay. Can't win them all.

EDIT: Yes, 40d7 does use more cpu time to draw frames than 40d; this is a necessary trade-off given DF's architecture and the apparently buggy buffer-object support on ATI cards.

Most of the time that's outweighed by improved opengl code giving the driver far less work to do, or improved partial-printing doing the same, but a rare few drivers actually worked fine with the code in 40d, so won't benefit. The best I can hope for there is to make them not suffer much.

[Baughn]

Also, one of you voted for "faster, with problems".

What problems, exactly?

[dwarfed one]

It was me. Hope to see partial printing without flicker 

[Baughn]

It was me. Hope to see partial printing without flicker 

That's what the framebuffer and single-buffer options are for, not to mention the reprint count on partial-printing. As I said in the poll, so long as *one* mode works, it doesn't count as a problem.

It may count as slowness, mind you. Depends on the speed.

[Veroule]

Here is a simple thought.  The G_FPS cap is a maximum, but we don't actually have to draw that often.  One app I built dumped a bit map into openGL for rendering, did SwapBuffers, then would only call SwapBuffers again on a WM_DRAW.  Effectivelly this is a G_FPS of 0, but I was dealling with a static image.  Because my card is single buffered all I had to do for WM_DRAW was a SwapBuffers. If I had more buffers then I would have had to put the image into each, but once each had the image then no further drawing would be required, just the SwapBuffers.

DF on the other hand may change the data behind the image, but the same principle applies.  There is absolutely no reason to output anything to the graphics rendering routines unless the image has changed or the OS is calling for a redraw.

There should be an existing data point to indicate that the image has changed because of the existing partial print code.  It would take me a while to find it, but since you are already intimate with the code you should know where it is.  Doing a single check on this data point is much faster then calculating the time since last redraw, and again there is no need to draw anything if nothing has changed.

I remember from my study of KQ code a long time ago when I first proposed seperating the FPS and G_FPS that the timing calculations to flash different things around a symbol (like thirsty, hungry, fey) and 2 different things standing in the same spot is done within a portion of the redraw code.  A quick look around the BC code makes me think it is in refresh_tiles.  That call could be placed on a timer in the enablerst::loop.

When everything properly sets whether or not a redraw is needed then it should be possibly to set G_FPS to 50, but have the actual graphics redraws at the main menu be 0.  It would redraw once when a user input occurred.  This is part of what I was getting at when I initially suggested seperating FPS and G_FPS back in the 2d versions. There is absolutely no reason to draw ANYTHING when there have been no changes.

Yes, 40d7 does use more cpu time to draw frames than 40d; this is a necessary trade-off given DF's architecture and the apparently buggy buffer-object support on ATI cards.

Correcting PP to only draw when there is a change in the data or an OS request will obviously eliminate this CPU overhead.  I don't know how many I have to state it before it sinks in, if the image hasn't changed don't redraw it.