16 replies to this topic

[supercat]

Here's a proof-of-concept demo for a brick-busting game with an unusually generous number of brick colors per row (FIFTEEN!). The kernel would require self-modifying code to allow a changing brick field and thus for all practical purposes would require something like a SuperCharger or M-Network cart, but would support three bouncing balls in a one-line kernel.

The colors aren't really solid colors, but consist of two colors blended on alternate scan lines. On even scan lines, the colors are black, gray, red, and cyan; on odd scan lines they are black, gray, purple, and gold.

Presently, the bouncing balls are tracked in a bitmap with one byte for every two scan lines; each byte is Z-zYyXxq where xyz are the enables for the first scan line and XYZ are the enables for the second; q is an end-of-data flag. Data are accessed via (zp),y addressing with a constant Y value ($18 for color gold) and must not be too near the start of a page. If the data were kept in zero-page RAM it would be possible to read it via PLA instruction, but it would be necessary to have some blank scan lines between rows of bricks to reload zero-page RAM from somewhere else.

Incidentally, I wonder if this kernel--if built into a game--would set the record for the maximum number of TIA register changes per line in a practical kernel (19!)

Puzzle: Can anyone figure out where the ball is, without cheating? If one accepts that there are three different yellow graphics objects in the middle of the screen (as opposed to one sprite relocated) I think there's only one place the ball can be. Can anyone figure out any alternative approaches?

Quote

I'd love to see this, but I believe you forgot to attach the binary..

D'OH!

Attached Files

•  test.bin   4K   163 downloads

Edited by supercat, Fri Jan 27, 2006 2:12 AM.

[Albert]

I'd love to see this, but I believe you forgot to attach the binary..

..Al

[SeaGtGruff]

supercat, on Fri Jan 27, 2006 3:49 AM, said:

Here's a proof-of-concept demo for a brick-busting game with an unusually generous number of brick colors per row (FIFTEEN!).  The kernel would require self-modifying code to allow a changing brick field and thus for all practical purposes would require something like a SuperCharger or M-Network cart, but would support three bouncing balls in a one-line kernel.

The colors aren't really solid colors, but consist of two colors blended on alternate scan lines.  On even scan lines, the colors are black, gray, red, and cyan; on odd scan lines they are black, gray, purple, and gold.

You forgot the 16th color-- black! Or if you prefer, black plus 15 colors.

You could try blending the colors more by alternating the colors on frames-- odd frames having black/gray/red/cyan (even lines) and black/gray/purple/gold (odd lines), and then even frames having the odd/even line colors swapped. I'd like to see what that looks like!

Michael Rideout

[supercat]

SeaGtGruff, on Fri Jan 27, 2006 3:50 AM, said:

You forgot the 16th color-- black! Or if you prefer, black plus 15 colors.

Well, there are two identical grays so I didn't want to count them separately though having two such grays may be useful. If placed side-by-side, the contour between the bricks would be visible even though they were the same apparent color.

Quote

You could try blending the colors more by alternating the colors on frames-- odd frames having black/gray/red/cyan (even lines) and black/gray/purple/gold (odd lines), and then even frames having the odd/even line colors swapped. I'd like to see what that looks like!

I'll have to redo the kernel to use the stack if I want to do that. Probably worth doing. I'll see if I can post another version tonight or tomorrow.

BTW, reading a paddle controller is going to be an "interesting" challenge, but I think with a couple tricks it should be doable even with the absurdly CPU-intensive kernel.

Also, another thing this demo doesn't show yet is that the widths of individual bricks can be adjusted in increments of 1/3 brick provided that the minimum brick width or space between bricks is as shown. That could allow for some very interesting level designs.

I would expect that the code for 16 rows of bricks would require 2K of RAM, putting the game well within the realm of Supercharger feasibility.

Edited by supercat, Fri Jan 27, 2006 5:23 PM.

[Zach]

Nice work, John. I haven't figured out the details yet, but I've got an idea how it works. Are you using STA, STX, STY, and SAX?

[supercat]

Zach, on Sun Jan 29, 2006 1:51 AM, said:

Nice work, John. I haven't figured out the details yet, but I've got an idea how it works. Are you using STA, STX, STY, and SAX?

Naturally. Sorry I'm late in my update, but I think the result is worth it. Left difficulty controls flicker mode; if flicker mode is off (difficulty "A"), right difficulty selects "A" or "B" frame. Color/BW selects between a brick height of 6+2 or 8+2. Which brick height to people prefer? I'm leaning toward 6+2 myself.

