Scorpion Engine

[Lemming880]

I want my player to climb up a ladder by holding the jump button. But after setting the jump button to yspeed up, the player still won't go up. I have the following code:

(on ladder overlap)
If control1jump == button_down then..
Set Player yspeed to -1.5
End condition

My main player is 'control_platform'. When it overlaps a ladder it changes to a player with 'control'. It will move in all directions with the joystick/dpad. And when I let go it will stand still in that place. My guess is that the player actor 'control' is hard coded to speed 0 when it is idle. And when I press the jump button it wants to go up but the idle player says nope, it's speed 0 dude, and they keep fighting and nothing happens. So eh, does climbing up with the jump button need to be hard coded for player actor 'control', or is there another way, or no way at all?

[earok]

Latest experimental check in:

* Codeblocks 68K optimizations. Essentially replacing the MOVE.L, ADD.W and SUB.W commands with MOVEQ, ADDQ.W and SUBQ.W commands where appropriate. It shrunk the compiled codeblocks code for Amigo the Fox by 7%, and it might give a performance boost on games where custom scripting is used extensively.

* Ladder_NoSnap example updated for Lemming880. Essentially it's made so that, every frame, if jump is pressed, than the joystick direction is overridden to up. Hope that works for you!

(Edit: Second minor fix for the day that resolves further sprite stability issues reported by NEESO)

(Edit: Third minor fix for the day! Resolves bug where pasting codeblocks lines wouldn't trigger a save, reported by Raptor Games)

---

My retro hour interview is up. I haven't worked up the courage to listen to it yet just incase I made any dumb mistakes in the nervous state I was in when I recorded it, but anyway, here it is.

https://theretrohour.com/reinventing...h-earok-ep326/

[acidbottle]

Great podcast, must admit I haven't caught a retro hour one for a while. Some interesting earok history in there!

An issue has arisen on the latest experimental. On the project tab, unless I shift to the setting 0 pixels right, I get corrupt gfx glitch. Adjusting buffer width makes no difference.

Have started using the render mode blink in a new project, works like a charm, great addition that!

[earok]

Originally Posted by acidbottle

Great podcast, must admit I haven't caught a retro hour one for a while. Some interesting earok history in there!

An issue has arisen on the latest experimental. On the project tab, unless I shift to the setting 0 pixels right, I get corrupt gfx glitch. Adjusting buffer width makes no difference.

Have started using the render mode blink in a new project, works like a charm, great addition that!

Thanks for listening!

I'll need an example project with the issue to investigate.

[acidbottle]

Cheers earok, will sort something out over the weekend. I set the shift to 0 and it runs just fine, just the screen is not centered.

[Lemming880]

Originally Posted by earok

Ladder_NoSnap example updated. Essentially it's made so that, every frame, if jump is pressed, than the joystick direction is overridden to up. Hope that works for you!

Aha you placed it in the ontimer codeblock. Yup that works. Thanks!


Another thing. Occasionally, when level 1 is loaded, everything (like tiles, blocks and the player) is black except for the parallax background. Also the camera is placed to the left of the level and is stuck there, instead of following the player. It mostly happens when I boot the game and very quickly press play right after the menu is loaded. It's fixed when I go back to the menu and load level 1 again.

[earok]

Latest check in to experimental:

- Fix preventing compilation if "set variable" is pointing to a previously deleted variable
- Minor fix for NEESO: Actor tags are appropriately categorised in the large selection boxes as such
- Minor fix for Lemming880: Fix for loadlevel codeblock to ensure that the camera position is centered by default, even when a large camera box could mean that the center position has drifted on reload

[earok]

Latest experimental check in brings a new movement type sponsored by BitBeamCannon - cpu_parallaxlock

It's fundamentally a clone of cpu_cameralock (in that it's for actors that are locked to the screen). The difference is parallax lock can also be synchronized with parallax movement. We've used it here for the foreground stalactites, but more subtly for the antenna and satellite dish building tops in the far distance that overlap the cloud layer.

Note that this doesn't need to be tied to the OCS style parallax system. In fact, we're now using that movement type on the GothicVania demo to completely replace all of the complicated codeblock stuff used for parallax with that movement type. The far cloud that doesn't move is cpu_cameralock, the mountain layer is cpu_parallaxlock, it's that simple.

Also note that we did need some complicated codeblock stuff for the vertical position of those stalactites, but the horizontal movement is all taken care of by the new movement type.

[nikosidis]

Very, very nice. Love it!

[TCD]

Originally Posted by earok

Also note that we did need some complicated codeblock stuff for the vertical position of those stalactites, but the horizontal movement is all taken care of by the new movement type.

