jrok

Thanks, man. Of course there will have to be a two player "versus" mode too, but I'm pretty sure I can just jam that into the banks I'm already working in. Cheers, Jarod

Here's my latest build: Finally got scanline under control with a small kernel edit and some optimization of the player control scheme. The game runs at a smooth 262 except for overflows during the death animations, which I'll have to investigate further. Replaced left and right walls with a PF0=128 vertical frame in the vblank Set a limits on laser beams to stop their progress at the left and right walls (still working on stopping vertical and diagonal beams) Created a color phase animation for the combatants while waiting for a new match to begin. Increased hittable area of both combatants Revised AI routine Expanded number and style of playfields Expanded number of unique enemies For me, the most exciting part was being able to finally get my core game routines to run at a reliable 262, since I was at the verge of giving up. I have lots of ideas where I want to take the game next, so its a big relief to know that, at the very least, I might still have a program that's functional. Next: Now that I can have scores of unique "looking" enemies, I really want to work on getting unique "acting" ones. I've left placeholders in my enemy data set that I will try to use as pointers for different weapons, and maybe even alternate AI routines. I have plenty of ROM left in my AI bank, so I just have to figure out what I want them to do differently that varies the challenge as you proceed through the game. I also would like to add in a few new player control options, which will be pretty easy since I'm already tracking the time that the player is holding down the fire button. But I could use some advice: Quick button "taps": Which do you think would be more interesting and/or useful: a quick dodge manuever or a melee attack? Overcharging the gun: Should this produce a negative effect for the player, like the weapon becoming unavailable for a short period of time? Or should it be some sort of super-attack or manuever that can be stocked up like smartbombs? Also, I've realized if I keep this a 32K game, I still have 2 completely empty banks to create completely alternate gameloops, to keep the player guessing about what's coming in the next level. For instance, instead of facing a lone gladiator with a laser beam, I want to create the following alternate round-styles: Fend off groups of alien wildlife that emerge from a pit. Battle a snakelike creature that moves like a Tron light cycle. Battle a killer robot that can teleport around the screen. It's probably biting off more than I or bB can chew, but if I can squeeze even one alternate play-style in there I think I'll be happy with this project. Cheers, Jarod Circus_Galacticus_m12_d4_y08.bin

Yes. You are resizing the wrong sprite. "NUSIZ0" resizes and/or duplicates player0. "NUSIZ1" resizes and/or duplicates player1.

Well, I just played for thirty seconds and died about a dozen times, so I think collision detection is working pretty well the way you have it now. Nice game, BTW! Jarod.

First, you forgot to set the bB kernel option to enable player1colors: set kernel_options player1colors Then, you used the wrong command to define your player1colors: The command is singular, not plural: if y=10 then player1: %00111100 %00011000 %00011100 %00111100 %00111100 %00111100 %00111000 %00011000 %00011000 %00011100 %00011100 %00011000 end player1color: $4E $40 $4E $4E $4E $4E $48 $40 $40 $48 $48 $40 end Fixed code is attached below. Cheers, Jarod. 5_AnimateASprite_02_fix.bas

Yes, there is a spot. The laser needs to intersect with the guy's playfield position. It's interesting you pointed this out, because its something that might change a lot before the game is done. Both playfield y position and collision detection in general are complicated by the fact that I am using 16px tall characters and no_blank_lines. I was actually thinking of contacting SeGTGruff about this, since he was so helpful in explaining the basics, but I want to try to figure it out for myself before I bothered him about it. Totally! I don't want to bite off more than I can chew right now, but I started reading up on the Vox a few days ago. I was thinking that if I am able to complete the game, I might look into it and see what it would entail. I've never completed a BB game period. If I'm able to finish this one it will be my first, but like a lot of guys here I dream of being able to put something on cartridge. Thanks, man! I feel like I'm pretty away from that right now. I'm still digesting the Stella Guide and SeaGTGruff's explanation of timing. It seems a little daunting sometimes. I get so close to having a well-timed program, but when I test with debugger I always seem to get a little "jump" to 263 scanlines in certain firing situations. If I'm really going to get serious about this hobby (and I think I am), I know I'll have to eventually break down and buy a Cuttle Cart so I can test this stuff for real. Cheers, Jarod.

Ah! My apologies. After reading Impaler's reply below, I think I understand your question now. Yes, that is true, batari's standard kernel uses double-height pixels to draw the player sprites. But it's possible someone have written a batari kernel mod that uses single-height pixels... you might want to search through this thread and maybe make a request. Good luck, Jarod.

