Wow, someone has sand in their vagina, just trying to help
UPDATE AS OF 24/10/10
FIXED!!!!!!!!!!!! THE CAUSE OF FRAMESKIPPING - GAME 64HZ ENGINE FLAW
Quote:
This Fixes the 64hz bug , it's true what happens. The engine runs at 64HZ/64FPS but the monitor is at 60HZ. So what the game engine does is drop 4frames per second to sync the engine with the graphics card/monitor this is what causes the frame skipping. Only one other game engine does this and thats the one with Doom 3 and Prey !
(((( FRAMESKIP/STUTTER FIX INSTRUCTIONS ))))
1) Install FallOut 3 Vegas
2) Install the fallout new vegas update 2 or make sure it's ver 1.1.1.271
3) Copy over the fallout new vegas update 2 NOCD ( skiddy )
4) Download and unpack preliminary_4 into your vegas dir
http://www.newvegasnexus.com/downloa...e.php?id=34832
4B) **Or you could try the 4GB And Stuttering Fix Mod instead
http://www.newvegasnexus.com/downloa...e.php?id=35262
Unpack into your vegas directory
5) Download the NEW d3d9 perf fix ( this one doesn't mess with your shaders like the original did , the one tweakforce was moaning about ) , unpack into vegas root directory
http://www.newvegasnexus.com/downloa...e.php?id=34778
6) Run the Main Game launcher Put Water Multisampling to LOW and everything else the way you want it!
7) Apply
8) Run the no_stutter.bat or FNV4GB.exe depending on which stutter mod you used
TOTALY SMOOTH GAMEPLAY HARDLY ANY STUTTER/FRAMESKIPPING( Don't use ifpsclamp )
=============
UPDATE FOR NO_STUTTER.BAT
Quote:
When you run the no_stutter.bat make sure it's working as it can have issues with different dir's to default!. To check this , load the text file called sr_New_Vegas_Stutter_Remover.txt , if it is correct and working it will say
initialize0() running in thread d30
initialize1() running in thread d30
Critical Sections mode 2 (improve fairness):
timeBeginPeriod: 0 -> 1
AutoInitialize finished
Improved_GetTickCount seems to be working
timeEndPeriod: 1 -> 0
Improved_GetTickCount seems to be working <- this is also an important bit , if it isn't working then you will NOT have a stutter/frameskip fix!
However if it says something like this
initialize0() running in thread cf0
initialize1() running in thread cf0
Stutter Remover: failed to find ini path
Creating new .ini file at path E:\Bethesda Softworks\Fallout New Vegas\Data\nvse\plugins\
ERROR:
TextSection::save_file: error opening file "E:\Bethesda Softworks\Fallout New Vegas\Data\nvse\plugins\"
You have a directory problem , basically it's trying to create the directory and it can't. So you will have to do it yourself. You have to go in to the data folder, create a new folder, name it "nvse", then go in to that folder, create a new folder, name that folder "plugins", then go back and run "no_stutter.bat" again.
=======================
26TH OCTOBER UPDATE ( THE PROBLEM SOURCE , *GetTickCount* )
Vegas Stutter Remover
Quote:
If everything is working right then it should create a new sr_New_Vegas_Stutter_Remover.log, which will include a line like "Improved_GetTickCount seems to be working".
4GB exe Memory/Stutter Remover Mod
Quote:
FNV4GB additionally hooks and replaces the Windows GetTickCount() function that may improve stuttering.
I was doing more research today and googled " Windows GetTickCount() " , this is what is improved or fixed in both the stutter fix mods for oblivion/fallout 3/vegas , which fixes my frameskipping.
Quote:
but if I understand your code correctly, what bFix64Hertz does is replace GetTickCount with a version that has a 1ms resolution rather than the ~15ms resolution of the stock one? And I'm guessing this works because Oblivion uses its own timer routines (but using GetTickCount to get elapsed time) rather than the Windows ones?
Reply to the above Quote
Quote:
The windows ones actually come from the HAL rather than windows itself, which might explain why there aren't complaints about this from xbox users... HALs differ a bit between different sorts of computers. Or that's my understanding, all I do is mess with how GetTickCount gets linked in to Oblivion.exe/Fallout/Vegas.
Quote:
I ran this code (post#5) and the only problem I see is periodic stuttering of movement, maybe due to the way GetTickCount values are used. What specific issues are you seeing?
GetTickCount Wikipedia
Quote:
GetTickCount works on all Windows platforms that support the Windows API. It measures time in milliseconds (though it does not have millisecond resolution; its value is typically updated every 16ms), and is in many cases precise enough to measure the speed of code execution in algorithms.
Another VERY interesting post quote
Quote:
Note that this also makes a number of other changes besides the spincounts, including changing Oblivion from running its main game logic timer off of GetTickCount (which increments at 64 Hertz on most computers, creating a nasty interference patterns with most refresh rates, aka microstuttering) to running it off of timeGetTime, wrapping Oblivion in a timeBeginPeriod(1) region, causing it to yield unneeded time with Sleep, and several changes to the way Oblivion game logic timing reacts to framerates and fluctuations in framerates.
Quote:
I'm tired and sleepy, so excuse any mistakes.
It's not a tick stutter. It's still frame stutter. The thing is that you use GetTickCount() to measure the time in ms since the system got started.
So you call the function, you get a value like 256, then later on you call it again and you get 272. You can use the delta between subsequent calls to measure the time that has elapsed (16 ms) and use this to see which things within the game engine need to be handled. E.g. the renderer might be hardwired to run every 30 ms (giving a theoretical maximum of ~33 frames per second).
GetTickCount()'s granularity has varied over the course of various Windows versions, apparently 5 ms on Windows 95 up to 15-16 on more recent versions. (I am not entirely sure which part of the hardware it uses to pull timing from, it doesn't seem to be either RTC or ACPI, maybe the old 8254 PIT?)
I think the problem lies that if you have a granularity of 16 ms and you use a refresh of 60 Hz for your monitor, the rendering parts of your code will constantly be triggered on wrong timing parts to properly coincide with the refresh of the monitor. Using timeGetTime() will give you, typically, a more precise counter, although the default apparently is 5 ms, but that would coincide better with the 60 Hz refresh of the monitor.
(And for those who are more versed in engine/rendering coding, feel free to point out my mistakes, I am still relatively new to graphics engine programming.)
DOOM 3 / PREY
Quote:
Apparently Doom 3 has a fixed 60 fps tic check system wherbyes you can not run it at more than 60 fps. Its like a 1 second interval check, apparently to stop online cheating.
The more i looked into it the more cases i have found with people experiencing this "tic stutter bug".
com_fixedtic 1 and com_precisetic 0 are meant to fix the stutter but alas for me they dont.
What do you guys make of that? , a Possible problem with some systems and TIC Rates? , is it called the tic stutter bug?. Why does the GetTickCount cause me so much grief with frameskipping?.
Of any relevance?
