Scorpion Engine

[earok]

Latest experimental:

* Fix for bug reported by Mixel wherein sometimes level loading wouldn't work (not totally sure it's fixed this in every situation)

* Fix for bug reported by Mixel wherein UI elements would blink repeatedly on the talkpad

* Some minor tidyups/optimisations related to codeblock compilation

[earok]

Latest experimental is sponsored by BitBeamCannon:

Mega Drive target now outputs a ROM that slide-shows through all of the panels in the project (assuming the panel isn't so detailed and rich in color that it can't be adapted to the Mega Drive palette - if it gives you that error, reducing to 16 colors will almost definitely make it work).

While this is far short of being able to actually produce a Mega Drive game with Scorpion (though slideshows are perfectly viable if you want to do that!), it is a major step towards it - in particular, the problems with embedding the "cartridge.se" file into a ROM have been solved.

---

Emergency check in, issue reported by Mixel with the engine not working at all.

I'm still working out a few kinks with compiling the Amiga and Mega Drive versions of Scorpion, what I think happened is I might have accidentally compiled the Amiga version with the Mega Drive source, whoops.

[earok]

Latest updates and fixes:

- Fix for bug reported by Mixel wherein level load would crash under certain circumstances

- New feature - Ability to change the value of IsNTSC (and thus, force an Amiga into NTSC or PAL mode). Note that this will likely only work on ECS and above Amigas

- New "processor" variable returns the Amiga. It's possible to do things like, for example, "if processor > m68020 then goto 030fx".

It has been pointed out to me that processor may be misleading as someone could have a processor that may appear to be a 68000 so far as the system is concerned, but is massively accelerated, so use carefully.

Also, while I know what the values will be for 68000-68040, what the value will be on an 68060 or a vampire is a mystery to me.

- Similarly, the new "kickstart" variable returns the kickstart version (for example, if the variable is 34, this means that kickstart 1.3 is installed)

- Uses latest licence keys posted on Patreon

[domkid]

[ Show youtube player ]
new final release,
new splash screen, menu, credits
fixes, enhancements and more...
coming soon on: z-team.itch.io/maria-renards-revenge

[vulture]

@domkid

Great news!

[nikosidis]

@domkid

That is a fantastic looking game!
Looking forward to the release.

[earok]

Looking great @domkid !

---

Latest experimental just brings an upgrade to the Foreach command.

Previously, you could only filter it by actor type - now you can filter it by any actor variable (tag, var, lookdir etc etc)

[earok]

Latest experimental:

- Fix for bug where "else" wasn't showing correctly in codeblocks.

- New "line of sight" demo where an enemy will only pursue the player if it can see it. The logic is in a single codeblock that could be copied and adapted into a different project. It basically just does a raycast between the actor and the player.

Note that this could be conceivably quite slow, so doing it every second or so might be better than every single frame.

---

I hope that demo is of some use @Lemming880!

[Lemming880]

Interesting. Will check it out soon. Thanks.

[earok]

Latest experimental

- Fixed bug where initial load of editor could be slow (hopefully this is the same issue that Flibble had)

- Some fairly major progress on the Mega Drive version, particularly to do with panels, codeblocks and input (video below explains everything)

- This includes some minor changes to the Amiga version as well (bringing the code for the two versions more closely together to make it easier to maintain both). Hopefully this hasn't resulted in serious bugs.

[ Show youtube player ]

[earok]

Latest experimental:

- Fix for crash on startup reported by Mixel (for games with large codeblocks)

- Update for build log: the memory size of each individual codeblock is listed (could be useful for finding opportunities for squeezing out a few more bytes of slow ram)

I'm still feeling a bit exhausted after the Mega Drive stuff on the weekend, I may be a bit slow on major updates for a bit.

[earok]

Latest experimental:

- Bug reported by Raptor games: Spawning an actor within a Foreach loop could cause a crash (essentially by extending the Foreach loop forever, with each new actor also running the Foreach code and spawning a new actor).

- Bug reported by BasementApe: Dice rolls not working at all.

- Renamed "AGA Sprite Double" to "AGA Sprite Screen Wrap". This had been a point of confusion for several users but I think it was Flibble that originally asked for a fix.

- Fix for issue reported by Lemming 880: Jumping while there's no room to jump (low ceiling) no longer triggers the jump animation. Should still trigger logic where (for example) if there's a block above that breaks if it detect a collision with the player moving upwards.

- Did some work on platform actors to try and solve some issues by Lemming 880 where (for example) the player's feet position didn't sit perfectly on the platform actor's collision box. I'm hoping this doesn't break anything elsewhere because it does also slightly tweak platforming mechanics.

