Beta Vibrant driver
3 messages in this thread
Ha. Ha. Speed isn't the issue here, Mr. Walbourn. The ability to have a
machine do network slave rendering while at the same time being available for
other things is. The ONLY thing keeping 3DS from being able to effectively
multitask under Windows is the fact that it's a graphics DOS program, and
graphics DOS programs can't multitask in a window and can really mess up the
Windows display even when running full-screen. The point of my driver idea is
to allow 3DS to run as a text-mode program when it is doing slave or
command-line or batch renders. It may also help OS/2 but not as much since
OS/2 can multitask DOS graphics programs, even in windows, as-is. But it would
help solve conflicting video mode problems in both multitaskers, since
EVERYBODY supports VGA text mode!
If you don't want the idea, just say so and I'll submit it to Panacea or
your other competitors. I gave you first crack at it because to date I've
liked Vibrant better, and your in-line technology could probably make it work
better. Heck, I could probably write an RCPADI driver myself to do this if I
put my mind to it.
I thought the real reason 3DS doesn't work under Windows (text or not) has to
do with "real breaks" being executed within the PharLap memory management code.
3DSr3 DOES work under Windows so long as DEVICE=PHARLAP.386 is added to the
[386enh] section of the SYSTEM.INI file (and, of course, that said PHARLAP.386
file is copied to the WINDOWS\SYSTEM directory). I believe that corrects the
"real breaks" problem.
A remaining problem is that unless a DOS program is Windows-aware and uses
some little-known tricks (which another user has detailed for us on this Forum
a few weeks back — thanks!), a DOS program cannot know when it has the full
screen or not, and if it's a graphics program and either the card or the video
mode is not one of the standard ones Windows knows about (CGA, EGA, VGA,
8514/A, maybe XGA, and that's about it), Windows cannot properly save and
restore the screen modes, so the DOS program would have to do so itself, and it
cannot know _when_ to do so without having to be Windows-aware.
Text mode programs don't have this problem, since Windows already knows how
to handle the standard text modes, including VGA's 80×50, the one I'm proposing
that this driver utilize. No need for it to be "Windows-aware" in this case.
And, it will multitask while running within a window, which no graphics DOS
program can do, period, even if it's "Windows-aware." This means, for
instance, you can have 3DS with this text driver running in Slave mode, in a
window that is using one of the small pseudotext fonts, and size the window
such that you can see only the "Frame ## of ###" and "Last render time" fields
of the status dialog box. Set the Background Priority somewhat low so that
3DSr3 doesn't slow other tasks down too much, and then you can use Windows
(say, to edit maps for another project) while at the same time your Windows
machine is helping out a tad with the network rendering farm.
Of course, all of this is moot with OS/2 2.1, which CAN multitask DOS
graphics programs, and does so MUCH more effectively than Windows, and to whom
Phar Lap isn't even an annoyance. Under OS/2, you can actually run multiple
copies of 3DS at once: say, one as a Network Rendering slave chugging away in
the background with little degradation, and another in UI mode accessing the
hardware key, with its Background Execution property (OS/2's Workplace Shell is
a fully object-oriented system) set to OFF so that it doesn't use any cycles
when you're not actively using it. So you can be working on one project while
rendering another! Whenever you take a break, just shove the UI instance of
3DS into the background, and it is suspended, allowing the Rendering instance
to run at nearly full DOS speed!
Not bad for a < $50 operating system! 🙂