Scorpion Engine

[earok]

Unfortunately the buffer seam is going to be a permanent change, it's a little complicated but I had to rework the map rendering so it doesn't count the 1 tile padding above the map as part of the map itself. I guess you could maybe make the map one tile larger at the top to counter balance it?

I've noticed the issues with edge blits, I'll see what I can do.

[earok]

cheers @d4rk3lf

---

Had a pretty rough time with bugs today, ended up wasting most of my day on it. I'll take a few days off.

Latest experimental check in:

* Fixed issue where objects leaving the top edge of the level can cause a crash
* Fixed issue with copper lists at the 255 line
* Fixed issue with path nodes
* Fix for some issues with tiles blitting in on the edges (hopefully, at a glance that seems ok)
* Restricted parallax images to 224 high (ultimately memory is wasted beyond that point since there's no way for that part to be displayed on screen)

[acidbottle]

I think you earned a break from coding, play some games or hang out with friends and family a while

I am getting a quit to desktop "cannot deplode cached map" error at certain points however ...!

[griffon]

Originally Posted by acidbottle

I am getting a quit to desktop "cannot deplode cached map" error at certain points however ...!

Sounds like an out of memory problem. As a temporary workaround, check if you have cache maps and/or implode compression activated, and turn them off?

[acidbottle]

Originally Posted by griffon

Sounds like an out of memory problem. As a temporary workaround, check if you have cache maps and/or implode compression activated, and turn them off?

Cheers griffon, it only happens on latest build but yea, turning off implode compressions fixes the issue

[Pyromania]

Nice update!

[UltraNarwhal]

Originally Posted by earok

Latest experimental check in:

* Fixed issue where objects leaving the top edge of the level can cause a crash
* Fixed issue with copper lists at the 255 line
* Fixed issue with path nodes
* Fix for some issues with tiles blitting in on the edges (hopefully, at a glance that seems ok)
* Restricted parallax images to 224 high (ultimately memory is wasted beyond that point since there's no way for that part to be displayed on screen)

I'm curently using the stable public release build of Scorpion but noticed this in experimental version - no events work, something to look at after you've had a rest from coding Scorpion

[Mixel]

I’m in the same boat but in my case events *do* work, but only when they’re not along the right hand side of a map.. ie the ones on the left work, and if I move my right hand events a few pixels to the left they start working too.. but all events seem off centre to where they are in tiled? So maybe some get shunted off the side of the map? (I might be imagining it, but it definitely seems like the right hand side of the box is over sensitive?)

The copper seams moving was no fuss at all here you’re right about adding an extra line to the top. It’s only that pterodactyl boss I had to change a single line of a codeblock on. Thanks for all the new things, and enjoy your break.

[earok]

Thanks guys, had a pretty good breather, shame that yesterday's stream (intended for doing some experimental grappling hook stuff, Neeso's Bionic Command stuff got me interested in proving how it can be done) was aborted by OBS recommending an update that broke things. Now that it's sorted, I'll retry the stream tomorrow.

---

Latest fixes:

* Events and teleport locations should be fixed now, bug had meant that they were 16 pixels out on both boundaries (this again relates to shrinking the map to not include the invisible walls on all four sides)
* Fix for issue reported by Griffon, the line 255 copper wrap around was causing issues on maps with sprite parallax.

[earok]

Did a check in, hopefully shouldn't break anything, but math has largely been re-written so I need to extensively test the sample games.

For reference, these are the available operators:

Add +
Sub -
Mul *
Div /
Mod %
And & (new)
Or | (new)
Shift Left << (new)
Shift Right >> (new)

In addition, 0x can be used for hex numbers, 0b for binary (eg, 0xFF for 255)


I've had to ditch some automatic optimizations (eg, converting divide by 16 into shift right 4 automatically, which caused issues with negative numbers that were quite apparent on last night's stream). But now that shift is in there, you could replace:

player_x / 16

with

player_x >> 4

(To convert actor coordinates into tile coordinates quicker than dividing by 16. I'll make sure the sample games are updated like that)

Incidentally, I did a few fixes on the Batman Returns rope swing unofficial demo. Not totally happy with it but I'll come back to it later.

[UltraNarwhal]

Originally Posted by earok

Did a check in, hopefully shouldn't break anything, but math has largely been re-written so I need to extensively test the sample games.

This version doesn't like teleporter names in codeblocks and throws error until disabled.

Other issue I noticed in previous experimental too is block collisions seem to be ignored if spawn object on the block. I uploaded demo showing this to my github, try clicking on the fake desktop icons (they work in stable public release).

[earok]

Was planning to stream but got sidetracked, I did manage to do an update though:

1) Fixed UltraNarwall's reported bug re: named teleporters in codeblocks.
2) Added "Get Block by Pixel Coordinate" command, explanation below.



@Ultranwarhal, unfortunately in regards to projectiles it was actually the "stable" version that is glitched. It was never intended for projectiles to have to do block collision checks on every single frame, only when it crosses the tile boundary (which was working for right and down, but not up and left). The reason for this is because there's a fair bit of CPU overhead in collision detection so it'd be best not to do it 16 times if it takes a projectile 16 frames to cross a tile boundary, when just doing it once would work.