(Previously, if an actor walked off an edge, it'd instantly move down a whole pixel. Now it only moves down the minimum amount on that frame, far less than a full pixel. To me it makes more sense this way but I'm hoping it doesn't break any custom logic that relied on that quirk being there).

I've only tested on a couple of projects, it's not tested extensively.

[Lemming880]

Thanks for the fixes earok. Not having a jump animation when a solid tile is directly above the player is something I wanted for a long time.

The platform collision box doesn't need to be 1 pixel higher anymore. Also walking from platform to 'land' (solid tile) seems to work smooth. But I need to test this some more. I did notice that when the player is standing half way over the edge of the platform, and it reaches land, then even though the player is above land, it still gets pushed back on to the platform. But this is probably by design and the other choice would be to have the platform push the player to land. But because it gets pushed back it's probably the reason why sometimes when you start walking right before the platform bumps to land, the players seems to get pushed back a bit. So I always start walking a bit sooner before the platform bumps to land.

Your chase code almost works. I changed the first line from stop moving to resume moving because the actor should resume patrol when it doesn't see the player. But one thing doesn't work right. It's a walking actor but when chase is active it flies. It should stay on the ground and only be able to jump. The actor is cpu_platform but I think the last line "Set direction for Actor to move_atplayer" makes it fly? In a top down game this would be considered as walking but in a platform game it's flying. ;]

Edit. I think the platform works fine actually. After much walking back and forth from platform to land I didn't fall off unless it was my own mistake.

[earok]

@lemming880 I think with the chase thing, you may need to use separate actor types and swap between them depending on whether they can see the player or not. That should more or less be compatible with the demo I did (swap out the "stop/start" code for set type)

Hadn't ever thought about platforms being able to "drop" the player off on to solid ground, I may need to come back to it.

---

Latest check in resolves another bug reported by @RaptorGames where Foreach could cause an infinite loop.

The new A500 "big ship" demo is there demonstrating how massive actors can be rendered without slowing the game to a crawl (using the existing 'no clearing' features and the new 'maskless blit' and 'drawclipbottom' features), but I'm not fully happy with the demo and I need to do a video explaining how it works.



Edit: Emergency check in for Mixel, asset bundles were almost entirely broken. Whoops!

[Mixel]

Curious about that massive actor.. I wonder how massive an actor can be before it stops working?

Thanks for that fix I’ll check it out v soon!

[earok]

In theory actors can be absurdly massive because Scorpion will clip the edges to remain in the bitmaps, though in practice.. I'm not totally sure, especially if there's byte-size variables involved somewhere that'll mess things up once they become larger than 128 or 256 pixels wide or tall. (though the ship is about 256 pixels wide).

Edit: I hadn't considered that there's a maximum blit size, definitely nothing wider than 1024 pixels and taller than (1024 / bitplanes) pixels would be possible.

Did two emergency check-ins: one for Basement ape to (hopefully) fix bug where animations are orientated backwards, another for Mixel to fix a bug with the auto-upgrade of the "foreach" functions to the new setup.

[Lemming880]

Erm.. now some of my bosses are facing backwards. One of them is doing a very good moonwalk actually.

I've seen before that an actor is not facing the right direction but it rarely happens. For instance in my game the small walking enemy should turn around and walk towards you when you shoot it. But sometimes only the animation faces you but the enemy keeps walking away so it looks like it's walking backwards.


Something else. Quit goes to wb on A1200 but on A500 the wb screen is scrambled. Is it because I use endrun?

[earok]

There's some bugs in experimental I'll need to find and iron out - the 'facing the wrong direction' bug may be editor rather than engine (I've had some reports that certain animations are actually facing the wrong way in the editor when viewed in the actor tab, but I don't have any examples of this)


EndRun closes the CLI to recover as much memory as possible (without totally shutting down the OS so it can still use system friendly loading). I'm not sure if it's possible to actually start it again afterwards.


---

Edit: Latest experimental check in.

- Errors are reported if attempting to compile a game where there are images missing from an animation (with the latest blitter setup, having images missing entirely could cause visual artefacts - but you can still use [ blank ] in animations if you need an invisible frame)

- Poll request: search filters. These are now on animation, actors, blocks and code tabs.

I might call a feature freeze at this point and work towards getting it stable for the 2023.0 public release. There's still some potential issues to be investigated.

Edit: Another check in

Resolves issue reported by @RaptorGames in which moving platforms cannot trigger "on collide with player" events anymore, as recent bug fixes meant that the players no longer physically overlap with the moving platforms underneath them.

As a slight aside - it is possible to detect player -> actor collisions using the "on platform landed" event on the player itself. This is maybe something I'll change in future to be more intuitive, but when such an event is triggered, the "projectile" variables point to the platform that was collided with.

(The reason why you might want to detect collisions using "on platform landed" rather than "on collide with player" is the former is only triggered on the first time a platform is touched, the later will be every frame)

[earok]

Latest experimental:

- Some improvements to compiling the project data, your mileage will vary but with my test program I shaved around 20% off the size of disk and fast/slow memory needed for the project data.

Note that this is a major change so it could bring some breaking bugs, but it should be the last major change of 2023.0

- Various bug fixes for moving platforms in particular reducing instances of "shaking" when a player is riding a platform left or right at a speed of less than 1.

- Major revisions to the big boat demo, along with a YouTube demo explaining all of the tricks about how it works.

[ Show youtube player ]

[Lemming880]

@earok: Your tip worked. Actors are not backwards anymore after reloading a backup of the animations.