Scorpion Engine

[Mixel]

Originally Posted by Z-TEAM

Hello to all,
I'm doing some tests on the engine and I find the loading time between 2 maps a bit long (15s in real Amiga 600 to unload the current level and load next level). Does the loading time of the map depend on the number of tiles or other parameters like sprites,block,etc.. ?

Hi.

Hopefully I get this all right.. Sound, actors, blocks & animations are loaded on game startup.. Unless you've specified for the animations to only appear in one level they shouldn't load with level loads, so it sounds like it's maybe all just tiles (and copper backdrops).. But I haven't really had slow loading on CMO and that has huge levels. I wonder what's up there? I guess depending on what you're doing with loading music in the codeblocks, that might slow it down too?

Originally Posted by Lemming880

Does anyone else experience weird bugs after copy pasting stuff between levels in Tiled? I had copied a part of a map to another map and suddenly levers and hatches spawned at places they shouldn't. So I went back a backup. Some time later I tried copying a boss arena to another map and this time the levers kept working but it seems it caused that triggers respond slower. So often a lever isn't activated when you walk over it. Or teleporting has a delay. I also switched two levels. So I renamed level 2 to level 3 and vise versa. And of course I've changed all codeblocks that involve anything with "level=x". But now none of the events work anymore in both level 2 and 3. So my note to self is to not copy paste things between levels but I'm wondering if anyone else has this problem and possibly has a solution.

I've never had bugs quite like that, sorry.. I copy things between maps too.. Sorry if i'm wildly off the mark with suggestions..

Did you rename the maps with Scorpion or in windows? Could you have some sort of conflict between multiple copies of the actor or block lists somehow? I always copy an extant map with scopion or generate a new map with scorpion and tell it to edit from within scorpion from the maps tab, to generate the latest actors/blocks etc.. Early on, before I got used to how the file structure works I had a couple of cases where I accidentally was somehow using 2 block/actor lists in the same map.. Now I use Tiled's World (.atlas) feature, and navigating the maps, it makes it obvious if I'd accidentally somehow done that again as multiple "actors/blocks" tabs would appear. (I have no idea how i messed that up in the first place, haha)

What you're saying about logic running differently/more slowly etc sounds very odd though, i hope someone can figure out why, too.

[earok]

Experimental check in - fixed crash with Fade Out when guy dies in Mixel's CMO:HX. Not totally sure this all reported issues with Fade Out, but hopefully!

---

Welcome Z-Team! Regarding level loading times, there's two things that get loaded on the startup of a level:

- The level map data itself. Generally speaking, the larger a map is, the longer it'll take to load. There's some optimizations that need to be done at my side but currently making the map smaller is the only thing that would decrease loading times.

- The level graphics data. Likewise, the larger this is (in terms of how many colors, how many tiles are actually used on a map etc), the longer this will take to load. At some point I want to be able to bundle graphics data together (so if, for example, you had a game like Sonic, you could bundle all of the art in a zone together so going from level to level in the same zone should take less time).

---

@Lemming880 Apologies, I don't really have any idea what the problem could be with copy+pasting in tiled. Not sure if it'd be useful or not, but sometimes I use WinMerge to compare two copies of a file to see what the differences are, that can sometimes be handy to spot the cause of corruption.

[Lemming880]

Originally Posted by Mixel

Did you rename the maps with Scorpion or in windows?

Windows, but I went back a backup and did another test and renamed the maps through scorpion. Althought I don't see a difference since scorpion also opens a windows explorer window where I then rename the files. But I got the events to work this time. So last time I probably made a mistake with updating the codeblocks of the levers and checkpoints (although I would swear I had it right!). My bad. However there is still one checkpoint that refuses to work. I use "if block_x=" to give each checkpoint its own variable number. The checkpoint is on block_x 40. But it's not triggered by "if block_x=40", nor 41. It does work with 39 and 42. Strange, but I'm not sure if it's related to switching the maps. Or if it's a user mistake again.

I also went back to before copy/pasting the boss arena and events work normal again, no delay. So copy pasting between maps definitely caused something. In other situations I've also had the double blocks/actors list but it's not the case now. But I also think there must be something double which causes a delay. So for now I think I'll just rebuild things by hand just to be sure.

@Earok np I might give WinMerge a try.

Edit: I can confirm that renaming maps works fine. The first time I made a mistake in the codeblocks. And the checkpoint problem was already there before switching maps.

[earok]

Okay, experimental update - I DO expect this one to possibly have some breaking bugs, and may require some codeblocks changes (I had to do so with my own games).


Put simply: The behaviour before is that all actors had a check to make sure the animation playing matched the direction they were looking/moving in.

