SNES Axelay - Ed 209 scene, can the 1200 do it?

[mcgeezer]

A bit of a hypothetical question for all us coders here: Could the A1200 do the Ed 209 boss at the end of stage 2 of Axelay? (It was a SNES exclusive if I recall).

What do you think? I say no.... Reason = not enough memory...but I haven't worked it out as I'm assuming everything would need pre-calculating.

[ Show youtube player ]

And when I say do it, I mean including the rotation.

Geezer

[Shatterhand]

I think it's doable with some cutdowns. I'm sure you noticed the robot is divided in different pieces and most of them aren't actually rotating... For me it looks its just the big head (which is the big problem here) and its ankles.

I don't know much about the SNES hardware, but the fact this part of the level actually "hides" the parallax foreground seems to be part of the trick. If I recall correctly, just one layer of background can use Mode 7 effects (and I may be completely wrong here). I'd say the ankles are normal sprites and just the head is being rotated "real time" by Mode 7 as background.

Change this for Dual Playfield on AGA and have the different angles of the big head as different bobs preloaded. The Dual Playfield will be used so you don't have to redraw background while blitting its individual parts. I don't know if the blitter would still be fast enough, but even on the SNES its movement doesn't seem that smooth (Let's it's a wink to the way the original Ed 209 moved on the Robocop movie, not all that smooth either ), so I think it could be done at 2 frames if needed.

Also, as there's NOTHING ELSE on that moment, you could have a load just before the boss battle, remove all other non needed sprites/bobs and I think you'd have enough memory for all different parts on the standard A1200 2Mb . Like I said, if you look close, most of its parts aren't really rotating, just moving around.

[saimon69]

We tried to use something similar for Powder in a giant robot with legs and arms and we did create a number of frames for each piece at several angles (0, 23, 45, 67, 90 and go on), each piece linked to a parent and them we did create an animation switching pieces and frames by timer, or at least we tried that; right now cannot remember if we did achieve mut that seems the way to go.

We were able to save memory by using subpalettes that switched on or off some of the bitplanes or masks; however downside was using 4 bitplanes all the time with no dual playfield and 25fps for enemy updates.

[roondar]

I'd say it depends on how you want to/can achieve the effect. Looking at a screenshot of the SNES version, the robot is about 45% of the screen in size and the head is about 22% of the screen (ah, the powers of rectangular select in paint ).

The head is seemingly the only part that really has many different frames of animation (due to the rotation), so lets ignore the rest for now and focus on the head first.

There's two questions: how much space would this require if stored as animation frames and how much processor time would it take to do real time rotation. Now, I don't know how much CPU time real time rotation requires for an optimised routine. But the memory can be looked at.

It seems the head rotates at most 90 degrees. Assuming 1 degree per frame means 90 frames. At 22% of the screen for the bob and 8 bitplanes, that would take 90*18024=1,54MB of memory. Which does seem to be a lot to keep in memory if coupled with the program, player and other required sprites, display & audio memory etc.

However, if some (or all) of those frames can be rendered in real time or the amount of degrees per frame are increased (say 2 degrees per step rather than 1), the amount of memory needed drops correspondingly. So it all depends on what level of smoothness is acceptable and what speed a real time rotation algorithm can get to on an A1200.

Sadly, I don't have such an algorithm and couldn't find one with a quick Google. Also note that I've only looked at memory here - blitting the thing in any time left is a whole new question.

[mcgeezer]

Some of my quick calculations...

Agree, only the main head turns and rotates 90 degrees as well as the lower legs of the Ed209.

If we only need to rotate 90 degrees then assume that the object is 160x160 and 8 colours... that's 20*3*160=864,000 bytes.

For the flashing centre of the robot we could blit into a fourth plane and colour cycle allowing it to have up to 16 colours in Dual Playfield.

Hmmm..it would be very tight.

I may try it as an experiment though.

[Tsak]

1 degree per frame is super wasteful. Just play the above video in slow motion and count. It takes roughly 7-9 frames for the whole rotation when Ed is on the move. Add another 5-8 frames for the intro, while he is standing up.

[mcgeezer]

Originally Posted by Tsak

1 degree per frame is super wasteful. Just play the above video in slow motion and count. It takes roughly 7-9 frames for the whole rotation when Ed is on the move. Add another 5-8 frames for the intro, while he is standing up.

hmmm... not sure about this...

Might be able to get away with 2 degrees per frame but 7-9....I think it would snap to wide and not look right.

It's worth a try this... I might put in on my lest for something to try out later in the year.

[Shatterhand]

If anyone wants to have fun with it:

https://www.spriters-resource.com/sn...y/sheet/47640/

[Shatterhand]

Did it even better

90 degrees rotation, 16 frames, 16 colors on IFF format:

https://www.dropbox.com/s/8ctqucxjen...rip16.iff?dl=0

56 kb.

Now go have fun with it. (You still need to get the other parts of the robot on the above sheet and convert them )

[DamienD]

Originally Posted by Shatterhand

If anyone wants to have fun with it:
https://www.spriters-resource.com/sn...y/sheet/47640/

Send Amiten an e-mail with the above

