PCEngineFans.com - The PC Engine and TurboGrafx-16 Community Forum
Tech and Homebrew => Turbo/PCE Game/Tool Development => Topic started by: Bonknuts on July 26, 2014, 06:33:32 PM
-
Curious how many of you pce homebrew peeps use Mappy?
-
I do--HuC's .FMP support is awfully convenient.
-
You use LUA scripts in the mappy editor, to extend to PCE related functions?
-
I use it now more than I used to because Windows 7 doesn't like my VB6-based custom map editor.
-
We use it. It's the best way to quickly smash out your maps and then convert them to something useful.
-
To Mappy or not to Mappy that is the question?
I think Mappy is a great little monster. You can load an image of tiles and draw with the tiles that you loaded in giving you some great optimization.
Now there is a little bad ass in town called ImagetoPCE this guy will take your image and optimize the similar tiles for you.
My thought is I would prefer to build my map in an image editor and then convert it to the 3 Bin files DATA, BAT, and PAL ImagetoPCE generates.
EX: Have a complex image and break into tiles load it into mappy and reassemble it.
EX: Have a complex image load it into ImagetoPCE and have it optimize the image for you :)
Currently I have downloaded lots of sources from the HUC site to see if any show case loading backgrounds from BIN files (No luck). I have also have tried quite a bit modifying Obey examples to see if I can get the image I have exported to display (No Luck). Finally I have read the original Image toPCE thread on this forum although an example is offered it is already compiled.
Does anybody know what it takes to load and display the data in the BIN files generated from ImagetoPCE with Huc? ](*,)
-
Just #incbin the three files it spits out, and do something like this:
load_vram(0x2000,datafile,0x2800);
load_bat(0x0,batfile,32,20);
load_palette(0,palfile,15);
Adjust according to your labels, the amount of data you're using, etc.
-
Does anybody know what it takes to load and display the data in the BIN files generated from ImagetoPCE with Huc?
Haven't played with ImagetoPCE, But displaying images on the pce is basically a 3 step process:
1) Load the tile data (the tile graphics). I believe load_chr() and/or load_tile() do that. Which you use depends on how the data is actually compiled in.
2) Load the palette data.
3) Load the BAT data. The are several ways to do this; Not sure what the functions are called, but there is one to load only the BAT area. Generally, I prefer the VRAM function, though. BAT is located at 0x0000.
Some words of advice on getting things to work:
Load the tile data first. Then you can look in the mednafen debugger and see a) IF it loaded correctly, and b)Where it loaded. If you don't see any tile stuff in mednafen, try hitting the [TAB] key to change palettes. You might be using an all-black palette :)
When you load the palette data, make sure you load the correct palette for the tiles. It's easy to load the sprite palette area instead of the tile palettes :)
Once you load the BAT area, you should see -something- on the screen. If you don't, check the palette. Your BAT information may be expecting a specific range of palettes, and/or a specific location for the tile data.
As for finding problems: A hex editor is invaluable for that. You can open the data files with it, and see where things are and usually figure out what went wrong. HuC has all the information you need to decode how the various data blocks should be set up. It will take some looking through the docs, but it is there.
The good news is, once you do it and get it to work, you can wrap it in a function call, and not have to worry about it too much :)
-
:dance: I can't thank you guys enough! I really appreciate the help. I have posted some modified Obey Brew source that incorporates the ideas you guys have helped me with! It should compile provided the gfx files are in place...Obey Brew's "Part 4 - Playing With Yourself" will give you the Bonk GFX and you'll need to process a 256x256 image through ImagetoPCE.
I had an indexed colour 256x256 image that was less than 16 colours. (Only required one palette)
In imagetoPCE I specified 1 palette and the optimize flag as there where several repeated tiles. I used the three 3 files that it spat out and the rest is history. My goal is to eventually do a larger image but man was it satisfying when the image displayed on the screen! I have been using Hugo but I am defiantly excited to switch it up to mednafen (Hoping to run it using a .bat file from the Huc command prompt to make for an easier testing environment)
Things to pay attention too
#incbin(scene_data,"Star_DATA.bin");
#incbin(scene_bat,"Star_BAT.bin");
#incbin(scene_pal,"Star_PAL.bin");
load_vram(0x2000,scene_data,0x2800);
load_bat(0x0, scene_bat,32,32);
load_palette(0,scene_pal,1);
scroll(0, bonkx, 0, 0, 223, 0xc0);
#include "huc.h"
#incspr(bonk,"bonk.pcx",0,0,2,2);
#incpal(bonkpal,"bonk.pcx");
#incbin(scene_data,"Star_DATA.bin");
#incbin(scene_bat,"Star_BAT.bin");
#incbin(scene_pal,"Star_PAL.bin");
main()
{
int j1, bonkx;
bonkx = 104;
init_satb();
spr_make(0,104,153,0x5000,FLIP_MAS|SIZE_MAS,NO_FLIP|SZ_32x32,0,1);
load_palette(16,bonkpal,1);
load_vram(0x5000,bonk,0x100);
load_vram(0x2000,scene_data,0x2800);
load_bat(0x0, scene_bat,32,32);
load_palette(0,scene_pal,1);
satb_update();
for(;;)
{
vsync();
j1 = joy(0);
if (j1 & JOY_LEFT)
{
spr_ctrl(FLIP_X_MASK,FLIP_X);
bonkx--;
}
if (j1 & JOY_RGHT)
{
spr_ctrl(FLIP_X_MASK,NO_FLIP_X);
bonkx++;
}
scroll(0, bonkx, 0, 0, 223, 0xc0);
spr_x(bonkx);
satb_update();
}
}
spr_make(spriteno,spritex,spritey,spritepattern,ctrl1,ctrl2,sprpal,sprpri)
int spriteno,spritex,spritey,spritepattern,ctrl1,ctrl2,sprpal,sprpri;
{
spr_set(spriteno);
spr_x(spritex);
spr_y(spritey);
spr_pattern(spritepattern);
spr_ctrl(ctrl1,ctrl2);
spr_pal(sprpal);
spr_pri(sprpri);
}
TheOldRover and TheOldMan are you guys responsible for Obey Brew? That site is so awesome! I ain't the best coder but enjoy it immensely the way the site is written really speaks to me and I have found it extremely helpful!
-
I developed ObeyBrew.com but it wouldn't be even half what it is without people like TheOldMan and Arkhan. It still has a ways to go before it's finished though.
-
TheOldRover and TheOldMan are you guys responsible for Obey Brew?
Not me. Rover, maybe.
............................................
Just for future reference: You should have spr_make either use globals or constant values in the function; you're losing a lot of cycles by having a load of parameters (which aren't really needed) that
get pushed and popped. I do admit, though, it is a one-time call, so that may not matter to you :)
Also, you should do the satb_update() right after the vsync(); that will cause the sprite table transfer to occur during the video blank period, and avoid any tearing and such caused by writing to VRAM during the active display period.
So why are you using the scroll() function, anyway? Just curious...
-
He is using some code from one of the earlier obeybrew tutorials. It's not optimal code but it's functional.
-
Heh, I totally went in here thinking Bonknuts was thinking of porting Mappy to the PCE, & was going to voice how much I'd love to see Mappy Land, as I loved that game as a kid. My bad! :D
-
It's not optimal code but it's functional.
Understood. I was just wondering why use scroll() at all. Is he trying to implement a scrolling background? If so, why move the sprite (via srp_x() )? Doing both means both the background and sprite move, giving an effective 2 pixel movement, which can complicate other things....
While I admit that there is no single way to write 'correct' code, most programs are improved by looking at what was written (and worked) and trying to better it. Nobody gets it right the first time on their own :)
-
I think he may just be experimenting for now... this code barely does anything at all outside of the basics. He may just be learning the ropes.
-
Oh, and on the spr_make thing... that is a convenience function I wrote for obeybrew.com that I sometimes use in my own prototyping. When I know things work, I remove the function calls and replace them with proper code. It's just a simplistic way of getting sprites onto the screen, but it creates a ton of overhead and is pretty inefficient so it's not intended to be used regularly.
-
PD: Hah!
HyperFighting: ImagetoPCE (that recent app?) is a completely different function than Mappy. It's more for creating BG from a pic, where as Mappy is a tilemap editor (along with brushes and other stuffs).
I convert my Mappy files directly to raw PCE files; tilemap, tiles, and palette. I've discovered a few tricks with using the editor, over the years. I wrote a conversion app (FMP2PCE... very original name :B ) to handle more complex stuff from the FMP format. I can clip any x1/x2, y1/y2 of a FMP tilemap. I can use embedded palette info for tiles (it knows what tiles belong to which subpalette number based on encoded color differences in the 36 increment/steps). I can offset the starting palette number. I can set the vram offset for the tiles. I can output the map in vertical or horizontal strips. 16x16 maps are converted to meta-tile and tiles divided down into 8x8. The map data can be prep'd for LUT use or no LUT use (map entry =tile_num*4, meta-tiles are offsets of 0,+1,+2,+3). You can choose other BG 'layers' in the FMP as collision maps(provided in byte or nibble output format), and optionally provided an offset subtract for that BG layer (to start with a cooked offset of '00' rather than the real tile number associated in the BG layer entry). Etc.
I can create really large maps, that all use the same tile setup, and then chop them into 'screens' and save them individually, etc. Having a collision overlay, without having to tie it directly to tiles, is nice.
But digging through the format, FMP format supports quite a few things that the editor does not. Each tile can have a whole range of attributes applied to it. Unfortunately, you need either the paid for Pro version, or you need to write LUA scripts to access that (from what I could tell).
As an editor, Mappy isn't exactly great. But it's decent for basic stuffs. And with a few tricks, you can supplement a few features manually. Since I have a crop function, I actually use large maps, with all the tiles I'm using in vram - at the start/top of the map. This allows me to format the order of the tiles (keeps them from being random), good for setting up animation or swapping them out, etc. And some blank area, to allow me to setup 'brushes' and save them, etc.
Off topic: The thing about vsync and updating the satb in vram; VDC satb auto dma happens right after the last visible line of the display (of the VDC, not the VCE). It doesn't happen again until the next frame. You won't have enough time to update the real SAT registers in the VDC (which the DMA does). So your sprite updates will be delayed by one frame. If you're syncing them to the background, you'll need to delay updating it as well. You'll see a good number of early PCE games that get this wrong (where sprites are supposed to be part of the BG layer); they get out of sync usually be one pixel (single pixel scrolling).
I handle this by putting my vsync 'flag', in the hsync area (quite a number of scanlines before real vsync interrupt). This lead time allowed me to get gamepad input, do some responses, then update SATB in vram. When vsync does hit, it'll update it. Though you can't always fit collision and other code in this gap of time. Other method was delay the BG updates to sync with sprites, using a request system. That gives me the whole active display area to workout all game logic in time, without having to try and fit it vblank (regardless of sync issues or not). And the last method was more advanced; setting up the VDC to do two 'frames' per VDC frame. This allows you to have a SATB at the start of active display (or have it underneath a top border/stat window). For a while, I thought manually triggering SATB update via writing to the SATB destination reg immediate triggered SATBDMA on the VDC side, but my tests showed that wasn't the case and only issued a one time request at the end of the next frame.
How do you guys handle this? Have you gotten the same or different results, regarding SATBDMA syncing/frame reference?
-
Heh, I totally went in here thinking Bonknuts was thinking of porting Mappy to the PCE...
Me too, then they started in with all this code gobbledygook and I fell asleep. :mrgreen:
-
Hey guys I must say it is honor get some help from you guys. I really appreciate you guys taking the time to help me out. The Obey website rocks!!!! I feel like I have very evolved state machine for my main character at this point I want to eventually have something significant to show you guys.
I am looking for an alternative to Mappy and I think ImagetoPCE might just be the ticket. I should have removed the bonk stuff in the code I posted as it over complicates matters. I just wanted to give a beginner a quick snippet that they could work with when importing a map data created by ImagetoPCE. The ultimate goal is to be able to scroll to anywhere in the map I thought I was on the right track with the scroll command.
Bonknuts - I realize ImagetoPCE is intended to create a background from a picture but technically you could play by the rules work within the 16 pals and draw a bunch of repeating tiles and ten export it out of ImagetoPCE and it will do the optimizations (determine the repeating tiles etc).
It's like your favorite image editor is your Mappy and ImagetoPCE is your means to output your map.
The FMP stuff is crazy interesting I will definitely look into this as well (My head almost exploded it will take me a minute to comprehend all of this craziness)
I still have to run more tests to see if I can get scrolling happening on a larger map and figure out how to properly increment hex values when importing larger map data. :D
TheOldRover - I am definately using the spr_make command with my existing code and am using #incspr to load my .pcx files based on the examples on the Obey site. Now that I know this not the best approach I will have to investigate further.
Thanks again guys the more you think you know you don't.
-
Heh, I totally went in here thinking Bonknuts was thinking of porting Mappy to the PCE...
Me too, then they started in with all this code gobbledygook and I fell asleep. :mrgreen:
I also had my dreams crushed!
-
You are on the right track with the scroll() function... TheOldMan was just curious as to why you were doing both a scroll() and a sprite move at the same time. Normally in games, you use one or the other but not both, unless you have a lazy camera setup.
EDIT: OK, I realize that that may have been confusing. :) For moving your player character around, you usually only scroll the screen or move the sprite in the same frame, but not both in the same frame.
-
I am looking for an alternative to Mappy and I think ImagetoPCE might just be the ticket. I should have removed the bonk stuff in the code I posted as it over complicates matters. I just wanted to give a beginner a quick snippet that they could work with when importing a map data created by ImagetoPCE. The ultimate goal is to be able to scroll to anywhere in the map I thought I was on the right track with the scroll command.
Bonknuts - I realize ImagetoPCE is intended to create a background from a picture but technically you could play by the rules work within the 16 pals and draw a bunch of repeating tiles and ten export it out of ImagetoPCE and it will do the optimizations (determine the repeating tiles etc).
It's like your favorite image editor is your Mappy and ImagetoPCE is your means to output your map.
The FMP stuff is crazy interesting I will definitely look into this as well (My head almost exploded it will take me a minute to comprehend all of this craziness)
ImagetoPCE isn't an editor though, therefore it's not an alternative. It's a conversion app. You could use it along side Mappy (Mappy can export into one large bitmap output file). Mappy isn't my favorite, it's just easy and convenient as an editor, and the format of FMP is clean and easy to use (with conversion tools, etc). But yeah, Mappy is a tilemap design tool. Image2PCE is an image conversion tool.
Image2PCE is pretty decent, but I have other conversion tools that do the same. Image2PCE is an alternative to those, but it also has some downsides (sometimes I don't want lossy down sampling of colors, or I need other specifics like forcing a certain color to BG #0, etc). The more apps, the better.
-
if I can get scrolling happening on a larger map....
A 2 screen x 2 screen setup isn't too hard to do; you just have to find the right constants for initializing the screen, and load the BAT correctly. The trade-off is, it uses 4K of VRAM (about 1/4, iirc).
The other choice is to check out the map_ functions; though I haven't played with them, they -should- let you scroll around on a very large map.
How large of a map are you talking about?
-
My master plan is to have a map that is 3 screens high and as long width wise as I can make it.
The game would have a top area (used for collecting secrets)
A middle area (used for the majority of the gameplay)
A bottom area (where the player falls to when he falls though a crack).
Each screen would tile seamlessly so that they could repeat and repeat forever.
I managed to figure out how seamlessly repeat the same screen over and over again by messing with the move_map(whichway) function that is used in the Obey Brew Tutorial Part 7 - The State Of The State (Using the Mappy example provided)
I then wanted to see if there was a way I could export an entire map I created through photoshop to a PCE format and this is where the ImageToPCE came in.
Today I tried exporting a 512x512 image from ImageToPCE. I was unsuccessful when attempting to get it to scroll vertically...The image just kept repeating after the first screen.
I tried several attempts at implementing the map stuff similar to the format seen below... I realized that set_tile_data(leveltiles); is supposed to get three parameters if #incchr_ex is not used but I couldn't get it to compile correctly.The basic is idea is displayed below it is terrible freehand stuff but should describe gist of how I am trying to make it happen.
#incbin(levelmap,"Star_DATA.bin");
#incbin(leveltiles,"Star_BAT.bin");
#incbin(levelpal0,"Star_PAL.bin");
main()
{
set_map_data(levelmap, 64, 64);
set_tile_data(leveltiles, 64, 1);
load_tile(0x1000);
load_map(0, 0, 0, 0, 34, 28);
load_palette(0, levelpal0, 1);
for(;;)
{
if (input)
mapx++;
mapy++;
load_map(mapx,mapy,mapx,mapy,1,SCR_H);
}
scroll(0,mapx, mapy, 0, 223, 0xc0);
I am beside myself after reviewing the spr_make function.
spr_make(spriteno,spritex,spritey,spritepattern,ctrl1,ctrl2,sprpal,sprpri)
int spriteno,spritex,spritey,spritepattern,ctrl1,ctrl2,sprpal,sprpri;
{
spr_set(spriteno);
spr_x(spritex);
spr_y(spritey);
spr_pattern(spritepattern);
spr_ctrl(ctrl1,ctrl2);
spr_pal(sprpal);
spr_pri(sprpri);
}
At a quick glance this function appears to use ints so I figured certain variables could be modified to be chars and that would optimize the function a little bit but I fear the real optimization comes from using different function calls. The entire function is based on function calls so this would mean using different more efficient function calls to create a sprite?
I would like to have a top score displayed at the top of the screen. I noticed when my background scrolls so does my text!? I can't seem to get it to sit still
The more you think you kno the more you don't know. Sorry for the ramblings and thanks for taking interest in this sad state of affairs.
-
OKay, okay. One at a time :)
I was unsuccessful when attempting to get it to scroll vertically...The image just kept repeating after the first screen.
look at ...doc/Huc/clibref.txt. There is a function set_screen_size(char size) that changes the size of the -virtual- screen (not the displayed screen). The scroll function uses the size of the virtual screen for scrolling, iirc. And of course, the default value is 32 tiles wide, to match what you see. Change it and you should be able to do a 512 pixel (64 tile) scroll quite easily.
When we did PP, I -think- I used a 64x64 tile screen.
I realized that set_tile_data(leveltiles); is supposed to get three parameters if #incchr_ex is not used but I couldn't get it to compile correctly.
...set_tile_data(leveltiles, 64, 1);....
The third parameter is a char *, which is an address. try set_tile_data( leveltiles, 64, levelpal0 ) and see if that works.
At a quick glance this function appears to use ints so I figured certain variables could be modified to be chars and that would optimize the function a little bit but I fear the real optimization comes from using different function calls. The entire function is based on function calls so this would mean using different more efficient function calls to create a sprite?
Using chars as parameters only sorta works. The get pushed as ints anyway.
The real optimization actually comes from not using parameters to spr_make(). If you are using a constant in the call, move it into spr_make() and get rid of the parameter. Most of the values passed in are not going to change, so making them constants speeds things up....
If you really want to know, here's how I believe it works:
When you call spr_make(), all of the parameters get pushed onto the 'C' stack. That's not the same as the hardware stack - in fact it's pretty in-efficient if you look at the assembler code.
Then, in order to pass them along to the functions inside of spr_make(), they have to
1) Be read from the 'C' stack - that code is slow as well
2) Be pushed back onto the 'C' stack, so the functions can find them.
If you move the actual constants or global variable inside spr_make(), you avoid the overhead of pushing the arguements for the call, and the reading from the stack just to push them again. :)
I would like to have a top score displayed at the top of the screen. I noticed when my background scrolls so does my text!?
Yep. You need more than 1 scroll area: one for the unmoving text, and one for the moving part of the map. Luckily you can have up to 4 scroll areas.
BUT there's a catch: Everything goes in the BAT for display. So when you load your map, you have to make sure you leave the text area alone.
The more you think you kno the more you don't know.
We were all beginners at this once. Tackle one problem at a time. Before you know it, all this stuff will be if not easy, at least more understood :)
-
Thanks sooo much! I will vanish into the shadows and get to work. As soon as I have some good news to report I will post it.
P.S. Playing Bonks Revenge tonight I was shocked and amazed at how many characters and backgrounds and items it has! There must be a secret to cramming gfx into the little card! I must be ahead of myself. Just saying that game really has alot going on! Bonk is a man of many animations! Long live Hu-cards! I love holding ten games in my hand just like a small stack of credit cards crazy!
-
Well, back to Mappy topic. I'm creating a few more things/options for the fmp2pce, and was wondering if there's anything you guys would use if I release this tool publicly (with source code).
Maybe it's best if I show off some features first. FMP format is fine, but HuC doesn't take any advantage of it. Raw output is a better option IMO.
-
Oh, and on the spr_make thing... that is a convenience function I wrote for obeybrew.com that I sometimes use in my own prototyping. When I know things work, I remove the function calls and replace them with proper code. It's just a simplistic way of getting sprites onto the screen, but it creates a ton of overhead and is pretty inefficient so it's not intended to be used regularly.
I was searching how to do some image2pce loading, and I found this comment. I've been WAY over abusing spr_make, and its bloating the crap out of my code.
Could you suggest how to do this less bloated code?
-
I do, I like it. Wish tiles could be mirriored, and the importing of multiple tilemap images was easier.
-
I do, I like it. Wish tiles could be mirriored, and the importing of multiple tilemap images was easier.
How would you handle tile mirroring when it's not supported by the hardware? You'd have to "stream" rows and/or columns of tiles at a time for that kind of support. It's doable, and realtime flipping is fast with a simple small LUT, but the scroll engine itself becomes more complex; you're scrolling a bitmap image that happens to wrap at tilemap arbitrary defined boundaries.
You can handle merging/importing sections or layers via an external app. The Mappy FMP format is pretty easy to work with.
-
How would you handle tile mirroring when it's not supported by the hardware? You'd have to "stream" rows and/or columns of tiles at a time for that kind of support. It's doable, and realtime flipping is fast with a simple small LUT, but the scroll engine itself becomes more complex; you're scrolling a bitmap image that happens to wrap at tilemap arbitrary defined boundaries.
You can handle merging/importing sections or layers via an external app. The Mappy FMP format is pretty easy to work with.
Thanks for the heads up, I had no idea it was a hardware limitation! I am not code savvy so I had assumed that it was a undeveloped element of HuC and or Mappy, apologies if my ignorance was surprising hahaha :) Good to know and not get my hopes up. You probably would've been very shocked when I asked DK of we can rotate sprites and tiles, that's an even bigger can of worms right? :P modern development has left me wasteful and liberal woth my design ideas!!
I currently have workarounds for the import process into mappy; from mappy to game I hand the content off to DK, so I wouldn't know much about the benefits of the fmp resulting file - the contents of which look like gibberish when o open it.
Out of curiosity, what external applications do you use for processing the multiple images? I was thinking of trying to write a Python script that would help me, just grab the images in a folder and combine them vertically to make a new image that mappy can accept to save me the trouble of doing that by hand. I am currently just making my tilemap, saving it as 16 color limited chunks and using the combined map in mappy to generate my fmp.
-
Well, in case you write any apps that directly edit FMP files, here's this:
//
// FMP format
// +0 (INT) 'FORM'
// +4 (INT) file size (big endian). Starting from byte 8.
// +4 (INT) 'FMAP'
//
// +4 (INT) 'MPHD' map header.
// +4 (INT) sizeof (big endian).
// +4 (INT) version # 16bit.16bit (lil' endian).
// +4 (INT) (WORD/WORD) (lil' endian) width in tiles (lil' endian) / height in tiles (lil' endian).
// +4 (INT) unknown.
// +4 (INT) (WORD/WORD) (lil' endian) tile width in pixels (lil' endian) / tile height in pixels (lil' endian).
// +4 (INT) unknown. Last byte is possibly bit depth. Seems to be '8' for palettized projects (lil' endian).
// +4 (INT) (WORD/WORD) (lil' endian) # of tiles (lil' endian) / # of tiles (lil' endian).
// .
// .
// +offset (INT) 'EDHD' <something> header.
// +4 (INT) sizeof/len (big endian)
// +4 (INT) unknown.
// +4 (INT) number of colors used for tiles (lil' endian).
// +Data (INT) unknown data.
// .
// .
// +offset (INT) 'EPHD' <something> header.
// +4 (INT) sizeof/len (big endian).
// +Data ( ? ) unknown data.
// .
// .
// +offset (INT) 'LSTR' header. Layer String names.
// +4 (INT) sizeof/len (big endian).
// +4 (INT) ??? Seems to be fixed to 0x00000008
// +4 (INT) Number of layers
// +Data ( ? ) Layer text names.
// .
// .
// +offset (INT) 'CMAP' palette data.
// +4 (INT) sizeof/len (big endian). Seems to be fixed in size regardless if <256 color entries.
// +Data (CHAR) R/G/B palette data. 3 BYTE segments.
// .
// .
// +offset (INT) 'BKDT' - unknown. Appears to be tile attributes.
// +4 (INT) sizeof/len (big endian).
// +Data ( ? ) unknown data.
// .
// .
// +offset (INT) 'BGFX' - Tiles data/pixels. Pixel depth is 8bit for palettized projects.
// +4 (INT) sizeof/len (big endian).
// .Data ( ? ) Variable in size. Palettetized tiles are BYTE/pixel format.
// .
// .
// +offset (INT) 'BODY' - map data. The primary layer.
// +4 (INT) Length of map data in bytes.
// .Data ( ? ) Note: FMP 1.0 map data is a tile number. FMP 0.5 map data is a tile number * 64.
//
// +offset (INT) 'LYRn' - map data. n = layer #.
// +4 (INT) Length of map data in bytes.
// .Data ( ? ) Note: Additional layers after 'BODY'.
//
Though beware there are internal structural differences from FMP 1.0 and FMP 0.5. I always work with FMP 1.0, but I never use those files directly with huc or pceas, so I have no idea how it handles either version directly. I always convert them myself and output them as raw data.
I just add features as I need them:
printf("FMP to PCE map converter. Ver 1.0.6-a");
printf("\n -Usage: fmp2pce <source.ext> -option ");
printf("\n -o<n> <n> is the subpalette offset for the tilemap. 1 digit hex");
printf("\n -l<n> <n> is the length of output palette block; (n+1)*16. 1 digit hex");
printf("\n -v<n> Tile offset in vram (kWORDs). 3 digit hex. Default is 100h");
printf("\n -s Output the tile map in vertical strips instead of horizontal");
printf("\n -c<n> Output byte-wide collision map for <n> layer.");
printf("\n -e Use embedded color encoding to build palette map data in tilemap");
printf("\n -x1<n> Clip map: horiztonal start position. Value must be a 4digit hex");
printf("\n -y1<n> Clip map: vertical start position. Value must be a 4digit hex");
printf("\n -x2<n> Clip map: horiztonal end position. Value must be a 4digit hex");
printf("\n -y2<n> Clip map: vertical end position. Value must be a 4digit hex");
printf("\n -m16 Convert 16x16 map for 'no LUT' expansion. ");
printf("\n -m8 Convert 16x16 map into 8x8 map. ");
printf("\n -to<n> Offset collision tile # (tile# - n, saturated floor at 0x00/0x01).");
printf("\n ^-Note: <n> is 3 digit hex max. Large values create 0/1 maps.");
printf("\n -z<name> Up to 10digits. Results in <name>.ext for file outputs.");
printf("\n");
printf("\n '15 Tomaitheous");
printf("\n");
Out of curiosity, what external applications do you use for processing the multiple images? I was thinking of trying to write a Python script that would help me, just grab the images in a folder and combine them vertically to make a new image that mappy can accept to save me the trouble of doing that by hand. I am currently just making my tilemap, saving it as 16 color limited chunks and using the combined map in mappy to generate my fmp.
Usually just photoshop and use layers from bitmap images. Unless it's something complex, like subpalette arrangements, then I just write a quick command line app for it. Though I really want to get away from mappy. I have a makeshift subpalette support for it, but a native PCE map app would be much better.