Tels

It's already half build.

Damn, you mean I just waited 18mins for it to build for nothing?

Just updated and started the compiling again, will look after it's through.

I like how StgRumpel uses the German language interface The video could really use a few more views and likes, so if someone has a youtube account, it would be cool if you could click through them, even if you don't understand German

Looking again at the code, the second part in DifficultyManager.InhibitEntitySpawn should probaby be moved to idGameLocal::InhibitEntitySpawn - that would be a bitmore logical. No functional change, but keep the code in DifficultyManager only for difficulty, and put the other query (random_remove, inline) in idGameLocal. Looks cleaner to me. (And mea culpa, should have done this the first time round

An easy way would be to inhibit the spawn of the entity when "inline" "1" is set. A good place to add this would be: /* ================ idGameLocal::InhibitEntitySpawn ================ */ bool idGameLocal::InhibitEntitySpawn( idDict &spawnArgs ) { // Consult the difficulty manager, whether this entity should be prevented from being spawned. return m_DifficultyManager.InhibitEntitySpawn(spawnArgs); } or in m_DifficultyManager.InhibitEntitySpawn. This routine already checks for difficulty related spawn and for "random_remove".

Rechecked out the source and it now compiles libgame.so \o/ but then stops with: Edit: At the top of sys/gllog/gl_def.m4 I see: define(`gl_start', `0') define(`gl_end', `335') define(`wgl_start', `336') define(`wgl_end', `357') define(`glX_start', `358') define(`glX_end', `363') These are used in sys/linux/glimp_dlopen.cpp.m4 here: define(`instance_funcptr', ``$1' ( * glX`$2' )(`$3');') forloop(`i', glX_start, glX_end, `instance_funcptr(indir(`f'i`_ret'), indir(`f'i`_name'), indir(`f'i`_params')) ') which would then result in these strange f363_end definitions. Maybe here is the problem

Yes, that would work. But it still uses two entities Yes, that sounds worth investigating. Even if we would only make it work for func_statics with a special spawanrg "inline" "1", it would help huge maps. Does the inlining happen at dmap stage?

Porting isn't easy and free. We can't just "port", we would need to bring over a lot of stuff and basically merge the two engines. Greebo spent a lot of time on this already when we switched to the OS version of D3. I guess BFG is even more work as it is vastly different from D3 vanila.

Speaking of feature proposals: Should I try adding the posibilty of a having particle at an idLight? I guess a few spawnargs with offset, rotation and .ptr name would be enough. In fact, I think we could even do something like a "multimodel" instead. Add support for "model2" and "model2_ofs" and "model2_rotate" and model3 and so on. Each light with a model would then simply either present the model to the renderer, or add the particle to its particle emitting-list (I know that multiple particles per entity work, I've used it for SEED). That way you'd had one entity with multiple models. Lights also have "broken" models (I'm not sure if TDM ues this, but in D3 you could shoot lights out) and an "off" model (the candle flame f.i. has a repeating "model" particle with the flame, and a "smoking for a while" run-once particle. (see, the "model" if the flame is a particle actually) If we add the same support for the other model spawnargs, then you could have a ligh with a streetlamp and a haze when on, and streetlamp and no haze when off.

Maybe we should get rid of the crazy netsync scheme (at least for spawnids) and replace it by two 32 bit ints. It's not that it would be used, anyway The spawn limit was formerly 2 million when we had 2048 entities as limit (that seems outright tiny now). I guess very long running network play sessions would still be safe with a 2 million limit, but as we are now down to 0.5mill and would be at 250K, or even 120K, this seems dangerous. The interesting thing is to me, that the spawnId could also just wrap around. But I guess back then it was simpler to code and worked (unless you played more than a few hours on a map with constant respawning items).

Agreed.

On the internet?

It is just work in progress and nothing comes out of yet for end-userss.[0] It's a "cleanup" effort, basically a house cleaning. It will allow (maybe) later enhancing the engine and modernize the grafics. Maybe. 0: Ok, that was a lie. You can expect about twice the performance, defered lighting, tissue-soft shadows, your manhood will be enlarged, beautiful women will flock to you and of course it will bring world peace.

Ah, yes, I deleted the file scons.signatures.dblite - hopefully it works now. Will report back.

I guess there is some water inside the hollow chamber and by turning the instrument, you affect the sound as it is made.

Downgrading isn't a good idea, unless you statically link the downgraded library into the executable (and even then it's questionable). The Linux/Unix way is to use the libary on the system, not ship outdated ones with the executable. However, I can see how upgraded libraries cause problems (see boost). So, not sure what you can do. For me it stops here: g++ -Wall -o framework/precompiled_engine.h.gch -x c++-header -c -pipe -Wall -Wno-unknown-pragmas -fmessage-length=0 -fpermissive -fvisibility=hidden -m32 -O3 -march=pentium3 -ffast-math -fno-unsafe-math-optimizations -fomit-frame-pointer -DXTHREADS -fno-strict-aliasing -Winvalid-pch -D__DOOM_DLL__ -Iframework -Ibuild/release/core/sys/scons -Isys/scons -Iinclude -Iinclude/zlib -Iinclude/minizip -Iinclude/libjpeg -Iinclude/devil -I. framework/precompiled_engine.h scons: Cannot explain why `build/release/core/glimp/sys/linux/glimp_dlopen.cpp' is being rebuilt: No previous build information found cd sys/linux && m4 -E < glimp_dlopen.cpp.m4 > /home/te/src/tdm_experimental/The-Darkmod-Experimental/src/build/release/core/glimp/sys/linux/glimp_dlopen.cpp m4:stdin:36: undefined macro `f363_ret' m4:stdin:36: undefined macro `f363_name' m4:stdin:36: undefined macro `f363_params' m4:stdin:48: undefined macro `f363_ret' m4:stdin:48: undefined macro `f363_name' m4:stdin:48: undefined macro `f363_params' m4:stdin:66: undefined macro `f363_name' m4:stdin:105: undefined macro `f363_ret' m4:stdin:105: undefined macro `f363_name' m4:stdin:105: undefined macro `f363_params' m4:stdin:132: undefined macro `f363_name' scons: *** [build/release/core/glimp/sys/linux/glimp_dlopen.cpp] Error 1 scons: building terminated because of errors.

Thanx! Would we get rid of m4 if we replace scons by automake/autobuild/autowhatever? I'm not a big fan of changing things for the change's sake but I think scons itselfs has a few problems now and then. My biggest wish would get back the "if you change one file, only this .o is compiled". Ever since the switch to the pre-compiled header on Linux every is re-compiled every time.

Not sure if these two things are related. If the entities are inlined at "map load", then they are never spawned in the first place, so wrap-around does not matter. If they are inlined after spawn, the map would still crash unless the inlined entities + everything else > LIMIT. So, yeah, I think inlining could help. OTOH, care must be taken to not inline func_statics that are refered to by something later. E.g. anything with a LOD stage or watched over by SEED or having a link (e.g. another entity uses it as "target spawnarg") or it is refered to by a script. I'm not sure it is that easy to discern. Maybe if the func_statics have an "inline" spawnarg, but then it would only be for new maps.

Oh boy... increment, but never decrement (or at least my grep-foo didn't find it): entities[ spawn_entnum ] = ent; spawnIds[ spawn_entnum ] = spawnCount++; So, constantly spawning entities, then removing them, then respawning (what SEED can do) would after a while crash the game? Plus, if we increase GENTITYNUM_BITS from 13 to 14 or 15, the code above does (32 - GENTITYNUM_BITS), which means it would have a lower limit? (e.g. now it is 1 << (32 -13) == 1<<19, afterwards it is 1 << (32 -14) == 1<<18?

Yes, I should have mentioned that there are different problems when raising the entity limit: maps with lots of entities (> 8000) will use a lot of memory. But only a part of that might be due to the entities itself, textures&models probably eat a lot more maps with lots of entities (> 8000) will run through XK slows instead of only 8K. That might be no problem at all (16K index accessed might be nothing for a modern CPU). maps with few entities (<1000) might end up with a lot of temp. allocations (I wasn't aware of that problem, and it might be fixable - allocated only HIGHEST_CURRENT_ENTITY_ID slots instead of the full block) maps with little entities, but constant entity spawning and respaning might have num_entities higher than it actually is - that is why the code seems to always run from 0 .. num_entities,but then checks that each entry is actually existing and valid. Interstingly enough, RegisterEntity does num_entities++ but UnregisterEntity does not --? Likewise, I'm not sure RegisterEntity handles the increment always properly.

I'm not sure it would really help. Sure, it removes the entities, but it makes them world_spawn, which is a different beast and I'm not sure that would work for huge maps. It depends on how they are converted to world_spawn. Just added to the "render list" or do they divide world_spawn faces, too? I think it does, but I'm not sure. This routine is the likely place and it looks like it doesn't do wrap around idGameLocal::UnregisterEntity does indeed set firstFreeIndex back. void idGameLocal::RegisterEntity( idEntity *ent ) { int spawn_entnum; if ( spawnCount >= ( 1 << ( 32 - GENTITYNUM_BITS ) ) ) { Error( "idGameLocal::RegisterEntity: spawn count overflow" ); } if ( !spawnArgs.GetInt( "spawn_entnum", "0", spawn_entnum ) ) { while( entities[firstFreeIndex] && firstFreeIndex < ENTITYNUM_MAX_NORMAL ) { firstFreeIndex++; } if ( firstFreeIndex >= ENTITYNUM_MAX_NORMAL ) { Error( "no free entities" ); } spawn_entnum = firstFreeIndex++; } entities[ spawn_entnum ] = ent; spawnIds[ spawn_entnum ] = spawnCount++; ent->entityNumber = spawn_entnum; ent->spawnNode.AddToEnd( spawnedEntities ); // this will also have the effect of spawnArgs.Clear() at the same time: ent->spawnArgs.TransferKeyValues( spawnArgs ); if ( spawn_entnum >= num_entities ) { num_entities++; } } Interesting is the support for "spawn_entnum", I'd say we should remove that. Setting the entity number via spawnargs - ugh. That exposes internal stuff to the outside world without real need.

Here is a small patch that adds one comment and fixes another one: Index: game/Entity.h =================================================================== --- game/Entity.h (revision 6166) +++ game/Entity.h (working copy) @@ -144,7 +144,7 @@ // // Signals -// make sure to change script/doom_defs.script if you add any, or change their order +// make sure to change script/tdm_defs.script if you add any, or change their order // typedef enum { SIG_TOUCH, // object was touched Index: game/Game_local.h =================================================================== --- game/Game_local.h (revision 6166) +++ game/Game_local.h (working copy) @@ -91,7 +91,7 @@ // Tels: If you change this value, make sure that LUDICROUS_INDEX // in renderer/RenderWorld_local.h is higher than MAX_GENTITIES: #define GENTITYNUM_BITS 13 -#define MAX_GENTITIES (1<<GENTITYNUM_BITS) +#define MAX_GENTITIES (1<<GENTITYNUM_BITS) // max entity count #define ENTITYNUM_NONE (MAX_GENTITIES-1) #define ENTITYNUM_WORLD (MAX_GENTITIES-2) #define ENTITYNUM_MAX_NORMAL (MAX_GENTITIES-2) Index: renderer/RenderWorld_local.h =================================================================== --- renderer/RenderWorld_local.h (revision 6166) +++ renderer/RenderWorld_local.h (working copy) @@ -21,7 +21,7 @@ #define __RENDERWORLDLOCAL_H__ // assume any lightDef or entityDef index above this is an internal error -#define LUDICROUS_INDEX 65537 // (2 ** 16) + 1; +#define LUDICROUS_INDEX 65537 // (2 ** 16) + 1; must be higher than MAX_GENTITIES typedef struct portal_s {

Yeah, that would be the way forward. However, larger maps, larger entity counts and so will also put a strain on the entire editing pipeline (you need a beefy PC just to open the map in DR) and the player. 64bit doesn't help if you have less then 4Gb memory in the PC, it might actually hut, because it uses a bit more memory. So, we also need to somehow try to reduce the memory footprint as well as the loading size. I remember a few years back stgatilov removed the "editor_" spawnargs from entities in memory, this massively reduced the savegame size (because our documentation effort added thousands of these to entities Maybe we can look at slimming down entities in general in the engine. If one entity uses a few Kbyte less memory, and the parts of the engine that try to find entities don't loop through all of them multiple times per frame, then doubling or trippling the limit won't be a problem.

Speaking of cleanup, do we still need to support the MD3 model format? renderer/Model_md3.h and renderer/Model_md3.cpp. It isn't much code, and only referenced in one place, but AFAICS we don't have any .md3 models. Does this format have any special abilities that make it worthwhile to keep?