In fixing the above I have re-implemented the way in which sprite patch records are generated. This process is no longer dependent upon Sprite (name) definitions, instead we now construct the spritedef_t databases directly from the lumps. However, as the games still depend upon an unobvious correlation between the prite name indices and the relevant spritedef_t indices, there is currently a kludge in R_InitSprites which re-indexes them as expected, using the existing Sprite (name) definitions indices.
A quick trawl over our codebase confirms to me that there are very few places remaining where the sprite name indice:spritedef_t indice assumption remains. The main instance being the sprite replacement in dpDehRead. As Doomsday itself no longer depends upon the Sprite (name) definitions; potentially they can be removed from the public shared data too (once the new DED reader/management is in place, solving the dpDehRead issue should be trivial).
Added by danij over 15 years ago
Added by
Fixed: Material definitions referencing sprite patches not working. Symptom - Bug #2673525 "wad midspace texture name does not work" (see http://sourceforge.net/tracker2/?func=detail&aid=2673525&group_id=74815&atid=542099).
In fixing the above I have re-implemented the way in which sprite patch records are generated. This process is no longer dependent upon Sprite (name) definitions, instead we now construct the spritedef_t databases directly from the lumps. However, as the games still depend upon an unobvious correlation between the prite name indices and the relevant spritedef_t indices, there is currently a kludge in R_InitSprites which re-indexes them as expected, using the existing Sprite (name) definitions indices.
A quick trawl over our codebase confirms to me that there are very few places remaining where the sprite name indice:spritedef_t indice assumption remains. The main instance being the sprite replacement in dpDehRead. As Doomsday itself no longer depends upon the Sprite (name) definitions; potentially they can be removed from the public shared data too (once the new DED reader/management is in place, solving the dpDehRead issue should be trivial).