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!!

[UltraNarwhal]

In the latest experimental build I noticed
- Wait is being ignored, so my splash screen no longer waits 4 seconds before fading out.
- Pressing fire on title screen now creates egg on level load.
- Moving up and down between screens shows part of level it shouldn't before moving camera to right place (though I can hide this using a fade). Updated repo so duck is next to a screen drop point.

Other than that rest is better.

[earok]

Originally Posted by Tsak

Awesome man!!

New check-in to exp/duck/cmo repos:

- Expressions are compiled to native 68K for performance reasons. There's also some automatic optimizations eg divides and multiplies are converted to 68K bitshifts where possible. (not sure if it was even being used by anyone, but modulus operation is currently not supported).

Also resolved Ultranarwall's reported bugs, being:

- Wait did not function while there was no level loaded
- Newly spawned player would attack immediately
- A sudden camera movement would result in a screen tear

[Mixel]

Sweet! I was having that last bug you mentioned too.

I don’t even know what modulus is so I’m pretty sure I’m not using it. All this optimisation sounds great! TY!

[UltraNarwhal]

Originally Posted by earok

- Expressions are compiled to native 68K for performance reasons. There's also some automatic optimizations eg divides and multiplies are converted to 68K bitshifts where possible. (not sure if it was even being used by anyone, but modulus operation is currently not supported).

Thanks, that was quick
Is modulus the reason my camera Player_Y / YRes * YRes now currently only moves half the distance up/down it use to?

Left is correct camera position in stable Scorpion, right is what it looks like in current experimental.

[earok]

Originally Posted by UltraNarwhal

Thanks, that was quick
Is modulus the reason my camera Player_Y / YRes * YRes now currently only moves half the distance up/down it use to?
Attachment 71155
Left is correct camera position in stable Scorpion, right is what it looks like in current experimental.

That has to be a bug with the compiler, sorry about that, I can check it out later.

[earok]

Checked in a new fix for the 68K assembly, fixes calculation issue with division reported in Duckstroma.

Modulus is an operation to get the remainder of a division. I think I can put it back in when I have some to further refine the 68K assembly. An example of using it would be like this:

You've got a clock that displays minutes and seconds. You've got 200 seconds left.

Calculating the minutes is just a matter of dividing 200 by 60 = 3
Calculating the seconds is a matter of using modulus on 200 (% symbol) by 60 = 20

Edit: I think I'll aim to publish all of these recent performance fixes into a new official version this weekend, so feel free to keep reporting glitches

[Samurai_Crow]

@earok

Do you mind if I ask what the problem computing the modulus was? I know the divide instruction computes the quotient and remainder in the low and high words of the destination register so extracting the modulus part requires something like

eor.w dx,dx
swap dx

Because the clr.w opcode is buggy in a 68000, I substituted the equivalent eor.w opcode to clear the low word.

I hope that helps.

[earok]

Originally Posted by Samurai_Crow

@earok

Do you mind if I ask what the problem computing the modulus was? I know the divide instruction computes the quotient and remainder in the low and high words of the destination register so extracting the modulus part requires something like

eor.w dx,dx
swap dx

Because the clr.w opcode is buggy in a 68000, I substituted the equivalent eor.w opcode to clear the low word.

I hope that helps.

Thanks mate, I'll use that. I need to do a general tidy up of the 68K compilation, at the moment it's more a problem of the expressions in Scorpion being hard coded so that each operation is no longer than four bytes (so I need to tidy that up so I can support longer operations with swaps, masks etc)

[earok]

New update posted, I may publish this as the official one in a day or two if no major issues come up.

- Improvements in the generation of 68K assembly.
- Modulus support is back in.
- The main palette can be edited within the utility, though it can still be edited in an external tool. It also shows how the colors will look in OCS and AGA setups.

I had some very random issues where the palette sometimes wouldn't save correctly, which (hopefully) are fixed but because of this I've made it so that it creates a backup when saving any changes.