I had been intending to add a "Get block by pixel coordinates" command, which I've now done so and might be a little easier to use for your use case. Something like:

=== cursor_onattack === (or put this in the onspawn on your cursor click actor)
get block by pixel coordinate: actor_x / actor_y into variable "myvar"
if myvar == block_icon1
; do this
else if myvar == block_icon2
; do that
etc etc

[acidbottle]

Nice update earok, was going to post about the teleport issue buy you fixed it already!

Checked in a new repo today, hope you dont mind being added. It has some weird glitchy effects when scrolling, maybe bad code or map setup but hope you can shed some light on it.

[UltraNarwhal]

Originally Posted by earok

1) Fixed UltraNarwall's reported bug re: named teleporters in codeblocks.
2) Added "Get Block by Pixel Coordinate" command, explanation below.

Thanks, excellent work.

[earok]

Cheers @Acidbottle @ultranarwhal

Daily update:

- Multiplexed sprites were not correctly aligned.
- Fixed bug sometimes preventing first step on palette crunch command.
- Fixed compile bug where, if there was an error on an Else-If statement, it wouldn't indicate the codeblock or line.
- Fix for sprite parallax on line 256
- A UI refresh is only triggered when a variable on a UI element has changed (not when it's set back to the same value it was previously).

Note that, if a variable is on any UI element, and you update that variable, it'll refresh every visible panel (Scorpion doesn't check to see if a specific panel is loaded when doing a refresh, it just assumes that updating a UI variable requires a refresh on whatever the current UI panels are)

---

@acidbottle I think it may be pushing DMA too far to have 128 colors on a scrolling screen with the copper split stuff Scorpion does for efficient eight way scrolling, also the screen needed to be further to the right so that copper has time to do it's thing before the screen is displayed. I reworked it a bit, down to 64 colors (still AGA, not EHB), and for good measure made the player ship a sprite and the player bullets multiplexed sprites (so you can have a lot more than 4 bullets on screen and still the ship is a sprite), and the sprites are in the 64-79 index range (so it's technically 80 colors on a 6BP/64 color setup)

[Mixel]

Originally Posted by earok

Cheers @Acidbottle @ultranarwhal

Daily update:

- Multiplexed sprites were not correctly aligned.
- Fixed bug sometimes preventing first step on palette crunch command.
- Fixed compile bug where, if there was an error on an Else-If statement, it wouldn't indicate the codeblock or line.

These are great changes! Ignore my latest CMO upload to git..

I was getting a compile error in the latest SE saying "Unknown Error Parsing YesNoPanel" - I didn't think YesNoPanel even exists anymore, so I was having trouble finding where it was tripping up.. It was a remnent from when i used to use panels for Yes/No selectors and I was still referencing it in the map section..

So I started writing this post thinking you needed to fix something but by the time I got to the end I've already fixed it, derp! I guess it could be more specific if you reference a panel that doesn't exist in codeblocks but it's hardly important.

[acidbottle]

Another fine round of bug squashing

Really appreciate you taking a look at the new project, had a suspicion the 128 colour palette was going to be a dangerous limit! Also great to see how multiplex is implemented, it is indeed quite simple. With that technicality out the way, can begin to populate the game and aside from one or 2 things to figure out, I think it should be reasonably straightforward from here.

[earok]

Cheers @acidbottle!

Daily check in:
- Fixed issue where sometimes compile errors didn't highlight the responsible codeblock or line.
- Some improvements to parsing negative numbers.
- Fix with multiplex sprite positioning (hopefully this hasn't broken anything)


New feature is the ability to set "screentop", but note that this is *extremely* experimental, doesn't have a proper function in the display menu yet (you can still set the variable directly).

The point of this is to add empty black space at the top of the gameplay screen so that, when a top panel is loaded and unloaded, it doesn't jarringly cause the gameplay screen to move up and down.

It *may* potentially cause issues with sprites and such, bug reports would be appreciated but please use carefully.

[earok]

New daily update:

* The previously discussed screentop is now officially supported (though minimally tested)
* Some minor fixes to copper (hopefully this won't break anyone's parallax, but do let me know if it has)
* Reworking of melee-to-block attacks, details below:

---

I owe Mixel bit of an apology, he had mentioned some time ago that melee attacks didn't seem to affect blocks in the way that it should, I didn't really investigate until now.

Melee attacks were only hitting the block in the very center of the melee box - now they should hit *all* of them. I think the reason why it was configured that way to begin with was Alex Kidd (Monkeylad) only allows you to hit one block even if the fist is half way between two blocks, but that is an issue that should have been solved in codeblocks.

[Mixel]

Originally Posted by earok

I owe Mixel bit of an apology, he had mentioned some time ago that melee attacks didn't seem to affect blocks in the way that it should, I didn't really investigate until now.

No worries and thanks for the fix! That’s great news as it was probably my jankiest workaround, you could kind of see the blocks steadily dissolve in front of you. I’m glad you fixed it before my player bullets got bigger as that’s when it would’ve really caused problems, trying to clear paths like in Turrican. It’ll probably speed my game up slightly being able to use it normally.