Scorpion Engine

[earok]

Daily check in:

- Fixed reported issue by Griffon above (missing line on Post_LevelLoad codeblock to kick off the level timer)

- Added support for bitwise and (&) and bitwise or (|) in codeblock expresssions.

- Made it so that, if you manually move the camera position, you can make it so that it doesn't disable camera follow (though this is still the default behaviour)

- Made an (untested) change to map compilation based on something Mixel pointed out on stream - block properties (solid, platform etc) are applied additively to the underlying tiles rather than replacing those properties (eg, a block that isn't a platform doesn't remove the platform property of an underlying tile)

For the life me I wasn't sure why it was additive to begin, and it wasn't consistent with how it worked when you changed blocks within codeblock commands, so now the block properties should completely replace the ones of the underlying tile. However, I may revert this if there's an absolutely compelling reason why it should go back to working the way it did.

- Various minor tweaks towards stripping down and streamlining the core engine, including reworking some of the codeblocks in the streamingassets folder. Hopefully not causing any bugs.

-----

Mixel also prompted me to think about a longstanding issue with the engine I hadn't really gotten around to providing a solution for. The pursuit direct and "look/move at player" commands aim towards the player's origin point (the "red cross" on the animation editor). On platformers, for the most part, the origin point is the player's feet and so projectiles using pursuit direct would aim at the player's feet.

It probably makes more sense to have it aim at the center of the player's collision box. Since these types are normally used for things like Heat Seeking rockets, it'd make the most sense if they were aiming right at the center point of the player so there's less chance it'd miss. A quirk of this change would also mean (for example) a player that ducks (and so has a shorter collision box) would adjust the projectile's trajectory downwards towards the player's new lower center.

Though I'm aware that (at least in Mixel's case) people have worked around this in ways that would likely be broken and require reworking after the change I've suggested. Please do let me know if the change I've suggested will cause a major headache, otherwise I'll implement in the next day or two.

[Mixel]

Wow! Thanks so much, these are big fixes.

I very much like the sound of the change to block/tile stacking behaviour. I hope it doesn't interfere with other peoples' games!

Aiming at the centre of collision box sounds good to me, I probably only need to adjust a couple of animations to accomadate that change and it'll stop everyone else from having to do what feels like quite a hacky work-around.. Would 8 directional actors set to look at the player also look at the player's centre point instead of the feet? I doubt anyone noticed but my wall-mounted eyeballs look like they have a foot fetish. I can imagine occasions where someone might specifically want it to lock onto an x/y0 coordinate too though, really I'm good with either way.

[earok]

It turned out not to be a difficult fix so I went ahead and did it and checked in, but it isn't extensively tested (I used CMOHX but couldn't notice any difference for the reason outlined at the bottom). Basically:

It affects three contexts:
- CPU_Pursuit_Direct movement type
- Actors that shoot directly at the player
- Manually pointing an actor at the player using LookDir in codeblocks


It uses the center point of BOTH the player's collision box and the actor's collision box (so it may continue to work as expected even if you've already manually adjusted the relative position of the actor and the actor's collision box)

[acidbottle]

Truly epic update that, do not think it will affect anything in my project but if so will report any strange anomalies

[Jack Burton]

I could make some progress on my project.

Thanks UltraNarwhal and earok for the advices. Now when the player hits other sprites the impact animation plays and then the sprite is destroyed. It works very well.

[ Show youtube player ]



Next, I would like to add a hit point system to the sprites. Eg, the bat needs 2 hits to be destroyed, slime needs 3 hits, rock needs 4 hits, etc. I guess that from that point, using variables will probably be mandatory ?
I tried to play with variables but it didn't work. Any help will be much appreciated.


I've some other questions too :

The player sprite is displayed behind the other sprites when they meet, is there a way to bring it to the front ?

How can I set a sprite to solid so that it can stop the player until it is destroyed (eg, in the case of the rock in front of the door).

Is is possible to disable the fadein/fadeout effect when changing levels ?

[earok]

@acidbottle cheers

---

@Jack Burton,

First up, well done for making the progress you have made!

Variables are the way to go, you'll want to use the "actor_var1" to "actor_var5" variables (these are relevant to the specific actor). On your melee collision hit you could do something like