I'm not quite sure I follow you. As far as I know, there is no TIA register that would "scale" a sprite's height, whether you are coding in batariBasic or pure Assembly... and there actually doesn't need to be. You can write as many lines as you want in a sprite's shape table. It could be 3 pixels high, 8 pixels high, 100 pixels high, etc. You are only limited by the amount of ROM the sprite uses. In other words, there is no such thing as "1x height" or "2x height." The height of a sprite is just the number of rows in it's shape table. For instance, the following draws a sprite that is 16 pixels tall: player0: %00000000 %00100100 %00000000 %00100100 %00100100 %00100100 %00111100 %00111100 %10111101 %00111100 %10111101 %10011001 %01011010 %01100110 %01011010 %00011000 end I'm not sure what the person who created that picture was specifically doing to achieve 4, but you can easily make sprites 2 and 3 by using the TIA registers scale a sprite's width to either 200% or 400%: NUSIZ0 = $05;(double-width player) NUSIZ0 = $07;(quad-width player) Same thing goes for all the pictures underneath 5-8. For example, image 9 isn't a scaled version of image 5, it's just that the person drew a taller sprite, than altered it's width it using a NUSIZ register. Hope that helps. Cheers, Jarod.

When you say "sprite scale", are you referring to the TIA registers NUSIZ0 and NUSIZ1? If that's the case, you might want to consider using either the missiles or the ball to create the graphic you need. For instance: NUSIZ0 = $10;(missile is 2 pixels wide) NUSIZ0 = $20;(missile is 4 pixels wide) NUSIZ0 = $30;(missile is 8 pixels wide) Or you could use the CTRLPF register to reshape the ball: CTRLPF = $11;(ball is 2 pixels wide) CTRLPF = $21;(ball is 4 pixels wide) CTRLPF = $31;(ball is 8 pixels wide) If all you want to do is scale a single pixel, it seems like a little bit of a waste to use up a whole sprite, unless that is essential to your game. What is the effect you would like to achieve? If you want to learn more about TIA registers in bB, here's a link. Cheers, Jarod.

Thank for the feedback. Absolutely agree. I was trying to figure out if there was a way to get off one last "revenge" shot when dying, but he still shouldn't be able to physically move around. I will fix that. I've noticed the same thing. The collision detection isn't fully resolved yet, that's for sure. I'm still working on some bits. Yep, that's a doozy. This is the result of returning values above 31 or less then zero for the playfield pixels when a shot goes past a wall. I'm working on it, I'm just trying to figure where in my program I would be the best place to ice off those kinds of shots. Hahahah, yeah. That would be hilarious. I definitely plan to use him during the match to f*** with you, shooting stuff at you and what not. "Blowing" you around the screen would be a nice addition to his bag of tricks. Great idea! FYI, I have attached yet *another* build, which adds color progression to the enemy sprite and playfield as you advance. It also lengthen's the range of the enemies beam in addition to making him more aggressive as you get farther in the game. I think that's gonna be my last update today, because I have to get my butt back to work. Thanks for the encouragement. Cheers, Jarod. Circus_Galacticus_m11_d25_y08_colors.bin

Will do. Thanks for the advice.

Thanks man! EDT: I think I resolved the issue with the enemy taking diagonal shots (new BIN attached). I'll have to work on the accuracy, though. Out of curiousity, does anyone own a Cuttle Cart or similar device that wouldn't mind testing this program out on it? I just wanted to find out if it's rolling the screen. If so, thanks in advance. Cheers, Jarod.

I have a new update. You can read about the build on my blog for more details if you're interested. Evil Emperor A talking hologram that announces the start of each battle. Press fire to make to shut him up and get on with the fight. Later on, I plan on making him serve an "Evil Otto" sort of function when matches take too long. Game Progression Playfields change as you advance through the game (only three so far). The enemy becomes more inclined to take a shot at you as you advance through the game. The score, playfield and enemy aggression reset to zero when you lose. Bugs/ To-do Laser beams aren't stopped at exterior walls. Enemy is having trouble shooting diagonally. Playfields are are too limited/boring, need improvement Need to change colors/powers for enemies Cheers, Jarod. EDT: - Fixed a sound bug at the completion of battles - Made the laser beams faster and more powerful - MY TOP SCORE SO FAR= 1600. Can anyone beat it??? Circus_Galacticus_m11_d24_y08_rev.bas.bin

