GGI or Svgalib
bil...@hotmail.com
are 3 options, X, Svgalib, or GGI. I am thinking of more along the lines of
games programming so the two options seem to be Svgalib and GGI. Since GGI
has a Svgalib target I would assume that GGI is what I want, but to be sure I
need answers to these questions:
1. Is GGI ready yet for application development, or is it still too alpha?
2. Is there a driver for a #9 GXE 4MB (ISA, S3 928 chipset)?
3. Is the Mesa(OpenGL) acceleration as fast as possible?
4. Can full screen programming with Mesa(OpenGL) be done yet?
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Sol Lightman
: I am looking to do some graphics programming in Linux. It seems like there
: are 3 options, X, Svgalib, or GGI. I am thinking of more along the lines of
: games programming so the two options seem to be Svgalib and GGI. Since GGI
: has a Svgalib target I would assume that GGI is what I want, but to be sure I
: need answers to these questions:
:
: 1. Is GGI ready yet for application development, or is it still too alpha?
LibGGI is just about ready and the team is now tucking corners for a BETA
release; KGI is not quite ready. This basically means you will be able to
learn the API under a slower target, like X, without having it changed
entirely on you later, and your apps should run on KGI when it is ready
without so much as a recompile.
: 3. Is the Mesa(OpenGL) acceleration as fast as possible?
:
: 4. Can full screen programming with Mesa(OpenGL) be done yet?
You'd be best off asking this on the ggi-d...@eskimo.com list.
--
Brian
Aki M Laukkanen
>: 4. Can full screen programming with Mesa(OpenGL) be done yet?
>You'd be best off asking this on the ggi-d...@eskimo.com list.
Well, not really. There is sample source code for example in
the xlockmore sources: xlock/vis.c. This file and the supplied
OpenGL screen savers in modes/glx should have all the needed
information.
--
D.
Patrick Dowler
You certainly can do full-screen OpenGL programming!! It is
just that you need a 3dfx card (voodoo1 or voodoo2) and the
linux port of the glide lib, then build Mesa with glide support.
That way you also get pretty decent hardware acceleration
thrown in :-)
Check out: http://glide.xxedgexx.com/
--
Patrick Dowler
Victoria, BC
Jon Taylor
>I am looking to do some graphics programming in Linux. It seems like there
>are 3 options, X, Svgalib, or GGI.
Yes and no. SVGAlib shouldn't really be considered an option as
it is getting pretty old now andwas never that robust a solution to begin
with.
>I am thinking of more along the lines of
>games programming so the two options seem to be Svgalib and GGI. Since GGI
>has a Svgalib target I would assume that GGI is what I want,
This can be confusing. LibGGI does have an SVGAlib target, which
means that LibGGI can use SVGAlib as a "driver" to render to. LibGGI
also comes with targets for X, Xlib, XFree86 DGA, Glide, VNC, terminfo,
AAlib and a bunch of others. This multi-target system allows you to
develop LibGGI-using code on a stable target (like X) and then be able to
use the exact same code with other targets later on.
GGI also comes with a wrapper library which allows SVGAlib
binaries to render to LibGGI. This allows us to provide full legacy
support for existing SVGAlib binaries (yes squake has been made to work
through this system). ELF only, though.
>but to be sure I
>need answers to these questions:
>
>1. Is GGI ready yet for application development, or is it still too alpha?
It is ready. We are aiming for a release at the end of the year.
>2. Is there a driver for a #9 GXE 4MB (ISA, S3 928 chipset)?
Yes.
>3. Is the Mesa(OpenGL) acceleration as fast as possible?
It is always as fast as possible, otherwise it would be faster
|->. Seriously, Mesa has GGI support now but it is currently fullscreen
unaccelerated. I am working on developing LibGGI3D, which will be a
generic shaded 3D triangle rendering API with pluggable shaders and
LibGGI-style rendering targets. Once this is up and running, it should be
fairly easy to add a generic LibGGI3D target to Mesa itself. But for
right now, the only way to accelerate Mesa on Linux is with a 3Dfx Voodoo
card.
>4. Can full screen programming with Mesa(OpenGL) be done yet?
See above.
If you are truly interested in GGI, you should check out or web
pages at www.ggi-project.org and/or subscribe to our mailing list.
Instructions are on the website.
Jon
--
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
Marcus Sundberg
ver...@emily.oit.umass.edu (Sol Lightman) writes:
> LibGGI is just about ready and the team is now tucking corners for a BETA
> release; KGI is not quite ready. This basically means you will be able to
Just a small note, the X target isn't really that slow.
It certainly is as fast as a native X application.
//Marcus
--
-------------------------------+------------------------------------
Marcus Sundberg | http://www.stacken.kth.se/~mackan
Royal Institute of Technology | Phone: +46 707 295404
Stockholm, Sweden | E-Mail: mac...@stacken.kth.se
Tim Teulings
[ah, someone with knowledge about GGI!]
>>1. Is GGI ready yet for application development, or is it still too alpha?
I'm the author of VisualOberon - a GUI library wirtten in Oberon-2, designed
to run under various OSs using an abstraction layer.
A question regaring VisualOberon and GGI: does current (or the at the end of the
year to be released first) version of has its own windowing system (possibly
as somekind of plugin)? I interested in porting VisualOberon to another GUI
engine and could do so for GGI if one of its layer does have a windowing and
graphics layer similar to X11 (similar in functionality not in interface).
--
Gruß...
Tim.
Jon Taylor
>Hello!
>
>[ah, someone with knowledge about GGI!]
Yeah. I'm sort of the GGI project ambassador to the world.
>>>1. Is GGI ready yet for application development, or is it still too alpha?
>
>I'm the author of VisualOberon - a GUI library wirtten in Oberon-2, designed
>to run under various OSs using an abstraction layer.
>
>A question regaring VisualOberon and GGI: does current (or the at the end of the
>year to be released first) version of has its own windowing system (possibly
>as somekind of plugin)?
Sort of. LibGWT is a basic windowing toolkit that runs on top of
LibGGI. I don't know what state it is in through, you'd have to talk to
the authors. Also, the Berlin project is being built on top of LibGGI as
well, and of course we also have XGGI, or own X server.
>I interested in porting VisualOberon to another GUI
>engine and could do so for GGI if one of its layer does have a windowing and
>graphics layer similar to X11 (similar in functionality not in interface).
Well I can tell you right now that LibGWT is *not* as powerful as
X, and probably will never be. It is not supposed to be. LibGWT is a
rectangular-regions ("viewports") manager. It handles/will handle
change-of-focus, backing storage management for window overlapping,
window lists, etc. More complex GUI functionality like menus, dialogs,
events, widgets, etc would be handled by another library that would ride
on top of LibGWT.
Tim Teulings
>rectangular-regions ("viewports") manager. It handles/will handle
>change-of-focus, backing storage management for window overlapping,
>window lists, etc. More complex GUI functionality like menus, dialogs,
>events, widgets, etc would be handled by another library that would ride
>on top of LibGWT.
This is exacly what VisualOberon does, it implements gadgets on top of
and GUI abstraction layer. Does the libGWT need a special window manager,
like you need for X11?
--
Gruß...
Tim.
Jon Taylor
I don't know. You'll need to look at the code and/or talk to the
authors. Check the GGI web page for more details - there's a "who's
doing what" document there somewhere.
James A Simmons
On 23 Nov 1998, Tim Teulings wrote:
> Hallo!
>
> >rectangular-regions ("viewports") manager. It handles/will handle
> >change-of-focus, backing storage management for window overlapping,
> >window lists, etc. More complex GUI functionality like menus, dialogs,
> >events, widgets, etc would be handled by another library that would ride
> >on top of LibGWT.
>
> This is exacly what VisualOberon does, it implements gadgets on top of
> and GUI abstraction layer. Does the libGWT need a special window manager,
> like you need for X11?
>
Nope. libGWT does not need a window manager. Its a bare bones API to
implement windows on ANY display target (svga, ASCII art, etc).
Tristan Wibberley
Thanks James,
But it should be noted that libGWT is far from useable yet.
The current tasks that need to be completed are simply handling clip lists
and invalid regions, and event distribution. Then there will probably
eventually be some way of interacting with a window manager depending on the
display target.
On a target like X11, libGWT will eventually just pass much functionality on
to the X server, whereas on the console it will pass as much as it can to
the hardware, and on SVGAlib it will do it all itself (Ah thank God for the
libGGI extension and accel mechanism :)
--
Tristan Wibberley