Re: [MiNT] XaAES sources for FreeMiNT 1.16.3

[Johan Klockars <johan@klockars.net>]

> What is AES if not a Window Frame and Widget render driver? What part
> of "interacts with screen layout and graphics rendering" is not
> covered by "algorithms dealing with bitmap textures, 3D work, an RGD

Well, the AES should not really need to bother itself much with such
issues. That is mainly the domain of the VDI.

> and since when do demos not include "bitmap", "texture", "vector" and
> "effects" ASM routines that are highly (even tortuously) speed
> orientated while maintaining visual quality

As I mentioned earlier, the problem with demo code is not that it is
not fast or pretty, but that it is very specialized. I would be
surprised if we could uncover more than a few scattered bits and
pieces that would be useful for the VDI. Especially considering that a
modern machine is not likely to be using any of the graphics hardware
the demo code has been written for in any case.

> (initially) a large amount of work involved, but as you will become
> aware, the best parts of fVDI are ASM, the parts in C have bee
> neglected simply because there was no one to pay them special

Actually, many of the C parts of fVDI are newer than the assembly.
Some things got written in assembly only because certain other parts
were, without any real performance reason (and some of the performance
reasons were no better than - "I want to beat NVDI at <insert test
program here>" ;-). When I last worked on fVDI I was rewriting some of
those things in C, for the same reasons others have mentioned.

The monochrome driver is 100% assembly, but much of that code dates
back to my monochrome ST days (I only had a monochrome monitor back
then, and wrote some rendering code for my QL emulator). Later I was
often using monochrome mode on my Falcon, for performance reasons, and
parts of the monochrome driver is reused internally in the fVDI engine
(text rendering).
There was never any question about not writing the RageII driver in C,
however, and it wouldn't have been significantly faster in assembly.
The last performance optimization I was working on was for the
bitplane driver, in C...

> attention. unfortunately for you and me, those part most neglected (or
> most rudimentary) are the same parts you an I would use on a regular

I think it might be a good idea to work out who the user will be here.
How important is bitplane and FalconTC really these days?
Still, there is certainly a lot that can be done to improve the speed
for the old graphics modes, especially on more modern hardware (I had
some good results using shadow buffers in FastRAM on my AB040).

/Johan