bB questions..

[yuppicide]

Alright I've been fooling around awhile. I have no idea how to go about picking up a piece to move it. It has to check certain things.

 

The idea is you push fire and the piece is picked up if there is indeed a piece there otherwise buzzer will sound. You can then press fire again to put it down or press up, down, left, or right to move the piece. The piece will slide in the direction you push the joystick until it 1 - collides with another colored block (except red which it can slide on top of), or 2 - it slides off the board in which case the game stops and waits for you to hit reset which it will reset the current level.

[SeaGtGruff]

or 2 - it slides off the board in which case the game stops and waits for you to hit reset which it will reset the current level.

Just to be sure I understand, you're saying you want the player to be able to slide the piece off the board to stop the game? Wouldn't it be easier to just let the player hit RESET or SELECT at any time to reset the current level?

 

Michael

[yuppicide]

or 2 - it slides off the board in which case the game stops and waits for you to hit reset which it will reset the current level.

Just to be sure I understand, you're saying you want the player to be able to slide the piece off the board to stop the game? Wouldn't it be easier to just let the player hit RESET or SELECT at any time to reset the current level?

Michael

 

You can move any piece in any direction (except red which doesn't move - it's where you need to get to finish the level). If you know you made a wrong

move you can hit reset to reset the current level. But the reason you can slide off the board into space is because, if you accidentally press the wrong way

and didn't see there's no blocks in the way your block can fly off into space. A sound denotes you've flown off into space and you must hit reset to reset

the current level. I want this in the game because if you're on one of the "Expert" or "Advanced" levels and accidentally press the wrong direction it will

force you to start over. Might make some people forget the moves they did leading up to that and they'll have to rethink over.

 

Is there a scoring routine in your kernel? I was trying to implement bB's score, but couldn't get it to show up. Is that because of your my_drawscreen routine which we use instead? Oh wait, I see that's just a remark you put in to say you're going to add score there.

Edited September 4, 2007 by yuppicide

[yuppicide]

Where in your kernal did you draw the cursor or did you not have to do that because you're just coloring a grid line which is already drawn? I would have liked the cursor to be:

 

**  **
*	*

*	*
**  **

 

Just the corners of the grid block.. or is that not possible?

 

Do you think this kernal it's possible to modify it into an 8 x 8 grid somehow? I don't want to do it now. I am

just thinking ahead that I have another game in mind we could make. It's a conversion of a homebrew from another

system that uses a grid as well.

 

I have at least 6 different games that could possibly be made with this kernal. I could probably combine them all into a multicart. They're all different gameplay and one of them if doable is my own unique idea as opposed to the others which are remakes of games from other platforms.

Edited September 5, 2007 by yuppicide

[yuppicide]

Oops.. deleted.. posted this by mistake.

Edited September 5, 2007 by yuppicide

[SeaGtGruff]

Where in your kernal did you draw the cursor or did you not have to do that because you're just coloring a grid line which is already drawn?

The cursor (or player0) is stored as an 11-byte tall shape:

 

   dim cursorline0 = var25
  dim cursorrow0 = var26
  dim cursorline1 = var27
  dim cursorrow1 = var28
  dim cursorline2 = var29
  dim cursorrow2 = var30
  dim cursorline3 = var31
  dim cursorrow3 = var32
  dim cursorline4 = var33
  dim cursorrow4 = var34
  dim cursorline5 = var35

But each byte-- or row of pixels-- is either 6 or 27 scan lines tall. Specifically, the horizontal lines of the cursor (cursorline0, cursorline1, cursorline2, etc.) are 6 scan lines tall, and the vertical lines (cursorrow0, cursorrow1, cursorrow2, etc.) are 27 scan lines tall. For example, if you write %11001100 to cursorline0, then the cursor will have that shape on line 0 of the grid. Or, if you write %10000100 to cursorrow0, then the cursor will have that shape on row 0 of the board. Actually, the kernel sets the values of those bytes for you, which means anything you try to write to them will just get overwritten by the kernel.

 

I would have liked the cursor to be:

 

**  **
*	*

*	*
**  **

 

Just the corners of the grid block.. or is that not possible?

