Long Loadtimes in AFX when vertical sync is enabled. - LOGGED
by Bloodknight · in Torque 3D Professional · 08/22/2010 (12:46 pm) · 7 replies
Started as a thread in AFX private http://www.torquepowered.com/community/forums/viewthread/119697
load times with vertical sync disabled 5-10 seconds
load times with vertical sync enabled 2-4 minutes
using the Classic Hovel Camp as a test
I did a search but came up empty.
I cant reproduce this in stock torque but thats because as stated in the otehr thread i probably dont have enough resourcs/datablocks loading to notice.
I rely on Vertical sync as my card/pc whistles and starts to generate lots of heat at the unneccesary speeds it runs torque at in general i get between 160-300 frames per second depending on how much junk i have in my mission.
Ive tried looking in the code for how and where to maybe address this, however some parts of the engine are just pure gobbledygook to me, so i just got lost.
I have also tried using the nvidia control panel to force vsynch on the application itself, but torque either overrides it or wont let it take control.
So, if anybod has any ideas on how to address this or knows another post that i missed where this is address that would be great :)
load times with vertical sync disabled 5-10 seconds
load times with vertical sync enabled 2-4 minutes
using the Classic Hovel Camp as a test
I did a search but came up empty.
I cant reproduce this in stock torque but thats because as stated in the otehr thread i probably dont have enough resourcs/datablocks loading to notice.
I rely on Vertical sync as my card/pc whistles and starts to generate lots of heat at the unneccesary speeds it runs torque at in general i get between 160-300 frames per second depending on how much junk i have in my mission.
Ive tried looking in the code for how and where to maybe address this, however some parts of the engine are just pure gobbledygook to me, so i just got lost.
I have also tried using the nvidia control panel to force vsynch on the application itself, but torque either overrides it or wont let it take control.
So, if anybod has any ideas on how to address this or knows another post that i missed where this is address that would be great :)
About the author
#2
08/22/2010 (1:50 pm)
the real question is... why is vsync slowing down the whole application when really it should be applied only to the rendering and to that end surely it should only be a link to a graphics card feature? 
#3
08/24/2010 (2:36 pm)
I have logged this as TQA-914 for the QA team to verify. I am unsure whether this is an issue directly with the T3D codebase or if it is in the added complexity of AFX since it is a rather massive and amazingly complex product. 
#4
11/23/2010 (1:02 pm)
vsync will block Torque.
#5
vsynch should have nothing to do with anything other than the screen rendering, unless vsynch combined with the gui progress bar is causing a massive lockup something i havent actually tested as of yet then i see no reason why vsynch should have any control over the loading of scripts and assets upon mission load.
Other than that, ive actually had no problems with vsynch at all, once the mission is loaded i have no problems whatsoever, i havent tested the system with massive AI or high drawcalls to see if vsynch has anegative impact on torque as a whole, but up to now the loading is the only problem.
the ony reason i even found this is a number of systems generate a high pitched whistle when games or other 3d apps have very high frame rates, noticable at 250+ fps on the systems i have, and this becomes very annoying to work with.
disclaimer... i have yet to test any of this on 1.1 b3 to see if the problem is resolved
11/23/2010 (1:39 pm)
theres nothing like a detailed and accurate description of a problem, and that weas nothing like a detailed and accurate description of a problem.vsynch should have nothing to do with anything other than the screen rendering, unless vsynch combined with the gui progress bar is causing a massive lockup something i havent actually tested as of yet then i see no reason why vsynch should have any control over the loading of scripts and assets upon mission load.
Other than that, ive actually had no problems with vsynch at all, once the mission is loaded i have no problems whatsoever, i havent tested the system with massive AI or high drawcalls to see if vsynch has anegative impact on torque as a whole, but up to now the loading is the only problem.
the ony reason i even found this is a number of systems generate a high pitched whistle when games or other 3d apps have very high frame rates, noticable at 250+ fps on the systems i have, and this becomes very annoying to work with.
disclaimer... i have yet to test any of this on 1.1 b3 to see if the problem is resolved
#6
Having said that, it'll be something bizarre about datablocks (probably to do with the network) which means their load speed is tied to framerate.
11/23/2010 (1:41 pm)
BloodKnight - if Vsync is enabled then Present BLOCKS when called too often. So the Torque framerate - and that includes it ticking everything (obviously) - will be tied to the display refresh rate.Having said that, it'll be something bizarre about datablocks (probably to do with the network) which means their load speed is tied to framerate.
#7
This seem to me to have potentially horrimbe ramifications, particularly when it comes to AI processing which as far as i know takes up a large portion of the CPU cycles in many games, and then physics which again, takes an awful ot of real time CPU cycles.
i am far from an expert programmer dispite my years of experience ive not worked on any projects anywhere near as complex as a game engine, profiling is something ive never had to try on a scale such as this and i wouldnt honestly know where to start.
11/24/2010 (7:00 pm)
the current version of AFX hs a workaround (Thank you Master Faust!) however it still seems to me that vsync is operating in the wrong place, i'm lacking much knowledge in such things, but the nvidia control panel has force vsync option, that i'm assuming has no effect on the application itself and is purely GPU based.This seem to me to have potentially horrimbe ramifications, particularly when it comes to AI processing which as far as i know takes up a large portion of the CPU cycles in many games, and then physics which again, takes an awful ot of real time CPU cycles.
i am far from an expert programmer dispite my years of experience ive not worked on any projects anywhere near as complex as a game engine, profiling is something ive never had to try on a scale such as this and i wouldnt honestly know where to start.
Associate Steve Acaster
[YorkshireRifles.com]