Pointer & GPC question..._(re)

Tue, 26 Aug 1997 13:11:28 -0400

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 
> 	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

Orlando Llanes (a010111t@bc.seflin.org)