Printable View
So I was watching the final boss fight in Super Turrican 2 and it grabbed my attention.
I thought it was neat because I was under the impression this wasn't very feasible to accomplish with the SNES's limited CPU. Yet here it is with some pretty fast movement to boot.
Might be some more examples out there?
That's pretty cool. I wouldn't have thought that the SNES would've been able to pull that off without a lot of slowdown.
As I recall there were some cool, multi-jointed bosses in Contra 3.
Oh Super Turrican 2, I love you so much. Also, the music that plays during this boss fight is a remix/rearrangement of the theme to the original Turrican
Well, most multi-joint objects/boss like that just used a predefined path, you just add the offset or transition between multiple LUTs. Not very CPU intensive at all. If each section of the multi-joint object has its own collision detection, well - that can slow things down. But there are ways around it, if it's needed. Anything that's constant in pattern can be offset to predefined tables.Quote:
Originally Posted by GeckoYamori
Multi-joint bosses are usually done to save on memory. BITD, it was much cheaper to use repeated sprites like spheres, cubes, etc than to draw out the animation. It would also give you a chance to do super smooth anything. By the time the SNES game out, it was kinda of an old school thing - though still around. The SNES sPPU has the graphic bandwidth to really do some fancy multi-joint options - better than the Genesis because of its better sprites per scanline limit. If the multi-joint requires more complex logic (variable position/detection/ AI, etc), then yeah - more CPU is going to be taxed. Simple just setting sprites positions by themselves isn't an intensive process.
It takes no more cycles to add 1 to a sprite offset than it does to add 8 or 16 or 50+ or 200+. It's still the same add cycle. You can almost always bet that one things increase in movement, they almost never-ever calculated collision for in between frames. A few games show this off by allowing you to get stuck in walls because of a poor detection code (or a bug in it) - basically you test to see if the object will end up in a no-no zone (like a middle of a wall) and if so, instead of putting the sprite +8 pixels to the left like from velocity value - you stop it right at the wall (or whatever physics/response should be appropriate).Quote:
Yet here it is with some pretty fast movement to boot.