I had actually thought about doing that, but it was easier to draw a square. You can change the top and bottom lines of the cursor to a "broken" line by making the following change:

 

; old code:
;   LDA #%11111100		; +02 ; 59
;   STA cursorline0,X		; +04 ; 63
;   STA cursorline1,X		; +04 ; 67

; new code:
  LDA #%11001100		; +02 ; 59
  STA cursorline0,X		; +04 ; 63
  STA cursorline1,X		; +04 ; 67

This will make the cursor look like two square brackets:

 

   [ ]

But it isn't as easy to make the vertical lines "broken," so that the cursor is just the four corners of a square, because the loops that draw the five rows of the board will each need to be divided up into three parts. This is doable, but I'd rather not do it until I rewrite the whole kernel to be more efficient, because it will be easier to write a new version of the kernel that draws the cursor that way, than to try to modify the existing kernel to draw the cursor that way.

 

Do you think this kernal it's possible to modify it into an 8 x 8 grid somehow?

That would depend on how the 8x8 grid is drawn. This particular kernel draws the different colored blocks by changing the background color several times as the scan lines are being drawn, and it's certainly possible to change the background color 8 times on a line-- but it probably wouldn't be easy to use playfield pixels for the lines of the grid. This 5x5 grid worked out really well because the color changes take a certain amount of time to perform, and it just so happened that the blocks could be drawn 4 playfield pixels wide, with 1 playfield pixel between each column of blocks, and it lined up well with the color changes.

 

I don't want to do it now. I am just thinking ahead that I have another game in mind we could make. It's a conversion of a homebrew from another system that uses a grid as well.

 

I have at least 6 different games that could possibly be made with this kernal. I could probably combine them all into a multicart. They're all different gameplay and one of them if doable is my own unique idea as opposed to the others which are remakes of games from other platforms.

Chances are that it would be best to create a different custom kernel for each game. For example, this particular kernel would be totally unsuitable for something like a chess board, checkers board, Othello board, etc., because this kernel doesn't allow sprites to be drawn inside the blocks.

 

Michael

Edited September 5, 2007 by SeaGtGruff

[yuppicide]

Chances are that it would be best to create a different custom kernel for each game. For example, this particular kernel would be totally unsuitable for something like a chess board, checkers board, Othello board, etc., because this kernel doesn't allow sprites to be drawn inside the blocks.

 

Michael

 

I don't have to draw any sprites inside the blocks. It wouldn't look as good, but I could do all the ideas without sprites inside.. just colored blocks.

[SeaGtGruff]

Chances are that it would be best to create a different custom kernel for each game. For example, this particular kernel would be totally unsuitable for something like a chess board, checkers board, Othello board, etc., because this kernel doesn't allow sprites to be drawn inside the blocks.

 

Michael

 

I don't have to draw any sprites inside the blocks. It wouldn't look as good, but I could do all the ideas without sprites inside.. just colored blocks.

