• entries
557
1237
• views
423490

# Untitled

78 views

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...

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.

##### Link to comment
Congratulations on beating your computer breakage, I hope I don't ever have to do that crap

##### Link to comment
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...

##### Link to comment
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.

##### Link to comment
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

##### Link to comment
Ohhh, I see. That might be pretty nifty actually...

## Create an account or sign in to comment

You need to be a member in order to leave a comment

## Create an account

Sign up for a new account in our community. It's easy!

Register a new account