[comp.sys.amiga.programmer] Better Dynamic HiRes Mode?

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

mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (06/07/91)

In article <1991Jun6.175602.13295@crash.cts.com> uzun@pnet01.cts.com (Roger Uzun) writes:
>[]
>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

It's possible to get more than 8 sprites on a line using the copper and/or
CPU to assist.  Check out manual mode for sprites in the ALL-IMPORTANT
hardware manual :)

--
****************************************************
* I want games that look like Shadow of the Beast  *
* but play like Leisure Suit Larry.                *
****************************************************

uzun@pnet01.cts.com (Roger Uzun) (06/08/91)

[]
>>Mike Schwartz says:
>> It's possible to get more than 8 sprites on a line using the copper
>> and/or CPU to assist.

Hmmm I do not think this is so, if it is, it is news to me and my old
hardware RKM.  You can reuse sprites, allowing many on the screen at once,
more than 8 inb any case, but only a max of 8 on a single scan line.

At least I think that is all you can get, can anyone prove me wrong,
My hardware manual says you can only reuse a sprite after a line of
waiting between uses.

-Roger

UUCP: {hplabs!hp-sdd ucsd nosc}!crash!pnet01!uzun
ARPA: crash!pnet01!uzun@nosc.mil
INET: uzun@pnet01.cts.com

mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (06/09/91)

In article <1991Jun8.075605.1420@crash.cts.com> uzun@pnet01.cts.com (Roger Uzun) writes:
>[]
>>>Mike Schwartz says:
>>> It's possible to get more than 8 sprites on a line using the copper
>>> and/or CPU to assist.
>
>Hmmm I do not think this is so, if it is, it is news to me and my old
>hardware RKM.  You can reuse sprites, allowing many on the screen at once,
>more than 8 inb any case, but only a max of 8 on a single scan line.
>
>At least I think that is all you can get, can anyone prove me wrong,
>My hardware manual says you can only reuse a sprite after a line of
>waiting between uses.
>
>-Roger
>
>UUCP: {hplabs!hp-sdd ucsd nosc}!crash!pnet01!uzun
>ARPA: crash!pnet01!uzun@nosc.mil
>INET: uzun@pnet01.cts.com

A number of European and American video games use more than 8 sprites on a line
to display the score at the top of the screen.  It does work.

--
****************************************************
* I want games that look like Shadow of the Beast  *
* but play like Leisure Suit Larry.                *
****************************************************