Scorpion Engine

[Mixel]

This is all so incredibly outside of my experience working in Scorpion, you're doing so many different things I've not touched on (firing 8 different directions, home made parallax, I don't know where I'd start!)

For the trees panning around while you're holding fire, do you need to add another set of conditions around it saying "if player xspeed and player yspeed = 0 .. So the joystick direction wont affect the parallax objects while you're firing.. It looks like you cant run and fire at the same time so that should work? I dont even really understand how they're moving? can you have them move based on the player's X position rather than the joystick control?

As for shooting in different directions to the animation, I have noooo idea as I've never tried anything like it, but given Earok's done some stuff with Experimental and directions I'd use Experimental before trying to fix it. I'd probably fire the projectiles from codeblocks rigged up to frames of the animation if I couldn't get it to work in the way i think it's supposed to.. (I'm not sure what that is in re: to your specific situation though)

I have a feeling you might run out of Chip RAM based on how many big animation frames it looks like you're planning on adding? Its going to be impressive when it's all put together.

[Tsak]

Originally Posted by Kaizen35

Hi, my game is not as advanced as yours, but here is the progress.
So I have some concerns, the main ones being those with the tire.
I had to assign the pull function to the "X" key because I couldn't get my parallax system to work with the joystick pull.
here is a copy / paste of the text of my video for explications:

And at the end, the new sprites to come

[ Show youtube player ]

Nice work! For the shooting bug (where you only shoot leftwards, despite looking to other directions) I suspect you need to click the 'match direction' button (down-left) on your actor page.

[Mixel]

Originally Posted by earok

What we've got now is that if you
A) Use SetType to change an actor, and
B) The idle/walking animation has the same number of frames as before

Oh oh.. this is odd, The behaviour when applied to platform player actors who can duck is all sorts of haywire in this build.

[ Show youtube player ]

In this video I'm mostly walking left and pressing/holding down/left .. the sliding is one thing, but the turning right and being idle is odd and the occasionally appearing shotgun is even more perplexing.. FrancisLogic should only display the shotgun version if Ammo > 0, so multiple weird things are happening here.

[earok]

Experimental has been updated. A couple of notes:

- Fixed a bug where it was attempting to transition every animation, regarding of length. This means if you were transitioning from a long animation to a short animation, it would "overshoot" and play a frame from a different animation.

I'm still not 100% sure it works in every situation.

- Fixed some bizarrely bad bugs with Commands (in particular, joystick fire 2). They should be more reliable now.


I suspect that second one is a major issue still in the "public" version, so I should work towards crunching every major known bug and do the 2021.5.2 release.

[Kaizen35]

Originally Posted by Mixel

can you have them move based on the player's X position rather than the joystick control?

Thanks for your help Mixel
yes, that's what I did (player position and not joystick) and it works with the "x" key but not with the pull. weird.

given Earok's done some stuff with Experimental and directions I'd use Experimental before trying to fix it. I'd probably fire the projectiles from codeblocks rigged up to frames of the animation if I couldn't get it to work in the way i think it's supposed to..

I haven't experienced all of this yet either. But it might also be a good idea to trigger an action from an animation frame.

I have a feeling you might run out of Chip RAM...

yes, I might run out. a few days ago, the project went back to an A500 with 1 mo of chip, but not now again. (my favorite amiga is an A500 with a TF536 and I would like this project to go over it ^^) I will therefore try to make it work on it by learning more from Scorpion Engine to make it as light as possible. (for example, fairly light levels, only with two actors, a bit like Moostone)
here are some images of my code. there really is nothing to complicate about, as I am not an expert in coding at all. But Scorpio allows us to kindly introduce us to this. I suffered a little a few days ago to try to make a shadow, but passed the course, I better understood how it all works. here are some images that show behind the scenes

(some definitions "mov_arb" for tree mouvement / "act_arb" for tree actor / "perso_tire" for player fire)

