Scorpion Engine

[UltraNarwhal]

Discovered a bug when using an invisible actor with blank preset animation frame. The actor ignores the recycle setting and once activated on screen stays active (I checked by having it add to score).

[earok]

Experimental check in for the day:

- Noticed an issue where it's possible for a talkpad's draw indicator to be positioned outside of screen (and hence, potentially cause an issue where it's blitted outside of bitmap memory). It's now no longer possible to do that.

- Fixed an issue where (very rarely) loading levels in a certain order could cause a crash. The fix was to reset every single byte in the reserved memory area back to 0 first, I didn't think this was necessary since the memory is simply overwritten by the next level (and indeed it hasn't shown a problem until now) but it seems doing that was the only way to fix a consistent bug reported by NEESO games. This may possibly resolve some other reported glitches with loading and unloading panels and such.

- Invisible actors should *now* honour recycling settings (at least I hope so @Ultranarwall!)

- Sprites should be *slightly* more efficient.

[UltraNarwhal]

Originally Posted by earok

Experimental check in for the day:
- Invisible actors should *now* honour recycling settings (at least I hope so @Ultranarwal!)

Thanks
Unfortunately it didn't fix for me. I've uploaded build with bug to git so you can see it happening. Walk left to activate the invisible crate spawner then watch the blue hud font increase as it runs its codeblock.

My current fix for the issue is to swap out animation when leaving screen.

[earok]

Originally Posted by UltraNarwhal

Thanks
Unfortunately it didn't fix for me. I've uploaded build with bug to git so you can see it happening. Walk left to activate the invisible crate spawner then watch the blue hud font increase as it runs its codeblock.

My current fix for the issue is to swap out animation when leaving screen.

Thanks for that! Found and fixed the bug in experimental branch, it seems to be okay now.

----

Plan for the next few days is to wrap up the 2021.5.3 release (including one or more multiplayer samples).

