🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.os.msdos.programmer
Article #7733

Re: Help w/ VGA Graphics Animation Routines

#7733
From: Junaid Walker
Date: Mon, 25 Jan 1993 05:18
41 lines
2624 bytes
In <1993Jan19.104520.13127@ousrvr.oulu.fi> scorpion@phoenix.oulu.fi.oulu.fi (Antti Kangas) writes:

>Joe Huffman (joe@proto.com) wrote:
>: jap7g@fermi.clas.Virginia.EDU (Jim Alan Pisano) writes:
>: 
>: >I need to write some animation-type graphics routines for VGA 16-color
>: >480X640 mode.  Specifically I'd like some routines that block copy from
>: >normal RAM to the VGA video RAM and once the images are in video RAM, then
>: >swap frames for high-speed animation.
>: 
>: I prefer to use the super VGA VESA 256 color modes (resolutions include
>: 640 x 480).  This gives you a one byte per pixel interface which allows
>: for easy data manipulation off screen with no conversion when doing the
>: transfer to the real screen.  The no conversion when doing the transfer


	I am in the process of creating a simular sprite library for
SVGA modes.  I agree competely, there's nothing like raw (non-bitplane)
video memory.  I also want to support mode X (320*480*256...) but using
the INT 10 mode 13 to boot the card in 320*200*256 and then tweaking
(like in the vgakit41) divides each video address into bitplanes and you
need to output a byte to some port for each memory access to select the
correct bits.  What a kludge!

BIG QUESTION: does anyone know how de-bitplane mode X and other standard
'IBM' 256 color modes?

Had a look at vgadoc the other day, nothing useful......



	As an asside, mere blitting to video memory isnt the problem,
its putting sprites on the screen without redundantly reading from video
memory (unless you keep a screen size background buffer).  Anyone have
any ideas for a sprite collision detection routine for N sprites?
I was thinking of a y-axis orrderred binary tree or hash array to reduce
bank switching.  But this still doesnt give you sprite collision
detection capability.  Think about it, it's not a trivial problem.
You update sprites in whatever convenient order and check for a
collision.  But there must be a better way than cheching the current
sprite for a collision with every other sprite?
Technical Details
Message-ID: <1993Jan25.051817.24757@monu6.cc.monash.edu.au>
Path: arc1-ca.pugleaf.net!sparky!uunet!munnari.oz.au!bruce.cs.monash.edu.au!monu6!yoyo.cc.monash.edu.au!junaid
References: <1993Jan18.190150.5024@proto.com> <1993Jan19.104520.13127@ousrvr.oulu.fi>

Show Full Headers
Complete Article Headers
Newsgroups: comp.os.msdos.programmer
Path: arc1-ca.pugleaf.net!sparky!uunet!munnari.oz.au!bruce.cs.monash.edu.au!monu6!yoyo.cc.monash.edu.au!junaid
From: junaid@yoyo.cc.monash.edu.au (Junaid Walker)
Subject: Re: Help w/ VGA Graphics Animation Routines
Message-ID: <1993Jan25.051817.24757@monu6.cc.monash.edu.au>
Sender: news@monu6.cc.monash.edu.au (Usenet system)
Organization: Monash University, Melb., Australia.
References: <1993Jan18.190150.5024@proto.com> <1993Jan19.104520.13127@ousrvr.oulu.fi>
Date: Mon, 25 Jan 1993 05:18:17 GMT
Lines: 41