Scorpion Engine

[earok]

Originally Posted by acidbottle

Some nice work going on under the hood there earok, always appreciated.

Assuming its a bit quieter on the board here due to discord being up and running, alas this is very problematic for me so thankful you're diving in here to with updates

There hasn't been a lot of discussion on the discord much either, I think people are busy with other things (or have their own threads here where they're discussing Scorpion games), I've been distracted myself with things related to Scorpion but aren't upgrades to the engine/editor itself.

---

Latest check in:

* Fix for czorny, keyboard "On Press" events were not working. Some other fixes related to keyboard handling too.

* The maximum speed a camera will follow a player at is now hard coded to 8.

It's a little difficult to explain but in general, since the game is double buffered, a camera that was following the player at (for example) a speed of 12 would travel 24 pixels between buffers, triggering more than a single row or column of tiles to be redrawn.

I had made the assumption that no one would make a game needing a character to move faster than 8, and for the most part that was true. However, it's common for players to have a jump speed above 8, which means for a fraction of a second the camera is moving faster than 8, and this can cause frame skips. So now the camera will follow up to 8 pixels per frame until fully caught up with the player.

[foleyjo]

Hi all,
Finally had some time to play around with Scorpion again and I have a question.
I`m looking at making a yoyo weapon similar to superfrog. I've got it so when the player presses fire button the player stops moving performs the anim to fire the yoyo and the yoyo fires out and comes back before the player starts moving again.

What I'm aftter though is for the player to not be able to move while holding fire and then when pushing a direction the yoyo fires out in that direction. Main thing I'm wanting is to override the jump commands while fire is held.
Could anyone give me some tips on how to achieve this please?

[UltraNarwhal]

Originally Posted by foleyjo

What I'm aftter though is for the player to not be able to move while holding fire and then when pushing a direction the yoyo fires out in that direction. Main thing I'm wanting is to override the jump commands while fire is held.
Could anyone give me some tips on how to achieve this please?

Change the player to another copy of player actor with a movement speed of 0.

[foleyjo]

Originally Posted by UltraNarwhal

Change the player to another copy of player actor with a movement speed of 0.

Thanks how do I make it so it changes when fire is pressed and changes back when fire is released though?

[UltraNarwhal]

From lots of tedious testing of Duckstroma I've found the following things to watch out for.

Too low Y buffer can cause random block to be redrawn in wrong place, triggered by current block that you change to none. Was at 13, raised to 16 for a 192 resolution screen.

Talkpad sometimes displayed even though didn't activate it with a key press. I was using the talkpad for pause indicator, but removed it and used a wait for fire instead. Unsure if Scorpion bug or WinUAE CD32 pad anomally, as it happens rarely.

[UltraNarwhal]

Originally Posted by foleyjo

Thanks how do I make it so it changes when fire is pressed and changes back when fire is released though?

Maybe using the Actor tab attack/on attack event, use the project tabs Commands on press/release. If that doesn't work you'll need variables and an on attack that runs an event with the If control1fire==Button_Down.

[foleyjo]

Thanks again UltraNarwhal you gave me enough to work it out.
On Attack I change to a different actor that has no movement speed. The animation for the directions performs the movement for firing the yoyo and the last frame calls the code to actually create a projectile that reaches a limit and then returns to the player.
I have a frame timer on the attack actor which checks to see if control1fire!=Button_down and if true it returns to the original actor.
Only problem I'm having now is that when it returns to the original actor the actor falls off the screen.

[earok]

Originally Posted by foleyjo

Thanks again UltraNarwhal you gave me enough to work it out.
On Attack I change to a different actor that has no movement speed. The animation for the directions performs the movement for firing the yoyo and the last frame calls the code to actually create a projectile that reaches a limit and then returns to the player.
I have a frame timer on the attack actor which checks to see if control1fire!=Button_down and if true it returns to the original actor.
Only problem I'm having now is that when it returns to the original actor the actor falls off the screen.

Hey FoleyJo, glad you're making progress with UltraNarwhal's help!

I'm not 100% sure of the cause of the original actor falling off screen, but if the collision box isn't perfectly aligned between two different actors, it could cause unexpected issues with collisions.

---

Latest experimental update:

- Fixed bug reported on the discord, when using autofire it would play an idle animation between shots. To be honest I'm not sure why I added the lines that broke autofire animation (basically preventing the re-trigger of an animation that was already playing), but if anything relates to animation suddenly breaks, please let me know.

- Editor improvement, the "notes" column about variables will show in popups.

- Number of copper instructions (for the last generated game display) are reported on exit. This can be used for optimizing the copper list for memory and performance reasons.

- ECS Border Blank is back.. kind of. It's now a variable you can turn on which will enable that ECS/AGA only feature, and will reduce the size of a copperlist if it can (and you can quantify the difference using the feature above). But it's one of those things you should only use when you really know what you're doing - I wouldn't recommend using it in builds aimed at OCS computers, or even non-emulated Amigas (when running on a real Amiga, you may experience an issue where part of the border is distractingly darker than other parts)

[amigaosx]

Originally Posted by earok

- Fixed bug reported on the discord, when using autofire it would play an idle animation between shots. To be honest I'm not sure why I added the lines that broke autofire animation (basically preventing the re-trigger of an animation that was already playing), but if anything relates to animation suddenly breaks, please let me know.

That was me! thank you! it's working now, but I think it broke something with animation frames. Now the shooting anim just stays on frame 1, my shooting animation has 2 frames looping on frame 1.

[earok]

Originally Posted by amigaosx

That was me! thank you! it's working now, but I think it broke something with animation frames. Now the shooting anim just stays on frame 1, my shooting animation has 2 frames looping on frame 1.

That makes sense. I had bit more of a think about it and I -think- the latest check in should permanently resolve it.

---

Latest experimental update:

- Some minor fixes for performance when rendering maps in the map tab (still needs an overhaul to make it faster)

- Reworked animations a little more. Reverted the animation fix from the last check in, but added some fixes so an idle frame shouldn't trigger when autofire is held down.

- Fixed minor issue where the attack delay setting was inaccurate by a single frame

- "Actor_FrameDelay" (etc) is now exposed to codeblocks. This is just how many game frames are left until the animation frame is expired and the next one triggers. A possible use case would be, if you've got a single frame animation that destroys the actor when the animation is finished, you could shorten or lengthen the amount of time until that happens.

- "Actor_AttackDelay" (etc) is now exposed to codeblocks. This only really works with player types, it's the number of frames until the player can attack again. You could maybe use this to extend or shorten the length of time until the player can attack again if you need to.

[amigaosx]

Originally Posted by earok

That makes sense. I had bit more of a think about it and I -think- the latest check in should permanently resolve it.

Excellent! Working here! thank you!

[earok]

Originally Posted by amigaosx

Excellent! Working here! thank you!

Great! Glad to hear it.

---

Latest experimental update sponsored by BitBeamCannon!

There's a new "find references" button on the actor tab. With that, you can quickly find all references in code to a specific actor - it'll show a pop-up box with all codeblocks that refer to the actor in one form or another. Selecting the entry will open the codeblock in question, and highlight all of the lines that refer to that actor.

Note that it uses the "Description" line on the codeblock tab to find the references. So, for example, if you had a comment that mentioned the actor type, it would be highlighted.

It's only the first revision so there may be some unexpected complications. Also it's a framework that could be expanded in future (for example, to find which levels contain a specific block, or which actors have a specific animation)

[acidbottle]

Fantastic stuff earok. Love all these quality of life improvements, the copy/paste addition for one has saved so much time. Anything that helps cross reference one part of the project with another is absolutely superb and supremely helpful!

I think there is so much redundant stuff in my code but am half afraid to delete it sometimes in case it causes an unexpected issue

[merman]

Issue 236 of Retro Gamer will have a feature on the Scorpion Engine...

[acidbottle]

Originally Posted by merman

Issue 236 of Retro Gamer will have a feature on the Scorpion Engine...

That's great to hear, despite its exposure in the Amiga community, would be great to see SE hit a large and broader audience, especially as it can compile to other formats to.

[earok]

Cheers merman and acidbottle! I've made a note to import a copy here.

---

Latest experimental update is a fairly substantial one:

- Fixed various bugs found with platforming (in particular, the "IsOnPlatform" variable being set when the head of a platformer character collides upwards with something)

- "Find References" button in actor tab expanded to find map references (so it'll tell you which maps have the specific actor, and at which specific tile).

- The "Play Sound" feature has been expanded to allow playback at any specific period. Period's a little hard to explain, it's kind of the inverse of frequency but it's a number that gets plugged straight into the Paula chip. If a sample is imported at 11025hz, it'll play back at about note F2 by default. You can select a note from the dropdown list or enter any period number you wish if you need super fine grained control.

(Note that, normally a sound won't trigger while that sound was already playing, but changing the period will allow the sound to be retriggered immediately).

(Also note that changing a sound's period will make that the default period if you play the sound again without specifying a period)

- Not well tested, but the new "LastSoundPlayedFrames" variable contains how many frames the last sound will take to play. So that can be used by chaining yields or waits together e.g. something like

Play Sound sample1
Yield for "LastSoundPlayed" frames
Play Sound sample2

- New "tone" sample has a musical keyboard that you can walk across, demonstrating the new "Period" feature.

(Edit: Forgot to mention, the new sound features are sponsored by BitBeamCannon)

[earok]

Latest experimental update's another fairly big one:

- Fixed a few bugs relating to period (in particular, leaving period as 0 should just leave the period alone and not cause a glitch!)

- A few tweaks to level loading that hopefully don't break anything (might be slightly faster compiling)

- The big feature is the ability to load the background for a different level at run time. There are a whole lot of caveats to be aware of:

* It'll always take a second or two to load the next background (I'll think about a solution to this)
* Swapping parallax displays will be glitchy (though it seems just swapping copper skies will cause no glitches. Might be possible to do something like swap between copper and parallax without glitches). If you really need to swap parallax at runtime, I'd recommend doing so in a "cave" where the parallax is entirely covered by tiles.
* Memory usage overall may be higher (since the parallax graphics and level graphics are counted separately now, the overall memory needed will be the size of the largest parallax AND the largest level graphics together)

[foleyjo]

Is it possible to make a platform on half a tile rather than the full tile?
I have a block which is smaller than the full tile and I want to use it as a platform but when I add the platform property to the blockit acts as though the whole tile is a platform not just the bottom half.

The tile is transparent and I tried adding a collision box in tile editor.

[UltraNarwhal]

Originally Posted by foleyjo

Is it possible to make a platform on half a tile rather than the full tile?
I have a block which is smaller than the full tile and I want to use it as a platform but when I add the platform property to the blockit acts as though the whole tile is a platform not just the bottom half.

The tile is transparent and I tried adding a collision box in tile editor.

Not with a tile, you need to use a block. Draw a block with transparent and single colour filing in bottom 16x8 section, tick IsSlope/IsInvisible/Replace TileProperties.

[foleyjo]

Thank you UltraNarwhal.

I was wondering if this was the best place to request advice or if there is somewhere else people use where some of my qiestions have already been answered?