Remember, just because you request it, that doesn't mean you'll get it.
Moderator: GZDoom Developers
- Posts: 8081
- Joined: Sun Jan 28, 2007 3:55 pm
Several other people on Discord thought this also would be a good idea so I bring it up here.
Models have several significant advantages over sprites... One of them being the ability to bind models to sprites based on their definitions via MODELDEF. This makes me wonder... If we can do that for models, why not sprites?
Code: Select all
// Sprite <SpriteName> <Frame> <Angle> <Graphic Path> [Flags]
// Angle: Exactly the same as sprite naming for consistency
// * Mirror: Flips the sprite.
Sprite ASDF A 1 "Graphics/ZombieA1.png"
Sprite ASDF A 2 "Graphics/ZombieA2A8.png"
Sprite ASDF A 3 "Graphics/ZombieA3A7.png"
Sprite ASDF A 4 "Graphics/ZombieA4A6.png"
Sprite ASDF A 5 "Graphics/ZombieA5.png"
Sprite ASDF A 6 "Graphics/ZombieA4A6.png" Mirror
Sprite ASDF A 7 "Graphics/ZombieA3A7.png" Mirror
Sprite ASDF A 8 "Graphics/ZombieA2A8.png" Mirror
The primary use would be to end sprite conflicts, but I could also see this being expanded to do other things with it as well. For very complex actors/weapons, it'll allow people to more sanely name their sprites without having to keep track of them all.
- Posts: 391
- Joined: Sat Jun 23, 2012 7:44 am
- Graphics Processor: nVidia with Vulkan support
- Location: Czech Rep.
Similar requests have been no'd before, even this year
, due to how the sprite loader works. The different suggestions for user-made definitions and syntaxes don't seem to be an issue. I guess a whole new sprite loader could be written and then used alongside the standard one (kept for compatibility) by specifying these MODELDEF-like sprite blocks, but I assume the answer is good luck making and maintaining that.
- Lead GZDoom+Raze Developer
- Posts: 48325
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
What people really fail to understand is how sprite management works in Doom. A very large part of this is automated, depends on the 4 letter name plus frame number and rotation angle.
All this ensures that lookups are fast during rendering. Add this kind of complexity and every single time a sprite gets looked up, the renderer has to go through all the lists to handle these newfangled user-defined sprite aliases.