https://scontent-cdg2-1.xx.fbcdn.net...1b&oe=60F428D7
https://scontent-cdg2-1.xx.fbcdn.net...35&oe=60F4051A
https://scontent-cdg2-1.xx.fbcdn.net...2a&oe=60F455FB
https://scontent-cdt1-1.xx.fbcdn.net...e4&oe=60F5131C
https://scontent-cdt1-1.xx.fbcdn.net...c3&oe=60F580BC

@Tsak, I have activated "macth direction". it's when I shoot too fast, it doesn't follow. to solve this problem, I would have to manage to add a delay and no longer allow bursts. What will be will correspond quite well to what I would like, finally.

[Mixel]

Originally Posted by earok

Experimental has been updated. A couple of notes:

- Fixed a bug where it was attempting to transition every animation, regarding of length. This means if you were transitioning from a long animation to a short animation, it would "overshoot" and play a frame from a different animation.

I'm still not 100% sure it works in every situation.

Ah! That seems to have fixed all the issues i was having already! TY again. I knew there must be a logical explanation for the shotgun thing.

Originally Posted by Kaizen35

Thanks for your help Mixel
yes, that's what I did (player position and not joystick) and it works with the "x" key but not with the pull. weird.

If you add RETURNs after each of the "play animations" in the firing code does it help at all? If it's continuing down the codeblock after running something higher up the codeblock it can run loads of these animation commands in succession without telling it to shoot in the new direction faced at the top.. (this may not help at all)

[domkid]

Originally Posted by earok

Experimental has been updated. A couple of notes:

- Fixed a bug where it was attempting to transition every animation, regarding of length. This means if you were transitioning from a long animation to a short animation, it would "overshoot" and play a frame from a different animation.

I'm still not 100% sure it works in every situation.

thanks for all this work, all my animations are working well again.

[earok]

Glad to hear that the animation bug seems to be fixed for everyone!

I'm going to take the night off doing any experimental updates, but I'll see if I can get the "thin line" AGA bug nailed over the weekend so I can get 2021.5.2 released to public.

In the mean time, NEESO Games has kindly given us a new sample for the unofficial demos repository. A clone of Pang!



Grab it from here - https://github.com/earok/unofficial-scorpion-demos

[domkid]

great, thanks to Neeso.

[Mixel]

DAMN Neeso that's awesome! Great demo.

ed: Oh and good luck with the thin line Earok!

[Kaizen35]

If you add RETURNs after each of the "play animations" in the firing code does it help at all?

Thanks Mixel, it partly works. I can now shoot faster in all directions. But very strangely, this creates other bugs (diagonal sprites are no longer the right ones, and the character does not stop even with "prevent move" activated). I'll try to see why.

Thanks Earok for Pang. It's always interesting to see how the code and the graphics are done. I could see that the sprites (balls for example) contain more colors than the project palette.
I would have liked to know if during the compilation, Scorpion stored the original images as they are (with all its colors) or if he stored the images already reduced in color, as displayed during the game? I ask when the question even if I think that it is better that the palette is the same between all the elements of the game. But also to know if it had an interest to sometimes have sprites with more colors than the palette of the project .

Another sound question. For my intro animation, I digitized the sound with Audacity, and created my sound in .aiff before renaming it as .8svx. (Miraculously, the sound comes out at the right level in scorpion, so great). It is 56kb, which is little but a lot. So I have it up a tone and it is only 23kb but is necessarily faster and louder. Can we ask scorpion to play a sound with a lower note?
One last question: which audio tracks do the sound effects use? If we play MOD music at the same time, does it have to be 3 tracks?

Thank you

[Tsak]

Originally Posted by Kaizen35

One last question: which audio tracks do the sound effects use? If we play MOD music at the same time, does it have to be 3 tracks?

