1.8 vs 1.7.1 performance?

#21 @Rene - I'm in no rush, but by patch, do you mean something soon we can use or something in a 1.8.1 patch that is coming much further down the road?

#22 I wish they would do what some other engines do, and post the little bug fixes in forum for the folk that NEED the fix right away.

#23 @Caylo, He did on IRC and recommended those changes.

#24 IRC is not the forums. IRC is not search-able and database-ed for future generations to marvel over. Also notice my undefined participle use over bug fixes is more all encompassing definition of 'bug fixes' not just this particular subject.

Why do i keep reading an undertone of hostility? I feel like Copernicus trying to convince flat minded people the world is round... You can prove for yourself its not simply the TerrainBlock's resource pointer, by running profile tests without any terrain. Also how to explain people commenting that they have 1.7.1 vrs 1.8 performance problems with Atlas terrain? See how the facts dont all line up?

I love to be proven wrong, post some facts so i can go eat worms....

#25 I think the only hostility being shown in this thread is from you. I'm certainly not exhibiting one. This thread was created because I noticed an issue and wondered if other people were experiencing the same thing, Turns out other people were, and we're all working together to come to a conclusion and fix. I have no idea why the perf is suffering, nor did I claim I did. I never said it was terrain or fencing, Other people did and I posted my results with the fencing fixes someone mentioned to me on IRC. I don't understand what *I've* done wrong... But I'd like to keep a constructive thread going. You've provided some valuable insight and I appreciate that but can you not rain on the parade with posts like that? And for the record I'm pretty sure it's not terrain as I get the same poor results on a blank mission with just a skybox, and I'm going to assume with the changes I made it's probably not the fencing; assuming the advice was sound. I didn't even know what fencing was until this thread.

#26 Im am sorry, I should have understood that referring to literature in a metaphoric manor could easy be misinterpreted, even with the Copernicus clue.

Im not even misting on the parade, but the only constructive thread i keep getting is "RENE......" who i keep pointing out seems to be working on the wrong issue.

I do keep forgetting what and who im collaborating with here, as a toy/hobby and not exchanging ideas with co-workers.

#27 The only reason I posted what I posted was I thought what you said was a little out of line, then I went and checked your other forums posts and it's obvious you like stirring the pot and trolling. I'm not going to justify it further with a response so lets get back to the issue at hand. I posted metrics information on your thread, check it out.

#28 indeed, thanks. (I take offence! my grandfather was a bridge troll!)

#29 fwiw - Back when I was developing game engines, I was very happy when they added state blocks to DirectX. It was super-annoying to have to juggle states, and adding in new features would sometimes cause things later down the scene graph to break for no apparent reason.

Mind you, I was very cautious about changing render states, so everything was batched by state (including material). I obeyed the graphics golden rule: Change state as little as possible.

So, I sat down, and rewrote all of my code to use state blocks. This took about two days. It solved all of my problems, every single one. However - I saw between a 20% and 60% decrease in framerate (depending on complexity). My complaints to Microsoft went unheeded - "It's a new feature, driver support will be better in the future, and it will get faster". Being as I had forgotten to check in the code before hand, I then spent the next two or three days ripping the state block code back out.

Now, i'm not saying this is what is causing the slow down. Maybe it is completely unrelated. But I do get an incredible sense of deja-vu.

#30 Interesting Jaimi, ill poke at the code and see if there is any way to test that idea.


EDIT:
I cant find anyway to test this. Impossible to test.

#31
@William
The changes will be up in the forum so anyone can apply them.

@Jaimi
I'd be surprised if we'd see a significant negative impact from the change over to stateblocks. So far, none of the profiling info hints in that direction (there's slight increases here and there but none that matter). Also, AFAIK some of the GG games (Legions, MB Ultra?) shipped with a GFX2-based version of Torque, so I suppose that tech can be considered reasonably mature.

#32 At the beginning of StandardMainLoop::doMainLoop in mainLoop.cpp, add

tm->setBackgroundThreshold(mClamp(sgBackgroundProcessSleepTime, 1, 200));
tm->setForegroundThreshold(mClamp(sgTimeManagerProcessInterval, 1, 200));

This should resolve the performance issues you've been seeing, except for those with Legacy terrain.

This fix, and various improvements to Legacy terrain, will be in 1.8.1.

#33 Holy cow, now my TGEA1.8 FPS test much faster then TGEA1.7.1!

What is the technical reason that fix works, what is it doing that is different?

#34 @Caylo: We told you GFX2 is vastly improved :). The foreground and background thresholds are a period of time Torque will sleep for after each frame. The defaults which are hardcoded in the TimeManager class are 5ms foreground and 10ms background. This meant that after every frame, TGEA 1.8 would sleep until the total time necessary for the frame was 5ms. Of course, the Win32 sleep function is only precise to within one tick (10ms), so even if that caused Torque to sleep for a "single" millisecond, it might wind up sleeping for 10.

The default pref values are 1ms for the foreground and 25 ms for the background. That fix sets the pref values in the TimeManager, which will generally prevent any actual sleeping (sleep(0) might still happen, but it's a special case). And there's your instant performance boost with two easy lines of code.

#35 @Alex - awesome, did the trick for me. Now my only thing is that this works fine in window'ed mode, but if I go back to fullscreen, it's back to the same numbers i was getting before applying the fix. Do you know if this works/relevant for fullscreen too.
thanks!

#36 my bad, i wasn't running the same test condition...with fullscreen i had 8x AA on hence the slowere frame rate....now they are the same...awesome fix Alex!

#37 Hey Alex, how about posting the terrain fix too :D

#38 Alex, I added those two lines in mainLoop.cpp and didn't improve the FPS. Any ideas?

#39

Quote:This fix, and various improvements to Legacy terrain, will be in 1.8.1.

MmMmm... tasty.