[Ninkazu]

[Gardon]

Read my above post, I asked about multiple maps. I already have a srolling background, I just need to know how to load maps and make it seamless.

Jason

[RuneLancer]

You mentionned a 3x3 "box" of maps, so why not dynamically load your maps?



If you move from M (the central map in the box) to, say, N, you could just unload G L Q and load J O T.



The problem is if the player moves back and forth across the border; the load time could be a pain. Most games implant transition screens to both encourage the player to stick on a given map and to avoid having to keep things seamless (ex, Zelda 1.)

Or you could just create a bigger map and make it scroll like Ninkazu suggested. I don't see why you'd need multiple maps if it's the same area and why you'd need the same map "context" when switching areas (ie, going into a dungeon or something.)
_________________
Endless Saga
An OpenGL RPG in the making. Now with new hosting!

[Nephilim]

Yeah, continually loading maps is kind of a pain technically and is the sort of thing that you can easily cut out of your first RPG without too much loss of gameplay sensibilities. With clever map and story design, your players will never miss it. Bottlenecking players through mountain passes and forest glades can easily be turned to your advantage from a story perspective. (And you'll often find yourself bottlenecking your players anyway even if your engine doesn't require it.)

Even if you want a world map that can be explored from sea, for instance, you can still do some clever tricks to keep players from knowing that there are staged loads. For instance, if you design your world so that it's in, say, quadrants, and no land masses overlap the quadrants (maybe your world is a bunch of island chains), then you can just have four large maps, and load at your liesure while the player is out to sea and you don't have to worry about the physical continuity of the land. (One of the early Ultima's did this.)

If you do decide to implement a rolling map load system, RL's suggestion above is the way to go - compute what's visible, and when your visible area moves out of your loaded area, unload the far stuff and load the near stuff. There are things you can do to minimize the constant reload he mentioned when stepping over boundaries, like keeping recently-left areas in memory until the player moves a little farther into the map area, or making your map sectors smaller, so that you have a 5x5 or 7x7 area visible instead of a 3x3 area, so that you load less unnecessary data and don't run into the redundant reload problem as much. (Of course, there's a point of diminishing returns which will depend on your particular implementation, so experiment to see what works best.)
_________________
Visit the Sacraments web site to play the game and read articles about its development.

[Gardon]

I'm going to experiment with something:

basically


A B C D E
F G H I J
K L M N O
P Q R S T
U V W X Y

ok I don't know how to make that look good or have lines through it, but the point is that there should be a box around just m. M is the current map, is 64 x 64 pixel tiles, and is 29 x 29 tiles big. With my current scroll rate (100 px a second) I can cross the map (from complete left to complete right) in a matter of 18 seconds.

What I'm currently doing is, assuming you're moving from M to L (to the left), having boundary markers to keep track of when to load the next map.

I currently have the boundary at 448 pixels (7 of the 64 x 64 bitmaps) and 1408 (again 7). I check for updates in the position, and if the player exceeds those boundaries the new map is loaded, and the old map (if any) is unloaded. The old map is the one on the other side of the boundary of the current map.

So:

K L M N O

M is currently loaded, but the user is still on M and goes left past the boundary marker. Now L and M are loaded, and if N was already loaded in memory it's now gone. If I were to switch over to M again on the right boundary point (1408), L would get unloaded and N reloaded again.