This has been changed so that the standard CPU type no longer has that check. This is for two reasons:

- The standard CPU type doesn't tend to change movement speed by itself, it can only do so through codeblocks or bouncing on a wall etc. It's a waste of cycles checking direction every frame.
- In order to allow a CPU to have an animation direction different to the direction they're actually moving in. This allows creation of enemies that can circle strafe the player (absolutely vital for top down shooters).

*But* this did mean that some codeblocks, including codeblocks I've written myself, were broken. Consider the random movement of the duck in Super Go Down The Hole, something like this:

roll dice with three sides
if dice == 0
   set actor_xspeed = -1
else if dice == 1
   set actor_xspeed = 1
else if dice == 2
   set actor_xspeed = 0
endif

This was broken because it told the duck to move without changing the direction. The duck would physically move left and right, but would appear to be walking on the spot or walking backwards. Fixing it was as simple as replacing the set actor_xspeed commands with setting the look direction.

[UltraNarwhal]

Originally Posted by earok

Okay, experimental update - I DO expect this one to possibly have some breaking bugs, and may require some codeblocks changes (I had to do so with my own games).


Put simply: The behaviour before is that all actors had a check to make sure the animation playing matched the direction they were looking/moving in.

This has been changed so that the standard CPU type no longer has that check. This is for two reasons:

- The standard CPU type doesn't tend to change movement speed by itself, it can only do so through codeblocks or bouncing on a wall etc. It's a waste of cycles checking direction every frame.
- In order to allow a CPU to have an animation direction different to the direction they're actually moving in. This allows creation of enemies that can circle strafe the player (absolutely vital for top down shooters).

I noticed this broke my invisible movement restrictor blocks, these on collision changed the actor lookdir to move_[dir]. Fixed by adding extra lines with a frame delay and then setting lookdir to look_[dir].

Cpu platform enemies, no longer face correct direction when hitting solids/the edge.

Example uploaded to my git.

[earok]

Daily check in:

- Bugs fixed for CPU_Platform (and the Stay-On-Platform collision type). Cheers @ultranarwall for a demonstration of the issue.

- Added a bit more "built in" documentation, now most of the selection boxes on the Actor tab have full explanations for exactly what they do (control types, class types, recycle types, wall collision types).

I was thinking about doing something similar for the codeblocks tab as well *but* I was a little concerned it might be frustrating to have pop-ups everywhere on that tab. I might be able to do some sort of hybrid where there's a help button you press to see what all of the options mean.

[domkid]

Yes, great idea And great work

[Mixel]

Odd bug, Max Entities (actor tab) seems broken now.. on my motorbike level the codeblock makes puffs of smoke, which I'd limited to 3, but now.. tons and tons of them appear and it slows it down a lot. (it's using a level/spawn on block command)

[earok]

Experimental update for the day:


I was never really happy with how MaxEntities worked so, along with tackling the issue Mixel reported, it's more or less rewritten from scratch.

Previously it'd be a little inconsistent about which actors it'd pick to 'destroy' in order to make room for new entities. Since the actor list is sorted by Z-depth, it'd generally pick the ones closest to the top of the screen, which is not altogether ideal. It's now been reworked so that the "oldest" actor (which is to say, the first one to be spawned) will be picked for deletion.

[Mixel]

Ah excellent thankyou! Killing the oldest entity sounds good, I hadn’t realised that wasn’t what was happening.

Not a help request but documenting something weird.. I’ve had some really odd behaviour in the last few updates but sometimes i fix it in ways I don’t understand..

It’s mostly to do with actor directions, like you said would happen, it’s just manifesting in some really unpredictable ways. (Slightly different behaviour depending on level, somehow?) like, my zombies spit works fine in some places but on one level shoot directly downwards and when they hit the player the player flies downwards through the floor, haha. I’ll try fixing them all today.

