New repo for old ZDoom versions [2.1.8 CL release]
- drfrag
- Vintage GZDoom Developer
- Posts: 3141
- Joined: Fri Apr 23, 2004 3:51 am
- Location: Spain
- Contact:
Re: New repo for old ZDoom versions [2.1.8 CL release]
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
- Spotlight Team
- Posts: 1052
- Joined: Mon Nov 25, 2019 8:54 am
- Graphics Processor: Intel (Modern GZDoom)
Re: New repo for old ZDoom versions [2.1.8 CL release]
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.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.
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
- Vintage GZDoom Developer
- Posts: 3141
- Joined: Fri Apr 23, 2004 3:51 am
- Location: Spain
- Contact:
Re: New repo for old ZDoom versions [2.1.8 CL release]
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.
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
- Spotlight Team
- Posts: 1052
- Joined: Mon Nov 25, 2019 8:54 am
- Graphics Processor: Intel (Modern GZDoom)
Re: New repo for old ZDoom versions
Well, that's great. The link is removed. I suppose i should now relegate to the 2.1.8 CL release or?drfrag wrote: Edit: removed.
- drfrag
- Vintage GZDoom Developer
- Posts: 3141
- Joined: Fri Apr 23, 2004 3:51 am
- Location: Spain
- Contact:
Re: New repo for old ZDoom versions [2.1.8 CL release]
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
- Spotlight Team
- Posts: 1052
- Joined: Mon Nov 25, 2019 8:54 am
- Graphics Processor: Intel (Modern GZDoom)
Re: New repo for old ZDoom versions [2.1.8 CL release]
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.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.
Oh well, now i had time to do a rampant DoomWiki session on several new articles, so all is well within the universe.
- drfrag
- Vintage GZDoom Developer
- Posts: 3141
- Joined: Fri Apr 23, 2004 3:51 am
- Location: Spain
- Contact:
Re: New repo for old ZDoom versions [2.1.8 CL release]
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.
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
- Vintage GZDoom Developer
- Posts: 3141
- Joined: Fri Apr 23, 2004 3:51 am
- Location: Spain
- Contact:
Re: New repo for old ZDoom versions [2.1.8 CL release]
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:
Some profiling, versions above 1.19 were very slow in nuts.
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.
Also in DObject::RemoveFromArray it adds "if(Inactive) return;"
According to randi on the GC:
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.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.
Some profiling, versions above 1.19 were very slow in nuts.
Code: Select all
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
- drfrag
- Vintage GZDoom Developer
- Posts: 3141
- Joined: Fri Apr 23, 2004 3:51 am
- Location: Spain
- Contact:
Re: New repo for old ZDoom versions [2.1.8 CL release]
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
- Lead GZDoom+Raze Developer
- Posts: 49066
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: New repo for old ZDoom versions [2.1.8 CL release]
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