Scorpion Engine

[earok]

Originally Posted by Mixel

Another thought.. does the existence of foreground tiles on the map use extra ram? If so does reusing the same tiles in the fg layer repeatedly use up less? There are some places I’ve done uneccessarily elaborate stuff on the foreground layer, if it uses ram in the same way as the other map layers that’s fine but if not I can probably simplify things.

Each foreground tile also stores the background image that it's underneath so that it can be blitted extremely quickly (it only blits overtop of things behind it when there's actually something behind it), but it doesn't store any redundant graphics so it should be fairly trivial.

If you check the size of the ".gfx" files (1.gfx for your first level, 2.gfx for your second level etc), that will tell you how much chipram they're consuming, since those files get loaded straight into chipram without decompression.

[earok]

Posted an experimental update to the experimental branch. It's a performance update only, across the board there's been a lot of tweaks and rewrites.

It could very well break things that worked before (though everything seems OK on the demo games), if you try it out, please let me know if it's messed anything up.

Edit: Some technical details if anyone was interested. The color bands are a way I have of measuring performance, overall the show how long it takes a frame to render. Left is the previous version, right is the current version.

You can see that, even though there's more happening in the right frame (twice as many onscreen characters), it's slightly faster than the left frame when it's the player character alone. That doesn't mean that you can put twice as much onscreen as you could before, but you should at least be able to fit a few more actors on screen without hitting any speed issues.

[Mixel]

Woo!! First of all, that seems a pretty sizeable performance boost on unexpanded A1200 again! TY!

My errors so far..

1) the last frame of sprites sticks around on screen.. (like, if I do the attack anim swoosh, it hangs around until the next sprite appears, applies to explosions and stuff too)

2) a lot of nasty graphical artefacts appearing all over the place, and they get worse over time..

3) "Prevent collision" on animations no longer works..

4) I got a guru meditation when I play through the whole game so far Intro barge, World map (pressing 1 to teleport to Level 1) on reaching tunnels2 it Guru'd (but by this point there was so much corruption on the screen im not surprised, hehe.. It seems to massively increase whenever foreground layers are on screen?)

I'll push up latest CMO in case it's helpful. Press N to disable the unfinished weird music.

[earok]

Originally Posted by Mixel

Woo!! First of all, that seems a pretty sizeable performance boost on unexpanded A1200 again! TY!

My errors so far..

1) the last frame of sprites sticks around on screen.. (like, if I do the attack anim swoosh, it hangs around until the next sprite appears, applies to explosions and stuff too)

2) a lot of nasty graphical artefacts appearing all over the place, and they get worse over time..

3) "Prevent collision" on animations no longer works..

4) I got a guru meditation when I play through the whole game so far Intro barge, World map (pressing 1 to teleport to Level 1) on reaching tunnels2 it Guru'd (but by this point there was so much corruption on the screen im not surprised, hehe.. It seems to massively increase whenever foreground layers are on screen?)

I'll push up latest CMO in case it's helpful. Press N to disable the unfinished weird music.

Ah, great to hear that it's given you a boost!

Sounds like CMO is a good test case for the latest build, so I'll grab your latest source and do another update in a day or two after testing.

[malko]

@earok:

[earok]

Editor updates checked into both CMO and experimental repositories. Should resolve issues with foreground/block overlap (which was the likely cause of guru), disabling collisions in animations, and sprites not disappearing. Not sure if it's absolutely everything fixed, but it seems to be much better than it was.


@Mixel - I noticed a glitch where there's a thin blue line at the top of the screen after dying. Is that deliberate? I assume the cause of that is setting Color00 in a codeblock.

[Mixel]

Originally Posted by earok

Editor updates checked into both CMO and experimental repositories. Should resolve issues with foreground/block overlap (which was the likely cause of guru), disabling collisions in animations, and sprites not disappearing. Not sure if it's absolutely everything fixed, but it seems to be much better than it was.

Woah! Super fast update again! TY! I'll see what else I can break.

@Mixel - I noticed a glitch where there's a thin blue line at the top of the screen after dying. Is that deliberate? I assume the cause of that is setting Color00 in a codeblock.

Oh boy, that's all related to me using non-black for 0.. I'd been using palette overrides to try and replace 0 with whatever I didn't think I needed in each particular level. I really need to fix it but I'm having some issues trying to get it to not make the wrong things transparent. Tried sacrificing my darkest green pair.

