Scorpion Engine

[earok]

No worries

Having a super late night with Mixel on his stream. I put in another experimental update while I was there:

1) Fix for attack (non-autofire)
2) Fix for toggling pause nudging parallax left or right
3) Fix for some panel glitches

For some strange reason, using the "normal" Blitz system for allocating memory with Bitmaps was introducing very rare graphical artifacts on panels, though they started becoming very common on Mixel's game. Manually allocating memory to put the panels in seems to have fixed that.

[acidbottle]

sadly i couldnt get the "charge up" working. I do notice a variable on the standardlibrary list named "button_down" with a constant of -1 if button held. I crashed the game trying to implement this in a codeblock but could this be a factor or umm .. somehow, something?!

[earok]

Button_down is a constant so it can't be changed. You can use it for things like

If control1_fire == button_down
;do stuff if the button is being held down
Endif

If control1_fire == button_hit
;do stuff only if fire was pressed this frame
Endif

[Mixel]

Originally Posted by earok

Button_down is a constant so it can't be changed. You can use it for things like

If control1_fire == button_down
;do stuff if the button is being held down
Endif

If control1_fire == button_hit
;do stuff only if fire was pressed this frame
Endif

Woah..! I didn't realise this either.

Thanks for the stream help again, that was a ridiculously productive. So many fixes.

It took me a while stewing on it and I figured out what you meant about isometric slime lake, and just tried it and i think it looks much nicer, so thanks for that idea too.

I tried some experiments with disappearing snail too.. It only destroys the block below it when it disappears if the surface is a Slope block (in my case it was a flat slope block. If it's just a flat platform I can still make the snail vanish by walking left then right at exactly the right time (sometimes) but it at least doesn't temporarily eat the floor logic in the process.

[earok]

Hmm.. I may need to look at that snail glitch sometime!


I ended up doing a few more random things for today's update:

* Copperlist optimisation - for games that have their background color as black, AND they don't use copper skies or parallax (so basically just top down games), there's now three fewer copper instructions per line.

* Copperlist optimisation - for games that do use parallax, there's two fewer copper instructions per line where the background (first strip in the image) is black.

Those copperlist optimisations should help performance at least a little on machines that don't have fastram, as well as save a few KB of chipram here and there.


* Editor fix, the set/edit parallax buttons now show the filename (Suggested by Czorny)

* Fixed graphical glitch when reloading bottom panel at runtime. (Essentially the cause of this was the old panel is still in turned on when being overwritten in memory by the new panel. The bottom panel gets turned off temporarily while the new panel is loaded in).

[acidbottle]

Well, button down constant is making progress!

However, on timer expire i set a codeblock to something like:

if control1fire == button_down then ..
set isfast to 1
goto newcodeblock
end cond

if control1fire != button_down then
set isfast to 0
goto newcodeblock
end cond

THEN, in the newcodeblock

i check var isfast and change the player type to either fast one or slow one

BUT, the player does not change back from fast once its set


is so close now, be a bummer if I cannot figure this out haha

[earok]

We've got a similar case in AlarCity where there's two versions of the player character depending if we've got fire held down or not (since there's walk animations for shooting and not shooting). What we did there was

=== codeblock_walkhandler ===
if control1fire != 0
set actortype to shooter
endif

=== codeblock_shoothandler ===
if control1fire == 0
set actortype to walkter
endif

Each of those is called in the onexpire of the respective actors

[acidbottle]

Originally Posted by earok

We've got a similar case in AlarCity where there's two versions of the player character depending if we've got fire held down or not (since there's walk animations for shooting and not shooting). What we did there was

=== codeblock_walkhandler ===
if control1fire != 0
set actortype to shooter
endif

=== codeblock_shoothandler ===
if control1fire == 0
set actortype to walkter
endif

Each of those is called in the onexpire of the respective actors

Ahhh you are a legend earok!!! Thats it

Thank you so much!

[earok]

No worries AcidBottle

