> Hey Kirk,
>
> > Yeah, don't know what was up w/ the maroon. Definately
>
> I forgot the stupid pound sign, just like you mentioned. :) I'm such a
> n00b.
Actually, maybe you shoulda put on your best Bugs Bunny voice
and said "Nyeahh, what a maroon!" ;-)
Actually, It's such an easy mistake to make, it should definately
go into 2600 cookbook. I just wish I could think of some good
way around it...like maybe suggesting prefacing every constant
w/ CONST_ , and then if you did a search for " CONST", the only
hits should be the defines, since all the other usages should
be "#CONST".
> code. I really thought collision/reflection and brick-removal would be more
> similar, but they are apples and oranges. Unfortunately, my clever half
> P0/half P1 ball, which is really handy for collision/reflection, is totally
> useless for brick-removal. There are 32 possible locations within an 8*4
Yeah, I didn't quite get why that was useful for collision/reflection,
actually, but was willing to take your word for it :-) I could see
why a ball made of 4 things mighta been useful though.
One random thought: would anything be any easier because you know
what directon the ball was going? if the ball was going left, then
it more likely hit a brick on the right...no, I guess not, because
it could just as easily nail a brick from up underneath, and then the
horiz.pos just wouldn't matter.
Manuel wrote:
> I solved a little simpler problem once, destroying the playfield with
> a single pixel. It seems like the key to effective code here was this
> table
>
> disintigratetab
> .byte %01111111
> .byte %10111111
> .byte %11011111
> .byte %11101111
> .byte %11110111
> .byte %11111011
> .byte %11111101
> .byte %11111110
>
> I used it to erase single blocks out. This table works as is for the
> left _and_ the right side, if you
> EOR #$07 the index for the right side.
Err, what did you use as the offset for that table?
> I also seem to have code that is testing for a brick at this location
> first and if there isn't any, I check he surrounding blocks as well.
> Not sure if this is really required, maybe my brick calculation was
> just buggy ;-)
JoustPong had a similar problem. Overall it was much simpler, 1D,
just a simple height/4 kind of thing, but when the ball was 2 scanlines
high, I found some situations where it the computer would register a
bounce but not remove a brick...turned out that was when the
2-high ball would've hit 2 bricks at once, but one was already gone...
instead of realizing it must hit the remaining brick it would round
the other way and re-remove the gone one.
Also, Lee, double simulaneous hits are definate possibilities,
(heh...at my birthday party Saturday someone karaoke'd Chef singing
'simultaneous loving'..."you...and me...and her...simultaneous")
In those cases you need to consider if you just want to remove
1 brick, or both hit bricks.
And of course you have a nice circle, so bounding rectangle code
won't work...(just brainstorming here)
Anyway, it's good that it sounds like you're not letting this
get you too intimidated. That happened to me a few times.
-Kirk
--
KirkIsrael@xxxxxxxxxxxxx http://kisrael.com
The purpose of conversation isn't to demonstrate one's glib intelligence;
it's how we stumble and grope our way through the mists and arrive at
something like intelligence. --Mr. Blue
----------------------------------------------------------------------------------------------
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
