Doom 3 engine release and game code

[revelator]

hmm could maybe adapt mh's timing function for doom3 ? the pthread in there kinda gave away that it was for posix systems
though pthreads also exist on win32 most prefer to use the native thread functions.

Thats also a point pvs-studio keeps nagging me about to change to use beginthreadex / endthreadex instead of the old versions doom3 uses.

[mh]

Modified Sys_Milliseconds for Windows:

Code: Select all

int Sys_Milliseconds (void)
{
   static LARGE_INTEGER qpcaccum;
   static LARGE_INTEGER qpcprev;
   static LARGE_INTEGER qpcfreq;
   static bool firstcall = true;

   LARGE_INTEGER qpccurr;

   if (firstcall)
   {
      QueryPerformanceFrequency (&qpcfreq);
      QueryPerformanceCounter (&qpcprev);
      firstcall = false;
      qpcaccum.QuadPart = 0;
      return 0;
   }

   QueryPerformanceCounter (&qpccurr);

   if (qpccurr.QuadPart < qpcprev.QuadPart)
      qpcaccum.QuadPart += 0;
   else qpcaccum.QuadPart += (qpccurr.QuadPart - qpcprev.QuadPart);

   qpcprev.QuadPart = qpccurr.QuadPart;

   return (int) (((double) qpcaccum.QuadPart / (double) qpcfreq.QuadPart) * 1000.0);
}

Also get rid of all timeBeginPeriod and timeEndPeriod calls which will make everything work nicer.

There's also a Sys_Sleep (1) call in idSessionLocal::Frame that should be killed. I've no idea why people continuously think that calling Sleep in a realtime program is somehow a good thing, but you see it time and time again. The reality is that Sleep only guarantees a minimum time to sleep for and will actually sleep for a lot longer owing to 15ms resolution on the timer it uses.

[motorsep]

Is it only for Windows or would Linux needs all that too?

Btw, tried high resolution GUI patch from d3w forums http://i.imgur.com/sOJAt.jpg - wicked :/

[mh]

for Windows

[WickedShell]

There's also a Sys_Sleep (1) call in idSessionLocal::Frame that should be killed. I've no idea why people continuously think that calling Sleep in a realtime program is somehow a good thing, but you see it time and time again. The reality is that Sleep only guarantees a minimum time to sleep for and will actually sleep for a lot longer owing to 15ms resolution on the timer it uses.

Agreed (which is probably partly why it missed so badly on linux). The linux timing code was undershooting its sleep by a millisecond, which I'd thought was to assist in timing, but if your saying that there's a sleep in Frame() then that might also explain it. I was always sorta partial to the approach of (in an uncapped game), calling sleep(0) which basically throws out the remaining time to the scheduler and attempts to come back as soon as possible...

[motorsep]

That's stuff is missing completely in dhewm3, Sys_Sleep(1) can't be found anywhere.

[mh]

Sleep (0) seems to be even worse: http://blogs.msdn.com/b/oldnewthing/arc ... 76847.aspx

In principle the idea does make sense though.

[WickedShell]

Excellent, time to throwing out some more stuff picked up from college CS classes (Where sleep(0) was advocated for that usage)

For arguments sake though, assuming a normal priority task is this a terrible thing? Yes it still preempts background/very low priority things but at the same time this is meant to be an interactive application, where losing to much time is already an issue, and its expected to eat the system load? Within the Linux world again (sorry) if you are using the CFS (Completely Fair Scheduler), those background tasks will still eventually grab processor time.

I guess I'd hold the position that assuming you are trying to run after a certain time delta (say a minimum of 1 ms) that sleep(0) represents a fair compromise between a busy loop that checks time until its incremented (I've seen this before, its sorta scary), and calling sleep(n) where you have an implicit large error in timing and can fall behind your goal. In the busy loop case, even assuming the application is a high priority then sleep(0) is no worse then spinning (probably still better as any other high priority process can grab time). Although in terms of something like Doom3 with that 60FPS cap, that's still low enough I've been trying to trust the scheduler with regards to sleeping appropriately, any thoughts here in terms of sleeping to long/or finer granularity?

Although its definitely something to consider, I hadn't really heard that charge leveled against sleep(0) before, I'll have to play with that here and see what it does to a low priority process. I'd be interested to see how starved it could become.

[revelator]

this one ?

Code: Select all

#if defined( _WIN32 )
    // Spin in place if needed.  The game should yield the cpu if
    // it is running over 60 hz, because there is fundamentally
    // nothing useful for it to do.
    while( 1 )
    {
        latchedTicNumber = com_ticNumber;

        if ( latchedTicNumber >= minTic )
        {
            break;
        }
        // Sys_Sleep( 1 );
    }
#else

disabled gonna test how it affects things.

[revelator]

Hmm seems to work allright

[revelator]

Ok tested extensively and only one remark.

It seems to make some parts stutter (gui intro etc).
Else it seems to work ok.

My guess is that timeBeginPeriod / timeEndPeriod was adjusting timing for the old function.

[mh]

I've been playing quite a bit with it recently and it seems OK for me, but then I haven't really been paying attention to the parts you've called out.

I've also been using toggle run on, and have recently just finished the Alpha Labs. It completely changes the dynamic of the game - rather than being a fairly slow-but-steady pace it's now a series of quite fast spurts; you run around (with bunnyhopping!) for a bit until your stamina drains, then stop and rest, then run some more. It's quite good fun and definitely makes for a good replay. If I wanted to do a more purist run through it I wouldn't use this, but for adding some difference and variety it's quite cool.

[revelator]

Aye makes for a fun ride even though the change is small it certainly adds to the experience.

The timing seems to affect roq rendering the worst making the mars flyby when you start the engine move in a chunky way.
It might be something else entirely but i noticed this after the code change.

[mh]

That Mars scene is actually the engine just drawing a model, the id logo movie is an RoQ though.

Can't say that I'm noticing the same however.

[revelator]

Ah thought that was also a roq ok its models having trouble then hmm.

I use a special menu with widescreen support that has a massive polycount md5mesh for the gui models might be that which its getting hickups from though it seems to vary.

i did some work at getting the engine to support it natively so that it doesnt stretch at 16:9 resolutions with some help from some code of justin marshall.
I will release some game dll's + doom3.exe with this support in. Added some additions of my own that justin might have overlooked so its no longer nessesary to hardcode
the 16:9 and 16:10 resolutions. Biggest change was removing all the hardcoded 640x480 virtual resolutions and instead set them dynamically (all follow the resolution currently set instead of fixed 640x480).
It seems to work fine but ill test it some more before i release it.