[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[MiNT] ARAnyM vrt_cpyfm extensions for font antialiasing (was: Re: Bit-Depth and Graphics stuff....)

Hi!
WRT antialiasing. It is quite an easy driver extension. In case the HW handles the alpha blitting it is supposed to be actually faster compared to the common monochrome glyph rendering way as there is no need for FreeType2 to generate the mono 
bitmap from the 8bit grayscale which is used for antialiased fonts.
As for the VDI extension I only needed memory to screen 8 bit vrt_cpyfm and so I extended the vrt_cpyfm (expandeArea method of the driver) so that it understands 0x100 bit of MFDB.fd_stand as the source to be 8bit grayscale. This could of course be worked into a more generic blitting API extension, but I only implemented what was 
necessary.
In ARAnyM this is only implemented in the fvdi_soft.cpp (doesn't work in the OpenGL 
mode). You can have a look at the code here http://cvs.aranym.org/cgi-bin/viewvc.cgi/aranym/src/natfeat/nfvdi_soft.cpp?annotate=1.33
starting on the line 395.
Another extension I played with was to use the NFVDI driver from Linux framebuffer where the bitmaps were not word aligned in memory. So I am missusing the MFDB.fd_wdwidth as a number of bytes per scanline in case 0x1000 bit of MFDB.fd_stand is set. Unfortunately the framebuffer code was not adopted upstream as I didn't finish it (sent to the 
debian mailing list).

Best Regards

Standa



On Jul 17, 2010, at 4:47 AM, Paul Wratt wrote:
On Fri, Jul 16, 2010 at 10:15 PM, Johan Klockars <johan@klockars.net> wrote:
I'm not scared of VDI code, I just don't think I'm the right person to implement new APIs for that kind of stuff :)
Why? You understand VDI from 'inside', you can always make a proposal 
and let other comment it (esp. Johan, as he is an author of fVDI ;)


I'm even reading this.  ;-)

Someone mentioned the fVDI CVS (or rather klockars.net) not being
available, which should be corrected now.
(I just bought a nice new WLAN router and it has apparently decided to 
reset itself once or twice, getting new dynamic IP addresses every
time, and thus causing my static DNS setup to fail. I've tried to keep 
up with that, but apparently my web server also lost its default
router setting for some reason...)
Maybe you'll get some critics but if, in your eyes, wont be convincing 
enough, you can still say "this is how I done it, feel free to do it
better". Even if Johan wont agree, it's GPL, you can fork it. No harm 
done, no code power wasted.
I'd hope to avoid a fork, and I'm all for these kinds of updates to the VDI.
A special blit mode would help a lot on standard graphics hardware - blit with on-the-fly C2P. That means the application has a simple and fast way to render data, and that the low ST-RAM bandwidth will be used efficiently. 

Yes, that is something that could definitly be added.

I always intended to write an actual chunky 8 bit driver, with such
blits being done in the background, but I suppose that wouldn't really have been very useful. Still, I believe it would be better to have the 
function not specifically do C2P, but rather extend the possible
source modes to include "chunky palette mode". That way it would be
useful even when the display is really chunky itself, but perhaps true 
colour.
The SuperVidel has alpha-blit capabilites. That would also be nice to have in the VDI. 
And another one more reason for you! :)


I believe Standa added something along those lines in the ARAnyM
driver to do the anti-aliased vector fonts. But it is possible that it 
was not a generic solution. Anyway, I'm all for alpha blits (unlike
those "interesting" blit modes that NVDIv5 added...).

/Johan


Thanks for adding your 2 cents worth Johan...

I believe Standa also keeps an eye on the list too, maybe he will add
a comment about "alpha-blit capabilites" if that is what he added (to
do the anti-aliased vector fonts)

Apart from that, its seems that now is a good time to supply some code
and a proto-type to extend the API.

And I believe that Johan hit the nail on the head about the crux of
PeP/Michael dialog:
""
.. I believe it would be better to have the function not specifically
do C2P, but rather extend the possible source modes to include "chunky
palette mode". That way it would be useful even when the display is
really chunky itself, but perhaps true colour...
""
This allows both points of view to be handled, and the inclusion of
alpha channel as well, all of which would solve m0n0's problem of how
to handle the situation.

On API proposals, I hark back to the use of wiki in making them
available in a permanent form (as opposed to the list or a text file),
as this would allow for more preliminary API definitions and the
possibility of additional code being added (to fVDI at least) as and
when time allows, in such a way that "everyone" will know what to
expect (programming wise), and anyone needing additional VDI
functionality would have a concrete place to start, one that may
already include a pre-definition of what they need

Paul