Scorpion Engine

[acidbottle]

No worries, glad the issue has been identified! Think UltraNarwhal's issue may be related to mine also, could be wrong.

Ultra also mentioned the up to jump in the Wonderboy thread and your absolutely right, was no reason at all not to have this set up as such, so just corrected that issue

[Mixel]

After a lot of tinkering i think it's safe to say the current acpu_pursuit_direct is.. not seeking the point it should be? (as i was seeing with the frog firing at my head) I need to stop tinkering with it further as I'll likely have to undo all the adjustments, hehe. eg my grabby bugs.. to get them to stick in the centre of the player sprite now the bug animations have to be offset about approx 12pixels downwards.. which means I'm doing the same sort of offset to get things in the right place as before the change, just.. backwards?

it's like it's specifically seeking the top left point of the collision box instead of the centre? This is a munchy bug that I've adjusted by moving it's animation down 11 pixels.. but i haven't adjusted for sideways.. it's definitely not seeking francis' centre point on either X or Y.. (if i put the bugs in the 0,0 centre it's stuck to the back of your head.)

(sorry its hard to see the bug because it's purple, haha, its stuck to your elbow) I'll readjust the walking bug animation to 0,0 and put them next to the player and up to github so you can walk straight into one and see.

[earok]

Latest check in to experimental and it's a moderately substantial one:

- On compile, startup-sequence is forced to be Amiga line endings (sometimes Git will check out files as Windows line endings regardless of the intended line ending format)

- Fix for AcidBottle's reported black screen of death issue. I have to say this was a fairly massive bug that affected the entire panel system, so other people having graphical glitches could have been affected by this as well.

- Fix for UltraNarwall's reported bug with camera following (restored an old behaviour where setting the camera follow setting will attach the camera to the current player rather than a previous one)

- DisableVar is removed from events, it was essentially redundant since it just did the opposite of EnableVar (and having both of them set didn't really have any use since you'd need to set both variables to the opposite of each other)

- DoubleSmooth is removed. I may add it back in future but it was potentially buggy and difficult to explain. As an alternative I may add a "speed scaler" setting in future which would also allow proper speed scaling for NTSC games, for example.

- Fix for Mixel's reported issue with CPU_Pursuit_Directly (hopefully! seems OK at my end now)

- New command "set camera center position" which puts the supplied coordinates in the dead center of the screen rather than the top left (@AcidBottle, this should resolve the left issue you were having, set camera was always meant to align the supplied coordinates to the top left so if it didn't always do that, it would have been a bug with the older version of Scorpion rather than the current one).

[acidbottle]

Brilliant update earok, solved the black screen for sure

The set camera_centre command seemingly worked then returned again, am not entirely sure what is triggering the respawn on the left edge at all.

Less important but weird, have lives var set to 3, though in game you now start with 2!

Another odd thing was a platform that should be respawning after being destroyed by on timer expire is not respawning. However, have exact same style codeblock in another part of the game and it works fine, only difference is the one that works goes up. May need to up a copy of the issue later if needed.

[earok]

@acidbottle Regarding the left edge position, this is what levelstart is doing.

- player x to 4155
- camera x to 4155

Player x will be on the left edge of the screen because the camera x refers to the left side of the screen.

I'm not sure about the other bugs but feel free to set up a build for me to look at if you're not able to solve them.

----

Check in for the day, a few issues resolved yesterday when I was watching Mixel's latest epic stream and one more right now.

* The ForEach command would cause a crash.
* The new feature to fix line endings would prevent compilation if WinUAE was open and had startup-sequence locked.
* Some fixes for copper display on panels, particularly when a panel is less than 256 pixels in height.
* Use of overlapping panels is prevented in projects with sprite parallax. The main problem here is that when there's a panel overlapping the top of the game display, the copper list needs to be rewritten to take into account the new top of the screen edge, but it's particularly problematic on sprite parallax where entirely necessary lines that set up slices of the parallax may be "hidden" behind the top panel (and of course it's not possible to have two copper lists running simultaneously on the same scanlines). As such, it's too complicated to support.

[Mixel]

These updates sound great! And thanks again for hanging out in the gruelling streams. (and helping immensely!)

I was just thinking, I don’t think it’s the case but just to make sure - if the memory allocated for levels is always = the size of the largest level, and the memory allocated to music is always allocated to the biggest music.. Does the same happen for panels? If the same happens to panels I may need to give my past self a stern talking to, haha!

Splitting a couple of levels up is working really well. I’m trimming the fat from some of the bigger stages too, though tbh it’s quite difficult to see which sections of the map will be “big”.. Tunnels2 is the biggest “main” stage and a big chunk of that was dead space, so I can trim a few lines off, simplify some things, but sometimes I can delete a substantial chunk of a map thinking it’ll reduce the size markedly, and it’ll barely do anything.

[earok]

@mixel that's no worries! I hope we can work out the winter level issue sometime.

Panels are complicated and I'm not overly satisfied with how they currently work. In general - the middle panels are essentially "free" in the sense that the memory they consume overlaps with memory used by levels (which is to say, unless your largest panel consumes more chipram than your largest level tileset, it's not going to be an issue).

Bottom and top panels are problematic though. Memory for them isn't allocated up front because I can't predict up front where top and bottom panels are going to be loaded into, this is a contradiction to my general principle that -all- ram should be loaded up front so a crash should happen immediately (rather than two hours into the game when the player is about to face a final boss etc). I may in future make it so that Scorpion devs have to explicitly label panels as being for middle, top, bottom etc (which would allow me to correctly allocate ALL required memory up front) but I didn't want to make that step right now.

---

@griffon apologies, I feel bad about disallowing use of overlapping panels in games with parallax but I can't think of a solution for it right now.

[acidbottle]

Well the good news is that the left edge bug is fixed by the new command! Just I had not set this on custom areas for fire and fall deaths, seemed to work fine when death by any other means.

The missing lives bug has vanished in the latest build to so one less thing to bother you with!

I have checked in a platform respawn (possible) bug to look at when you have time. When you load in you will just see 2 clouds fall into the ocean and never reappear. When clouds go in the other direction (up) they seem to work fine!

Now the latest build is really shaping up nice, thanks a lot for your hard work and tips on Mixel's stream. I guess I still cannot fathom auto scroll for going up slopes though
At present you jump to move the map tiles up, if you don't the player just moves to the top of the screen while camera stays fixed in the same spot.

Aside from all this, I do not know exactly what changes are being made under the hood but in winuae (non jit) the game is running on 1MB chip and 1 MB (z2)fast on a500+/full ecs, with only minimal slowdowns at certain points. This is with next to no optimisation, fantastic!

[earok]

Glad that performance suddenly got better, I'm not entirely sure what could have been causing slow downs that's no longer present. Admittedly the engine was quite a bit messier a week ago, there could have been something jettisoned from the engine recently that was accidentally causing a major slow down in some circumstances.

At some stage I wouldn't mind taking a crack at optimizing Wonderboy myself (sprites, palette, swapping fruit actors out for blocks etc)

Autoscroll should be fairly straight forward, the h-scroll demo uses auto scrolling and it should be possible (if the level is large enough for eight way scrolling) to use those same commands to make it scroll diagonally. Though admittedly it isn't tested with diagonal scrolling.

[earok]

@acidbottle checked in some changes to the Wonderboy repo to tidy up and fix the infinite looping cloud downward bug. Essentially I've got it doing this on the ontimer expire every frame:

if actor_y => 224 ;Off the bottom of the visible display
actor_y = actor_y - 256 ;Move above the visible display
endif


Advantages are that it works and it'll work everywhere you need it (eg, there's only one down looping cloud actor now, you won't need to do make a new actor for every downward cloud in the game). The reason why it doesn't use an ontimer expired of (say) 50 is that the top cloud and the bottom cloud take different lengths of time to reach the bottom of the screen.

I think the reason why it didn't work before at all is you had it destroying actor and then yielding on the actor (yielding won't work as expected on an actor that's already destroyed), in any case the new code should be a lot more solid.

[earok]

Daily update to experimental has been posted - hopefully hasn't broken anything, it's just an optimization pass only that shaved ~10KB off the executable (and thus saves 10KB or so of chipram).

[amigaosx]

I'm trying to make a simple anim5 loop inside scorpion, but it crashes at the end of the anim with a software failure screen.

My current Startup code is:

=== loop start ===
Play anim5 animation
Goto-> loop start

Even playing the anim without trying to loop crashes WinUAE.
Previous versions of scorpion did not crashed at the end of the anim, but the animation loop wasn't 'seamless', it paused to a black screen at the end of the anim before looping.
Also, to control the framerate of the anim I have to use 'frameskip' right?

Any help would be appreciated!.

[Mixel]

Ed: sorry Amigaosx, I have no experience with adding anim5s so haven’t a clue how that works either.

Originally Posted by earok

Daily update to experimental has been posted - hopefully hasn't broken anything, it's just an optimization pass only that shaved ~10KB off the executable (and thus saves 10KB or so of chipram).

Maybe it did break something, hehe. (could be anything though probably!) When I selected "Startup" as my startup codeblock.. which is supposed to load the intro etc.. it sent me to totally the wrong level..

So I thought, might as well delete the contents of the output folder and build again see if it fixes it.. But now CMO freezes at the Scorpion splash screen. I upped it to Git, fingers crossed its not too bad.

---

Edit: What the heck.. I've reverted to every one of the last 6ish SE Experimental builds and its giving me the same problem when i "run in WinUAE" or FSUAE, in both Wizonk and CMO.. it just hangs at the scorpion splash screen.. Wizonk is tiny though so I can't understand that.. Particularly can't understand it as im using SE versions I know I must have been using without issue previously. No errors in build.log

[acidbottle]

Originally Posted by earok

@acidbottle checked in some changes to the Wonderboy repo to tidy up and fix the infinite looping cloud downward bug.
.

Outstanding earok, thank you so much for digging into the depths of my hacky code! I need to use proper logic far more than the weird workarounds that end up costing way more resources than needed. Can use this logic elsewhere to which is great.

There is certainly a tonne of scope for optimisation on this project. I just noticed that on level 2 the top 2 tile rows on the map are objects and not map layers

You are more than welcome to have a look through and see where improvements can be made at some point, the block one should be easy enough!

[earok]

Daily check in, simply found and resolved @Mixel's bug. I have to say, I'm likewise confused why this suddenly became an issue, even on slightly older Scorpion Experimental versions. But it definitely was an engine bug rather than something weird at your side.

---

@acidbottle no worries at all!

---

@amigaosx Ah, sorry to hear about your anim5 bug. I did indeed change the anim5 handling to make it more reliable and use less memory but I guess ironically I broke it. It does work fine on my own test anim5 file but feel free to upload yours somewhere (or email to earok 3d at gmail dot com) for me to find out what the issue is.

[Mixel]

Originally Posted by earok

Daily check in, simply found and resolved @Mixel's bug. I have to say, I'm likewise confused why this suddenly became an issue, even on slightly older Scorpion Experimental versions. But it definitely was an engine bug rather than something weird at your side.

Thanks so much Everything all back to normal.. Glad it wasn’t something dumb I did, haha!

[earok]

I've been thinking about finally getting the PixelGlass Patreon up and running. Nothing is absolutely set in stone yet, I did want to discuss the general ideas behind the project and see what people thought.


- The Patreon would be largely Scorpion focused but would be useful for supporting development of unreleased PixelGlass related projects (Retro Animator, AlarCity, ReImagine remakes and such). It wouldn't be only for Scorpion developers, support from anyone able to back the project at any level would be much appreciated.

- The Patreon would have funding goals which would allow me to create and maintain requested features (eg, at a certain funding level, I could justify working on a Mac build of the editor, comprehensive documentation and tutorials, or begin work on an engine for other platforms than Amiga and so on)

- Different levels of backer perks could include time limited exclusive posts and tutorial videos, a "Scorpion Gold Edition" splash screen, special thanks in Scorpion Engine credits and so on.

[earok]

Latest experimental check in: Basically just some efficiency tweaks (both performance and memory size) and bug fixes. There were some problems with the Panels tab that have been fixed (not all of the options would always fit on screen, and I think as Griffonchan pointed out on screen the Sound drop down for panel options wasn't working).

One thing to keep an eye out for - I've reworked panel elements a bit so that Scorpion no longer needs to check if they need to be redrawn (basically the compiled codeblocks will tell Scorpion when a panel redraw needs to be done, rather than Scorpion checking look up tables to work it out). Hopefully that hasn't broken any panel elements or options.

I have been thinking about the immediate next steps and this is what I'm planning to do next - the level height has been hardcoded at 512 tiles, I'm going to see if I can expand that out to around to at least 1024 (maybe a theoretical maximum of 2048). Either of those should be enough to fit the whole arcade Jackal in a single level

[Mixel]

Was waiting for someone else to reply but I think that sounds great! Any way we can support you/Scorpion is greatly appreciated.. im sure there are a good few appreciative amiga scene regulars who would chip in despite not being developers too.

Looking forward to however this pans out. Would scorpion gold (or a tier above that) let us customise the splash screen or even (not saying i would, but eventually someone might want to) drop it entirely? like the more expensive unity licenses do.. How to really break the brains of the “i can always tell when a game isnt 100% bespoke!” crowd, haha.

edit: oh my! map height increase sounds awesome too! for vertical shooters that sounds really handy.

[Silverstreak]

I think the Patreon is great idea. That people support these projects with their time and effort is one thing, but to able to say thanks with the price of a virtual beer, I'd say is something I'd be happy to do.