What objects would be needed on the screen (just in the main area game area-- don't worry about the score because it will have its own "zone"):

 

-- colored blocks (8x8 if possible);

-- presumably some grid lines (9 horizontal, 9 vertical);

-- presumably a cursor of some sort;

-- anything else?

 

Depending on the precise needs, there could be different ways of doing it.

 

Michael

[yuppicide]

I don't have to draw any sprites inside the blocks. It wouldn't look as good, but I could do all the ideas without sprites inside.. just colored blocks.

[quote name=What objects would be needed on the screen (just in the main area game area-- don't worry about the score because it will have its own "zone"):

 

-- colored blocks (8x8 if possible);

-- presumably some grid lines (9 horizontal' date=' 9 vertical);

-- presumably a cursor of some sort;

-- anything else?[/quote]

 

All I was mentioning is that I have 5 or 6 games that could be done using the grid, the blocks, all with different game play. It just wouldn't be any different graphically so it wouldn't be as interesting as something that has graphics in the block for instance.

 

For example one of the games that could be done (although it's already been done) is Lights Out. You know the game where you touch a light and the others around it either light up or light out.

[SeaGtGruff]

I don't have to draw any sprites inside the blocks. It wouldn't look as good, but I could do all the ideas without sprites inside.. just colored blocks.

[quote name=What objects would be needed on the screen (just in the main area game area-- don't worry about the score because it will have its own "zone"):

 

-- colored blocks (8x8 if possible);

-- presumably some grid lines (9 horizontal' date=' 9 vertical);

-- presumably a cursor of some sort;

-- anything else?[/quote]

 

All I was mentioning is that I have 5 or 6 games that could be done using the grid, the blocks, all with different game play. It just wouldn't be any different graphically so it wouldn't be as interesting as something that has graphics in the block for instance.

 

For example one of the games that could be done (although it's already been done) is Lights Out. You know the game where you touch a light and the others around it either light up or light out.

Well, if the only things you need are a grid of lines, 9 across and 9 down, creating an 8x8 board where each block can be a different color, plus a cursor to show you which block you're on, then I've worked out how to do it. It will still use the playfield to draw the grid lines, so the grid lines will be pretty thick-- one-third as wide/tall as the blocks-- but I think that should still look okay. I'll see about making a modified kernel for that later, and post a demo.

 

Michael

[yuppicide]

Well, if the only things you need are a grid of lines, 9 across and 9 down, creating an 8x8 board where each block can be a different color, plus a cursor to show you which block you're on, then I've worked out how to do it. It will still use the playfield to draw the grid lines, so the grid lines will be pretty thick-- one-third as wide/tall as the blocks-- but I think that should still look okay. I'll see about making a modified kernel for that later, and post a demo.

 

Michael

 

No no hehe.. I guess I shouldn't think out loud. I was getting ahead of myself. Must. Fin. ish. This. Pro. Ject. First. Must. Not. Talk. In. Frag. Ments. Must. Stay. Crunch. Y. In. Milk.

[Fort Apocalypse]

This thread is way cool. Can't wait to try the game! This kernel looks like it would be great for doing some sort of strategy/simulation game also, or board games (chess/checkers/chinese checkers/maybe even mancala!). I'm probably getting way ahead of myself.

[SeaGtGruff]

This thread is way cool. Can't wait to try the game! This kernel looks like it would be great for doing some sort of strategy/simulation game also, or board games (chess/checkers/chinese checkers/maybe even mancala!). I'm probably getting way ahead of myself.

Probably not, because this kernel (and the 8x8 version I'll do later) basically just changes the color of the background to get the different colored blocks, and that takes so much time during the line that it doesn't leave much time to do other things, like draw the sprites-- and this kernel doesn't let you use any sprites, anyway. I'm not saying that a strategy game or board game isn't possible, just that this particular kernel wouldn't be able to handle them. But it would be possible to create other kernels.

 

Michael

[yuppicide]

This thread is way cool. Can't wait to try the game! This kernel looks like it would be great for doing some sort of strategy/simulation game also, or board games (chess/checkers/chinese checkers/maybe even mancala!). I'm probably getting way ahead of myself.

 

It's okay I got ahead of myself as well.

 

The game is going to be called "Spaceman Spit". I got the idea for the name as I was reading a Calvin and Hobbes cartoon book. He has an imaginary character

called Spaceman Spiff.

 

As of right now it looks like there's enough room to fit 40-60 levels into this game! This may change as I add title screen, sound, music, etc. With 40

levels in the game there's still room to add stuff, which is good, so I'd say there will be atleast 40 levels.

 

Levels are broken down into skill levels from Beginner to Expert.

 

Things I expect to have in the game:

 

- Nice title screen with music

 

- Select button will allow you to start on either level 1, level 10, or level 20. This allows you to sort of "continue" the game so you won't have to start

all over at the beginning again. Note I don't think there will be any selecting your way to level 30. You'll have to work your way back there if you stop

playing and come back later.

 

- Level indicator to show which level you are on

 

- Sound effects to represent your spaceman spitting

 

- Maybe some sort of intermission every 10 levels?

[yuppicide]

I have been trying to figure out movement. I can't find a good way to do it without extremely bloated code and even then I haven't finished working on it because it's very time consuming.

 

Explain this code of yours to me:

 

   b = 5 * cursory + cursorx
  c = blockcolor[b]
  c = c + 2
  blockcolor[b] = c

 

I am not totally sure, but I'm thinking I need to figure that out what that does exactly in order to do master block movement. Am I on the right track there?

 

Here's what I am thinking for movement:

 

   if carry=0 then goto nocarry 
  if carry=1 then carcol = 1 : goto carry
  if carry=2 then carcol = 2 : goto carry
  if carry=3 then carcol = 3 : goto carry
  if carry=4 then carcol = 4 : goto carry
  if carry=5 then carcol = 5 : goto carry

 

That would let the program know you are carrying a block or not when you press a joystick direction. It would also tell the program what color the block you are carrying is.

 

Then my code would do nocarry which is if you're not carrying a block:

 

nocarry

  if joy0left then cursorx = cursorx - 1 : if cursorx = 255 then cursorx = 4
  if joy0right then cursorx = cursorx + 1 : if cursorx = 5 then cursorx = 0
  if joy0up then cursory = cursory - 1 : if cursory = 255 then cursory = 4
  if joy0down then cursory = cursory + 1 : if cursory = 5 then cursory = 0

  gosub my_drawscreen

  loop

 

That's easy.. there's no block to erase and draw as it slides. It just moves your cursor then goes back to the loop you made. Atleast I think that part is right.

 

Now here comes my bloated part:

 

carry

  if joy0left then cursorx = cursorx - 1 : if cursorx = 255 then cursorx = 4 : gosub carle
  if joy0right then cursorx = cursorx + 1 : if cursorx = 5 then cursorx = 0 : gosub carri
  if joy0up then cursory = cursory - 1 : if cursory = 255 then cursory = 4 : gosub carup
  if joy0down then cursory = cursory + 1 : if cursory = 5 then cursory = 0 : gosub cardo

carle:
  if cursorx = 0 and cursory = 0 then block00color = black : goto deaths
  if cursorx = 0 and cursory = 1 then block10color = black : goto deaths
  if cursorx = 0 and cursory = 2 then block20color = black : goto deaths
  if cursorx = 0 and cursory = 3 then block30color = black : goto deaths
  if cursorx = 0 and cursory = 4 then block40color = black : goto deaths
  if cursorx = 1 and cursory = 0 then block01color = black :

 

carle will be a routine for carrying left.. or sliding a block left.

carri will be a routine for carrying right.. or sliding a block right.

etc.

 

.. as you can see with all the possibilities my code would be very bloated and use up too much space.

 

As you can see if your cursor is in the left column and you press left it slides off the board. So it sets that block to black then goes to the section that makes the sound of you flying off into space. The game stops there until you press fire to restart the level.

 

Now if your block is any other position but the first column the program needs to check if it can indeed move left. If there is no other block there it can move left. If it cannot move left it plays a buzzer noise. If it can move left it paints the current block with black, moves left one and paints that the appropriate color. It repeats this process until it either bumps into another block in which case it stops or slides off the board in which case you fly out into space.

 

Your input is most appreciated. Thanks.

Edited September 7, 2007 by yuppicide

[SeaGtGruff]

I have been trying to figure out movement. I can't find a good way to do it without extremely bloated code and even then I haven't finished working on it because it's very time consuming.

 

Explain this code of yours to me:

 

   b = 5 * cursory + cursorx
  c = blockcolor[b]
  c = c + 2
  blockcolor[b] = c

 

I am not totally sure, but I'm thinking I need to figure that out what that does exactly in order to do master block movement. Am I on the right track there?

That snippet of code calculates the block number where the cursor is, gets the color of that block, increments the color by 2 (to get the next color in the Atari 2600's 128-color palette, since the 128 colors are all even-numbered), and then changes the current block to the new color. Since you want to understand this code, I'll explain it in more detail.

 

The blocks are nothing but blobs of color, so the only data we need to store for them are their color values. The blocks are arranged in 5 rows, and 5 columns, so there are 25 blocks, numbered 0 to 24. Thus, there are 25 consecutive bytes assigned to the block colors, starting at "blockcolor" (or "var0"). You don't need to use any of the other variables to use the blocks (e.g., "block20color"), because if you know the number of a block, then you can use it with "blockcolor[whatever]" (where "whatever" is simply the block number, given as either a numeric literal like "1" or "2," or a variable like "a" or "b"). Note that the blocks are numbered as follows:

 

+---+---+---+---+---+
| 0 | 1 | 2 | 3 | 4 | row0
+---+---+---+---+---+
| 5 | 6 | 7 | 8 | 9 | row1
+---+---+---+---+---+
|10 |11 |12 |13 |14 | row2
+---+---+---+---+---+
|15 |16 |17 |18 |19 | row3
+---+---+---+---+---+
|20 |21 |22 |23 |24 | row4
+---+---+---+---+---+
col0 col1 col2 col3 col4

As stated, the blocks are arranged in 5 rows, numbered 0 to 4, and 5 columns, also numbered 0 to 4. To get the number of any block, we just need to know the row and column it's in, and then we can use this formula:

 

   block = 5 * row + column

For example, if we're in row 3, column 4, then the block number is 5 * 3 + 4 = 15 + 4 = 19. So that's what the first line of that code does-- it multiplies "cursory" (the row the cursor's in) by 5, and then add "cursorx" (the column the cursor's in), to get the block number, which is then stored in variable "b" (I probably should have used the "block" variable that I'd defined for this purpose, but the fact is, you can use any available variable).

 

Okay, now that I've calculated the number of the block, I want to look in the table of block colors to see what the color of that block is-- so that's what the next line does, it looks up "blockcolor" and stores it in variable "c."

 

The line after that is dependent on what I'm trying to do-- that is, the program you're referring to was a simple little demo to show the kernel in action, and what the demo did was let you move around the board with the joystick, and then press the fire button to change the color of whatever block you're on. In particular, each time you press the fire button, the color value of the block goes up to the next color. The Atari 2600's color values range from 0 to 255, but the odd-numbered values are the same as the even-numbered values, so there are really only 128 colors, not 256 (i.e., 0 and 1 are the same colors, 2 and 3 are the same colors, 4 and 5 are the same, etc.). So to increment the current color of the block to the next color value, I add 2 to the current color value.

 

But then I have to actually set the block color to the new value, which is what the last line does.

 

Here's what I am thinking for movement:

 

   if carry=0 then goto nocarry 
  if carry=1 then carcol = 1 : goto carry
  if carry=2 then carcol = 2 : goto carry
  if carry=3 then carcol = 3 : goto carry
  if carry=4 then carcol = 4 : goto carry
  if carry=5 then carcol = 5 : goto carry

 

That would let the program know you are carrying a block or not when you press a joystick direction. It would also tell the program what color the block you are carrying is.

 

Then my code would do nocarry which is if you're not carrying a block:

 

nocarry

  if joy0left then cursorx = cursorx - 1 : if cursorx = 255 then cursorx = 4
  if joy0right then cursorx = cursorx + 1 : if cursorx = 5 then cursorx = 0
  if joy0up then cursory = cursory - 1 : if cursory = 255 then cursory = 4
  if joy0down then cursory = cursory + 1 : if cursory = 5 then cursory = 0

  gosub my_drawscreen

  loop

 

That's easy.. there's no block to erase and draw as it slides. It just moves your cursor then goes back to the loop you made. Atleast I think that part is right.

 

Now here comes my bloated part:

 

carry

  if joy0left then cursorx = cursorx - 1 : if cursorx = 255 then cursorx = 4 : gosub carle
  if joy0right then cursorx = cursorx + 1 : if cursorx = 5 then cursorx = 0 : gosub carri
  if joy0up then cursory = cursory - 1 : if cursory = 255 then cursory = 4 : gosub carup
  if joy0down then cursory = cursory + 1 : if cursory = 5 then cursory = 0 : gosub cardo

carle:
  if cursorx = 0 and cursory = 0 then block00color = black : goto deaths
  if cursorx = 0 and cursory = 1 then block10color = black : goto deaths
  if cursorx = 0 and cursory = 2 then block20color = black : goto deaths
  if cursorx = 0 and cursory = 3 then block30color = black : goto deaths
  if cursorx = 0 and cursory = 4 then block40color = black : goto deaths
  if cursorx = 1 and cursory = 0 then block01color = black :

 

carle will be a routine for carrying left.. or sliding a block left.

carri will be a routine for carrying right.. or sliding a block right.

etc.

 

.. as you can see with all the possibilities my code would be very bloated and use up too much space.

 

As you can see if your cursor is in the left column and you press left it slides off the board. So it sets that block to black then goes to the section that makes the sound of you flying off into space. The game stops there until you press fire to restart the level.

 

Now if your block is any other position but the first column the program needs to check if it can indeed move left. If there is no other block there it can move left. If it cannot move left it plays a buzzer noise. If it can move left it paints the current block with black, moves left one and paints that the appropriate color. It repeats this process until it either bumps into another block in which case it stops or slides off the board in which case you fly out into space.

 

Your input is most appreciated. Thanks.

As you already suspect, you can simplify that code a lot. First, let's suppose the player presses fire to pick up a color. You said before that the black colr can't be picked up (because it indicates that there's nothing in that square), and the red block can't be picked up, so we want to check the color of the selected block to see if it's black or red, and sound a buzzer if it is:

 

   carrying = no : rem * initialize the "carrying" variable to "no" (or constant "0")
  if !joy0fire then goto fire_not_pressed : rem * skip ahead if fire isn't pressed
  block = 5 * cursory + cursorx : rem * calculate the current block number
  color = blockcolor[block] : rem * get the color of the block
  if color = black then goto buzzer : rem * can't pick up black
  if color = red then goto buzzer : rem * can't pick up red
  carrying = yes : rem * set the "carrying" variable to "yes" (or constant "1")
fire_not_pressed
  rem * etc., more code goes here

  rem * then somewhere else in the program is the code to sound the buzzer
buzzer
  rem * etc., code to sound the buzzer
  goto fire_not_pressed : rem * after sounding the buzzer, jump back into the loop

So now we're either carrying a block, or not. By the way, we probably want to check the "carrying" variable when the fire button is pressed, because the fire button will do something different depending on whether or not we're carrying a block-- if we're *not* carrying a block, then fire will let us try to pick up a block (if it isn't black or red); but if we *are* carrying a block, then fire will let us drop the block in the current spot.

 

As for moving around, you want to check to see if anything's in the block you're trying to move into, that is if you're carrying a color. But if you *are* carrying a color, then you also need to save your current position, so you'll need to use two other variables for the new position. Something like this:

 

   column = cursorx : rem * initialize new column to cursor column
  row = cursory : rem * initialize new row to cursor row
  if joy0left then column = column - 1 : goto check_block
  if joy0right then column = column + 1 : goto check_block
  if joy0up then row = row - 1 : goto check_block
  if joy0down then row = row + 1
check_block
  if column = 255 then goto off_the_board
  if column = 5 then goto off_the_board
  if row = 255 then goto off_the_board
  if row = 5 then goto off_the_board
  if carrying = no then goto move_cursor : rem * can skip over the next part
  block = 5 * row + column
  color = blockcolor[block]
  if color = black then goto move_block
  if color = red then goto move_block
  goto buzzer
move_block
  oldblock = 5 * cursory + cursorx
  oldcolor = blockcolor[oldblock]
  blockcolor[oldblock] = black
  blockcolor[block] = oldcolor
move_cursor
  cursorx = column
  cursory = row
  rem * then loop back

I haven't tried this yet, so I don't know if it's okay.

 

Michael

[yuppicide]

For example, if we're in row 3, column 4, then the block number is 5 * 3 + 4 = 15 + 4 = 19.

 

That was one of my first mistakes in reading the code. I was thinking the code was actually doing row + column * 5 and if you do the math you get a much higher number which I knew wasn't right. That was totally my mistake in not being able to figure it out.

 

I will take a more in-depth look at it when I get home tonight from work and test it out. If my desk/monitor wasn't facing out at work I'd get bB and DASM right now and start working lol, but since it's not the most I do is read things. I usually copy the

latest message from the forum and paste it into Windows Notepad, so it has no color or graphics. This makes it look like I'm actually doing work hehe (as you might tell we're not that busy right now).

[SeaGtGruff]

For example, if we're in row 3, column 4, then the block number is 5 * 3 + 4 = 15 + 4 = 19.

 

That was one of my first mistakes in reading the code. I was thinking the code was actually doing row + column * 5 and if you do the math you get a much higher number which I knew wasn't right. That was totally my mistake in not being able to figure it out.

Actually, it does sort of seem backwards, and it could go either way depending on how the blocks are numbered-- from column to column across each row (example 1), or from row to row down each column (example 2):

 

   example 1		|   example 2
  00 01 02 03 04   |   00 05 10 15 20
  05 06 07 08 09   |   01 06 11 16 21
  10 11 12 13 14   |   02 07 12 17 22
  15 16 17 18 19   |   03 08 13 18 23
  20 21 22 23 24   |   04 09 14 19 24

Then there are the possibilities of going right-to-left instead of left-to-right, or bottom-to-top instead of top-to-bottom.

 

Since the color values are being used one scan line at a time, from left to right, the numbering method in example 1 makes the most sense. This means the individual block variables (e.g., "block34color" or "block25color") use numbers that seem backwards, because when we think of a point on a grid, we typically think of (X, Y) where X is the column and Y is the row, so the column comes before the row. But in this case, the row actually comes before the column-- so in the variable name "block25color," the "25" does *NOT* mean (2, 5), it actually means row 2, column 5.

 

Way back in college, one of my computer professors taught us a catchy little phrase to help us remember this:

 

"Me and my RC."

 

In this case, "RC" means "row, column," not a cola.

 

Michael

[yuppicide]

"Me and my RC."

 

In this case, "RC" means "row, column," not a cola.

Michael

 

Nowadays that might be a little "outdated". Not many places here in NJ sell RC Cola anymore.

 

My art teacher taught me a little saying too.. "a little dab'll do ya" -- in reference to not using too much glue.

[yuppicide]

Been fooling around. I can get it to compile, but not to work properly. Whatever I/we did with the code movement is very slow. You have to hold the direction down for a few seconds before it'll move.

 

First off I added this in the beginning.

 

   dim oldblock = 0
  dim oldcolor = 0
  dim carrying = 0
  dim color = 0

 

Otherwise with your code in there it wouldn't compile. I also got an error because at one point you said carrying = no. I had to make it so carrying could = 0 for not carrying or 1 for carrying.

 

So then I added your code into the loop and modified it a little:

 

loop

  if new_level then gosub load_new_level

  for x = 0 to 119
  gosub my_drawscreen
  next

  column = cursorx : rem * initialize new column to cursor column
  row = cursory : rem * initialize new row to cursor row

  if joy0left then column = column - 1 : goto check_block
  if joy0right then column = column + 1 : goto check_block
  if joy0up then row = row - 1 : goto check_block
  if joy0down then row = row + 1 : goto check_block
  if joy0fire then goto carry_change

 

That's my first change. We needed something to check if fire was pressed. You were only checking for directions. So if fire is pressed we goto here:

 

carry_change
  if color = red then carrying = 0 : goto check_block
  if color = black then carrying = 0 : goto check_block
  carrying = 1

 

That above says if you press fire and the block underneath is red or black then carrying is no. You can't carry those colors.

Otherwise if it's any other color underneath you may carry so set carrying to yes. Now we goto this part:

 

check_block
  if carrying = 0 then goto move_cursor
  if column = 255 then goto restart_game
  if column = 5 then goto restart_game
  if row = 255 then goto restart_game
  if row = 5 then goto restart_game

 

Your code had carrying = no after that last row statement. I think the placement is incorrect. First we need to check if we're carrying a block. So I added the first line which is saying if you're not carrying anything then goto the cursor moving section. Otherwise if you are carrying something it goes to routine to move block. I changed those to goto restart_game as opposed to off_the_board. Just for now because I wanted to see the game work. Later on I could add the off_the_board routine. This is saying if you do slide a piece off the board the game is over and you must start that level over again. The code continues here:

 

   block = 5 * row + column
  color = blockcolor[block]
  if color = black then goto move_block
  if color = red then goto move_block
  
move_block
  oldblock = 5 * cursory + cursorx
  oldcolor = blockcolor[oldblock]
  blockcolor[oldblock] = black
  blockcolor[block] = oldcolor
  carrying = 0

 

I added the carrying = 0. Because after your block moves you're no longer carrying a block. The block slides in the direction you moved the joystick until it bumps into another block, flies off the board, or lands on the red block. If it bumps into another block the block stays there, you are no longer carrying. If it flies off the board it will do the off_the_board routine, but for now restart_game. Red is the only block (besides empty black blocks) you can travel over. If your purple block lands on the red block you have completed the level.

 

move_cursor
  if column = 255 then column = 4
  if column = 5 then column = 0
  if row = 255 then row = 4
  if row = 5 then row = 0
  
  cursorx = column
  cursory = row
  
  if level = 0 then goto restart_game

  goto loop

 

I will send you a link to the game I am recreating. You can see for yourself how it plays.

[SeaGtGruff]

With regard to the speed thing, I had used some simple frame-counting logic in my earlier demo to keep the movement from being too fast:

 

   a = a + 1
  if a < 4 then goto continuewithloop
  a = 0

In an actual game, some sort of "debounce" routine would be better. Right now I won't try to explain what I mean by that, but in the meantime you can speed up the frame-counting logic by changing the if to use a smaller number.

 

I will send you a link to the game I am recreating. You can see for yourself how it plays.

It looks like you've changed the rules slightly from the original game? Because in the original game the red block can be moved, too.

 

Michael

[yuppicide]

It looks like you've changed the rules slightly from the original game? Because in the original game the red block can be moved, too.

 

Michael

 

No your mistaken. I didn't want to have two red blocks because that would be confusing on the 2600 since we don't have any graphics in the block just color. So, I made your character purple and left the middle block red which is the mothership. The middle block (red) cannot be moved.

[SeaGtGruff]

First off I added this in the beginning.

 

   dim oldblock = 0
  dim oldcolor = 0
  dim carrying = 0
  dim color = 0

 

Otherwise with your code in there it wouldn't compile.

Sorry, I didn't pick up on this earlier. You can't "dim" like that. Or rather, you can, but you need to be careful what you're doing. The "dim" statement lets you equate a new symbolic name with an address or existing symbolic name. If you say "dim name = number" (like "dim oldblock = 0"), you're telling the batari Basic compiler and the DASM assembler that wherever you use that name (like "oldblock"), you really mean the indicated memory address (like "0"). If you say "dim name1 = name2" (like "dim name = uservariable"), you're doing exactly the same thing, except you're referring to the address of something that's already been defined (so "dim oldblock = a" would mean that "oldblock" has the same address as "a").

 

The problem with your code is that 0 is the memory address for the VSYNC register, so those "dim" statements are locating those variables to the address of VSYNC, which isn't a RAM address. You need to "dim" those variables to some addresses in RAM-- either some bB "system variables" that aren't needed by the custom kernel, or some of the 26 "user variables," etc.

 

Michael

[SeaGtGruff]

It looks like you've changed the rules slightly from the original game? Because in the original game the red block can be moved, too.

 

Michael

 

No your mistaken. I didn't want to have two red blocks because that would be confusing on the 2600 since we don't have any graphics in the block just color. So, I made your character purple and left the middle block red which is the mothership. The middle block (red) cannot be moved.

Okay, I thought that might be what you were intending. In that case, maybe a different shade of red could be used for the central block, or maybe even something like a flashing color?

 

Michael

[yuppicide]

   a = a + 1
  if a < 4 then goto continuewithloop
  a = 0

In an actual game, some sort of "debounce" routine would be better. Right now I won't try to explain what I mean by that, but in the meantime you can speed up the frame-counting logic by changing the if to use a smaller number.

 

Does that not make no sense?

 

1. If a = a +1 then a would equal 1.

2. If a is less than 4 then it skips the whole thing and goes to continuewithloop which redraws the screen then goes to the beginning of loop again (thus never getting to the joystick routine). a is always less than 4.

3. a will always be less than 1 because you're setting it to 0 again.

 

Maybe continue with loop is where all my joystick and other routines go like check block and all that or do I place them in loop?

Edited September 11, 2007 by yuppicide