Doom Marine Posted February 16, 2019 (edited) So I'm cleaning up my Dehacked files in search of more animation frames. @fraggle https://github.com/fragglet/deh9000/blob/master/deh9000/reclaim.py pointed out some more stuff I overlooked including bullet puffs == revenant frames, item respawn fog that can be converted into teleport fog. Fraggle's script is a slight superset of my findings, but I also found additional redundancies that I will update this thread as part of an ongoing discussion. 2 Share this post Link to post
esselfortium Posted February 16, 2019 I'd recommend checking out the bex patch from Valiant. It uses the additional frames and codepointers from MBF, which are supported nowadays in PrBoom-Plus, ZDoom, and Eternity and allow you a bit more space to play with. 0 Share this post Link to post
Doom Marine Posted February 16, 2019 7 minutes ago, esselfortium said: I'd recommend checking out the bex patch from Valiant. It uses the additional frames and codepointers from MBF, which are supported nowadays in PrBoom-Plus, ZDoom, and Eternity and allow you a bit more space to play with. Do you have a link to where I can check out the additional frames and codepointers from MBF? 0 Share this post Link to post
Doom Marine Posted February 16, 2019 Just about every monster have a redundant pain frame, so I got rid of the extra frame and compensated frame time accordingly. 0 Share this post Link to post
Doom Marine Posted February 16, 2019 @fraggle Not sure if you did this already, based on what I've seen with your script... but I find these highlighted frames insignificant and can be put to better use elsewhere. 1 Share this post Link to post
Doom Marine Posted February 16, 2019 (edited) More of the same optimization strategy *Ignore highlighted VILER0, accident. Edited February 16, 2019 by Doom Marine 1 Share this post Link to post
Doom Marine Posted February 16, 2019 At the very least, I freed up BOS2N0, BOSSN0, and VILEY0. They are like single-digit pixel differences compared to the final corpse. 0 Share this post Link to post
fraggle Posted February 16, 2019 1 hour ago, Doom Marine said: Just about every monster have a redundant pain frame, so I got rid of the extra frame and compensated frame time accordingly Added, thanks. I had some reservations about this because it removes the delay before playing the pain sound, which some players might notice. However, when I tried it out I personally couldn't notice any change. Nonetheless I still wonder if others might notice it, so I opted for a compromise - monsters with the highest pain chance (zombies, imps, etc.) make pain sounds most often, so I moved them down in priority. This means that DEH9000 will try other strategies before it resorts to changing them. Lower pain chance monsters (bosses etc.) will be changed earlier with the assumption it probably won't be noticed. Agree on the other single-pixel frames - I'll look into removing these too. 0 Share this post Link to post
Doom Marine Posted February 16, 2019 (edited) 5 minutes ago, fraggle said: Added, thanks. I had some reservations about this because it removes the delay before playing the pain sound, which some players might notice. However, when I tried it out I personally couldn't notice any change. Nonetheless I still wonder if others might notice it, so I opted for a compromise - monsters with the highest pain chance (zombies, imps, etc.) make pain sounds most often, so I moved them down in priority. This means that DEH9000 will try other strategies before it resorts to changing them. Lower pain chance monsters (bosses etc.) will be changed earlier with the assumption it probably won't be noticed. Agree on the other single-pixel frames - I'll look into removing these too. Yeah, some animation frames are strictly degenerate (eg mancubus blast) and no reason not to... optimizations that alter appearances / sound are more down to personal choices... like the BFG shot, teleport fog, or now the pain frame which *slightly* alters the sound, but not gunplay 0 Share this post Link to post
Doom Marine Posted February 17, 2019 (edited) Let's talk about the Revenant chase frames. As sprites: SKELA == SKELD SKELB == SKELE SKELC == SKELF This may be a big one, but I haven't read the C source code for the revenant's chase behavior to determine if deleting 329 to 334 changes the frequency of their attack. @fraggle Question: is a revenant's attack dependent on (A) Chase loop finishing - or - (B) Does it break the chase loop to attack? If A, then deleting the six chase frames would increase the attack probability, which is undesirable. Else if B, the attacking frequency is independent of the number of chase frames and then we can delete the six frames. 0 Share this post Link to post
Doom Marine Posted February 17, 2019 @fraggle Quote def all_green_torches(file, mobjtype): """Makes all torches green torches. By using the green torch frames we can use color translation bits to shift into different palette ranges; this frees up frames while keeping different-colored torches looking distinctive, which is important on levels like TNT.WAD MAP30. """ new_sprite = { MT_MISC41: (1, S_GREENTORCH), # Blue torch -> Indigo MT_MISC42: (0, S_GREENTORCH), # Green torch MT_MISC43: (3, S_GREENTORCH), # Red torch -> Red MT_MISC44: (1, S_GTORCHSHRT), # Short blue torch -> Indigo MT_MISC45: (0, S_GTORCHSHRT), # Short green torch MT_MISC46: (3, S_GTORCHSHRT), # Short red torch -> Red } if mobjtype in new_sprite: color, state_id = new_sprite[mobjtype] mobj = file.mobjinfo[mobjtype] mobj.spawnstate = state_id mobj.flags = ( (mobj.flags & ~MF_TRANSLATION) | (color << MF_TRANSSHIFT)) ... I'm having trouble understanding this part. So you're turning all torches green, and then using some kind of color transition to turn it back into different colors? How does this work with respect to Boom Compatibility? 0 Share this post Link to post
fraggle Posted February 18, 2019 On 2/16/2019 at 7:51 PM, Doom Marine said: Let's talk about the Revenant chase frames. As sprites: SKELA == SKELD SKELB == SKELE SKELC == SKELF This may be a big one, but I haven't read the C source code for the revenant's chase behavior to determine if deleting 329 to 334 changes the frequency of their attack. I considered this myself. It won't change game behaviour but it does lead to a visual change. D/E/F are the mirror-flipped versions of A/B/C. So you can cut out them out but it will look like the Revenant is stumbling along on one leg. I think I tried it and didn't like the results, but I don't remember now. 20 hours ago, Doom Marine said: ... I'm having trouble understanding this part. So you're turning all torches green, and then using some kind of color transition to turn it back into different colors? How does this work with respect to Boom Compatibility? It's the colour translation mechanism used to change the marine from green to indigo/brown/red in multiplayer mode. The simpler approach here would be to just change them all to the red torch (and in all honesty it looks nicer). However there are levels like TNT MAP30 where the colours have an important meaning and it's necessary to be able to distinguish them. That said, I'm probably overthinking it. 0 Share this post Link to post
Doom Marine Posted February 18, 2019 (edited) 5 hours ago, fraggle said: I considered this myself. It won't change game behaviour but it does lead to a visual change. D/E/F are the mirror-flipped versions of A/B/C. So you can cut out them out but it will look like the Revenant is stumbling along on one leg. I think I tried it and didn't like the results, but I don't remember now. 2 Yeah, now that you pointed it out, it does look weird. I think the older version of WhackEd does not display mirrored sprites properly, so it appeared non-mirrored in my WhackEd. In any case: SKELA != SKELD SKELB != SKELE SKELC != SKELF So this "optimization" is no longer worth pursuing. 5 hours ago, fraggle said: It's the colour translation mechanism used to change the marine from green to indigo/brown/red in multiplayer mode. The simpler approach here would be to just change them all to the red torch (and in all honesty it looks nicer). However there are levels like TNT MAP30 where the colours have an important meaning and it's necessary to be able to distinguish them. That said, I'm probably overthinking it. 4 It's necessary for my project to have different colored torches. Is there a thread or walkthrough I can look at? Edited February 18, 2019 by Doom Marine 0 Share this post Link to post
NiGHTMARE Posted February 18, 2019 An idea I had recently was to recreate the bases of the torches as level architecture. That way you only need three sets of sprites (or even one if you're happy with the translations) rather than six. Come to think of it, if you convert the flame into a midtexure and use it on + shaped linedefs you could get away with not having any torch sprites at all! 1 Share this post Link to post
fraggle Posted February 18, 2019 On 2/18/2019 at 2:36 AM, Doom Marine said: It's necessary for my project to have different colored torches. Is there a thread or walkthrough I can look at? I don't know if there's a tutorial but it's pretty simple. You said you're using WhackEd - I haven't used it but I found this screenshot and there should be a couple of flags at the bottom of this list, apparently they're named "Color 1" and "Color 2": The way it works is by remapping colours from the Doom palette. If you find an object that has green elements (like the player/marine), the green range colours (0) get remapped to other colours from the other ranges: So if you turn on one or both of colour flags the green parts of the sprites will change into one of the other colours. It's intended for the player sprites in multiplayer but you can also use it on some other sprites - the nukage inside barrels, the hair colour on zombiemen or the green torches are a few. It doesn't work on all sprites, though if you're making your own sprites you can design them to take advantage of the feature. Batman Doom uses it to produce multi-coloured variants of the same monsters for example. 1 Share this post Link to post
Gez Posted February 19, 2019 21 hours ago, fraggle said: It's the colour translation mechanism used to change the marine from green to indigo/brown/red in multiplayer mode. The simpler approach here would be to just change them all to the red torch (and in all honesty it looks nicer). However there are levels like TNT MAP30 where the colours have an important meaning and it's necessary to be able to distinguish them. That said, I'm probably overthinking it. Note that it doesn't look very good. It's the three torches in the middle. First you have the green, blue, and red normal torches from the IWAD; then the translated gray ("indigo" officially, but it's gray), brown, and red from the green torch. Then some other recolors you can ignore. 0 Share this post Link to post
Doom Marine Posted February 19, 2019 6 hours ago, Gez said: Note that it doesn't look very good. It's the three torches in the middle. First you have the green, blue, and red normal torches from the IWAD; then the translated gray ("indigo" officially, but it's gray), brown, and red from the green torch. Then some other recolors you can ignore. It's not as good as I hoped it would be, going to have to skip that optimization. The good news though, is that I have an excess of about a dozen frames now after everyone's input. 0 Share this post Link to post
-TDRR- Posted February 19, 2019 (edited) Removing the second A_Look state from each monster is a great way to get states with codepointers, maybe enough to add another simple monster. And if you want marine monsters in your game, you can have them share the chase, pain, look, death and XDeath frames, use a different attack frame for each to have a completely different attack and use the color flags to re-color them. Pretty neat, right? EDIT: Forgot to mention, no, doing this does not introduce desyncs so that is a pretty useful trick. EDIT2: @fraggle Why don't you make it so when a custom state has a codepointer it is automatically asigned one with a codepointer? I oftentimes have to take way more states than needed because every single time it says something like "state bla bla bla can't be used with a codepointer in vanilla" Edited February 19, 2019 by -TDRR- 0 Share this post Link to post
fraggle Posted February 19, 2019 If you use DEH9000's DECORATE-style parser, it already does that. For example if you check smooth.py there's no special logic in the file to deal with the assignment of code pointer states to vanilla states with code pointers - it just happens automatically. 0 Share this post Link to post
Doom Marine Posted February 19, 2019 (edited) On 2/16/2019 at 3:21 PM, fraggle said: Added, thanks. I had some reservations about this because it removes the delay before playing the pain sound, which some players might notice. However, when I tried it out I personally couldn't notice any change. Nonetheless I still wonder if others might notice it, so I opted for a compromise - monsters with the highest pain chance (zombies, imps, etc.) make pain sounds most often, so I moved them down in priority. This means that DEH9000 will try other strategies before it resorts to changing them. Lower pain chance monsters (bosses etc.) will be changed earlier with the assumption it probably won't be noticed. Agree on the other single-pixel frames - I'll look into removing these too. Another finding: The cyberdemon so far is the only monster with a non-redundant, single pain frame. This IMO sets a precedent that the rest of the monster pain states have redundancy worth removing. 0 Share this post Link to post