🚀 go-pugleaf

In article <38152@uflorida.cis.ufl.edu> LIONESS@oak.circa.ufl.edu writes:
>In article <82592@mavenry.UUCP>, nider@mavenry.UUCP writes:
>>
>>much of  a problem.  As 386 is now the standard for good software, expect 
>>better games to be programmed. 
>
>This is a gross overgeneralization of the situation.  Programmers are NOT
>the one's to blame for everything.  Can you blame a programmer because
>he can't transfer more than 2MB/sec over the ISA bus?  Sure, if he
........
>
>The problems/solutions that I see are as follows:
>
>A.  The ISA bus is 16-bit wides and 8MHz, with a realistic max throughput
>of 2MB/Sec.  The solution to this is to use local bus video ( which can
>up throughput to 33MB/Sec ) and/or an EISA bus machine.  Both require
>extra hardware and cost.
>
And 2MB/sec cannot be obtained on a standard vga, since you have to
set i/o ports (8 bit access and lots of cpu register swapping)
and pass your data in 8 bit chunks thru those dreaded latches.
A real 2MB/sec transfert rate can be obtained only in "block mode"
(moving data 4 bytes a time thru latches).

>B.  The PC does not support coprocessed video functions with a stock
>VGA.  Stock VGA provides NOTHING drawing wise.  It is a dumb frame
>buffer.  The solution is to use a coprocessed video board such as an
Yeah! And not a plain frame buffer, but a darned kludged frame buffer.
When those IBM guys designed VGA they just produced a "super ega"
without real 16 bit enhancements (and they designed it for Microchannel !!!)
IF they simply provided a 128k "memory window" instead of those pesky
max. 64k "memory windows" displaced in a 128k range
AND
added some planar addressing with REAL 16 bit access
(even in 320x200x256 MCGA mode a 16 bit transfert gets internally
translated to two 8 bit transferts to different planes, if i remember well)
NOW
we would have a GOOD frame buffer zipping at 2MB/Sec (real life performance).
Sigh! With a 2 MB/sec RAM to VRAM transfert rate , 128k "memory window"
and planar addressing i could do wonders!!
..........
>
>The PC programmer can assume the following about most of his target machines:
>
>1.  A dumb frame buffer supporting transfer rates of 2MB/sec.
     It's better assume 512kb/sec .
     You can get 2MB/sec only if you switch to "block mode"
     ( moving 4 bytes at a time from VRAM to VRAM)
>2.  32-bit registers and instructions.
     Hmm! Most of the time it's better to stay in 8086 mode
     and use 32-bit instructions with care (if you don't switch to 
     protected mode you have to use op-code prefixes for every 32-bit
     instruction , but switching to 32-bit protected mode you need
     a good dos-extender).
>3.  At least 16MHz clock speed.
>
>The limiting factor here is obviously the frame buffer.  When we manage
>to get another standard out there that is faster and makes more sense...say
>IBM comes out with an integrated 32-bit wide XVGA or something to set a
>new standard ( XGA failed and so did the 8514/A ), then we may be able
>to get better looking games.  But hardware assistance is the key, and the
>PC just doesn't have it.
>
>Brian

There are GOOD graphic cards now, no need for a new video hardware standard.
What is really needed is something like "Quicktime for Games"
or "Video Game Extensions for Windows" with unified graphics data formats
and graphic routines geared for video game animation
providing at least:

Video mode initialization

Dual video buffer (write on one page and display the other)
& related page flipping & pixel by pixel scrolling functions.

VRAM buffer i/o for storing bitmaps that need quick drawing

Line drawing & Polygon drawing functions 
(just drawing a single color OR a gradient , with no clipping)

Bitmap Drawing functions (simple blits and "sprite-like" blits).

BITMAP COMPILER (translating generic bitmaps to quick-to-draw formats)
                (at least two choices: "quick blit" data reordering
                                     & "inline code" data compiling)
                (and at least two animation modes: single frame
                                                 & delta-frame animation)
& "compiled bitmaps" drawing functions.

QUICK BACKGROUND REFRESH ( pass a pointer to a matrix specifing
                           the background patterns codes
                           and the routine draws the equivalent 
                           bitmaps on active page using the quickest method)
			 (this is useful for games like commander keen)

With a group of routines like these, nearly everything can be done
("special effects" can be created using a collection of bitmaps
 and compiling them with the bitmap compiler into an animated sequence)
What's more, routines like these are no harder to program than 
a Windows video driver.

Lorenzo Micheletto       mike@sabrina.dei.unipd.it

P.S. Forgive my possible mistakes, as you can guess from my name and
     internet address, i'm not very skilled when it comes to write something
     in english.