---

I ended up doing a fairly significant update to the sprite system (checked into experimental). We've now got support for four color (technically 3+transparency) sprites. It is a complicated beast to understand and there are a few gotchas, so I'd recommend only using it if you really know exactly what you're doing.

Just a refresher - the Amiga has eight sprite channels, you only need to use one for a 4 color sprite but you need two for a 16 color sprite.

Let's consider this screenshot.



The cowboy and all of the six bullets are rendered with sprites. The cowboy is in 16 color mode, the bullets only have three colors each so they're in 4 color mode.

Both the cowboy and bullets are set to Only Sprite. The cowboy can be left as the default "attached 16 color" mode, but the bullets need to be changed to a four color mode. We've got some options here:

- 4 colors (channels 8-1)
- 4 colors (channels 6-1)
- 4 colors (channels 4-1)
- 4 colors (channels 2-1)

We've chosen the second option (channels 6-1) because we want six channels for six bullets.

Now we need to arrange the palette. Let's take a look at this:



The green area is for 16 color sprites, so all of the colors the cowboy can use are in that zone.

We've said that we want to use the first six channels, so:
Channels 1-2 are the red area
Channels 3-4 are the yellow area
Channels 5-6 are the white area

There's one final thing I wanted to mention - you need to take care to make sure that the sprites are rendered in the correct order when mixing and matching different kinds of sprites, otherwise you'll get visual glitches.

Let's say you render the bullet and then the cowboy. The bullet uses only one channel, which means that the next sprite will be on an even numbered channel. But 16 color sprites can only work on odd numbered channels.

All I needed to do to reverse the draw order so the cowboy was first, was simply increase the z-order of the cowboy.

[acidbottle]

Gunsmoke will be an awesome game to port

[Mixel]

Wow that does look like a big deal with the sprites! Useful for a lot of games. I dont think either of my current projects are suitable candidates to use this but it looks powerful! And that looks like an interesting demo project(?)

Odd feature request - eventually could we have control over copper gradients.. either by scrolling them up/down, or somehow tweening between different ones? (both ideally) To be able to have the background copper fade in different areas, or have the sun set (Fire & Ice style), etc. TBH even if you could swap out the copper file with a different one using codeblocks that'd be enough as I could manually fade it in the way i have elsewhere.

Maybe you could do similar with the copper/parallax stuff too, by providing multiple of those colour strips from the left hand side of the .parallax png, that would be super powerful. We could use codeblocks to randomly do lightning flashes that change the palette of the parallax backdrop and stuff. (seems like an odd thing to revisit though maybe as its advanced already all things considered! I just keep getting cool effect ideas!)

[Tsak]

Awesome update! With this Scorpion taps even closer to the true potencial for Amiga games. The big deal with sprites is that they are VERY cheap, essentially using them means that you offload the blitter from heavy duty which really helps with performance. Almost all classic Amiga games did use sprites to some capacity.

@Mixel, imho you should definitely consider using them, you can really do all sorts of stuff, projectiles, impact/explosions or other effects, even have enemies and foreground elements as sprites. Especially with your Wizonic game f.e. you could keep the game running in 16 color mode and then have plus 16 colors (for free) for all 4 players or projectiles. The game will run lightning fast leaving you ample space for all sorts of crazy effects and action on screen and still keep it a smooth 50hz for your a500 target render.

[earok]

@Mixel I'll need to think about it. Giving more control of copper is something I'd like to do -but- changing and entire screen's worth of copper skies may be slow if done on a frame by frame basis. Though I think simply making it so that you can change the colors in codeblocks on any particular line could be doable.


I did another check in (!), this changes how platforms work so it may be a good idea to review platforms in your game to make sure they work as expected. It's a change that probably should be done awhile ago, but Czorny prompted me about it and that got me thinking about how to implement it in the engine. I'm aware that some people have implemented complicated codeblock routines to fix this exact problem, hopefully this will make things a little simpler!



