I did not have a lot of time for Doomsday last week, so I worked on some of the low-hanging fruit in the known issues
. A couple of situations where the engine would crash were fixed, e.g. a problem with preparing Hexen's teleport travel graphics. (I'm not sure if this applies to ringzero's texture manager, too; Danij, could you check out commit e1b6a5f74d
?) Other fixes include line specials that were potentially executed by the Doom client, Hexen's falling scream and damage, client's foot clipping and other viewheight glitches. I believe I also managed to make some further improvements with the client's plane movers, fixing the bug of some planes not reaching their correct destination and the situation where players get jammed in doors.
The plan for the coming week remains the same: continue working on the known issues.
I too had little time for Doomsday this week, though I did manage to address a couple more of the known issues
. Resource search paths were being duplicated during namespace construction resulting in paths being added multiple times to the resource namespaces.
Other than the regression fixes, work on refactoring the filesystem continued with changes to the way lumps are published from files to LumpDirectory
s. Lumps can now be published into any number of independent LumpDirectory
s, which will aid us in addressing the lump name collision issues I mentioned in my progress update last week.
This week also saw the beginnings of a new abstract filesystem component named LumpCache
, which when completed will introduce thread safe caching of file/lump resources for all supported file/lump container formats (i.e., WAD and ZIP). Internally LumpCache implements a multiple-reader-single-writer locking mechanism which allows for concurrent access to data lumps from multiple threads.
Over the coming week I intend to continue working on the filesystem refactorings, in particular the completion of the LumpCache
I'm not sure if this applies to ringzero's texture manager, too; Danij, could you check out commit e1b6a5f74d?
Thanks for the heads up but no this doesn't apply (I caught this problem during the texture manager refactoring for ringzero).