Scorpion Engine

[Tsak]

Originally Posted by malko

@acibottle & @Mixel : I agree that a "Scorpion" Sub-forum of, let's say, "Coders.Language" can help in the organisation of the information.

I should also mention that creating a subforum here isn't gonna be much helpful other than having seperate threads. There are still a ton of other subforums here and navigation suffers. People wanting to get informed on the latest on Scorpion still need to rely on the 'today's posts' option or they need to pay a visit to each and every Scorpion thread seperately. This most certainly won't help me or Erik to maintain them either. Plus we need to rely on the local moderation to do literally anything.

On discord we can do all the above much, much easier. This thread will still be kept -of course- for anyone wanting to stick around. Both me and Erik visit this forum daily (to get our updates on all the wonderful projects going on) anyhow.

[Tsak]

Anyhow, I should mention it's not a 'done deal' yet as we're still thinking about it.

[acidbottle]

@ Mixel and Ultranarwhal

Thanks for the suggestions on this, wasnt so far off with logic but needs some refinement I think. Will definitely try using the block as the actual spawnpoint if I cannot get my code to function!

The top of the map collision (or lack of) is intended. The collision box can be adapted so that your char just bumps off the edges but I turned off these collisions so the player can leap out of sight, briefly. Never thought the panel might actually be an issue so will investigate that later for sure, many thanks

I am certainly, if not too clear in my earlier post, all for a 1 stop shop for all things scorpion, just my personal issues with discord are my issues to sort! I think its a fantastic idea, just will still need to put my comments here instead because of them. So long as EAB thread isnt forgotten about all is good and sounds like everyone is a winner!

[UltraNarwhal]

Bug (?) on latest experimental build - fire button attack is ignored, unless tick the autofire option.

[Mixel]

Originally Posted by UltraNarwhal

Bug (?) on latest experimental build - fire button attack is ignored, unless tick the autofire option.

I'm also having this bug in CMOhn.. Eek.

[malko]

Originally Posted by Tsak

[...] Plus we need to rely on the local moderation to do literally anything. [...]

Current team lack velocity, that's true. But I'm sure they are doing their best.

[Tsak]

Originally Posted by malko

Current team lack velocity, that's true. But I'm sure they are doing their best.

No, it's not that. EAB team does a fine job. But it's another thing to have admin powers for yourself. Simplifies things much.

[gimbal]

It's not like RCK is shy about giving people admin rights on a specific subforum though But Discord is simply a better choice, Scorpion should be bigger than EAB.

[Mixel]

Uh oh.. Two engine questions!

Could there be an equivalent of “on spawn” but for .. blocks? Just a routine that runs once when they first appear on screen, rather than every 5 ticks when they animate. (Also, I’m not at my computer atm, but if I set its animation frame to itself will it still run the codeblock while not actually animating at all? That could be very useful)

Other question is to do with the “creases” in parallax. It’s easy enough to cover the 18th lines, but I’ve found there are heights you can jump in specific conditions that trigger artifacts on the screen. (Generally as you jump to a height just below the seam) You don’t have to be moving left/right, just up/down. I’ve got a whole host of ways of minimising them and ensuring the player can’t trigger them but they’re complex workarounds.. Are the graphical glitches likely to be a permanent engine fixture and just a byproduct of vertical motion on complex horizontal patterns? (Not a complaint if so) - or will it be revisited to try and remove them, as it’ll save me quite a bit of time doing strange hacky looking things in Tiled.

For reference the background glitch tends to look something like this:


One thing I haven’t tried lately is turning on all the AGA stuff.. Maybe it stops then. Will check in a minute. (ed: No difference what ever AGA/F-mode settings I choose)

[Clydos]

Originally Posted by Tsak

Hey guys, currently me and Erik are setting up a new Discord server which will have a dedicated Scorpion section with all the necessary threads. I think this will help much the (ever growing as it seems) Scorpion community to have such a centralised and extended place to call home, get help, showcase their projects e.t.c.

Thank you! I think this will work well, additional to this EAB thread!

[Tsak]

Originally Posted by Mixel

Could there be an equivalent of “on spawn” but for .. blocks? Just a routine that runs once when they first appear on screen, rather than every 5 ticks when they animate. (Also, I’m not at my computer atm, but if I set its animation frame to itself will it still run the codeblock while not actually animating at all? That could be very useful)

