Scorpion Engine

[Mixel]

Ah great thanks! Noisy animated platforms here I come!

One bug I’ve noticed is - it doesn’t flash when it fades/loads levels but it does when I fade out/teleport/fade in which is what happens when the player dies/respawn a in CMO.. I think it might be worse in levels with copper stuff in the background. (It also might be exacerbated by me overwriting the palette with its default state, which I also do on death, not sure?)

[earok]

New check in time to experimental and CMO branches.

1) Fixed bug reported by NEESO games where, on a lower end Amigas, a static screen with 5 or more bitplanes may flash once or twice upon loading
2) Fixed bug reported by Mixel where jumping off a ladder didn't work (specifically, there were two bugs - one that reset the jump button when an actor type is changed, one that didn't immediately reset the movement type when an actor type is changed)
3) Fixed bug reported by Mixel where changing palette during "faded out" screens caused graphical glitches

[Mixel]

I .. cant find anymore bugs yet. Thanks again for fixes.

Do you think it's safe to update to the new Tiled version? I guess I could try it and revert if it messes anything up.

[earok]

Originally Posted by Mixel

I .. cant find anymore bugs yet. Thanks again for fixes.

Do you think it's safe to update to the new Tiled version? I guess I could try it and revert if it messes anything up.

I guess so? haha. Let me know if you have any problems with it.

Just pushed a new update to experimental.

1. Minor fix, forgot to add something to the Unity Editor that was present in the previous version. SetPanel now has settings for setting the time delay or waiting for joystick fire (making coding for static screens slightly simpler)

2. Rather than just sitting there static, the Parallax background can scroll at an independent speed to the foreground.



To actually use this, set the parallax distance setting to at least 1 (the higher this value is, the slower the background moves relative to the foreground). 1 is probably the best value for most situations, it can look a little jerky at lower speeds.

Note that it uses the trick from Video Kid to reduce memory usage to 8 copies of the background, rather than 16.

[Havie]

Looks really good and excellent sense of depth! Keep up the good work.

[Mixel]

Oh my! That adds so much depth and life to it! Working great here.

