home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.os.msdos.programmer
- Path: 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
-
- 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?
-