Actually, you might want to consider avoiding "if-then" statements when setting up an animation routine. Basically, you have to remember that Atari doesn't natively have any commands that execute animation. In order to animate something, you have to build the logic fom scratch. Start by creating a variable that represents the frame of animation that should be displayed, and make it increment in your gameloop independently of anything else that you are doing. For example, if you wanted to create a game with sprites that had four-step animations: dim frame = f gameloop frame = frame + 1 if frame = 4 then frame = 0 drawscreen goto gameloop So now you have a looping variable that you can point to for your animation. The next step would be to include some subroutines that draw the player sprites. dim frame = f player0x=30 player0y=48 player1x=60 player1y=48 gameloop frame = frame + 1 if frame = 4 then frame = 0 gosub Sprite1 gosub Sprite2 drawscreen goto gameloop Sprite1 COLUP0 = $66 goto Shape1 return Sprite2 COLUP1 = $C6 goto Shape2 return Shape1 player0: %00000000 %00000000 %00000000 %00011000 %00011000 %00000000 %00000000 %00000000 %11111111 %11111111 %11100011 %11110111 %11110111 %11110111 %11110111 %11110111 %11110111 %11110111 %11110111 %11110111 %11010111 %11100111 %11111111 %11111111 end return Shape2 player1: %00000000 %00011000 %00011000 %00011000 %00011000 %00011000 %00011000 %00000000 %11111111 %11111111 %11000011 %11011111 %11011111 %11011111 %11011111 %11101111 %11110011 %11111011 %11011011 %11011011 %11011011 %11100111 %11111111 %11111111 end return Now, every time your program loops, it will draw two player sprites with unique colors and shapes. But instead of your Sprite subroutine pointing to a single shape (i.e. "goto Shape1"), we would want it to point to an animation. In that case, we would use the "on" command to track the current value of "frame" and have it point to the desired shape table. dim frame = m player0x=30 player0y=48 player1x=60 player1y=48 gameloop frame = frame + 1 if frame = 4 then frame = 0 gosub Sprite1 gosub Sprite2 drawscreen goto gameloop Sprite1 COLUP0 = $66 goto Sprite1Animation return Sprite2 COLUP1 = $C6 goto Sprite2Animation return Sprite1Animation on frame goto Shape1_1 Shape1_2 Shape1_3 Shape1_4 Sprite2Animation on frame goto Shape2_1 Shape2_2 Shape2_3 Shape2_4 Shape1_1 player0: %00000000 %00000000 %00000000 %00011000 %00011000 %00000000 %00000000 %00000000 %11111111 %11111111 %11100011 %11110111 %11110111 %11110111 %11110111 %11110111 %11110111 %11110111 %11110111 %11110111 %11010111 %11100111 %11111111 %11111111 end return Shape1_2 player0: %00000000 %00000000 %00111100 %00111100 %00111100 %00111100 %00000000 %00000000 %11111111 %11111111 %11100011 %11110111 %11110111 %11110111 %11110111 %11110111 %11110111 %11110111 %11110111 %11110111 %11010111 %11100111 %11111111 %11111111 end return Shape1_3 player0: %00000000 %01111110 %01111110 %01111110 %01111110 %01111110 %01111110 %00000000 %11111111 %11111111 %11100011 %11110111 %11110111 %11110111 %11110111 %11110111 %11110111 %11110111 %11110111 %11110111 %11010111 %11100111 %11111111 %11111111 end return Shape1_4 player0: %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 %11100011 %11110111 %11110111 %11110111 %11110111 %11110111 %11110111 %11110111 %11110111 %11110111 %11010111 %11100111 %11111111 %11111111 end return Shape2_1 player1: %00000000 %00011000 %00011000 %00011000 %00011000 %00011000 %00011000 %00000000 %11111111 %11111111 %11000011 %11011111 %11011111 %11011111 %11011111 %11101111 %11110011 %11111011 %11011011 %11011011 %11011011 %11100111 %11111111 %11111111 end return Shape2_2 player1: %00000000 %00000110 %00001100 %00011000 %00110000 %01100000 %11000000 %00000000 %11111111 %11111111 %11000011 %11011111 %11011111 %11011111 %11011111 %11101111 %11110011 %11111011 %11011011 %11011011 %11011011 %11100111 %11111111 %11111111 end return Shape2_3 player1: %00000000 %00000000 %00000000 %11111111 %11111111 %00000000 %00000000 %00000000 %11111111 %11111111 %11000011 %11011111 %11011111 %11011111 %11011111 %11101111 %11110011 %11111011 %11011011 %11011011 %11011011 %11100111 %11111111 %11111111 end return Shape2_4 player1: %00000000 %00000000 %01100000 %00110000 %00011000 %00001100 %00000110 %00000000 %11111111 %11111111 %11000011 %11011111 %11011111 %11011111 %11011111 %11101111 %11110011 %11111011 %11011011 %11011011 %11011011 %11100111 %11111111 %11111111 end return The way the above works is that, in every game loop the value of frame is incrementing from 0 to 3 and the subroutines "Sprite1" and "Sprite2" are comparing that value to the four Labels listed after the "on" command. So if the value of frame is "0", "on frame" goes to the first label after the command ("Shape_1_1" for player0 and "Shape_2_1" for player1), if its "1" it goes to the second label, if it's "2" it goes to the third label and if it's "3" it goes to the fourth label. Once you have a stable animation routine in place, you can use conditional statements to switch between multiple animations based on user inputs. Cheers, Jarod. animation.bas