That's interesting, I think I might be needing this also as I'd like to be able and setup block based enemies. There is another solution though, you can link the block to an invisible actor and adjust the behaviour from there. I've done something similar with the turrets in the Chaos Guns demo (though the actor there -head- is visible).

[Mixel]

Originally Posted by Tsak

That's interesting, I think I might be needing this also as I'd like to be able and setup block based enemies. There is another solution though, you can link the block to an invisible actor and adjust the behaviour from there. I've done something similar with the turrets in the Chaos Guns demo (though the actor there -head- is visible).

Thanks! That'll actually work for me and I'm not sure why i didn't think of it.. I wanted a routine to run on the blocks appearance that then modifies the placement of those blocks (essentially shuffling the blocks with each other) but I only want it to happen at level start. But the blocks are going to be in different places on a per level basis, so baking the logic into the block code made more sense to me than putting it in the level code.. (it.. Made sense in my head anyway lol) So what I need to do is not place these blocks at all in Tiled, I need to use an actor that creates those blocks instead!

---

Nobody asked, but others are likely to run into the same issues.. Parallax stuff!

Those parallax seams I mentioned above.. I'm dealing with them by designing chunks of the background around the player's likelihood of being at different heights.. So in an area I know for a fact they'll be jumping up to a problematic height, rather than black it out entirely (like i do in the underground boss level.. i doubt anyone noticed!) - using the "weird parallax colours" you can make the parallax into basic copper gradients instead, which don't display any of the glitches.

Alternatively: Avoid making the map more than 18 tiles tall, and this never comes up, haha.

If other people have found other ways of dealing with it I'd like to share notes. (Czorny has a lot of vertical movement in Morci!)

Another thing with parallax is occasional lines leaking into the black border.. I found you can completely remove these by isolating where they happen and moving the problem line's first colour one space to the right in the .parallax png and putting black in the left hand column. If you want to ensure it never happens at all you can just move the whole lot to the right and fill the left bar in black. (this limits you to 3colours per line+black, though) - I'm not sure if there are any disadvantages other than the loss of a colour, it's been solid here.

eg:

And an area I've protected against glitches:

[earok]

https://github.com/earok/scorpion-editor-experimental

Eeep, wish I had seen the reports about the autofire bug before doing a new build! Sorry about the radio silence past few days, been very busy with IRL stuff.


Today's update might be the last in a few days, I really need to get off my ass and get Retro Animator published.


* Built with a more recent version of Unity (hopefully that shouldn't affect anything)

* Included the source code of my two player gamejam game. I included it because I thought it had a working example of multiplayer melee combat, but on closer inspection that isn't the case - so I'm not actually sure if melee combat does currently work between two controlled characters or not! In any case, it might be useful as a reference and is intended to be included in the official demos pack eventually.

* Fixed an issue where sprites were misaligned by half a pixel. Normally this isn't really noticeable, however it becomes apparent when it's configured so a character switches back and forth between bob and sprite rendering - a character would seemingly at random jump half a pixel to the left. This hopefully fixes the issue in AlarCity and Wizonk.

* Renamed "joystick 1" and "joystick 2" in the events panel to be clearer (now they're "port 1 (player 2)" and "port 2 (player 1)" to be unambiguous).

* Default actor type is CPU, not Control (suggested by NEESO).

* Spent a fair amount of time pruning the copper list. In general, this should (marginally) boost performance on fastram-free machines, as well as reduce the overall amount of chipram needed. Every single line of the copperlist has been reduced by at least two instructions per line, and the copperlist generation is smart enough to know not to change the colors on the copper when it isn't needed (when a parallax image doesn't change colors much, for example).

This *won't* fully fix bugs resulting from the 18th tile wrap-around that Mixel highlighted above, but maybe it might make it a little better in some cases?

[Clydos]

@Mixel: Nice that you found a solution/workaround and share it here, thanks!

@earok: Thanks for the update! Two player mode is definitely very interesting. I wonder how Mixel will support up to FOUR players in "Wizonk" though!? :-)

@all: As erok mentioned "Retro Animator": Currently I see three different tools that the people here are using for pixel work:
- Pro Motion NG
- Pyxel
- Aseprite

