Ok..., that sounds cool....... maybe I can dredge up some good pure Win32API
stuff to help us on the windows implementation end of things..........(make
the DirectX calls cleaner & more streamlined for one thing......). As for
the native graphics privileges/primitives, I think that, at least on Win32,
we can do a direct frame/Z-buffer to a window and allow the system graphics
handler to do the rest (less trouble in the case of a Win32API kernel
panic.... which happens way to often as it is....). Can somebody check this
one (as I have no idea where to start looking for it)?
Also..., as an aside...., if anybody wants to continue to argue about the
video-modes for the splash-screens--let's do that off of this list, ok? It
is starting to look a little bit too much like comp.os.windows.w98se (is
that the right name...., anyway you get the point....) in here.
Drew Northup, N1XIM
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
> Of Nick Behnken
> Sent: Friday, October 27, 2000 4:44 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [plex86] X Windows in plex86
>
>
> Im working on SDL-1.1 in Bochs.... This gives me a framebuffer to write to
> in BeOS / Linux / Windows. SDL will use (I think) DGA / Direct X /
> BDirectWindow or fall back to using the native graphics primitives.
>
> Check it out at http://www.devolution.com/~slouken/SDL/
>
> Nick
>
>
> ----- Original Message -----
> From: "Sintsov Dmitri" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, October 27, 2000 3:37 AM
> Subject: Re: [plex86] X Windows in plex86
>
>
> >
> >
> > On Thu, 26 Oct 2000, Jeffrey B. Siegal wrote:
> >
> > > I think an easier way to get X work would be with flat 256 color (one
> byte per
> > > pixel). Then there are no latches to worry about. There is
> a standard
> VGA mode
> > > for 320x200, and VESA linear-address modes for higher
> resolution. (This
> would
> > > work with vesafb and XF86_FBdev.)
> > >
> > I agree with that, too. If running in full-screen mode, no latch access
> > even has to be trapped for 16 color modes, because VGA has been designed
> > to allow to completely save/restore state of video in hardware (dump of
> > vram, and regs are r/w). I remember that used to be one of the major
> > advantages of VGA over very similar older EGA standard, which was less
> > multitasking OS'es friendly because it didn't allow to get full state of
> > video hardware. Interestingly, is it possible to get a quick
> fast hack of
> > running plex86 with modern 3d accelerators in full-screen mode
> not having
> > to write special drivers/layer of access to host OS drivers, just by
> > saving full video state, re-initing card (in a similar way that BIOS is
> > doing) and allowing direct access to video in full-screen mode, when you
> > switch to host OS/other apps, it will restore the prevoiusely
> saved state.
> > My point was, I believe that windows doesn't trap that much of
> video when
> > it runs VGA full-screen (I might be wrong, but it looks fast). You
> > have to write initer/saver/restorer of state for this specific
> > card, which should be easier than writing the complete driver.
> Running in
> > window would be more tricky, of course (it's just I personally
> feel enough
> > to run full-screen).
> > Uhus
> >
> >
> >
>
>
