Doom 3 engine release and game code

[revelator]

Holy bitchorama well the only thing we would actually need would be bink.c and change its function naming scheme to fit Doom3's unfortunatly id stripped the source completely and only left in the protos in the headers so how it was setup from the beginning will be a bit of a guesswork.

I also found the spot where it crashes the old doom games strangely its in the sprite code they had a cast from a const char * const to an *(int*) that looked something like this
intname = *(int *)array; but it returned a NULL pointer whenever you tried to start the doom1 or 2 game. The cast is pretty weird cause theres no way to do it with a C++ cast as far as i can tell,
i tried *reinterpret_cast<int *>(array) *const_cast *static_cast and none of them is compilable msvc just keeps on bitching that theres no known way to convert that type but the C cast is ok and thats starnge cause the C casts just iterate through the C++ stayle casts untill it hits something that accepts it so either msvc is stupid or im missing something obvious which i may since im not used to C++.

[mh]

What's especially interesting here is that a D3D version should now be viable.

[r00k]

*wink-wink *nudge_nudge

[revelator]

What's especially interesting here is that a D3D version should now be viable

Sledgehammer hehe but yeah maybe possible now

[revelator]

Will be a huge undertaking the new renderer looks nothing like the old and i was right Doom3 uses glsl internally but can convert cg at runtime.
The old ARB assembly ones still seem to be there to though the backend was updated somewhat.

As for the video code the calls we need are these.

_BinkClose@4
_BinkDoFrameAsync@12
_BinkDoFrameAsyncWait@8
_BinkGetError@0
_BinkGetFrameBuffersInfo@8
_BinkGetKeyFrame@12
_BinkGoto@12
_BinkNextFrame@4
_BinkOpenWithOptions@12
_BinkOpenXAudio2@4
_BinkPause@8
_BinkRequestStopAsyncThread@4
_BinkSetMemory@8
_BinkSetSoundSystem@8
_BinkSetVolume@12
_BinkSetWillLoop@8
_BinkStartAsyncThread@8
_BinkWaitStopAsyncThread@4

taken from a depend scan of the original exe.

[revelator]

Ok after some digging it might not be to hard adapting the new renderer though we need to get rid of draw_arb2.cpp and draw_common.cpp
The new renderer has comparable functions in tr_backend_draw.cpp renderprogs.cpp and renderprogs_GLSL.cpp the naming for the interaction functions are even the same (except the GLSL one).

the ARB assembly one now uses parts of the GLSL render backend functions for getting the correct offsets / uniforms etc.

see here

Code: Select all

