RE: [stella] Generic kernal or just build a game?

Subject: RE: [stella] Generic kernal or just build a game?
From: KirkIsrael@xxxxxxxxxxxxx
Date: 29 Mar 2004 12:31:51 -0000
> 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 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, 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, 
( 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.  

 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
Unsub & more at

Current Thread