supercat Posted January 27, 2006 Share Posted January 27, 2006 (edited) 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 January 27, 2006 by supercat 1 Quote Link to comment Share on other sites More sharing options...
Albert Posted January 27, 2006 Share Posted January 27, 2006 I'd love to see this, but I believe you forgot to attach the binary.. ..Al Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted January 27, 2006 Share Posted January 27, 2006 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 Quote Link to comment Share on other sites More sharing options...
supercat Posted January 27, 2006 Author Share Posted January 27, 2006 (edited) 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 January 27, 2006 by supercat Quote Link to comment Share on other sites More sharing options...
Zach Posted January 29, 2006 Share Posted January 29, 2006 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? Quote Link to comment Share on other sites More sharing options...
supercat Posted January 29, 2006 Author Share Posted January 29, 2006 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 Quote Link to comment Share on other sites More sharing options...
supercat Posted January 30, 2006 Author Share Posted January 30, 2006 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 Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted January 30, 2006 Share Posted January 30, 2006 Yet another version. 1009335[/snapback] The colors blend nicely! Good job! Michael Rideout Quote Link to comment Share on other sites More sharing options...
Zach Posted January 30, 2006 Share Posted January 30, 2006 This has the potential to become a great game. And yes, I prefer the 6+2 bricks too. Quote Link to comment Share on other sites More sharing options...
Zach Posted January 30, 2006 Share Posted January 30, 2006 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. Quote Link to comment Share on other sites More sharing options...
supercat Posted January 31, 2006 Author Share Posted January 31, 2006 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. Quote Link to comment Share on other sites More sharing options...
supercat Posted February 5, 2006 Author Share Posted February 5, 2006 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. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted February 5, 2006 Share Posted February 5, 2006 I don't see it in your blog Quote Link to comment Share on other sites More sharing options...
supercat Posted February 6, 2006 Author Share Posted February 6, 2006 (edited) I don't see it in your blog 1013434[/snapback] For some reason the attachment didn't get posted. Probably an oops on my end. Try it now. Edited February 6, 2006 by supercat Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted February 6, 2006 Share Posted February 6, 2006 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. Quote Link to comment Share on other sites More sharing options...
supercat Posted February 6, 2006 Author Share Posted February 6, 2006 I also tried it in Stella and enabling the phospor effect makes it look perfect. 1013500[/snapback] 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. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted February 6, 2006 Share Posted February 6, 2006 (edited) 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 February 6, 2006 by SpiceWare Quote Link to comment Share on other sites More sharing options...
overgrouth Posted September 12, 2020 Share Posted September 12, 2020 I will try this Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.