Article View: comp.os.msdos.programmer
Article #7733Re: Help w/ VGA Graphics Animation Routines
From: Junaid Walker
Date: Mon, 25 Jan 1993 05:18
Date: Mon, 25 Jan 1993 05:18
41 lines
2624 bytes
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!junaidReferences:
<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