A86: Re: Re: 102 and 95 findpixel. Last message.. honest!

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

A86: Re: Re: 102 and 95 findpixel. Last message.. honest!

With reluctance, I am attaching the routines that I wrote.  I didn't want to
release them quite yet, but I guess I might as well.  I was saving them for
a tutorial on 86 Central, though it might not get done for a while since I'm
very busy now.  I will note that there is one bug that I know of.  Clipping
that occurs on the lower-left hand corner will cause stray pixels to appear
on the byte following the last row.  If you are drawing to video ram (which
will wrap to rom) or to a buffer and allocate an extra 16 bytes on the end,
then it won't matter.  With grayscale, things drawn to the first plane will
wrap to the upper-left corner on the second plane (assuming they are
sequential).

These routines, while not the best, are pretty good I think, at least for my
first attempt at a putsprite.  They are actually four routines in one, for a
total of 250 bytes:

 PutSprite
PutSpriteClip
GraySprite
GraySpriteClip

All four routines are masked and do only 8x8 sprites (though this could be
changed with a little work).  They do not support background saving...I
always use a tripple buffer, and again, these are my first putsprite
routines.  Unfortunately, due to the way I handled clipping of left/right,
clipping must be for the full screen.

I haven't counted cycles, but when I switched these routines in my original
space invaders game (which was really slow), it sped it up by a good five to
ten times, though I think the sprite routines may be about 2 times faster
than the ASCR routines.  (Mardell, I know you're on the list, if I'm wrong,
let me know why :)

These use extensive self modifying code for stuff, I know they're very hard
to understand, I didn't write them for understand, but to be small and fast
and usable.  They work for me, you might find them useful, and I'll fix the
bug sometime.  There's also a few other optimizations that can be done to
save a few bytes and cycles, but not much with this design.  If anyone sees
anything wrong or improvements, please tell me.  Read the comments to find
out how to use it.  Should be pretty much compatible with the ASCR
PutSprite.

Everyone can expect some awsome sprite and other game code sometime in the
future.  Dux has been talking to me all evening about this super fast sprite
routine he's writing, and it's incredibly cool.  We also think we found a
way to do grayscale side scrolling that is very fast and eliminates sprite
clipping, but you'll hear about that in the future...


----- Original Message -----
From: <HonorIam2@aol.com>
To: <assembly-86@lists.ticalc.org>
Sent: Wednesday, February 17, 1999 4:18 PM
Subject: A86: Re: 102 and 95 findpixel. Last message.. honest!


>Okay, I've found one more thing about these routines, I'm sorry for posting
so
>early with my results.  The first two hex digits for the table address in
both
>routines can be one of 4 values.  07h, 47h, 87h, and c7h.  This puts the
most
>valid location at 8700h which is free ram on page 1.  I've updated these
>routines as much as I can.  As far as I can tell, unless someone can
optimize
>the bit rotations in the first few lines of the coding, there is no way to
>make this faster than 95 ( 91 with input scrapped.)
>
>If somebody has a chance, I'd appreciate (and so would a lot of other
people)
>making a really fast and optimized masked putsprite routine.  I think this
>would be a neat challenge for everybody who likes game programming.
Besides,
>findpixel isn't used for much stuff anyway.  Sprites and raycasting is
where
>most of the cool stuff happens.  Good Luck.
>~Code7~
>
>ZAPO
>

sprite.asm