Re: Interested in starting some basic development

[Magnus Norddahl <mbn@dark.x.dtu.dk>]

Quoting Christian Reiniger (warewolf@mayn.de):

> Abstraction? Will your svgalib or fbcon program also run on X or aalib or
> render to a file without change to the binary?

/dev/fb is supported by both the Linux kernel (2.1.x) and XFree86.

> Kgi is still in its infancy, right. But libggi is almost completely usable.
> And if you use libggi you *automatically* use all features (including
> acceleration) of the underlying display mechanisms (X11, svgalib, fbcon,
> aalib, ...). Why code for one display mechanism if you can code for all of
> them without any additional effort?

I don't know how much you've actually looked at the libggi api, but last I
checked, they had support for text mode gfx and framebuffer access - and
nothing more.

In pseudo DirectX language, it would look like this:

char *frontbuffer_ptr = frontbuffer->lock();
go_paint_the_backbuffer(frontbuffer_ptr);
frontbuffer->unlock();

I cannot even create a new non-frontbuffer surface or have a hardware
accelerated doublebuffer system (correct me if I'm wrong).

> I don't know what you exactly mean with "accelerated surfaces", but if
> *any* display mechanism on Linux supports tham, chances are very high that
> you can use them with libggi, too.

When I say hardware accelerated surfaces, I mean
Images/Sprites/surfaces/Pixmaps stored in videomemory and copied to the
backbuffer (or framebuffer) using the display cards hardware accelerated
blits. This was _the_ feature that made DirectX (or Game SDK as it was
called in version 1.0) famous.

It is hardware accelerated surfaces that makes the Pacman game run at 500
fps on my Pentium 166 using my Riva 128 card (if it doesn't wait on the
refresh rate). 

Only 3D games use extensive direct framebuffer access - all others prefeer
to have a set of surfaces/images instead.

Last time I checked, libGGI2d did NOT have any support for this (looked into
the header files) - and when I asked on their mailing list, I did not get
any reply, so...

Only two libraries for Linux has any kind of support for hardware
accelerated surfaces, and that's svgalib and X Window. With svgalib, you
need to use some rather displaycard specific functions - but with X Window
it is called Pixmaps.

> >(I'm just tired of Christian constantly mentioning a project that doesn't have
> >any future, if they do not change course)
> 
> What course should they take? Their current course is to do things
> properly. I think this is the best course.

The problem with GGI is that they require throwing away all older graphics
libraries and programs. I don't want to throw away my XFree86 - and I'm
quite satisfied with svgalib's performance on my system. If I install GGI
onto my system (the kernel part), I'm no longer allowed to run those older
system - and that's just a too expensive price to pay.

In general, I ofcourse wish GGI luck with their project - but I just want to
see something worst installing before I'm going to use it. In the mean time,
I'm going to improve XFree86's Pixmap acceleration, so all X11 Pixmap based
games run like DirectX...

--
Magnus Norddahl
ClanSoft