On Sat, 13 Oct 2001, Brian S. Julin wrote: > Heya, > > Just throwing this to the gallery for comments. > > We have three new lowlevel libraries which (along with LibGGIMISC) > will be forming the core of the intermediate API for the GGI Project, > LibBuf, LibBlt, and LibOvl.
Great... Congratulations... what is GGI about ? to get as many different libs as possible ? Anyway, have been talking with some programmers lately, trying to promote GGI / KGI, and had to admit they got good reasons not to use GGI. I'm just passing them through, don't take them personal from me: 1) Lack of 3D support. There are many libs available that can do this at the moment. Indeed they are not so flexible as GGI is, but they are cross-platform and use accelleration. Most programmers just want a normal window (might be fullscreen) to draw to, with accelleration. (see 3) 2) Drowning in libs. Their complaint was GGI doesn't look like a solid system, but as a heap of many small stand alone thingies. Documentation about them doesn't seem up to date. 3) Wrong priorities. To quote one of the guys I spoke to: "Nice to see someone has been hacking GGI to run on that Compaq handheld (with my personal compliments). Nice to see GGI running on a cube. Nice to see gdoom running in 16 separate windows, nice to see it running on aalib. Where is the 3D support ???" 4) They are working on everything at the same time, instead of trying to get something really finished. This was said to be a reason not to join the GGI development: They simply didn't know where to start, for there was a lot of half-finished code, causing a lot of confusion. -- Personally, I think especially the lack of 3D will kill GGI sooner or later. I have been thinking about how to do it, and was thinking we shouldn't reinvent the wheel, but create a LibGGGL. (GL compatability layer), using the OpenGL syntax. Don't have time right now to explain, but please feel free to fire your bullets at me already. Jos