Attached Files

•  bricks.bin   4K   126 downloads

[supercat]

supercat, on Sun Jan 29, 2006 2:11 AM, said:

Zach, on Sun Jan 29, 2006 1:51 AM, said:

Nice work, John. I haven't figured out the details yet, but I've got an idea how it works. Are you using STA, STX, STY, and SAX?

Naturally. Sorry I'm late in my update, but I think the result is worth it. Left difficulty controls flicker mode; if flicker mode is off (difficulty "A"), right difficulty selects "A" or "B" frame. Color/BW selects between a brick height of 6+2 or 8+2. Which brick height to people prefer? I'm leaning toward 6+2 myself.

Yet another version. This one doesn't support the color/bw switch anymore (locked on 6+2 height) but supports a paddle controller. The 1LK doesn't yet continue all the way to the bottom of the screen (which would be bad in the real game 'cos the ball would disappear just before hitting the paddle) but that should be easily fixable. If I spend an entire 320 bytes on the bitmap, the whole area between the lowest (16th) row of colored bricks and the second scan line above the paddle is a 32 wide by 64 bitmap with per-line color. Here I just stuck some score-ish digits in the middle, but it could be used for other things as well.

Attached Files

•  bricks.bin   4K   134 downloads

[SeaGtGruff]

supercat, on Sun Jan 29, 2006 11:54 PM, said:

Yet another version.

The colors blend nicely! Good job!

Michael Rideout

[Zach]

This has the potential to become a great game. And yes, I prefer the 6+2 bricks too.

[Zach]

supercat, on Fri Jan 27, 2006 2:49 AM, said:

Puzzle: Can anyone figure out where the ball is, without cheating?  If one accepts that there are three different yellow graphics objects in the middle of the screen (as opposed to one sprite relocated) I think there's only one place the ball can be.  Can anyone figure out any alternative approaches?

Judging by their positions, I'd guess the ball is the left yellow border, and the last two pixels of the PF make up the right one.

[supercat]

Zach, on Mon Jan 30, 2006 8:40 AM, said:

Judging by their positions, I'd guess the ball is the left yellow border, and the last two pixels of the PF make up the right one.

There are 5 color-changing border pixels, then two yellow ones, 144 brick kernel ones, two more yellow ones, and 7 changing-color ones. There aren't enough cycles to change the playfield registers during the scan line.

The yellow lines are one player (set for double-width mode). So that gives a few pixels' flexibility for where the playfieldish object has to end. Unfortunately, if I make the playfield stick out 4 pixels from the end, there will be gaps next to both yellow lines and the ball can only cover 1. And if it sticks out 8 pixels, it will overhang the left yellow line. But there is a way to make things work.

[supercat]

I've just posted a new rev over on my blog. The game is now compiled for SuperCharger, and I've got a collision-detection routine working. Collision-detection in this game is harder than it might seem, since none of the bricks "really" exist--the playfield is solid in the middle part of the screen and the bricks appear purely as a result of thousands of stores to COLUPF.

[SpiceWare]

I don't see it in your blog

[supercat]

SpiceWare, on Sun Feb 5, 2006 6:00 PM, said:

I don't see it in your blog 

For some reason the attachment didn't get posted. Probably an oops on my end. Try it now.

Edited by supercat, Sun Feb 5, 2006 7:34 PM.

[SpiceWare]

Sweet! Tried it out with my supercharger. I really like how you've done the score and the colors for the first row of colord bricks(and the Atari logo, bottom row of bricks and the short row in the middle of the grey bricks) look great.

The flicker of the greys and every other color on the 2nd colored stripe(starting with red) are pretty noticable. I suspect that's because they're alternate colors with black instead of another color. I wonder if it would look better if your background where grey instead of black?

I also tried it in Stella and enabling the phospor effect makes it look perfect.

[supercat]

SpiceWare, on Sun Feb 5, 2006 8:56 PM, said:

I also tried it in Stella and enabling the phospor effect makes it look perfect.

Well, almost. On my TV set the flicker's not too bad, and it makes the countours between the gray bricks visible. The phosphorescent mode loses that.

[SpiceWare]

supercat, on Sun Feb 5, 2006 9:10 PM, said:

makes the countours between the gray bricks visible.

Ah - didn't pick up on that - but yep, that is a noticable difference.

Have you tried with a dark grey background instead of black? I wonder if that would make the flicker less noticeable.

Edited by SpiceWare, Sun Feb 5, 2006 10:20 PM.