Re: Video subsystem draft

[Vincent Pelletier <subdino2004@yahoo.fr>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 1773 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 26 Nov 2005 02:28:53 +0200
Vesa Jääskeläinen <chaac@nic.fi> wrote:
> Yoshinori K. Okuji wrote:
> > If you want to improve it, feel free to do it. It is our own
> > format. But I think the byte order was set conveniently.
> 
> Byte order is currently exactly the same as in .hex file :)
> 
> It has minor issue with widechar fonts (char width > 1). It like
> contains two different font data. First there is first half of like
> normal 8x16 font and then there is second half. My idea would be to
> store bitmap in scanlines instead of character blocks so I can take
> whole character width and draw that.

By the way, there is already a font format handled by IEEE1275
frame buffercards.
- From the standard : 

set-font ( addr width height advance min-char #glyphs -- )
Set the current font as specified.

So I think they can handle arbitrary-sized glyphs.
I can't find the font data definition, but as "default-font" returns
all those values for the default font, reverse engineering will be a
matter of minutes.

If the font format you want to design could be compatible with ths one,
it would be a pleasure to port it to sparc :) - and probably the same
for PPC.

By the way, I think we should start a discussion on the API common to
all architectures for framebuffer handling.

Vincent Pelletier
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDiCCXFEQoKRQyjtURAryjAJ9Xppf3KxB4aYi8m5V1Xzta6fB5XgCeJXwE
lVa4Lay3OgE/JF3WHBqfZ0k=
=RJLt
-----END PGP SIGNATURE-----

	

	
		
___________________________________________________________________________ 
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
Téléchargez cette version sur http://fr.messenger.yahoo.com