Re: A82: 6 by x sprite routines

[Prev][Next][Index][Thread]

Re: A82: 6 by x sprite routines


That's possible, but again, you're better off using 8bit mode. 16x16
sprites can be drawn quite efficiently (taking less time than say running
an 8x8 routine 4 times), whether whole or as halves. As for memory, you
are, in effect, losing 4bits per line of the 12x12 sprite. Of course, you
can still use those bits, but it becomes quite awkward.
There's no reason why you can't use sprites with widths which are
multiples of six (or any other +ve integer), but unless you've got an
exceptional reason, it's probably not worth it. (Getting more "mileage"
out of a row by using more "thinner" bitmaps is probably reasonable in
some circumstances, I guess.)

-Jeremy

On Mon, 2 Aug 1999 Jkhum98@aol.com wrote:

> 
> Could another Implementation be to more easily put a 12x12 tile TileMap to 
> the screen, so then you can work in halves of tiles, and they be aligned, 
> rather than some of those 12x12 sprites in a normal 8x8 system be 
> Non-Aligned? Just wondering...
> 
> Jason_K
> 
> In a message dated 8/2/99 10:17:15 PM Central Daylight Time, 
> j.wazny@ugrad.unimelb.edu.au writes:
> 
> > I don't think it's all that useful since you still have to write a whole
> >  byte to the port (obviously), so you're losing 2bits of potential
> >  information. The other thing is that you'd have to write directly to the
> >  data port, instead of using some bitplane in addressable ram (eg.
> >  GRAPH_MEM), which tends to get awkward if you want to be able to easily
> >  manipulate it later on, or if you don't plan on displaying the data
> >  strictly in the order that you receive it; ie. direct cursor manipulation
> >  is messy, especially things like "backspacing" it after a write when
> >  you've got so few registers for quick temp. storage. The alternative, to
> >  write a CR_GRBCopy-esque function for the 6bit mode is terribly wasteful
> >  when you consider you'd need 1024 bytes as opposed to 768 bytes in the 8
> >  bit case. Even if you "compacted" all those 6bit chunks into fewer 8bit
> >  bytes, you'd still be faced with the problem of shifting them back into
> >  position before the port write. 
> >  On the other hand of course, if for some reason, you needed to align 6bit
> >  wide bitmaps so that they lie directly side-by-side (text, perhaps?), it
> >  could be at least an "interesting" alternative to boring old shifting.
> >  
> >  -Jeremy
> >  ... and to answer your question: I don't know.
> >  
> >  
> >  On Mon, 2 Aug 1999, Kouri wrote:
> >  
> >  > 
> >  > If anyone has read the newest version of 82-PORTS.TXT, Dines says 
> > something about changing the display controller mode so that you can use 16 
> > columns of 6 pixel-wide "bytes" instead of 12 columns of 8 pixel-wide 
> "bytes."
> >  I was just wondering if anyone has actually made a routine that utilizes 
> > this new information. Anyone?
> >  > 
> >  > 
> >  > HotBot - Search smarter.
> >  > http://www.hotbot.com
> >  > 
>
References: