home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / os / msdos / programm / 12425 < prev    next >
Encoding:
Text File  |  1993-01-25  |  2.5 KB  |  53 lines

  1. Newsgroups: comp.os.msdos.programmer
  2. Path: sparky!uunet!munnari.oz.au!bruce.cs.monash.edu.au!monu6!yoyo.cc.monash.edu.au!junaid
  3. From: junaid@yoyo.cc.monash.edu.au (Junaid Walker)
  4. Subject: Re: Help w/ VGA Graphics Animation Routines
  5. Message-ID: <1993Jan25.051817.24757@monu6.cc.monash.edu.au>
  6. Sender: news@monu6.cc.monash.edu.au (Usenet system)
  7. Organization: Monash University, Melb., Australia.
  8. References: <1993Jan18.190150.5024@proto.com> <1993Jan19.104520.13127@ousrvr.oulu.fi>
  9. Date: Mon, 25 Jan 1993 05:18:17 GMT
  10. Lines: 41
  11.  
  12. In <1993Jan19.104520.13127@ousrvr.oulu.fi> scorpion@phoenix.oulu.fi.oulu.fi (Antti Kangas) writes:
  13.  
  14. >Joe Huffman (joe@proto.com) wrote:
  15. >: jap7g@fermi.clas.Virginia.EDU (Jim Alan Pisano) writes:
  16. >: 
  17. >: >I need to write some animation-type graphics routines for VGA 16-color
  18. >: >480X640 mode.  Specifically I'd like some routines that block copy from
  19. >: >normal RAM to the VGA video RAM and once the images are in video RAM, then
  20. >: >swap frames for high-speed animation.
  21. >: 
  22. >: I prefer to use the super VGA VESA 256 color modes (resolutions include
  23. >: 640 x 480).  This gives you a one byte per pixel interface which allows
  24. >: for easy data manipulation off screen with no conversion when doing the
  25. >: transfer to the real screen.  The no conversion when doing the transfer
  26.  
  27.  
  28.     I am in the process of creating a simular sprite library for
  29. SVGA modes.  I agree competely, there's nothing like raw (non-bitplane)
  30. video memory.  I also want to support mode X (320*480*256...) but using
  31. the INT 10 mode 13 to boot the card in 320*200*256 and then tweaking
  32. (like in the vgakit41) divides each video address into bitplanes and you
  33. need to output a byte to some port for each memory access to select the
  34. correct bits.  What a kludge!
  35.  
  36. BIG QUESTION: does anyone know how de-bitplane mode X and other standard
  37. 'IBM' 256 color modes?
  38.  
  39. Had a look at vgadoc the other day, nothing useful......
  40.  
  41.  
  42.  
  43.     As an asside, mere blitting to video memory isnt the problem,
  44. its putting sprites on the screen without redundantly reading from video
  45. memory (unless you keep a screen size background buffer).  Anyone have
  46. any ideas for a sprite collision detection routine for N sprites?
  47. I was thinking of a y-axis orrderred binary tree or hash array to reduce
  48. bank switching.  But this still doesnt give you sprite collision
  49. detection capability.  Think about it, it's not a trivial problem.
  50. You update sprites in whatever convenient order and check for a
  51. collision.  But there must be a better way than cheching the current
  52. sprite for a collision with every other sprite?
  53.