Scorpion Engine

[Lemming880]

Sent. I hope you can find something.

[domkid]

Originally Posted by earok

@domkid I do need to do a proper ladder demo as part of the asset pack, there are ladders in Pitfall but that's admittedly that project is a bit odd since Pitfall has very non-standard platforming mechanics and it's not part of the "official" repo (can be found here - https://github.com/earok/unofficial-scorpion-demos ). In any case I hope you can work it out with your game.

ah yes, it would be nice a demo ladder... , I will look at Pitfall..., thanks,

[earok]

https://github.com/earok/scorpion-editor-experimental

Today's experimental check in is a substantial one:

Misc:

• Issue with sound appears to be fixed
• IsNTSC variable added to standard library
• It was accidentally possible to redefine a numeric value (eg, if you had a teleporter named "2" and it was the first teleporter in the game, it would redefine 2 as 1). This is no longer allowed.

Debug system updated (previous dumps are now invalid)

• Shows if dump was made on NTSC
• Game timer (how long, roughly, the game has been running for excluding loading times)
• Last sound played
• Decompiled code (easier to read in debug.log than debug.json)

Change to acceleration behavior in editor, hopefully this doesn't break any existing games but should be easy to fix if it does. Previously setting an acceleration of '0' would result in an instant acceleration to top speed, now it prevents acceleration at all.

In short:

• Set the value to 0 if you don't want acceleration to work at all (useful for custom behaviour where you want to manually control the player's speed in codeblocks)
• Set the value above 0 if you want acceleration
• Leave the value blank if you don't care about acceleration and want the actor to always move at full screen

New "EventsToCheck" variable (can be set in the Level section of codeblocks). Defaults to 1.

Increasing this number will decrease the "reaction" time of events but slow down the game, it's up to you to work out the right balance. The value is capped by the actual events in the level (eg, if there's 10 events in the level and you've set the value to 1000, it'll only check those ten events once per frame at most)

[earok]

Another check in for today! There was a few things I wanted to add, so I've gone ahead and done them:

* Fixed issue where using "player_animation" etc in conditionals didn't always work (eg you can now do "if actor_animation == actorwalking" if you wanted to check what animation is currently on the actor). Requested by NEESO.

* Added OnTimer events to levels. Works the same as setting it on an actor, this is mostly for if you've got custom logic you want to run in the background (say, a time limit countdown), and it can be different per level. (It's slightly easier and more efficient to do this than to create an actor just to handle level logic)

* Debug info upgraded to show both the current animation on actors, and any upcoming OnTimer events (again, old debug dumps are no longer compatible)

[Lemming880]

Originally Posted by earok

It was accidentally possible to redefine a numeric value (eg, if you had a teleporter named "2" and it was the first teleporter in the game, it would redefine 2 as 1). This is no longer allowed.

Wow you saved my project! Who would have thought teleport numbers would interfere with actor variables. Glad it's fixed, thanks a lot!

Found some new small issues in this latest experimental:

-Some projectiles stay put where they spawn (turrets, first boss). Some other projectiles still work (player, other bosses). It seems projectiles that have 4 way speed stopped working and projectiles with only left and right speed still work.
-When a small enemy dies it should change to a coin actor but it doesn't.
-When the player dies it should change to a player death actor but it doesn't.

[acidbottle]

Amazing updates, really appreciate you looking at the acceleration behaviors. Debug feature is going to save a lot of time when troubleshooting to

[earok]

Thanks guys!

@Lemming880: Re projectiles, if the acceleration setting is at 0 on any direction, just delete that so it's a blank box. If that doesn't work, please let me know. I may need to have a look at your latest project again about those other issues.

[earok]

Check in for the day. No updates to editor or engine, there's a new official ladder demo.

https://github.com/earok/scorpion-editor-experimental

It feels fairly solid to me but I'm happy to look at fixing anything that doesn't feel right. Even for people that have already implemented ladders in their Scorpion games, hopefully the ideas in the demo might be of some use.



art via https://opengameart.org/content/a-pl...-in-the-forest

[Mixel]

Ahh excellent.. I find with the cmo ladders if the ladder it up against a wall on the right, I can sometimes walk off the ladder and through the wall.. it doesn’t apply to the left. I assume it’s to do with the alteration in width between walking/falling Francis and ladder Francisl.. I’m not at home atm but I wonder if that’s no longer an issue.

[domkid]

wow, Super earok, this is great, thank you so much,
it will really help us

[earok]

Cheers guys!

I've got something rather exciting to show. It's still in early stages, may be buggy, definitely could use some improvements to take into account acceleration, is sub-optimal and I still need a way to disable it if it's unwanted.

https://github.com/earok/scorpion-editor-experimental

This GIF was made with the previous version of Scorpion Engine. It's very clearly running on 25HZ mode.



Here's a GIF made with the current experimental version of Scorpion Engine. No code or options have been changed, and yet it runs much smoother.




It works using the the Battle Squadron trick - sprites and scrolling updates at 50HZ, while the rest of the game updates at 25HZ. It's entirely illusionary, in the middle of a two-frame sequence, the sprites are nudged by half their usual speed, along with the camera. Internally the game logic is still 25HZ.


The major caveat is it ONLY works for sprites (non-multiplexed). And that's how games using this trick tend to work - the player is a sprite, and since that's moving smoothly along with a smooth camera you usually don't notice the slower moving bob enemies that are still 25HZ.

