BeNjaMMiN
Cooltrainer
Jerry Beans Man!
Posts: 109
|
Post by BeNjaMMiN on Mar 22, 2010 20:50:29 GMT -5
ok im a noob so i really dont know how to do that.
|
|
|
Post by Tauwasser on Mar 23, 2010 9:36:57 GMT -5
What, repointing? I'm pretty sure lots of people here know how to do that o.o Or are you talking about Tile->Pal assignment?
cYa,
Tauwasser
|
|
BeNjaMMiN
Cooltrainer
Jerry Beans Man!
Posts: 109
|
Post by BeNjaMMiN on Mar 23, 2010 15:59:01 GMT -5
tile -> pal assignment
|
|
|
Post by Tauwasser on Mar 24, 2010 8:26:32 GMT -5
That's really simple. Just look at the data. Each half-byte (4 bits) determines the palette for one tile. That's the number range 0-F, or the "right side" and the "left side" of each byte. For instance, for tileset one, this data ist 50 15 22 10 11 66 66 66So the only trick here is that the lower 4 bits represent Tile 0, the upper Tile 1 etc. So when thinking in "byte halves", they are switched. Look at the attachment, it contains the first 0x10 tiles, whose palettes are encoded in 0x08 bytes (because 0x10 * 4bit = 0x40 bits = 0x08 bytes). So here goes: TileNo | PaletteNo | Palette description | 00 | 00 | gray palette | 01 | 05 | brown palette | 02 | 05 | brown palette | 03 | 01 | red palette | 04 | 02 | green palette | 05 | 02 | green palette | 06 | 00 | gray palette | 07 | 01 | red palette | 08 | 01 | red palette | 09 | 01 | red palette | 0A | 06 | roof top palette | 0B | 06 | roof top palette | 0C | 06 | roof top palette | 0D | 06 | roof top palette | 0E | 06 | roof top palette | 0F | 06 | roof top palette |
Now compare to the attachment, and you'll see this holds. Now, in Crystal, the special thing is that you will have to use the values 0x08 thru 0x0F to represent Palettes 0x00 thru 0x07. So basically, all tiles that are in VRAM1 have to get an assignment >=0x08. This is because bit3 actually represents which Vram part (0 or 1) to take the tile from. Also, as I mentioned earlier, you will have to fill the 0x20 tiles gap between the tilesets (the tiles that are below tileset part one in Vram). cYa, Tauwasser Attachments:
|
|
|
Post by Masterge77 on Mar 28, 2010 8:42:31 GMT -5
I'm trying to figure out how to extend some tilesets in Crystal that are not extended by default, such as the gyms.....
|
|
|
Post by Tauwasser on Mar 29, 2010 13:14:17 GMT -5
Just insert bigger gfx, and repoint the block and collision data if you want to add onto them. By definition, all tilesets are "extended", just not all really use more than 0x60 tiles.
cYa,
Tauwasser
|
|
|
Post by Mateo on Apr 24, 2010 16:18:49 GMT -5
Ok, so I finally got around to trying this out and I've noticed a problem in the english version. While it loads the tileset graphics properly, and allows use of more blocks, when you try to use tiles in the extended part, the game just loads the corresponding tiles from bank 1. I applied it to a clean gold (u) rom, using the appropriate patch for that language, so I assume this is an oversight in one of the routines.
|
|
|
Post by Tauwasser on Apr 24, 2010 20:29:23 GMT -5
Ok, so I finally got around to trying this out and I've noticed a problem in the english version. While it loads the tileset graphics properly, and allows use of more blocks, when you try to use tiles in the extended part, the game just loads the corresponding tiles from bank 1. I applied it to a clean gold (u) rom, using the appropriate patch for that language, so I assume this is an oversight in one of the routines. Did you follow the guideline of adding 0x08 to the Tile->Pal assignment? cYa, Tauwasser
|
|
|
Post by Mateo on Apr 25, 2010 0:34:41 GMT -5
That would be it. My mistake. Thanks for pointing it out.
|
|
|
Post by Tauwasser on Apr 25, 2010 6:24:41 GMT -5
That would be it. My mistake. Thanks for pointing it out. Yeah it's stupid that it needs that info in there, but for conformity with Crystal I didn't change that. Technically, you could make the routine so that it works as in G/S (with map-bank-dependent palettes) and still find the right VRAM bank via interpreting the high bit of the tile info. Still, map-bank dependent palettes can be handled via the roof palette as well. cYa, Tauwasser
|
|
|
Post by Mateo on Apr 25, 2010 14:33:31 GMT -5
Ah well. As long as it works, no sense in changing it ya know? haha. But yeah, that fixed the problem right up, and I haven't noticed any other bugs, just the fact that when the screen fills with black for a battle, the screen parts over the extended tiles will with white, but that's no big deal. I can live with that. Much better than the sprites disapearing/ tiles being replaced with the font/other ridiculous bugs that come with HyperHacker or MeanMrMustard's hacks.
|
|
|
Post by Tauwasser on Apr 25, 2010 15:02:21 GMT -5
Ah well. As long as it works, no sense in changing it ya know? haha. But yeah, that fixed the problem right up, and I haven't noticed any other bugs, just the fact that when the screen fills with black for a battle, the screen parts over the extended tiles will with white, but that's no big deal. I can live with that. Much better than the sprites disapearing/ tiles being replaced with the font/other ridiculous bugs that come with HyperHacker or MeanMrMustard's hacks. Argh! See, that's stuff I need to know I forgot that stuff like that happens lol! Will be fixed asap. cYa, Tauwasser
|
|
|
Post by Mateo on Apr 26, 2010 1:31:36 GMT -5
Good deal. I tested it to see if any of the known bugs from the other hacks happen, and I haven't seen them do it, so that's a good sign. Like I say, the only one I've seen is the one I mentioned about it filling with white on those tiles. Good job mate! Lookin forward to the next release when that will be fixed as well
|
|
|
Post by koolboyman on Apr 26, 2010 5:19:40 GMT -5
This is looking pretty good. I think I'll use it for Prism once this is officially declared "Glitchless"
|
|
|
Post by Tauwasser on Apr 28, 2010 17:15:49 GMT -5
Ok. The battle intro bugs should be fixed. Tiles will now be loaded to the right spots in RAM and palettes will be correctly assigned for both VRAMs' tiles.
See first post for all info.
cYa,
Tauwasser
|
|