Okay, I have a new version, and here's what's in it: Both the player and the enemy can be killed. When either man is shot, a brief death animation plays, then the game resets. Improved enemy AI (there's still a ways to go, but he's a little trickier now, and can detect and dodge shots every once in a while). Incorporated Michael Rideout's method for variable playercolors to palette-swap the Hero and the bad guys. Hopefully, I can use this to create a bunch of different flavors of baddie without using up a lot of space in my shape bank. Added some sound effects (these still need a LOT of work.) Now that there's actually a game here, I think my next steps will be to add some game progression to make the game tougher with each new stage. For this, I'm thinking of: Giving the badguy a number of shields/hitpoints that increments. Having the badguy's level of aggression ramp up Include two additional enemy types with different weapons/abililties. Changing the playfield layout and properties (Electrified playfield, Ricochet shots, etc) Using my two flickered sprites and the ball for obstacles or additional enemies (Gun Turrets, Hungry Beasties, Landmines, etc) The size of the game is 32K, but I'm not using most of it and might downgrade to 16k again. Bank 2 is empty. Banks 3-4-5 are filled with the 48-playfield map routine I was using for Armageddon Complex, and I doubt I'll need 48 unique playfields for this game. Bank 6 is about two-thirds full, and contains my player control schema and my enemy AI. Bank7 is is filled with my animation loops and my player1color variables, and bank8 is about halfway-filled with my shape data and my vblank. EDT: Oh did I mention bugs? There are a few: - I need to halt the progress of the beams at the edges of the screen, so neither combatant can exit - There's still a few collision detection issues with the enemy, where he can get stuck for a few loops. Usually though, he just blasts his was out of it. Cheers, Jarod Circus_Galacticus_m11_d21_y08.bin

Here's my spongebob attempt... you'd be down a flicker, though. Sbob.bas

Hey this is pretty cool! Thanks!

You mean a homebrew where you work 9 to 5, pay your bills, walk the dog, pick up steaming hot dog turds, go on a diet because you're getting too fat around the middle, and so on? Yeah! It's about time! When he said "Adult Homebrew," I thought he meant a thought-provoking exploration of the themes of art and confrontation in Proust's "Time Regained." Imagine my relief when I saw blood and sperm.

