Jump to content

  • Log In with Google      Sign In   
  • Create Account

Dissecting idTech4

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

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

#1   Members   -  Reputation: 104


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 :










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 ?



#2   Members   -  Reputation: 104


Posted 18 July 2014 - 04:23 AM

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

#3   Members   -  Reputation: 686


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;
    {                           // 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

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

	// done before Com/Sys_Init since we need this for error output

	// no abort/retry/fail errors

	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

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

//	Sys_FPU_EnableExceptions( TEST_FPU_EXCEPTIONS );

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

	common->Printf( Sys_FPU_GetState() );

	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 );

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

	::SetCursor( hcurSave );

	::SetFocus( win32.hWnd );

    // main game loop
	while( 1 ) {


#ifdef DEBUG

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

		// run the game

	// never gets here
	return 0;

#4   Members   -  Reputation: 1065


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: 



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

#5   Members   -  Reputation: 1592


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?

An in-game LuaConsole for SFML: https://github.com/FRex/LuaConsole

#6   Members   -  Reputation: 104


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/

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.