Put simply:
- The yellow blocks just have the solid flag ticked only. Under no circumstances, can an actor cross them.

- The grey boxes have the solid AND platform flags ticked. They're only solid on the top, so we can jump from underneath, but there's no way for us to fall through. If your game doesn't support the ability to drop through a platform, you'll want to flag all of your platforms as solid.

- The brown boxes have JUST the platform flags ticked. If we hold down on the joystick, we'll fall through. Also on non-platform control types, like "control" or "cpu direct", they should just move through these.


This is not well tested other than the video I just made, so I'd be interested in any bugs that need to be fixed.

[Mixel]

Originally Posted by Tsak

@Mixel, imho you should definitely consider using them, you can really do all sorts of stuff, projectiles, impact/explosions or other effects, even have enemies and foreground elements as sprites. Especially with your Wizonic game f.e. you could keep the game running in 16 color mode and then have plus 16 colors (for free) for all 4 players or projectiles. The game will run lightning fast leaving you ample space for all sorts of crazy effects and action on screen and still keep it a smooth 50hz for your a500 target render.

You're probably right, I've got to admit though I didn't 100% understand the explanation, haha! Currently I'm autospriting all my moving things. (basically duplicated my 16 colours in the second half of the 32 so that they don't change when they toggle between BOB and sprite. Now, looking at the example again and rereading it a bunch of times I think I understand.

The thing that threw me (i think) is the fact that in the 3 different channels contain the same colours.. I most likely would want to use it for projectiles.. I need to experiment and see what happens when I put multiple sprites in the same channel? When the channel isn't available will they fall back to 16col sprites, then fall back to BOBs? or just bypass sprite entirely going straight to BOB? Or flicker between the sprites in that channel? - Tried that.. Oh man. I don't think I'm smart enough to get this to work, lol. Most of the time my players are currently sprites, but they're all using too many colours to exist in a single channel each.

Originally Posted by earok

@Mixel I'll need to think about it. Giving more control of copper is something I'd like to do -but- changing and entire screen's worth of copper skies may be slow if done on a frame by frame basis. Though I think simply making it so that you can change the colors in codeblocks on any particular line could be doable.

That's great. Not really a critical request, anyway.

I did another check in (!), this changes how platforms work so it may be a good idea to review platforms in your game to make sure they work as expected. It's a change that probably should be done awhile ago, but Czorny prompted me about it and that got me thinking about how to implement it in the engine.

Ha AWESOME! I was just about to manually implement this! When I was messing around roughing Wizonk maps I very quickly realised why in rodland you can make ladders down through the ground and in Bubble Bobble you can jump up on bubbles. Without a way to save yourself, certain map patterns are really difficult to not make into "boring death traps". Passing through the ground is ideal.. (i was also thinking of wall jumps as a possibility but I dont think they really fit the game) TY!

You're on a roll again!

[earok]

Amiga hardware in general is pretty difficult to follow, it took me a bit just to properly think through how I was going to implement the gun.smoke example!

The three different slots (17-19, 21-23, 25-27) containing duplicates of colors is because each of those slots overlaps with two 4x color sprites. Thus, I need to have an exact duplicate of the colors in three slots to use in six bullets. (there's no technical reason why they couldn't be different colors other than it'd mean some bullets were one color, and others would be different)

---

New check in based on some bug reports from Czorny:
- Fixed issue where dynamically changing blocks didn't support the new "soft/hard" platforms system.
- Fixed issue where CPU_Platform would fall through a "soft" platform
- Fixed an inconsistency where collisions to the left and top were inconsistent with collisions to the bottom and right. It's kind of hard to explain but essentially it should solve an issue where it took less time to dig to the left in Morci than it did to dig to the right. This is one of those things where I hope it doesn't break anything else!

[Tsak]

Originally Posted by Mixel

Oh man. I don't think I'm smart enough to get this to work, lol. Most of the time my players are currently sprites, but they're all using too many colours to exist in a single channel each.

Do this :

1) create a 16 color sprites palette -just- for your players.
2) set all your player anims to be SPRITES ONLY.
3) Done! Since your players are more than 3 colors each means that they can only be rendered as attached sprites. Scorpion will take care of that, you don't need to do anything else, (like arrange your palette in some special way). Attached Sprites can use ANY color from your 16 color sprites palette except the first one which is always used for transparency.
4) Since the players are rendered as attached sprites and you've got 4 of them, means that you'll be using all 8 available sprite channels (2 channels are used per attached sprite). Since you're using all of them, everything else must be a bob. So don't set anything else as a sprite (except for your players) and you're good to go. This setup will basically give you optimal performance since the one thing you see all the time are the 4 players.

