|
Post by gredler on Jun 15, 2018 20:35:59 GMT
Correct, the first tile in every tilemap image that ProMotion spits out is always color 0,0 solid image (just like Mappy).
It sounds like your load address suggestion might be just the ticket, so I look forward to trying that address change.
As little as I know about using the HuC functions I know even less about addresses and how loading and unloading vram works, so any tutorials or threads to pull on to learn vram handling would be greatly appreciated btw.
|
|
|
Post by theoldman on Jun 15, 2018 20:42:29 GMT
Okay, I actually tried it. It doesn't work. Nothing I tried with the load addresses worked. Okay?
But oddly enough, changing the set_map_data() call to
set_map_data( levelmap+1, 16, 16 ) does.
Wierd..... Not something I would use in a program until I figured out why it worked, though.
|
|
|
Post by Arkhan on Jun 16, 2018 4:56:58 GMT
Yeah, you can USE mappy's data, as long as you remember to -1 stuff, lol.
This is all such a clusterfuck.
wtb Tiled library.
lol
|
|
|
Post by elmer on Jun 17, 2018 20:15:28 GMT
FYI, I've just sent gredler a test version of HuC that reads both PNG and ProMotion's STM files, too.
|
|
|
Post by theoldman on Jun 18, 2018 6:08:41 GMT
"FYI, I've just sent gredler a test version of HuC that reads both PNG and ProMotion's STM files, too. " Good to know. Now people won't have to wait.
|
|
|
Post by gredler on Jun 18, 2018 15:10:53 GMT
I just saw this advancement and can't believe this is already implemented!! Wow!
I am so excited to check this out, and will report back as soon as I have tried it out!
Thanks so much Elmer; the time you spent on this will save me, and probably many other artists down the road, so much time and frustration. I think it can improve the quality of the art I can do because I can spend more time detailing and shading, and less time trial and error implimenting and reworking.
RIP Mappy, it was fun while it lasted, on to bigger and better workflows!!
|
|
|
Post by elmer on Jun 18, 2018 17:39:31 GMT
I just saw this advancement and can't believe this is already implemented!! Wow! Ahhh ... thanks, but as I mentioned in PM, it isn't fully implemented yet. PNG file reading and STM file reading are there, and appear to be working fine (which is why I sent it to you for extra testing), but the code to automatically read which palette number an individual spr/chr/tile uses in a 256-color image, has not yet been implemented. That'll take some deeper messing around inside HuC/PCEAS than actually just adding the new file formats.
|
|
|
Post by theoldman on Jun 19, 2018 21:31:44 GMT
Quick brain dump, so I don't forget..... Mappy has no problems loading a map with only the tile information. (ie, no graphics) Promotion simple maps contain 0 information about the tile sizes. There's no easy way to know if it's 8x8 or 16x16 pixel tiles. If you +1 to the promotion .map data, then things work out correctly. Ie, it displays right. Unfortunately, that screws things up when mappy displays it. I know there's a way to correct for that, somewhere, in mappy. I don't think there is an easy, general purpose way around the palette problem. If you re-build the palettes via a program, they won't match the original palettes. If you use the original palettes, there's no information in the tile data about which palette to use. It may turn out to be easier just to specify the palettes by hand...
|
|
|
Post by gredler on Jun 19, 2018 21:45:32 GMT
Thanks for sharing the dump.
Is there a way to assign defined palettes to ranges of tiles? Say tiles 0 through 127 use pal0, and 128 through 255 use pal1? Etc
|
|
|
Post by theoldman on Jun 20, 2018 2:25:49 GMT
"Is there a way to assign defined palettes to ranges of tiles.."
Oddly enough, I was thinking this through, and realized I don't have to re-build the palettes, I just have to check the pixels in the tile and see if they all belong to the same palette. So yeah, I have an idea to work on now; it will probably read the pcx file and spit out a text file to be #included, with the palette #s for each tile. And of course, error messages if all the pixels in a tile are not in the same palette.
And while I'm typing, let me ask: Is it worth the bother to try and load the tiles into the .fmp file I generate? That might (would?) require some research into how gfx are set up in mappy, but might be worth it.
And for whoever asked, mappy actually supports .bmp files. And .png, if you have it set up right. There are some problems using them in HuC, I assume, but mappy has no big problem with it that I can see....
|
|
|
Post by elmer on Jun 20, 2018 6:56:26 GMT
Is there a way to assign defined palettes to ranges of tiles? Say tiles 0 through 127 use pal0, and 128 through 255 use pal1? Etc Yes, there is. David Michel added "#inctile_ex" into HuC for that very purpose. And, if you don't want to use that, you can define your own palette lookup table for the tileset and pass it as the 3rd parameter in set_tile_data(). I just have to check the pixels in the tile and see if they all belong to the same palette. Yeah, that's kinda the whole point in splitting your 256-color palette into 16 logical palettes of 16-colors, and then having your artist work within that scheme. ProMotion will even do the checking for multiple-palettes-within-a-tile errors for you. ... Or you can just use PSP/Neopaint/Grafx/whatever and do the checking and conversion with an external program, like the one that you mention, and just include the raw data after the conversion. PCEAS already supports this kind of logical-palette functionality in its .inbat feature but, for some reason, nobody ever extended the concept to .incchr, .inctile or .incspr. And when #inctile_ex functionality was added, it was done at the HuC level, and not the PCEAS level ... which is kinda annoying (at least to me, since I'm trying to extend the functionality, and want it to work for assembly language programmers as well). When I'm done, PCEAS should support that kind of automatic logical-palette-detection-within-a-256-color image for most of the functions (when using PNG files for the graphics, but not when using PCX files, so that I don't break backwards-compatibility with old graphics files).
|
|
|
Post by theoldman on Jun 20, 2018 22:58:56 GMT
Gredler: I hate to tell you this, but I think your palettes are screwed up. Even when I look at the original.png file (in gimp), the colors are all over the place.
I suspect you need to sort the palettes by tile in ProMotion. And make sure slot 0 of each palette is 0
Will check more into it later tonight.
|
|
|
Post by gredler on Jun 20, 2018 23:05:54 GMT
Gredler: I hate to tell you this, but I think your palettes are screwed up. Even when I look at the original.png file (in gimp), the colors are all over the place. I suspect you need to sort the palettes by tile in ProMotion. And make sure slot 0 of each palette is 0 Will check more into it later tonight. Yes the test files I uploaded are messed up, sorry! The color 0 is not consistent. I am going to be working on this tonight using Elmer's provided variant of HuC, #inctile_ex, and correct palettes, to get a final working prototype setup! Edit Attached is the fixed set of files to test with. A few things to note for users trying to go with ProMotion: The TurboGrafx-16 template uses the rainbow-333 palette which seems wrong. While these colors appear to display correctly in HuC the palette is borked as old man had mentioned; the colors 0, 16, 32 etc should all be the same "transparent" color", so that is wrong with the rainbow 333 palette. also the palette uses only ~90 unique colors. For these new test files I made sure that a few things were true; 1) uses at least 241 total colors 2) uses at least 255 tiles 3) does not have more than 16 colors per tile 4) simplify tile arrangement to better correspond with palette arrangement (tiles 0,15 now only use colors 0,15, and so on) I believe I met all of those criteria with these files, so now I will next work in coding my .c file to load all of the palettes instead of just the first palette, but I have to sleeep! tomorrow night, I code!
|
|
|
Post by theoldman on Jun 21, 2018 20:56:51 GMT
Congratulations. It looks good. Looks like all that's needed is some copy/paste to fix the #inctile_ex() call, and to change the load_palette() call to load 16 palettes (instead of just 1). Looking forward to seeing it in 240+ colors. (But I don't envy you fixing that #inctile_ex() call )
|
|
|
Post by gredler on Jun 22, 2018 8:07:19 GMT
I got pretty close, but still a bit off! The farthest right column of the tiles looks off, and it doesn't appear to be a palette issue but I could be entirely wrong; Notice on the right now some tiles have black boxes over them? I don't understaaaaaand, but pretty cool progress.. Too bad this only works on such rigidly planned palette/tile layout (16 rows of 16 tiles using 1 of 16 palettes...) #include "huc.h" #incbin(levelmap,"pce_tilemap_palette_tests.FMP"); #inctile_ex(leveltiles, "pce_tilemap_palette_tests.pcx",0,0,16,1,0,\ "pce_tilemap_palette_tests.pcx",0,1,16,1,1,\ "pce_tilemap_palette_tests.pcx",0,2,16,1,2,\ "pce_tilemap_palette_tests.pcx",0,3,16,1,3,\ "pce_tilemap_palette_tests.pcx",0,4,16,1,4,\ "pce_tilemap_palette_tests.pcx",0,5,16,1,5,\ "pce_tilemap_palette_tests.pcx",0,6,16,1,6,\ "pce_tilemap_palette_tests.pcx",0,7,16,1,7,\ "pce_tilemap_palette_tests.pcx",0,8,16,1,8,\ "pce_tilemap_palette_tests.pcx",0,9,16,1,9,\ "pce_tilemap_palette_tests.pcx",0,10,16,1,10,\ "pce_tilemap_palette_tests.pcx",0,11,16,1,11,\ "pce_tilemap_palette_tests.pcx",0,12,16,1,12,\ "pce_tilemap_palette_tests.pcx",0,13,16,1,13,\ "pce_tilemap_palette_tests.pcx",0,14,16,1,14,\ "pce_tilemap_palette_tests.pcx",0,15,16,1,15); #incpal (levelpal, "pce_tilemap_palette_tests.pcx");
main() { set_map_data(levelmap,16,16); set_tile_data(leveltiles); load_tile(0x1000); load_map(0,0,0,0,16,16); load_palette(0,levelpal,16);
}
|
|