if actor_var1 >= 0 ;Has health
actor_var1 - 1
else ;out of health
destroy_actor
endif

(Use the Actor tab to set the default var value of each of your enemies)

In regards to not fading out, this is untested but you could try setting the FadeTime (display command) to 1.


edit: Missed that there were two other questions:

- Try increasing the player's "ZOrder" in order to force it to render in the desired order (top right of actor tab)

- For the rock, I would create a "block" type rather than using an actor. Blocks are more suitable (both in performance and ease of use for collisions) for things that don't move much, you could still use an actor for the rock crumbling animation. For the melee hit on block you could do something like:

spawn "block break animation" on block
destroy block

[UltraNarwhal]

Originally Posted by earok

- Made an (untested) change to map compilation based on something Mixel pointed out on stream - block properties (solid, platform etc) are applied additively to the underlying tiles rather than replacing those properties (eg, a block that isn't a platform doesn't remove the platform property of an underlying tile)

For the life me I wasn't sure why it was additive to begin, and it wasn't consistent with how it worked when you changed blocks within codeblock commands, so now the block properties should completely replace the ones of the underlying tile. However, I may revert this if there's an absolutely compelling reason why it should go back to working the way it did.

This affects my game, I use blocks to prevent enemy movement in some places. They're overlayed over solid tiles and flip movement for enemies that don't have the same speed going left/right or up/down (speed doesn't set correctly if use solid bounce collision).

A reason to add back additive example: a platform game has non solid platforms on top of each other and collectable blocks overlay these platforms, now none of the platforms work.

Since the new boot copper logo I noticed level fading is a lot slower and doesn't look as nice, as it starts mid fade for a few seconds before starting.

[earok]

Check in for the day:

- Ongoing work towards stripping down the engine by removing redundant code and porting parts of it into codeblocks - Duckstroma seems to be less glitchy with the startup title sequence though I'm not totally sure it's as expected. It's around 7KB lighter than it was a week ago and I hope to keep going with it until the executable is a more reasonable size. There probably are going to be unexpected glitches pop up.

- Regarding the block properties thing, I thought about it a bit more and figured there was no reason why both scenarios couldn't be supported. So there's now a new "replaces tile properties" setting on blocks (by default is on). For consistency, also applies to blocks that are set within codeblocks using Set Block.

@UltraNarwhal hadn't really thought about bounce with actors that have different left/right or up/down speed. I could maybe look at making it so that there's a "deflect" collision type that simply sets the maximum speed in the opposite direction rather than inversing the current speed.

[Mixel]

^ That best of both worlds tile properties thing sounds amazing. Thanks for that. I was thinking about Narwhals examples above and realised the additive version would be much more useful in Wizonk than it would in CMO.. (i haven't touched wizonk in months so it's kinda broken atm i suspect!) Either approach being the only option would require some duplication of assets on one game or the other.. (when i made wizonk back when things weren't additive i had spawners with platforms embedded, etc.. I can get rid of those with the additive effects - wheras in cmo i made multiple copies of the same platform tile to get the right properties because the additive effect was interfering.. Now i need neither workaround!) Supporting both is really handy.

--
Very new, very weird bug.. i'll upload to git.. for some reason francis appears in the sky in a totally arbitrary place now oon the ship level.. its nowhere near his actor as placed on the map, and there's nothing in start_ship I can see that would cause it?

[earok]

Did a check in for ^ that bug, stripped out some more redundant engine code while I was at it (only 1KB to the exe size but every little bit reduces memory consumption, increases performance and makes the codebase easier to maintain).

Essentially the bug was, it was triggering the "out of screen" codeblocks before it had a chance to correctly place the camera in the level (so it was snapping the player to a camera set at position 0).

The fix (which IMO is sensible but hopefully doesn't cause any unexpected side effects) is now no actor logic will run while the screen is fully faded to black, that allows the camera to move to the correct place before the screen starts to fade in.

EDIT: I'm doing a deeper dive and finding a *lot* of bugs, but I'm also making progress with further streamlining of the engine. I'll do a proper test of each of the sample games before the next check in.

[earok]

Another experimental check in, fixed a bunch of bugs but no doubt there's a few remaining. There's also some new codeblocks (taking care of things that used to be done internally in Scorpion).

[Mixel]

Thinking about what I asked on stream re: an option for pursuit direct actors choosing between aiming for animation X0,Y0 and the colbox centre like you just implemented..

The child actor thing you suggested as a workaround.. for all the enemies I had planned to hover a little above the player I could use the same parent for all of them, so that’s pretty easy.

I’m just super confused by exactly how long I need to make it if I want it to haunt eg 150 px to the right of the player.. thinking specifically about the witch ghost now.. She, and a couple of other bosses I have planned are supposed to wave around to the side of the player, and considering it now goes to the calculated centre between the entities wouldn’t that mean have to have the parent with its colbox 300 to the right, which would knock it outside the screen entirely? Unless I misunderstand.

Thanks so much for the help on stream btw, and to everyone else too.

[earok]

@Mixel no worries. That was a hell of a stream!

I did a tweak to the player seeking code so that it only takes into account the player's collisionbox, it now uses the actor's center again (eg, the cross on the animation tab) so it should be easier to make enemies that float above the player's head and such. Though it's not tested.

---

Daily check in. A bit more of the core engine has been ripped out and migrated to codeblocks (particularly in the area of loading and unloading panels etc). I think it's reasonably stable now but please let me know if anything is obviously broken.

Hopefully with the ongoing conversion of core engine features to Scorpion, it'll mean that end users may be able to spot and fix core engine bugs, and possibly even customise core features if they really need fine grained control.

[acidbottle]

Is great to see you constantly striving to improve the core engine, these gains all add up.

However I am getting some severe top panel flicker, particularly through level transitions. Had a stutter or 2 during gameplay also. Was to be expected by the sounds of it so no worries other than that.

[griffon]

I don't know what the problem might be, but the very same project that compiled without issues with the previous release, now gives me the error "Cannot parse number 33000 outside of 16 bit range?" ....wut?

@earok It's on the usual github if you wanna check

[earok]

@acidbottle I might need to get a copy of your game, I can't explain that.

@griffon that's as expected. Scorpion handles 16 bit numbers (it only uses word length 68K operations) and the largest signed 16 bit number is 32767. It *is* a new error to prevent math operations that Scorpion can't handle.

[griffon]

Oh I see. I'm so used to unsigned number and 65535 as max number for 16 bit data that I didn't think about signed numbers limits. Guess I'll have to adapt the tables to fit that...

[earok]

@griffon ah, apologies about that!

I'm likely to stick with 16 bit for the foreseeable future. I do intend to add fractional number support sooner or later, which would technically bump that to 32 bit, but it'd still be limited to 32768 for positive numbers (since the bottom 16 bits would be reserved for the fractional portion).

---

Daily check in:

- Some fixes which *theoretically* might resolve issue reported by @AcidBottle, but I'm not totally certain it was the cause. In any case, please let me know if the issues remain!

- Added "jump height" field to actor. This is not 100% accurate but should be close enough to be useful (I found that if I told my actor to jump 80 pixels, it would jump a couple of pixels higher than that). Basically it overrides the gravity field when you edit it.

- Added a new "movement_jump" direction in set actor lookdir. This makes the actor jump at the actor's jump speed without overriding actor's x movement speed or looking direction.

- Vastly improved the memory guestimates in build.log to separate chipram from other ram.


---

I called in a favor from NEESO games, I was aware that he had made a full screen FMV demo (without using ANIM5) and I figured that might be useful reference if anyone needs a full screen FMV in their game. It's on the unofficial demos pack under "movie"

https://github.com/earok/unofficial-scorpion-demos

[griffon]

@earok no biggie, I just divided the tables by 10, and incase I'll just add a fake 0 to the panel. Same ol' tricks

The jump additions are very interesting and I'll definitely try them out asap!

Question about AND/OR operators that have been recently added... before I go and screw up my code entirely, do they work only in like bittest ifs and the like, or any condition of any kind? Thaks in advance!

[acidbottle]

Hey earok, using the latest build no levels load, black screen of death after the start menu. Tried 4 or 5 different levels to to make sure it wasn't one in particular. I perhaps need to make an adjustment somewhere?

Last build I can use safely is the first one with tsak logo.