Scorpion Engine

[earok]

@UltraNarwhal not quite sure what the NTSC issue could be :/

---

Latest experimental of 2022.6 is up.

The spawning system has been completely reworked (essentially actors no longer spawn when the tiles they're standing on are blitted, but rather they're spawned when the "spawn area" around the camera overlaps their starting positions). I'm hoping that it doesn't cause performance issues, glitches or unexpected behavior but it may do. In any case, since this is only the first check in to experimental, I'll have plenty of time to iron out issues before public release.

A new feature (which resolves an issue reported by Raptor Games ) is the "spawning area" around the screen can be adjusted with four new variables:

Spawn_X
Spawn_Y
Spawn_Width
Spawn_Height

You may wish to tweak these if you're having issues where particularly large enemies "pop in" at the sides rather than being spawned entirely offscreen.

An example of the kind of issue the new system solves is below: The three enemies are horizontally aligned in the tilemap, but they're staggered in 2022.5 (top left). Fixed in 2022.6 (bottom left).

[flibble42]

@Earok


Looking interesting. Wonder if it will change the way my cars align in Spy..yeah that thing



While you are tinkering, any chance you can fix the teleport codeblock so it functions as it used to prior to the scroll speed change?

[earok]

Did a minor update to experimental - while trying to fix a different bug I came across an issue where deleted actors could be "recycled" (and therefore, potentially respawned). I didn't actually get around to fixing that original bug (some issues with actors being respawned repeatedly) but hopefully that will be fixed in the next day or two.

---

@flibble42 I'll definitely need more detail - what's broken in the teleport codeblock?

[flibble42]

@Earok


Other than it not teleporting but going for a leisurely stroll instead?

In my current case for instance the road needs to loop, the player car is teleported correctly but the camera scrolls ever so slowly back thru the level to the loop point instead of jumping instantly.

It all depends on your definition of broken, yes and no. For my purposes yes, for others maybe no.

I just feel that restoring the previous behavior of the codeblock would save myself and others from haveing to patch old projects (for some that could be many).

I understand this is a side effect of the camera follow speed limit (?) and i am not asking you to change or reverse that, just to add any changes needed to restore the teleport codeblocks previous behavior so that the user doesn't have to (i haven't managed to make my road work since the change, rather important in a top down scrolly car game).

I also believe that any codeblock solution you implement is going to be faster and more effiecient than anything i finally come up with.

Hope this sheds some light on the problem and what i am asking for.

Thanks.

[earok]

Ah right - I've made a note to look into it.

I wouldn't use the teleport function at all, since it'd overwrite the X and Y position rather than just the Y position. I'd do something like:

Set Player Y Position = Player_Y + Dist
Camera Y Position = Camera_Y + Dist

Whereas Dist would be something like the height of the map minus 256. Also would need to untick the "reset" box on the camera command.

[flibble42]

@Earok



I think the x thing might of come up before, Mixel suggested storing the player_x in one of the player vars and retreiving it after the teleport. Worked ok with the old codeblock.

[flibble42]

@Earok


Just got "Runtime error, unable to recycle (too many actors?)


Is this something you where looking into?

[flibble42]

@Earok


Something isn't right, i just leave it inactive and boom, crash. Just going to delete some other objects and see what happens.


SpyHunter_Earok.1.0.rar


Just run and leave it.. it will crash

[Mixel]

I’ve personally not used teleports, I’ve just used set position.. but I did find since a few versions back that if I set positioned the player in some cases without also manually moving the camera the player would not come out at the correct location. (May be unrelated to what’s happening to you flibble, but it sort of checks out and probably coincides with the scrolling change) - it only broke one of my levels anyway as my older ones I had already manually set the camera position.. fixed it by doing the same in that level too. (Doesn’t sound like a useful fix for spy hunter probably)

[earok]

Checked in a fix to experimental for the "respawn" recycle type, it was completely broken for destroying enemies that were on the screen and hopefully it's now working identically to how it worked before.

---

@Mixel the issue you've had is probably due to "snap to screen" set on the player on the leave screen event. If you move the player out of the camera before the camera has moved into position (and the scrolling is now hard coded to max 8 pixels per frame in order to avoid any frame skips caused by more than one row or column of tiles rendering in a frame), the player will snap back into the camera.

---

@flibble42 I had a play around with it. The issue is that cars are being spawned every couple of seconds without being destroyed (the recycle mode is set to "always" on some of those cars, so if they're off the screen, they're stored in memory rather than deleted, and so the list of actors stored offscreen gets bigger and bigger until it crashes).

I can't quite explain why it didn't crash in earlier versions, it could have been bugged in such a way that spawning new cars was overwriting older cars. But...

My recommendation would be this - change the recycle mode on all of those spawned actors from "always" to "never", so they never get into the recycle list. I normally don't recommend using the "never" mode (which basically means that actors offscreen are burning CPU cycles all of the time, instead of being "frozen" on to the map), but you've already got handling for actors leaving the top or the bottom of the screen (destroy_actor on one side and 01-leavescreen on the other) so I don't think it'll be a problem.

[UltraNarwhal]

