Scorpion Engine

[griffon]

I... think the transparent color doesn't count as hitbox in hardware. Not sure how SE handles it tho?

[earok]

Originally Posted by Mixel

Feature idea: optional extra collision squares on actors? Was thinking about “spread” projectiles like in Turrican’s multiple, given the sprites are screen height*, could lots of bullets be a single sprite, improving performance in comparison to a ton of little bullets, but that’d only work if the single sprite could have multiple collision boxes?

*I think?

Nb: this would be even more interesting if the various collision squares could have different codeblock calls?

Gunsmoke uses a single actor for two bullets when shooting straight upwards. On collision, it just works out if the enemy was closer to the left or right bullet (something like if actor_x - projectile_x > 0 is on right etc), then spawns a new bullet on one side.

That concept theoretically should be expandable to any number of bullets.

[acidbottle]

Just 1 real game breaking bug left in my project.

Upon hitting an enemy with a projectile, if I manage to hit and kill it, while at the same time the enemy hits the player, the game sorts of hangs in limbo with both characters dead!

its tricky to replicate but advice needed please

In the normal scenario, if either player or enemy dies first it continues just fine as it should.

[earok]

Originally Posted by griffon

I... think the transparent color doesn't count as hitbox in hardware. Not sure how SE handles it tho?

I've not yet implemented any support for bitplane/sprite collisions, it is a very cool feature of the Amiga hardware but in practice is somewhat unwieldly. All collisions in Scorpion are bounding boxes.

Originally Posted by acidbottle

Just 1 real game breaking bug left in my project.

Upon hitting an enemy with a projectile, if I manage to hit and kill it, while at the same time the enemy hits the player, the game sorts of hangs in limbo with both characters dead!

its tricky to replicate but advice needed please

In the normal scenario, if either player or enemy dies first it continues just fine as it should.

Oh, ouch haha. That is an awkward condition. I wouldn't know what to suggest without taking a look at the code. Being able to replicate it 100% of the time would help.

[Mixel]

Originally Posted by earok

Gunsmoke uses a single actor for two bullets when shooting straight upwards. On collision, it just works out if the enemy was closer to the left or right bullet (something like if actor_x - projectile_x > 0 is on right etc), then spawns a new bullet on one side.

That concept theoretically should be expandable to any number of bullets.

Oh of course! TY! I guess I could even check for set ranges and have it only do the visible collision stuff when hit by a certain chunks of the actor, so there can be gaps between them I just needed to think further outside the box again.

—
One thing I’ve noticed in CMOhn that might theoretically be similar to acidbottles issue, I have some timer loops that predate the level timer thingy, I find that if I yeild on the level timer, my older background timers just sort of.. stop?

[acidbottle]

You might be onto something there Mixel. I use a timer loop codeblock for the energy bar, this still ticks over when aforementioned bug occurs. It may be related ...

Thanks though earok, if I can figure out an easy way to replicate (spawn a tonne of wasps perhaps haha) I will send over for a look.

[UltraNarwhal]

Thanks Earok for the drive sound issue fix, seems to have banished it.

[Jack Burton]

Originally Posted by griffon

That's one of the very first problems I've encountered as well! It's easy to solve it, tho, go in the animation tab, and pick your attack animation, then tick "Prevent move" on the right side of SE. Now the character will stop in place when attacking

Thank you ! It works now !

You can use a different palette for every map! You can use setcolor if you want, but it's easier to use the "Set override Pal" button in the map tab, after you selected the relevant map.

Thanks ! I made some tests and it worked very well !

As for transparencies, alot of amiga programs don't handle that effectively. I use photoshop on windows (aseprite is great for that, as well), and just add a transparent color when saving pngs. The engine will do the rest and treat is as transparent without using extra colors.

Finally I could solve this transparency problem by exporting the sprites in .GIF format with the transparency enabled. But I still had to juggle with different programs.

I have to say tho, that black border on your sprites give the game a really nice retro feeling, like a spectrum game. I don't mind it at all, personally!

Yes, it gives this kind of 8bit retro feeling, it reminds me the MSX as well (the games that don't use HW sprites).

[Jack Burton]

Originally Posted by Mixel

grafx2 is free and supports iff and png.. On the amiga side PPaint supports png so you could load them from Brilliance in PPaint and convert them there if you liked, but ppaint doesnt have transparency either. https://libresprite.github.io libresprite is a free fork of Aseprite, which is what I use for most of my Windows/Mac pixel stuff. (Ideally suited for working with pngs with transparency)

Thanks. I downloaded Grafx2. I used it a long time ago (around 2002/2003) on my XP machine back then. I had completely forgotten about it.
On the other hand I didn't know libresprite. I'll try it since it seems well suited for this job.

it's complicated, but ramps are different to other types of block as they can have any height on each line of the 16 px.. They have a bunch of behaviours that make them work differently to platforms and solids though, but they can definitely be manipulated for certain staircases etc. you can't use them to make a half width wall, as such, but that could be achieved by clever use of (potentially invisible) actors in certain circumstances if you really had to have half thickness walls. "platforms" in my game (not solids) are all 8px high too, but obviously those can only appear in the top half of the 16px square..

I'll look if ramps can be of any help. Otherwise I'll look for another solution, maybe by adapting the level design...

that's looking great! I think you've probably got over the biggest hurdle now, once it clicks and you start getting how things are supposed to work, you just end up adding more and more stuff until you look back and wonder how the hell you did all that.

Anyway, as I've no experience with coding I think I will face some coding problems very soon. In fact it already started. I added an animation frame when the little green slime is hit by the player. It works, but I couldn't erase the slime sprite after a sword hit. If I use the command "Play slime_impact on Actor" it plays the animation, but if I add a second command line "Destroy Actor", it doesn't play the animation anymore and directly destroy the slime sprite instead.
I still have a long way to go...

[UltraNarwhal]

Originally Posted by Jack Burton

I added an animation frame when the little green slime is hit by the player. It works, but I couldn't erase the slime sprite after a sword hit. If I use the command "Play slime_impact on Actor" it plays the animation, but if I add a second command line "Destroy Actor", it doesn't play the animation anymore and directly destroy the slime sprite instead.

If you want it to play the animation and then destroy itself when finished, put the destroy actor bit in 'slime_impact on Actor' animations last frame and put tick for loop frame in the last frame.

[earok]

Originally Posted by Mixel

One thing I’ve noticed in CMOhn that might theoretically be similar to acidbottles issue, I have some timer loops that predate the level timer thingy, I find that if I yeild on the level timer, my older background timers just sort of.. stop?

The level itself is kind of like an actor with it's own "ontimer" loop. If you use the level ontimer function, and then yield on level, it overrides it. (similar to how yield on actor overrides the actor's ontimer function).

