The following is an older page. In essense, the page was written with the feeling that C provided some useful functionality for some tasks like manipulating strings, but didn't provide a lot of features for interacting with graphics. Basically, this page represents a roadmap that I made for generating a library similar to SDL.

Before I completed this library, other "open source" libraries were developed and have become popular. Software to run a "virtual machine" has been created. Much of the plans mentioned on this page are not going to be pursued, largely due to a lack of current need. This document was written when there would have been greater benefit to having a library that provides these features.

Despite being very outdated, this page is remaining online, in the spirit of combating the "link rot"/bitrot that happens when pages go offline. Some of the decision to keep this may also be for personal/nostolgic/sentimental reasons, with the thought that I may view this again later in my life.

Without further ado, here is the older text that has been on this page even longer than this earlier text.

It is the position of Second Millennium Software that C is a powerful and portable language, but is not powerful nor portable enough, and Second Millennium Software is going to tackle that problem.

ANSI C, capable of displaying text to a screen and accessing files, is a very, very portable language.  Custom functions can be defined, making it quite flexible as well.  However, ANSI C has it's limits.  Second Millennium Software wants to expand on those limits a bit, while still maintaining as much compatibility as possible.

Second Millennium Software will be releasing expansion routines (with most of the programming being in a file called "gg.c").  These routines will add features such as graphics.  As much of this library set as is possible will be programmed via ANSI C or other, simpler functions within itself, so that there is very little work needed to be done in order to port the library.

3rd party help will be appreciated and possibly even requested in porting gg.c to multiple platforms, but no outside help is yet desired.  I have someone who says he will help make the DOS port for at least some of these functions.  I will hold off asking for more help until things are further developed.

The speed at which this library executes is pretty much not a concern.  That is, if programs written with these functions go slow, Second Millennium Software isn't worried about it.  Two things will be able to help alleviate things a bit:

Thing One Future programs by Second Millennium Software will use these functions.  Scaling graphics will use the simple, easily-portable, unoptimized graphic routines.  Then when another program runs the scaling graphics, the scaling graphics code will run the very simple, easily-portable, unoptimized graphics routines.  However, it should be relatively simple for a programmer familiar with a particular operating system to write a faster, system-specific, optimized graphics scaling function which may go quite a bit faster.  Then code which calls the scaling-graphics function can be sped up by individuals writing custom versions of the functions.  Meanwhile, those systems that don't have faster system-specific ports of Second Millennium's graphic library will still be able to use the slower version which is very easily ported.

Thing Two Second Millennium Software believes computers will continue to become naturally faster, and then a program's slow nature will become less and less apparent over time.  The goal of this library is compatibility and easy portability.  All performance issues will be blamed on the hardware, and hardware-specific optimizations is not likely to be written into the code.  (Compiler optimizations will, hopefully, alleviate some of the unoptimized nature of this code.)

No release date has been set.  As Second Millennium Software continues to bounce around new ideas as possible projects to work on next, more and more ideas of what should be included in gg.c are being created.  This leads Second Millennium Software into a position to either stall off on the new project being thought of, or to go ahead and work on the project duplicating the effort which will later be exerted when developing gg.c.  Despite Second Millennium Software's many plans on things to write, they are currently on hold until at least some of gg.c is complete.

For the time being, this is the plan.

Many of the following features will say "gg.c won't do much for this: This will be system specific."  Some of the features will require some system-specific code which will be programmed by an outside source. However, the programming will be written to Second Millennium Software's specifications, and will be incredibly simple in nature and easy to port.  Second Millennium Software will make the other functions which use the system-specific code. Some of the things in later drafts, such as sounds, are pure speculation and may never be tackeled in this project or by Second Millennium Software at all.

The system specific code will be made publicly available, so that others can see the specifications and exactly how it is done on various OS's, and to be able to port the code.  As for the rest of the code, it is not yet decided what parts will be made publicly available and what will not be. Such decisions will likely be made as each part is released, and may be subject to change (by releasing code previously unreleased).

Draft 1	Feature Status Comments Manual Virtual Memory 85%. On hold. May be dropped due to fairly limited demand. (Useless for many systems, such as Linux systems, or the native Windows 95 platform) Graphics 0% The following functions need to be provided for each OS: Return all available video modes.  Switch to specified video mode. Copy data (in a certain format) from RAM onto screen.  In fact, gg.c won't do much for the programmer yet in this draft. File Buffering 0%  May be dropped in favor of ANSI C stream buffering. Copies (specified amount) of data into RAM, then provides functions that act similar to getc() and fread() that access the RAM instead of the disk, intelligently swapping more data from disk to RAM as needed.  File Search 0% Searches through a file for specified bytes possibly ncluding HIGH-ASCII values, \0 (NULL), and others.
Draft 2	File Search If this doesn't make it in the last draft, it should make it into this one. DWDisplay Boxes In a very Dragon Warrior Style manner, creates display boxes (or text boxes, if you will).  Supports multiple display boxes, overlapping, and so forth. May change to add support for later drivers (see below). Source self-extraction A new version of source-code self-extraction.  It will be similar to my current programs that use bin2char.c, except that it will store all data in  the original, main C file.  No seperate bin2char.c or external .h files  required.  This will use file searching, so won't be done until that function is done.  It will be trivial to copy just this function and the required file-searching function w/o all of gg.c.
Later Drafts	Keyboard Initialization Are there keys buffered? What are they?  What's the status of the keyboard lights? gg.c won't do much for this: This will be system specific. Joystick Initialization What directions/buttons are pressed? Calibration.  gg.c won't do much for this: This will be system specific. Mouse Initialization Is there a mouse? What buttons are pressed? How fast is it moving, and it what direction? gg.c won't do much for this: This will be system specific. Timer For the timing of a computer. gg.c won't do much for this: This will be system specific. Keyboard Usage Functions to get input from the keyboard.  Allows keys being held down, and so forth. Joystick Usage Reads joystick values.  Reverses it for left-handed controls.  Force Feedback? Mouse Usage Displays mouse cursor on screen.  Cursor may change appearance. Mouse movement may be read at a 90 degree angle, inverted, or more. Mouse input may be read from a mouse, or virtualized from joystick or keyboard input. Sound Initialization Initializes sound card.  Returns number of channels.  Plays WAVE-type sound through one of the channels.  gg.c won't do much for this: This will be system specific. Sound Effect Playing Plays a sound in a (specified) channel. Plays multiple sounds in a single channel if necessary. If the sound card can't handle that, converts multiple sounds into a single sound escription. MIDI Synthesizing Converts MIDI music to WAV sound, similar to Wingroove, then plays it using above driver. MIDI Playing Plays MIDI via native mode driver, or selects MIDI Synthesizing method. gg.c won't do much for this: This will be system specific. Graphic Manipulation Includes such abilities as graphic resizing, graphic rotation, graphic flipping, graphic dithering, and then way down the road perhaps more advanced stuff like polygon support.