Cybearg

So, if the version of bB on the website is outdated, where can I find a link to the absolute latest and greatest version of bB? And what are the changes--added raw functionality or mostly improved compiling logic?

Oh, ouch. Anyway, I thought that Visual bB was just an IDE that one could update bB as required for, but apparently they're tied together in ways that they can't be separated? Maybe I should invest in bB. I mean, what does Visual bB offer above just bB? The ability to work within an environment that organizes files for you? One could just have Visual bB running for the nice visual interfaces for setting up playfields, sprites, etc., then copy it on over to normal bB, right?

Oh, yeah. That fixed it for me, too. Thanks! Also, holy crap, SeaGt! That's awesome! I've been having some issues with . It's all working pretty well except that I seriously need a way to have multiple colors in the same row on-screen at once. Do you think this would work for that? I don't know Assembly at all, so if so, how could/would it be implemented?

I meant in the context of memory. The 2600 and its cartridges have very limited space, which is why we only get 26 variables, each of which can hold a single byte. How do we also get as many 256-byte data sets as we want? Where is that information stored? It must go into some area of the RAM that isn't available for normal processes, eh?

Maybe it's just me, but this won't compile in bB. I get errors, such as a syntax error on line 35, column 37, three warnings including one for "the," (line 52, column 74) "rainbowdrawscreen," (line 27, column 7) and "asm" (line 38, column 1) and it gets an error while compiling. I have version 1.0 (build 566) of bBasic and am using the most recent version of dasm.exe that I could find, which is from 4/10/2008 or so. Also, making it go horizontally is an "exercise" in the same way that winning the Olympics is a "warm-up."

Ah, no, it's no secret. I just didn't know of a need to spam with a ton of more code, that's all. After a bit of tweaking, this worked wonderfully! I changed it to render by pfpixel's color, rather than after each individual pfpixel. Once I get a kernel that will let me update mid-scanline, though, it'll probably be closer to your code. Still, it saved me another 200 bytes or so! That brings me up to 1438 bytes (and two variables) to spare after implementing your suggestion along with some crazy crap I was doing to make things more efficient. Where is this being stored, out of curiosity?

