Scorpion Engine

[AF2013]

earok? You got Amazing motivation(otherwords for keep going!) and I guess you do have road map for your Scorpion Engine 2020 and onward(2021+)

[earok]

Thank you! It's honestly one update at a time at the moment.

The big updates over the next few years are intended to be the complete feature set needed to finish and release AlarCity, broader native platform support for modern platforms (PC, Mac, Android etc) and potentially other retro platforms (Mega Drive, Jaguar and Dreamcast etc), maybe with some additional import support from other engines (Nesmaker in particular). Though Amiga is always going to be the core focus of the engine. And I'll need to get funded somehow, probably a patreon at some stage.

[Kaizen35]

Bravo Earok

[Predseda]

Originally Posted by earok

The big updates over the next few years are intended to be the complete feature set needed to finish and release AlarCity

This probably means AlarCity will not be released in years yet?

BTW I am patroning a game, that is being developed upon Scorpion engine, so I do not see any problem to patron the engine itself too.

[earok]

Your backing would be hugely appreciated I'll try to get the ball rolling on a Pixelglass patreon soon.

AlarCity is something that'll be finished sooner or later. I do intend to get stuck into more frequent minor updates about that game.

----

Daily update to experimental.

There's a new "parallax_var" setting on the map screen. By default this is tied to the camera_x, as it was previously hardcoded to be, but it doesn't have to be. You could tie it to camera_y if you wanted a vertical parallax level, or to your own variable, eg in my test script:

if control1fire == button_hit
myparallaxspeed + 1
endif
myparallax + myparallaxspeed

Is a script that runs every frame and increases the parallax speed by 1 whenever the fire button is hit.

[earok]

Did another check in today. Fixed an issue reported by Mixel with corruption when going between options menus, also there's now the ability to convert an image to use as vertical parallax.

Vertical parallax is extremely limited - the source image must be 32x32, and no more than 4 colors in total across the entire image.

However, after your initial import, there's no reason why you can't abuse the resulting image with post processing to create something quite cool looking, as shown here.

[Samurai_Crow]

Re:vertical parallax

If you are blitting to the sprite DMA and then muxing the 2 sprites with the copper, there is a way to remove the vertical-only constraint: Firstly, make the image buffer 16 pixels wider with the rightmost 16 pixels identical to the leftmost 16 pixels. This is to allow horizontal wrap-around. Finally, you'll have to store the word before the sprite image in a CPU register or memory so you can restore the contents after blitting. This is a side effect of blitting with a horizontal offset other than zero.

[acidbottle]

Absolutely love this idea. Sadly I have absolutely no idea how to use parallax it seems. I get a series of horizontal lines (32) at the top of the screen, though they are under the map tiles.

The edit parallax data is likely key but have not been able to crack that particular code!

What was bothering me today is the score variable. I have a panel and the sores will display fine if using just 3 digits. If I want a score of more than 3 digits the engine creates a random player and hiscore that never changes .. what is wrong please

[earok]

@Samurai_Crow I'm not quite sure I follow I'm not actually using the blitter for the sprites, it's just a very simple (eg, memory heavy) system where up to 32 frames for the background sprites are in memory and the parallax system just cycles between them.

@acidbottle it might be worth having a look at the parallax in the Amigo the Fox and Flappy Fox demos, both of them use the parallax system heavily.

Not really sure what the issue with score is - check that you've got 9999 set as the "max value", also bear in mind that the maximum value that can be displayed in an element is 32767 (signed 16 bit integer).

(With Pitfall, I actually used two elements together with a maximum of 999 each for a maximum of 999,999, where increasing the lower value above 999 would increase the upper value by 1)

[Samurai_Crow]

@earok

Blitting to a sprite DMA is as easy as blitting to an interleaved, 2 bitplane screen with 16 pixels' width (or 64 pixels on AGA). I've done it with the Kickstart 3.1 routines on my A1200. The only trick was transplanting the image buffer pointers from a SimpleSprite structure to an interleaved BitMap structure, then passing that BitMap structure into AllocRastPort(). The resultant RastPort could draw anything you want and it would draw it to the sprite.

[acidbottle]

Originally Posted by earok

Not really sure what the issue with score is - check that you've got 9999 set as the "max value", also bear in mind that the maximum value that can be displayed in an element is 32767 (signed 16 bit integer).

(With Pitfall, I actually used two elements together with a maximum of 999 each for a maximum of 999,999, where increasing the lower value above 999 would increase the upper value by 1)

Cheers! I wasnt aware of the max limit per element. Sorted now

[earok]

@samurai_crow Ahh, I see

@acidbottle no worries!

----

Daily check in:

- Clamped the maximum element value to 9999 to avoid confusion (technically it could support up to 32K but it may be confusing not being able to use all of five digits)
- Added a "cheat sheet" to the dialogue box for tags (eg, <br> for new line, <1> for delay one frame etc).
- Didn't realize the dialogue choice codeblock command was completely broken, which is an absolute necessity for visual novels (and is used in the Phoenix Wright demo), so I've fixed that.

[earok]

Latest experimental has been checked in, it -might- be a bit buggy on UI potentially. I attempted to fix an issue Mixel has been having for awhile and ended up rewriting a fair bit of the UI code, so updating the UI should have less overhead than before.

I've given it a test on a couple of different games but there might be some edge cases that I missed.

[Mixel]

Originally Posted by earok

