Except that the Turrican games which all 3 ran at 50/60-FPS did full tile-based displays with scrolling in all directions in the non dual-playfield higher color-modes and on top did all kinds of tricks to add parallax, including copper-skies, multi-plexed sprites, and more crazy tricks. All while they were throwing around tons of objects, all blitter-based. So your statement that an entire frame gets eaten up by doing tile-based displays is completely wrong, Turrican 1-3 prove it can be done extremely cheaply.
If you're Manfred Trenz, sure. One of the very best technical coders of his day, and factoring that in his original C64 version of Turrican is actually even more impressive considering the hardware limitations.
Generally though, you're severely understimating the magnitude of difficulty.
The "cheap" way of doing scrolling on the Amiga uses screen pointer manipulation. Its fast, but not free because you have to do the edge-updates using regular blits. The edge updates uses fake tiles, because you are always writing to bitmap UNLIKE either MegaDrive or SNES which had actual mapped tile playfields.
The difference being that changing a single 16x16 pixel tile on the consoles involved writing a single word, on the Amiga that was 16 blitter writes per bitplane, so 16x3 per tile, per layer assuming your configuration is 2x 8colour dual playfields. So, 48x slower plus the additional overhead of tracking write position (no DMA-delay to help you out) as the display area drifts according to "map" position, and the additional overhead of all those bitplanes eating into cpu overhead.
Also, to stop the edge-update eating into frame-time you have to carefully manage the screen scrolling to limit scenarios where you're forced to update both a horizontal and a vertical edge at the same time, and allow you to pre-cache your new data into a single blit to lower cpu-cost.
Trust me, I've written scroll routines for both, and Amiga is vastly more complicated.
I don't think anyone ever multiplexed sprites per se on Amiga either; traditional multiplexors like on c64 essentially were used to put more "actor" objects on-screen (baddies). On the Amiga each sprite was effectively too small to be used for much as enemies tended to be larger in terms of pixel dimensions and all multiplexors are hamstrung by the hardware setting finite limits on how many can be drawn in the same horizontal band,
On the Amiga, ironically they more often tended to be used by force-loading data into the registers in a repeating pattern to create an additional fake scrolling layer. The only snag being doing that essentially locked out the CPU for the duration of its display.
Leander/Galahad is a good example of all the techniques I've mentioned. Jon (Burton) was an extremely good 68k coder, although to be fair a lot of his tricks were straight lifts of known demo-scene techniques which is why they tended to have quite specific limitations in application.
Which in the end, is kinda the crux of the matter. If you have to dig deep into your grab-bag of tricks and do a bunch of very technical code to do basic stuff like drawing objects and scrolling the screen, it leaves you less time to work on the rest of the game. It even affects the design because., for instance, the pointer-scroll technique while way quicker than doing it the orthodox way (full screen copy and shift, or redraw every tile on update) means you can't wrap your scrolling playfield around on itself.
Coming from the Amiga, Megadrive/Genesis was easy mode. Night and day different. The 68000 was even clocked higher on top of the entire raster update basically only requiring you to prime the VDP with data and set it to trigger DMA download on VBlank... It was cake by comparison.
www.lemonamiga.com
Ah ... the good old days ... it even happened once or twice the police entered the building and the whole place erupted in panic and mayhem. This video is a good snapshot of those heady youthful days.
