Jump to content
IGNORED

15-color (PER ROW!) brickbuster mini-kernel demo


supercat

Recommended Posts

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?

 

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

 

D'OH!

test.bin

Edited by supercat
  • Like 1
Link to comment
Share on other sites

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.

1007833[/snapback]

 

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

Link to comment
Share on other sites

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.

 

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! :)

1007847[/snapback]

 

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
Link to comment
Share on other sites

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?

1008872[/snapback]

 

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.

bricks.bin

Link to comment
Share on other sites

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?

1008872[/snapback]

 

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.

1008875[/snapback]

 

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.

bricks.bin

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

1009507[/snapback]

 

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

makes the countours between the gray bricks visible.

1013517[/snapback]

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
Link to comment
Share on other sites

  • 14 years later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...