Playfield upgrade request for batari Basic

[+Random Terrain]

Below is a 32 x 23 playfield (actually 32 x 22 visible).

 

  playfield:
  XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
  X..............XX..............X
  X..............XX..............X
  X..XXX..XXXXX..XX..XXXXX..XXX..X
  X..............................X
  X..............................X
  X..XXX..X..XXXXXXXXXX..X..XXX..X
  X.......X......XX......X.......X
  X.......X......XX......X.......X
  XXXXXX..XXXXX..XX..XXXXX..XXXXXX
  X..............................X
  X..............................X
  X..XXX..XXXXXXX..XXXXXXX..XXX..X
  X....X....................X....X
  X....X....................X....X
  XXX..X..X..XXXXXXXXXX..X..X..XXX
  X.......X......XX......X.......X
  X.......X......XX......X.......X
  X..XXXXXXXXXX..XX..XXXXXXXXXX..X
  X..............................X
  X..............................X
  XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
end

 

It's nice that we can create playfields like the example above instead of only being able to use pfpixel, pfhline, and pfvline.

 

But it would be very helpful if we could tell playfield: where to start drawing. I'm not sure what is possible, so I'll give a couple of examples.

 

 

Example #1 (ypos only)

 

If xpos isn't possible and we can only to tell playfield: to start drawing at ypos, then we could do something like this with a number or variable:

 

 

  playfield: 15
  XXX..X..X..XXXXXXXXXX..X..X..XXX
  X.......X......XX......X.......X
  X.......X......XX......X.......X
  X..XXXXXXXXXX..XX..XXXXXXXXXX..X
  X..............................X
  X..............................X
  XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
end

 

batari Basic would leave rows 0 through 14 alone and place the above data on the screen starting at row 15.

 

 

 

 

Example #2 (xpos and ypos)

 

If it would be possible to tell playfield: to start drawing at xpos and ypos, then we could do something like this with numbers or variables:

 

  playfield: 19 15
  XX..X..X..XXX
  ....X.......X
  ....X.......X
  XXXXXXXXXX..X
  ............X
  ............X
  XXXXXXXXXXXXX
end

 

batari Basic would leave the rest of the screen alone and start drawing the data above starting 19 pixels over and 15 rows down.

 

Here's another xpos/ypos example:

 

  playfield: 0 15
  XXX..X..X..XXXXXXXXXX..X..X..XXX
  X.......X......XX......X.......X
  X.......X......XX......X.......X
  X..XXXXXXXXXX..XX..XXXXXXXXXX..X
  X..............................X
  X..............................X
  XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
end

 

 

 

I hope example #2 with xpos and ypos will be possible, but if you can only do example #1 with ypos, that's better than nothing. Example #1 would still help me create random-ish playfields for maze games, but example #2 would give me more control and would be useful in all kinds of games.

 

I'm really going to need this ability in at least two of my future games. Yes, I know everyone reading this just fell on the floor laughing, but I will get at least one game finished.

 

Thanks.

[+batari]

Vertical is easy enough but horizontal is a bit harder unless you limit changes to 8-pixel swaths. Either way, the only benefit I can think of is partial playfields will just save ROM space (provided you have enough to overcome the extra ROM space needed for the new library that would be needed.)

 

So the real question is would there be so many playfield combinations that you'd use more than 32k?

[jrok]

What if you just created three binary data arrays for the top, middle and bottom of the maze containing the on/off bit for each playfield pixel in a maze segment, then run a pointer through it that sets on the pfpixel whenever it encountered a "1" (think of the way you might run a pointer through a data statement for music; except instead of singing, this pointer draws pixels). Then, you could randomize the row at which each pointer begins to draw it's segment of the maze. Then once all the drawing is finished you could start the game level.

[+Random Terrain]

So the real question is would there be so many playfield combinations that you'd use more than 32k?

I doubt I'd have that many. In my old crappy work in progress called Bloober and the Gnarl, the maze has three sections (middle, top, and bottom) and each section is made up of one of seven randomly selected pieces. Some pieces of the top and bottom sections can affect the middle section, so that mixes it up a bit. It's a messy version of controlled randomness.

 

That was 7 pieces for each of the 3 sections (7 x 3 = 21). Problem is that I had to draw out everything with the VbB playfield editor, then figure out how to convert it using pfpixel, pfhline, and pfvline. A huge pain in the butt and too darn hard for somebody who has about 2 working brain cells.

 

Now that I have improved, less messy code for a maze game, I can redo Bloober and the Gnarl and make new pieces for a 32 x 22 maze that will be randomly put together. I just hope this time there will be a better, easier way to do it. I almost broke my brain the first time, so I hope I won't have to do it all over again with pfpixel, pfhline, and pfvline.

Edited August 3, 2011 by Random Terrain

[jrok]

I almost broke my brain the first time, so I hope I won't have to do it all over again with pfpixel, pfhline, and pfvline.

 

Why all three? It seems like pfpixel alone would do the trick. Conversion sounds like it would just be a matter of replacing all the "."s with zeros, all the "X"s with ones, then putting that into a data statement. You could get eight rows of pfpixels from each statement, so each array could form a third of your maze.

 

For instance:

  playfield:
  XXX..X..X..XXXXXXXXXX..X..X..XXX
  X.......X......XX......X.......X
  X.......X......XX......X.......X
  X..XXXXXXXXXX..XX..XXXXXXXXXX..X
  X..............................X
  X..............................X
  XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
end

 

...could be:

 

  data MazePiece1
  1,1,1,0,0,1,0,0,1,0,0,1,1,1,1,1,1,1,1,1,1,0,0,1,0,0,1,0,0,1,1,1,
  1,0,0,0,0,0,0,0,1,0,0,0,0,0,0,1,1,0,0,0,0,0,0,1,0,0,0,0,0,0,0,1,
  1,0,0,0,0,0,0,0,1,0,0,0,0,0,0,1,1,0,0,0,0,0,0,1,0,0,0,0,0,0,0,1,
  1,0,0,1,1,1,1,1,1,1,1,1,1,0,0,1,1,0,0,1,1,1,1,1,1,1,1,1,1,0,0,1,
  1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
  1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
  1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
end

 

 

You could make a bunch of those, then you could use a byte of RAM to determine which data statement to draw and when. Then use a temp variable to write the data.

 

As a bonus, the screen would have a cool "drawing" effect as the pointer moved through the arrays

[+Random Terrain]

I think at the time I originally started the old crusty random maze, I was fuzzy about how to use data with batari Basic.

 

If I didn't punch the wrong numbers into the calculator, 32 x 22 divided into 3 sections would be less than 255 each. If it's as easy as that, I guess batari doesn't have to waste time if he doesn't want to. It shouldn't be that hard to convert X and . to 1 and 0 with commas using Notepad or something.

 

Thanks.

Edited August 4, 2011 by Random Terrain