Sounds good to me so far......, the only major stumbling blocks to
implementing the full-screen video so far as I see it are as follows:
1) We will need some sort of separate status window, so that if something,
somewhere goes awry, we can always drop back to some sort of
console/std-error and recover,
2) If we plan for this to run on win32 ever in the future we'll need to deal
with the fact that windows just loves to access video memory directly (there
is some sort of addressing "lock-out" to keep things down to the current
"master" application.....--i.e. in win95,98,&98se the shell graphics/master
window handler, explorer.exe.... a module kernel32.exe, is usually the
master--but I have no idea how robust this is.....) and not use some sort of
host buffer space in userland. If X uses a similar "painting method" (does
it?) then we could, in theory, "grab" the video output pipe directly..., or
maybe easier yet, we could just make the plex86 output take up one entire
virtual desktop and just use the local accelerated X video routines instead
of writing our own & re-inventing the wheel...per se. These routines
should, in theory, allow us to get to the frame/z buffers pretty directly
with little overhead. I am not sure, but I do believe that this is how the
job is done for many "DirectX" [(c) MS] style games. So far as I know the
rest of them just grab the output device directly, and do the rendering
themselves with no Win32API help--which is something that, to my knowledge,
unix systems don't really appreciate!!!
Drew Northup, N1XIM
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
> Of Sintsov Dmitri
> Sent: Tuesday, October 31, 2000 5:07 AM
> To: [EMAIL PROTECTED]
> Subject: plex86 video proposal
>
>
> Greetings,
>
> Here's my thoughts on the possible way of video implementation in plex86:
>
> General idea of plex86 is virtualization, not emulation. Running multiple
> virtual PC's at the same PC hardware. Thus it means to emulate as less of
> CPU as possible to allow virtualization to run at maximum speed. Thus I
> believe it makes sense to use the same approach for virtualization of the
> rest of hardware (because we are virtualizing PC archtecture, not just
> x86).
> Virtual and real hardware matches, so when it's possible to access some
> particular hardware exclusively (eg. video when running full-screen
> guest so no other host tasks accesses it simultaneously), it should be
> possible to allow full-screen guest to access video hardware directly (in
> the similar way windows uses full-screen VGA in VDM's, but extending it to
> SVGA and 2D/3D-specific hardware of modern accelerators). Benefits could
> be the fastest possible video access for guest, including 2d/3d
> acceleration not having to write an additional layer to host os
> drivers (x/ogl/directx etc). However I realize that windowed guest is also
> required, but it doesn't prevent from implementing a faster technique for
> full-screen mode. Another problem I can think of, is that some of modern
> accelerators have a lot of on-board RAM, 64MB could be a lot to
> save/restore when switching from full-screen guest to another task and
> back, however it maybe possible to optimize this code. Also, the question
> is, could the code of initializing/saving/restoring the state of specific
> video chip be obtained freely. Also, SDL is a good approach of portable
> video, however is it worth to write additional layer of 2d/3d
> acceleration, which could cause slow-downs and compatibility problems,
> when the guest hardware matches the host hardware. But I understand that
> for bochs, being a cross-platform using portable library is the only
> possible approach (also probably for windowed guest of plex86).
> Uhus
>
>
