id Tech Forums

Here it is: https://iddevnet.dhewm3.org/

It's mostly complete (all articles are there), but a few downloads and several images are missing.
The Quake4 part may look like a Wiki but it's static pages, so search won't work.

https://github.com/dhewm/iddevnet#missing-files-not-available-on-archiveorg-either has a list of missing files, if you have any of them please post them here so I can add them

Have fun!

I ran into an assertion in the script interpreter when testing a dhewm3 mod in a Debug build: "st->c->value.argSize == func->parmTotal" from idInterpreter::Execute()

(Please read this if you're familiar with Doom3 scripting; I will explain what seems to go wrong in C++, but you can ignore that part, I'd just like to know if this issue is know and/or considered normal. Thanks!

It turned out that the problem was the following:
We have a player "class" like:

object player : player_base {
// .. lots of stuff not important for the issue
void init();

float music_volume;

void check_music_volume();
// ... and more details
};


and then below there's implementations for those methods - and init() creates a thread with check_music_volume(), but the check_music_volume() implementation is below the init() implementation!


void player::init() {
// .. whatever ..
thread check_music_volume();
// ...
}

// ...

void player::check_music_volume() {
// ... does some stuff in an endless loop ...
while(1) {
if(music_volume > 0) {
// .. do whatever ..
}
}
}


Now when I start a map and that code gets executed (player::init() is called when the player spawns), I get the aforementioned assertion (if assertions are enabled, like in debug builds), because the opcode pretends that the function call has no arguments at all (that need to be passed when calling), while in reality the "self" pointer to the player object is implicitly passed (so check_music_volume() knows what player object it belongs to and can access its fields, like music_volume).

This can be "fixed" by moving
void player::check_music_volume() { ... }
above
void player::init() { ... }

Is it a known problem or considered normal, that the order of function/method implementations matters if one function calls another function?


(Following the C++ analysis:)

Now the problem was that the script compiler, when generating the ops for that thread creation
(idCompiler::ParseObjectCall() => idCompiler::EmitFunctionParms(), op == OP_OBJTHREAD)
it sets the wrong size for the statement, taken from func->value.functionPtr->parmTotal.
This happens at game startup, when all the scripts are parsed and compiled.

The reason that parmTotal for the "check_music_volume" function_t is 0 (while it should be 8, at least on my machine, for the self object reference) is, that even though an idTypeDef with type ev_function and the function_t is created when object player : player_base { is parsed and it encounters the void check_music_volume(); line, parmTotal is not calculated and set until the implementation of the function is parsed much later (when it reaches void player::check_music_volume() { way below).

It all happens in idCompiler::ParseFunctionDef(...) - that function is called both for the function declaration/prototype (void check_music_volume();) is called from idCompiler::ParseObjectDef() when it parses the player object, and later when parsing the implementation (after the bytecode for player::init() is generated), in that  case it's called from ParseNamespace() => ParseDefs() => ParseFunctionDef().

The reason the second call calculates and sets parmTotal (and also numParams) correctly (and the first call doesn't) is the following lines in idCompiler::ParseFunctionDef(...):

// check if this is a prototype or declaration
if ( !CheckToken( "{" ) ) {
// it's just a prototype, so get the ; and move on
ExpectToken( ";" );
return;
}

// calculate stack space used by parms
numParms = type->NumParameters();
func->parmSize.SetNum( numParms );
for( i = 0; i < numParms; i++ ) {
parmType = type->GetParmType( i );
if ( parmType->Inherits( &type_object ) ) {
func->parmSize[ i ] = type_object.Size();
} else {
func->parmSize[ i ] = parmType->Size();
}
func->parmTotal += func->parmSize[ i ];
}

// define the parms
// ... etc ...


So when parsing the method declaration/prototype ParseFunctionDef(...) returns before doing the calculations for stack space needed by function parameters - this is only done when parsing the implementation!
So, if the method is called in the script file before the the implementation, assert( st->c->value.argSize == func->parmTotal ); in idInterpreter::Execute() fails.

I have no idea why the stack space calculation etc isn't just done when parsing the prototype.

I'm working on bringing the Windows-only MFC tools to dhewm3 (see https://github.com/DanielGibson/dhewm3/tree/tools if you're interested) - it's based on the older dhewm3-based SteelStorm2 code, so thanks to motorsep for giving me that code!

Seems to work overall, however there is an issue with the Particle Editor that also exists with the original 1.3.1 binaries (at least on my System: Win10, Intel Haswell CPU with Iris Pro GPU):
When selecting a different  texture (and clicking "Ok" or whatever you click to close the texture selection window), a new small viewport turns up in the lower left corner of the window and is used exclusively (the rest of the window doesn't seem to really get updated anymore), looks like this:

Has anyone encountered this before? Were you able to implement a fix or at least workaround?

See https://www.youtube.com/watch?v=sbDQSOmwA20 and https://twitter.com/Nightworkgames/status/722905662871572480

Fuck, this sounds awesome. I hope it'll have a proper single player campaign.

I've just released the first release candidate of dhewm3 1.4.0, a sourceport of the "old" (non-BFG) Doom3: https://github.com/dhewm/dhewm3/releases/tag/1.4.0_RC1

UPDATE:1.4.0 is out, see https://github.com/dhewm/dhewm3/releases/tag/1.4.0

UPDATE2:1.4.1 Release Candidate is out, see https://github.com/dhewm/dhewm3/releases/tag/1.4.1_RC1 - please test!

I provide Windows binaries there, if you're using Linux or OSX you have to compile yourself, but that shouldn't be very hard either.

Some features of dhewm3 vs the original code:

• 64bit port
• OpenAL for audio output, all OS specific audio backends are gone
• OpenAL EFX for EAX reverb effects (read: EAX on all platforms)
• Better support for widescreen (and arbitrary display resolutions), more resolutions can be configured in the menu
• The mouse isn't too fast in menus at resolutions > 640x480
• The console can be opened with Shift-Escape, regardless of your keyboard layout
• SDL for cross platform low level OS support, OpenGL and input handling
• A portable build system based on CMake
• (Cross-)compilation with mingw-w64
• Lots of other bugfixes I forgot

If you test it I'd be glad about feedback (both problems and "I use operating system $XY and it works!") 

So far it has been tested mainly on Linux, and I did a bit of testing in Windows XP and Win7 - so I'd be especially interested in Win8 and Win10.

OS X would also be interesting.

Thanks a lot!

http://www.mobygames.com/game/windows/zaero-for-quake-ii

I finally started playing it (while fixing its code to be more stable with modern systems for https://github.com/yquake2/zaero) and I think it's really great.
I'm only about halfway through and already played for many hours and so far it has been fun. It also looks great, the levels architecture and lighting looks good and so do the added textures.
The added models (a few weapons and enemies) are a bit patchy.. some look quite good, others (especially this dog-thing) don't.. but it's not so bad that I'd stop playing because of that (and most of the time you encounter standard Quake2 enemies anyway).

Has anyone played it? What do you think?