nanogui: Thread: nanoX bugfix v0.4 coming

I have been working hard to fix all known bugs and get the sample
nanoX programs completely running.  The sample programs don't work
properly without XOR line drawing modes for linedraw, pixel, and fillrect, for instance.
This is now fixed.

In addition, there are considerable issues with palette management.

The v0.3 release didn't properly completely handle type 1 vs type 2 graphics 
drawline code, which has also been fixed.

I think I will be releasing v0.4 very soon, which can be used as a reference port
for initial driver work, to have a set of properly working sample programs with which
to compare drivers with.  BTW, the landmine program is now fun to play!

I'm also still working on bitblt and readpixel routines, as well as redesigning
driver info interfaces.  Unfortunately, this means that the driver api will need to 
change.  So we're not quite ready yet to start writing tons of drivers, although it
would be nice to start experimenting.  Another issue is that, if we want to implement
all this fancy GDK and Mozilla stuff on top of nanoX, the driver layer is going to have
to support a HELL of alot more than it does now.  This means that it will take
longer to create drivers...   An example of this is that we will have to support
palette management, xor/and/or/set drawing modes, background transparency
draw modes, text with transparency, and possibly a nanogui-defined device context
structure for each entry point, which will mean that drivers will have to ultimately be
designed for nanogui itself for speed.  Comments?

Greg

> would be nice to start experimenting.  Another issue is that, if we want to implement
> all this fancy GDK and Mozilla stuff on top of nanoX, the driver layer is going to have
> to support a HELL of alot more than it does now.  This means that it will take

Not that much

> palette management, xor/and/or/set drawing modes, background transparency

Fixed palette is acceptable with gtk, and indeed for LCD screens is a good
first model anyway.

> draw modes, text with transparency, and possibly a nanogui-defined device context

Text just needs to follow the draw modes - or/xor/and/set

> structure for each entry point, which will mean that drivers will have to ultimately be
> designed for nanogui itself for speed.  Comments?

I think thats unavoidable. 

Greg Haerr ####@####.#### writes:

   I'm also still working on bitblt and readpixel routines, as well as redesigning
   driver info interfaces.  Unfortunately, this means that the driver api will need to 
   change.  

What sorts of bitblt do you need?  Do you need screen-to-screen
bitblt, or screen-to-buffer, or buffer-to-screen, or all three?  The
BOGL API has a bmove routine for screen-to-screen bitblt, but it's
never been implemented because it turned out that I didn't ever need
it.

Yes, all three.  In our first version, the upper level will use "device-dependent" bitmaps
so that the bitblt is identical for all three.  In a later version, we'll have upper level
formats for bitmaps that can be converted by drivers to their own low level format.

In addition, we need to think about patblt, which is another form of bitblt that
works from predefined patterns to be used for fill backgrounds.  All this can wait
for a while though, since bitblt will allow pictures and icons to be drawn.

On another note, the pointer draw routine and the low level bitblt routines should
probably merge, so that ultimately we have just one bitblt routine for any image,
whether its cursor or bitmap.  In order to do icons well, the bitblt needs AND and 
OR drawing modes.  I'm working on a spec for all of this as well.

Greg

On Wednesday, May 12, 1999 10:49 AM, Ben Pfaff ####@####.#### wrote:
> Greg Haerr ####@####.#### writes:
> 
>    I'm also still working on bitblt and readpixel routines, as well as redesigning
>    driver info interfaces.  Unfortunately, this means that the driver api will need to 
>    change.  
> 
> What sorts of bitblt do you need?  Do you need screen-to-screen
> bitblt, or screen-to-buffer, or buffer-to-screen, or all three?  The
> BOGL API has a bmove routine for screen-to-screen bitblt, but it's
> never been implemented because it turned out that I didn't ever need
> it.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 
> 

Greg Haerr ####@####.#### writes:

   On another note, the pointer draw routine and the low level bitblt routines should
   probably merge, so that ultimately we have just one bitblt routine for any image,
   whether its cursor or bitmap.  In order to do icons well, the bitblt needs AND and 
   OR drawing modes.  I'm working on a spec for all of this as well.

Come up with a spec and I'll see what I can do about coding it up.

BTW: Are the rest of you getting stuff from the list?  I'm not,
although I did for a while, and a mail to ####@####.####
(I think that's the address--it's on the webpage) didn't get a
response.
-- 
"...dans ce pays-ci il est bon de tuer de temps en temps un amiral
 pour encourager les autres."
--Voltaire, _Candide_