Thanks much for this! It didn't quite work and I ended up varying a fair bit, but if you hadn't made the suggestion, I wouldn't have known to use a data group (or even what they were, really). Now if only I could simplify my big lists of pfpixel coordinates with a data set. Is that possible? Such as pfpixel [temp1]? Your suggestion cut my ROM size from about 170 bytes to 734 bytes. I'd love to do THAT again! By the way, how many data sets am I allowed? Or is it just as many as I like, so long as they don't total over 256 bytes? Thanks for all the information on the assembly and kernels, folks. I'll check it out, though I'll probably still need a lot of help writing that kernel. Still, things are getting better and better! EDIT: And after some more thinking and tweaking, I've cut things yet further, down to 1239 bytes to spare! And with an easier set-up for expansion, to boot, though that size efficiency comes at a bit of a cost of CPU speed. I idle at solid 1024 when on the title screen (which bypasses almost all the code for calculating ball location, colors, etc. until joy0fire wakes it up. When running normally, I can see the numbers going from anywhere between 300 and 1000 in rapid succession. When a ball is in play and I'm rotating the colors, it goes down to anywhere between 300-something and 700-something, sometimes hitting 1000-something here and there. This is quite the change from a few days ago, when my code only had about 100 bytes to spare but the cycles were regularly at 1300-1700. Still, the game is set up to be more easily expanded now, so all that is really needed still is that kernel stuff.

No, the "title screen" is just two playfield drawings that alternate. I'm not using bB to do anything special there, at least not in regards to your ability to create "Titlescreens." I don't even really know what those are or how they work. Besides, if I had to choose between a means of making the game itself work and cutting out a title screen, the title screen would get chucked in a second. Just like that? I can set the game size to 8k, but how would that do it? Would it just speed up operations to the point that the flicker wouldn't be noticeable anymore? Note that the blocks are not hidden by being colored black. I call pfclear at the top of the main loop and then draw either red, yellow, or blue blocks, depending the value of a variable called flicker, which is either 0, 1, or 2 (and draws a color accordingly). Okay... I don't fully understand and I have no clue what to actually write to do this, but I'm glad that there's a possible solution! Also, bB converts the .bas file to .asm before compiling it, so I could always edit the assembly file at that stage, rather than HEX-editing the finalized .bin file, although I do have a HEX editor to do so if necessary. I'm just relieved by your optimism! Any suggestions of who I could/should get into contact with for help on doing what I need to do here? Sound simple enough. What do I need to do to call ASM in bB? Do you know? Ah, that makes sense, then. I've read the first nine of his lessons so far, so I'm fleetingly familiar with how it works and what numbers are involved. So how would I do this, then?

It's a neat idea, but keep in mind that the playfield's colors must be retained during left and right rotation and the right color of ball must go to the right color of block (or, in the case of secondary colors, either of the two primary colors that make up that secondary color). I worry that the back and forth animation to make this possible with be almost as sickening to the player as the flicker itself.

I was thinking that as well--that I could compile the game, then replace what is needed with an alternate kernel. As long as I knew exactly what to replace and what to replace it with, I'm okay with a workflow that involves me doing that. That's basically what I'm doing, though it's very code-heavy (unless someone has some alternative suggestions for how to do it). The program takes the first 16 variables, a[0] through a[15], and assigns them a number. That number is the color value that will be used for each of the sixteen blocks on-screen, starting at the absolute top one and moving clockwise. The game then does a loop through all the values a[0] through a[15] and, if the color is red, it draws that pfpixel and then sets the playfield to red. If not, the pfpixel is not drawn. Then, it drawscreens and cycles through the main loop again, this time for yellow, then again for blue. So, it takes 3 full cycles of the main loop in order to color every block, and each pfpixels is black for 2/3 frames, which results in significant flicker because each of them is actually black for longer than they are a color. Also, this is a very labor/code-intensive way to determine the colors and makes adding further colors essentially out of the question because of the bulkiness of that code, plus each additional color increases the time that all the other colors are black, thus increasing the flicker. If I did the whole 8 colors that I would prefer, you'd only get a fleeting glimpse at which color is supposed to be being rendered. I don't know what "reflective" mode means, but the circle pattern should not be mirrored, if that's what you're saying. There could be a color standing alone in any location, since it's randomized. But yes, I'm doing it using pfpixels and yes, the collisions are being handled by a series of if-then statements. I'm going to go back and test the code suggestion on the previous thread page to see if it works/is more efficient, but for the time being, every main loop cycle, the location of the ball is checked against these ranges, and if it falls within a range, the color of the ball is checked against the color of the pfpixel in that location and either it's a good hit or a bad hit. I've never heard of GRP0 and GRP1. What are those? The heart is Player0. The ball is Player1. This is because missiles take on the color of the player, which is wrong. The ball needs to take on and retain the color of the central heart as soon as the trigger is hit. The color should not be varying once the ball is in play. The flicker comes from swapping between rendering the red, then yellow, then blue. Well, the color of the ball, when spawned, needs to remain the color of the heart at the moment of the ball's spawning. Maybe I can use traditional collision, but so far as I know, that just checks to see if something collides with something, but doesn't take not or has any feedback indicating WHERE it took place. The game isn't just about hitting a ball to a block--a central gameplay element is hitting the right color of ball to the right color of block. If I can't compare the color of the ball at the time of collision to the color of the specific block that it hit, it won't work. The reason I don't stagger the blocks, aside from that the symmetry more strongly implies a circular shape, is due to calculating ball trajectory. Since there are too few pixels at play for the ball to move at 1/2 or 1/4 value, I have to handle all that manually. +1 x and +0 y will cause the ball to move up. +1 x and +1 y will cause the ball to move up and to the right at about 45 degrees. +0 x and + 1 y will cause the ball to move straight right. So you can only possibly hit 8 out of the 16 blocks on the playfield. The point of the other 8 blocks is to see which colors are where and to react faster. When playing, in my opinion, it isn't nearly so evident that half the spots on-screen will never possibly be hit by the ball. As a result, I only have soft collisions for blocks at every 45 degree increment, since the ball will never hit the every 22.5 degrees. If the blocks were staggered, it would be difficult to make those numbers work to guarantee a collision path, wouldn't it? This looks very much like what I need! I'll definitely ask around to see what can be done, but if worst comes to worst, I can always wait a week or so 'til you've got more free time. I think that you're not quite understanding the way that the game works. Here, let me show a couple videos: is of the game in its current state. Towards the end of the video, I slow down the footage so that you can see what it's doing. is the game I designed about a week ago for GlobalGameJam, which this Atari game is crudely based off of. Obviously, I can't do much of what was in the original game, but I'm finding compromises where I can. It should give you a better sense of how the gameplay is supposed to work.

May do that, RT. I'd like to hold off unless absolutely necessary. I managed to fix that silly bug with the duplication between a[0] and a[15], which is a huge relief. I've gone through and optimized the code as much as I can, squeezing out a total of 183 Bytes that have not yet been used. If this kernel thing works to handle the flicker, that can be upped to about 710 bytes, as a good chunk is spent in the flicker code. I haven't looked into the kernel/etc. stuff yet, but I'm about to. If anyone has a genie-in-the-bottle solution to offer, though, I'm all ears. It was suggested that some assembly code be used to update the colors mid-scanline. Does anyone have the code for this? Can I insert assembly code into bB so that it runs those things separately? I can't read Assembly and I don't know what it means, so if it's coming to that, I'm probably going to need some strong advice/help.

Yes, I did. There are a lot of variables at play and I don't see how many of them are absolutely necessary. You have temp variables for all sound values, loops, functions, etc. all over, but is that necessary? What is the absolute minimum code necessary to make a sound work? Because I've only got about 200 bytes and maybe 1 variable to spare.

Alright, got that collision detection issue all sorted out. As I figured, I put in the wrong numbers, forgetting that sprites center to their coordinates. . There's a bug where block #15 and block #0 always share the same colors. #0 starts at the very top and the numbers go clockwise, so #15 is the one just to the left of it. I'm sure that I made a dumb mistake when writing the rotation routine, but every time I stare at the code for it and try to visualize the problem, my brain goes numb. If anyone is willing to point out the glaringly obvious oversight, it would be appreciated. I'm sure that I just have to store one of the variables to be placed later or something like that. rem move all block values to the right 435 for temp1 = 0 to 15 temp2 = temp1 + 1 if temp2 = 16 then temp2 = 0 a[temp1] = a[temp2] next offset = 50 goto 500 rem move all blocks to the left 445 for temp1 = 15 to 0 step -1 temp2 = temp1 - 1 if temp2 = 255 then temp2 = 15 a[temp1] = a[temp2] next offset = 50 450 Other than that, it mostly just comes down to flicker issues. If I can get the flicker issues fixed through everyone's suggestions and things look to be working well, I'll probably expand this to an 8k ROM and add some further functionality. Again, if someone can explain how sounds work, that would be a great boon as well.

Unfortunately, I do not have an iOS device, but I'll definitely go over that code, thanks! Too bad I don't know anything about Assembly, so I'll probably end up needing assistance. In the meanwhile, I kept hammering away at the game and I think it's basically done, aside from two things: 1. The flicker problem 2. Collision detection issues The collision detection code can be seen below: rem collision detection 700 if a[0] = 0 then goto 701 if player1x > 80 && player1x < 85 && player1y >8 && player1y <17 && ballcolor = a[0] then a[0] = 0: goto good_hit if player1x > 80 && player1x < 85 && player1y >8 && player1y <17 && ballcolor <> a[0] then goto bad_hit 701 if a[2] = 0 then goto 702 if player1x > 113 && player1x < 118 && player1y >16 && player1y <25 && ballcolor = a[2] then a[2] = 0: goto good_hit if player1x > 113 && player1x < 118 && player1y >16 && player1y <25 && ballcolor <> a[2] then goto bad_hit 702 if a[4] = 0 then goto 703 if player1x > 129 && player1x < 134 && player1y >48 && player1y <57 && ballcolor = a[4] then a[4] = 0: goto good_hit if player1x > 129 && player1x < 134 && player1y >48 && player1y <57 && ballcolor <> a[4] then goto bad_hit 703 if a[6] = 0 then goto 704 if player1x > 113 && player1x < 118 && player1y >80 && player1y <89 && ballcolor = a[6] then a[6] = 0: goto good_hit if player1x > 113 && player1x < 118 && player1y >80 && player1y <89 && ballcolor <> a[6] then goto bad_hit 704 if a[8] = 0 then goto 705 if player1x > 81 && player1x < 86 && player1y >88 && player1y <97 && ballcolor = a[8] then a[8] = 0: goto good_hit if player1x > 81 && player1x < 86 && player1y >88 && player1y <97 && ballcolor <> a[8] then goto bad_hit 705 if a[10] = 0 then goto 706 if player1x > 49 && player1x < 54 && player1y >80 && player1y <89 && ballcolor = a[10] then a[10] = 0: goto good_hit if player1x > 49 && player1x < 54 && player1y >80 && player1y <89 && ballcolor <> a[10] then goto bad_hit 706 if a[12] = 0 then goto 707 if player1x > 33 && player1x < 38 && player1y >48 && player1y <57 && ballcolor = a[12] then a[12] = 0: goto good_hit if player1x > 33 && player1x < 38 && player1y >48 && player1y <57 && ballcolor <> a[12] then goto bad_hit 707 if a[14] = 0 then goto 708 if player1x > 49 && player1x < 54 && player1y >16 && player1y <25 && ballcolor = a[14] then a[14] = 0: goto good_hit if player1x > 49 && player1x < 54 && player1y >16 && player1y <25 && ballcolor <> a[14] then goto bad_hit 708 if player1x = 0 || player1y = 0 then goto 750 if player1x=156 || player1y = 140 then goto 750 I mapped out the top-left pixel location of all the pfpixels in the playfield seen below: playfield: ............X...X...X........... ........X...............X....... ................................ ......X...................X..... ................................ .....X..........X..........X.... ................................ ......X...................X..... ................................ ........X...............X....... ............X...X...X........... end From there, I added a range of 4 width and 8 height to accommodate the full "hit box" of the pfpixel. For some reason, though, only #703 and #707 (the bottom-right corner and top-left corner) work correctly. All the other hitboxes register no detection and the "ball" passes straight through. I would say that it's a problem with the ranges I set, but I used the same sort of range values for all other pfpixels as those two. In all cases, the minimum ranges are derived from the top-left pixel in the pfpixel (determined by checking through spawning player1, with a sprite shaped like a pfpixel, at the location), though now that I say that, I may have an idea as to what is wrong -- I'm probably forgetting that player sprites are spawned in the center of their location, so all my values are incorrectly offset. Oh, well, I'll get 'em fixed! Somewhat worryingly, I'm down to just 263 bytes left, though it's probable that there is room for optimization and the core of everything is there already. If there is a way for me to resolve this flicker problem as Omega and others have suggested, I may have to upgrade the game to an 8k rom file, because what you see is really a very simplified version of a game that I designed for GameJam. I'd like there to be room to add secondary colors (orange, for instance, can be 'killed' by a red ball or a yellow ball) and white (which can be killed by any ball, but takes to hits to do so) and black (which will hurt if it is hit, so the player will have to take note of the "blank space" relative to the other colors and make sure not to hit it) with levels that progress at more than an entirely random degree (a bit of planned progression to introduce the new blocks as they come, though still governed by randomness). Also, is there a good, simple tutorial for what is necessary to add sounds? Music is out of the question, both because I am no composer and due to the size limit, but I'd at least like to have audio feedback for a good hit and a bad hit. The demos I've seen seem a bit complicated and don't make it clear how much of all the code is necessary for getting a sound to play. I'll probably also get someone to playtest to give me some feedback on the controls--whether the balls move too quickly to respond and whether the controls on the block rotation are too fast or too slow. So, thanks to everyone for the great feedback and help! Any more resources that can teach me more about how to get this flicker problem to go away, or anyone willing to write a kernel that I can just plug 'n play while still programming in bB, that'd be great!

Thanks for the info, Spice. I read your presentation as well as about half of the assembly course, though I don't feel much closer to actually being able to do things differently, though it is interesting stuff that makes the meanings of things a bit clearer. Okay, so we've established that the playfield either has to be a solid color or a solid horizontal line. Now, is there any way to put multiple colors in the background without being limited to a single color per line? There seems to be different colors per line in Pitfall, there. If I could color in specific colors to certain regions of the screen, I could use a mostly-black playfield as a mask to cover up the rest of the background so that the colors only would show through where I wanted them to. If not that, and not any way to do the playfield differently, is there maybe a way of interlacing the image to that each pfpixel is made up of half as many lines, but those lines, each of the appropriate color, could be swapped between fast enough to made the flicker negligible? Even if it results in a less-solid image, that'd be preferable to one that flickers. If not any of that, is there ANY solution whatsoever, or is it entirely impossible to have multiple colors on screen like I'm trying to do?

Well, I've been told that the more advanced stuff, like this, isn't really possible with batariBasic but may be possible with Assembly, although I don't know Assembly. I'll try going through Andrew Davie's course and hopefully that will put me a bit further along. Meanwhile, of what the code does so far. I could try the pflines thing if I space out the blocks differently, but then they certainly wouldn't be circular and it may be very limiting. Could this be done if I use multisprite, giving each different colors, and moved them around the field instead of pfpixels?

Well, I was kind of hesitant to post the full code of what I was working on, but this has so many problems, unless folks have some novel fixes that I wouldn't have considered, it won't be going much further, anyway. [redacted] Sorry for the mess in the code. You can see the basics in place. There are multiple colored squares that are rotated by left/right joystick movements. In the center is a pulsing heart sprite that serves as a life bar as well as an indicator for "ball" color. When the trigger is pressed, a ball of the same color as the heart at the moment of the trigger is created and sent off in a random direction. The object of the game would be to match the color of the ball to the color of the block it hits, scoring points. The wrong ball to the wrong block loses a life. There are lots of things wrong with the build at the moment. The most glaring is the awful flickering. Second, I can't seem to work out how to get the ball to shoot out in one of 8 set directions at random (every 45 degrees) without being too fast to react to. Third, I have no idea how to perform by-box collision that will allow the hit box's color to be compared to that of the ball to determine whether the hit is good or not. There's also a weird glitch in the first and last box values (the very top and the one just to the left of the top), causing those two to always share the same color for some reason. And this is just a very simplified version of the game I intended to do. Ideally, the boxes would rotate fluidly, not just swap between a number of pre-determined spots and there would be more possible colors/effects on the boxes, but alas. I'm rather exhausted with the attempt unless someone can suggest novel ways of dealing with the aforementioned problems that I just didn't think of.

I very much appreciate the help on the variables and such. Thanks! Now, there's one major remaining hurdle: I need either multiple colored sprites or multiple colored pfpixels or something else on-screen at once. I've tried going through loops like so: dim temp = a for temp1 = 0 to 15 temp2 = rand if temp2 < 41 then a[temp1] = 64 if temp2 > 40 then a[temp1] = 28 if temp2 > 80 then a[temp1] = 148 if temp2 > 120 then a[temp1] = 46 if temp2 > 160 then a[temp1] = 214 if temp2 > 200 then a[temp1] = 100 if temp2 > 240 then a[temp1] = 14 if temp2 > 247 then a[temp1] = 0 next rem didn't use a for-loop because it just wouldn't work right 100 temp = 0 125 if temp < 16 goto 150 else goto 175 rem starting at the top, going clockwise, define each pfpixel 150 if temp = 0 then pfclear: pfpixel 16 0: COLUPF = a[temp]: drawscreen if temp = 1 then pfclear: pfpixel 20 0: COLUPF = a[temp]: drawscreen if temp = 2 then pfclear: pfpixel 24 1: COLUPF = a[temp]: drawscreen if temp = 3 then pfclear: pfpixel 27 3: COLUPF = a[temp]: drawscreen if temp = 4 then pfclear: pfpixel 28 5: COLUPF = a[temp]: drawscreen if temp = 5 then pfclear: pfpixel 27 7: COLUPF = a[temp]: drawscreen if temp = 6 then pfclear: pfpixel 24 9: COLUPF = a[temp]: drawscreen if temp = 7 then pfclear: pfpixel 20 10: COLUPF = a[temp]: drawscreen if temp = 8 then pfclear: pfpixel 16 10: COLUPF = a[temp]: drawscreen if temp = 9 then pfclear: pfpixel 12 10: COLUPF = a[temp]: drawscreen if temp = 10 then pfclear: pfpixel 8 9: COLUPF = a[temp]: drawscreen if temp = 11 then pfclear: pfpixel 5 7: COLUPF = a[temp]: drawscreen if temp = 12 then pfclear: pfpixel 4 5: COLUPF = a[temp]: drawscreen if temp = 13 then pfclear: pfpixel 5 3: COLUPF = a[temp]: drawscreen if temp = 14 then pfclear: pfpixel 8 1: COLUPF = a[temp]: drawscreen if temp = 15 then pfclear: pfpixel 12 0: COLUPF = a[temp]: drawscreen temp = temp + 1 goto 125 175 The problem is that, with the pfpixels arranged in a circle on the playfield, it just creates a very noticeable loop of the colors spinning around, since it's not fast enough to draw them without being noticed. Is there any way to have multiple (in this case, 16) objects of different colors on-screen at once without it being a flickering mess?

Thanks much for the response! I don't know much about the kernels and such. From what I've just read, they seem to take an awful lot of space. Not sure if that's worth it for bitmaps and the like. My biggest problem is getting loops, functions, and variables to work correctly, so that's my primary concern. For instance, I know that bit operations work almost like arrays, with a{0} being a binary variable, a{1} being another, on up to a{7}. However, can I somehow reference them using a variable as an index, such as the following: for temp = 0 to 7 bitop{temp} = 1 next Which, in theory, should count up through the 8 bits and set each of them to 1, but it returns an error instead. Secondary is any better way of rendering a series of boxes on-screen with minimal flicker. I know that there may be some answer in this, though I admit that I don't understand the concept there. The idea I have is fairly simple, I think. The complication is in making those updates without a flickering mess.

Prelude: Hello to all! I've recently had an epiphany of how wonderful game design can be, so I'm doing a little exercise to try to build my programming and artistic skills. Specifically, I'm starting with the Atari 2600 and then trying to work my way up with some other older consoles before settling again on modern engines. It seems like a good, fun exercise in rapid game development, since Atari 2600 games are relatively small. Keep in mind that I'm a novice programmer and this is meant to be a learning exercise to get me used to "thinking like a programmer." Problems: I sat down last night to crank out a simplified version of a game that I recently designed for GameJam and it's been going fairly well so far, thanks to visual bB and the manual that came with bataribasic. However, there are a number of problems and questions I have, so I hope that you good folks with all the knowledge can help me out: 1. First of all, I know that there are serious limitations on what can be done, but why are they THIS limiting? Maximum of two sprites? Any more requires significant slow-down and flicker as you teleport them from place to place? What about, for instance, (which is very similar to the game I'm trying to make)? You've got a ball that does not share the same color as the playfield (and, for that matter, a playfield that is not one solid color) and a series of "blocks" that I assume are sprites, yet there is no noticeable flicker. Or, for another example, Pitfall, which not only seems to have multiple different sprites on screen, but also sprites with multiple colors (the man) and a playfield consisting of much greater pixel quantity/density than is available to me in Visual bB. What gives? 2. It seems like most loops and functions don't really work. For instance, I wrote this: rem randomize color values 10 for temp = 0 to 15 step 1 temptwo=colorfun(f) goto storecolors next function colorfun if rand < 81 then return 1 if rand > 80 && rand < 161 then return 2 if rand > 160 && rand < 251 then return 3 if rand > 251 then return 4 rem get and assign numbers for variables - red, yellow, blue, white end storecolors if temp = 0 then one = temptwo if temp = 1 then two = temptwo if temp = 2 then three = temptwo if temp = 3 then four = temptwo if temp = 4 then five = temptwo if temp = 5 then six = temptwo if temp = 6 then seven = temptwo if temp = 7 then eight = temptwo if temp = 8 then nine = temptwo if temp = 9 then ten = temptwo if temp = 10 then eleven = temptwo if temp = 11 then twelve = temptwo if temp = 12 then thirteen = temptwo if temp = 13 then fourteen = temptwo if temp = 14 then fifteen = temptwo if temp = 15 then sixteen = temptwo return The intention is for-loop to count from 0 to 15, each time calling the function colorfun[ction] to generate one of four numbers (which will be used to determine the colors of things later on) and saving the value in a temporary variable, then sending it into an appropriate holding variable for later. The problem is, when I don't get a ROM out of space error on this (even though I have ~ 1.2K of ROM left), the screen is simply black, like the program is having trouble crunching the numbers in this fairly simple set-up. It's like batariBASIC can't handle nested functions/loops. Is there some way to get this kind of stuff working? The required workarounds--that is, using goto commands, is very wasteful of preciously scarce programming space. 3. Is there some way to name variables in ways that I can access easily through loops? Taking the above example, I have sixteen variables that hold a number from 1 to 4 denoting the color to be assigned to sixteen pfpixels (I would use sprites, but in my experience so far, the processing requirements to have sixteen sprites on screen at once makes the game such a flickering mess, it's unplayable), with an additional two variables used as bit operations to determine whether a given block should be "on" or "off" (that is, whether it's alive or has been destroyed). I would LOVE to be able to somehow count through the variables with a loop without specifying specifically, one by one, what to do, as if it were an array along the lines of: array[temp] = temptwo That would be so much simpler and more efficient. On a similar note, I wish I could do: for temp = 0 to 7 step 1 bit_op{temp} = 1 next ... Or something along those lines. That is, use variables to denote other variable names so I can quickly and efficiently count through them and determine/set a number of variables without wasting the space with dozens of if-then statements for every possible iteration. This is especially important for later on, since, after I've established which pfpixels get which colors and whether they are on or off, I'll need to program in collision (or some semblance thereof) so that getting hit by a ball (or missile) kills a pfpixel (a la Breakout). That would be difficult enough, BUT it gets harder: Basic Game Explanation: The pfpixels need to rotate their values, since the primary gameplay mechanic is the player moving the blocks to meet the ball, rather than the other way around. I'll need for loops to store the current and next color value of the blocks, swap the new value in while preserving the old, check to see whether that block is on or off, affect the collision appropriately, etc. Maybe that explanation is confusing, so I'll try to represent it visually. The one-sixteen variables hold a color value from 1 to 4, which will possibly end up being 1 to 7, if I have my way. This is important, because only balls of a certain color can cake out blocks of a certain color, so there will need to be if-then statements comparing the stored value of the color of the ball with the stored value of the color of the brick to see if they are a match or not, then flip the appropriate bit operator. This can be represented with sixteen bit operations (between two variables) and sixteen actual variables (though it could possibly be done with bit operations, though it would be complicated): 1 1 0 1 1 1 1 1 1 0 1 0 1 1 1 1 0 - Bit Operation (on/off = alive/dead) 1 2 3 2 4 3 1 3 4 1 2 3 4 1 3 4 3 - Variables (number = color) ---------------------------------------> - Direction that the values must be shifted for each joystick right <--------------------------------------- - Direction that the values must be shifted for each joystick left Meanwhile, balls of three colors are being created on a loop, rather than randomly: pulse = pulse +1 if pulse = 15 then color = color + 1:pulse = 0:beat = 0 if color = 3 then color = 0 if color = 0 then COLUPF=64 if color = 1 then COLUPF=28 if color = 2 then COLUPF=146 Which, when joystick trigger is hit, creates a ball with a color value based on the color variable and stores it for that ball so that it doesn't change. When collision happens between a pfpixel and a ball (perhaps manually determined by a range of values that denote the pfpixel's location?), the ball's stored color value is checked in an if-then statement against the values in the brick being collided with: if ballcolor = [variable containing block color value] then [set block bit operation to 0 to "kill" it and give the player points] if [variable containing block color value] = 4 then [set block bit operation to 0 to "kill" it and give the player points, since these blocks can be killed regardless of the color of the ball hitting them] else life = life - 1: goto [somewhere] If need be, I could try using six variables as bit operations (instead of sixteen) to denote red, yellow, and blue colors and a function to generate the color number when needed , for instance: for count = 0 to 7 step 1 if red{count} = 1 && yellow{count} = 1 && blue{count} = 1 then color = 4 if red{count} = 1 && yellow{count} = 0 && blue{count} = 0 then color = 1 if red{count} = 0 && yellow{count} = 1 && blue{count} = 0 then color = 2 if red{count} = 0 && yellow{count} = 0 && blue{count} = 1 then color = 3 Though I'd need two versions of it, since there are two bit operation groups at play, since there are sixteen blocks, so I'd have to run it again for the second half. This would be nice because it's scaleable if I want to expand the number of possible colors: if red{count} = 1 && yellow{count} = 1 && blue{count} = 0 then color = 5 if red{count} = 0 && yellow{count} = 1 && blue{count} = 1 then color = 6 if red{count} = 1 && yellow{count} = 0 && blue{count} = 1 then color = 7 As is probably apparent, I haven't gotten to these latter parts yet due to the difficulties I'm having getting loops and functions to work correctly. So, after all that, if anyone can offer me some advice as to what's going wrong or how I can make my dreams come true in an efficient way, it would be very much appreciated! TL;DR: Help me!