Moving to next screen?

[endrien]

I'd like to know how I can move from on screen to the next.

For example with a playfield like:

  XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
  X...............................
  X...............................
  X...............................
  X...............................
  X...............................
  X...............................
  X...............................
  X...............................
  X...............................
  XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

 

When the player moves to the open area they go to the next playfield.

How could this be done?

[TooSlowGamer]

Something like this:

 

If player0x=192 (I'm not sure what the number is, but you could look it up or trial and error) then playfield:

(insert playfield here)

[endrien]

Something like this:

 

If player0x=192 (I'm not sure what the number is, but you could look it up or trial and error) then playfield:

(insert playfield here)

 

Thats what I was thinking, though you would need to do that for the entire x axis of that open area. Which is why I was wondering if there was a more efficient way.

[TooSlowGamer]

What do you mean? All it would do is use one if command and cover the whole side of the screen.

[endrien]

What do you mean? All it would do is use one if command and cover the whole side of the screen.

Oh yeah haha, brain fart. For some reason I was thinking x and y axis .

[+Random Terrain]

Oh yeah haha, brain fart.

I have a lot of those, especially when it comes to batari Basic.

[yuppicide]

Not sure what you're making, but SeaGt made a nice demo program that you can actually use.. it contains rooms similar to what you drew above, with every possible combination. The rooms are stored in data statements I believe, so it makes making a large map easy.

[SeaGtGruff]

Not sure what you're making, but SeaGt made a nice demo program that you can actually use.. it contains rooms similar to what you drew above, with every possible combination. The rooms are stored in data statements I believe, so it makes making a large map easy.

Yeah, the demo program was called move_around_rooms.bas, and you can get it here. You'll need to assign each room a number, and the data statements tell the program which room you end up in if you go north, east, south, or west from a given room.

 

Michael

 

PS -- As I recall, the demo reused the playfield statements for different rooms. For example, if room 1 and room 12 have the same shape, but represent different locations on the map, you can use the same routine to set the playfield shape of both rooms, but still give them different colors, and of course their exits would lead to different rooms.

Edited August 31, 2010 by SeaGtGruff

[+Gemintronic]

That demo does a good job of moving from room-to-room but the maze is from the dimension of chaos. You start with the Yellow Castle a room above you. If you move left -> up -> right the room with the castle is replaced with a green room.

 

Instead of separate level data for each direction why not one data statement for the whole dungeon?

[SeaGtGruff]

That demo does a good job of moving from room-to-room but the maze is from the dimension of chaos. You start with the Yellow Castle a room above you. If you move left -> up -> right the room with the castle is replaced with a green room.

Yeah, I started out wanting to approximately duplicate the arrangement of rooms in Adventure, and parts of the maze do have the same layout as Adventure-- except the rooms don't necessarily have the exact same shape or colors as in Adventure. Other parts of the maze are completely different. But I did include a lot of "spatial warping" in the maze, as in Adventure, where going left can take you to a location that's also reachable by going right, down, right, or something like that! It makes the maze difficult if not virtually impossible to map out well on paper, but if you forget about the spatial absurdities and just learn the maze, eventually you can quickly navigate your way to a desired location.

 

Instead of separate level data for each direction why not one data statement for the whole dungeon?

You could put all the data into a single data statement, but having four separate named data tables makes it easier to look up the next room going in any direction using the current room number as the index. It might be a bit wasteful for smaller mazes, since you wouldn't need to use all 8 bits in each data byte, but it allows for up to 256 rooms. If you've got only 16 or fewer rooms in your maze, you could combine two directions into a single table, using the high nibble for one direction and the low nibble for the other direction, and use bit masking and/or bit shifting as needed to get a value between 0 and 15. Or, if you want to have more than 256 rooms, you could use 2 bytes per data item, and read from the array using the sdata/sread method-- but you'd need to compute the address you want to sread from. That's actually pretty easy to do.

 

Michael