Thanks for the advice. I actually *am* using the vblank to do certain things, but I have the feeling that I am using it badly. Currently, my vblank does the following: Updates each sprite's current playfield position. Updates each sprites next playfield position based on their current directions. Reads the state of the each sprite's next playfield pixel based on the their current directions (for collision detection). It doesn't seem like a lot of cycles when i describe it like that, but it works out that way because I'm changing the value of each sprite's Y playfield position based on the sprite's current direction. It seems awful and wasteful when I look at it, but If when I track their playfield Y with a universal formula, they end up getting stuck on collisions. dim sprite1dir = a; The 8-directional vector of the sprite dim sprite1ydir = b; Vertical direction (Up or Down, including diagonals) dim sprite1xdir = c; Horizontal direction (Left or Right, including diagonals) dim sprite1lastX = d; The last x coordinate before a collision dim sprite1lastY = e; The last y coordinate before a collision dim sprite1PFX = f; The sprite's playfield X position dim sprite1PFY = h; The sprite's playfield Y position dim sprite1nextPFX = i; The next playfield X dim sprite1nextPFY = j; The next playfield Y dim sprite2dir = k dim sprite2ydir = l dim sprite2xdir = m dim sprite2lastX = n dim sprite2lastY = o dim sprite2PFX = p dim sprite2PFY = q dim sprite2nextPFX = t dim sprite2nextPFY = u const pfres = 24 ... vblank sprite1PFX = (sprite1X-14)/4 if sprite1dir = 0 then sprite1PFY = (sprite1Y-13)/4 if sprite1dir = 1 then sprite1PFY = (sprite1Y-13)/4 if sprite1dir = 2 then sprite1PFY = (sprite1Y-8)/4 if sprite1dir = 3 then sprite1PFY = (sprite1Y)/4 if sprite1dir = 4 then sprite1PFY = (sprite1Y)/4 if sprite1dir = 5 then sprite1PFY = (sprite1Y)/4 if sprite1dir = 6 then sprite1PFY = (sprite1Y-8)/4 if sprite1dir = 7 then sprite1PFY = (sprite1Y-13)/4 if sprite1xdir = 0 then sprite1nextPFX = sprite1PFX + 1 else sprite1nextPFX = sprite1PFX - 1 if sprite1ydir = 0 then sprite1nextPFY = sprite1PFY + 1 else sprite1nextPFY = sprite1PFY - 1 if pfread(sprite1nextPFX,sprite1PFY) then sprite1X = sprite1lastX : sprite1Y = sprite1lastY if pfread(sprite1PFX,sprite1nextPFY) then sprite1Y = sprite1lastY : sprite1X = sprite1lastX sprite2PFX = (sprite2X-14)/4 if sprite2dir = 0 then sprite2PFY = (sprite2Y-13)/4 if sprite2dir = 1 then sprite2PFY = (sprite2Y-13)/4 if sprite2dir = 2 then sprite2PFY = (sprite2Y-8)/4 if sprite2dir = 3 then sprite2PFY = (sprite2Y)/4 if sprite2dir = 4 then sprite2PFY = (sprite2Y)/4 if sprite2dir = 5 then sprite2PFY = (sprite2Y)/4 if sprite2dir = 6 then sprite2PFY = (sprite2Y-8)/4 if sprite2dir = 7 then sprite2PFY = (sprite2Y-13)/4 if sprite2xdir = 0 then sprite2nextPFX = sprite2PFX + 1 else sprite2nextPFX = sprite2PFX - 1 if sprite2ydir = 0 then sprite2nextPFY = sprite2PFY + 1 else sprite2nextPFY = sprite2PFY - 1 if pfread(sprite2nextPFX,sprite2PFY) then sprite2X = sprite2lastX : sprite2Y = sprite2lastY if pfread(sprite2PFX,sprite2nextPFY) then sprite2Y = sprite2lastY : sprite2X = sprite2lastX return The main idea is that a sprite's playfield position is the both origin of it's laser and the value used for collision detection. The sprite itself isn't used for anything - it's just a pretty coat. But the above looks and feels incredibly sloppy to me. I mean, I know that "sprite1xdir" and "sprite1ydir" are binary values, and should be nybbles, and there are some other ways I can pretty obviously save RAM. But what really bothers me about the above is how much division I'm doing, just for collision detection. I get the feeling I probably shouldn't be doing this stuff at all, let alone here in the vblank. Is there a simpler way to achieve what I'm going for? Thanks, Jarod.

Thanks man! There are actually four sprites on the screen, but I've repositioned the other two offscreen for now until I figure out what I want to do with them. But actually I was flickering even before I added in the sprites, since testing for both player and enemy beam and movement routines before each vsync was causing some scanline problems. Also, I wanted them to share sprite data, so this seemed a pretty straightforward way to do it. I'll have to check those out, thanks. I was a pretty big fan of the Discs of Tron arcade game, and gameplay wise I love the idea of hitting your opponent with ricochet shots. Yep! That's the one. Thanks. You know it's hard for me to think of "Doom" as anything other than a 3D game, since that was sort of its mark of fame. Unfortunately, most of those Atari "First Person Perspective" maze games usually turn out to be frustrating or boring or both for me. What might be kind of cool would be a "Battlezone" version that had the 3D feel but with simple obstacles/landmarks instead of mazes. Cheers, Jarod.

