Re: [MiNT] XaAES sources for FreeMiNT 1.16.3

[Peter Persson <pep.fishmoose@gmail.com>]

On 9 dec 2009, at 22.41, Johan Klockars wrote:

>> The original TOS has a low level video API (XBIOS). I see no good reason not to keep this approach. Maybe if there was a good alternative - but the VDI does not constitute that alternative. The lack of a good low level API effectively shuts out games and demos completely,
> 
> That the current VDI does not make a good alternative does not mean
> that an upgraded one could not be.

Ok, but now we're talking about something that does not exist. I'd be the first one to applaud a good alternative, because I want my full screen stuff to work well on all kinds of graphics hardware (and I've been through hell to get my stuff to work on the ET4K and Mach 64). But let's be realistic. Preventing applications from accessing the framebuffer directly would mean yet another source of incompatibility.

>> which is unfortunate. Accessing video memory directly is something that people want to do.
> 
> Only because they are used to it and it makes some things easier. If
> they are interested in real performance (on modern hardware that is),
> they are going to have to work with the graphics drivers, not against
> them.

No, they're doing it because that's the only available option at the moment. There are currently no graphics drivers for any commonly available hardware which provide what you're talking about. Correct me if I'm wrong.

> There is simply no way you can compete with accelerated graphics
> hardware by writing directly to the screen. Often such direct access,
> when it is at all possible, is very slow indeed (as in tens to
> hundreds of times slower than what the hardware is capable of when
> used the way it is intended to be).

Ofcourse not. But again, in most cases we're not actually talking about modern accellerated graphics hardware. It would be wrong to impose a significant performance penalty on the majority of the users for the sake of something which doesn't really exist in practice.

> The VDI could easily be extended with masked/alpha blits, blit chains,
> etc. Unlike if you were drawing directly to the screen, such things
> could be done entirely on a graphics card, using Gigabytes/s of
> bandwidth. If you absolutely must draw yourself, at least use
> something like SDL and let it have the graphics driver deal with
> blitting everything to the card (having a graphics card use its DMA
> engine to fetch data from normal RAM is usually many times faster than
> trying to write things to the card's framebuffer yourself.

Well, to get good performance I'd stay away from SDL (no offence Patrice - your SDL port is bloody great and I do use it for lots of stuff) and use a copyspeed C2P-rout which only converts as many bitplanes as I actually need. Now, if I didn't have access to the framebuffer, I'd have to perform the conversion in fastram, in which case I loose the advantage of the copy speed conversion, and I get an additional performance penalty while the data is copied to ST-RAM. That'll be the difference between 50 and 20 FPS.

Having said all this, I do welcome a better alternative. But I want to see that alternative for real before closing the door to the solutions we already have.

-- PeP