Re: [MiNT] XaAES sources for FreeMiNT 1.16.3

[Johan Klockars <johan@klockars.net>]

>> 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

Please, take a look at what I wrote a few minutes ago.

> 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.

I want to prevent it exactly to avoid this existing source of
incompatibility (and to improve speed on modern hardware), which you
just mentioned.

>>> 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
...
> No, they're doing it because that's the only available option at the moment. There are

Well, it is not an option at the moment, really, if you want your
software to run everywhere. See the Eclipse/RageII and accelerated
ARAnyM.

Anyway, I only meant to question the assumption that people "want" to
access video memory directly. They've "had" to in the past, but the
world has changed and it is no longer a good way to get good
performance (unless you are still using the same old hardware).

> currently no graphics drivers for any commonly available hardware which provide what you're talking about. Correct me if I'm wrong.

You are not wrong.

>> There is simply no way you can compete with accelerated graphics
...
> 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.

True. Again, see what I wrote recently.

> 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
...

There's no reason why the C2P could not be done by the VDI while
blitting. Granted, doing less than all the planes is not something
that would be useful in more "normal" cases, but I still would not
have any problems with the VDI doing that.
I was actually experimenting with using less than four planes for text
windows in 16 colour mode on my Falcon in the early days of fVDI.  ;-)

/Johan