rhodes@rogue.llnl.gov (Rhodes, Mark) (10/30/90)
Flight simulators are very processor intensive and so is WINDOWS. The two together are a bad mix. Just for fun I tried running FALCON AT under WIN3 with some very amusing (and unusable results). So far, I think windows is great for things like DTP and drawing programs like DESIGNER and little else. I'd be very surprised to see a decent flight game run under windows ( maybe a 486 with ultra fast video).
aaron@jessica.stanford.edu (Aaron Wallace) (10/30/90)
In article <85057@lll-winken.LLNL.GOV> rhodes@rogue.llnl.gov writes: >Flight simulators are very processor intensive and so is WINDOWS. The two >together are a bad mix. Just for fun I tried running FALCON AT under >WIN3 with some very amusing (and unusable results). So far, I think >windows is great for things like DTP and drawing programs like DESIGNER and >little else. > >I'd be very surprised to see a decent flight game run under windows ( >maybe a 486 with ultra fast video). It could probably be done *if* a Windows-specific implementation were written. When running a DOS graphics app under Windows, the double-buffering kills graphical performance (i.e the app writes the info to what it thinks is the screen, then Windows copies it to the Window.) A Windows-based flight simulator wouldn't have this problem. Whether Windows' graphics routines are as fast as specialized ones for flight simulators is a different story... Aaron
jls@hsv3.UUCP (James Seidman) (10/30/90)
In article <85057@lll-winken.LLNL.GOV> rhodes@rogue.llnl.gov writes: >Flight simulators are very processor intensive and so is WINDOWS. The two >together are a bad mix. Just for fun I tried running FALCON AT under >WIN3 with some very amusing (and unusable results). So far, I think >windows is great for things like DTP and drawing programs like DESIGNER and >little else. You might try running in Standard mode, which is much faster than 386 Enhanced mode for running DOS apps. If you want to run it in 386 mode, you should adjust the PIF to (a) make it run in exclusive mode, and (b) set the "Monitor Ports" in the advanced section to "Text." Part (b) alone will make a tremendous performance difference. Any graphics-intensive application will perform terribly if the PIF has "Monitor Ports" set to "High Graphics." That setting will add quite a bit of overhead to the graphics functions. If you're not doing something else processor intensive in the background, the speed of calculation itself shouldn't be too much of a problem. When not running other programs, you should suffer less than a 15% performance hit. Assuming you're running in 386Enh mode, try this and see what a difference it makes. -- Jim Seidman (Drax), the accidental engineer. "It doesn't have to work... they'll be paralyzed just from laughing at me." - Dr. Who, _Shada_ UUCP: ames!vsi1!hsv3!jls INTERNET: hsv3.UUCP!jls@apple.com
strobl@gmdzi.gmd.de (Wolfgang Strobl) (10/30/90)
rhodes@rogue.llnl.gov (Rhodes, Mark) writes: >Flight simulators are very processor intensive and so is WINDOWS. The two >together are a bad mix. Just for fun I tried running FALCON AT under >WIN3 with some very amusing (and unusable results). So far, I think >windows is great for things like DTP and drawing programs like DESIGNER and >little else. >I'd be very surprised to see a decent flight game run under windows ( >maybe a 486 with ultra fast video). You don't need a 486 or an ultra fast video card to do that. Windows clean separation of application programs, the graphics device interface and the video driver make it possible to take advantage of new hardware developements - like video cards with builtin processor and intelligence - without changing or even relinking the programs. Intelligent video cards like the Hercules graphics station card are a bit expensive today, but I don't see why they shouldn't go down in price like the SVGA adapter's did within one or two years. With these cards, the advantage of tuned assembler hacks using a memory mapped video interface over using a GDI will suddenly disappear. Ok, the Windows API/GDI was not written with the game programmer in mind, but it isn't that bad for this purpose, either. Perhaps I am a bit biased, because I don't like fast animation games (mostly "shoot'em up" type), anyway :-) Wolfgang Strobl #include <std.disclaimer.hpp>