Weird EAB was down for me when I tried to post this and I've msg'd you about it already, but interesting transparency stuff.

[lesta_smsc]

I don't have time to trawl to nearly 550 posts on this but just want to say I watched that YouTube clip from the first post and @earok wow this is great!

My brother once made a pokemon game on the Amiga and wrote it all in AMOS! He extracted sprites from the original game.

If this engine let's you essentially take the base files and run them on Amiga that would awesome. Even better if it was over a few disks and asked you to insert another disk for loading lol.

If I have completely misinterpreted the nature of this engine then apologies.

[earok]

Scorpion is designed to be a fairly generic engine. Just because there isn't a turn based RPG in it currently, it doesn't mean that one *couldn't* be made in it. But it can't just load generic data files, everything would need to be converted to Scorpion's formats.

Multi-disk game support is something that isn't there yet, but will be at some point in the future (so currently games either have to fit on a single floppy, or game have to be hard drive installable)

[UltraNarwhal]

Experimental build is quicker. Main thing I noticed is in release build more than 4 sprites caused slowdown, experimental keeps speed but flickers.

[Mixel]

A new bug that's actually a real bug and not an entirely made up by me being daft bug

When something spawns it does a second or two of idle before switching to the moving frames, so eg if you die and hold down right, you slide along as idle for a little while. enemy actors do the same after spawning. It also does it for a flash when I get off ladders.

On the other hand.. Daaamn it IS fast/smooth now. And the latest Colour0 lock thing is so neat, I can use 63 of my 64 EHB colours I havent had to sacrifice any of them seemingly. I wasn't expecting that.

I'm really curious about how the "scorpion engine: free edition" splash screen is surrounded by the same "shade of black" as the border frames at the top and bottom.. If I used.. whatever that off-black is, instead of pure black, would it get rid of the dark band with the game in? (only visible on real amiga)

[earok]

Thanks for the tests guys! Really happy to hear everyone's getting improved performance, that made all of the optimizations across the entire codebase worthwhile. I'll look into the sprite, black and animation issues tomorrow. Would you mind checking in your latest changes to the repo?

[Mixel]

Done. Its really visible in that "smooth or jerky, who knows" video: [ Show youtube player ] (though maybe not if your brightness settings are different to mine..?)

I get the same in SGDTH and Amigo, a dark band with the game in the middle compared to a "lighter black" band along the top and bottom (which seems to be the same slightly lighter black that the splash screen uses) - only happening on real hardware and doesn't matter whether I turn off or on 24bit colour etc..

Its markedly different to how it was a few days ago though where the status bar was in its own little island of darker black-ness. (you also cured that odd fringe of copper on the left side!)

[earok]

I've got a fairly good idea of what the issue is (to do with border blanking again, which I need for 24bit AGA gradients, but I could maybe disable it and just use the OCS gradient if there's only an OCS gradient defined)

In other news, Alpine9000 helped me solve some issues with the sound library, so in the next update music should be more reliable on high end systems that have VBR mover utilities installed.

[Mixel]

Originally Posted by earok

I've got a fairly good idea of what the issue is (to do with border blanking again, which I need for 24bit AGA gradients, but I could maybe disable it and just use the OCS gradient if there's only an OCS gradient defined)

That sounds like a good compromise.

TBH It'd look okay in my game if it was straight? it's got this weird lip at the left where it goes down.. It looks way worse in SGDTH for some reason.. No idea why my game's grey spans all the way to the top and bottom now but SGDTH's doesn't.. (I've turned up the gamma on a couple screen captures here to show the.. slight wonkiness of the line)

Edit: it occurred to me that this wonky bit could easily be outside of the normal overscan area anyway, and people with more traditional (eg not an OSSC) display setups might never see it anyway? Either way I’ll probably just avoid Aga gradients if you do use that solution.

In other news, Alpine9000 helped me solve some issues with the sound library, so in the next update music should be more reliable on high end systems that have VBR mover utilities installed.

Oh so THAT's the setting that was killing my sound. I had no idea what that does in the ACAtools thing.. looking at the docs they warn against using it and say it has minimal impact on performance anyway, so I'll probably just leave mine turned off, but happy to test with it enabled if that helps.

