CompuServe Thread

No, I wasn't offended per se. I was, however, making a quite serious suggestion. Unlike some others here, we don't have the time or sufficient discretionary funds to play around, make jokes, discuss politics or how neat the pizza is in New York or what have you, in this Forum. When we make a posting here, it's of serious intent. Windows does not permit any graphics DOS program to run within a window or to multitask effectively. Text-only DOS programs work reasonably well under Windows, but going into ANY graphics mode, even CGA, let alone VGA or VESA, let alone the numerous non-standard SVGA modes out there, means the program will come to a screeching halt if you put it in a window. The ONLY way to allow 3D Studio to run in the background under Windows in such a way that you can visually monitor its progress and still see your other applications, is for someone to write either an RCPADI or an Inline driver that supports VGA's extended text modes. 80×34 is the minimum, but any VGA card can go to 80×50. Basically, any VGA card has three fonts in its character generator (not counting code pages): 8×8 for CGA emulation, 8×14 for EGA emulation, and 8×16 for VGA. Normal VGA text mode has a 640×400 pixel resolution, but the pixels are not individually addressable — they are only used to build the characters, and are under the control of the character generator ROM only. CGA text mode is 640×200. EGA is 640×350. Simple math shows that 200 scan lines divided by 25 rows of text equals 8 scan lines per character row for CGA. 350 scan lines divided by 25 rows of text equals 14 scan lines per character row for EGA. 400 scan lines divided by 25 rows of text equals 16 scan lines per character row for VGA. EGA cards include their own 8×14 font, as well as the 8×8 CGA font for emulating its modes. By using the 8×8 font in the EGA's 640×350 text mode, you get 350 / 8 = 43 rows of text instead of 25. You can get to that mode on either an EGA or VGA card by typing "mode 80,43" at a DOS prompt (if you have ANSI.SYS loaded). VGA cards can duplicate that function of EGA, or they can use the CGA's 8×8 font in the VGA's 640×400 text mode to provide 400 / 8 = 50 rows of text. Or they can use the EGA's 8×14 font in VGA's 640×400 text mode to provide 400 / 14 = 28 rows of text. Those are the standards supported on every VGA card made. VGA cards can support up to 480 scan lines, so by going 640×480 instead of 640×400, direct programming of a VGA card can yield 80×30 VGA 16-line characters, 80×34 EGA 14-line characters, or 80×60 CGA 8-line characters. To see all of these in action, try the various Display modes in the DOSSHELL program that comes with MS-DOS 5, and on the supplemental utilities disk available for MS-DOS 6.0 or 6.2. If 80×34 is all 3DS's UI requires, then you could support 80×43 mode (CGA font in EGA 640×350 text mode), and not only would this allow 3DS to run as a slave under Windows, but it would also allow 3DS to run as a slave on an EGA-equipped machine (to save money on a rendering farm)! Of course that's not a consideration anymore, since EGA cards are no longer made, and basic VGA cards are available for as low as $9. It might be better to go with 80×50 (CGA font in VGA's 640×400 text mode), as Windows has better support for that, even if 3DS's UI doesn't require that many rows. I'm going to go out on a limb here and speculate about the nature of 3DS video drivers. I'm assuming that they are low-level, but not extremely so — they can accept commands of somewhat higher level than "Set this pixel to this color." I'm assuming they can accept commands as high-level as "Draw a character at this location" or even "Draw a string of characters starting at this location" as well as "Draw a line from here to here" and "Fill a rectangular area between these two opposing corner points with this particular color." I base this on the fact that dialog boxes do indeed pop up faster on GUI-accellerator chipset cards, and rectangle fills are one of the things greatly speeded up by such cards which dialog boxes could take major advantage of. I base the bit about drawing strings and/or characters on the fact that your drivers allow the user to specify which font to use from a nice variety of supplied fonts. I notice that not all of those fonts are true monospaced fonts — the "BLOCK##" fonts (as oppposed to the "BLOCK##x##" fonts) do appear to be proportionally- spaced, but 3DS still draws them as monospaced (watch how the characters line up in neat columns in the menus even when one of those fonts is selected). Apparently, 3DS can specify the location to display text on a pixel basis, so that the text need not line up on standard character boundaries. This does complicate matters somewhat, but not that much — one can simply round to the nearest whole character position. If 3DS says "display this string starting at location 33,19 (with the origin being 0,0 in the upper left corner), the text driver can round both of those coordinates to the nearest multiple of 8 resulting in (32,16), and then divide by 8 to get the actual character coordinates (4,2 — fifth character column over from the left, three rows down from the top, since we start at 0,0). Drawing horizontal and vertical lines is more involved, but basically involves knowing when to use the "-" character (Extended ASCII 196) and when to use "|" (Extended ASCII 179) and when to use the various corner and connector characters for single lines (+, +, +, +, -, +, -, |, and +). This means knowing what character is already at a location before putting a new character there. If a "-" is at a location and you are told to draw a vertical line through that location, when you get there you will need to put a "+" there instead of a "|". Figuring corners and partial connects would be more involved still: basically, it involves looking at the cells adjacent to the cells you are drawing through. If a cell to the left of one where you plan on putting a "|" has a "-" then you would put a "|" in the cell just to the right of the "-", where you would normally have put a "|", and so on. If this is at the bottom endpoint of your vertical line, you would put a "+" there instead. Filling rectangles with color involves the characters " " (space, 32), "_" (full block, 219), "-" (? block bottom, 220), "|" (? block left, 221), "|" (? block right, 222), and "-" (? block top, 223). Because ? blocks are available, rectangles can usually be filled to a ?-cell resolution, rather than a full-cell (unfortunately, no ? or 3/4-block characters are available for corners, as they are in the Commodore 64's character set). Anyway, this should more than suffice for the status bar, dialog boxes, etc. Diagonal lines would be ignored, as would commands to draw icons for the icon buttons in the lower right corner, etc. After all, the intent here isn't for making the UI actually usable, but rather simply to provide a rough facsimile so that network rendering can take place in text mode. I really don't see what's so hard about this, or why it would be so impractical. I could probably do it myself as an RCPADI if I had access to the Protected-Mode ADI SDK, which I don't.

Chuck, >> 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. The advantage you have with the fact that 3DS is running in a DOS session under Windows is that it is in a seperate VM from the other Windows apps, so you can explicitly control how much CPU time gets dedicated to it, aka: pre-emptive multi-tasking. -Chris Panacea

I like the idea of a "no display" slave render session under windows. While I agree that its usefulness would be pretty limited, there are times when I would like to keep rendering while doing other stuff in windoze. I tend to have windows open a lot on one machine, but it also doubles as a render slave. If I could get it rendering in the bg, I would be rendering as I type this, although I understand that under many circumstances it would be slower than molasses <g>. I think it would be worth it if its not a really big deal to implement. thanks, John Tissavary (LUNA cie)