I know I'm pushing the envelope with this series of e-mails, so if it's off-topic, then reply by e-mail, we'll discuss it there, and I'll post a summary to the list if desired.
Cool, so would the admin have to install it? Or could it be installed by a normal user? Another thing I'm curious of is does Linux use or support DPMI in it's native state? Or does it have it's own proprietary memory scheme?
From: Michael Meeks michael@zeus.imaginator.com Because ... this would invalidate all the security measures. At ... is youre uncle ( perhaps ). oh, and make the program run suid to that
For the time being, I'll create wrappers for SVGALib. I'm not just creating a graphics lib, I'm creating a cross platform game programming lib (yes I'm aware of SVGALib ported to the PC, but it's buggy). I'm looking at how things are done on different OS's so I don't take a wrong turn with my lib. For example, while I was planning the Mode-X support and working on VBE support, I realized that graphics on the Macintosh are different (I decided to "emulate" these modes on the Mac if possible).
I would just use SVGAlib myself, as it is supported, and supports lots of hardware + there is llittle point in duplicating effort ! :) and IIRC it supports off screen buffers etc.
The architecture I'm using for the graphics portion of the game lib is similar in concept to a loadable device driver, but it will use objects: * A unit defines a base object and is used as a pointer to the other objects in the "generic" unit * Each object overrides the base API * Methods added are proprietary to the object, otherwise there is no need to extend the base object API further * According to certain mode ranges, a specific object is initialized (de-initializing the previous one if neccessary) and the object base pointer is set to that of the new object * An off-screen buffer is allocated by the object * Error codes are returned so the programmer can handle errors and so that the programmer knows where the objects failed (memory error, driver failure, etc) * The off-screen buffer is exposed so that the programmer can implement their own custom routines, special effects, 3-D routines, etc * First set of inherited objects will support VBE 256/32k/64k/16M color modes, VGA, 3 to 7 Mode-X resolutions (VBE LFB will be supported after the VBE engine is in place) * Expandable to support triple buffering (I haven't fully thought this out yet) * Custom mouse handlers (also not fully thought out yet) with support for monochrome or 256/hi/true color cursors
If anybody has a suggestion on something to add, any ideas, or would like me to send them the game lib specs, feel free to e-mail me. My goals are to make the libs logical, tight coded, handling as much of the platform/OS specific details as possible (Device Context Handles in Windows for example), to make the lib Modular yet Integrated, to provide flexibility, to make it easily extensible, and to provide a "load on use" style so that only what's needed is loaded.
See ya! Orlando Llanes