I was thinking it would be a word play on "Circus Maximus" which was the Latin name for the largest gladiator arena in Rome. My original idea was to make a sort of Combat-like game, with different selectable modes for different events. Like, Laser Duel would be one event, while another event might be some sort of futuristic chariot racing thing or an event where you have to survive waves of space monsters.

Thanks man! I guess if I went the Tron route, I might as well abandon the whole laser beam thing and go with discs. But on the other I could reuse portions the laser routine to do the lightcycle levels, so that's a pretty interesting idea. I'm almost postive I saw someone do a 2600 Doom hack of something(?), but it might've been Castle Wolfenstein. Smash TV was probably my favorite Robotron clone, and Robotron was probably my favorite arcade game, period. I have four flicker sprites available to me right now, including the player. I suppose I could beef up that number with the multisprite kernel, but I haven't tried to adapt my beam drawing routine to it yet, and I have a suspicion it won't work with a symetrical playfield. Absent that, I suppose I could use playfield pixels to represent the basic, swarming grunt-type enemies, and save the sprites for more dangerous foes. That actually might be kind of sweet. Has anyone ever done anything like that? Yeah, I definitely want to try to do the grenade thing in my next build, maybe with a shakescreen effect. I'd also like to have two different modes (1 player and 2 player), but I might not be able to pack that much game onto a 16k romboard.

I've been taking a break from Armageddon Complex to try to write something a little less, well, complex. This game is more action-oriented, with a control schema that I based on one of my favorite games, "Berzerk." The setting is a futuristic gladiator tournament, where combatants duel each other to the death for the pleasure of the galactic empire. The game will comprise the player's fighting career, with the difficulty and rewards ramping up with each match. I've attached a demo of the current engine. The blue character is controlled with the left stick. Holding down the fire button cause the character to stop, and simultaneous aim and charge up his laser gun. The longer the button is held down, the longer the laser beam he will fire when he releases the button. If the beam reaches it's maximum range or hits a portion of the playfield or the enemy character, its progress will stop and the beam will fade away. Once a beam fully disappears, the player may charge and fire a new beam. The green character is controlled by "A.I.", such as it is . It's pretty meatheaded right now, so I'll have to figure out ways to trick it into looking smarter. There's no way I can hitch anything as smart as A* into Atari, but I will try to build a very simple short term memory for the dude so he at least doesn't make the same mistakes over and over. I've lent him a few supercharger variables as placeholders to ramp up his aggression and accuracy, but at the present it's sort of like handing a blind man a machine gun. You can shoot him, but for now hits just increment your score. He can shoot you too, but for now you are godlike and invincible. I'm hoping to include a few different breeds of enemy and different arena types with traps and gadgets that you can use to help you win. Another thing I'm thinking of incorporating is a few different options for attack, based on how long you hold down the button and particular joystick movements. Short button presses & joystick movement : Perform a quick dodge or melee attack Long button presses & back/forth joystick movement : Throw a grenade There's a bug in the game that I left in on purpose, since I think it might make for an interesting grenade effect. If you fire diagonal past either horizontal edge of the arena, a shortcoming in the beam progression routine causes what looks like a massive explosion on the other side of the screen! Hooray for cool looking bugs! What do you guys think? Cheers, Jarod UPDATE: This game has changed substantially since this first-post. I've been posting progress on the Homebrew forum as well, so I will try to keep current updates consistent on both pages. Thanks to everyone in the bB forum for the all the helpful feedback and advice - Jarod. Current Version: Circus_Galacticus_m1_d30_y11.bas.bin

Thanks for all the helpful advice. This is a lot of information to "process", if you'll pardon the pun, but it is very fascinating stuff. I'm not much of hardware guy either, but much of it is actually starting to make sense! Cheers, Jarod.

...Also, bear in mind that when you are using pfread, you don't have to use static values. You could use variables. So in your case, you'd want to do something like if pfread (my_rand_x,my_rand_y) then gosub do_some_stuff ...where my_rand_x and my_rand_x are the user defined variables that are returned from your random function. So basically, you'll have to build two random functions: one to pick a number between 0 and 31 (the playfield pixel's x position) and one to pick a number between 0 and 11 (the playfield pixel's y position). Then you test those variables with the above statement whenever you want to detect a playfield pixel's state. Jarod