Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Doom Marine

Cleaning up and optimizing animation frames in BEX, an ongoing discussion

Recommended Posts

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.

 

Share this post


Link to post

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.

Share this post


Link to post
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?

Share this post


Link to post

Just about every monster have a redundant pain frame, so I got rid of the extra frame and compensated frame time accordingly.

 

image.png.0e1db7f89730315caf0cc7422b654b3b.png

 

image.png.1018df5f972db1f93c898f5595a83f3e.png

 

Share this post


Link to post

image.png.9026e3dfc564e98a60476e6d24f41766.png

@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.

Share this post


Link to post

More of the same optimization strategy

 

image.png

*Ignore highlighted VILER0, accident.

Edited by Doom Marine

Share this post


Link to post

At the very least, I freed up BOS2N0, BOSSN0, and VILEY0. They are like single-digit pixel differences compared to the final corpse.

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post

image.png.3b08d071bff620c3bb7740b5db885080.png

 

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.

Share this post


Link to post

@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?

Share this post


Link to post
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.

Share this post


Link to post
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 by Doom Marine

Share this post


Link to post

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!

Share this post


Link to post
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":

 

ZTSjQM8.png

 

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:

 

VSYIZuI.png

 

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.

Share this post


Link to post
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.

STb3TMe.png

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.

 

Share this post


Link to post
6 hours ago, Gez said:

Note that it doesn't look very good.

STb3TMe.png

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.

Share this post


Link to post

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 by -TDRR-

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×