How difficult would it be to implement SNES Jim Power style "oh my god why is the parallax going backwards this makes me feel sick" by entering minus values? 99% of the time you'd not want to use this but.. It could be a nice option if it's really easy to add (some boss levels and stuff, places where you're circling something in the background, could be neat.

So far no problems with latest Tiled either, hehe.

[earok]

Cheers @Havie @Mixel!

Actually, I think it would be fairly easy for Jim Power SNES puketastic parallax. Let me think about it though.

Anyway, new update for the day:

1. Fixed issue reported by NEESO games (error thrown when adding an animated tile on top of another tile doesn't specify which level has the problem, this has been fixed)

2. Error messages have been simplified considerably. The "stack trace" (which indicate which line of code in the editor tripped the error) only shows up if it's an actual bug with the editor, if it's a problem with the project it should show a much shorter message.

3. Addition of Platform class (use instead of defaultclass etc) for turning an actor into a platform that the player can stand on. It's not extensively tested BUT it does seem to support horizontally and vertically moving platforms (as well as those that are both)

[earok]

Minor experimental update for the day:

General improvements to the platform class, which include:

- Platform actor collisions should still work as usual (so if you want a shootable platform, for example, that should work)
- Player collision detection still works when riding a platform (so if you've got a low ledge, the player will be pushed off)
- The mechanic for a player getting on the platform has been tweaked slightly so that they won't shoot up noticeably if their jump was just short of the top edge.

A side effect of that last one is that, if you've got a platform that goes up through the ceiling, the player will be pushed down through the platform rather than riding it upwards through the ceiling (I can't say I'm familiar with any games that actually do that, but that's the behavior here).

[Mixel]

Ah thanks again for another update.. I got my first wavey actor working today.

This is weird, at some point in the last week or so CMO stopped working on 2MB unexpanded A1200.. It just kicks me out saying

Exited with Error?
Exited with Error?

(it says it twice, dunno if that's important) - It runs fine if I add just a single MB of Fastram.. So I guess I'm out of memory.. The level using up the most RAM in .gfx and .map is Tunnels2.. I might have to reduce its size.. I can trim quite a lot off probably but it'd be really nice if it broke down how much ram each part of the game had allocated to it, so I could know to keep it within that budget, or trim, some sound effects or something. my Project.gfx is currently 918KB.

[earok]

It's probably the scrolling sprite background that was the straw that broke the camel's back (it uses some tricks to be as efficient as it can be, but in any case the entire sprite background needs to be stored eight times at different offsets in order to be smoothly scrolled).

I'm not really sure what the solution is other than trimming down assets. Converting from EHB to 5BP would reduce the size of all of level and actor graphics (and the screen buffer) by nearly 20%, though I figure that might not be enough in the long term.

[earok]

Minor check in to experimental, not extensively tested.

- Fixed some issues with loading and displaying a static full screen image when a level is loaded.
- Fixed an issue where sometimes, unloading a level wouldn't resume the codeblock.

[Mixel]

Originally Posted by earok

It's probably the scrolling sprite background that was the straw that broke the camel's back (it uses some tricks to be as efficient as it can be, but in any case the entire sprite background needs to be stored eight times at different offsets in order to be smoothly scrolled).

I'm not really sure what the solution is other than trimming down assets. Converting from EHB to 5BP would reduce the size of all of level and actor graphics (and the screen buffer) by nearly 20%, though I figure that might not be enough in the long term.

That’s good to know it’s something I can potentially fix. I’ll keep massaging things. (I can try just compiling it as 5bp and see if it’ll load then too, hadn’t thought of that)

Is it currently not loading the game at all as it can tell that it won’t have enough memory for a specific level? Because my most memory eating level from the .gfx perspective is tunnels2, and that doesn’t have any parallax. Parallax doesn’t kick in until tunnels1.. hmm. (After the barge and map) I can kill a few sound effects easily too. Lots of options for me to tinker with.

I guess I’m right in thinking a backdrop with fewer colours in it should take up less memory too, I could definitely tone down the copper stuff, haha.

[DamienD]

@Mixel; I don't think it really matters if your game runs on say 2MB Chip and 4MB Fast RAM.

I'd say most real A1200 users at least have that.

IMHO it's best not to cut down your game, remove cool stuff / features just so that it will fit into 2MB Chip RAM only.

You're game should be the best it can be, without sacrifices

[Mixel]

Originally Posted by DamienD

@Mixel; I don't think it really matters if your game runs on say 2MB Chip and 4MB Fast RAM.

I'd say most real A1200 users at least have that.

IMHO it's best not to cut down your game, remove cool stuff / features just so that it will fit into 2MB Chip RAM only.

Thanks I really appreciate the input as I’ve had people from both sides haggling me up and down, hehe. I’m with you, i just occasionally second guess the decision; I’ll go all out and see what can be trimmed down/optimised after the fact. If it ended up being a case of just using copper rainbows instead of parallax to make it run on 2MB machines that’s a very easy extra build of the game I could do.

[earok]

My personal two cents is I'd aim for the stock of whatever Amiga you're aiming at. 2MB would also allow for a CD32 launch, though CD32 should be easier to achieve <2MB on due to the game being launched directly instead of through workbench (also CD music support will come sooner or later).

Let me keep thinking about a potential solution. An overlapping problem is that Scorpion (currently) offers no support for multiple disk games. If there were a way of dividing up a Scorpion project into several "disks", you could take advantage of this to keep the overall memory consumption down even if you only release as an HDD installable game (eg, you'd have one disk in memory at a time, and Scorpion would silently load the next "disk" into memory if you were on HDD, but would prompt the user to change disk if they were running from floppies)

[nikosidis]

Originally Posted by earok

My personal two cents is I'd aim for the stock of whatever Amiga you're aiming at. 2MB would also allow for a CD32 launch, though CD32 should be easier to achieve <2MB on due to the game being launched directly instead of through workbench (also CD music support will come sooner or later).

Let me keep thinking about a potential solution. An overlapping problem is that Scorpion (currently) offers no support for multiple disk games. If there were a way of dividing up a Scorpion project into several "disks", you could take advantage of this to keep the overall memory consumption down even if you only release as an HDD installable game (eg, you'd have one disk in memory at a time, and Scorpion would silently load the next "disk" into memory if you were on HDD, but would prompt the user to change disk if they were running from floppies)

Normally if the situation is like this people have to wait for whd-install.
Support for more than 1 floppy would be nice

[Mixel]

Originally Posted by earok

Let me keep thinking about a potential solution. An overlapping problem is that Scorpion (currently) offers no support for multiple disk games. If there were a way of dividing up a Scorpion project into several "disks", you could take advantage of this to keep the overall memory consumption down even if you only release as an HDD installable game (eg, you'd have one disk in memory at a time, and Scorpion would silently load the next "disk" into memory if you were on HDD, but would prompt the user to change disk if they were running from floppies.

Yup sorry for being so gung-ho with such a broad project. Don’t mean to force any type of optimisation over any other things you might want to work on. Good luck with a solution though. I’m happy to adjust the target to whatever works. CD32 would definitely be great though. (I think it’ll make most sense as a target by the end)

[saimon69]

Is not 'forcing optimisation' rather 'real world development problems' imo, read: sooner or later a dev would stumble on this

[Cobe]

Well its not like Mixel is coding the game itself without game maker engine and someone's gonna tell how couldn't you make it run on stock A1200, Jim Power runs on A500..........
If Commodore lived a year or 2 more, fast ram for A1200 imho would become mandatory like 512k for a500 and it not only adds memory but doubles the speed.
And most of us "active" cd32 users have at least tf328. Look at the lists on Amibay..

[Mixel]

I only meant I wasn’t expecting CMO memory issues to be a pressing priority and I didn’t want to divert attention from other facets.. I likely find feature updates way more exciting than optimisation / asset management updates and I’m in no rush at all, haha. (I imagine feature updates are more fun to work on too but I wouldn’t find any real programming enjoyable so I may be wrong there, lol)