New repo for old ZDoom versions [2.1.8 CL release]

[drfrag]

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.

[Redneckerz]

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.

You listed the changes yourself and then said that you were going to retain the ZDoom CL name. Which is a strange thing to say if they aren't that different.

I mean i have far less of an issue with this in CL because its an edge case port, but the idea that this will also occur in a port with far greater visibility is a natural point of discussion But that's a topic for another day.

[drfrag]

But which changes? Between 2.1.7 and 2.1.8 CL? Between 2.1.4 and 2.1.4a CL? Or between both CL versions?
If i were to release another one it would also be CL. The concept is the same, but 2.1.4 and 2.1.7 were not that different to begin with anyway.
IMO both classic versions are very similar, this one is cleaner and better.

[Redneckerz]

Edit: removed.

Well, that's great. The link is removed. I suppose i should now relegate to the 2.1.8 CL release or?

[drfrag]

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.

[Redneckerz]

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.

I mean, if i was ought to test them without knowing that link would be gone within a few days, i would have dedicated more time to this.

Oh well, now i had time to do a rampant DoomWiki session on several new articles, so all is well within the universe.

[drfrag]

I've uploaded another build to test the compat_oldrandom compatibility option and the -noscript command line parameter, that is to prevent loading MAPINFO and DECORATE lumps from Boom compatible pwads. There are many wads mainly developed for PRBoom that aborted with an error due to the presence of those.
It will be available only for a few days: <link removed>
Edit: i've done a little testing with 1klinecp2.wad, DYINCAM3.wad, intercep2.wad and swtchrm.wad.

[drfrag]

Turns out i discovered that actor destruction was very slow and i suspect that it still is with the GC. Howeven Odamex is fast in nuts.wad, it still has DObject::EndFrame but not DObject::DestroyScan nor player_s::FixPointers. And i don't know why. I've noticed it calls DThinker::DestroyAllThinkers() in DObject::::StaticShutdown tough.
Also in DObject::RemoveFromArray it adds "if(Inactive) return;"
According to randi on the GC:

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.

It would be cool to speed up this old version, DObject::DestroyScan nulls the pointers but it's not in Odamex yet it somehow works.
Some profiling, versions above 1.19 were very slow in nuts.

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

I was looking at the wall near the start in software, the second one is from modern GZDoom. The mayority of calls to functions in ntdll.dll were from _malloc_base and _free_base and that looked suspicious. I mean i don't think that work to destroy the thinkers is free now. BTW i tried with 2.3.1 and that one doesn't have portals, FPS oscillated between 10 and 1 vs 1 all the time in 2.1.7. Just some thoughts but i'd really like to speed up that old version anyway.

[drfrag]

Now i've discovered why Odamex is fast in nuts.wad, they use something called self-zeroing pointers.It should be portable to the 2.1.x branch but that work was made in a private SVN repo in 2006 by an older dev. I think it's doable with DiffMerge.

// 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.

[Graf Zahl]

ZDoom already uses a concept of self-zeroing pointers ever since it added the garbage collector. TObjPtr is essentially this - before returning a valid pointer it first checks if the object being pointed to is still valid