From: Marcus Sundberg <mackan@stacken.kth.se>
  To  : ggi-develop@eskimo.com
  Date: Thu, 17 Sep 1998 00:29:31 +0000

Re: Glide-target now works again

Jon M. Taylor wrote:
> 
> On Wed, 16 Sep 1998, Marcus Sundberg wrote:
> 
> > I've added event handling back to the glide target and it now uses
> > the Linux_common files for keyboard and mouse support.
> 
>         Thanks a million.  I am still getting segfaults with everything,
> though.  I even blew away my whole CVS tree and re-downloaded it to no avail.
> Are you sure you committed everything?

Yes, that I'm sure of. I'll rebuild my libggi from scratch now. If
it still works I have no idea what might be giving you trouble.
Just two possible causes:
1. You have some old part of libggi lying around somewhere.
2. Your glide is linked against a different libc than your libggi.

[rebuild was done]
Nope, it works fine here. Please check 1 and 2 above. That's the only
thing I can think of. Set GGI_DEBUG to 255 and check where it segfaults.

[/me is back again]
(I'm doing lots of other stuff while writing this reply ;-)
I did change the refreshrate to 70Hz when I added my stuff though.
Could that be causing trouble for you?

> > In addition
> > to that it supports VT switching, which I don't know of any other
> > glide app that does. ;)
> 
>         YEAH!  AAaaaaaahhh!!!! I wanna see this!

Yep, it's pretty nice. Now I _really_ need to get some more monitors
to take advantage of all the nice features GGI has given me. ;-)

> > I've also removed the directbuffer hack
> 
>         What makes you call it a hack?  I agree that it was slow, but was
> the only way I could see to do nonblocking display flushing since you
> can't write to the hardware framebuffer without acquiring a lock through
> Glide.

It's a hack because it emulates a DirectBuffer. This should never be
done
unless it gives a significant performance boast.

> I took a quick look through all that new code you added but I
> have to confess that I don't grok a lot of it.  What happens on a VT
> switch?  Does the app sleep?

Yes, the vtswitch.inc code calls pause() on switchaway. So the app wakes
up on switchback. But actually it doesn't have to do this, as the kernel
aren't running any consoles on the 3DFX board we could very well keep
on drawing after switchaway.
We have actually two alternatives:
1. Keep the app running on switchaway - only one glide app at a time.
2. Call grGlideGetState() and pause on switchaway, unpause and call
   grGlideSetState() on switchback - this should let us have several
   glide apps running at the same time!

I suggest we allow both modes and let the user decide with an
environment
variable which one to use

> > and added glide acceleration
> > instead. Performance is quite OK for a card not at all designed for
> > 2D, especially considering that I haven't found a way to turn off
> > doublebuffering, which forces me to do things like:
> >       grDrawPoint(&gvertex);
> >       grBufferSwap(0);
> >       grDrawPoint(&GLIDE_PRIV(vis)->fgvertex);
> >       grBufferSwap(0);
> 
> How about using:
> 
>         grRenderBuffer(GR_BUFFER_FRONTBUFFER);
>         grDrawPoint();
> 
> instead?

Ahh! Thanks, I'm new to glide and didn't notice that function.

> That should force all drawing to the front buffer.  That will cost
> you your double/triple buffering capabilities but you said you don't want
> those anyway.  *I* want (need) them eventually, but for now they can stay
> out.

Not necessarily. I'll just add grRenderBuffer(<BUFFER>) to the
ggiSetWriteFrame() function in the glide target. This will make
libggi support double buffering on the glide target!

> > Lastly I've added PS/2 mouse support to Linux_common/mouse.inc
> > as I needed to test the mouse handling in the glide target. ;-)
> 
>         I've been wondering if the X_common and L_common code wouldn't be
> better off as a helper library?

Not the X_common code. The only code that's really common is color.inc,
and
that's to little to put in a separate library. The other files are full
of
target specific #ifdefs.
As for L_common I don't think it's worth the trouble to put it in a
separate
library.

> > If there's someone here that's familiar with Glide you're welcome
> > to help me with using font characters as textures. That would make
> > a quite nice nixterm terminal out of a 3DFX board.
> 
>         I'll do what I can.  I have a nice spiral-bound hardcopy Glide
> Programming Guide I put together a while back which I have been reading
> cover-to-cover.  I'm not to textures yet, but hopefully soon.

That would be great. All that is needed is to upload 256 8x8 bitmaps to
the texture memory and a function to blit them to the screen with the
specified foreground and background color. But I have limited experience
with 3D, so I don't know where to look for that functinality, and I
don't
have time to read the glide docs from cover-to-cover. (And the fact that
I have to read it in xpdf doesn't help ;-)

>         I brought the Glide target back from the dead so I could have a
> well-working 2D target to build the LibGGI3D Glide target on top of.  That
> point has almost arrived.

Definitely. I have ggidumb running on the glide target on VC2 right now,
as mere mortal user, complete with mouse support!
Actually we might even make people developing pure glide apps use libggi
for input management. libggi's eventbased system is far more nice too
use than the Linux's keyboard handling, and for mouse support there
isn't
even a standard way to do it. It also has the benefit that you only have
to write one copy of the input managing code to make the app run
everywhere.

And once libggi3d is ready and supports glide acceleration it
would really rock!

//Marcus
-- 
-------------------------------+------------------------------------
        Marcus Sundberg        | http://www.stacken.kth.se/~mackan/
 Royal Institute of Technology |       Phone: +46 707 295404
       Stockholm, Sweden       |   E-Mail: mackan@stacken.kth.se