(Edit: Just to be clear - the reason why you'd want a 25HZ mode that runs at a fake 50HZ is so that you can have twice as much "stuff" as you could normally have in 50HZ, but still have the scrolling and player movement at 50HZ)

[acidbottle]

Neat trick indeed, just the player itself needs to be a sprite then, if I am reading that correctly?

Noticed when I compile builds through scorpion into winuae, the outcome is very silky smooth. I was previously using amikit and scrolling feels janky using it.

Makes me cautious to be not testing on real hardware in case it behaves different again?

on a side note earok, the acceleration that has indeed fixed the "blocks" issue has indirectly caused some others. The character on the skateboard is now firing backwards (to the left), despite the actor's attack set to match direction (which is forwards or to the right). Is the solution here to generate a new actor when the control (or animation) is going left/slow with no attack, this then switches to forward when at default or faster speed?

Cheers!

The ladders thing has inspired me to look at another game idea to. The AI of the cpu might be an issue though. While you can create a path for enemies with no issue, the cpu_direct will look for a path to get at you. Will it follow the rules that if, say, a ladder was a direct route to you, it would use it or will it get stuck or glitch on scenery?

Sorry for the daft questions, its more interesting pondering ideas than work today (apologies to my clients, stuff will get done honest ...)

[earok]

No daft questions detected

- Yes, the player needs to be a sprite. Currently it'll smoothly move *any* sprite (multiplex copies excluded), though I'm not sure if I'll either change that to be just the player, or expand that to include the multiplexed copies too.

- I'd use entirely custom logic for throwing now since the skateboard uses custom logic. Make a codeblock for on-attack, shoot an axe from there and set the xspeed by setting xspeed on the "new" actor.

- AI would need to be entirely custom, codeblock driven for ladders, the pursuit/patrol types are designed just for top down games.

[earok]

Experimental check in for the day. Dante Mentes tested the sprite interpolation by stuffing Green Beret full of autosprites, and it broke pretty quickly. I've fixed that bug so hopefully sprite interpolation should be more solid now.

[acidbottle]

Thanks for clearing that up earok, custom codeblocks it is!

[Mixel]

Originally Posted by earok

Experimental check in for the day. Dante Mentes tested the sprite interpolation by stuffing Green Beret full of autosprites, and it broke pretty quickly. I've fixed that bug so hopefully sprite interpolation should be more solid now.

If I’m understanding correctly (can’t check for a few days) a game with 4 players who are all sprite based (wizonk) could benefit from this a lot? It has no scrolling.. but if they move around at 50hz even in the 25hz lowspec mode that’s be awesome.

[Lemming880]

Projectiles work again after changing 0 to blank. And thanks for the ladder demo. Is there a reason for using a combination of blocks and tiles? Does that run faster or something? I use blocks for both image and code. I actually want to make a ladder that uses only 1 block type and see if that's more efficient. I now have a ladder made of 3 block types which is quite laggy on A500. I've tested with 1 block as ladder (which was half broken but it worked) and the game was already faster.

But another factor slowed down the game even more on A500: animated waterfalls! Isn't it possible to use color cycling instead of "block cycling"? Someone told me color cycling should be more efficient.

And where should I put the 'eventsoncheck'. I've placed it in player spawn but it's hard to tell if it actually works. I've set it on 3 because there are never more then 3 events in the screen at once. But I'm not sure if that's how it works.

[earok]

Experimental check in. Some fixes and improvements to the interpolation system. It's also possible to turn it on or off in camera follow - you can enable or disable camera AND sprite interpolation separately depending on your needs. You may want one, the other, or both (eg, it'd be pointless having camera interpolation on a single screen game)

@Mixel I hadn't actually thought of Wizonk, indeed if you've got four players for sprites, running it in 25HZ with interpolation might allow you to have a lot more projectiles without noticeable slowdown on A500.


@Lemming880:

Re ladder: The way I've done it is faster.

It's like this: It doesn't matter how many tile layers you have, if you have a (non-block) tile ladder above a lot of background layers etc, they'll all be flattened down to a single visual tile that gets blitted with a single blit.

But having an visible block is going to be slower than an invisible block, since a visible block requires at least two blits (the underlying tile, and then the block itself).


Re: Color cycling, yes it's absolutely possible. There's a very rudimentary demo in the "RepairWare" demo (the rain on the cat level is controlled by color cycling). Though Mixel has done much more impressive stuff with storm effects on CMO:HX


Re: EventsOnCheck, only needs to be set once so may as well go in startup. Note that it doesn't check if events are on screen or not, the check is against all events in the entire level - so if you want a guaranteed instant event response, you'd want to set it to at least that number, though if you can wait a frame or two it might be OK to set it much lower. I tend to avoid using events in my own projects and just use invisible blocks if I can.

[domkid]

Just to announce the entry of the Z-TEAM (Domkid & Troudki) in amigamejam with a small video...
[ Show youtube player ]

[Mixel]

@domkid Exciting! Looking forward to seeing it up and running.

@lemming the way I’ve done colour cycling is by having a bunch of individual codeblocks for different palette variations and then attaching them to frames of animation on an invisible actor. So you can set the cycle speed etc there. then I’d have an invisible block that runs a restore palette codeblock when I want the colours restored. (I also put restorepalette in places like my player respawn codeblock) Not sure if this is the best way but it lets me do localised lighting effects.

Earok: wow that sounds super handy for wizonk then, woo! TY!