Scorpion Engine

[Mixel]

Ah! I'll be careful not to codeblock too much.

This is going to be confusing..

Just recorded the sliding bug and looked at my codeblocks it's once again it's a ME bug, not a scorpion bug. But it's still potentially interesting! It's not "when spawning" - It's actually when you change-actor - the animation behaviour's slightly different now. (i got confused because all my code I refer to it as spawning but it technically isn't from your POV, doh - at times some of my actors do spawn a different actor and destroy the old version of themselves too, so I thought that was what was happening with the beetle!)

It seems to play the first animation in an uninterruptable way. Previously I had francis teleport in null/dead form and play the franidle anim on him to trigger him into visibly existing again. Now the idle animation plays in full regarldess of whether you're walking. I've now fixed it in his case by making a single frame animation and tell him to play that instead. So it's not a necessarily a bug just a subtle change in the way you're dealing with prioritising animations/motion, and I can fix it easily now.

The beetle code I've included here used to work: "when the dice was <= 2 change actor to bigbugfly" overriding the bigbughide animations. Now he plays the bigbughide animation while flying, then continues flying (and playing the appropriate animation) after the hiding animation is complete. Now I can just tell those not to play if the diceroll is >2 and that'll be fixed too.

[ Show youtube player ]

(The second after Im reincarnated .. And the moment where the beetle switches from shell to flying and slides along)

So, not sure if this is intended functionality, it doesnt seem like a worse way for it to be really. Probably not going to affect anyone else..?

These bugs are definitely real though: The sticky sprites are back.. (my vwoosh hovers on screen until another sprite is also on screen) And there's a flash of copper rainbow in the middle of fades.

[earok]

Fixes for the day checked into CMOHX, Experimental and Duckstroma repos.

1. (re)fixed sticking sprites
2. Fixes for blanking copper rainbow between level loads


Regarding set_type, the behavior is that if there's a one shot animation playing from the previous type (which is to say, one manually triggered from codeblocks), it continues playing until the end. I can't remember the exact reason for that, but it's a deliberate thing I put in the codebase so there must have been some case for it.

[Mixel]

Originally Posted by earok

Fixes for the day checked into CMOHX, Experimental and Duckstroma repos.

1. (re)fixed sticking sprites
2. Fixes for blanking copper rainbow between level loads


Regarding set_type, the behavior is that if there's a one shot animation playing from the previous type (which is to say, one manually triggered from codeblocks), it continues playing until the end. I can't remember the exact reason for that, but it's a deliberate thing I put in the codebase so there must have been some case for it.

Thanks! yeah that’s totally great change_actor behaviour now I know why it’s happening, it’s probably better for stringing animation sequences together anyway.

Two bugs.. if you punch and then activate dialogue your projectile sprite flashes between pages of the dialogue. (Easy to activate by punching while walking toward Lucy in the blue barge section at the start)

I haven’t set up obs properly yet and should go to sleep but in tunnels1, there are creases that if you fall down the sewer, then the next big fall to the right, like ripples across the entire map. Idk if it’s an emulator thing or a scorpion thing so I’ll try it on the A1200 in the morning. (This is another one of those bugs where I look at it and think “wow, if you could control that you could make an awesome water effect..” like those half opacity clouds before, haha)

[Mixel]

Woo thanks for the border fix that's so much nicer now.

Had a chance to capture it on the real A1200, so it's definitely the same in UAE and real life..

It seems to be at the tile heights.. 17, 35, 53

Included is a screenshot where francis' legs are chopped off.. (see what I mean about how it'd be neat as a water effect if you could do it intentionally? haha)

And here's a video of it. but youtube seems to process it out a bit.

[ Show youtube player ]

[saimon69]

A little playability warning: i would make walkable blocks brighter than the ones in background so people kinda know where to jump

[Mixel]

Originally Posted by saimon69

A little playability warning: i would make walkable blocks brighter than the ones in background so people kinda know where to jump

