🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Untitled

posted in DruinkJournal
Published February 21, 2007
Advertisement
Well, I at last have a working PC and a good backup. Acronis True Image 10 is awesome.

Moving swiftly on, delay loaded DLLs are also awesome. My "engine" now supports delay loading of D3D and D3DX and gives pretty errors if either DLL is AWOL. Well, it does for D3DX, I don't have any PCs withouth D3D9.dll on them to test...

Next up, I'd like to get some call stacks logged in my memory manager, which would be nice, and would mean I can get rid of my NEW macro (Which logs the current file, line and function, then calls new) completely.

I also need to get my timer class working, which will use QueryPerformanceCounter. Which means I need to deal with all the associated problems it has, such as the timer skipping backwards or forwards several seconds, it returning different results when running on multiprocessor or dual core systems, etc.
Should I really lock my main thread to CPU 1? That seems to be the usual way to do it, but it sounds like a terrible waste of the main thread...
Previous Entry Untitled
Next Entry Untitled
0 likes 6 comments

Comments

Aardvajk
I don't know how accurate you need the timing for your engine, but personally I've found that if I call:


timeBeginPeriod(1);


at application startup, and then:


timeEndPeriod(1);


at termination, good old timeGetTime() returns results that are suprisingly accurate (i.e. to within a couple of hundreths of a second). To my knowledge this does not suffer from the multi-core problems that QPC does.

Could be wrong about that though. Just thought I'd mention it.

Glad to hear you've got your PC working. Painful when they bugger up.
February 21, 2007 03:17 PM
Prinz Eugn
Congratulations on beating your computer breakage, I hope I don't ever have to do that crap
February 21, 2007 03:33 PM
jollyjeffers
Could always come up with some obscure timing thread architecture - have it fixed to a single core/CPU and other threads query it. The trick of a centralised timer is that you can lock it in step with each frame which can be very useful...

Also, didn't various drivers/updates/patches fix the odd QPC problems? I'm sure AMD released something to solve it for their CPU's...
February 21, 2007 04:24 PM
Evil Steve
Quote: Original post by jollyjeffers
Also, didn't various drivers/updates/patches fix the odd QPC problems? I'm sure AMD released something to solve it for their CPU's...
Yeah, but that relies on the end user having the CPU driver installed, which I don't really want people to have to do.

I don't like the idea of synching threads every frame either, that sounds like it could be horrendous. I've had a look at timeGetTime(), but I'm not sure if it's accurate enough. I could always use timeGetTime() and QPC() together I suppose.
February 22, 2007 03:43 AM
jollyjeffers
Quote: Original post by Evil Steve
I don't like the idea of synching threads every frame either, that sounds like it could be horrendous.
Oh it would be! But that's not quite what I was trying to describe [smile]

If you have a centralized "time server" then it could be notified of the frame count (e.g. by the rendering thread when it calls Present()) and thus 'stop' the clock such that any thread requesting the time for the duration of that frame gets the same value. Synchronizing the time with the frame count, not synchronizing the threads themselves...

If a frame lasts ~10ms then it avoids the potential mistake of threads taking different timing (between 1..10ms) and updating the simulation with a different time delta to other parts of the simulation.

hth
Jack

February 22, 2007 04:47 AM
Evil Steve
Ohhh, I see. That might be pretty nifty actually...
February 22, 2007 12:28 PM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Advertisement
Advertisement