Jump to content
IGNORED

Tetris for 2600 BASIC?


atari2600land

Recommended Posts

When I first heard about pfpixels 6 months ago, the first thing that popped in my mind was Tetris. Since Batari Basic has been around for a long time, I'm surprised nobody has made a Tetris game using the pfpixels. So is it possible? I tried my hand at it, and if anyone wants to improve upon it, you'll want to take out the blockcounter variable and replace it with something else. Right now, my (stupid) demo is just one pixel instead of a shape, and you can't put pixels on top of each other, and when the whole line is complete, the score changes and the line disappears.

 

EDIT: If you change line 187 to read:

187 if blockcount>=10 && pfread(a,b) then blockcount=0 : goto 211

then it won't matter how many blocks come down when you fill the line. The first .bas file I made I stupidly put

187 if blockcount=10 then goto 211

not realizing that once 10 blocks have fallen, it will automatically clear the line whether it was full or not.

tetris2a.bas

tetris2a.bas.bin

Edited by atari2600land
Link to comment
Share on other sites

When I first heard about pfpixels 6 months ago, the first thing that popped in my mind was Tetris. Since Batari Basic has been around for a long time, I'm surprised nobody has made a Tetris game using the pfpixels. So is it possible?

Yes, it's possible, but I think you'd want to customize bB to do it well.

 

First, you'd want to modify bB's kernel and pfdrawing routines to get more pfrows, either by using Superchip RAM, or by simply using fewer bytes per pfrow. For example, bB's asymmetric zero-page RAM playfield uses 48 bytes-- four bytes per pfrow, and 12 pfrows per screen (or 11 visible pfrows in a non-scrolling display)-- but you could modify bB to use just two bytes per pfrow, and get 24 pfrows per screen (and even display all 24 pfrows, rather than hiding one or two of them behind the score bar). Each pfrow would be just 16 pfpixels wide, consisting of the left and right copies of PF2, with PF0 and PF1 being untouched by the kernel (the way PF0 is in bB's standard kernel). That should be a wide-enough playfield for Tetris, and you could use PF0 and PF1 to put a border on the left and right sides of the "drop zone."

 

Second, you'd want to increase the number of colors per screen. You wouldn't need to change the colors from scan line to scan line-- and in fact, you'd really want the palette to stay constant for the entire height of the "drop zone." Fortunately, you could use flickering with three different colors per field-- flipping between two sets of three colors on odd and even fields-- to get up to nine colors on the screen (a background color, plus eight colors for the different shapes), as follows:

 

Color 1 = BK1 + BK2

Color 2 = PF1 + PF2

Color 3 = PM1 + PM2

Color 4 = BK1 + PF2

Color 5 = PF1 + BK2

Color 6 = BK1 + PM2

Color 7 = PM1 + BK2

Color 8 = PF1 + PM2

Color 9 = PM1 + PF2

 

where

 

BK1 = COLUBK on the odd fields

BK2 = COLUBK on the even fields

PF1 = COLUPF on the odd fields

PF2 = COLUPF on the even fields

PM1 = COLUP0 and COLUP1 on the odd fields

PM2 = COLUP0 and COLUP1 on the even fields

 

So the two players would be set to the same color as each other, and would be sized and positioned to get 16 player pixels that overlap the 16 pfpixels.

 

By carefully choosing the two sets of three colors, you should be able to get a variety of nine colors, although you wouldn't actually need nine colors, so you could pick just the six combinations that give the widest range of colors.

 

And third, I would expect that you'd want to modify bB's zero-page RAM usage so that the two player shapes are stored in RAM, with each player pixel being the same height as the pfpixels-- which would be another 48 bytes of RAM (24 bytes per player). That would require 96 bytes of zero-page RAM, which would leave 32 bytes for other things-- user variables, the score, a few temporary variables, and the stack. The alternative would be to leave bB's zero-page RAM alone, and use Superchip RAM for the game screen (pfpixels and player pixels), but I think you should be able to make do with just the zero-page RAM-- as long as you customized bB by removing all unneeded routines and system variables. For example, if you aren't going to use the ball and missiles, and if the two players are going to have fixed positions on the screen, and if the player memory will have a fixed location in RAM, then all the bB system variables that are currently used for moving the players, missiles, and balls, and for specifying their heights and memory pointers, could be used for player RAM instead.

 

So I think a 4K Tetris game should be doable with bB-- otherwise, an 8K Superchip Tetris game.

 

Michael

Link to comment
Share on other sites

This is just a quick color mix test to demonstrate how mixing (flickering) two sets of three colors-- as described in my previous post-- can produce up to nine colors. For this demo, I tried to choose colors that mix to create the greatest range of hues, but two of the mixtures look fairly similar, so of these nine color mixtures, let's say there are seven or eight mixtures that could be used in a Tetris game. If memory serves me, there are six different shapes in Tetris, so we'd need seven different colors in the "drop zone"-- six shapes, plus the background. In this color mix test, you can lock in either field by pressing the fire button on the joystick. This test is written in standard bB, and the most "exotic" thing about the code (as far as standard bB goes) is the use of the "no_blank_lines" kernel option.

 

Michael

 

post-7456-1164693080_thumb.jpg

 

post-7456-1164693092_thumb.jpg

 

post-7456-1164693104_thumb.jpg

color_mix_test.bas

color_mix_test.bas.bin

Link to comment
Share on other sites

If memory serves me, there are six different shapes in Tetris, so we'd need seven different colors in the "drop zone"-- six shapes, plus the background.

Oops, that should be seven different shapes, so eight colors would be needed. :)

 

Michael

Why do the shapes have to be different colors?

 

"Tetris in Batari Basic would be cool."

Yes, I know. If only we could get someone who knows way more about the innards of bB than I do to work on such a thing...

Link to comment
Share on other sites

It'd be a lot easier to program if all the shapes were the same color. Something like in Edtris (only slimmed down to meet bBasic's requirements)

Colin Hughes did a version of Tetris that used multiple colors, but the colors were the same for each row, so you could do something like that with bB's pfcolor option.

 

Michael

 

post-7456-1164854580_thumb.jpg

Link to comment
Share on other sites

"Tetris in Batari Basic would be cool."

Yes, I know. If only we could get someone who knows way more about the innards of bB than I do to work on such a thing...

How about the game programmed in straight assembly? I wouldn't use the trademarked title, though. Edited by Zach
Link to comment
Share on other sites

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...