(fw to 38:30)

This is a video of FF from the wonderswan.. at that time I believe there were no shaders to use so Im guessing they were just manipulating (a copy) of the current textures being used on the scene

isnt this kind of operations kinda of slow? (for that hardware)

If I were to recreate those same effects to day on current hardware should I still be using texture manipulation routines or should I use shaders?

also about the texture waving effect: how does it never shows any black pixels? I mean the effect sways the texture from beyond the current viewable area, so unless the texture is bigger than the screen size shouldnt black pixels get displayed?

</div></div>

" Im guessing they were just manipulating (a copy) of the current textures being used on the scene

isnt this kind of operations kinda of slow? (for that hardware)"

There's a couple of approaches that work on 8/16 bit hardware.

The first would be to trigger interrupts at the start of the scanlines and to manipulate the start address of the scanline. This would work on machines with a suitably programmable interrupt generator. (Certainly Amiga type hardware could do this). Some of the 8-bits could do it with h/w interrupts. The others would do something like this with timing loops.

Pixel accurate scrolling on 8 bits was pretty much a no-no in real-time (a video ram byte encoded more than 1 pixel, so almost all games used byte scrolling which would make the waves really tricky).

On 16 bits, there were byte-per-pixel displays at which point scrolling by pixel becomes practical. One of the cunning things about this particular effect is that it's largely immune to tearing -- you don't actually have to do the pixel scrolls for every pixel line on the screen in one flyback... if (say) the bottom half of the screen lags by a field, no-one will notice...

Hardware sprites makes it all a lot easier because then you can muck about with the backdrop without needing to fret about the figures.

Actually, the platform you're looking at has a 3MHz 80186 clone CPU but an entirely not inconsiderable sprite/video co-processor; it's a 32 bit co-pro with features like sprite scaling, so I'd expect that the effect is being done on the graphics system. The extra pixels are just done by having the image bigger than the screen.

They used fancy hardware tricks. HBlank ISR to modify a background tilemap x-offset via a LUT, most likely. With the hardware that the game was for, you can do a lot of fancy hardware tricks, including faking perspective using only a 2D tilemap and the hardware graphics scaling system. GBA programming is very similar, and probably used a lot of the same tricks, but with the benefit of a slightly faster, 32-bit processor.

Standardized hardware means you can do a lot more to push it to it's limits, since you are guaranteed to know what those limits are. You'd be amazed at some of the tricks that had to go into those fancy effects that you see for 2 seconds.