void idRenderProgManager::Init() {
	common->Printf( "----- Initializing Render Shaders -----\n" );

	for ( int i = 0; i < MAX_BUILTINS; i++ ) {
		builtinShaders[i] = -1;
	}
	struct builtinShaders_t {
		int index;
		const char * name;
	} builtins[] = {
		{ BUILTIN_GUI, "gui.vfp" },
		{ BUILTIN_COLOR, "color.vfp" },
		{ BUILTIN_SIMPLESHADE, "simpleshade.vfp" },
		{ BUILTIN_TEXTURED, "texture.vfp" },
		{ BUILTIN_TEXTURE_VERTEXCOLOR, "texture_color.vfp" },
		{ BUILTIN_TEXTURE_VERTEXCOLOR_SKINNED, "texture_color_skinned.vfp" },
		{ BUILTIN_TEXTURE_TEXGEN_VERTEXCOLOR, "texture_color_texgen.vfp" },
		{ BUILTIN_INTERACTION, "interaction.vfp" },
		{ BUILTIN_INTERACTION_SKINNED, "interaction_skinned.vfp" },
		{ BUILTIN_INTERACTION_AMBIENT, "interactionAmbient.vfp" },
		{ BUILTIN_INTERACTION_AMBIENT_SKINNED, "interactionAmbient_skinned.vfp" },
		{ BUILTIN_ENVIRONMENT, "environment.vfp" },
		{ BUILTIN_ENVIRONMENT_SKINNED, "environment_skinned.vfp" },
		{ BUILTIN_BUMPY_ENVIRONMENT, "bumpyEnvironment.vfp" },
		{ BUILTIN_BUMPY_ENVIRONMENT_SKINNED, "bumpyEnvironment_skinned.vfp" },

		{ BUILTIN_DEPTH, "depth.vfp" },
		{ BUILTIN_DEPTH_SKINNED, "depth_skinned.vfp" },
		{ BUILTIN_SHADOW_DEBUG, "shadowDebug.vfp" },
		{ BUILTIN_SHADOW_DEBUG_SKINNED, "shadowDebug_skinned.vfp" },

		{ BUILTIN_BLENDLIGHT, "blendlight.vfp" },
		{ BUILTIN_FOG, "fog.vfp" },
		{ BUILTIN_FOG_SKINNED, "fog_skinned.vfp" },
		{ BUILTIN_SKYBOX, "skybox.vfp" },
		{ BUILTIN_WOBBLESKY, "wobblesky.vfp" },
		{ BUILTIN_POSTPROCESS, "postprocess.vfp" },
		{ BUILTIN_STEREO_DEGHOST, "stereoDeGhost.vfp" },
		{ BUILTIN_STEREO_WARP, "stereoWarp.vfp" },
		{ BUILTIN_ZCULL_RECONSTRUCT, "zcullReconstruct.vfp" },
		{ BUILTIN_BINK, "bink.vfp" },
		{ BUILTIN_BINK_GUI, "bink_gui.vfp" },
		{ BUILTIN_STEREO_INTERLACE, "stereoInterlace.vfp" },
		{ BUILTIN_MOTION_BLUR, "motionBlur.vfp" },
	};
	int numBuiltins = sizeof( builtins ) / sizeof( builtins[0] );
	vertexShaders.SetNum( numBuiltins );
	fragmentShaders.SetNum( numBuiltins );
	glslPrograms.SetNum( numBuiltins );

	for ( int i = 0; i < numBuiltins; i++ ) {
		vertexShaders[i].name = builtins[i].name;
		fragmentShaders[i].name = builtins[i].name;
		builtinShaders[builtins[i].index] = i;
		LoadVertexShader( i );
		LoadFragmentShader( i );
		LoadGLSLProgram( i, i, i );
	}

	// Special case handling for fastZ shaders
	builtinShaders[BUILTIN_SHADOW] = FindVertexShader( "shadow.vp" );
	builtinShaders[BUILTIN_SHADOW_SKINNED] = FindVertexShader( "shadow_skinned.vp" );

	FindGLSLProgram( "shadow.vp", builtinShaders[BUILTIN_SHADOW], -1 );
	FindGLSLProgram( "shadow_skinned.vp", builtinShaders[BUILTIN_SHADOW_SKINNED], -1 );

	glslUniforms.SetNum( RENDERPARM_USER + MAX_GLSL_USER_PARMS, vec4_zero );

	vertexShaders[builtinShaders[BUILTIN_TEXTURE_VERTEXCOLOR_SKINNED]].usesJoints = true;
	vertexShaders[builtinShaders[BUILTIN_INTERACTION_SKINNED]].usesJoints = true;
	vertexShaders[builtinShaders[BUILTIN_INTERACTION_AMBIENT_SKINNED]].usesJoints = true;
	vertexShaders[builtinShaders[BUILTIN_ENVIRONMENT_SKINNED]].usesJoints = true;
	vertexShaders[builtinShaders[BUILTIN_BUMPY_ENVIRONMENT_SKINNED]].usesJoints = true;
	vertexShaders[builtinShaders[BUILTIN_DEPTH_SKINNED]].usesJoints = true;
	vertexShaders[builtinShaders[BUILTIN_SHADOW_SKINNED]].usesJoints = true;
	vertexShaders[builtinShaders[BUILTIN_SHADOW_DEBUG_SKINNED]].usesJoints = true;
	vertexShaders[builtinShaders[BUILTIN_FOG_SKINNED]].usesJoints = true;

	cmdSystem->AddCommand( "reloadShaders", R_ReloadShaders, CMD_FL_RENDERER, "reloads shaders" );
}

[revelator]

Fix for doom classic crashing by tr3b though i made a better fix

Code: Select all

