CompuServe Messages

Beta Vibrant driver

    11-Apr-94 17:07:55
To: Marion K. Marks 70700,2777
Sorry if you are offended by my earlier comment. I had originally assumed that it was a 'tounge-in-check' request. I appologize. Thank you for giving us your feedback and I am truely sorry if you feel that I belittled your input. Vibrant's current work with the Inline driver has not focused on Windows as the platform–our primarly goals were to deal with the hardware compatability issues under DOS. We did not design the driver (or our draw-code) to work under the Window's environment and it would take a good deal of work to deal with this correctly. We have recently gotten some good information via CompuServe which would make dealing with this technically feasible in some cases, but would require a great deal of work on our part. I don't think the 'text' driver would be as easy as you might think. I will, however, take a lose look at it. One big problem is that the display needs a 80×34 text area, so placing text would be fairly complicated, if even possible, unless we put the system into a non-standard text mode–this might create problems. Status information would be extremely complicated to display because the interface is very low-level (we don't know if we are clearing a viewport or drawing the red status bar on a render, or clearing a menu area, etc.). Making a driver which displayed nothing would be easy, but configuring it may be complicated. Do you know if the NULL driver is accepted for the MAIN-DISPLAY variable? I think I'll try it out. I am not convinced that this would be particularly useful even if it did operate correctly. I guess my main concern is that slave render mode is EXTREMELY CPU hungary, and multitasking (particuarly Window's implemenation multi-tasking) such a heavy process may severly impact system performance. The DOS applications are given processing as long as they do not perform writes to video memory, which is why the graphics mode updates prevent Windows from giving it any time. Therefore a NULL driver would allow it to run, but I don't know how much useful processing could be done in the background. It might be worth a try to do a 'NULL' driver option and do some benching. Again, Vibrant did not develop the 3D Studio Inline driver to work with Windows. There was also no requirement for this in our agreement with Autodesk, and we were not originally aware that this would be a big issue. The standard VGA modes work correctly for the most part, but higher-resolutions modes do not. We are looking into the issues, but we currently don't have a lot of resources allocated to 3D Studio R3 Windows. With that said, I'll look into what is involved for essentially a 'NULL' display driver for slave mode. Are you able to get 3D Studio to run configured for basic VGA modes as the display? I was under the impression that Windows handles the Generic VGA modes and VESA modes fairly well. If speed is not an issue for you doing this, you might want to give this a try. Chuck Walbourn – Vibrant Graphics