Agreed - that'd be really annoying if this wasn't a secret path - they're not supposed to know to jump there. I purposely hint to it with the existence of those two pipes leading down as a way of introducing hidden paths to the player early. There are a lot of this sort of thing, it's just the most clear demonstration of the graphical wibble happened next to one. (I also have walls that appear solid but you can walk through them, etc.)

[earok]

Ah, thanks for the video and screenshot, I know exactly what the cause is.

From a technical point of view, for efficient vertical scrolling, the bottom of the display buffer connects to the top of itself. Like sending a fax where the paper is taped top-to-bottom in a loop.

Which is fairly complicated as you can imagine (part of the way through rendering the screen, I tell the copper to draw the top of the display buffer rather than the bottom). But what about for objects that cross that boundary and have to be drawn on the top AND bottom? Well, you need to split them in half and draw them twice.

For whatever reason, a bug has crept in where the alignment between the top and bottom halves is wrong, I'll see if I can fix that in the next experimental update.

---

I meant to say, in regards to the "one shot" animation from the previous type still playing, I still can't remember the exact reason for that behaviour so maybe it wasn't important. But in any case, I have been thinking of adding an additional trigger to override a one shot and put the animation back to what it normally should be (the same way there's an animation trigger to trigger whatever attack animation is correct for the actor)

[Mixel]

Originally Posted by earok

Ah, thanks for the video and screenshot, I know exactly what the cause is.

From a technical point of view, for efficient vertical scrolling, the bottom of the display buffer connects to the top of itself. Like sending a fax where the paper is taped top-to-bottom in a loop.

Ah that is interesting.. I didn't have any idea that's how it works. Glad you know what's happening.


I found another glitch, though it might be related to the previous one.. I can see it in two places in CMOHN so far.. it's really obvious in the World Map, but I thought that might be something I did so ignored it as I dont have the world map working full yet anyway.. But it also happens at a really random seeming part of Tunnels1.. This is one place I've noticed it so far in the video, though it also happens to the left of the lake. Basically places along the bottom of the map.. (I included some footage of it not happening, so you can see the transition between the jitter and non-jitter state)



You might not be able to see the jitteriness unless you watch at 720p/50 and fullscreen, I didn't think the video had captured it at all when YT had only partially processed it! It's like you're vibrating back and forth a pixel while running, but incredibly quickly.



[ Show youtube player ] - and this time it's definitely not my capture set-up. It only seems to apply to the player actor.

I meant to say, in regards to the "one shot" animation from the previous type still playing, I still can't remember the exact reason for that behaviour so maybe it wasn't important. But in any case, I have been thinking of adding an additional trigger to override a one shot and put the animation back to what it normally should be (the same way there's an animation trigger to trigger whatever attack animation is correct for the actor)

That sounds good to have options.. Then everyone's covered regardless.. I've fixed my beetle behaviour so it works as expected, but there's probably some situation where that won't be as easy.

[earok]

Fixes checked in to CMO/DS/Experimental repos. The bug was a rather embarrassing one: The area underneath the copper split (where the bottom of the display buffer wraps around to the top) was displaying the front buffer rather than the back buffer.

Which is to say, the area underneath that line was displaying the image buffer that was still being drawn to, hence the glitchiness when moving/jumping underneath the line.

[earok]

It's nearly 4AM, and it's not heavily tested, but Scorpion is compiling part of the codeblocks system to native 68K ASM

Most of the codeblocks system is still interpreted bytecode, but the part that calculates results of expressions is now 68K, eg stuff like

Variable1 = 5 * 5 + Variable2

Would translate into something like

ADD.W #5, D0
MULS.W #5, D0
ADD.W 100(A0), D0 (Assuming the memory address of Variable2 was A0+100)
RTS



The long and short of it is, custom codeblock events should become far less of a performance burden than they currently are.

[Tsak]

Awesome man!!