SciTech MGL Graphics Library Version 4.05 Cool Projects and Things To Be Added May 12 1998 What is this document for? -------------------------- This text document is intended to provide an overview of some of the neat projects that could be worked on within the SciTech MGL to make it a better product. If you are interested in working on any of these projects, log onto news.scitechsoft.com and check out the scitech.mgl.developer newsgroup. There may be other people working on in the same area and you could contribute to this work. If you have any other ideas for cool projects for the SciTech MGL, let us know and we can add them to this list. Blitting Functions ------------------ . Add support for stretching in ModeX modes, using a simple stretch to a temporary buffer and then blit to the screen using the ModeX putScanLine functions. . Add support for MGL_flipBlit and MGL_mirrorBlit functions that will do a blit of a bitmap with a flip in the vertical direction or a mirror in the horizontal direction. Most useful for sprite based games. We would also need to implement transparent versions of these functions. . Add support for stretching with transparency. Currently the MGL will only support stretching without transparency and vice versa. . Add support for transparent blitting between device contexts of different pixel depths and pixel formats (ie: a translated, transparent blit). Currently the MGL requires that the pixel formats and color depth be the same for transparent blits. . Add faster, optimised C code for implementing special case translated blits. The most obvious candidate would be to implement fast 8-bit to 15/16/24/32 blitting functions optimised for each case, since this is a good color depth for sprites. Currently the code to handle 8-bit to higher color depth translates goes through a single generic module in EMULATE\EM_TRANI.C . Add support for stretch blitting from 4 bit DC's to 15/16 bit DC's. Currently the MGL only handles stretching from 8 to higher color depths, but not 4 bit. . In order to provide better support for downloading of sprite data to hardware we could provide new functions to create special bitmaps allocated in offscreen memory on the graphics card. The offscreen memory manager from the Game Framework Sprite Library could then be merged into the main MGL libraries, and use either that or DirectDraw to manage the surfaces when we create them. Currently the SciTech MGL can only allocate a single, rectangular offscreen bitmap when running under DirectDraw, and on newer cards we could use DirectDraw to allocate smaller offsceen bitmaps for us more efficiently (ie: similar to the linear offscreen device contexts in the MGL). . Add a new MGL_bitBltRegion() function that would perform a normal BitBlt, but the blt will be clipped to the passed in region to the source device context. This can then be used for doing very fast blts of arbitrary areas for overlays etc. It could also be done in hardware using the blitter to move each scanline, which would work well for non-transparent blitter hardware. If we added a new MGL_bitBltBatch() function to allow blitting of a batch of rectangles, then we could layer the above function directly on top of that (for hardware accelerators). Then we could add a new bltBatch function to the VBE/AF device drivers to full handle multiple small blts very quickly (might make it very fast for transparent cockpit overlays etc). Internal Rendering Functions ---------------------------- . New integer ellipse algorithm to replace the current floating point routine that is a place holder. The old integer ellipse algorithm suffered from overflow in the decision variables (4*A^3 is a large number when A gets about about 800; A is the diameter of the ellipse), so the decision variables are now floating point. I am sure a better algorithm could be implemented that would solve this problem. . Add support for portait display capabilties so that the coordinate system for the MGL could be turned on end (either left or right) for a tall skinny display. For most of the rendering functions this would be easy, since all you need to do is swap the coordinates. The MGL text functions already support drawing in any 90 degree angle so that is easy. The biggest change would be new bitmap blitting functions that will do on the fly conversions between horizontal and vertical scanlines when blitting the bitmaps to the screen. . Add support for color mouse cursors. Currently the MGL only supports single color mouse cursors, and color mouse cursors would allow you to do cool things like have animated cursors playing while loading data from CD-ROM or whatever. . Change the mouse cursor rendering, to copy from the screen to a small scratch buffer, render the mouse cursor image to this system buffer and then blit the result to the screen. This will result is perfectly smooth mouse cursor motion that will totally eliminate any flicker. . Add support for 32x32 or larger patterns rather than the default 8x8 bitmap pattern support. . Add support for fat elliptical arc rendering. We can do this quickly by computing an elliptical region and chopping out the wedge, although using regions may be a little slow. . Add support for round cornered rectangles. . Add support for scaling monochrome bitmaps to any size during rendering. Perhaps what we really need to do is add support for a mono stretchBlt routine that will actually stretch a mono bitmap to the display. Hence the bitmap will not need to be changed, just the code that does the blt operation. . Add code to align the bitmap pattern origin to a new location so that pattern fills can be done properly allowing the pattern to be aligned to any starting pixel coordinate. Currently the pattern is always locked to the global screen coordinates. . Add support for high speed pixmap rendering code. Basic pixmap (ie: color pattern fills) has been implemented in C for the library code, but none of it has been optimized yet). Device Driver Functions ----------------------- . Add support for rendering directly to the surface of a window using either DCI (for Windows 3.1, Windows 95 and Windows NT) or DirectDraw (Windows 95 and Windows NT). Once this is implemented, it will be possible to use the MGL rendering functions to draw directly into a window for transparent bitmap rendering as well as implement front buffer rendering for OpenGL. The only complication with this is that rendering to the window can be complicated if the window is obscured by other windows, since we then need to handle the clip regions properly. In order to get around this problem, we can probably have an MGL function that will allow the app programmer to determine if the window is obscured, and if so do all rendering to a system memory back buffer and blit that to the screen (the blit will of course be correctly clipped). Stereo LC Shutter Glasses Support --------------------------------- . Add Stereo support into the Game Framework. The MGL API itself is currently Stereo Enabled, but the Game Framework has yet to have stereo support added. . Update the MGL OpenGL bindings to properly support stereo. Most of the work for this has already been done, but stereo has not yet been tested when using the OpenGL libraries (only the regular MGL code). . Add Stereo support to the SGI SkyFly OpenGL sample program, as well as some of the other OpenGL samples. The best way to do this would be to include a -stereo command line switch to enable stereo in the standard sample program. . Add support for software stereo for systems that dont have hardware stereo page flipping or hardware stereo syncing. This needs to be done using a timer driven interrupt (using the real time clock I believe) for the DOS environment, and a VxD in Windows 95 based on the same principle. Perhaps some of the Stereo LC shutter glasses manufacturers would like to step up to the plate and take a look at adding software stereo support to the MGL? Region Algebra Functions ------------------------ . Add support for the missing polygon region functions, elliptical arc region functions and other region generation primitives. . Modify the segment definition to include both X1 and X2 coordinates in the same segment and re-write the underlying algebra routines. This will make the memory requirements significantly smaller for complex regions and will make it faster (but the algebra routines will be more complicated). . Add support for clipping all output to a selected clip region. This could probably be implemented by using a small driver routine that would hook between the API call and the device driver call when a complex clip region is selected, that would select each rectangle in the clip region as the current driver clip rectangle and then re-issue the driver rendering command over and over until the region has been traveresed. Bitmap Loading/Saving support ----------------------------- . Add support for 1/4/24 bpp bit PCX files. Currently the MGL will only read PCX files that are 8-bpp. . Add support for PNG bitmap reading, based on the freely available LIBPNG library. This would be very similar to the new JPEG functions based on the IJG JPEG library. . Add support for TIFF bitmap reading, based on the freely available LIBTIFF library. This would be very similar to the new JPEG functions based on the IJG JPEG library. Font Functions -------------- . The MGL currently does not have support for scaling bitmap fonts from one size to another, so you can only use the size specified in the font files on disk. It might be interesting to add a font scale function that would scale the monochrome glyphs in the font file when it is loaded from disk. . The MGL currently includes a bunch of font files that are in the MGL 1.x font file format, but it can also load fonts in the Windows 2.x style font format (standard format used by Windows 3.x, Windows 95 and Windows NT). A useful project would be to write a font converter from the MGL headers and source that would convert the MGL 1.x style fonts to Windows 2.x style fonts. With this completed it would then be possible to edit any of the MGL fonts with a Windows font editor. . The MGL currently only support loading of Windows 2.x fonts in the .FNT format which is a single font per file. Normally Windows bitmap fonts are distributed in .FON Font Library format with all the sizes for that font included in a single file. An interesting project would be to add support for Font Libraries to the MGL so that a single font of a specified size could be loaded from a specified font library file on disk. Of course to make this really useful, the MGL 1.x fonts would need to be converted to Windows 2.x format so that the font collection can be all converted to font libraries. . The MGL currently supports only bitmap and stroke font files, and does not support True Type fonts. An interesting project would be to write some code that loads and renders a True Type font for the MGL internally, so that font can be used as a bitmap font of a specified size. This project has actually neen started by an MGL developer, using the FreeType library for doing the TrueType font conversions. At this stage the code is not integrated into the MGL library proper, so this project should be relatively simple to complete. . The MGL currently does not support caching of font data in offscreen memory when using a VBE/AF hardware accelerated mode. Although the MGL_putMonoImage function is fully accelerated by VBE/AF, storing the font data in offscreen video memory will provide a big increase in font rendering performance on VBE/AF 2.0 drivers that support the new PutMonoImageLin functions (and in fact some hardware devices can only support this format). Hence an interesting project would be to add support for caching the font data in offscreen video memory for ultra fast font drawing (if the font is rotated, the cache font would have to be rotated also, but the MGL already does this internally). MegaVision C++ GUI Framework ---------------------------- . The MegaVision currently has a few minor bugs in the screen update code, so an useful project would be to take a look at fixing some of these bugs. . The MegaVision library currently has classes for Radio Buttons and Check Boxes, but those classes have not been completed (no support for drawing the text labels for the buttons!). An interesting project would be to flesh out the button controls for the MegaVision including these and adding support for bitmapped buttons to the library. . The MegaVision library currently requires that all user interface components be created in code, and does not have a disk based resource file format. A useful project would be to create a resource editor for MegaVision and a set of routines to load the definitions of the resources from disk, allowing user interfaces to be constructed in a visual manner. . One thing that would make the MegaVision a very powerful GUI library is to add support for changing the 'Style' or Look and Feel of the GUI library, such as how the windows look, how the buttons look etc. It might be possible to change a lot of the UI drawing code to be bitmap based so that a different set of bitmaps could be used to completely customise the look and feel of the GUI library (great for game devlopers who want a GUI that fits in with the theme of the game!). Game Framework -------------- . Add code to the Sprite Manager to allow it to not own the source bitmaps so they wont be deleted when it is destructed. . Add support for assembler run length encoding routines. We can change the code not support any clipping, and to maintain the original bitmap as well as the RLE bitmap and draw the original bitmap when clipping is on (may be faster). Although clipping may be just as easy. . Add code to the Sprite Manager so that we can change the active device context and it will automatically figure out how to reload the bitmaps into the new device contexts. Mesa OpenGL Support ------------------- . Layer the Mesa rendering functions on top of the MGL 3D rendering functions for primitives that are supported. These functions are written in assemble and are relatively fast, and would make rendering in Mesa quite a bit faster when using the MGL. . Get the 3Dfx and S3 Virge accelerated version of Mesa compiled and working with the SciTech MGL. It should be possible to implement the new DGL OpenGL/DirectDraw bindings interface in these drivers for fully integrated fullscreen OpenGL support. Hardware OpenGL Support ----------------------- . Flesh out the support for the MGL 2D rendering and bitmap functions using the OpenGL drawing functions. This will then allow the MGL to run with hardware acceleration on hardware accelerated OpenGL drivers for the 2D MGL functions (like MGL_bitBlt, MGL_drawRect etc). Enhanced DOS Extender Support ----------------------------- . Update the support for the Phar Lap TNT DOS Extender, which can be used with the Borland, Microsoft, Symantec and Watcom C++ 32-bit DOS compilers. The basic TNT support functions are already implemented in the PM/Pro library (full interrupt handling, mouse handling etc). The only missing function is PM_mapPhysicalAddr() which maps a physical memory address to a linear address. In the early MGL 2.0 beta libraries this was done by creating a selector and using that selector in all the drawing code, however now the code is purely 32-bit flat linear addressing so this function needs to be implement. When running under a real DPMI DOS extender the Phar Lap DPMI 1.0 functions wont work, but you can probably write some code to detect this and use the direct DPMI calls that we use for the Watcom C++, Borland C++ and DJGPP versions of this function (see the GENERIC_DPMI32 section of the PMLITE.C module. Ports to other Operating Systems -------------------------------- The MGL internally is developed using a combination of C and assembler, however the MGL can be compiled using a #define NO_ASSEMBLER macro, which effectively disable all the runtime assembler functions and compiles in optimized C code equivalents to these functions. For ports to other OS'es running on the Intel platform, getting the assembler code to compile and link for that OS would be benefical, but for non Intel CPU's you can simply use the C only code. 1. Complete the port to the DEC Alpha running Windows NT. The MGL libraries have already been ported to the DEC Alpha, however some of the code in the MGL (specifically the fixed point math functions) could benefit from being re-written to use the DEC Alpha 64-bit multiples in C for very efficient fixed point routines. Some of the low level rendering functions like blitting might also benefit from a sprinkling of Alpha assembler code. 2. Port to the Linux OS. The MGL compiles and links fine with GCC under DOS (DJGPP), so it should compile and link just fine with GCC under Linux. We also have the OBJ2BFD utility that converts the TASM'ed assembler code to COFF, ELF or other formats so that it should be possible to compile and link the real assembler code with a Linux port. The most complicated part of doing a port to Linux is adding the MGL binding functions that usually live in the MGLWIN\MGLWIN.C module (the Windows version). These bindings would need to be developed to allow for rendering in a window using a X shared memory buffer, as well as rendering to a fullscreen display using whatever fullscreen technology is available. An even better project would be to get support for VBE/AF working under the Linux OS, and then you could do fullscreen exclusive modes similar to DirectDraw or WinDirect under the Windows environments. VBE/AF would take care of all the details of controlling the graphics card, and would include full support for 2D acceleration functions. A Linux port could also form the foundation of a port to any other OS (Intel or Non-Intel) based on the Unix environment. 3. Port to OS/2 Warp. This would be an interesting port, assuming that people are still interested in developing for OS/2. I dont know if many game developers would care about this, but perhaps IBM could step in and do this ;-) 4. Port to the Apple Macintosh OS. This would also be an interesting port. The Macintosh is a gamer developers paradise waiting to happen, since there are lots and lots of Macs hanging out in peoples homes. Being able to cross compile a game for the Mac without any major headaches would be a real plus. 5. Port to the Apple Rhapsody OS. This is going to be an interesting OS, so it would be interesting to see a port to this, especially the Intel version of Rhapsody. Perhaps Apple would be interested in doing this ;-) 6. Port to the BeOS. I dont know much about this OS, but it sounds neat. Perhaps a port to the BeOS would be cool, especially since the appear to be very focused on OpenGL so it might be a cool game developer platform. 7. Port to Silicon Graphics Workstations. Now this would be a killer port, especially if there was full OpenGL support in the libraries. With a port to SGI boxes, you could do testing and development on SGI boxes and then re-compile the code for testing on real PC before deployment. Maybe Silicon Graphics would be interested in doing this ;-) ---- END OF PROJECTS.TXT ----