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

Re: SDL vs GGI



Ingo Ruhnke wrote:

> > Also, Svgalib is in just about all distributions right now, but right
> > after an install of Red Hat 6.0 that told me it detected my video
> > hardware correctly (and it was right, X works perfectly), tell me why
> > starting Quadra crashed my machine?
> 
> Because svgalib is just a plain hack, which doesn't support all gfx
> card. It shouldn't be used anymore, there a better alternatives (GGI,
> fbdev).

Yes, I agree. One of the problem with GGI is that very often, it uses
Svgalib on the console, thus inheriting all of the problems (including
awful crashes if not configured on Matrox G200 cards).

fbdev, in its fully hardware accelerated incarnation, could have some
future as a backend. But one thing that I think will remain is that
companies like Precision Insight and nVidia will invest more in the most
visible part of a graphical Linux installation, the X server.

Note that I think that nVidia did the right thing by releasing very
general information to programming their video hardware, instead of just
releasing an X server for their card.

> > If GGI get a similar level of "support" by the distributions (just
> > including the package, that is), tell me what would be the advantage of
> > GGI over Svgalib?
> 
> The main advantage of GGI, above any other gfx lib is that GGI is
> display independent, it can run under console, using fbdev or svgalib
> and can also run under X. If somebody ports it to another display
> target, you would have another target for your game for free.

Yes, but currently, very few people have GGI in a runnable state and the
thing isn't exactly completely frozen, ready or time-tested. X is
everywhere and works reasonably fast. Xlib+XShm+DGA for 2D work and
OpenGL+GLX for 3D work is what I call for.

> > If the advantage is that it at least work in X, then
> > tell me why I wouldn't use Xlib instead and gain the ability to pop
> > multiple windows and support cut & paste?
> 
> If you use Xlib directly you would lost the transparent access to the
> display, you would be fixed to use X, console would be impossible or
> require lots of extra work. And hey, why should a game have stuff like
> multible windows and cut&past? If I want to play a game, then I want
> to *play* the game and not play around with different popup windows
> and cut&paste stuff. "Real games[tm]" must have the ability to run in
> fullscreen!

I agree that a "Real Game" should have the ability to run in fullscreen,
but my opinion is that it should be optional, and that the "meat" of the
game should be as friendly to the resident windowing system as possible.

Lets face it, we lead complicated lives. No longer we just run a game,
play and quit. No, we now have Internet servers, LANs, mods, chat,
gaming portals and what-have-you. Newer games should evolve to fit well
into this. Not counting that I have an awful number of Netscape windows
and other things open at any time that I could want to quickly switch to
or monitor.

I want to be able to chat with my buddy while trying out a new mod that
I downloaded by copy/pasting the URL he gave me in the (in-game) chat. I
want cool web front-ends to game servers that allows you to select your
game and start it by clicking on a link in Netscape.

And all of this stuff is going to be awfully hard with GGI or fbdev.
It's a shame for GGI though, it has a very nice API (GII is particularly
well done), but the point is that it is misguided and that it won't
solve my problem.

-- 
Pierre Phaneuf
Ludus Design, http://ludusdesign.com/
"First they ignore you. Then they laugh at you.
Then they fight you. Then you win." -- Gandhi