I am currently working on a Final Fantasy project, and I was wondering about Final Fantasy's maps. Are they based on 2x2 meta tiles? Do they have different sizes? I'm really really concerned that I may not have enough space for maps, and I'm wondering how the other Final Fantasies work. Does anybody know how they conserve space? Like Final Fantasy 3 for instance? Any multiple size metatiles?
A lot of games use "object oriented" maps, where each element of the map has a type, x, y, width and height, and those are rendered into a metatile map in RAM before being drawn to the nametables. Super Mario Bros. uses a primitive version of this technique; Super Mario Bros. 3 and Super Mario World implement it exactly as I just described it.
As for games whose map structure is still a grid, Pokémon is said to use 32x32-pixel metatiles. Sonic the Hedgehog 2 uses run-length encoding and 128x128-pixel (!) metatiles, which is acceptable because the player moves so fast that he or she doesn't see the repetition.
All 8-bit Final Fantasy games (including Final Fantasy Legend and Adventure for game boy, even if they're not real FF games) works on 16x16 metatiles.
The games probably use some trick to reduce the size of the maps. There is many compression algorithms, begining with RLE, that can easily shut the size down to 20% of the original one, and because they run with additionnal RAM, it is easy to use a lot of RAM to have all used maps decompressed in RAM.
If you want to know more, try to reverse-engineere them to have a better idea of how they works.
tepples wrote:
Sonic the Hedgehog 2 uses run-length encoding and 128x128-pixel (!) metatiles
These are indeed very large metatiles! But even with such large construction blocks they can pull levels that look much more interesting than the ones in the GBA
Sonic games.
I think they use some sort of LZ compression, not RLE. The whole level is decompressed to RAM at once, on level start. The 128x128 metatiles are made of 16x16-pixel metatiles though, not individual tiles. The SMS version of
Sonic 2 uses RLE compression and 32x32-pixel metatiles, that are placed directly in the levels. The levels are also fully decompressed to RAM when the level starts.
Celius, I can't tell you how they do it in
Final Fantasy. But if you want to have large maps you will most likely need to chose one of the following:
1. object-based levels, where every screen starts empty and is filled with objects at specifyed positions, in RAM;
2. grid-based with compression, where you decompress the screens to RAM as the player moves;
3. grid-based with heavier indirection, as in the
Sonic series, where you have more than 1 level of metatiles.
For my current game I chose option 3, since that seems to be the only option that does not require extensive use of RAM. I use 16x16-pixel metatiles that are used to make 64x64-pixel metatiles that are used to make 256x256-pixel screens that are used to form the level. May seem complicated but allows for very large maps, needs no compression/decompression algorithms and needs no extra RAM, you can access everything directly from ROM.
Thank you all for that information. I have one question though.
tepples wrote:
those are rendered into a metatile map in RAM before being drawn to the nametables
Why is that? Why are they rendered into RAM before being drawn to name tables? I've always wondered why people say a map has to be decompressed before it can be compressed in RAM or something like that, I thought it was all nonsense. Why the heck does it have to be decompressed before compression? I think I may be translating this into my brain incorrectly. I really don't know what everyone's talking about. Will someone please clarify this?[/quote]
Celius wrote:
tepples wrote:
those are rendered into a metatile map in RAM before being drawn to the nametables
Why is that? Why are they rendered into RAM before being drawn to name tables?
Most general-purpose data compression schemes require data to be read out in strict sequence, such as from left to right and top to bottom. Arbitrary scrolling maps are specifically
not read out in strict sequence; the RAM is used as a buffer to allow random access to inherently sequential data.
Celius wrote:
Why is that? Why are they rendered into RAM before being drawn to name tables?
Because you draw ROWS and COLUMS of tiles to the name tables. If your map is not arranged in the form of rows and columns, as happens with grid maps but not with object based maps, you'll have a hard time translating that to rows and columns in real time.
I don't know if you know that Celius, but when the screen scrolls, you only draw what is new, in the form or rows and columns. When your screens are compressed or arranged with objects, thare is no way you can read rows or columns from there unless you decompress/render them to RAM first, where the map will be arranged in the form of grids.
You could render a non-grid map to the name tables IF you didn't use scrolling, since in that case you could just shut rendering off and take your time to draw all you want to the screen - object by object, or by full decompression of the compressed screen. But with scrolling, you only have time to draw a few rows and/or columns of tiles.
Hope you understand.
tokumaru wrote:
I don't know if you know that Celius, but when the screen scrolls, you only draw what is new, in the form or rows and columns.
I understand that, I believe I was translating it into my head incorrectly. I'm retarded, I thought people were talking about meta tiles for some reason. Like, for a one screen 16x15 map using 2x2 meta tiles, you had to have all 1024 bytes for each tile, instead of one byte for each 2x2 meta tile. Like decompressed meta tiles. I don't know. But what do you think would be a good way to do what you were talking about?
I think I'll try a few things, I should be able to come up with something. I'd be able to have about 64 maps + code in 1 16k PRG bank. So 1 8x8 screen grid in 1 bank, that's pretty good actually. And I don't know why people keep saying 2x2 meta tiles makes a 16x16 map, it doesn't. It makes a 16x15. I've counted. I only need $F0 bytes to fill a whole screen. Now that I think about it, I don't think it'll be THAT much space taken up.
So pretty much I'm just retarded. I think reading the columns will be the hardest part. Should I have the whole 8x8 screen grid is 1 big 1 dimensional array? Or should I have 64 seperate screens? I think the big array will be the better option, because reading columns will be alot easier. Thanks a bunch for your feedback. =)
tokumaru wrote:
1. object-based levels, where every screen starts empty and is filled with objects at specifyed positions, in RAM;
I don't think this one is very good, at least not for an RPG. While space-efficient, it would be very limited and glitchy if you happen to superpose one object on another.
Quote:
2. grid-based with compression, where you decompress the screens to RAM as the player moves;
This is probably the best option for a RPG or a strategy game.
Quote:
3. grid-based with heavier indirection, as in the Sonic series, where you have more than 1 level of metatiles.
This will be better for platformers or shooters, where maps are larger and less detailed than with RPGs.
For my current game (that is a action-adventure game) I use two levels of metatiles. I use maps of 8x6 blocks that are 32x32 pixels (the maps are compressed with a kind of RLE), then I use 16x16 metatiles (there is 4 of them in a 32x32 block) that contain tile graphics and collision properties. This works fine because it is an action-RPG so it needs less detail than a true RPG. However, in a real RPG you couldn't use that method because you need a lot of detail with houses, chests, etc...
I hope I was clear enough.
Celius, I definitely should make an univeral RPG map library available for anyone that want to make a 16x16 based RPG. I'd do that someday, but I have pretty much alot of work right now.
I am thinking of making a NES ROM map editor like the one I made, but for large 8x8 screen maps. But the bad thing is that it'd only be able to let you edit a 4x8 section, because RAM is only 8k, and 8x8 screens is 16k. So this is not good. I don't know how I could do this. I really wish I could have 1 big map. Oh, I still could, I'd just have to edit it like 4 screens verticly, and 8 screens horizontally. Then I'll just copy/paste the data from one, and combine it as the second half of the other. I don't know. I cannot make any C/C++ programs, that is out of the question. I will learn those sometime, but not soon.
Metatile maps are smaller and will also probably compress better in some cases than 8x8 grid maps. I don't think it's any harder to index metatiles (just run through each row/column twice, drawing half on each pass).
Celius, here is a quick tip to draw (to the name tables) metatiles in the form of rows or columns of tiles:
Have the maps for the metatiles arranged in a non-sequential way. Reserve 4 pages (256 bytes) of ROM, so that one page represents the top left tile, the other page represents the top right tile, and so on. Then you can have access to any tile of the metatile just indexing with the metatile number.
Then to draw a row of tiles, say, the top half of the metatiles, you'd do it like this:
Code:
LDA (screenmap), Y 'load the metatile index
TAY 'put it in Y
LDA upleft, Y 'load upper left tile index
STA $2007 'write it
LDA upright, Y 'load upper right tile index
STA $2007 'write it
Then you move to the next metatile.
It will work you have maps for your metatiles, but I just remembered that you were using a format where you specified the index of the first tile the other 3 were the ones following the first, right?
You can still draw a row just as easily. Like the previous example, say you want to draw the top half of the metatiles:
Code:
LDA (screenmap), Y 'load the metatile index
TAY 'put it in Y
STY $2007 'write the index of the top left tile
INY 'make it the index of the top right tile
STY $2007 'write it
Or something like this. Hope you got the idea.
I'm sorry, I'm not calling you a bad explainer, but I dont' know what you mean. My format does this:
meta tile index = $82
This is what will appear on screen:
$82,$83
$92,$93
If the variable Tile_Index is $82, and is processesed through my subroutine, then that is what will happen. It will show up as what I posted above. But why do you only show me like 3 writes to $2007? I don't know how this shows a column, or a row. Would you care to explain again? I don't get what you are saying when you are talking about the upper right/left corners. Sorry...
Celius wrote:
If the variable Tile_Index is $82, and is processesed through my subroutine, then that is what will happen.
Where? In your level editor? You'll probably have to write faster code for the game itself. I'd suggest you have metatile $82 be composed by tiles $82, $83, $84 and $85 just for simplicity. You can write faster code if you do it like this. You must be doing it the way you do so that you can easily view the blocks when you use a pattern table viewer, right? Please don't bother with that if it will slow down your code.
Quote:
But why do you only show me like 3 writes to $2007?
Because I showed you how to render 1 metatile only. It is up to you to build the rendering code around that. I don't know if you're gonna make a loop, or have it unrolled... so I showed you how to render only 1, and you repeat that as you'd like.
Quote:
I don't get what you are saying when you are talking about the upper right/left corners.
Your metatile is composed by 4 tiles: the upper left one (0), the upper right one (1), the lower left one (2) and the lower right one (3). Like this:
Code:
0 1
2 3
When you're copying rows of tiles to the name tables, you have PPU increments set to 1, then you'll be drawing either tiles 0 and 1 or 2 and 3. Remember, rows. If you're rendering columns, with PPU increments set to 32, you'll be drawing either tiles 0 and 2 or tiles 1 and 3.
The code I showed you before wrote tile 0 and then tile 1. You'll have to build the other 3 versions of that, or figure out a way to use the same routine for all 4 cases.
Anyway, you'll be running through all the metatiles in the row and/or column to be drawn, writing the 2 tiles of it that interest you, depending on whether you're drawing a row or a column, and if it's the first or second half of it.
tokumaru wrote:
Celius wrote:
If the variable Tile_Index is $82, and is processesed through my subroutine, then that is what will happen.
Where? In your level editor? You'll probably have to write faster code for the game itself. I'd suggest you have metatile $82 be composed by tiles $82, $83, $84 and $85 just for simplicity.
I'd suggest
$84 $86
$85 $87
which would let you use the same tile data for backgrounds and 8x16 sprites. However, if you don't run your metatiles through a lookup table, you're going to have problems with solid-color sky metatiles taking up 4 tiles in your pattern table instead of 1.
Quote:
You can write faster code if you do it like this. You must be doing it the way you do so that you can easily view the blocks when you use a pattern table viewer, right? Please don't bother with that if it will slow down your code.
If you have a pattern table viewer or editor that supports 8x16 sprites, such as the tile view of 8TED, then the layout I proposed will still look fine.
Okay, I think I understand. You want to know something?
tokumaru wrote:
If you're rendering columns, with PPU increments set to 32
I've never understood until just now what PPU increment 32 meant. I thought it had something to do with PPU cycles, or one of those things that just flies over my head. That is really really handy. Hey, if you set PPU increments to 32, can you store something in $2007 32 times, and have it start storing tiles in the next column? Do you get what I'm saying? Well, this is good information to have. But with metatiles, wouldn't you have to like switch between increment 1 and 32? Yeah, you could write 1 meta tile to the Name table, then increment 32, but you'd have to render it in a certain way:
in meta tile $82:
render tile $82
render tile $83
render tile $93
render tile $92
increment 32
because it would start out on the second tile of the next meta tile. If you don't get it, it's okay, because I'm a bad explainer. But yeah, I suppose it would be easier to have 1 meta tile in the pattern tables like:
0 1
2 3
instead of
0 1
10 11
You know? Yeah, thanks a bunch. But still, how would you take a column, and turn it into an array? I have a lot of thinking to do, I guess.
tepples wrote:
I'd suggest
$84 $86
$85 $87
which would let you use the same tile data for backgrounds and 8x16 sprites.
Why not? It works just as well for rendering and is compatible with the 8x16 sprites, in case you want to animate a block or something.
Quote:
However, if you don't run your metatiles through a lookup table, you're going to have problems with solid-color sky metatiles taking up 4 tiles in your pattern table instead of 1.
He's making a RPG, so it's more like a grass tile, but that's the same! =) I also think this is not such a good way to do metatiles... they will be very limited because of little to no reuse of tiles.
Quote:
If you have a pattern table viewer or editor that supports 8x16 sprites, such as the tile view of 8TED, then the layout I proposed will still look fine.
Anyway, how can that be usefull? Unless you're actually drawing all the game's art a tile at a time, in a tile editor, as was done 15-20 years ago. Come on people, draw the graphics in a more versatile editor. I use MSPAINT, great tool for low-color sprites/tiles. Then I rearrange the tiles (bless the select/scissors tool!) in a way that results in the best performance of the program and use my own program to convert the BMP to the NES format.
Nah, what the hell... Now I think it's not even such a big difference in Celius' case. An ADC #$10 here or there will not hurt anyone. The biggest problem may be not having tilemaps, but that's his decision when he sees how the levels are going to look when finished. Who knows, it might just work out well.
I have 1 thing to say about your format though, Celius. If each number indexes 4 tiles, that means you'll be using 64 metatiles, right? I don't think you'll be using a value in between metatiles that will get you a messed up block... Well, if you have only 64 metatiles, you have 2 unused bits that I think you should use to define the palette of the metatile. It's just an idea, to make use of the unused bits. After all, you are doing things in a very compact way, and that's pretty compact. May be a bit hard to decode/handle (although I don't know how you're doing the attributes at this time), but may be worth the space not wasted.
I think YY-CHR supports that display mode (0,1,2,3 for 16x16). I know that's what I use for my metatiles (makes a lot of sense, especially for animating metatiles in CHR-RAM).
Quote:
But with metatiles, wouldn't you have to like switch between increment 1 and 32?
Nope. Each metatile is 2 nametable columns, so just render each nametable column seperately with 32 increment all the way down.
Celius wrote:
I've never understood until just now what PPU increment 32 meant.
Yeah, it exists so you can write columns as fast as you can write rows.
Quote:
Hey, if you set PPU increments to 32, can you store something in $2007 32 times, and have it start storing tiles in the next column?
No, not really. You'd get into an attribute table, I guess, since that's what's after the name table. And it's 30 times, not 32. This happens with rows, though. If you get to the end of it and keep writing you'll start to fill the next row. Unfortunatelly not with columns, no, you'll have to manually set the address of the next column.
Quote:
But with metatiles, wouldn't you have to like switch between increment 1 and 32?
I'd avoid doing that more than twice. Say the player is moving diagonally: set increments to 1, write the first half of a row then the second half, set to 32, write half a column, write the other half. You shoudn't draw 1 full metatile at once, or you'll have to set the write address twice for every metatile and the code will be too slow to fit in VBlank. That's why I told you to draw HALF a metatile at a time. After you draw the first half of all metatiles, then you draw the second half, so that you don't need to set the address excesively or keep switching the increment value.
Now that you understand the increment thing, think how it helps to draw half a metatile at a time. You have a lot to draw and can't spend too much time with each metatile.
Quote:
But still, how would you take a column, and turn it into an array?
I didn't get it.
Quote:
I have a lot of thinking to do, I guess.
Yeah, that's a good thing. I spent the whole weekend trying to figure out stuff for my game. Got a lot of great ideas I'll be implementing soon. Curiously enough I was thinking about map rendering, metatiles and scrolling, the same stuff we're talking about here (although I put some emphasis to attributes). =)
Memblers wrote:
Nope. Each metatile is 2 nametable columns, so just render each nametable column seperately with 32 increment all the way down.
See? That's the difference between someone who can explain things and someone who can't. I make a huge-ass post trying to explain this, then Memblers shows up and explains it clean and easy with one sentence (2, if you count "Nope.", but that's hardly a sentence). =)
What I meant by turning a column into an array was considering a 1 dimensional array/map as a 2 dimensional array, and taking a column from the 2 dimensional one, and turning it into a 1 dimensional array. Like say here:
00 03 23 54 13 64 34 72 74
43 74 34 64 23 53 23 75 27
00 03 23 54 13 64 34 72 74
43 74 34 64 23 53 23 75 27
00 03 23 54 13 64 34 72 74
43 74 34 64 23 53 23 75 27
00 03 23 54 13 64 34 72 74
43 74 34 64 23 53 23 75 27
I want to get the first column:
00
43
00
43
00
43
00
43
into an array: 00 43 00 43 00 43 00 43
So I can use PPU increment 32 and write that array to $2007, and get a column of meta tiles. How would I easily do such a thing?
Celius wrote:
How would I easily do such a thing?
Exactly as I described with the sample code. Let's take your sample array. You'll loop through the array, starting from the first metatile (00). So, this metatile translates to tiles:
Code:
00 01
10 11
You're interested in tiles 00 and 10, wich make the first half of the column, so, write those to your array/buffer.
Now, move to the next metatile, wich in your example is 9 metatiles later, but in the actual game it probably is 16 later (just as the PPU has to increment 32 to move down at the tile level, you have to add 16 to move down at the metatile level), right? So, add 16 to the pointer so you can read the next metatile. It is 43. This translates to:
Code:
43 44
53 54
Again, we're (and will be, until the column ends) interested in the first half, so write values 43 and 53 to the array/buffer (wich now has values 00, 10, 43, 53). Add 16 to the pointer to read the next metatile... and so on, so on.
By the end of the last metatile you'll have a clean 1D buffer to write lightning fast to the name table during VBlank.
Tip: since you'll already be running through all the metatiles, store their other half into another 1D buffer, so you can draw one after the other during VBlank. It doesn't get better than this.
EDIT: you'll won't get an array "00 43 00 43 00 43 00 43" because those are metatile numbers, and you'll draw tiles to the name tables, not metatiles. Well, I'm assuming those are metatile numbers, 'cause that's what you use to make the screen maps, and that's what you'll have aligned in grids like that.
I didn't follow your whole very complicated conversation, but the logical format for a metatile would be the following :
5 bytes per metatiles :
Byte 1 : Header (2 bits for colors, x bits for collision, x bit for layering effect and x bits for Z-planes)
Byte 2 : Topleft tile index
Byte 3 : Topright tile index
Byte 4 : Bottomleft tile index
Byte 5 : Bottomright tile index
More stuff could be reserved for trigger special events, treasure chests, altered parts of a map (those that can change if the player actived a specific event) and exits to another map.
Hey, Bregalad, that would be the logical choice for defining metatiles, but Celius seems to be aiming for maximun compression here. Apparently he's trying to fit code, maps and everything withing a 16kb bank, so I would think he actually needs to make things as compact as possible.
The metatile code defines the first tile used, and the other 3 are calculated from the first. It results in a limited number of metatiles and waste of pattern table space, but it's a very compact way to define metatiles. I don't know how he's handling the other attributes of the metatiles though, such as palette, collision, etc. Maybe it is all hardcoded based on the metatile index, I wouldn't be surprised.
I do metatiles in my game exactly as you described, each one using 5 bytes. I have some separate height maps used to make slopes and such, something you don't need in an RPG.
I think it is much clever to compress MAPS, not metatiles constituing it.
If you really want to save space, go for two group of metatiles (with hardcored numbers). For example metatiles 0-31 are 4 consecutive tiles, and metatiles 32-63 are custom tiles. I do that in my current project, but I don't think it would be fair in a large RPG.
Bregalad wrote:
I think it is much clever to compress MAPS, not metatiles constituing it.
To fit a
Final Fantasy game within 16kb of ROM, he needs
both. Let's see how that turns out. It might just work like this.
16kb of ROM ? What the ???
He said it himself.
Celius wrote:
I'd be able to have about 64 maps + code in 1 16k PRG bank.
Here:
http://nesdev.com/bbs/viewtopic.php?p=9079#9079
In a MAP editor, you'd need to only edit a map at time. Then save it in a .sav file, to rename it manually into a .bin file to include in a larger NES ROM. Scince the goal is to get the result in a larger ROM, I think metatiles doesn't have to suffer of stupid restrictions.
Simply encode all metatiles sets for a standard game plus a map editor in 16kb is decent.
I'm sorry, I think you all misunderstood me. 64 maps would fit in 1 16k PRG ROM. Not like all I need is 1 16k PRG ROM bank for all maps. That's gonna be like the biggest ROM hog of it all. I'm worried about space, because there's like a million maps. But I think it'll all be okay. There'd be like 5 banks for the world map. Thankfully, it's a really small world map. I have no idea how many other banks there'd be for other maps. Alot. But the ROM is going to be like maxed out in space. 512k for an MMC1 game with CHRRAM. Oh crap! I forgot about CHRRAM, that'll be a crap load of graphics data. I'm blabbering. But I just wanted to make that clear, that I was not saying I could fit all maps in 1 16k PRG bank... And the code I was referring to was the code to load the map in the bank, so I wouldn't have to bankswitch and slow things down. I wish I could compact it all in 1 bank...
Please calm down.
What you need is map compression, not meatile format reduction. In the opposite way, the best way your metatiles are made, the more tiles you'll save.
I think you have to first worry about how to make a working map engine before worring about the copression.
For the world map, I have an idea of how to store a very-large map, while being compressed.
If will work like a lot of maps large of at least 16x15 metatiles (so the size of a NES' nametable, you could do larger if you want (like 16x16 to simplificate calculations)). Then, while scrolling, you'll have room in SRAM to store 4 different small maps at the same time. Then when scrolling, the programm will fastly switch the map in SRAM to scroll it when needed. So each maps can be compressed, and you don't need RAM for all your world map at the same time.
The problem is that your maps have to be internally loaded dynamicly, so this couldn't show a huge frezee as the player walks on the world maps at certains scroll lines. I think it should decompressiong from ROM to RAM should be done in less than 1 frame (or if needed a bit more than 1 single frame).
For all other maps of any RPG, I doubt they would overflow the size of 32x32 metatiles (so the size of 4 world maps parts). If they do, have a larger memory buffer in SRAM.
About FFVII, you should programm the menu first I think, because it is a bit less tricky (while not being ideally much easier), and more game-specific. That will also force you to structure how to tidy items, materia, stats, etc... in memory.
This is why a level coding scheme that allows random access to any rows or columns is good. However, the ammount of compression you can gain from such schemes is limited, and they result in maps with a certain ammount of repetition, not the case for RPG's.
To be able to scroll freely, 4 screens must be loaded at all times. But everytime the camera crosses a screen boundary, horizontal or vertical, you have to load 2 new screens. A decompression routine that will output 240 or 256 metatiles/bytes per screen can eat a lot of time. Fortunately, RPG's do not scroll very fast, and a little delay might just go unnoticed.
So, in the case of an RPG I'd go with the compression option. Maybe you can have each screen compressed independantly, and have an array of pointers, pointing to the place in memory where each screen starts, so you know where to decode each one from.
But I'd agree with Bregalad. Try making your engine first, using an already decompressed map in WRAM. Do not worry about loading/unloading and compressing/decompressing screens yet. Just move the character around 4 screens directly placed in WRAM. When the engine works, figure out the storage and handling of the screens.
tokumaru wrote:
So, in the case of an RPG I'd go with the compression option. Maybe you can have each screen compressed independantly, and have an array of pointers, pointing to the place in memory where each screen starts, so you know where to decode each one from.
That is what I had in mind. So this fixes the problem of compression and or RAM usage, scince you only have 4 screens at the same time.
The real problem would be when you need to load 2 of them in memory. Yeah, a little delay may be unnoticed, but this shouldn't eat too much time.
Else, you could do the decompression in a sequence of different steps every frame, during a particular metatile is scrolling.
Bregalad wrote:
Else, you could do the decompression in a sequence of different steps every frame, during a particular metatile is scrolling.
That is not possible if you scroll in both directions. If scrolling was more limited, you could design the compression scheme so that data could be decompressed in a sequential way, relative to the scrolling direction, as part of the screen beeing decompressed will already be visible. But since you can approach a screen from any direction, that does not seem possible.
Unless more than 4 screens are loaded at a time. Maybe 16, arranged like a square. That way, as soon as the camera leaves one of the screens, the one that's 2 positions ahead begins to be rendered. I believe that having 16 loaded screens is the only way to perform progressive decompression of the screens. But that's just not practical... you'd need 4kb of memory for that and... well, it's just not practical.
EDIT: This post is pure crap. I don't know what I was thinking. Just ignore it.
Sorry I didn't folllow you.
On a side note, being too slow when loading can cause problems for example if you are scrolling like on an airship in FF1, 4 pixels at time.
Maybe you didn't mean sequencial like I meant. I think scince you have a buffer of 8 pixels, so 8 frames when scrolling 1 pixel at time, you can load a map in parallel with the programm that just scroll. Just save the pointers during decompression, and restore them the next frame. I see nothing impossible here.
Yeah, if you do it like you say it can work. You get that 8-pixel buffer by hiding the leftmost 8 pixels, right... As for scrolling vertically, your buffer is whatever the TV cuts off, certainly more than 8 pixels.
It's just that even when I try to think "RPG" I end up thinking "platform", wich is what I think about all the time, and they scroll tipically faster than RPG's. You are right, at low speeds like 1 or 2 pixels per frame an 8-pixel buffer is enough to decode 2 screens in separate "sessions".
The left border that can be clipped and the top/botttom 8 pixels of the screen aren't software buffers but hardware buffers, allowing you to scroll witout having gabrage in border.
However, on PAL TVs, the vertical 8 pixels buffer isn't valid.
But that isn't the problem here, I mean the 16 pixels that are from a metatile to another as a buffer, since you will load your data when scrolling to the last meatile of the last map, isn't it ?
i read nes documents.. what is the "clipping"???
Bregalad wrote:
But that isn't the problem here, I mean the 16 pixels that are from a metatile to another as a buffer, since you will load your data when scrolling to the last meatile of the last map, isn't it ?
Man, I'm just stupid. I just realised how dumb I've been the last few posts. You're absolutelly right. I've been thinking so much lately that my brain is just not working very well...
You know what I was thinking? since you'd decompress the new screen as the last metatile started to scroll in, that would mean that such metatile would still be visible at the other side, and overwriting it would cause glitches. But that's just wrong, you'd just be decompressing to RAM, the RAM map would be overwritten, not anything graphical. Well, don't mind me, I was just beeing stupid these last few days.
Yeah, if you decode the new screens as the last metatile of the current ones begin to scroll in you have quite some time to do the decompression. It may get a little complicated if the player decides to go back halfway through the decompression though. But then again, as this is an RPG you can simply force the player to move full metatiles at a time and the problem is gone.
I'll just think better before I post stupid crap about loading 16 screens at a time.
lord wrote:
what is the "clipping"???
You have the option to hide the leftmost 8-pixel column of the screen, not showing any sprites or background. That space is filled with color 0 if you do so. It is mostly used to hide glitches caused by scrolling horizontally using horizontal mirroring. Some glitches usually still show, though.
Since sprites cannot have negative HPos, it would disapear sudently on the left of the screen, so the leftmost 8 pixels clipping fixes this (sprites positions 0-8 act as negative).
I'm really sorry to bring up this really really old thread, but I need to figure something out, and it's about Final Fantasy's maps, so might as well not start another thread...
I can't think of a way to:
A. Arrange a 16x16 screen 2x2 metatile map in a 1 dimensional array.
or
B. Compress data
I think this is really difficult, because there's so much data, and it has to be in a 1 dimensional array, and I have to worry about how much space I'm taking up. I really don't think I can afford to have the world map of a Final Fantasy game take up 64k of PRG! That's rediculous. If I can compress it well, then it'd be good. Any suggestions?
Weren't you working on an implementation of RLE for this? RLE should work very well for this kind of map, where there is a lot of grass and such.
I'm not much of a FF fan, so I don't know exactly how the maps are, but usually, in RPG's, there's are a lot of repeated patterns, such as trees, houses, mountains, bushes, etc, so you could pull a SMB here and have your maps object-based, instead of (meta)tile based. Like, if you have the object "house" defined somewhere in your ROM, you could define a house anywhere in a screen with only 2 bytes (one to identify the house and another one to define it's position within the screen with metatile precision), and that's pretty compact for me.
About 50% of an average RPG map would be just water tiles, so RLE will be really efficient for this.
If this is not enough, just pick any existing compression format and try it.
Quote:
I'm not much of a FF fan
How crazy...
Bregalad wrote:
Quote:
I'm not much of a FF fan
How crazy...
Hehe! Well, I do like one of them, Final Fantasy VIII for the PSX, the only one I could play for more than 10 minutes.
I usually don't like RPG's (specially from the 8 and 16-bit era) because of the crazy ammount of pointless fighting to increase your stats. The fights are too damn repetitive, I can't stand that (I absolutely hate the random enemies that are everywhere, you can't walk!). It feels like freaking
Teletubbies to me, waaaaaaaay too repetitive.
I like the rest of the mood in these games, it's just the insane ammount of boring fighting that pisses me off. I'm not saying RPG's are bad, I know for a fact that some are very good, but for me, repetitive fighting is not fun, so I don't play them. I like action RPG's (is that what they're called?), where there is no fighting engine and everything happens in place.
RPGs is probably the genre that has the less changed from 8-16 bit aera and today. The genre isn't really much affected by 3D graphics and more powerfull systems, it is just perfected (in my opinion), while most other genre are ruined by 3D today (platformers.... Just play a recent Megaman X game and see what I mean)
Quote:
I absolutely hate the random enemies that are everywhere, you can't walk
What about RPGs like Crono Trigger, Final Fantasy Mystic Quest, Romancing Saga or Live a Live where battles aren't random ?
Quote:
Hehe! Well, I do like one of them, Final Fantasy VIII for the PSX, the only one I could play for more than 10 minutes.
In my opinion Final Fantasy VIII is the only one in the series wich doesn't absolutely rock, but also it is the only one wich is really annoying, wich its heavy G-Force cutscenes and annyoing messed up battle system.
I can undertand one doesn't like too "hardcore" RPGs like Dragon Quest, but Final Fantasy is so much innovative and perfected at each entries of the series...
If you don't love FF9 nor FF10 you're definitely crazy.