You can use all 4 channels if you like. Scorpion (if I remember correctly) uses PHXs routine which automatically assigns sfx to an available channel (the sound fx system will always block the channel which would be free for the longest period). That may or may not work optimally depending on the track composition and the duration/frequency of your sfx (I don't mean hz but how often a sfx is fired up and how many will be there at the same time). For the most part this system works fine but if you're heavy on sfx (f.e. if you've got continuous shooting and explosion sounds) you might notice these interruptions. Test and see what works better for you.

[earok]

@kaizen35

Yes, as Tsak said it's okay to use all four channels for music and SFX since we're using the PHX player, though you'll inevitably get sound glitches if you there's too many sounds playing at the same time.

Pang is thanks to NEESO, I only announced the upload

The colors are reduced at compile-time, using the "closest" matched colors from the palette. The original colors are not included in the actual compiled game.

Just change the project frequency down to say 11HZ (or smaller) to have a smaller file size at the same tone (in Audacity, it's at the lower left corner).

[Kaizen35]

tks Earok,
I forgot to specify but the frequency is already 11hz. that's why I tried to lower the size even more by raising the chentillon one tone and playing it in a lower tone to have the same sound in the end. But if this is not possible, it does not matter because the sound is still very much in this way. (tested with octamed)

[Kaizen35]

ps: Tsak, thanks too !

[earok]

Experimental update, now with some fixes to edges. Tested against the motorcycle level from Creeping Me Out: Hex Night.


- WinUAE OCS/ECS emulated, seems to be fine
- WinUAE AGA emulated + Subpixel display emulation, seems to be fine
- WinUAE AGA emulated without Subpixel, a little unaligned on both sides but better than what it was.
- Real AGA, *mostly* seems to be fine, maybe a little unaligned on the right side but certainly a lot less noticable overall than what it was.


Even if it's not 100% perfect in every single scenario, I think it's better than what it was, if there's no other big breaking issues I'll do a full test against all of the official and unofficial demos before doing a new public 2021.5.2 release.

[Mixel]

Thanks, this sort of mostly fixes it! And it makes it possible for the user to 100% fix it if it's happening in their project too.

When it was happening on the left hand side of the map I tried padding out the left with black blocks and limiting the camera to stop the line from appearing and it didn't work for some reason..

Now that it's on the right hand side - you can pad out the right of the map and limit the camera range, and it removes the glitch, as it's happening off camera.

Here's what it looks like in blue barge (on my A1200, imagine the dotty line is on the right hand side of the screen I somehow forgot to take a screenshot until after I started trying to fix it, doh!), and how it's cureable with camera_xmax, so that's totally fine.

ed: included the world map showing what it looks like on the right hand side of the map. But I I've fixed it now.

ed ed: Might it makes sense to move camera_xmax and xmin into the display section instead of them only being variables?

ed ed ed: there seems to be nothing to do with flickering on either the left or the right side of the screen on my A1200, so I think this is the best it's ever been. TY!

[earok]

Eeep.

Did another check in, tweaked the DIWHIGH register a bit so corruption shouldn't show on right side, at least under emulation. I'm not sure how this will affect things on a real Amiga (haven't had a chanced to check yet)

[Mixel]

Originally Posted by earok

Eeep.

Did another check in, tweaked the DIWHIGH register a bit so corruption shouldn't show on right side, at least under emulation. I'm not sure how this will affect things on a real Amiga (haven't had a chanced to check yet)

I can test it no problem.

Probably not what you want to hear, but It's slightly worse now on my A1200, on balance.. On the worldmap even when you're not at the right hand side there's a half pixel wide line through to the copper rainbow layer. In kershaw house (with a parallax backdrop) there's no line like that though? (sorry if this is TMI!)

In the blue barge (no rainbow or parallax) the corruption is still there it's just 1/2 a pixel wide now.

edit: helps to include the right screenshot of the worldmap, oops!

[earok]

Okay, new experimental check in! Finally this seems to solve the subpixel issues (at my end at least). I would have solved it a lot sooner had I realised that, when emulating in WinUAE, I need to make sure that I'm emulating a super-high-resolution display as well as subpixels on. Technical explanation for anyone suffering from similar AGA issues in Blitz projects:

- DIWStart has been nudged by half a pixel for both start and stop
- Parallax sprites have been nudged by half a pixel
- Blitz Basic's BPLCON1 scrolling (which strangely nudges by three quarters of a pixel even when you're telling it to scroll by integer amounts) has been tweaked to only nudge by half a pixel.

That seems to bring everything into alignment with the copper sky background.

EDIT: Forgot to mention, both "Wait" and "Yield" commands accept full expressions instead of just whole numbers.