Pac-Man-type maze question

[+atari2600land]

So i've got this maze set up (no dots to eat, anyway), but I have 2 questions:

#1 = why is there a line above my character

and

#2 = how do I program the guy to move the way Pac-Man does? Right now, if you press up while going left or right and he hits a wall, he just stops instead of just ignoring the wall and going on his merry little way.

pacman.bas.bin

pacman.bas

Edited May 24, 2007 by atari2600land

[Nukey Shay]

Regarding the second question, you need to first check that the direction wanted by the player is valid before allowing the direction variable to be changed. Basically, you'd need a lookup table that has directional info for every pixel location. If all of your intersections (i.e. where direction changes are possible) are evenly spaced, you can cut down the size of this table considerably.

The screen is horizontally mirrored, so the directional info for the other half of the display can be reused. That eliminates half of the pixel locations that need to be included in this table. Going vertically, the other half of the display is -almost- a mirror image of the first (only the top row of thick walls differ)...so you might want to edit the maze before proceeding.

[+atari2600land]

OK, I made the top the same as the bottom (thanks for pointing that out BTW.) Anyway, how would I go about doing that? Let's say there's an intersection at 90 & 41. Something like:

if x=90 && y=41 then a=5

so if x didn't equal 90 then it would go the direction of where it was going (either left or right) regardless of if I push the joystick up or down?

[+atari2600land]

Am I on the right track?

pacman2.bas

[Nukey Shay]

Just imagine a gridwork of lines that cover the maze...running through the center of rows and columns. The gridwork should be evenly spaced so that you can easily weed out sprite locations that don't need checking (by dividing the X and Y by the spacing...for example, every 4 color clocks wide by 8 scanlines high = X/4, Y/8). If the center of the top row is at the 8th scanline, there's no need to check on the 7th or less...a sprite can never be there.

 

This is going to involve checks at a LOT of screen locations, so the best way is to use a lookup table. Optimally by dividing the X by the number of pixels each column takes x 4 (because each playfield pixel is 4 color-clocks wide) and divide Y by the number of scanlines each row takes. If either have a remainder, skip the routine and just use the existing direction (not at an intersection in the imaginary grid). Otherwise, multiply the latter by the number of bytes of "map" data each row requires, then add the former...then use that as an offset to read from the map table. The value returned should indicate which directions are valid. If invalid, use the existing direction. If valid, change the direction.

[Tempy]

Sorry for digging up such an old thread, but I'm having similar issues with the player sprite having a line above it, and I was wondering what I'm doing wrong and if you've solved that issue.

 

test.bas

Edited August 15, 2007 by Tempy

[SeaGtGruff]

Sorry for digging up such an old thread, but I'm having similar issues with the player sprite having a line above it, and I was wondering what I'm doing wrong and if you've solved that issue.

 

test.bas

I think maybe it's because you haven't defined any of the other sprites. Try defining player1, even if it's just a blank line:

 

   player1:
  000000
end

 

I haven't done a lot with the multisprite kernel yet, but I seem to remember that if you use player0 without defining player1 or any of the other players, you get a vertical line above your player0 sprite.

 

Michael

[Tempy]

I think maybe it's because you haven't defined any of the other sprites. Try defining player1, even if it's just a blank line:

 

   player1:
  000000
end

 

I haven't done a lot with the multisprite kernel yet, but I seem to remember that if you use player0 without defining player1 or any of the other players, you get a vertical line above your player0 sprite.

 

Ah thanks, that did the trick!

 

On another note, pasting bit data in the codebox in forum posts doesn't always seem to work properly. Oh well.

[+Random Terrain]

#2 = how do I program the guy to move the way Pac-Man does? Right now, if you press up while going left or right and he hits a wall, he just stops instead of just ignoring the wall and going on his merry little way.

This may not be the correct thing to do, but in my WIP bB game and on other computers that I made Pac-Man type games, I never used a lookup table. I just have the program check to see if a wall is where you are trying to go and if there is one, the program keeps your little guy moving in the direction he was already moving. The program does all the work for you, so there is no need to make a lookup table. Using this method also allows you to have random mazes and your little guy will always move the way he is supposed to.

 

 

Update:

 

If you want a working example of Pac-Man style movement without a lookup table, try this unfinished test game I was working on back in 2005:

 

ruins_y2005m10d01e06.bin

If you use Stella, make sure the height under Game Properties is set to 210 (set it, quit the game which will take you back to the list of ROMs and start the game again).

 

Here's my old bloated code you can look at in case any of it might be helpful, but it probably won't work correctly with the latest version of bB:

ruins_y2005m10d01e06.bas

Edited August 16, 2007 by Random Terrain

[SeaGtGruff]

I think maybe it's because you haven't defined any of the other sprites. Try defining player1, even if it's just a blank line:

 

   player1:
  000000
end

 

I haven't done a lot with the multisprite kernel yet, but I seem to remember that if you use player0 without defining player1 or any of the other players, you get a vertical line above your player0 sprite.

 

Ah thanks, that did the trick!

 

On another note, pasting bit data in the codebox in forum posts doesn't always seem to work properly. Oh well.

Sorry, I forgot about that bug. The way to get around it is to put some empty bracket thingies (like bold on/bold off) right after the % but before the first digit, like this (I'm using {} instead of [] so it shows up):

 

%{b}{/b}00000000

 

Then it looks like this %00000000 instead of this 000000.

 

Michael

Edited August 15, 2007 by SeaGtGruff