> > Why? You could simply use a normal tile engine and add some stuff to make
> > clipping efficient, e.g. only parse the needed parts of the tilemap.
>
> The Megadrive has per line offset... I'm not sure how this effects the choice of
> a line-based renderer and a tile-based renderer... I remember have a bit of a
> nightmare in Final Burn with a tile based one!

It shouldn't, it's not hard to add to either.

> Had anyone actually compared a line-based and tile-based engine and the
> performance difference?
>
> If it is minimal, is there any great advantage to tile based engines at all??

Yes. For some systems it's handy to queue tiles based on priority before rendering them (e.g. systems with per-tile priorities). If you have a system that has that and masking effects when sprite-sprite priority doesn't match sprite-tile priority, it lets you optimise things more, since you already know which tile priorities you can skip. Ofcourse the sprite bit implies you're rendering everything back-to-front to one buffer and use a z-buffer to get the masking effects. This is what makes of the Cave games run full-speed on a PII-266 in FBA (except Guwange, which has a lot of out of sequence sprites). Note that FBA's cave tile renderer doesn't use queues for row-scroll/row-select modes, since those aren't used in-game, and my lazyness means I didn't optimise the rendering more than needed.