First, I am unsure whether those tools do literally the same or are there big differences? Which one is better (if you can say), maybe one is better for a certain task (pixeling, animating, ...). I am no graphic artist at all but I want to do at least some basic work but I am not sure which tool would be best.
And how "Retro Animator" comes into play here. Will that be another tool in the same line as the above mentioned or is it "just" a subset (animating)?

[earok]

@clydos Scorpion already supports the standard four player adapter for Amiga (eg, like the one that came with Dynablaster). I should maybe look at keyboard sometime.


I haven't used those pixel art packages myself! RetroAnimator is solely an animator, it can't make any pixel art, what it can do is create fluid animations out of pixel art (eg, like in Metro Siege).

The main difference between RetroAnimator and the animation component of Scorpion is that you can assemble frames out of multiple body parts and such (as such, they're not directly compatible, though I could maybe look at making an export tool for RetroAnimator into Scorpion)

[Clydos]

Thanks for the heads-up, earok! This was helpful.

[Mixel]

Originally Posted by Clydos

@Mixel: Nice that you found a solution/workaround and share it here, thanks!

No problem!

@earok: Thanks for the update! Two player mode is definitely very interesting. I wonder how Mixel will support up to FOUR players in "Wizonk" though!? :-)

Like Earok said.. Also luckily in WinUAE it’s really easy to assign the adapter to multiple sticks, WASD and Cursor keys.. The difficulty is more in testing it as I’m not an octopus.

Currently I see three different tools that the people here are using for pixel work:
- Pro Motion NG
- Pyxel
- Aseprite

First, I am unsure whether those tools do literally the same or are there big differences? Which one is better (if you can say), maybe one is better for a certain task (pixeling, animating, ...). I am no graphic artist at all but I want to do at least some basic work but I am not sure which tool would be best.

Everyone will have different ideas on this but if I was to suggest one app to keep things simple with some really excellent Scorpion friendly features, I’d go with Aseprite.

Pyxel is missing a ton of quality of life drawing features but is great for easy tileset creation/management. Pro Motion (likely?) has all the features of all of them, and is incredible for palette management and doing parallax backdrops, but IMO has a hyper fiddly interface and very steep learning curve. I think some people must just click with how it works though, I’d try the free version. (I think it’s also most expensive option to buy?)

If you want something REALLY like DPaint/Brilliance - GrafX2 is free, powerful, supports ocs colour restrictions, etc! I’d say it’s interface is non-optimal if you want to have a bunch open on screen at once, etc, but for basic editing it should be fine. (It’s simultaneously the easiest and least easy of the apps to understand, depending on your experience with old apps because of how much it acts like Brilliance.)

I’m going to try streaming in a moment, mostly doing graphics/tileset stuff (for both games) I’ll try doing a bunch of comparitive app feature stuff in it too? Ed: OBS issues, not sure I can stream for an hour or two while I sort it all out lol.

[acidbottle]

Retro animator may be something I will use a fair bit, look forward to trying this out.

@ Clydos - For me, I think Aseprite is a very easy to use 1 stop shop for all things pixel art related. It has a few minor drawbacks that may require certain other programs but its generally my go to at the moment.

Now, I am nearly finished with all the core function of my particular creation, with many thanks to everyone on here so far. The last feature I need may require an actual earok intervention (sorry earok ) as I cannot see anywhere how this can be done. Essentially I need to be able to hold down the fire button for a length of time to activate a codeblock. Is this possible with scorpion currently?

[earok]

Originally Posted by acidbottle

Now, I am nearly finished with all the core function of my particular creation, with many thanks to everyone on here so far. The last feature I need may require an actual earok intervention (sorry earok ) as I cannot see anywhere how this can be done. Essentially I need to be able to hold down the fire button for a length of time to activate a codeblock. Is this possible with scorpion currently?

Is this for like a cheat, or a charge up, or..?

May be able to do something like this

firetimer = 0
while control1_fire != 0
firetimer + 1
yield for one frame
if firetimer > 50 ;held for one second
goto the codeblock
end condition
end condition

If you call this from an ontimer expired (with 0 frames), it -should- be okay since the yield should stop ontimer from running again until the fire button is up again

[acidbottle]

Thanks for the lightening quick assist!

It is indeed a kind of charge up and will try this out later Thought about a button press timer but couldn't figure out exactly how, so this is awesome.