SDL!!!!!!!!!!! SDL uses directX when available and GDI when it isn't. Not
all of us have cards that are OGL accelerated... for example this Matrox
card in my machine sucks at OGL.
Nick
----- Original Message -----
From: "Drew Northup" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, November 06, 2000 4:12 PM
Subject: RE: Peripheral considerations
> Cool...., sounds like you've been doing some really hard thinking.......
> Now if there were more of us who knew how to code those things...... (My
> specialty is crash-testing, seeing as I seem to be able to crash
> anything--LINUX & FreeBSD included....;^)!!)
>
> Drew Northup, N1XIM
>
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
> > Of Colin Davidson
> > Sent: Monday, November 06, 2000 4:58 PM
> > To: Plex86
> > Subject: Peripheral considerations
> >
> >
> > Hi Everyone,
> >
> > There are some general issues and trade-offs around peripheral
> > handling that
> > I thought worth thinking about in general and bearing in mind while we
> > discuss particular peripheral situations.
> >
> > There are at least four approaches to supporting peripherals in
> > Guest OSes:
> >
> > 1) Segragate the machine. Have the Guest OS use one set of
> > hardware and the
> > Host OS another. This is very little work, most of which is required
> > regardless of the approach actually taken, but requires extra
> > hardware (LAN
> > card, display adapter, mouse, keyboard, disk controller and hard
> > disk ... At
> > some point, you ask yourself why you don't just use 2 machines. In some
> > circumstances, though, it will give maximum performance for minimum
effort
> > and can be really worthwhile if you need either (graphics comes to mind
> > here).
> >
> > 2) Emulate a known piece of hardware - Ne2000, 3dfx voodoo3, etc, etc.
Use
> > the standard Guest drivers but punt their implementation to a host
device.
> > This allows the support to be written once, but kept up-to-date with the
> > latest driver from the hardware supplier - for as long as that supplier
> > supports the device in question. It relies on the hardware spec.
> > being well
> > enough known to emulate and assumes that the hardware/driver interface
is
> > simpler than the OS/driver interface. As it is at a lower level than the
> > OS/driver interface, it will almost inevitably be less efficient than a
> > higher-level emulation.
> >
> > 3) Emulate an virtual piece of hardware, designed to be easy and
efficient
> > to emulate. This hardware does not have to have any real existance. The
> > Guest driver captures the OS requests and passes them over to a
> > corresponding handler on the Host. This will be about as efficient as
> > emulation can be, but may need frequent updates in rapidly changing
areas
> > (DirectX, e.g.). It assumes access to Guest driver writing capabilities
> > (Windows DDKs, e.g.) and suffers from a potential problem of only being
> > partially open-source, as the driver may have to live "in" a proprietory
> > environment. Nonetheless, it may be well worth pursuing in cases where
the
> > driver needs to be efficient but dual hardware is prohibitive.
> >
> > 4) Use to same hardware in both OSes. This is really only possible for
> > stateless, synchronous peripherals, such as keyboards and mice, perhaps
> > (also potentially devices such as printers, which can report a "busy"
> > condition while being used by the other OS. Stateful peripherals, such
as
> > display adapters, and asynchronous peripherals, such as LAN cards and
> > Modems, are a poor choice for hardware sharing. In most cases,
> > this is a BAD
> > IDEA. Even where hardware can be share, some mechanism is required to
> > enforce sharing, so that only one OS at a time will actually access the
> > hardware.
> >
> >
> >
> > Note that in many cases, these option will not be exclusive and the
actual
> > best solution will depend on the situation at hand - what the user can
> > afford, what applications are running, personal ideology and a
> > host of other
> > factors. Where possible the implementation of a solution should
> > not prohibit
> > the implementation of an alternative. This really is a case of
> > the more the
> > merrier, so long as we get *something* working in a reasonable
timeframe.
> >
> > Cheers, Colin
> >
> >
>
>
>
