Jump to content

  • Log In with Google      Sign In   
  • Create Account


Dissecting idTech4

  • You cannot reply to this topic
5 replies to this topic

#1 Vidrohi   Members   -  Reputation: 104

Like
0Likes
Like

Posted 18 July 2014 - 04:11 AM

Recently, I realized that even knough I understand many parts of game dev, a complete game and engine and how everything comes together is beyond me, so I looked into a few options and settled on diving into idTech4 to better my understanding of game dev.

 

The problem , however, is that information is very scant. There is no official documentation available and aside from these three sources :

 

http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code

 

http://fabiensanglard.net/doom3/index.php

 

and

 

http://www.iddevnet.com/doom3/code.php

 

I have found very little info, I have gotten the game to run from visual studio and stuff , so atleast that is taken care of, but I am unsure of how to proceed with trying to understand this massive codebase.

 

I kinda want to break stuff down and go into one component at a time, maybe starting with AI and character animation, but I cant even find the entry point into these subsystems, can anyone here give me some sage advice ?

 

Thanks



Sponsor:

#2 Vidrohi   Members   -  Reputation: 104

Like
0Likes
Like

Posted 18 July 2014 - 04:23 AM

Also, in case someone wants to pair dissect this with me , gimme a shout :)



#3 rAm_y_   Members   -  Reputation: 327

Like
0Likes
Like

Posted 18 July 2014 - 09:06 AM

Generally I would search for WinMain as that will always be the starting point. You may want to look into the Unreal Engine source code, can be downloaded for $19, it's much cleaner code that idtech. For example in the doom 3 BFG source WinMain is in DOOM-3-BFG-master\neo\sys\win32\win_main.cpp, you can set some breakpoint there and work your way through it. You can see from the snippet below where the main game loop starts, this always runs as long as the game is running every other subsytem/call is run inside here.

int WINAPI WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow ) {

	const HCURSOR hcurSave = ::SetCursor( LoadCursor( 0, IDC_WAIT ) );

	Sys_SetPhysicalWorkMemory( 192 << 20, 1024 << 20 );

	Sys_GetCurrentMemoryStatus( exeLaunchMemoryStats );

#if 0
    DWORD handler = (DWORD)_except_handler;
    __asm
    {                           // Build EXCEPTION_REGISTRATION record:
        push    handler         // Address of handler function
        push    FS:[0]          // Address of previous handler
        mov     FS:[0],ESP      // Install new EXECEPTION_REGISTRATION
    }
#endif

	win32.hInstance = hInstance;
	idStr::Copynz( sys_cmdline, lpCmdLine, sizeof( sys_cmdline ) );

	// done before Com/Sys_Init since we need this for error output
	Sys_CreateConsole();

	// no abort/retry/fail errors
	SetErrorMode( SEM_FAILCRITICALERRORS );

	for ( int i = 0; i < MAX_CRITICAL_SECTIONS; i++ ) {
		InitializeCriticalSection( &win32.criticalSections[i] );
	}

	// make sure the timer is high precision, otherwise
	// NT gets 18ms resolution
	timeBeginPeriod( 1 );

	// get the initial time base
	Sys_Milliseconds();

#ifdef DEBUG
	// disable the painfully slow MS heap check every 1024 allocs
	_CrtSetDbgFlag( 0 );
#endif

//	Sys_FPU_EnableExceptions( TEST_FPU_EXCEPTIONS );
	Sys_FPU_SetPrecision( FPU_PRECISION_DOUBLE_EXTENDED );

	common->Init( 0, NULL, lpCmdLine );

#if TEST_FPU_EXCEPTIONS != 0
	common->Printf( Sys_FPU_GetState() );
#endif

	if ( win32.win_notaskkeys.GetInteger() ) {
		DisableTaskKeys( TRUE, FALSE, /*( win32.win_notaskkeys.GetInteger() == 2 )*/ FALSE );
	}

	// hide or show the early console as necessary
	if ( win32.win_viewlog.GetInteger() ) {
		Sys_ShowConsole( 1, true );
	} else {
		Sys_ShowConsole( 0, false );
	}

#ifdef SET_THREAD_AFFINITY 
	// give the main thread an affinity for the first cpu
	SetThreadAffinityMask( GetCurrentThread(), 1 );
#endif

	::SetCursor( hcurSave );

	::SetFocus( win32.hWnd );

    // main game loop
	while( 1 ) {

		Win_Frame();

#ifdef DEBUG
		Sys_MemFrame();
#endif

		// set exceptions, even if some crappy syscall changes them!
		Sys_FPU_EnableExceptions( TEST_FPU_EXCEPTIONS );

		// run the game
		common->Frame();
	}

	// never gets here
	return 0;
}


#4 uglybdavis   Members   -  Reputation: 901

Like
5Likes
Like

Posted 18 July 2014 - 11:02 AM

Dissecting a production engine is never a fun learning experience. In production, things make it into code that shouldn't. That's just life.

 

How about starting with a more modern engine, that was made specifically to learn from: 

https://github.com/blackberry/GamePlay

 

There is an older GDC video about it, but i lost the link.



#5 FRex   Members   -  Reputation: 276

Like
1Likes
Like

Posted 22 July 2014 - 07:00 PM

If you do decide to dissect it, alone or with someone, will you make a blog or news posts about it to increase the net sum of documentation available?



#6 Vidrohi   Members   -  Reputation: 104

Like
0Likes
Like

Posted 28 July 2014 - 09:02 PM

@rAm_y_  I actually did start there and went as deep as I could, however , after some point you just need someone who knows better to hold your hand for a bit :)

 

@uglybdavis I realize that, however , its those intricacies that I am trying to understand with this attempt, I could very well just mess with my own engine, but I feel like I have reached the limit of what I can learn from it.

 

@FRex I already did , havent gotten very far into it because I got busy with work, but here is the link to my blog :http://strangenessensues.blogspot.com/







PARTNERS