On Tue, 11 Sep 2001, Ulhas Samant wrote: > Thanks Chris, > > To begin with, I shall briefly introduce myself > and my organisation. I am Ulhas, working with Software > division of Patni Computer Systems Ltd. Patni Computer > Systems (PCS) is an IT services Company, providing IT > consulting and implementation services, turnkey projects > and onsite technical services. > > We have done a number of CAD/CAM and Graphics related > projects for customers like Parametric Technology > Corporation and Co-Create. For more information about our > company you can visit www.patni.com. > > We just came across 'Help-wanted' page of 'GGI' project, which is > managed by you. We thought, as a team of developers, we can contribute > to this software development project. Yes, that's really awesome! > We just wanted to know more about the Project. > > Now that you have sent some info. about the project. I visited the > said web-site. We shall try to download and study the libraries and > also subscribe to your newsletters. > > IN THE MEANTIME, YOU CAN TELL US WHAT PROJECTS CURRENTLY EXIST. The GGI project is soooo big, that we can do nothing but dividing it into many many subprojects. ;-) The GGI project as a _whole_ is currently somewhere between alpha and beta state. Here is a short and roughly overview about how the GGI project is organized. libgii: (beta, but production-stable) It provides support for many input devices (keyboards, mice, joysticks, wacom tablets, remote input through tcp and much more). Further multi-input is supported. This allows you to use two keyboards and two mice on one machine allowing two persons working on it as they would work on their on machine. Recently in CVS a touchscreen driver for Compaq's iPaq PDA has been added. A shot made with a digital camera is available at http://www.ggi-projects.org/screenshots.php. It contains a sublib called "libgg", which provides dynamic (un)loading of targets platform independently. libgii can also be used as standalone without libggi. Each input device driver can be seen as a sub-sub project. :-) libggi: (majored) This is the GGI's core library. It provides video mode initialisation and the really _basic_ set of drawing primitives everyone needs to be able to write GGI application in order to guarantee high portability. Further it provides an highly flexible extension system to allow to tap each graphic system to its limit. It is also designed to allow multi-head, whereever possible. It requires libgii and one supported graphic system to compile and to use it. In the term of GGI a graphic system is called a "target". It also provides some pseudo-targets to allow running 8bpp applications under a 32bpp environment, for example. libggi/doc/targets.txt gives a good overview of supported targets. It also should make clear the difference between a target and a pseudo-target. Each target can be seen as a sub-sub project. libgalloc: (alpha) This is the graphics allocator intended to figure out what a certain target can do and get the best out of it. libmmutil is a sublib of libgalloc providing the batchops and the range-manager. The batchops provides a way to perform multiple operations at once. The range manager tries to use the onboard video RAM (which is usually very limited) as best as possible. It also takes about fragmentation caused by allocating and releasing of resources again and again. The fragmentation may not be implemented as of this writing. Each target will make use of the range-manager. For more information about libmmutil read the libmmutil documentation at http://www.ggi-project.org/docs/ It requires libggi to compile. libbuf (alpha) It is intended to make use of buffer resources like alpha, z, stencil, texture and raw buffers. It also takes care about data-transfer like bus-master DMA, AGP, etc. How far this goes depends on the target. It requires libgalloc to compile. libovl: (alpha) It is intended to make use of overlay resources. Overlay resources are resources, which NEVER manipulates the framebuffer, so that you never have to take care about saving/restoring their background. Examples of overlay resources are: true hw-sprites, videos and windows. It requires libgalloc to compile. In future development it might require libbuf as well to compile in order to add support for alpha-blending, for example. libblt: (pre-alpha) It is intended to make use of blitting operations targets provide. It makes use of libbuf to add support for a bunch of raster operations (ROPs). It also uses libmmutil to perform blitting operations as fast as targets allows. In the current development state it only requires libgalloc to compile. libggimisc: (beta/major) It is intended to make use of miscenallenous features like VGA splitline, ray position detection, waiting for vertical retrace and such things like that. It requires libggi to compile. In future it will make use of libgalloc. libbse: (alpha) It is intended to provide support for sprites, bobs and emulated sprites. It glues libovl and libblt together for user convenience to provide this. It asks libovl for true hw-sprite and in case libovl fails, which means no hw sprite is available) it falls back to libblt to emulate sprite using bobs. In this case it takes care about saving/restoring the background. It requires libovl and libblt to compile. libvideo: (planning) It is intended to provide everything what has to do with videos. It uses libovl for best performance and in case libovl fails, then it falls back to use libbuf and libblt to handle the non-full accelerated case. Example: It might be a libovl target supports video, but no mpeg decompression. In this case, the decompression is done in software or accelerated in an other way (i.e. using a mpeg decoder card) and video displaying is done by libovl. So, in the worst case everything is done by libblt (emulating video playing). It will require libovl, libbuf and libblt to compile. libxmi: (alpha) It is a port of xmi to GGI to support any 2D operation, which isn't supported by one of the above libs. Its API might be friendly with you, if you are already friendly with xmi. libgpf: (planning/pre-alpha) It is intended to provide any data-streaming from anywhere to anywhere. This allows you to do video-streaming from the internet or DVD and using libvideo for displaying it, for example. You can also load a simple picture into memory or safe from memory into a file. You can also do picture convertion from any to any format... There is no limit. It will require libgii for dynamic (un)loading of sub-libs. libggi3d: (planning/pre-alpha) It is intended to abstract the lowlevel 3d rendering pipeline. Several chipsets have several rendering ways/strategies to give its best performance. If the target provides geometric operations additionally to the rendering operations, they will be used to transform and render 3d-objects. Otherwise, it will use libxmi (or we will develop and use libggi2d, if libxmi's API turns out being to weak) for drawing polygons and other things. It should make use of the batchops (libmmutil) to speed operations up. It will require libxmi (or libggi2d). > You can send us more details about the work involved (along > with the info. like resources required/ effort-estimated). I hope, the above description gives an impression what GGI is and which potential it provides for the future. As you can see obviously, we actually need support for help!! BTW: I also CC'd this mail to the GGI ML. > Our aim is to gain experience and improve our skills in the > process. Hoping for a favorable reply and thanking you in > anticipation. I am sure, you and your team will learn how to do graphics programming in THE RIGHT WAY. CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