Ooh, new bug/behaviour.. What used to be the weather/flickering palette effect on the storm level is now a painful game staggering, fade to black repeatedly palette effect, as seen here (i didn't change anything)
[ Show youtube player ]
It's PaletteDarker, PaletteDarker2 and PaletteRestore codeblocks run from 4 frames of the "SeaCamera" animation (which is attached to the camerabug Actor that lives by the player)

it *looks* like it's not doing my palette stuff at all and it's just looping fade ins (and momentarily freezing).. Pretty odd. (if you needed to look at this you should be able to press "7" on the intro/anywhere in the game to teleport straight there)

It's definitely a new issue with adjusting colours in codeblocks.. Here's part of the game where the same thing is happening..


Ed 29th: Another new (i think?) bug.. I think it was working before anyway! Blocks that are flagged as both Solid and Platform (making them a platform you cant drop down through) - I can drop down through them currently by pressing down. Doesn't apply to tiles, just blocks.

Edit 30th: (sorry to just keep adding bugs to a single post, thought it better than just spamming the hell out of the thread, so you dont get a barrage of notifications! )
[ Show youtube player ] - The motorway level, and some other places, are weirdly buggy now.

I've set up the version on Git to start you in the school level. If you press down+fire you kick normally, until you collect a save point.. Which makes the control/collision logic go haywire.. kicking left slides the player to the right.. colliding with the zombies flings the player to the right.. Dying doesn't work anymore, it just sort of stops. Nothing in my "savepoint" or "spawnplace" codeblocks has anything like this, im suuuper confused.

eg: if you start, you kick normally, you collect one save point, you kick wrong and the collision is wrong.. you go right to pick up the key and the code/kicking starts working normally again, then you open the door and it goes wrong again.. Until you pick up a save icon and it breaks again...? XD lol. Did I just fail to end a condition somewhere and i keep getting hit by it at random seeming moments?

[earok]

Apologies for the slow response, I'll take a look at the various bugs in the next few days.

Did a minor fix for experimental today so that CPU_Pursuit_Direct can be stopped and started with the lookdir options (consistent with CPU_Pursuit)

[earok]

Minor experimental fix for the day - blocks should obey the rules for IsSolid and IsPlatform - so flagging them both means you can jump up through them but not fall down through them, flagging IsPlatform allows you to fall through them if you're holding the down direction, flagging IsSolid means you can't pass through in any way.

[acidbottle]

Nice updates earok.

Would it be possible for an actor to ignore block rules while the player follows them. For example, an enemy jumping through a platform or solid block but the player being unable to fall through?

[Mixel]

@earok Ahh thanks! And I hope you’re doing ok. I’m doing graphics mostly atm anyway, will look at logic again shortly..

That’s the rope bridges working properly though. Really like that addition to CPU_pursuit_direct too, that’s going to allow for some really interesting attack patterns!

@acidbottle: I'm not sure exactly what sort of enemy style you want to do it with but maybe switching between duplicate actors with different collision properties (and potentially animations depending on what's going on) with codeblocks would work for this? I have creatures that can pass through walls when flying but then land etc.. I thinkyou could do the same while jumping too (so they could jump through solid ceilings etc)

[acidbottle]

Cheers Mixel, that was definitely worth a shot.

I went and duplicated 1 of my animations and actors and set to no collisions. Using an older Scorpion revision and the latest build, setting block to platform only, was unable to move the actor back through the floor after jumping up through it.

It may be something I have to live with. To be honest, if that is the only drawback, it is still outstanding what can be achieved using logic and this engine!

[Mixel]

Originally Posted by acidbottle

Cheers Mixel, that was definitely worth a shot.
I went and duplicated 1 of my animations and actors and set to no collisions. Using an older Scorpion revision and the latest build, setting block to platform only, was unable to move the actor back through the floor after jumping up through it.

It may be something I have to live with. To be honest, if that is the only drawback, it is still outstanding what can be achieved using logic and this engine!

Ahh.. I think there’s still hope.. If it’s just jumping up/down you could use cpu_accelerate based on what Erik was saying about coins.. That wouldn’t interact with platforms at all, but I don’t entirely understand how to get it to arc nicely. But I think you can.

[domkid]

hello guys
a question, I would like to crawl my player to go under some blocks,
how do I crawl my player by pressing down and left/right (on control-platform) ...?

[Mixel]

Originally Posted by domkid

hello guys
a question, I would like to crawl my player to go under some blocks,
how do I crawl my player by pressing down and left/right (on control-platform) ...?

That sounds like it could work similar to how I have crouching in CMO.. I have two actors, one for ducking and one for standing..

I call a codeblock from the idle and run animation frames:


And on the frames of the ducking actor I call..


You can set the ducking actor to be slower, and have a smaller colbox etc.

I can't vouch for this working as my character is set to be stationary in the ducking state, but i think it should work?

[domkid]

@Mixel, thanks, ok I will try this...

[acidbottle]

You know Mixel, I made an error and forgot to set the actor's collision (had just done the anim) to none. The actors now indeed pass through blocks with no issue, which is fantastic. Alas the issue I had been left with is that I had to change the projectile from cpu_platform and thus losing the gravity aspect ... A straight and forward firing projectile doesnt work for me here ..

To be fair, hopefully only the hardcore will notice the enemies are not exactly where they should be Trouble is I think these kind of encounters will be more common during the course of the game, instead of the one occurrence in the first 4 levels. doh!