#348 - snug - Mon Jan 06, 2003 6:53 pm
I've come up with a few ways of doing large maps, like using a hardware BG map and reloading it with an offset after every 8 pixels. I'm just curious how other people are doing this.
Adam
#355 - sgeos - Mon Jan 06, 2003 8:25 pm
It is done something like that. That is the solution I'd use. Have you seen how Breath of Fire solves that problem? It's kind of neat.
-Brendan
#358 - snug - Mon Jan 06, 2003 8:44 pm
No I haven't. Would you mind sharing with me? I'm working on an engine and I'm trying to find the best way to do it.
#370 - sgeos - Mon Jan 06, 2003 11:28 pm
| snug wrote: |
| No I haven't. Would you mind sharing with me? I'm working on an engine and I'm trying to find the best way to do it. |
It uses a 64 tile wide by 32 tile high scheme. With a 32 tile wide scheme you can only load 8 by 8 bg tiles, but it looks like they are using 16 by 16 bg tiles. As you walk, the BG keeps scrolling (in a circular manner, no 8 pixel deal) and writes over the old stuff when it gets there. I'm not sure exactly how it works, but it seemed to load 'half tiles', that is 8 by 8 tiles. I thought it was an interesting solution.
-Brendan
#382 - Costis - Tue Jan 07, 2003 3:00 am
Hi,
16x16 pixel background tiles are not supported in hardware. Only 8x8 BG tiles can be used. All other tiles that are in BG layers and appear to be larger are just "meta-tiles", which are really just 8x8 tiles placed together.
Costis
#394 - anli - Tue Jan 07, 2003 9:55 am
You can get 16x16 bit tiles if you use bg scaling :)
If you have a big map, I would recommend using a small bg and
do the hardscroll by modifying the screenbase data every 8th scroll tick.
Then you can decide the dimensions freely.
Just how I would do
/anli
#396 - ampz - Tue Jan 07, 2003 10:04 am
I have a bitmap game where all the tiles are unique and changing all the time.
I use a text BG with tiles just to get hardware scrolling.
There is space in video RAM for "almost" one unique tile for every tile position on screen, left me with a small border, perfect for the menu ;)
It's quite complicated to do pixel modifications in a text BG, but I got it working.
I don't know if others use the same "trick" just to get hardware scrolling when a bitmap mode should really be used?
#397 - Lord Graga - Tue Jan 07, 2003 10:05 am
But in a engine it might be necesary to have 16x16 tiles in a engine because of the lack of variable space. Then a small map only need 256 variables in a array (that is four times smaller).
A sample loading method could be (note, it is untested):
| Code: |
int i,j;
for(i=0;i<16;i++) //Every other vertical line of mem
{
for(j=0;j<16;i++) //Every other horizontal line of mem
{
ScreenMem[i*2+j*2] = map[i*j];
ScreenMem[i*2+j*2+1] = map[i*j];
ScreenMem[i*2+j*2+32] = map[i*j];
ScreenMem[i*2+j*2+33] = map[i*j];
}
}
|
#2441 - Francis Lillie - Tue Feb 04, 2003 1:07 am
There are a number of ways of doing large maps, but the one I am going for, and which will work well for what I need (as I did it on the Megadrive), is to have the tile screen made up of unique character numbers. That is have the map numbered 0-31 across the top row, then 32-63, and so on for a screen size of 32x22. This means that I need room in VRAM for 704 unique characters. When I scroll 8 pixels, I know which row or colum goes off screen, and therefore which characters are now free in VRAM, and upload tiles to those slots. The actual "map" in VRAM never changes. Worst case scenario is that a row and a column of characters gets sent to VRAM each frame, which is either 1728bytes or 3456 bytes. A complete map screen of 32x22 is 1408 bytes. Take your pick. Using this method, having meta-tile sizes of 64x64 I plan to have map sizes of 3km x 3km, where 1 8x8 character represents 1m x 1m. Another advantage of the unique character approach is that I can store certain events, such as tyre marks (yes, I'm doing a driving game) and alter the character data as I upload it without affecting any other place that that character data is used on screen. Effectivley a bitmap based character map. it's the way the deformable landscapes were done on Worms back on the Megadrive and SNES. Hope this helps.
#4169 - DiscoStew - Fri Mar 21, 2003 11:23 pm
I new to this forum, but I have a little knowledge about programming for the GBA, and after looking at some of the docs, I've come to this conclusion (I haven't tried this, since I'm not around my own computer to try it out).
The way the Text Backgrounds are laid out (according to my understanding from ThePernProject), each 256x256 (or 32x32 tiles) is it's own block of data. What I mean is that the structure is in an order like this...
32 tiles from left to right on 1st vertical block, then
32 tiles from left to right on 2nd vertical block, ... until
32 tiles from left to right on 32nd vertical block.
Of course you all knew that, but where I'm getting at is that with the other background dimensions of Text Backgrounds, it's laid out the same way, but the first 32x32 tiles on the top-left side is structured first, then the next 32x32 tiles on the top-right side are next, then 32x32 tiles of bottom-left, then lastly, 32x32 tiles on bottom-right (as structured of a 512x512 size background). For this size of a background, to my knowledge, it isn't ordered like...
64 tiles from left to right on 1st vertical block,... until
64 tiles from left to right on 64th vertical block...
but is structured like I said above.
So, to have a large map, I would have every map before compiling into the GBA format be split into even 32x32 tiles from whatever width to whatever height, as long as it is divisable by 32 each way. Then the regular load map into external RAM, and load a 2x2 section of your 32x32 tile split map (whichever you wish to start from) into the VRAM where your data for the 512x512 text background is like so...
1st section placed into mapdatalocation,
2nd section placed into mapdatalocation + 32x32x2bytes,
3rd section placed into mapdatalocation + ((32x32x2bytes) x2),
4th section placed into mapdatalocation + ((32x32x2bytes) X3),...
...and when you scroll your background, when entering a new 32x32 section, just offset your x and y counters (whatever is needed) that locate the complete map data comprised of your 32x32 sections, and load them into you mapdatalocation like above.
Like I said before, I haven't tried this procedure yet, but to me it looks like it should work. I'd draw a picture or something, but I am unable to at this time. I hope those of you who read this understand it, and that you can use it to your advantage.
Just my 2 cents.
_________________
DS - It's all about DiscoStew
#4175 - tepples - Sat Mar 22, 2003 2:49 am
| DiscoStew wrote: |
| So, to have a large map, I would have every map before compiling into the GBA format be split into even 32x32 tiles ...and when you scroll your background, when entering a new 32x32 section, just offset your x and y counters (whatever is needed) that locate the complete map data comprised of your 32x32 sections, and load them into you mapdatalocation like above. |
Some games actually do this, but there is one slight potential problem with this technique. It may be possible for the player to walk back and forth across the borders so as to require loading two new map segments quite often. If your maps are compressed, loading a new map segment can take a long time (possibly longer than one frame), making the scrolling appear jumpy.
In addition, using a 64x64 tile map uses 6 KB more VRAM than using a 32x32 tile map. Be prepared to give up 192 tiles.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#4255 - DiscoStew - Wed Mar 26, 2003 12:54 am
6K VRAM? Dang, I never thought of it that way. Though there is 64K total for both tiles and map data, losing 192 tiles (or more depending on how many 64x64 map sizes you have) can be bad. I guess it all depends on how you set up everything.
The jumpiness that you described could be fixed (somewhat). Instead of each section being 32x32, the actual sections could be 30x30 with a tile extra for each of the 4 sides, still making it 32x32. Then when loading up a new portion, just reposition the background coordinates to make it look like it's still moving as it should. By doing this, when you move over to a new section, you'll be 8 pixels (1 tile) away from the edge of reloading the last section of map data, so the jumpiness will not exist (or at least not as frequent).
This is one reason why I like these forums. You give your comment, someone gives you a question concerning it, and you (usually) find out the solution. It helps me think a little more.
_________________
DS - It's all about DiscoStew