cache pointer to teleport mobj in sector#2684
Conversation
…a sector with a second teleporter spawn point
|
The existence of UDMF itself shouldn't cause any problems here. The real possible problem could come when handling parameterized/hexen/zdoom line specials, in the future for Woof! or in the present for DSDA, as they could work a bit differently. As it happens, we were discussing this on the DCPC discord, and AFAICT this isn't an issue with those line specials, as it seems that non-zero Thing ID (TID) hashmaps are used to target teleport destinations instead of lowest index of the first tagged sector. So there's no major concern for compat in that case. In the future, once the Bulk Demo Tester tool is more matured, we'll probaly be able to just use it for these kinds of things, testing changes against the existing DSDArchive. |
Yes, we need to add saving of |
Do we have a means to store variable arrays in keyframes? 😬 |
Wait, the whole array is just a single memory block allocated with |
No, there will be a memory leak because we use Is this optimization worth it, though? It seems like a specific case to me. |
WDYM, the optimization in general or this implementation with the dynamic arrays? |
a9b769d to
f36426c
Compare
|
I have updated the |
Yay for savegames in compressed JSON format, btw. 😉 |
6da37bf to
c42e80b
Compare
It was a highly inefficient and redundant linear search through all thinkers. I have replaced it with a per-sector array which caches each sector's first teleport spawn mobj. Please have a look and tell me what you think. |
This is an alternative approach to the one presented in kraflab/dsda-doom#889. It makes use of the facts that (1) only the first
MT_TELEPORTMANtype mobj in a sector is used for teleport respawning and (2) that mobjs are added to sectors in order. This means, the first time aMT_TELEPORTMANtype mobj is placed into a sector, this one will be used, all otherMT_TELEPORTMANtype mobjs will be ignored.This even takes care of the absurd situation that a
MT_TELEPORTMANtype mobj is removed from a sector and of the even more absurd situation that another such mobj remains in the sector after that and thus becomes the active one. (You know, DEHACKED and stuff. Imagine a teleporter spitting Pain Elemental or whatever).This approach survives our own demo test suite and the
d411-780.lmpdemo that revealed a typo in the implementation suggested for DSDA-Doom.Regarding the performance impact. Run
woof -file ~/Downloads/oversat.zipand load the attached savegame. Shoot the switch and turn around.In my case, FPS went down from ~700 before hitting the switch down to ~8 afterwards on the master branch, and from ~700 down to ~200 on this branch.
Question remains, have I covered all cases which require to handle the new
sector_tfield? New Game, Load Game works. How about UDMF? Do I have to do anything for keyframes?woofsav2.zip