It is currently Mon Oct 23, 2017 5:32 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 45 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
 Post subject:
PostPosted: Sun Feb 05, 2006 9:35 pm 
Offline
User avatar

Joined: Sun Jun 05, 2005 2:04 pm
Posts: 2131
Location: Minneapolis, Minnesota, United States
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Feb 05, 2006 10:00 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10068
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Feb 05, 2006 10:07 pm 
Online
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3471
Location: Indianapolis
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Feb 05, 2006 10:23 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10068
Location: Rio de Janeiro - Brazil
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). =)


Top
 Profile  
 
 Post subject:
PostPosted: Sun Feb 05, 2006 10:29 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10068
Location: Rio de Janeiro - Brazil
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). =)


Top
 Profile  
 
 Post subject:
PostPosted: Sun Feb 05, 2006 10:33 pm 
Offline
User avatar

Joined: Sun Jun 05, 2005 2:04 pm
Posts: 2131
Location: Minneapolis, Minnesota, United States
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?


Top
 Profile  
 
 Post subject:
PostPosted: Sun Feb 05, 2006 10:59 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10068
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Feb 06, 2006 10:07 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7235
Location: Chexbres, VD, Switzerland
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.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Feb 06, 2006 10:43 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10068
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Feb 06, 2006 10:57 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7235
Location: Chexbres, VD, Switzerland
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.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Feb 06, 2006 11:04 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10068
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Feb 06, 2006 11:47 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7235
Location: Chexbres, VD, Switzerland
16kb of ROM ? What the ???

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Feb 06, 2006 12:04 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10068
Location: Rio de Janeiro - Brazil
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


Top
 Profile  
 
 Post subject:
PostPosted: Mon Feb 06, 2006 1:44 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7235
Location: Chexbres, VD, Switzerland
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.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Feb 06, 2006 4:13 pm 
Offline
User avatar

Joined: Sun Jun 05, 2005 2:04 pm
Posts: 2131
Location: Minneapolis, Minnesota, United States
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...


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 45 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 6 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group