Scorpion Engine

[Mixel]

I think enemies being able to use platform actors is pretty new functionality? (If the actor is set to platform class) i think you might have to (?) swap the squid out for a cpu accelerate actor and have it become a platform actor when it reaches the bottom of its arc or something? (Do they all disappear “behind” the sea like in the second stage? You could also theoretically have an invisible actor or block firing them as a cpu accelerate projectile upwards on a timer? That’d be the most efficient, maybe.)

Hmm this has made me realise I can make my jumping fish behave much better too, I’ve had them appear between platforms to stop them from landing on those.. they currently climb entire levels if I set it up wrong.

[acidbottle]

Cheers Mixel for confirming, thought I would have noticed the issue by now if it was always this way!

The idea of an invisible actor shooting the squids up is perhaps the easiest fix, this will require a couple more sprites and have used up all 256 slots in the sprite bank somehow

Hopefully, a few sprites may be redundant though so can at least try it out.

[Mixel]

Originally Posted by acidbottle

Cheers Mixel for confirming, thought I would have noticed the issue by now if it was always this way!

The idea of an invisible actor shooting the squids up is perhaps the easiest fix, this will require a couple more sprites and have used up all 256 slots in the sprite bank somehow

Hopefully, a few sprites may be redundant though so can at least try it out.

You mean the actor grid thing? I didn’t think there was a limit on sprites? I hope there isn’t or I’m going to run into issues, haha! If you have actors (or projectiles, or probably most importantly blocks) that you don’t ever place directly on the map in Tiled you can set their tileID to -1 and they won’t use up slots. I occasionally have to go through and clean out the things that I spawn from codeblocks.

[acidbottle]

Originally Posted by Mixel

You mean the actor grid thing? I didn’t think there was a limit on sprites? I hope there isn’t or I’m going to run into issues, haha! If you have actors (or projectiles, or probably most importantly blocks) that you don’t ever place directly on the map in Tiled you can set their tileID to -1 and they won’t use up slots. I occasionally have to go through and clean out the things that I spawn from codeblocks.

Well that's my new knowledge for the day, never knew that, many thanks for the tip!! Have a handful, at least, that spawn in from codeblocks.

I literally have no idea if 256 is the maximum but the grid is 256 spaces and assumed you couldn't put one on ID 257 ...

[earok]

Latest experimental:

* Performance - the YIELD command has now been converted into 68K, so games that heavily use YIELD should see some minor performance gains.

* Fix - Rather than crashing if a YIELD was used following a GOSUB (the two commands are incompatible since a YIELD won't know where to return to if it's after a GOSUB), compile is prevented with a suggested fix to either use GOTO or INLINE.

* Feature - Importing sprite sheets now has a scale feature to allow all images in the sheet to be scaled up or down uniformly.

The scale feature could definitely be improved, it's based on RotSprite but with my own tweaks. I've posted the source code for the library to https://github.com/earok/DotNetScalingExtensions



---

@AcidBottle Sorry I missed all the messages! Thanks for jumping in @Mixel

[domkid]

Great last experimental,

[acidbottle]

As a feature request, we already have Scorpion able to detect AGA chipsets. Could the same idea be achievable with cpu speeds also? I know its a bit niche but whilst Wboy will run on OCS, it is looking like, at present, only 14mhz or better cpu. I would rather the game did not run at all than run poorly on lower powered systems

[earok]

Cheers @Domkid

@Acidbottle Even if I put some detection in for the model of 68000, that might not work so well - an accelerator might present itself as a 68000 even if it's massively faster, the addition of Fast Ram may make the game run smooth enough on 68000, and so on.

I feel like there's lots of opportunities for improving the performance of Wonderboy, here's a few random ideas:

