saunders@triton.unm.edu (Richard Saunders CIRT) (06/05/91)
I was wondering about the technical feasibilty of a better Dynamic Hi-res mode. As I understand Dynamic Hires, every raster line can change its pallete, in effect giving you any 16 colors per line. Well, the 16 color limit per line comes from the fact that Hires screens can only use 4 bitplanes ... so is there a way to use all 32 color registers instead of just the first 16? Well, how about if we used all eight sprites FOR EVERY LINE? Have every sprite be just one pixel high (one raster line high), and change the definition of all 8 sprites every raster line. The sprites use color registers 16-31, so by displaying the sprites at every raster line, we could increase the number of colors to 32 ... Now granted, this is an EXPENSIVE graphics mode, as every raster line would have to reuse all eight sprites as well as do the normal dynamic hi-res magic, and the extra 16 colors would be limited to the size of the sprites (16 bits * 8 sprites, only 128 bits per raster line for our new 16 colors), but this mode might be real useful for a GIF viewer, or something like that. Now, I am fairly new to the amiga community (just got my 3000 a few months ago), but does this "dynamic hires with sprites" sound like a resonable graphics mode? I'd like to try it out, but I'm still not an Amiga Guru yet ;v) * saunders@triton.unm.edu * "This is _NOT_ Mel Torme!" - Top Secret
aaron@stat.tamu.edu (Aaron Hightower) (06/07/91)
In article <1991Jun05.165952.14140@ariel.unm.edu> saunders@triton.unm.edu (Richard Saunders CIRT) writes: >I was wondering about the technical feasibilty of a better Dynamic >Hi-res mode. As I understand Dynamic Hires, every raster line can >change its pallete, in effect giving you any 16 colors per line. >Well, the 16 color limit per line comes from the fact that Hires >screens can only use 4 bitplanes ... so is there a way to use all >32 color registers instead of just the first 16? > >Well, how about if we used all eight sprites FOR EVERY LINE? >Have every sprite be just one pixel high (one raster line high), >and change the definition of all 8 sprites every raster line. >The sprites use color registers 16-31, so by displaying the sprites >at every raster line, we could increase the number of colors to 32 ... >Now granted, this is an EXPENSIVE graphics mode, as every raster >line would have to reuse all eight sprites as well as do the normal dynamic >hi-res magic, and the extra 16 colors would be limited to the size >of the sprites (16 bits * 8 sprites, only 128 bits per raster line >for our new 16 colors), but this mode might be real useful for a GIF viewer, >or something like that. One problem with this method is that sprites are displayed in LORES, regardless of what resolution the screen is in (unless it is productivity mode or something above 640x400). What you would need to do is set the sprites behind the bitmap so that you can cover up half the sprite LORES pixel with a ViewPort/Screen HIRES PIXEL. Interlace would be the same thing. In other words, in HIRES | LACE, a sprite pixel would occupy the equivalent of four screen pixels. So your real problem arises when you need more than one of the 16-31 color values within that sprite pixel. >Now, I am fairly new to the amiga community (just got my 3000 a few >months ago), but does this "dynamic hires with sprites" sound like >a resonable graphics mode? I'd like to try it out, but I'm still >not an Amiga Guru yet ;v) You may want to try it out, but I wouldn't expect superb improvements considering the amount of effort that would be required. You would need to duplicate the background color (color register zero) so that you could cover up the sprite with that color instead of letting the sprite be displayed in that position (SPRITES would be displayed in place of any location with a color zero, so basically if there is a sprite in a position, you lose the ability to use color register zero - for all practical purposes, you lose one color (which means you have 15 colors + sprite stuff)). > >* saunders@triton.unm.edu * "This is _NOT_ Mel Torme!" - Top Secret --- Aaron Hightower :: aaron@stat.tamu.edu // // Check out "yatc.lzh" on ab20.larc.nasa.gov - /amiga/games or /incoming/amiga // It's a self-playing 3D-look tetris game that plays itself with lotsa extras // like giving you "hints" of where to put a piece! :-) Have fun!
uzun@pnet01.cts.com (Roger Uzun) (06/07/91)
[]
Actually the sprites could only accent a line ,since 8 16 color sprites
is only 64 pixel width of data. So only 1/10th of a scanline could use
the upper 15 color registers (recall for sprites that color 0 is always
transparent)
A worse problem is that the pixel width of a sprite is fixed at lo res,
so in fact you get 1/5th of a line of data, but each pixel is twice as
wide as a hires pixel. It is not too practical, because of the pixel
size differences, and the lack of enough pixels to cover more
than 1/5th of a scanline.
-Roger
UUCP: {hplabs!hp-sdd ucsd nosc}!crash!pnet01!uzun
ARPA: crash!pnet01!uzun@nosc.mil
INET: uzun@pnet01.cts.com