Note that using Autosprites isn't optimal, the above setup is guaranteed to give you the best buck for your money performance wise. As a plus, by keeping the players and their palette seperate means also that you can have unique colors for them and unique colors for all the rest. Like f.e. you can change the level colors and theme later on (say create a snow themed tileset) and the players won't be affected (this is true only for 16 color games but not if your game is a 32 color one as then you might be using for bobs and tiles colors 16-31 which are also used by sprites).

[Mixel]

Aha! Thanks! . that’s not too far off what I’ve done already, except I’d told the enemies and projectiles to be sprites too. Which meant every time you fired - one player would briefly become a Bob. I am only using 16col mode, so that’s all really interesting!

It hadn’t even fully dawned on me by having the 4 players be the [i]only[/] sprites I’d be guaranteeing I don’t run out of sprite channels. Interesting! So far I’m enjoying working with the really limited fixed palette (it suits the way I like to make one big tileset per project too) but I can definitely see myself experimenting with more/different colours later. Hmm!. (While cmo has an abundance of colours it’s really nice to work with the opposite, as a challenge as much as anything) .. when it comes to eventual campaign levels without 4 players I’d probably want to sprite some extra stuff too. I think I totally get everything now.

[earok]

Experimental update time!



As with before, the Cowboy and the bullets are flagged only sprite. But the cowboy takes up two sprite channels and there's sixteen pairs of bullets.

All sixteen pairs of bullets use a single sprite channel and the copperlist is the same size as before. How did we do that?



We have a new multiplexes feature in the animation window. It comes with a LOT of caveats:

• Only supports four color mode.
• Each copy must be the exact same sprite, we can't use this trick to render a bunch of different looking bullets for example.
• Only supports sprites that are 16 pixels wide or less.
• There's a memory trade off (each multiplex adds an additional copy of the sprite, so it's only recommended for small things like bullets)
• Only one copy per scanline will work. You could do a second copy of the animation to have more than one multiplexed sprite on a scanline, but this would come at the cost of an additional sprite channel.
• Only works if the actors are sorted sequentially in the Z-Buffer (eg, if the Cowboy was in the middle of the bullets, it could cause issues unless Z-Order was set appropriately)

How it works is based on the Saint Dragon trick. In short, we configure the end control words - when a sprite has finished rendering, we tell it to go somewhere else until there's no copies left. We can't start the next sprite until the previous one is finished, hence the restriction on scanlines.

In theory this trick would work much better on a top down shooter than a side scrolling one, which is ironic given that it comes from Saint Dragon (indeed, Codetapper notes that there is sprite flicker in Saint Dragon precisely because there's sometimes more sprites on a scanline than otherwise allowed).

[acidbottle]

Such another great update, the engine is becoming the 8th wonder of the world, at this rate!

Quite a lot to take in on the sprite side of things but think I get the gist of it now. Had decided a few weeks back to re do all the starforce gfx now I have a much better understanding, its difficult and time consuming but had no real choice.

Going to start a thread for a particular project later in the week, has plenty of bugs and things to resolve but what has been achieved in a month would have taken me many months in machine code or even AMOS (which was about my technical limit), if I could achieve anything at all!

[domkid]

Great job and update Earok