// needs to be NULL terminated
const char * const sprnames[NUMSPRITES + 1] = {
    "TROO","SHTG","PUNG","PISG","PISF","SHTF","SHT2","CHGG","CHGF","MISG",
    "MISF","SAWG","PLSG","PLSF","BFGG","BFGF","BLUD","PUFF","BAL1","BAL2",
    "PLSS","PLSE","MISL","BFS1","BFE1","BFE2","TFOG","IFOG","PLAY","POSS",
    "SPOS","VILE","FIRE","FATB","FBXP","SKEL","MANF","FATT","CPOS","SARG",
    "HEAD","BAL7","BOSS","BOS2","SKUL","SPID","BSPI","APLS","APBX","CYBR",
    "PAIN","SSWV","KEEN","BBRN","BOSF","ARM1","ARM2","BAR1","BEXP","FCAN",
    "BON1","BON2","BKEY","RKEY","YKEY","BSKU","RSKU","YSKU","STIM","MEDI",
    "SOUL","PINV","PSTR","PINS","MEGA","SUIT","PMAP","PVIS","CLIP","AMMO",
    "ROCK","BROK","CELL","CELP","SHEL","SBOX","BPAK","BFUG","MGUN","CSAW",
    "LAUN","PLAS","SHOT","SGN2","COLU","SMT2","GOR1","POL2","POL5","POL4",
    "POL3","POL1","POL6","GOR2","GOR3","GOR4","GOR5","SMIT","COL1","COL2",
    "COL3","COL4","CAND","CBRA","COL6","TRE1","TRE2","ELEC","CEYE","FSKU",
    "COL5","TBLU","TGRN","TRED","SMBT","SMGT","SMRT","HDB1","HDB2","HDB3",
    "HDB4","HDB5","HDB6","POB1","POB2","BRS1","TLMP","TLP2", '\0'
};

thats in doomclassic/info.cpp

and in info.h change the extern to look like this

extern const char * const sprnames[NUMSPRITES + 1];

now doomclassic works.

[revelator]

Btw this little hack is not possible in msvc 2012 without some workaround

#define private public
#define protected public

you need to put this in preprocessor

_XKEYCHECK_H

[revelator]

Hmm might be a bit harder than i first anticipated to backport the renderer since the new VBO function is somewhat different.
Might need to scrap the old Doom3 renderer completely.

[revelator]

Had some input from the ID dev who uploaded the bfg edition source about my using of '\0' instead of a NULL pointer, it should not be right but it magically works and after sifting through the info i could get on it it seems its actually perfectly legal and intended behaviour (taken from the mouth of one of the C++ standard devs) since '\0' is just an const integer 0 pointer, but if you where to do say '\1' then its another ballgame interely.

And something i was not aware of is to avoid try catch exception statements and instead use if else since the exception handling is very very slow.
Ofc theres situations where it might be handy (or even needed) but as a footnote its not a good idea to use them overly.

Ill be visiting my dad this christmas so i wont be back before newyear, so merry christmas all

[qbism]

merry xmas, have a good trip.

[revelator]

Just dumping this before i leave

Took a shitload of work but drop this in Doom3's base folder and you get HD menu with 16/9 16/10 display.
Removed dentonmod specific stuff from the menu.
Removed the bloom setting in advanced as it was commented out because of a bug.
Updated shaders (defaults to arb hint nicest).
High poly models (no more jagged npc or monster models).

There are no race conditions so the only warnings you might get in doom3's console is what was allready there.

Fixed a long standing bug with the HD menu from 6th venom where the only difficulty availiable was marine, props go to a guy on doom3world who fixed it.

So this is an unofficial update to Doom3 standard if you also want nicer textures go to doom3world and get wulfens texture pack 2 and the high res pipe textures update for it.

Im also making a version for resurrection of evil but cant finish it before i get back.

TODO:

Fix overwriting of savegames not possible with the HD menu.
Add HDR light to the menu instead of bloom.
Make parallax occlusion mapping a material shader so we can avoid having parallax on decals or textures with bad normals (causes decals to flicker and textures with bad normals get sliding images "some rock types").

http://sourceforge.net/projects/cbadvan ... 4/download

[revelator]

Seems the ATI slowdown bug is caused by me removing the non VBO fallbacks motorsep posted about the problem at doom3world and mentioned that the cards in question where from the 4xxx to 5xxx series so i started digging and it turns out these cards dont support OpenGL3 fully (especially the 4xxx series) causing massive slowdowns when mh's arbmapbufferrange version is used.

There also seem to be a problem with the indexbuffers and these versions from ATI but how big an impact it will make im not sure but for now if you got an ATI 4xxx or 5xxx card turn of the arbmapbufferrange stuff. theres a cvar which will do just that.

Now i need to find out how to detect an ATI card from these series so it can disable it automatically, checking for the extention is not enough as the ATI cards dont work well with it even though the driver
says its supported.

[mh]

That's quite obviously a driver bug rather than a hardware issue as GL_ARB_map_buffer_range is designed to provide D3D's D3DLOCK_DISCARD/D3DLOCK_NO_OVERWRITE functionality, which has been used successfully (and with good performance) since the Pre-Cambrian Period. Pity that AMD no longer provide driver updates for these cards, as a simple update should be all that's needed to resolve it.

[revelator]

indeed man that sucks.
Guess ill just have to tell users of those cards to turn it off if they want to use my engine.