TOUKO wrote:Of course, it's a simple palette change, but it's here
And? It's such a simple technique that it doesn't really alter the feasibility on SNES/MD. The giant scaling graphic is the only part that's remotely challenging.
You sounded like you were trying to portray this as something clearly beyond the capabilities of the SNES and MD. Is this not what you were trying to say?
mode 7 is useless here
Only for this exact scenario, and only because the foreground layer isn't quite sparse enough to avoid glitching when combined with the player, HUD, and far background if all of them have to be sprites.
...okay, I haven't actually verified that the boss will fit in 256 tiles with no horizontal flipping (this being Mode 7, you can vertically flip the whole picture in between scanlines, so it's possible you could save some tiles on vertically symmetric features). If not, there's a trick that allows a 128x256 4bpp Mode 7 graphic without any compression losses, or potentially even bigger and/or more colourful if the picture compresses well. I think you could get pretty close to what's seen in your example.
Did you watch the Rendering Ranger example? Multiple independently-scrolling backgrounds made of sprites, combined with a Mode 7 boss (complete with palette fade-in). Carefully designed to avoid sprite dropout. Granted the foreground layer is eliminated before the actual fight starts, but that's probably because the player in this case can put out some fairly massive firepower, and combined with the boss' firepower it would have guaranteed glitching. Your scenario seems to lack firepower entirely; it's just the squirrel and the machine.
and even with precalc,i think you do not have the DMA budget for that,or you must drastically reduce the fram rate
This isn't a generic full-screen graphic being scaled. It's a horizontally symmetric, vertically chunky full-screen graphic. That makes a big difference. Besides, even if you did have to drastically reduce the frame rate of the scaling (as you might if you attempted it in software), that wouldn't have to affect the frame rate of the rest of the action.
The zoom is probably done by changing the X/Y harware scrolling, the copper can do it easily,but not at a 1 pixel precision.
Interesting. But I was speculating about how to do it on SNES.
With precomputed graphics it's not hard at all. Considering how chunky the boss graphic seems to be at high zoom, along with the fact that the right side is a mirror flip of the left, I figure it probably doesn't need to be more than about 7-8 KB or so if you use a BG layer for it and repeat lines with HDMA scroll changes. Considering not much else is happening, you could probably update the whole thing in two frames on NTSC, or one frame on PAL (which may actually be the more appropriate comparison). The backdrop is dead simple to do with sprites; it doesn't even move, and coverage is low, but if it's only 2bpp it can be BG3. The foreground stuff can be a normal BG layer, and the HUD can be sprites, or BG3 or a mixture of both if the far background is sprites. The only question is storage, and you can get very fine-grained scaling in a few hundred KB with no optimization or compression, if you're willing to burn that much ROM.
Using precomputed sprites might work too, and it would take far less ROM because a lot of the fine scaling could be accomplished by shifting sprites relative to one another. You'd have to be super careful with sprite priority, though, to avoid massive glitching when scaling vertically - this is one scenario where the SNES has a disadvantage vs. the MD despite its slightly higher overdraw ratio, because it's the frontmost sprites that drop out, so you'd have to dynamically fiddle with sprite priority to keep the player's sprite in front of the sprites behind it, but behind the sprites beside it. Naïvely, DMA bandwidth requirements would seem to be higher than with a BG layer because you can't stretch sprites vertically with HDMA, so the graphics for a given frame take more space, but in practice you'd have several frames to upload the required shrunken sprites because with this scheme you don't need to update the whole mess every frame. You might actually be able to get 60 fps scaling this way. The boss seems to be slightly wider than the screen at its widest point and closest zoom, but if you used window masking instead of opaque sprites to fill, say, the dark part of the jet intakes, you might be able to avoid glitching since there's almost nothing else onscreen.
With a software scaling method, you have compute time to worry about (because all that crazy maneuvering in the previous paragraph is free, right?), and the tradeoffs get more complicated. An efficient quasi-tepples method of the sort I've been considering would involve 16-bit tables, which might actually take up more space than the precomputed BG approach... 8-bit tables are way smaller but constrain the method to be somewhat slower.
Technically it is possible to change H-scroll values during a line, and it would probably work if you used DMA. However, there are at least two reasons why this is a bad idea, possibly three: 1) DMA stalls the CPU, which is very bad in the case of a full-screen effect, 2) DMA is two dots per byte, and the timing alignment inevitably results in a one-dot horizontal offset between scanlines, so it's actually impossible to change a register at the exact same point on all lines, and 3) there's significant lag in the PPU's uptake of scroll values, which may or may not cause unresolvable issues. (I'd mention the 1/1/1 DMA/HDMA clash bug, but if you can pull off a timing-critical raster effect like this you can probably avoid triggering that bug in the process - in fact you can probably just forget about HDMA entirely and use DMA to do the same thing.) So duplicating the effect as you suspect it was accomplished on the Amiga is probably not reasonable on SNES - but as I've suggested above, there are other ways that could produce good results.