CurtisP

I put a PAUSE at the end of the batch file, then right-click the batch file in explorer, choose the properties tab, and select "Close Window on Exit". This creates a shortcut which I use to do the compile.

Would it also be possible to do a similar thing with multicolored sprites? Here's another thing I wish could be possible in a new kernel. It has to do with the score. Would it be possible for the score to only show the digits used so far? If the score is 10, only 10 would be shown instead of 000010. If the score is 8,000, only 8,000 would be shown instead of 008000. And added to that, could a comma be added once the score hits the thousands? For example, instead of 100742 we would see 100,742. The way six players on a line is done is by setting NUSIZ0 and NUSIZ1 so that you have three copies of each player, with either wide or close spacing, then setting the X positions so that each copy of Player 1 closely follows Player 2, so you have either 1 2 1 2 1 2 or 121212 Then, during each line, three different values are written into GRP0 and GRP1 each. Thus resulting in the appearance of six different players. Unfortunately, the limited number of cycles available during each scanline, means that the there isn't enough time to set each of the six "virtual" players their own color. The best that can be done is to give the copies of Player 1 one color and Player 2 another color. Now it should be possible to change these colors every scan line, but this would mean that three of the virtual players would share the same multicolors. I was going to allocate 12 memory locations for player colors so you that the odds and evens could have different colors for each row of sprites, something like this: R Y R Y R Y Y R Y R Y R R Y R Y R Y G B G B G B O W O W O W W O W O W O For the score, there is no way to add a space in the middle, so it would not be possible to add in a comma. It is possible to have score_graphics.asm have spaces. I think I can do a quick hack that runs in vblank which would clear all the leading zeros and would not require changes to the kernal or score_graphics.asm. I will put this on my to-do list.

That's where I got them. Keep in mind that while I have been using these includes in my own projects, I haven't otherwise tested them.

Rather than have the bees turn into blocks, how about having them drop blocks. That way it would be like they are building a beehive. Also, after a bee is killed, a new one could either fly in from the side or hatch (with animation) from one of the cells. Making the playfield white, like wax would be cool, and give you some contrasting colors. Also animated flying from the bees would be nice. Faster missiles would also be nice. I assume you are using the ball as the gun at the bottom. It just occured to me to write a minikernal that would let you have an actual sprite down there. No idea yet on what might cause the game to end. Something would have to kill the gun at the bottom I suppose.

That sounds very, very cool Curtis. You know, that might be an interesting template for all kinds of games, up to and including strategy board games and RPGs. How much vertical separation and horizontal separation do you think there would need to be between each tile? It turns out that rows of six sprites is much easier to do. I could do up to eight rows pretty easily, but six rows looks best. For now I'm going with loose spacing, but putting them right next to each other might also be possible. Here is a static example of what this would look like. tiles.bin

I like that idea.

Actually, you shouldn't need to modify the kernel at all, just 2600basic.h. And instead of a playfield command create a data table names playfield. I will play with the code this week and see what I can come up with.

The background colors are strobing a bit too much for my taste, and sometimes there isn't enough contrast between the background and the bucket. The game is also a bit hard for me, but most games are. Two must do's: Have the reset switch start/restart the game the same way the joystick button does. Actually, the game should completely reboot any time the Select switch is pressed, and restart any time reset pressed (this is standard for Atari games). Set PF0 to make walls to the left and right of the screen (currently you have an empty space that can't be entered, walls would be more intuitive). Once it's complete, this will definitely be worth putting on a cart.

I cleaned up Michael's code, added left or right keypad selection, and packaged into a couple include files. The ZIP file contains the include files, two sample programs, and documentation. Now you can write those keypad games. keypad.zip

Horizontal or Vertical Scroll?

I think you'd be surprised how much you can fit into 4k with a little trickery. Right now the code is wasting a bit of space.

If these includes make it into the standard package, then you can include this in the manual... When the noscore constant is set, six additional variables are freed up, these may be addressed using dim statements referencing the variables score and scorepointers. For example, dim foo = score dim bar = score + 1 dim baz = score + 2 dim inky = scorepointers + 1 dim pinky = scorepointers + 2 ... dim blinky = scorepointers + 5 Advanced: In 2600basic.h the scorepointers memory immediately follows the score area, giving you a 9 byte array. dim arr = score for i = 1 to 9 arr[i] = i next And, if you do don't otherwise use variables temp1 through temp6, you can have a 15 byte array. Note, however that the temp variables are destroyed every time you drawscreen and may also be overwritten during function calls (like rnd).

Not only does this save a few bytes of code. It also stops the 3 score and 6 scorepointers from being overwritten, so you can now use them for your own purposes. (9 more variables, yay!)

How about using up to jump. It would be great if you could keep the game at 4k, so I can load it on my Supercharger. Personally, I prefer a smaller ROM to title and intro screen.

Last night, I discovered that some code that manipulates score and scorepointers was still being compiled into the code even though the constant noscore was set. I modified the offending include files appropriately. noscore.zip

I always put the extra include files in the same folder as the .bas file that I am compiling, rather than bB's includes folder.

Could you add A-F to these fonts? I can then package them up into a score_graphics.asm with the appropriate switching. Each font should have a name as well.

I've considered writing a whole new kernel to allow writing tile and card games. The playfield and sprites would be replaced with 5 rows of 8 tiles each each tile would be eight or nine pixels wide and eight lines high). Each tile would have an individual shape, chosen from a table of up to 256 shapes (basically a character generator). I have also thought about allowing a selectable background color (either COLUBK or COLUPF) for each tile. Is this something people would be interested in?

I would put Silhoutte on it. It's currently 4k. Don't know if I could get it down to 2k.

it would be quite easy to choose which one to use with a constant.

Nah, color striping would ruin the effect, which, by the way, is fantastic.

Don't use the temp variables for loops as they sometimes get used in bB functions. The rand function, for example, overwrites the value in temp1.

I'm pretty sure it's just reporting what memory location that label resolved to, most likely because it changed between passes.

You can use DATA tables for the X and Y positions, then you will only need 1 nybble for each enemy (assuming there are only 16 possible positions for each enemy).

In bB, the height of a sprite is stored in a single byte, so the largest height would be 255. This is far higher than what would actually get displayed on screen though, since the default playfield height is 88 lines and maximum would be about 120 lines. Yep, there seems to be a 256 height limit. I found that out when I was working on Tone Toy 2008.