[4.4.0.1] Animating in BD engine

[TheOnyxGuy]

Welp, as 4.4.0.1 is released, and support for some custom animations is added, I tried implementing my improved rockford sprites as soon as possible. But I've encountered the problem... Animations in BDX seem to ignore linear animations and instead globally refresh all of them at once every 16 in-game frames. I assume it's because of the engine syncing everything together much like EM engine.
To not write a whole essay about the animations, I just compiled a quick animation test that shows out animations misbehaviors in action.

bdx_animtest.zip

(3.17 KiB) Downloaded 204 times

[Holger]

Yes, this is correct. The BD engine currently works as you described it, so animations currently have to fit into a 16 frames cycle. This also means that animations defined as being linear (to stop with the last frame) are restarted every 16 frames.

I have to change this so that more R'n'D-like animation definitions are possible and really work as intended. Currently it is still very static and not very flexible.

The same is (partially) true with level specific colors, which is now supported for all game engines. It even supports not only single colors (like in the original BD engine), but also color gradients with up to 255 colors, which allows for really cool looking graphics that have different colors for each level, and not only supports up to 8 single colors like with the default C64 style graphics for the BD engine, but up to 8 color gradients, which allows for very Amiga-style graphics. I will hopefully be able to provide a little example to show how this works, and to play around with.

[amirnatsheh7]

cool

[TheOnyxGuy]

The same is (partially) true with level specific colors, which is now supported for all game engines.

Does that mean that it will move out of the "Engine" tab? Since, well... it will not be the engine specific thing.
Also, speaking of, only the BD engine seems to have the "Engine" tab. Is there a possibility that there may be settings for other engines in the future? Although I honestly don't know which settings may even go aside from properties of elements themselves...

It even supports not only single colors (like in the original BD engine), but also color gradients with up to 255 colors, which allows for really cool looking graphics that have different colors for each level, and not only supports up to 8 single colors like with the default C64 style graphics for the BD engine, but up to 8 color gradients, which allows for very Amiga-style graphics. I will hopefully be able to provide a little example to show how this works, and to play around with.

I may sound a bit annoying, but will MM/DF laser beams get the same treatment? Plus maybe an ability to customize their overloading colors separately?

[Holger]

Does that mean that it will move out of the "Engine" tab? Since, well... it will not be the engine specific thing.

Hmmm... you are right. It was indeed BD engine specific first, but now it isn't anymore. So it should in fact not be under an "engine" tab.

Also, speaking of, only the BD engine seems to have the "Engine" tab. Is there a possibility that there may be settings for other engines in the future? Although I honestly don't know which settings may even go aside from properties of elements themselves...

For now (and for the foreseeable future) I do not see any engine specific settings for game engines other than the BD engine.

So, for any engine other than the BD engine, there could simply be a "color" tab at the 4th tab position (if the currently active graphics set supports level specific colors).

However, for levels using the BD engine that also have graphics with level specific color support, we would still need two additional tabs -- one for the engine settings, one for the color settings.

If anybody has any idea how to reasonably arrange these settings in level editor tabs that ideally are at the same position for same functionality, please let me know.

I may sound a bit annoying, but will MM/DF laser beams get the same treatment? Plus maybe an ability to customize their overloading colors separately?

Now that we have a nice color picker available in the level editor, it would be highly desirable to be able to just easily select a level specific color for the laser beam in the MM/DF engine! Regarding overloading color, it seems naturally for me to let the normal beam color change towards red (just as it seems naturally to me to let it change towards black when fading out), but it wouldn't be a problem to just make it configurable, too. And I could even introduce a "primary" and a "secondary" laser beam color, using them to draw the middle part and the border with a different color, for example, having a white laser beam which is glowing blue at its sides. This could look quite nice, wouldn't it?

[TheOnyxGuy]

And I could even introduce a "primary" and a "secondary" laser beam color, using them to draw the middle part and the border with a different color, for example, having a white laser beam which is glowing blue at its sides. This could look quite nice, wouldn't it?

Indeed, I had that idea a while ago, but wasn't sure back then if it was possible to implement for this game. One question is, since it will technically be two beams simultaneously changing directions, does that mean that they are twice more likely to hit the beam cap and cut it off in the middle?
Could the behavior of the beam potentially be optimized in such a way that it would be much less likely for it to even hit such cap? As much as I like and support the idea, because I kinda wished for it a while ago, I'm also a bit sceptical about it's functionality because I'm not sure if it will be as usable as one beam, considering that one beam already has a pretty low cap.

[TheOnyxGuy]

Revisiting this idea about the laser beam, I got a random idea: what if we could have different animations for the beam? Aside from it slowly turning from regular to overloaded color, what of there were animations of it flipping between the two whenever it hits any with configurable frequency and configurable fading length?

I could show off some examples, but let's just say, I wrote that while being at work from my phone, and I wrote it right now just so I would not forget about it. Maybe later.

[Holger]

No examples or demonstration animations needed, I think, because I got the idea! And yes, that makes sense. Especially when playing without sound, it's sometimes hard to notice the overloading laser beam, even if there is still the "overloading meter" in the game panel. But when only looking at the playfield, you sometimes really only notice that it's overloading when it's quite late! So yes, if it would be "blinking" or oscillating between two colors, that could be quite helpful! Like, between the current "normal color turning slightly or some more towards overloading color" and "fully overloading color". Or between the current color (fading slowly from normal to overloaded) and a second highlighting color.

I do like the idea, and will think some more about possible implementations.

[TheOnyxGuy]

What would also be a pretty good indication for overloading is something that I don't think R'n'D/MM engine can technically do, but can at least "imitate" is little beam particles erupting from the spot where the beam is being reflected back at. But it would be kind of too much, so maybe at least predetermined sprite animations of little sparks jumping from that spot.
Or perhaps also the "active" state of the beam shooter (Emitter/McDuffin) instead flashing between red and orange as a warning. (although, I also got a thought that ".active" state could be instead for the disabled Emitter/McDuffin via Fuse and overloading shooters as something else... maybe, ".dying", it's barely used aside from being player's "ARGH" death sound)

[TheOnyxGuy]

I just remembered that outside of beam flashing we could have an animation for the shooters themselves (emitter and McDuffin) we could have a separate animation whenever they get overloaded... Although I'm not sure if would be '.active' since we also have their "active and inactive states" whenever they get turned on and off with a fuse.