Is multiplexing sprites intended more for vertical moving stuff? As if multiple are moving horizontal on the same line they don't display.

[flibble42]

@Earok


Thanks for the advice i'll make the changes and see what happens.
EDIT: So far the crash as not returned, fingers crossed..

Also, did you happen to goto the map tab, what was your experience?
It's painfully slow on my machine (spinning drive), as no-one else has complained i have to ask, am i doing something wrong? The map is very block heavy as they are used to control the AI, could this be a cause?
This is only 2.5 16x512 columns, to complete the map many more are needed.

On my system it takes 53 seconds from clicking spyhunter for the map to display and become useable. And then every time i try to make a change to options Events, Solid Top, anything really, it is painfully slow.


Any ideas? Is this only happening to me?


Thanks

[flibble42]

Is there a practical reason why CameraPush is not a thing?

[Mixel]

Originally Posted by earok

@Mixel the issue you've had is probably due to "snap to screen" set on the player on the leave screen event. If you move the player out of the camera before the camera has moved into position (and the scrolling is now hard coded to max 8 pixels per frame in order to avoid any frame skips caused by more than one row or column of tiles rendering in a frame), the player will snap back into the camera.

Oooh, yeah thankyou that would make a ton of sense! Almost all my levels I don’t need snap to screen enabled so I’ll go about disabling it on those ones.

Flibble: map screen seems not slow here, it’s instantaneous on most of my maps and takes a couple of seconds to display the really long ones. If it was taking ages though, and lacking some more useful fixes/advice.. I only use the map tab to set up parallax/backgrounds and event boxes, otherwise do you even need to look at the map tab at all? (Fair enough if you have a lot of event boxes)

Is it because of drive access speed? VRAM or something? I just tried the latest build from your thread and it took about 6 seconds to display that version of the map in the map tab first time and is quicker on repeat visits and things like the solid buttons take about 2 or 3 seconds.

[flibble42]

@Earok


Unity seems to be trying to detect USB drives, Joypads etc in the Scorpion editor while it's running not just at startup. Might want to look into that.

[flibble42]

@Mixel

It makes no sense, this is an i7 12 core 16gb gaming laptop, It can emulate a PS2, I play Tomb Raider, Jedi Fallen Order you name it, no hard drive issues. Could Microsoft be getting in the way? Virus scanning or something? What the shed is going on?

I just tried the Boot SSD and a 12TB USB same results.

Sorry to go off on one, it's just that my enjoyment of the dev process is being ruined by this issue, and unless someone can tell me otherwise it is clearly my problem not Scorpions, i just wish i knew what the problem was. I shall try to refrain from bringing this up again.

[earok]

Latest experimental:

* Attempted fix for KrisRetro's reported issue re: codeblock event not triggering on first frame of animation

* Investigated long standing performance issues with the map tab (raised by Flibble42 lately). Accessing large maps should be close to instant now, broadly speaking there were three fixes done here:

- Used GPU rather than the CPU to generate the map image.
- Only rendering the top layer of each tile (rather than blending them all down). I figure that a pixel perfect rendering of the tile isn't really needed for that view of the map.
- And the biggest speedup came from.. telling Unity not to generate a collision mesh on the map (basically making a 2D mesh representing the solid and transparent areas for collision detection in physics based games). I was shocked to find out that was the default behaviour rather than something that needed to be manually turned on!

---

@Flibble42 ah yeah, Mixel brought up that issue with joypad control messing with the editor some time ago, I'll try to remember to investigate that soon.

CameraPush isn't a thing because it's something that can be done in a codeblock (eg, moving the camera position between yields). If it was a native feature, it'd be a slight overhead on every game whether or not it was actually used (because Scorpion would need to check every frame if the camera needed to be pushed)

---

@Ultranarwhall

The multiplexing system (as used in the Bullet Hell demo) relies on the "end of data words" function, which only change the sprite position after the sprite is actually rendered. While that comes at the cost of not being able to move the sprite on the same scanline, the massive advantage to doing it that way is there's no copper list shenanigans required at all.

It *is* possible to use the copper list to render the same sprite multiple times on the same scanline (as per the parallax system), but it's tricky to set up, essentially it requires moving the sprite back and forth between every position on every line. The parallax system (which in itself was a nightmare to get going) basically bakes a static copperlist into memory and then only changes small parts of the copperlist to make the background scroll.

[flibble42]

@Earok


Oh my F**ing god, that is awesome, it's like you flipped a switch, thank you, this should make dealing with maps a pleasure not a chore.

Also thank you for the explanation of the logic behind not including CameraPush, makes sense.

Thank you, Thank You, Thank yoU


P.S. Does it not make you wonder what else Unity is doing? Dun Dun Dahhh

[flibble42]

@Earok


Don't know if this is on purpose, but if you CTRl+C and then CTRL+V a Camera Move the RESET flag gets enabled.

[earok]

@flibble42 I'll investigate!

---

Latest check in to experimental is a fairly minor one, fixed another issue relating to codeblocks triggered by the first frame of an animation, and improved the bundled "barrel" demo so that it's better at handling large numbers of falling barrels