|
Post by elmer on Jun 13, 2018 2:19:47 GMT
I saw the code responsible for importing the mappy file and it was pretty simplistic, it basically selected a very specific section of the file (the tilemap) and ignored the rest. There's plenty of room for improvement there, that's for sure. We might even choose to say that HuC's .FMP import routine was "hastily-coded". Or we could just say that it does only what it needs to, and no more. The downside to using Tiled is you'll need to write your own BAT generation utility because you can't use the HuC #incmap stuff. Nope, you're right, you can't use its output in #incmap yet ... but its JSON format looks fairly parseable for anyone with reasonable C coding skills. As for 16-color, I believe Rover used 16-color because it's simpler to give people introductory things that are basic as hell. That's a very, very good point! Also, I thought HuC *was* a student project, that used Small-Cisms as a basis, and that was what OldMan was referring to when he called something a student project. HuC itself may well have been a student project ... I can't comment on that. But it was created by taking one of the many old Small-C source dumps, and then modifying it to add all of the wonderful PCE-specific stuff. You only need to compare the code here ... SmallC-85, to the HuC source to confirm that. NeoPaint is like the proper Windows equivalent of an Amiga paint program where GFX2 was never fully fleshed out. ... It's only 45$, also. Yep, Grafx2 is pretty primitive. But, as a programmer, it works nicely for all the stuff that I've wanted to do relating to PCE translation hacking. For me (and not for everyone), the DPaint/DAnim interface is really easy to use. For artist folks who want friendlier capabilities, then something like NeoPaint is a very viable option. But so is ProMotion, and that package is arguably more suited to game development, and it is also $6 cheaper at $39. I presume you really want 240 color tiles Yes sir, ideally I'd have one palette providing bitmap that can be used to define 15 palette indexes of 16 colors (but I must be honest and thought I had 16 indexes to work with for tilemaps, good to know for current in progress level as I have blocked out 16!) You do have 16-palettes to play with ... each with room for 16-colors. BUT ... the 1st color in each palette is treated as transparent by the hardware, so you only get to define 240 different colors (that's 16 palettes * 15 usable-colors-per-palette). I am the worst at grasping this stuff, so I am not surprised to hear there are several error ("lots" was expected ), but it makes sense that I am using the wrong combination of functions - thanks for taking the time to look into my horrible excuse for code! HuC's #inctile_ex function just stores a bunch of information before the regular tile data, and then you use set_tile_data(char *tile_ex) with a single parameter (the pointer to that stored information) and it'll set everything up automagically. There is really no big difference between doing things that way, or using HuC's #inctile and then using set_tile_data(char *tile, int nb_tile, char *ptable, char type). The #inctile_ex version will probably just produce slightly shorter code.
|
|
|
Post by theoldman on Jun 13, 2018 7:00:03 GMT
".... using set_tile_data(char *tile, int nb_tile, char *ptable, char type)."
Sorry, I don't seem to have that function. I do have set_tile_data(char *tile, int nb_tile, char *ptable ), however. That allows me to supply a table of palette indexes (not palettes), one per tile number, so I can use more than 1 palette in my maps. Provided, of course, I'm willing to type all of the palette indexes in.
And I believe #inctile_ex() only allows a single palette for all the tiles.
"You only need to compare the code here ... SmallC-85, to the HuC source to confirm that."
No one ever said students don't cheat. It could be based on code that was based on a version of SmallC-85. But you do agree that it is Small C, without all of the full C functionality, correct?
|
|
|
Post by Arkhan on Jun 13, 2018 17:22:13 GMT
Nope, you're right, you can't use its output in #incmap yet ... but its JSON format looks fairly parseable for anyone with reasonable C coding skills. Yeah, tweaking it probably isn't awful. I don't know if Mappy sees regular updates anymore. I had emailed the guy about his annoying import bugs and got no reply. It was annoying, so I decided no more Mappy after Inferno. Yeah, thats effort lol. I think HuC might have some other... "isms" that might not be SmallC/OldAssC related. It's got .. alot of ... things. I don't disagree there. With shades of gray. If you modify the palettes too much (for high color images), the UI palette also changes, and you can sometimes be left with a UI you can't even see/read. It's funny, but also annoying. Also some buttons were never fully implemented, so it's missing features, unfortunately. I don't recall that the Windows version fixed it. At that point it's really about which one has better buttons/bells/whistles. NeoPaint had nice dithering and palette editing tools, and support for old formats. I don't know how well Promotion jives with those. I'd like to see Grafx2 just get finished/updated, but that's probably not happening. The DOS one hadn't changed in over a decade, and the Windows one only recently(ish) got restarted IIRC. Might as well just setup DPaint in an Amiga emulator at that point, lol
|
|
|
Post by elmer on Jun 13, 2018 22:18:42 GMT
".... using set_tile_data(char *tile, int nb_tile, char *ptable, char type)."Sorry, I don't seem to have that function. I do have set_tile_data(char *tile, int nb_tile, char *ptable ), however. Yep, I changed the longform set_tile_data() function to have a 4th parameter in the new HuC. It was part of the change/upgrade/fix/whatever-you-want-to-call-it that was needed to remove the 2-bytes of annoying junk that HuC (and not PCEAS) was adding between every binary file that you .incbin/.incpal/.incchr/.inctile/.incmap. It is documented in the "whats.new" file. And I believe #inctile_ex() only allows a single palette for all the tiles. That's right, #inctile_ex() is pretty limiting. I'd definitely recommend using the basic #inctile() instead for more flexibility. But you do agree that it is Small C, without all of the full C functionality, correct? Errr ... yep. That's why I keep on mentioning Small-C and posting links to Small-C-related stuff. HuC is one of the many modern decendants of the Small-C legacy ... as is CC65, BTW. I suspect that we're saying the same things, and it's just that our way of saying them is causing a misunderstanding. Anyway, HuC being based upon the whole Small-C legacy is the point of a lot of Uli's work on improving the whole HuC experience for new developers. He took the advances (ANSI function syntax, structures, etc) that had been made after Small-C85 came out (probably from that same codebase that I linked to) and grafted them into the HuC codebase, and then went on to add more improvements and fixes from that point. I think HuC might have some other... "isms" that might not be SmallC/OldAssC related. It's got .. alot of ... things. Yeah, there are a bunch of PCE-specific language features that the original HuC authors added. They did an absolutely great job in making it a usable system. At that point it's really about which one has better buttons/bells/whistles. NeoPaint had nice dithering and palette editing tools, and support for old formats. I don't know how well Promotion jives with those. Yep, at the end of the day, it's all about everyone's individual preferences. Folks can use whatever they want. Gredler seems to be liking to use ProMotion, but that doesn't mean that everyone would, nor that anyone has to change their existing workflows.
|
|
|
Post by gredler on Jun 14, 2018 11:33:16 GMT
Alright fellers, tonight I put some time into doing my best to clean up my code, and looking this over seems like it should be working, so now I think I need to revert to default values in mappy and see if that's why the tilemap isn't showing up correctly? Or am I still missing something on code side #include "huc.h"
#incbin(levelmap,"pce_tilemap_palette_tests.FMP");
#inctile_ex(leveltiles, "pce_tilemap_palette_tests.pcx",0,0,16,16,0);
#incpal (levelpal0, "pce_tilemap_palette_tests.pcx");
main()
{
set_map_data(levelmap);
set_tile_data(leveltiles);
load_tile(0x1000);
load_map(0,0,0,0,16,16);
load_palette(0,levelpal0,1);
}
|
|
|
Post by Arkhan on Jun 14, 2018 16:27:44 GMT
use the debugger in mednafen and see if your tiles are even loaded into VRAM, lol.
you can use the > and < to cycle palettes and take a look.
If the tiles aren't even showing up, that's a problem.
I usually call load_tile/vram before setting map and tile data. .. I also haven't used HuC's versions in a bit, but that looks like it... should do something.
|
|
|
Post by gredler on Jun 14, 2018 17:34:23 GMT
use the debugger in mednafen and see if your tiles are even loaded into VRAM, lol. you can use the > and < to cycle palettes and take a look. If the tiles aren't even showing up, that's a problem. I usually call load_tile/vram before setting map and tile data. .. I also haven't used HuC's versions in a bit, but that looks like it... should do something. Word dude will try debugging vram when I get home, thanks for the suggestion. I will re-arrange my code to have the set map and tile data after calling the loads - that makes sense!
|
|
|
Post by theoldman on Jun 14, 2018 17:41:14 GMT
Where did the sizes for set_map_data go?
try -> set_map_data( levelmap, 16, 16);
and while I'm at it, what version of windows are you running? What version of Huc?
|
|
|
Post by gredler on Jun 14, 2018 18:08:01 GMT
Windows 10, I think I am on the latest version elmer pushed out at one point - is the version # for HuC noted somewhere in the documentation or something? I will add the sizes for set_map_data back in, I must have been confused about the arguments. I changed the inctile back to _ex and so I removed the other arguments from the set_map_data Update: I was able to get my tilemap loading in and visible so I can start getting to the bottom of a decent workflow; I've attached an updated zip to this post with my current test state - I am now officially blocked from doing anything but re-importing the PCX into Mappy and re-laying out each individual tile. The tilemap looks great in ProMotion, great in Mappy, and the PCX looks fine to me, but because of something mappy is doing (looks like shifting all indexes by 1) when the map shows up in game it's all offset by 1 using the blank tile where tile number 1 should be and offset down the line.
|
|
touko
Punkic Cyborg
Posts: 106
|
Post by touko on Jun 15, 2018 7:51:57 GMT
This is strange, in fact your example is exactly how importing the .pcx image should be displayed, it seems that your mappy BAT be not taken in account .
|
|
|
Post by cabbage on Jun 15, 2018 15:16:28 GMT
#inctile_ex can be used to define multiple palettes for a single tileset...
inctile_ex : This instruction includes data for character patterns from a series of .pcx files, and sets up for the "new style" of 16x16 scroll-tiling.
#inctile(identifier_name, "filename_1", begin_x, begin_y, col, row, pal_idx1, \ "filename_2", begin_x, begin_y, col, rox, pal_idx2, \ "filename_n", begin_x, begin_y, col, rox, pal_idxn ); Extract row rows and col columns of 16x16 tiles starting at position (begin_x, begin_y), and using the stated pal_idx from filename_1 (etc.), assembling them as a single list of tiles in memory, available for use in the map and scrolling functions
gredler: don't make that first tile all black or mappy will skip it and mess up your alignment step 1- recolor that blank tile or something
step 2- import the tileset again in mappy so it doesn't skip that tile step 3- use the "Create map from a big picture" useful function
|
|
|
Post by gredler on Jun 15, 2018 17:43:13 GMT
#inctile_ex can be used to define multiple palettes for a single tileset...
inctile_ex : This instruction includes data for character patterns from a series of .pcx files, and sets up for the "new style" of 16x16 scroll-tiling.
#inctile(identifier_name, "filename_1", begin_x, begin_y, col, row, pal_idx1, \ "filename_2", begin_x, begin_y, col, rox, pal_idx2, \ "filename_n", begin_x, begin_y, col, rox, pal_idxn ); Extract row rows and col columns of 16x16 tiles starting at position (begin_x, begin_y), and using the stated pal_idx from filename_1 (etc.), assembling them as a single list of tiles in memory, available for use in the map and scrolling functions
Cabbage is the best, thanks so much dude!! That palette setup you did there is EXACTLY what I was hoping for!!! That's a huge step forward for exporting directly from ProMotion without touchup to the grafx (no more need to split the images apart by palette, and load each individually for those palettes!!!) Mind blowing step forward, thanks so much! gredler: don't make that first tile all black or mappy will skip it and mess up your alignment step 1- recolor that blank tile or something
step 2- import the tileset again in mappy so it doesn't skip that tile step 3- use the "Create map from a big picture" useful function Thanks for the clear information and taking the time to make and post the example, but I am familiar with these steps and was what I was talking about when I said I was hyperbolic in that you don't need to lay out each tile individually by hand in this case because the tile map and image match almost identically. Because they match you can use the create from big picture in this instance to re-build the map, but in most practical applications the tile map image and tile map layout in mappy are not 1:1, but rather the tile map is made of a much fewer repeating tiles, but this gradient example just happens to allow us to place the tilesmap from a big picture. The issue I am bringing up is the inability to use map data exported from ProMotion, which would be awesome! I was hoping doing the .map export from ProMotion into Mappy to save out a .fmp would be the solution, but the tile 0 mixup seems to ruin any chance of using the map data out of promotion. I think this is moot if we get STM support in HuC because this is a byproduct of opening a exported .MAP from ProMotion in Mappy to save out a HuC usable .FMP - which is why I made this test and posted it to the thread. I think it would be worth while if I made a more plausable test case rather than this gradient example, but I wanted to post something to get the ball and conversation started between artists and programmers going So right now the workflow if using ProMotion is: - Create tile graphic data in promotion with cleanly laid out palette sets of 16 colors with color 0 all being identical. -Export tile map .PCX -Edit .pcx in some art program to add graphical data to tile 0 so that mappy does not skip it when assigning the tile indexes from the pcx -import the pcx into mappy and layout your tilemap and save out .fmp -compile rom with pcx and fmp I don't see how I can use tile layout data from ProMotion as of this post, so until some HuC support changes it will be PM>Gimp/PSP/PS>Mappy loop, which isn't the end of the world Thanks again for the palette information though cabbage - that is immediately useful!!
|
|
|
Post by theoldman on Jun 15, 2018 18:27:09 GMT
Congratulations! It works!
So that blank tile at the start of the pcx is a result of exporting the graphics from ProMotion? I know Mappy will always make tile 0 'blank', but IIRC that's not a problem.
Just to satisfy my curiosity, how does it look if you load the tiles at 0x0fe0 ?
........................................................................................ Cabbage: yes, you can use mutiple files to build a tileset with multiple palettes. Or even different pieces of a single file, for that matter. Each file in the #inctile() will still have a single palette.
It's a bigger problem than you think, though. The tiles are numbered according to the order they are included, iirc. So they don't match any realistic order, either in the image or in mappy. There is a way (I forget how right now) to define a palette index array, and set the palettes. It's just a pain to setup when you have 200+ tiles....
And this is why we use our own filter to do this stuff......
|
|
|
Post by gredler on Jun 15, 2018 18:38:04 GMT
Congratulations! It works! Thank you! It was changing set_map_data to ( levelmap, 16, 16); You fixed it, I just typed your words! So that blank tile at the start of the pcx is a result of exporting the graphics from ProMotion? I know Mappy will always make tile 0 'blank', but IIRC that's not a problem. Yes - the blank tile at the start of the PCX is a result from how grafx export from ProMotion. So the way Promotion exports grafx, and the way Mappy imports them don't play nice together. The artist needs to add graphical data to tile 0 for mappy not to remove it, and since promotion's map data treats tile 0 like tile 0, and mappy ALWAYS ADDS a tile 0, you can't use the tilemap data from mappy since the indexes are offset by one (which is why Arkhan says he has code to -1 the indexes mappy is trying to load in some instances.) Just to satisfy my curiosity, how does it look if you load the tiles at 0x0fe0 ? I am going to be very busy for the next few days, but I will try to upload results of a test with me trying to load the tiles at 0x0fe0.
|
|
|
Post by theoldman on Jun 15, 2018 20:19:55 GMT
Wait a minute.
"Yes - the blank tile at the start of the PCX is a result from how grafx export from ProMotion" Okay. So ProMotion -always- exports an all black tile in the .pcx .....
"The artist needs to add graphical data to tile 0 for mappy not to remove it". Ah! but we want mappy to remove it. Or use it as mappys tile 0 (I don't care which)
" you can't use the tilemap data from mappy since the indexes are offset by one" Not true. Yes, mappy does offset things by 1. But that doesn't mean we can't use it.
........................................................................................................................
And that's why I asked about changing the load address.
Here's what I *think* is happening.... Promotion exports the graphics, with a blank tile at the beginning. (Tile 0) When mappy imports the graphics, it sees the first tile as blank, so it uses it as tile 0.
Now you create the map in mappy, and save it. I know mappy/Huc does something to the tile numbers at this point. That blank tile? It becomes index -1 (honestly)
SOoooo. If you load the pcx 1 tile lower, things should work out. I think.
I'll play around with it a bit more, and make sure.
(And just fyi, I found the mappy sources. I can re-use their create new map function to make a blank map. Then I can use their save map function to write it out, and be assured it should be loadable in mappy. Once that's up and running, its no problem to copy the tile indexes into the right place in mappy. There's a bit more to it than that, though. And I'm slow. We will talk more about that later.)
|
|