GgiDoom

ggiDoom, Also called GGIDoom, was an early source port of Doom by Uwe Maurer to the GGI (General Graphic Interface) library, based on the Linux Doom source release. It was released one day after John Carmack released the Doom source code. GGI was mean't to run on any computer system that supported it, and was considered a competitor to the X Window System. It supports resolutions higher than 320x200, e.g. ggidoom -mode 640 400.

ggiDoom's source code and binary as released contained no license whatsoever. However, in ggiDoom's TODO file referenced below, it is explictly mentioned that Maurer planned on using the Doom Source License.

Marcus Sundberg provided a LibGGI driver for use with Linux Doom and Linux Heretic on 09-02-1999. It is however unknown if ggiDoom made use of this driver in the 30-11-2001 build as the latest released version of ggiDoom is dated 17-2-1998, despite Maurer's reference entry on his home page.

As GGI as a display standard became increasingly outpaced and outdated as compared to the X Window System, development eventually ceased.

Maurer's TODO file
One interesting historical aspect is Maurer's TODO file. Dated 11-1-1998, It contained a lot of planned features on where he wanted to go with the port. Aside the plan to use the Doom Source License, it showed a look at incorporating features from glDoom. The full TODO list is as follows, converted to readable text format: - create Web repository for sources, patches, news, and pointer to doom-editing mailing list. - get DOOM Public License from id--- - remove m_fixed, switch to floating point. More stable, and prolly even faster. - make SCREENWIDTH/HEIGHT work at startup? Well, the HUD/STBar stuff is tied to the scales implied by the graphics. Rather do GLDOOM and use texture mapping. - fix aspect ratio? 320x200 is nothing viable nowadays. A 320x240 base (4:3) would be a lot better. See above on width/height. - limited look up/down by y-shearing? Prolly not worth it, rather switch to GLDOOM. - switch to C++? The action function pointers have varying argument lists (no parameter, one, etc.). C++ doesn't like that much. A major rewrite. - switch to doommain.c plus libdoom? Have libref, libgame etc.? Another major rewrite. - use XFree86 DGA, prolly not that much faster than MIT SHM, but allows for directly sampled mouse (and even freelook). Recommended for GLDOOM. - put together an accompanying developer toolkit source distribution: DEU, RMB, BSP for Linux/X. - move info.h, info.c, sounds.h, sounds.c and other data to a separate lump in the WAD, or into a libgame.so, to separate the generic stuff (refresh, I/O) from the DOOM specifics. - decide whether precaching all sounds is better than retrieving and releasing every so often. DOOM seems to do that frequently (8bit stuff, originally for DOS), and the Linux sound is 16bit (conversion in the mixing, requires some padding) - we prolly got the memory to spare. - 16bpp CLUT. The lightmaps and the framebuffer could be changed to switch to 64K colors. Prolly better to do GLDOOM right away. - remove checks for commercial etc., in non-essential issues (enabling PWAD's). - change (simplify) determination of sky texture (done by game version). Explicit? - remove all game version checks - different handling of Demo - don't exit on "different game version" - how about shareware/retail "You are here" intermission animation? Wasn't in commercial (DOOM 2). - double shotgun in DOOM1, all weapons with shareware - checks for required lumps. We need fallbacks for lumps that are not present, that is, default sounds etc. to be used instead, or removing THINGS w/o sprites etc. - client/server? I'd suggest ripping off some stuff from the abandoned IBM WebView project - Blockmap. The BLOCKMAP lump might be (partly) redundant, as the BSP allows for clipping (except certain LineDefs that will not spawn Segs). - LOS REJECT and intersection based LOS checking could be done using the BSP. In case of REJECT, certain monster AI special effects would be lost, though. - correct handling of height in collision. This is not done, and the checks are scattered around in many places. It does require handling of "player on top of monster" situations, too - we have to make sure the players falls off far enough to avoid getting "stuck in monster". - remove obsolete menus (Detail. Music Volume?) - clip explosion range damage (and sprites) using REJECT? That is, if one Sector/SSector not visible from the other, do not apply damage, not render sprite if player in other sector. Hmmm - explosion behind small pillar might not be visible at all, but do we care? - Ungraceful and untimely demise of Linuxdoom (core instead of I_Error) will leave idle sndserver processes in your system, blocking /dev/bsp. A timeout on lack of input for "sndserver"? - threaded sndserver? SHM mixing buffer? Or internal, timer-based?

Version history
Note: Taken directly from Uwe Maurer's homepage.
 * Nov 30 2001 - ggiDoom works with the latest libggi version again.


 * Feb 17 1998 - Updated


 * Dec 24 1997 - Initial release