A82: More ideas on SpriteClip
[Prev][Next][Index][Thread]
A82: More ideas on SpriteClip
Response to ----------: (Eric Piel)
> Including this routines in CrASH is a great idea. But how would
> it fit in the
> 1000 bytes of CrASH?
> (Did you notice : I reply on the 26 to a message written on the 27!)
Well, the size of CrASH is not stationary at 1000 bytes, for your
information. It didn't even used to be there! The current version is
running at about 1678 bytes (i don't think I'm going to be using all that
space yet though)
Anywho, the point is, of course I'm planning to resize CrASH... Otherwise
nothing will fit- you know, I have that new relocation going on...
Oh, the reason the date was set to the 27th was to evade the CIH virus...
(you know, to skip over April 26th...)
Well, my computer still thinks it's the 28th today... Soon it'll think it's
the 27th again though :P
Response to ----------: (Sam Heald)
> Masking the way Jimmy Mardell's SQRXZ routine does it or the 5-6
> other masking routines. First sprite is a standard sprite, the
> following is a bit mask. Anything not a one in the mask, XOR's onto
> the screen.
>
> Sprite:
> .db %00111100
> .db %01000010
> .db %10100101
> .db %10011001
> .db %10100101
> .db %01000010
> .db %00111100
> .db 0
>
> .db %00111100
> .db %01111110
> .db %11111111
> .db %11111111
> .db %11111111
> .db %01111110
> .db %00111100
> .db 0
Hmm well, the way SprClpANDXOR works is it has the AND-Bitmask (different
order than Jimmy Mardell's) and then the XOR-Bitmask... This way is faster
by a lot and that would require a lot of recoding, too. I think the AND/XOR
way is easier to understand too... (the and mask is a bit-wise compliment
of mardell's bitmask)
I guess I can try to make it, but it's somewhat slower...
The same sprite from above would be:
Sprite:
.db %11000011 ; 1 is where the background
.db %10000001 ; is to be left the same
.db %00000000
.db %00000000
.db %00000000
.db %10000001
.db %11000011
.db %11111111
.db %00111100 ; 1 on top of a corresponding
.db %01000010 ; 0 from above is black,
.db %10100101 ; 0 on top of a corresponding
.db %10011001 ; 0 from above is white,
.db %10100101 ; 1 on top of a corresponding
.db %01000010 ; 1 from above is inverted,
.db %00111100 ; and 0 on top of a corresponding
.db %00000000 ; 1 from above is transparent.
Response to ----------: (Kouri)
> Well, I think that it would be useful to have an included sprite
> routine in CrASH, but there are so many different routines out
> there that have different features. A programmer usually just
> picks the one that serves his/her purposes best. Creating a good
> general purpose sprite routine is a hard thing to do. Some people
> only need a raw 8 by 8 spriteput routine. Others may need an 8 by
> x, x by 8, or x by x routine. Some may need clipping or masking
> too. What would be useful is a standard graphics library, but I'm
> not sure we could all agree on that.
Maybe we can all agree on one routine that can be included. We might as
well say the XOR only 8 by X routine; size modifiable through a call...
Making libaries is pointless too, because if programs require different
libraries, then it's a waste of space. The best way is to use commonly used
functions (like CR_GRBCopy and RAND, and possibly CR_SprClpXOR) inside of
CrASH itself.
Final deductions-----------------------------------
The following subroutines have not been yet finalized, but they may be added
to CrASH2 whenever I decide to release it.
Possible new add-ons to the CrASH routine lineup:
CR_SprXOR (non-clipping sprite XOR routine) (B,C) coordinates,
HL -> sprite
CR_SprClpXOR (clipping sprite XOR routine) (B,C) coordinates,
HL -> sprite
CR_SprHtChg (sprite height changer) A = height
Anyone have any opinions? Please join the discussion!
Does anyone have some new CrASH call routines that you would want to see
added to CrASH2?
-crashman
PS - Oh, quick news; PutSprClp v3 XOR-only version is due out soon
(again)... all I need to do is type it up
References: