home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Shareware Overload
/
ShartewareOverload.cdr
/
database
/
suprig36.zip
/
SUPRANSI.DOC
< prev
next >
Wrap
Text File
|
1990-07-10
|
4KB
|
104 lines
Super Rig! v3.5
===============
Notes on ANSI terminals and Extended Graphics compatibilitiy
ANSII graphics problems with different terminal software is not unique.
I have had comments from users on the Main title screen, where the truck
is not displayed right, and on the TruckStop screen where the gas pumps
are not displayed right either.
Ok, the truck screen and the truck stop are stored in the current game
directory under the names TITLE.SCR and TRUKSTOP.SCR. These files can
be TYPE'ed to screen with (MS-DOS 3.x - 4.01) ANSI.SYS driver installed
in the CONFIG.SYS of the machine in question. Some video boards that
include ANSI drivers (such as Orchid's EANSI.SYS) and others, will not
display EXTENDED ANSI GRAPHICS SETS correctly!
You can look at these files anytime by entering this on the command line;
TYPE TITLE.SCR (return) ;sitting in the game directory.
When these or any other .SCR files are transmitted, they are read in
from their respective disk files and transmitted directly to the COM
port. As the ANSI file is being transmitted it is displayed locally
through an 'internal' ANSI file reader and displayed on the users
local video screen.
MANY terminals that claim to be able to display ANSI graphics are only
partially correct (ie. VT-100 emulators). Currently, I know of (3)
terminal programs that WILL display the -extended- ANSI/ASCII graphics
sets correctly.
They are these;
PROCOMM 2.4.2 (and v2.4.3)
PCPLUS v1.1b
Qmodem v4.x
Testing a terminal program
==========================
If you have a 'question' of the ANSI/ASCII compatibility of a terminal
program you can do the following short test!
[1] In the terminal in question; make sure its setup that XON/XOFF flow
control is turned OFF!
[2] Use the terminals ASCII (download transfer menu) Protocol to capture
what comes in over the COM port into a disk file. You can hit the
particular key to envoke this immediately PRIOR to starting the
game up, so that when the game begins, its writting to disk the
data that is coming in over the port.
As soon as a screen is completed, you can END the ASCII transfer
to disk (in Qmodem and PCPLUS its hitting ESC.) You have now
'photographed', so to speak - the incoming file to disk.
Now that you have the "transmitted" file on disk, you can SHELL
out to DOS and TYPE it to screen. It should be identical to the
file that is on the HOST (transmitting computer) in all respects
from DOS. It might also contain prompts and other characters that
are sent immediately prior, or immediately after the ANSI screen
in question - but you can 'see' if the basic color screen was sent
correctly.
Screen 'capture' modes and screen scroll back buffers DO NOT WORK
in attempts to re-read ANSI screens, as ANSI control codes are not
stored on the screen, they are cursor and color positioning screen
commands.
This will prove whether the file was transferred un-altered to the
remote machine and that the REMOTE terminal is/is not 'translating'
the incoming file correctly. There is a lot of them that will NOT
handle the 'extended' character sets (outside normal text/graphics).
If you were to try using the above mentioned terminals - you should be
able to see the difference as well.
I know this to be a problem, as I have experienced this first hand in
the creation of these games and the different complaints from my local
users on 'scrambled' or display problems on ANSI graphics. So, all
games are tested via the "DOS" and "capture" method, and in using the
above programs to 'view' the games via remote modem.
I hope that this will SysOps some info and direction there concerning
display problems on remote terminals. Note also, there might may be an
ocassional 'drop-out' bit transmit problem (at hi-speeds) on terminals
that rely on BIOS com port polling for the serial ports. Changing to a
buffered 16550an UART on the serial cards will fix that, in addition to
setting RTS/CTS hardware handshaking on the remotes modem - to prevent
buffer overruns and bits being dropped, inducing hardware transmission
errors.
- Marv'-