Edit again: That translucency glitch (its not a bug, its a feature!) that seems to be a result of using EHB slot #31 when color#0 is enabled.. Is that likely to stick around? I kind of love the effect and am contemplating using it intentionally? (no biggie if it breaks really, just wondering if you're going to actively try to squash it?) scratch that I think it might already have been squished, I haven't been able to replicate it again yet. *sad trombone* Oh well, lol.. Either you fixed it or it only worked with one, specific weird palette arrangement. I'll go back through my old ones and see if its my end. It was a silly idea anyway. XD

[saimon69]

I think you know well that allocate new color is needed instead of color 0 for the sewer...

[Mixel]

Originally Posted by saimon69

I think you know well that allocate new color is needed instead of color 0 for the sewer...

Well.. Yes, hehe. That wasn't what I was testing at the time. That's fixed now. It's looking much nicer with pure black out of the equation entirely. Colour #31 is a bit suss in EHB - trying to use it when the colour in slot #0 is also black (even if its not pure 000) seems to have unpredictable results.. (and has done in so many different ways since I started, i don't think it's scorpion's fault) So I've sidestepped that.

[earok]

Latest experimental update pushed to experimental, Duckstroma and CMOHN repositories.

- Previously discussed audio fix for machines with non-zero VBRs
- Sprite flicker should be much better now (the bunny pen was super cute btw @UltraNarwall)
- Removed ECS border blank everywhere except AGA copper skies (the one place it's actually needed), which should result in a consistent border shade. But you can now simply remove an AGA sky and use the OCS sky instead, you no longer have to assign for AGA as well as OCS. (If you've already assigned an AGA sky, just go to assign a new one, but click cancel)

Could not replicate issue with 'sliding' idle animations, but I tried a couple of things that could potentially fix it.


I'm wondering if I should treat 2021.4 as a performance centric update with no new features (maybe after doing performance optimizations on the sample games with new features like sprites and animated blocks), and do 2021.5 as the parallax update, or if both updates should be released as part of 2021.4.

[Mixel]

I’ll try to get sliding to happen again today while I’m recording (and before updating). I think it might happen more when there’s a lot of stuff happening on screen.. (which happens most times I die in CMO because of the bonesplosion)

I can see the advantages to both those .4/.5 ideas. It sounds sensible to do your first thing and use .4 as a chance to get everything in order? But parallax! (I bet parallax will cause a big boost in interest.)

How baked-in is the “follow player direct” coordinates? I have some really cool ideas for enemy behaviour if you can set variable followtargetx to Playerx+30, etc.. if you see what I mean? So much really interesting movement could be made in codeblocks by slingshotting enemy actors around blocks etc, have bosses that float at x pixels away from you then strike at you.. or just float in front of you and shoot constantly (some turrican stuff does this)

[earok]

Originally Posted by Mixel

I’ll try to get sliding to happen again today while I’m recording (and before updating). I think it might happen more when there’s a lot of stuff happening on screen.. (which happens most times I die in CMO because of the bonesplosion)

Interesting.. definitely show me a video if you can (but after updating, otherwise you may be recording an issue that's already fixed).

Originally Posted by Mixel

I can see the advantages to both those .4/.5 ideas. It sounds sensible to do your first thing and use .4 as a chance to get everything in order? But parallax! (I bet parallax will cause a big boost in interest.)

I think you're right, I'll launch .4 as a performance update only release, maybe this weekend depending how I get on with things.

I've got some ideas for boosting performance in some of the sample games that are a bit choppy on A500 (Amigo and Monkey Lad particularly), so I'll tidy those up as well.

Originally Posted by Mixel

How baked-in is the “follow player direct” coordinates? I have some really cool ideas for enemy behaviour if you can set variable followtargetx to Playerx+30, etc.. if you see what I mean? So much really interesting movement could be made in codeblocks by slingshotting enemy actors around blocks etc, have bosses that float at x pixels away from you then strike at you.. or just float in front of you and shoot constantly (some turrican stuff does this)

It's pretty baked in, but at least in theory most of that can be achieved with the "CPU" actor and use of codeblocks. Eg, stuff like

if actor_x < player_x + 50
setlookdir right
endif
if actor_x > player_x + 50
setlookdir left
endif

Having said that, codeblock controlled movement like that is more CPU heavy than native scorpion movement types (in general, codeblock stuff should be kept to a minimum, particularly stuff that runs every frame - it really needs optimisation too). Adding an X/Y offset for pursuit types makes sense. Could even theoretically be used for "drone" helpers.