If the diagonal point is hit then a diagonal map is loaded (both the x and y markers. The max number of maps in memory at one time can only be 4.


Well I'm gonna experiment with this and see how it works. My goal is to have it where you can have a limitless game size.

And if it doesn't work then I'll just stick to one bigmap.


Jason

[RuneLancer]

Well, depending on the size you need, you might not even have to load stuff dynamically.

Endless Saga is 3D, thus my concepts don't quite apply to yours. But it doesn't take much alcohol for my brain to map 3D concepts to 2D, and I brewed meself a good 'ol cranberry screwdriver or two (polar bear vodka FTW!) So this should work...

Endless Saga splits up its map in "sectors." A sector is defined as a chunk of map data any size up to 16x16x16 units. The main use of sectors is to allow me to have multiple heights (I can just make 2 sectors overlap and easily handle, say, a spiraling staircase like this.) It quickly became a tool to optimize the display of very large maps. Instead of checking which polygones/objects/whatever are visible for everything on (say) the world map, which is a massive map, I just go through my list of sectors (maybe a few hundred or so at most for the world map?) and right off the bat, only keep the ones that are an arbitrary set of units away from the player (taking into consideration the direction being faced; no point rendering a sector 64 units immediately behind a player...)

This means that I always have little more than a handfull of chunks of map data to actively work with, and the rest just remain in memory until they're needed. No loading, no unecessary processing, and it works just fine. :)

Now. How this works in 2D. Even if you use 2 bytes per tiles (0-65535), a 2048x2048 tile map is only 8 megs. Which, with today's 1 gig+ PCs, is nothing to worry about (and frankly, that's a ridiculously massive map! IIRC, Final Fantasy III/VI has a 512x512 world map and uses only 256 tiles: 256k to load the whole thing.) So you can load the complete map data easily enough...

It gets even easier in 2D than 3D though: you don't have to worry about the player's field of view because it's always the same. The player can't move the camera and make it look far away into the horizon. You know there's always 20 tiles around the player before the display cuts off. So, all's you have to do is display those 20 tiles (that would be a 41x41 viewing region) and never even think about the other tiles (since they won't be seen anyways.)

At this point, the only problem you can have is if your map is truly massive (and if you have over 250 different 64x64 pixel tiles on a given map, I really doubt you'll have a 4096x4096 map. If you do, you need to downsize your game. ;) ).

The lesson here is, just render what you need and don't sweat it if you have unecessary stuff in memory. The more things loaded, the faster you can readily access them when you have to use them. Dynamic loading should only be considered when things become too big to manage. Keeping a dozen megs of map data in memory is no biggie. Keeping 128 megs of map data in memory is when you need to start rethinking your approach.

Edit: This makes sense to me, but then again, I have a few russian comrads patrolling the inside of my head. I'll elaborate if necessary.
_________________
Endless Saga
An OpenGL RPG in the making. Now with new hosting!

[Ninkazu]

RL, I don't think you understand... he's not using tiles... he's just using huge bitmaps that are made up of tiles. I tried to talk him out of it and to learn a bit more about engine theory, but he's not listening.

So ya, big fuckoff bitmaps for each map. 10mb a map. That's really efficient. *sigh* kids these days. When are they gonna learn memory doesn't grow on trees.

[RuneLancer]

...Oi. Yeah. That's not a very good idea, Gardon.

If you can use tiles, do so. Using bitmaps is only something you should do when tiles won't suffice (such as, say, FF7's prerendered scenary.) In the long run, you'll have problems you just wouldn't even have to worry about if you'd have used tiles...

Whereas a 512x512 16x16 pixel tiles map using 256 tiles would only take 256k for the map data and 192k for a 24bpp bitmap, a large bitmap of the same map at the same bit depth would be 192 megs. That's 1024x bigger.

Ninkazu has the right idea here: use a tile engine.
_________________
Endless Saga
An OpenGL RPG in the making. Now with new hosting!

[Gardon]

I just have to figure out how to scroll with it. i thought it was easy with a bitmap because I could just tell it what to blit and what the offset was by handling input. Now I have to work around that.

I mean I guess you guys are both right. Whatever.

I'll figure something out.

Thanks,

Jason

[Gardon]

Damn, and now I have to redo my map and maphandler classes.

Oh well,

Jason

[tunginobi]

Substitute a direct blit with a call to a function that draws a particular map of tiles. Use an X and Y offset to reposition the entire map at once.