* Using hardware sprites
* Looking at opportunities to turn static actors like fruit into blocks or animated blocks
* Using tricks for turning off background clearing (Mike and I are using that on ScorpionBoy to have a massive boss that smoothly moves back and forth over the background - though since your boss animations would already fit in a sprite, anything complicated like that might not be necessary)
* Using the platform assets function to create a "lighter" version for A500,
* Putting it in a 25HZ mode with camera and sprite tweening so the player and camera still moves at 50HZ
* Trimming to 16 pixels where possible (I noticed the animation for Tom is 17 pixels wide, simply trimming one pixel off his hair so it can be shrunk to 16 pixels wide would result in an blit that's twice as fast, or something that only uses 2 sprite channels instead of 4)

[earok]

Just some news about streaming:

Two new VODs of previous streams are up on YouTube.

AlarCity with Tsak, where we primarily work on screen flash and camera shake effects.

[ Show youtube player ]

Robocop 2D (based on the Windows XP game by former AMOS game developers Park Productions) mainly work on aiming and shooting.

[ Show youtube player ]


The next stream is planned to be at about 9AM Thursday UK Time. The plan is for Mike Parent and myself to do an optimization pass on AcidBottle's Wonderboy, as well as (time permitting) do a little more work on our own collaboration with the working title Scorpion Boy.

[acidbottle]

Fantastic dev streams there, they are always a goldmine of information. Remember the early Scorpion Boy videos helped and inspired me to look at creating Wonderboy 3! Really appreciate you and Mike having a look at my code, will drop by for sure as soon as I am able to see what you make of it

[nikosidis]

Originally Posted by earok

Cheers @Domkid

@Acidbottle Even if I put some detection in for the model of 68000, that might not work so well - an accelerator might present itself as a 68000 even if it's massively faster, the addition of Fast Ram may make the game run smooth enough on 68000, and so on.

I feel like there's lots of opportunities for improving the performance of Wonderboy, here's a few random ideas:

* Using hardware sprites
* Looking at opportunities to turn static actors like fruit into blocks or animated blocks
* Using tricks for turning off background clearing (Mike and I are using that on ScorpionBoy to have a massive boss that smoothly moves back and forth over the background - though since your boss animations would already fit in a sprite, anything complicated like that might not be necessary)
* Using the platform assets function to create a "lighter" version for A500,
* Putting it in a 25HZ mode with camera and sprite tweening so the player and camera still moves at 50HZ
* Trimming to 16 pixels where possible (I noticed the animation for Tom is 17 pixels wide, simply trimming one pixel off his hair so it can be shrunk to 16 pixels wide would result in an blit that's twice as fast, or something that only uses 2 sprite channels instead of 4)

As the game run perfect on standard A1200 spec. I would vote against 25hz mode and other limiting factors that are not there now. At least make 2 versions For some original game to sell I would understand the importance to run on standard A500.

[earok]

@nikosidis I think the game now runs acceptably on A500 (assuming the expanded memory requirements are set). There are some slow downs in areas that are tricky to optimise (lots of large moving cloud platforms plus moving enemies that go behind the foreground waves on screen at once) but generally it feels pretty good.

---

Latest Twitch VOD is up (https://www.twitch.tv/videos/1604324213 - it should be on YouTube in the next day or two). Mike and I spent a couple of hours doing a bunch of experimental optimisations to Wonderboy. Some of them simple and straight forward (turning certain actors from bobs into hardware sprites), some of them pretty complex (turning off background clearing for example, which produces a "Winning at Windows solitaire" effect if an object is moving but is a decent speed up on anything that isn't moving). One particularly complex optisation we rolled back was turning off rendering after turning off clearing (so that the object is essentially "baked" into the background and does't need to be redrawn, but this messes up as soon as another object overlaps it, we found this optimisation a little too tricky to make glitchless especially in the short time on the stream).

Mike and I may do another pass at it, we didn't get a chance to do the optimisation to the moving clouds that we had intended to, we may attempt to do that as a side-task on a stream primarily focused on our own Scorpion Boy project.


Next Twitch stream is at 8PM UK time, approximately 16 hours from now. Tsak and I are going to be doing another development pass on AlarCity. I'll try to be a bit better at announcing these ahead of time going forward.

[nikosidis]

Originally Posted by earok

@nikosidis I think the game now runs acceptably on A500 (assuming the expanded memory requirements are set). There are some slow downs in areas that are tricky to optimise (lots of large moving cloud platforms plus moving enemies that go behind the foreground waves on screen at once) but generally it feels pretty good.

---

Latest Twitch VOD is up (https://www.twitch.tv/videos/1604324213 - it should be on YouTube in the next day or two). Mike and I spent a couple of hours doing a bunch of experimental optimisations to Wonderboy. Some of them simple and straight forward (turning certain actors from bobs into hardware sprites), some of them pretty complex (turning off background clearing for example, which produces a "Winning at Windows solitaire" effect if an object is moving but is a decent speed up on anything that isn't moving). One particularly complex optisation we rolled back was turning off rendering after turning off clearing (so that the object is essentially "baked" into the background and does't need to be redrawn, but this messes up as soon as another object overlaps it, we found this optimisation a little too tricky to make glitchless especially in the short time on the stream).

Mike and I may do another pass at it, we didn't get a chance to do the optimisation to the moving clouds that we had intended to, we may attempt to do that as a side-task on a stream primarily focused on our own Scorpion Boy project.


Next Twitch stream is at 8PM UK time, approximately 16 hours from now. Tsak and I are going to be doing another development pass on AlarCity. I'll try to be a bit better at announcing these ahead of time going forward.

That is fantastic!

What a great engine you are doing
What I was against was limiting factors. Back in the day it was normal to lock to bad fps to make games run on A500. Thankfully in the renaissance of the Amiga I do not think I seen anything other than true 50hz games. Not that 50hz matter in all type of games but it would in a game like Wonder Boy.

Today we have a very mixed audience. Maybe up to half of the Amiga users use emulation, at least now with the Amiga mini. I also have a feeling around 25% got some kind of acceleration on their Amiga. If they do not have accelerator it is quite cheap and easy to get. I totally love the open source project of the 68000/14MHz accelerator with 1MB RAM. That card run as fast as a standard A1200. This card can be had for around 50 Euro and is 99% compatible with old games, scene prods. and software.


As you optimize Scorpion Engine it is for the benefit of all. We already seen games run perfect on standard A500. I would still believe that standard A1200 spec. with OCS gfx is the sweet spot. That way you stay true to original hardware and there is no Amiga hardware that could not be upgraded to run the games perfect.



Keep on the fantastic work!

[nikosidis]

I'm watching some of the Wonder Boy optimization video you linked to.
Great stuff! for sure made the game run faster on A500 CPU spec.
As the game still require 2MB memory and at least 1MB chip a standard A500 is out of reach unless you do a chip mod. as I have done. I understand that a lot could be done from the beginning to bring down those requirements.
Great tutorial video!
The video series you are doing will be important for the future Scorpion Engine game developers.

[acidbottle]

My absolute gratitude goes out to Mike and Erik for having a poke around the WB project! Was just gutted I had to quickly leave halfway through, but it was extremely helpful. In particular I had not seen the disable_clear codeblock in practice.

@niko Alas, for the time being, a 1MB A500 will not run the game, as is. For it to run at all on an A500 is incredible and shows how far the engine has developed.

[nikosidis]

Originally Posted by acidbottle

My absolute gratitude goes out to Mike and Erik for having a poke around the WB project! Was just gutted I had to quickly leave halfway through, but it was extremely helpful. In particular I had not seen the disable_clear codeblock in practice.

@niko Alas, for the time being, a 1MB A500 will not run the game, as is. For it to run at all on an A500 is incredible and shows how far the engine has developed.

Very true!
Mike and Erik are true Diamonds to this community.

[earok]

Thanks guys!

Sorry for the slow rate of updates recently.

Latest experimental check in is some adjustments to the rotation behaviour for "control" movement types. I'm hoping it hasn't broken anything - the change was more or less to fix an issue in AlarCity where tapping in a different direction would only result in a partial rotation, rather than the full rotation you'd get from holding that direction.

[earok]

Another minor check in (I haven't had a lot of time lately but I figured a minor update would keep momentum going).

The "VAR" values on the actor tabs can be populated with constants, including the names of other actors, sounds, animations etc.

Say each enemy has it's own death animation. You could use var1 to store the name of the death animation, and then when an enemy dies you can just have a single codeblock like

play animation var1 on actor.

Instead of codeblocks for every kind of actor

Technically you could already do this inside codeblocks, but not inside the actor tab.

[acidbottle]

Nice little update that, cheers

Tsak mentioned possible considerations for dual playfield. Maybe worth putting it up for a vote next month! Still trying to get to grips with the sprite parallax but it did open up a lot of possibilities.

[earok]

Minor fix - the "set color" command was pretty broken and might have caused larger issues, that has now been fixed. Also, it's possible (I'm not totally sure) that the previously reported rotation fix wasn't the latest version, it should be now.

---

I'm hesitant about dual playfield for a lot of reasons. Some of them relate to the actual game output - the massive reduction in colors, DMA overhead of six bitplanes or eight on AGA, additional memory needs of entirely new buffers. Then there's complications about how to implement it (eg, if the dual playfield layer should be another level or just a bitmap, implementing features like per-line scrolling to have feature parity with the existing sprite parallax system, complications around implementing it in such a way it doesn't add overhead to non-dual-playfield games etc).

It may come some time in the future, for now I'd recommend RedPill for dual playfield games.