He'll then be able to produce a new "original" game out of those sprites via AMOS, claim them as his own and finally charge an absolute fortune for it; in virtually no time at all

Mind you, as per standard, it would still be the same old mediocre game that only a 5 - 10 year old would get excited about.. and if you were stupid enough to purchase; then you'd play for one minute maximum before getting totally bored due to restrictions / scrolling / dodgy hitboxes / features / storyline / lack of originality.

[Tsak]

Originally Posted by mcgeezer

hmmm... not sure about this...

Might be able to get away with 2 degrees per frame but 7-9....I think it would snap to wide and not look right.

It's worth a try this... I might put in on my lest for something to try out later in the year.

To be clear, I'm saying that 7-9 frames is the 45 degree rotation he does while he walks. You need another 7-9 frames for the complete 90 degrees so in total around 14-18 frames.

Honestly, pixel art wise to do a smooth 360 rotation, 16 frames is all you really need (granted you won't be animating your object in extremely low speeds). So already ~16 frames for a 90 degrees rotation is more than enough. Having said that, there are a couple things to factor in: the bigger the object and the less the animation speed, the less frames you can get away with. But if you look closely at ED's animation, it's already a bit snappy, so if your goal is to outperform what's already there you could go for more frames.

Even so, 1 or 2 degrees per frame still remains a huge overkill imho. This cannot even register visually in such a small resolution and limited pixel space other than a few awkward internal pixel shifts. Just try to do a 1 degree rotation of a pixel art object in your favourite paint program and you'll see what I'm talking about

Originally Posted by Shatterhand

Did it even better

90 degrees rotation, 16 frames, 16 colors on IFF format:

https://www.dropbox.com/s/8ctqucxjen...rip16.iff?dl=0

56 kb.

Now go have fun with it. (You still need to get the other parts of the robot on the above sheet and convert them )

Yup, that's nice

[roondar]

Originally Posted by Shatterhand

56 kb.

Nice example, thanks for the file. Seems the head is somewhat smaller than I thought.

I do want to point out one very minor thing out here though: the size of the IFF file is somewhat deceptive because IFF uses compression. The uncompressed version of this would* take about 129KB (using 4 bitplanes).

That said, it does look like 16 frames is a good number - it certainly doesn't look like the steps between frames are big and adding more would probably rapidly lead to diminishing returns.

*) Including the minimum of a 1 bitplane mask that's needed for blitting.

[Samurai_Crow]

AGA huge sprites can do it if you opaque blit to the sprite buffer to save CPU bandwidth. If you have Fast RAM, realtime delta decompression (IFF ANIM) like was showed earlier wouldn't cost much chip RAM either.

There are multiple ways to try it but ultimately the hard part is getting rid of the fat left border when using all the sprite DMA and scrolling besides.

[zero]

It looks like the robot is only moving at about 5 fps anyway. My guess is that it's not using any special hardware for scaling.

SNES games that scaled sprites often used a special chip in the cartridge to do it, it wasn't built in to the SNES hardware itself, but sometimes they just used the SNES CPU instead.

To me this looks like the SNES CPU doing some simple rotating using the shearing method. Or maybe even just scanline interrupts and multiple sprites for the Y axis shear.

[Amigajay]

Ditto, that robot movement looks awful, if that was on the Amiga people would be laughing at the awful jerkiness of that boss!

[DanScott]

Originally Posted by zero

It looks like the robot is only moving at about 5 fps anyway. My guess is that it's not using any special hardware for scaling.

SNES games that scaled sprites often used a special chip in the cartridge to do it, it wasn't built in to the SNES hardware itself, but sometimes they just used the SNES CPU instead.

To me this looks like the SNES CPU doing some simple rotating using the shearing method. Or maybe even just scanline interrupts and multiple sprites for the Y axis shear.

No, the head is being rotated using a Mode 7 playfield. The rest is constructed from pre-rotated sprite frames

[Shatterhand]

Nice example, thanks for the file. Seems the head is somewhat smaller than I thought.

SNES resolution is smaller than Amiga. That's probably why it looks bigger on a SNES screen Your calculations weren't that far I believe, it's just that the SNES screen is smaller

[chb]

You could try to use blitter rotation like in Brian the Lion (intro logo/bonus stage rotating platform) or the skull in World of Commodore/Sanity. AFAIR it is a variety of the shear/skew rotation. The next frame is computed based on the previous one, and there are only quite small rotation steps possible*, but the robot's head seems to rotate slowly and uniformly. One would need to put the head in a playfield of it's own, but that shouldn't be a problem with AGA.

Still, it's not an easy effect to implement, pre-calced rotation is for sure the more pramatic way to go, esp. with the A1200.

*max stepsize is atan(1/16) I think, y-shear is done by alternating between two sources (same data but a line below) with a mask in BLTCDAT, so one pixel y-difference per 16 pixel width

[turrican3]

Flink have also rotations (apples), zoom (monsters from the river) and big final bosses.

[Hewitson]

Originally Posted by Amigajay

Ditto, that robot movement looks awful, if that was on the Amiga people would be laughing at the awful jerkiness of that boss!

Really? I actually thought the boss was fairly impressive. There's few bosses on the Amiga that have had as much work put into them as this one.