After that, the intention for 2021.5.4 is to add support for AGA mandatory games. Definitely for expanding the palette (eg, 5BP games can have 48 colors since sprites can be in a different 16 color band that doesn't overlap bitplanes), *possibly* for expanding sprite sizes to 32 or 64 pixels but I haven't quite solved some issues around parallax at that size yet.

[UltraNarwhal]

Originally Posted by earok

Thanks for that! Found and fixed the bug in experimental branch, it seems to be okay now.

Cheers, seems to do the trick.

Did have an odd issue at first, loading project in new experimental build caused a chip ram error after my title screen and loading project back in anolder build caused same error (hadn't before).
Anyway I restored the project from my git and it works fine now.

Moral of the story, remember to make backups.

[earok]

@UltraNarwhal

Ah that's.. interesting. If there's a particular check-in on the git that's broken, I can download that version and see if I can replicate and fix the issue (or at least, compare that check-in with the one before or after to see what changed)

---

Experimental check in:

- Fixed an issue where shooting projectiles out of bounds (in particular, top and left sides) could cause crashes.

- Undid a change I had where changing a player's type would reset the fire button state. To be honest, I'm not totally sure why I did this in the first place, but it caused some unexpected issues in the engine with other projects I'm working on. In any case it shouldn't be too hard to restore the old behavior with codeblocks (eg, set control1_fire to 0 after changing type if you really need to reset the fire button state)

[UltraNarwhal]

Originally Posted by earok

@UltraNarwhal

Ah that's.. interesting. If there's a particular check-in on the git that's broken, I can download that version and see if I can replicate and fix the issue (or at least, compare that check-in with the one before or after to see what changed)

Appears to be a freak occurrence with that version I had only on my HDD, maybe a tmx or png had corupted itself.
If it does happen again (hopefully not) I'll make a backup of its corrupted state.

[Mixel]

I’m a bit confused about colours again, and this is a silly question that’s sort of been answered before, or variations of it. It’s to do with a side project, not CMOhn..

Is there going to be much performance boost by choosing to use 16 colours for a project instead of 32? I know it’ll save some chip.. this project has no parallax, so I’d only lose one colour to copper rainbows. I’m going to try to target 512k A500s, but if not, it’ll definitely run with 1MB, I’m just trying to keep things as efficient as I can.

I guess by using the 16cols for everything I can autosprite all the actors, and they’ll look the same even when they momentarily become BOBs.

[Samurai_Crow]

If the screen is 16 colors, sprites will be the other 16 colors. Bobs will be the screen colors. The screen will update 20% faster and the added bandwidth will be used by the CPU.

[UltraNarwhal]

Originally Posted by Mixel

Is there going to be much performance boost by choosing to use 16 colours for a project instead of 32? I know it’ll save some chip.. this project has no parallax, so I’d only lose one colour to copper rainbows. I’m going to try to target 512k A500s, but if not, it’ll definitely run with 1MB, I’m just trying to keep things as efficient as I can.

As I've discovered 16 colours is best to keep performance, especially if game has scrolling. If you want 32 colours or lots of sprites/bobs on screen try 25fps setting (frame_wait 2).

Don't think I've ever got a Scorpion game to ever run with less than 1MB.

[Mixel]

Thanks! That’s what I suspected. The game/experiment has no scrolling but it will be hectic (many tiny sprites/bobs at least) and I’d like to aim for 50Fps. Design-wise it’s almost the anti-CMOhn. (Though I’ll be using it to experiment with certain systems I’ll need in cmo and other projects.)

Ahh and perhaps it won’t be possible to fit in 512k.. But who doesn’t have 1MB anyway?

[earok]

It'd be very difficult to get a Scorpion project to run in less than 1MB of RAM, partly due to how large the executable is uncompressed (due to the need to support everything from tracker music through to ANIM5, sprite parallax and all of the other features in there). I do want to try and optimize the size of the executable down sometime, possibly by breaking it up into different "modules", but that might be some time away.

Yes, definitely recommend 16 colors for BP and 16 colors for sprites if you're aiming at A500. 16 (and lower) uses the least amount of DMA time. I think 16 for BP and 16 for sprites is the best "bang for buck" on A500, it's what I did for Amigo the Fox.

---

Experimental check in for the day.

AGA mandatory is an option but it currently just moves the sprites from palette entry 17-31 to 241-255. (which is to say, on a 5BP game, you've got 48 or so colors available rather than just 32). Parallax will be completely broken, will need to come back to it. Also there's options for 64, 128 and 255 colors but these are not tested yet.

Next step is going to be allowing sprite sizes to be 32 or 64 colors.

[Mixel]

Sounds great re:AGA

I’m really not attached to the idea of 512k support at all, 1MB will do just fine.

I’ve pretty much decided on a fixed 16col palette for everything in the game (other than rainbows) - it’s a fun challenge to work with and it’s an odd thing to gauge performance for, as the game will sometimes have very little going on but at other times be incredibly hectic, hopefully I can do it at 50fps anyway!

I wonder how slow 128 colours is on an A1200 with fast ram? Is it markedly slower than 64colour EHB? The idea of an even higher end build above the high end build of CMOhn is funny as a thought experiment. (Probably a bad idea in practice)

[Tsak]

>Next step is going to be allowing sprite sizes to be 32 or 64 colors.

*Erik meant here 32 or 64 pixels wide: this means that -f.e.- instead of needing 2 sprites to make a 32px wide one you can now do it with just 1.

>I wonder how slow 128 colours is on an A1200 with fast ram

It should be quite slow as the Blitter on 1200 is exactly the same as in a500 (it's gets marginally better thanks to higher fetch modes). However fast ram does help a lot with performance in general.

[Mixel]

Originally Posted by Tsak

>Next step is going to be allowing sprite sizes to be 32 or 64 colors.

*Erik meant here 32 or 64 pixels wide: this means that -f.e.- instead of needing 2 sprites to make a 32px wide one you can now do it with just 1.

Ahhh! Will this be automatic? I love the idea of it detecting AGA and just using the wider sprites if they’re available. Hmm would this mean a potential 64px wide parallax columns too? ?

>I wonder how slow 128 colours is on an A1200 with fast ram

It should be quite slow as the Blitter on 1200 is exactly the same as in a500 (it's gets marginally better thanks to higher fetch modes). However fast ram does help a lot with performance in general.

Ahhh.. I don’t think I should even flirt with the idea of making AGA enhanced CMOhn. I’m not exactly short of colours as it is. It’s tempting to experiment though.

Could IsAGA be a thing in codeblocks? So we could detect AGA and send the player to intro sequences and certain levels with more colours? (Or display panels with more colours) .. While leaving the bulk of the game ECS. I’m needlessly complicating things again, haha.

[Tsak]

Originally Posted by Mixel

Ahhh! Will this be automatic? I love the idea of it detecting AGA and just using the wider sprites if they’re available.

No, it will most probably be a global game parameter, selected for the whole project. You can't have mixed 64 and 32 or 16 wide sprites. Also you can't have AGA specific features and OCS together in the same exe. Afaik, even in the old days, most games had completely seperate versions for OCS and AGA.

Originally Posted by Mixel

Hmm would this mean a potential 64px wide parallax columns too? ?

Yes, this could be used for parallax, though Erik will have to add this (and currently having AGA sprites and paralax doesn't work).

[acidbottle]

Love the idea of full AGA, 1 project would benefit greatly with a bump in colour, I sometimes like a challenge but not always!

Now panels, these have been the bane of my life sadly and cannot get to grips with them! I had originally thought that they worked as a kind of overlay, over the top of the display, though this is clearly not the case. Is an overlay style panel even remotely possible in scorpion or is my following situation a bit doomed ..

Have used slopes in a level, the level is just over 400 pixels in height to accommodate this. The panel will display above the game area (bottom of slope) but this has the disadvantage of bumping the game area down off the bottom, the larger the panel. I can reduce the size of the panel so the cutoff doesn't happen but I still have a "gray" area between the game screen and top panel. When I reach the top of the slope, of course it all looks good, not so cool at the bottom. Does this make sense to anyone, perhaps a screen shot might be better

Any advice, as ever, is appreciated.

[earok]

Ah, yes Tsak is correct, I meant to say 32 pixel and 64 pixel wide sprites. The complication is we can't pick and choose sprite channels to have at 16/32/64 mode, the entire game needs to be consistent. Which will make parallax extremely tricky, and definitely way more memory intensive. I didn't really want to have to completely rewrite the system entirely for 32 and 64 pixel wide modes but I haven't ruled that out either.

---

@acidbottle! I think a screenshot would be useful. It isn't possible to overlay a panel on the game area but it's possible to use the parallax system for an game area UI (see Amigo the Fox)

[earok]

Experimental check in, support for 32x and 64x wide sprites is now there. Was bit of a pain! I didn't realise that 32/64 wide not only require more bytes for control words but the sprites themselves need to be aligned to 4 and 8 byte boundaries.

I wouldn't try it with parallax - it's going to look janky as hell until I've had a chance to work out how I'm going to handle it.

[UltraNarwhal]

I'm sure this was posted somewhere in here, but after sifting through the past 30 pages can't find it.

Is the maximum width of a map in Scorpion limited to around 512 tiles (8192 pixels)?