On Wed, 12 May 1999, Greg Haerr wrote:
> Yes, all three.  In our first version, the upper level will use "device-dependent" bitmaps
> so that the bitblt is identical for all three.  In a later version, we'll have upper level
> formats for bitmaps that can be converted by drivers to their own low level format.
> 
> In addition, we need to think about patblt, which is another form of bitblt that
> works from predefined patterns to be used for fill backgrounds.  All this can wait
> for a while though, since bitblt will allow pictures and icons to be drawn.
> 
> On another note, the pointer draw routine and the low level bitblt routines should
> probably merge, so that ultimately we have just one bitblt routine for any image,
> whether its cursor or bitmap.  In order to do icons well, the bitblt needs AND and 
> OR drawing modes.  I'm working on a spec for all of this as well.

Have you had a look at Allegro? It's a really excellent DOS games library
(with Windoze and X ports under way the last time I looked). The license
is pretty open:

   Allegro is swap-ware. You may use, modify, redistribute, and generally
   hack it about in any way you like, but if you do you must send me
   something in exchange. This could be a complimentary copy of a game, an
   addition or improvement to Allegro, a bug report, some money (this is
   particularly encouraged if you use Allegro in a commercial product), or
   just a copy of your autoexec.bat if you don't have anything better. If
   you redistribute parts of Allegro or make a game using it, it would be
   nice if you mentioned me somewhere in the credits, but if you just want
   to pinch a few routines that is OK too. I'll trust you not to rip me 
   off.

I think there wouldn't be a problem including his code in Nano-X, and
there is some really excellent graphics code in there. I actually got into
Open Source after reading about Allegro, then getting DJGPP (the DOS port
of GCC) in order to use it.

http://www.talula.demon.co.uk/allegro/

--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------

On Wed, 12 May 1999, Alex Holden wrote:
> Have you had a look at Allegro? It's a really excellent DOS games library
> (with Windoze and X ports under way the last time I looked). The license
> is pretty open:
<snip swap-ware license>

I just downloaded the latest version of the library, and turns out that it
is now totally free. Here's an extrace from the feature list:

Supports VGA mode 13h, mode-X (twenty three tweaked VGA resolutions plus
unchained 640x400 Xtended mode), and SVGA modes with 8, 15, 16, 24, and
32 bit color depths, taking full advantage of VBE 2.0 linear framebuffers
and the VBE/AF hardware accelerator API if they are available. Additional
video hardware support is available from the FreeBE/AF project
(http://www.talula.demon.co.uk/freebe/).

Drawing functions including putpixel, getpixel, lines, rectangles, flat
shaded, gouraud shaded, and texture mapped polygons, circles, floodfill,
bezier splines, patterned fills, masked, run length encoded, and compiled
sprites, blitting, bitmap scaling and rotation, translucency/lighting,
and text output with proportional fonts. Supports clipping, and can draw
directly to the screen or to memory bitmaps of any size.

Hardware scrolling, mode-X split screens, and palette manipulation.

FLI/FLC animation player.

I think it'd be really great if we could make use of parts of Allegro in
Nano-X. Man years of work have gone into the optimised low level
primitives and things like the pallete handling code, but it's still
extremely clean, small, and _very_ fast.

--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------

Alex Holden ####@####.#### writes:

   On Wed, 12 May 1999, Alex Holden wrote:
   > Have you had a look at Allegro? It's a really excellent DOS games library
   > (with Windoze and X ports under way the last time I looked). The license
   > is pretty open:
   <snip swap-ware license>

   I just downloaded the latest version of the library, and turns out that it
   is now totally free. Here's an extrace from the feature list:
   [...]

Wow, that's pretty impressive.  If it's also relatively small and easy
to port, then maybe that's what we should use, instead of BOGL.

On 12 May 1999, Ben Pfaff wrote:
> Wow, that's pretty impressive.  If it's also relatively small and easy
> to port, then maybe that's what we should use, instead of BOGL.

The main disadvantages with it are that it doesn't have a Linux FB driver,
plus some bits of it are hand optimised x86 assembly which would have to
have C versions written. It would probably be a better basis than Bogl for 
non Linux-2.2 platforms though. There was actually also a partial SVGAlib
a while back, which was abandoned due to the X port progressing faster.
I'm sure there's plenty of stuff we can use in it though. There's even a
_very_ tiny widget set in there, which was great for designing game map
editors and things. I remember impressing a lecturer with a really flashy
looking program graphical units converter I built with it as an example in
about an hour once :) Thinking about it, it could be very useful as a
basis for a PDA GUI due to it's small size...

--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------