Explosion Graphics

[skymarshall]

I have a proposal (and code branch ) for improving the way that area explosion sprites are handled.

At the moment, we're limited to using the explosion graphics in X1.PCK for every area explosion - I think it would be quite cool to allow different explosion graphics for different weapons in the game.

There's also a couple of minor bugs that I've spotted in the way that explosion sprites are drawn, notably that:

 - large explosions tend to look diamond shaped on screen rather than circular, since the sprites are randomly drawn within a square on the battlefield
 - explosion graphics are displayed slightly too high on screen from the centre of the explosion

I have made a code branch that externalizes the explosion graphics config into entries like this:

explosions:
  - type: STR_DEFAULT
    spriteSheet: "X1.PCK"
    start: 0
    end: 8
    animSpeed: 100
    density: 100

I've then created a custom ruleset that has new entries like this:

  - type: STR_DEFAULT
    spriteSheet: NEW_EXPLOSIONS
    start: 0
    end: 35
    animSpeed: 50
    density: 100
  - type: STR_PLASMA
    spriteSheet: NEW_EXPLOSIONS
    start: 36
    end: 72
    animSpeed: 25
    density: 300   
  - type: STR_STUN
    spriteSheet: NEW_EXPLOSIONS
    start: 72
    end: 108
    animSpeed: 25
    density: 300 

Then, I've ripped and converted some explosion graphics from other sources so that I can play a game in which rockets, plasma grenades and stun bombs have different explosions as shown:





All look much nicer animated, and the settings are all contained in a new mod ruleset file.

Feedback please, I would like to submit this one.

My branch is here: https://github.com/skymarshall/OpenXcom/tree/new-explosions/src

[pkrcel]

Seems nice, I'll try to compile the branch this evening aand let you know my impressions.

[XOps]

This is pretty awesome. Explosion sprites are one of the limitations I came up against while modding. Would be even more awesome if it would also externalize explosion sound effects for them too.  Right now you can only replace all explosion sounds rather than going on a case by case basis. Seems like a good compliment to more animation control. Regardless being able to define extra explosion animations alone would be really nice. This will probably have to be done at some point for TFTD anyway.

Also curious. Does it fix the explosion radius issue? I noticed that setting the blastRadius in the item config has no effect on the size of the explosion animation area. Instead it seems to draw the animation based on weapon damage. You could have a 200 power weapon and fire to see a massive explosion, but if the blastRadius is set low then only a small crater remains. Not a massive issue, just an oddity I noticed with the current code.

[skymarshall]

Good points - I spotted the blast radius issue too but hadn't attacked it yet.  It would be easy enough to bolt this in to ExplosionBState. 

The sound config needs a bit of thought on a sensible way to configure it first, as the current code uses two sounds, one for power <= 80 and one for the rest.  I didn't want to hack in a solution (e.g. have the default stick to this behavior, have new explosions use a configured sound), similarly did not want to overengineer (e.g. have a vector of powers and sound effects for each explosion).  So, thought I would stay away for now and try to get what I've done into an approvable state.

BTW Kudos for all your new graphics in your XenoOps mod - I will download that and check it out properly soon but just from the screens I can see that there's probably weeks of your time spent on it.  Really like the look of your new UFOpaedia screens

[Warboy1982]

interesting... although i'd take a different approach: extend the explosion pck to contain more sprites, and define the "starting frame" of the explosion on a per-item basis, allowing even greater flexibility and with minimal code impact.

in fact... i'm already half way through doing exactly that for TFTD, as it has above ground explosions starting at frame 8 instead of 0.

[skymarshall]

I did start by doing that, but that approach commits you to using 128x64 images (or at least uniform images, I think).   If SurfaceSet will actually cope perfectly well with different size images, or could easily be made to, then expanding x1.pck is the way to go.  It's nice to use the x/y sprite dimension in SurfaceSet to determine the offset to display the sprite rather than use hardcoded 64/32.  These are extremely useful features if you have spritesheets handy already, as converting e.g. 85x85 sheets to 128x64 is a soul destroying activity.   

Unlike unit images and tiles, where uniformity is king for obvious reasons, it's OK I think to allow variation in size for explosion images.

Having control over anim speed and sprite density is also desirable if using nonstandard sprites, as you end up with very lame looking slow or sparse explosions unless the sprite is very similar to the original.  Once I'd added that, I thought there was enough to justify moving explosion config out to a separate yaml entry, so that multiple items could share the same config without replicating it.

If you do want to keep explosions on the item config, it also would be nice to have a way of changing the default explosion(s) without needing update every item entry or being tied to sprites 0-7.

Anyway, these are just my ideas, not even arguments or strong opinions, so please feel free to ignore or use as you wish

[Ran]

Yes please - I have requested custom explosion sprites several times.
I had already created 2 alternative ones from an existing sprite, not knowing I could only replace the original one but not add new sprites.
https://openxcom.org/forum/index.php?topic=2151.0

[RSSwizard]

In regard to explosion size (blastRadius) ive brought this up too.

The Blast Radius setting should dictate how explosions decrease in strength rather than cut them off at a certain amount.

This way you can put blastRadius: 15 on a hand grenade that does 50 damage and it will spread out to 15 square radius.

The way to do this is as follows. Any time the engine calls for reducing the damage for an explosion based on its distance from source . . . the amount that is reduced is 10 * (Multiplier) per square. Rather than a flat 10 like vanilla.

That multiplier would be ( damage / (blastRadius * 10) ).


Likewise setting the blast radius smaller than usual will still confine the explosion to a smaller area, but it would do it because it is reducing the damage by more than 10 per square from source.

Likewise I think this should also affect the simulated size of the explosion as far as Sprite Spread is concerned (sprite spread treats the damage as if it were times ( (blastRadius * 10) / damage) ). But not necessarily the Density . . . the Density should remain the same.

That way you can get a small explosion that appears to be jam packed with explosion sprites, reflecting how much damage it actually does.