As an aside, if you use Yield on Actor but there's no actual actor (say if you run a yield on actor when there's no level loaded), it'll use the timer that the level typically uses. That could be confusing things too.

Originally Posted by UltraNarwhal

Thanks Earok for the drive sound issue fix, seems to have banished it.

Great! There's been another update for that issue, will detail below.

Originally Posted by Jack Burton

If I use the command "Play slime_impact on Actor" it plays the animation, but if I add a second command line "Destroy Actor", it doesn't play the animation anymore and directly destroy the slime sprite instead.
I still have a long way to go...

Lines in codeblocks typically execute immediately after each other, within the same frame if possible.

If you wanted a delay between the time that slime_impact runs, and the time it, I'd recommend setting "destroy_actor" as the "OnFinish" event on the animation itself (so the animation plays once before destroying the actor). You could alternatively use the command "base->yield on actor" to force the codeblock to pause temporarily.

----

Update to experimental:

- I changed the way top and bottom panels function a little bit. Since they're never removed from memory (only overwritten), if you unload a panel and reload it, it doesn't read from disk again. This should be a nice improvement to loading times if you typically only use one panel on top or bottom and just show and hide it.

- Scorpion will use longer delays when loading (in order to avoid Floppy disk loading during gameplay issues) when there's a file called FLOPPY (with more than 0 bytes) in the data folder. This file is generated automatically using EXE2ADF, and not generated when doing a typical compile.

I may need to document that somewhere, I figure 99% of people use EXE2ADF to generate their ADFs but if anyone manually makes their ADF for whatever reason, they'd need to know to add that file.

[earok]

Did another minor check in to experimental. It seems that 44K samples weren't working, they are now.

Really need to get 2022.1 official and publicly released so I can start working on some new major features for 2022.2. I'll do another round of testing on my sample games before announcing it publicly, but do let me know if there's any outstanding engine bugs you're aware of that should get fixed.

[domkid]

hello Earok,
since version 2022 and maybe before, I have an error message when compiling, z-team reported the problem and give you his gitlab, I think it comes from the events path, not sure, can you look at this please.

[earok]

Hi DomKid,

Apart from a bug in All Egypt having a bad tileset path (tried to push my commit when I fixed it but I don't have permissions), I didn't have any problems compiling on 2022.1. Without a way to replicate the bug on my computer, I can't solve the problem.



Edit: I have a feeling it could be something unusual to do with number formats and localization, I'll experiment a bit

[earok]

Experimental check in.

@DomKid my apologies, I didn't realize France had a different way of representing decimal numbers compared to English, I believe on your computer Scorpion Engine was trying to interpret the data in the French way whereas the data was actually stored in the map file in the English way.

In any case, the path bug should now be fixed.

---

Going on stream soon - https://www.twitch.tv/earok - nothing that exciting, just testing each of the sample games to make sure they're working OK before doing an official 2022.1 release

[domkid]

@Earok, great, thanks a lot, it works well now
sorry, for french computers

[saimon69]

Originally Posted by earok

Experimental check in.

@DomKid my apologies, I didn't realize France had a different way of representing decimal numbers compared to English

In any case, the path bug should now be fixed.

Most of Europe use . for thousands and , for decimals and THEN, U.S. use the reverse ^^

[coldacid]

Not just USA, Saimon69, essentially the entire English-speaking world.

[earok]

@domkid no worries at all! It's kind of my fault but I do blame C# for not forcing me to pick a localization scheme for parsing decimal numbers

---

Scorpion Engine 2022.1 is out

[ Show youtube player ]

In addition, I went on twitch earlier today. Mostly just tweaking demo projects. It's pretty rough but the video is here.

[ Show youtube player ]

I'll probably go on twitch again around 7PM UTC, maybe to work on a few miscellaneous Scorpion projects.

[gimbal]

Originally Posted by earok

@domkid no worries at all! It's kind of my fault but I do blame C# for not forcing me to pick a localization scheme for parsing decimal numbers

I don't really. A lot of C# (or Java, or whatever platform is your favorite) applications actually will stay on exactly one machine and then you just want to be able to rely on system defaults.