That looks very cool. I've been out of the loop for a bit, what's the name of that game?

[acidbottle]

What an outstanding update, love anything to do with parallax at the moment

I must ask, is there a way to keep an actor on the foreground parallax layer, and not have it scroll. I suspect there is but not worked out the logic for it as yet! As an example, having say, "Round 1" as an actor displayed at the bottom but moving with the screen.

I did work out what the issue was with the gfx glitch though earok. It was the top panel was hanging down a touch too far (was fine before said update) and so used the panel gap feature to make an extra line or 2. If i dont it does go screwy though so can still send the build over to look at in case it is a genuine bug.

[Mixel]

Daaamn Earok that’s amazing and great examples.. I was thinking like the blimp in SOTB etc but things like the bg aerials are much more useful examples. They go a long way to completely counteracting the repeating pattern.

Looking forward to tinkering with the AGA equivalent!

These are maybe not as useful to me on CMOhn ECS because my sprite channels are pretty much saturated with bones, blood and bullets.

Originally Posted by acidbottle

I must ask, is there a way to keep an actor on the foreground parallax layer, and not have it scroll. I suspect there is but not worked out the logic for it as yet! As an example, having say, "Round 1" as an actor displayed at the bottom but moving with the screen.

That sounds like CPU_CameraLock actor type? You put the Screen Xpos into Actor_Var4 and Ypos into Actor_var5 .. I use it for my floating boss healthbar.. It doesn’t need other logic, it’s just pinned to the screen. (I do wonder how much you can do with things pinned to the screen.. Lots of potential for weird behaviours by manipulating those two vars)

[acidbottle]

Originally Posted by Mixel

That sounds like CPU_CameraLock actor type? You put the Screen Xpos into Actor_Var4 and Ypos into Actor_var5 .. I use it for my floating boss healthbar.. It doesn’t need other logic, it’s just pinned to the screen. (I do wonder how much you can do with things pinned to the screen.. Lots of potential for weird behaviours by manipulating those two vars)

Well that was my thinking but no matter what layer I place the sprite on, it always ends up in the background behind literally everything else! Tried all the layers and same result. It does stay locked to camera tho!

[earok]

Originally Posted by acidbottle

Well that was my thinking but no matter what layer I place the sprite on, it always ends up in the background behind literally everything else! Tried all the layers and same result. It does stay locked to camera tho!

Add 500 or so to the zorder.

[acidbottle]

Unfortunately the zorder doesnt make any difference. The sprite parallax affects the cameralock in a way I cannot fathom!

[earok]

Originally Posted by acidbottle

Unfortunately the zorder doesnt make any difference. The sprite parallax affects the cameralock in a way I cannot fathom!

I might need to have a look at your project to work it out.

[earok]

I meant to bring this up ages ago - this Saturday there's an indie game event that I'm booked to appear at. I'm trying to get eight games in rotation divided across two devices (A CD32 and an A500 Mini, so the CD32 will have the parallax heavy games and the Mini will have ones that aren't).

https://techweek.co.nz/whats-on/prog...owcase-2022-3/

If we haven't already talked, and you've got a (relatively) polished and playable demo to ready to go, please get in touch.

[acidbottle]

Cheers earok, will sort something out

There was 1 other thing that is bugging me but will explain more when I am able to check it in for you to take a peek.

[gimbal]

Originally Posted by earok

I meant to bring this up ages ago - this Saturday there's an indie game event that I'm booked to appear at. I'm trying to get eight games in rotation divided across two devices (A CD32 and an A500 Mini, so the CD32 will have the parallax heavy games and the Mini will have ones that aren't).

https://techweek.co.nz/whats-on/prog...owcase-2022-3/

If we haven't already talked, and you've got a (relatively) polished and playable demo to ready to go, please get in touch.

That sounds cool, I hope there will be some video material of that event.

[earok]

@acidbottle sounds good!

@gimbal I'll post something here if there are any photos or videos etc.

---

Latest experimental check in brings a new memory saving feature: The ability to turn off 2X copper (which is on by default).

I'd only recommend turning it off if you're starving for chipram and absolutely need more. The reason why there are two copies of the copper list to begin with is for smooth transition between one copper list and the other when top and bottom panels are displayed (such as when there's dialogue). Basically, one copper list is displayed on screen while the other is regenerated, then they're swapped.

The reason why I wouldn't recommend turning it off (especially for games that frequently change panels or show dialogue) is because it could introduce split second visual glitches when the main game screen is resized (when top or bottom panels are loaded or unloaded). But over time I should be able to make it so that it'll be less glitchy when 2X copper is turned off.