Qbasicnews.com

Full Version: Map-scrolling method (long friggen post, please read)
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Okay I have a dilemma, and I think I have some sort of concept for a solution, but I want opinions.

Let me first set you up the situation...

I have a map consisting of any number of rows (y >= 10) and any number of columns (x >= 16) of integers that represent 20x20 tiles. The reason the maps must be 16x10 is because that's how big a screen is, and you can't very well have a map smaller than the screen, or else you're a crazy person. Anyways, the example map I have provided below is 20x15 and consists of mostly 00s, randomly places 01s, and 02s as the border. Being an actual RPG map, the 02s could represent a wall, the 00s grass, and the 01s any random object such as a rock.

In BowlingBall, my mario-clone engine, the method I used to display a map was to load a DC (layer) as big as the entire map is for each level. Obviously, this caused some unwanted complications in the code, and the very big problem of SPEED/MEMORY LOSS with relatively large levels.

I've thought of a new method that would save space, but might not be too efficient for a pixel-scroller such as BB... I could just load a DC the size of the screen's width and height plus one tile in each direction! This would mean that no matter the level's size, I'd always load a DC that is 340x220, which is really small compared to 5000x200. Then, as the character moves in any direction, such as RIGHT for example, the entire map is "moved over" 20 pixels to it's left, and the 10 new (blank) tiles on the right would then be read from the map file and placed onto the map DC! The reason this only works for my RPG is because I sorta cheated when I made movement available for my engine; I used the same method that Darkdread used in Secrets of Cooey 2: when you move, the character is animated 20 pixels to the left, without any stopping in the middle. Obviously, this method works wonderful when you don't want to deal with collision detection. So in my game, I can redraw the map DC at the beginning of the move, have my character walking in place (center-screen), amd simply move the map across the screen for 20 pixels!

So what do you all think? Is it a good idea? Can it be done? Should it be done? Has anyone else used this method in their games? I know someone mentioned using a similar method, but it was pixel by pixel, and that would just confuse the hell out of me.

(If I have repeated myself at all anywhere in here, or went too in depth, I apologize... I just like to write these things out before the thoughts are completed in my head, so I understand them better... Basically, I was thinking of this method as I wrote it down.)

Also, about the map data below, I know it could be stored more efficiently in a file. I know that a single character could represent a number up to 256, which would save space. However, I'm not interested in saving space in my external files. During the making of this game I'm working on, I've decided that I don't care if my files aren't compressed or efficient... I just want them to take up as little coding to read as possible, in the hopes that I can save enough space to FINISH my RPG! And I do read these numbers as strings, and then they are looked for as filenames in the datafile .pak file. This means that you can put any characters in that data that you want, and as long as there is a filename corresponding to it, it'll work. This makes it a lot easier to add more tiles in (such as adding an extra 900 tiles if I need more room, and just adding an extra digit to the tiles that need it).

Comments? Questions? I'm here all night.... But then no more for a few more weeks.

Code:
[MAP1.DAT]
02,02,02,02,02,02,02,02,02,02,02,02,02,02,02,02,02,02,02,02
02,00,00,00,01,00,00,00,00,00,00,00,00,00,00,00,00,00,00,02
02,00,00,00,00,00,00,00,00,00,00,00,00,00,01,00,00,00,00,02
02,00,00,00,00,00,00,00,00,00,00,00,01,00,00,00,00,00,00,02
02,00,00,00,00,00,01,00,00,00,00,00,00,00,00,00,00,00,00,02
02,00,00,01,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,02
02,01,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,02
02,00,00,00,00,00,00,00,00,00,00,01,00,00,00,00,00,00,00,02
02,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,02
02,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,02
02,00,00,01,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,02
02,01,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,02
02,00,00,00,00,00,00,00,00,00,00,01,00,00,00,00,00,00,00,02
02,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,02
02,02,02,02,02,02,02,02,02,02,02,02,02,02,02,02,02,02,02,02
I want to know something.

Your map is tile-based, right?

that's something like a 400x24 map, right?

So what's the problem?
I'm not sure I quite understand your question... If you mean my maps are only as big as the screen, then yes, that was what I was doing before. But now I'm changing my method to the Standard RPG Method, or SRPGM (sirp gym). I'm doing it this way because it's much better and cooler and better.
"maps only as big as the screen"?

WHAT? Your DC is as big as the screen??????
Just make your DC as big as your screen (320x200 for example). When your map doesn't fit in one piece on the screen it is ok, because you only need to draw the currently visible part of the map (so the speed will increase because less things will be drawn).

Just make it likes this:

Code:
cam.xpos = 0     'upper left corner of the screen (x-coordinate)
cam.ypos = 0     'upper left corner of the screen (y-coordinate)

cam.xwide = 20   'how many tiles in every row
cam.ywide = 15   'how many tiles in every column

tile.xwide = 20
tile.ywide = 20

FOR nx = cam.xpos TO cam.xpos + cam.xwide
FOR ny = cam.ypos TO cam.ypos + cam.ywide
  gx = tile.xwide * (nx - cam.xpos)
  gy = tile.ywide * (ny - cam.ypos)
  PUT (gx, gy), tile
NEXT ny
NEXT nx
That's a simple tile by tile scroller, but you must add only a few things to make it a real pixel by pixel scroller