ZDoom

drfrag wrote:But why do you think they are that different? For me it's pretty much the same but for another version. I did not merge a GL renderer initially for 1.4 and then i reverted some things after the last release i believe.

drfrag wrote:Edit: removed.

drfrag wrote:Of course, that link was up only for a few days. It works well, i miss some automap enhancements but the missing cheats actually make things more interesting: no more kill spidermastermind, kill cyberdemon... NOVA 3 is turning into a slaughterfest on later levels.

randi wrote:this code only affects when thinkers are destroyed, not created. Previously, whenever a thinker was destroyed, it had to do a lot of work directly proportional to the total number of thinkers every tic. Now, that same work is still done, but it's aggregated and spread out across several tics.
None of this code was present in Doom originally. It was all added by me to make the engine more robust. (And also because saving a game would almost always crash without it due to significant changes between ZDoom's savegame format and Doom's savegame format.)
The old way
When an object's Destroy method is called, it gets added to a list of objects to delete. At the end of each tic, if there is anything in that list, the engine steps through every object in the game, looking for pointers to objects in the list. Any such pointers it finds are nulled, and then the objects are all deleted.
The new way
When an object's Destroy method is called, it sets a flag indicating that this object wants to die. Most pointers to objects are wrapped inside a template class that checks for this flag and nulls the pointer if it's set. In addition, while the collector is running through the mark phase, it also nulls any pointers to objects with this flag set. Eventually, there will be no more pointers to the object left, and it will be collected as normal, unreachable garbage.

Code: Select all • Expand view

Function Name   Exclusive Samples   Exclusive Samples %   Inclusive Samples   Inclusive Samples %   Source Line Begin   Source Character Begin   Source Line End   Source Character End
   DObject::EndFrame   10.426   35,65 %   10.426   35,65 %   429   0   429   0
   PIT_CheckThing   994   3,40 %   994   3,40 %   826   0   826   0
   P_BlockThingsIterator   930   3,18 %   930   3,18 %   739   0   739   0
   
Function Name   Exclusive Samples   Exclusive Samples %   Inclusive Samples   Inclusive Samples %   Source Line Begin   Source Character Begin   Source Line End   Source Character End
   [ntdll.dll]   8.318   13,67 %   8.318   13,67 %   0   0   0   0
   FMultiBlockThingsIterator::Next   3.626   5,96 %   3.626   5,96 %   1.099   0   1.099   0
   FBlockThingsIterator::Next   2.582   4,24 %   2.582   4,24 %   987   0   987   0
   FThinkerCollection::RunThinkers   2.010   3,30 %   35.002   57,50 %   114   0   114   0
   FThinkerIterator::Next   1.728   2,84 %   1.728   2,84 %   965   0   965   0
   [openal32.dll]   1.619   2,66 %   1.904   3,13 %   0   0   0   0

// denis - szp<T>, the self zeroing pointer
//
// Once upon a time, actors held raw pointers to other actors.
//
// To destroy an object, one cycled though all the others searching for its
// pointer and resetting every copy to NULL. Then one did the cycling for
// the players, then the sector sound origins, and so on; with hack upon
// hack. Ironically, zero dereferencing is what often crashed the
// program altogether.
//
// The idea behind szp is that all copies of one szp pointer can be made
// to point to the same object in O(1) time. This means that having a
// single szp of an actor, you can set them all to NULL without iteration.
// And, as a bonus, on every pointer access, a NULL check can throw a
// specific exception. Naturally, you should always be careful with pointers.