Latest experimental has been checked in, it -might- be a bit buggy on UI potentially. I attempted to fix an issue Mixel has been having for awhile and ended up rewriting a fair bit of the UI code, so updating the UI should have less overhead than before.

I've given it a test on a couple of different games but there might be some edge cases that I missed.

Ooh! I'll take off my "all 5s" fix (i'll leave that in the Billbuild) and check that out. Thanks for spending so long on such a fringe error.

I've played through it so many times now without issue the Billbuild seems fixed too, albeit through a silly method. I'll also switch the health bar to be a bar.

Edit: It seems like you fixed it(I think!) and I've not encountered any other weird behavior either.
Nope, it's similarly wonky now. (on 7 in my first attempts, need to make it happen 3 more times in a row)

I can definitely replicate it now, and.. it's gone from 8 being inexplicably cursed to 7 being inexplicably cursed.. I can't use the fix that seemed to work on 8 anymore either as it starts even when 7 is not the first number rendered.

[UltraNarwhal]

Originally Posted by earok

Latest experimental has been checked in, it -might- be a bit buggy on UI potentially.

Yep, that build breaks my hud. Weapon select no longer works and the elements are corrupted in colour and position.

[Mixel]

Originally Posted by earok

Latest experimental has been checked in, it -might- be a bit buggy on UI potentially. I attempted to fix an issue Mixel has been having for awhile and ended up rewriting a fair bit of the UI code, so updating the UI should have less overhead than before.

I've given it a test on a couple of different games but there might be some edge cases that I missed.

I've discovered something...

The problem seems (in my case) like it might be "element 4.."

I moved my score counter out of element 4 and put an exact replica in Element 8.. 7s are no longer glitching after multiple playthroughs, doing the exact things that triggered it before.

But the Key, which is just an On/Off toggle, which has always worked perfectly until now, had shuffled into the #4 slot when I deleted the old coin counter.. And it's occasionally going corrupt now. (black stuff overlapping to the right of the key now) - this is a much "safer" thing to have going wrong occasionally though as you rarely get/have keys in the demo.

[earok]

@Ultranarwall Checked in a fix for the Duckstroma bug (issue where elements without variables attached were still getting added to the final output and confusing the engine).

@Mixel that is really, really odd. If you can give me a build where I can just press compile and see the bug in action, I should be able to diagnose and fix.

[Mixel]

Originally Posted by earok

@Mixel that is really, really odd. If you can give me a build where I can just press compile and see the bug in action, I should be able to diagnose and fix.

The "is it a rendering empty space glitch" idea was a dead end too.. I'll let you know if I ever find a way of reliably and quickly activating the remaining graphical artefact.. (it's conveniently placed currently in a way that i could integrate into the interface and nobody would know, if we can never figure this out.. haha)

It's not just the "key graphics" causing it either it turns out, I've found that if I press the F shortcut, used for resetting the Francis actor to his basic state, the 3 pixels appear and disappear every time you press it. (if you're already in one of the places that it happens - but you can't teleport to those as it starts working normally then) ..

This is some serious Professor Layton puzzle wackiness.

Feel like I should document what I'm doing in case anything leads to a Eureka moment.

Ed: I noticed the colour of the 3 dots are EHB dark colours, so I took the panel out of EHB to see what they look like - then it displays a completely different graphical glitch in a slightly different but close-by place. which sometimes blinks on and off..* That also reverted the 7s to often being corrupt behaviour..

[ Show youtube player ]
*Explaining what's happening in this video.. The flashing pixels below the health bar - up until 10s they're flashing of their own accord. When I collect the coin is slightly disturbs their timing, but they continue flashing.. Then from 15s onward I'm hammering the F key (francis' coat flaps about a bit) which makes it flash in time to the pressing the F key.

After that I switched it back to EHB but both sets of glitches are present.. (the 3 dots AND the coloured stuff below the healthbar.. And 7 is still crazy once the graphics have starting going odd)

So I revert to the version with just the 3 dots on git.. I can't make the numbers glitch or anything flash anymore.

Not sure if any of that sheds any light on where exactly the problem might be.

Other things I've tried: Deleting the panel and starting from scratch (makes no difference even if i do that and only add the key), deleting and recreating all elements.. (as above) What is Scorpion changing when you switch a panel from 64cols to 32, because something that happens during that process definitely seems to stir things up?

[earok]

Re: UI glitches, I'll come back to it once I've got a demo where they can be replicated every time on startup.

---

Experimental update for the day:

Added the initial workings of the "asset bundling" system. Animations can be linked to maps, which means that those animations are only in memory when the maps are loaded. The primary and most obvious use for this is for huge boss characters that are only in a single level, though it could be used for mini games with animations that only appear there.

This system may get supplemented entirely by something more flexible (in particular, something that allows bundling an animation against multiple (but not all) maps, and something that allows multiple asset bundles to be loaded at once).

[roondar]

Originally Posted by earok

@Samurai_Crow I'm not quite sure I follow I'm not actually using the blitter for the sprites, it's just a very simple (eg, memory heavy) system where up to 32 frames for the background sprites are in memory and the parallax system just cycles between them.

If that's the case, you should be able to make a horizontal version as well

By the way, I'm impressed at how good a 32x32 pixel background like that can look. I always felt that Sprite background layers with repeating patterns were pretty limiting, but it seems now that the design plays a crucial role. Good to see