Two images one Mappy - adhering to 16color per image

[Gredler]

Numbskull noob needs nfo, sorry for the incoming silly questions 


How exactly do I split the images that I export from Mappy into multiple images so that the colors are limited to 16 per image?


I've created an image keeping each 8x8 tile to under 16 colors, and made sure that there are no more than 16 different combinations of colors. There are 34 total colors in the image right now, and I am estimating after this point, but there will be probably ~5 palettes to achieve this image. I did this so that it would be "easy" LOL 


I got all the images into Mappy, and I created a tile based image using the Mappy tools. When I exported the art that accompanies the FMP all of the tiles combine into one 34 color image - which I obviously can't use. 


I am stumped on how to export from Mappy while adhering to 16 color limit per image. Although I can restrict that manually using my Photoshop>Gimp workflow, once it gets into Mappy everything gets combined again. 


The HuC tutorial(http://obeybrew.com/crashcourse6.html) provides PCX images appear to have been exported by mappy, both images included in the archive (http://obeybrew.com/tutorial6files.7z) that are provided are limited to 16 colors, but I was not yet able to find documentation on how to export 1 Mappy image into multiple PCX images limiting them to 16 colors per image. Even the export I receive from Mappy now is a BMP that I manually convert to PCX.


It was late when I hit this road block, and I haven't deeply researched it yet today, but I thought rather than running in google circles I would reach out to the obey brew guru's and see if there's a simple solution - there's got to be a "make game" button somewhere, amirite?

[Arkhan]

I don't recommend exporting Mappy images for use in anything. 

Use it for tile map generation.   Keep track of the image color palette index usage yourself with a real art program.

[Gredler]

I don't recommend exporting Mappy images for use in anything. 

Use it for tile map generation.   Keep track of the image color palette index usage yourself with a real art program.

Thanks for the super quick reply sir, but I am afraid I didn't explain my confusion well enough.

I created the tile maps in Photoshop, converted the color table in Gimp, and import them into Mappy. So my palettes and images are created outside of Mappy.

When I import the tiles into Mappy it appears that all of the images I imported get combined into one that one "tile set", there is not designation between the images that were imported.

So I only need to provide the programmer the original images and the FMP? Does Mappy create UV coordinates based on the originally imported images? It appears to combine them into one image then create new coordinates.

[Arkhan]

I don't recommend exporting Mappy images for use in anything. 

Use it for tile map generation.   Keep track of the image color palette index usage yourself with a real art program.

Thanks for the super quick reply sir, but I am afraid I didn't explain my confusion well enough.

I created the tile maps in Photoshop, converted the color table in Gimp, and import them into Mappy. So my palettes and images are created outside of Mappy.

When I import the tiles into Mappy it appears that all of the images I imported get combined into one that one "tile set", there is not designation between the images that were imported.

So I only need to provide the programmer the original images and the FMP? Does Mappy create UV coordinates based on the originally imported images? It appears to combine them into one image then create new coordinates.

Original PCX files with the palettes + indexes + pixel usage correct, and FMP file from Mappy.

That's all I ever did.  That export crap in Mappy is mental.

[Gredler]

pixel usage correct, and FMP file from Mappy.

Sick, I was totally over-complicating this then. I really need to make my own test environment / level where I can load in palettes and images and get a better understanding of what's under the hood, thanks man.

My only remaining question here is what do you mean by pixel usage correct? Do you mean my color index's for each palatte per image matching correctly?

Image 1 would have a palette of 0,1 = 0 0 0 and all of the black pixels in my image was exported as blacking being the 01 color in the table within gimp?

That export crap in Mappy is mental.

Glad I am not alone in assuming this was the case. Everything was going smooth until I imported the second image into Mappy and it appeared to have combined them. I assumed it was generating a new texture atlas based on the combined images that were imported. I exported the image from mappy and it was exactly that, so I Was like fuuuuuuu "how do I make sure that the FMP is mapping correctly to the original image," as it appears to create it's own texture map when imported. The lack of documentation on this is a little scary, but understandable.

Thanks again for taking the time to help the rookie out, it's greatly appreciated

[elmer]

Traditionally, you'd manually partition your 256 color palette into 16 sub-palettes of 16 colors each, i.e. index 0-15 = palette 0, index 16-31 = palette 1, etc.

That's a "logical", or "imaginary" partition ... the graphics program (Photoshop, GIMP, Dpaint, etc) just sees that you're editing a 256-color image.

Then it is up to the artist to make sure that each 8x8 tile is drawn in pixels from just one sub-palette.

At that point, it's trivial to export the image so that the the tiles themselves just come use the bottom 4-bits of the index, and the palette number for the tile comes from the top 4-bits of the index.

What you are doing in Photoshop and GIMP, makes it sound like you are screwing up that "traditional" workflow, and instead expecting that the conversion tools will automatically figure out how to split your image into palettes.

Some tools can do that, but AFAIK, they're mainly for static-image conversion and not map-making.

*************

You don't seem to quite understand the map-making process, I think that you may need to do some more research. "Mappy" is a very traditional (and powerful) old-style map editor.

There are no "UV" coordinates, or "texture atlas", you're still thinking in terms of modern 3D hardware and texture mapping ... this old hardware is sort-of-similar, but different.

A "tile" is NOT just a polygon that's rendered by looking at the original texture image that you are loading into "Mappy". It is pretty-much exactly the opposite of that.

When you are importing an image into Mappy, it's doing exactly what it is designed to do ... it is splitting up the image into tiles, and then adding them to the current tileset.

Then you re-create the image by piecing together all those small 8x8 tiles back into something that looks like the original image ... just like a jigsaw.

There is only one tileset, and one map at any one time. I don't know what you're expecting to happen.

*************

What you end up giving to the programmer depends upon their workflow and conversion tools.

In the early days, we'd use Map Editor programs (like Mappy), that allow an artist/level-designer to create "tiles", and then place those tiles on a "map".

Later on, we'd just have the artist/level-designer create a huge bitmap, and then automatically convert it into a tileset/map. The conversion process would throw out error messages when the artist broke the rules (i.e. used more than 1 palette within a tile, or used too many tiles within a map).

For example, my old converter outputs a "processed" image that highlights any "bad" tiles in the bitmap, and lets the artist visually see where the problem is that they've got to fix.

But it's sill based on an artist manually partitioning the palette themselves.

I believe that Bonknuts has a tool that will take in a random 256-color image and automatically convert it into 16-palettes and restrict the colors used in 8x8 tile regions.

But that's not how normal game art was done, because the palettes were usually seen as a precious and limited resource, and managing how many palettes (and which ones) were used in an image was an important part of the design work.

For example ... you normally dedicate certain palettes/colors for the status-panels/text-output/etc.

[Arkhan]

pixel usage correct, and FMP file from Mappy.

Sick, I was totally over-complicating this then. I really need to make my own test environment / level where I can load in palettes and images and get a better understanding of what's under the hood, thanks man.

My only remaining question here is what do you mean by pixel usage correct? Do you mean my color index's for each palatte per image matching correctly?

Image 1 would have a palette of 0,1 = 0 0 0 and all of the black pixels in my image was exported as blacking being the 01 color in the table within gimp?

That export crap in Mappy is mental.

Glad I am not alone in assuming this was the case. Everything was going smooth until I imported the second image into Mappy and it appeared to have combined them. I assumed it was generating a new texture atlas based on the combined images that were imported. I exported the image from mappy and it was exactly that, so I Was like fuuuuuuu "how do I make sure that the FMP is mapping correctly to the original image," as it appears to create it's own texture map when imported. The lack of documentation on this is a little scary, but understandable.

Thanks again for taking the time to help the rookie out, it's greatly appreciated

by pixel usage correct, I mean:

Say you have a tile that is 16x16.   Pixel #2 (top row, second from left) is using color 3 of the palette.

This means, it will always use color 3 of whatever palette you assigned to it.

So as long as you supply these images, you'll be OK.

Mappy doesn't deal in palettes really.  It's just a tile map.   It splits your tileset into numbered tiles and the file basically says "use these tiles from this image".

[Gredler]

by pixel usage correct, I mean:

Say you have a tile that is 16x16.   Pixel #2 (top row, second from left) is using color 3 of the palette.

This means, it will always use color 3 of whatever palette you assigned to it.

So as long as you supply these images, you'll be OK.

Mappy doesn't deal in palettes really.  It's just a tile map.   It splits your tileset into numbered tiles and the file basically says "use these tiles from this image".

Rad, that's what I had hoped and is manageable for sure, thanks again for all of your help sir, hopefully I can pay it forward someday

[Arkhan]

a good visual representation of this would be to open the VRAM looker atter in Mednafen, and press the <> keys to cycle palettes.

The indexes used never change.  Just the palette that is referenced. 

Atlantean for example, the buildings are all technically the same tiles.  I just applied a darker palette to the back row to make them look further away.   Paul didn't have to draw new tiles.  It just works that way because both palettes used have sensible indexes, and the tiles use them.

yay

[Gredler]

a good visual representation of this would be to open the VRAM looker atter in Mednafen, and press the <> keys to cycle palettes.


The indexes used never change.  Just the palette that is referenced. 


Atlantean for example, the buildings are all technically the same tiles.  I just applied a darker palette to the back row to make them look further away.   Paul didn't have to draw new tiles.  It just works that way because both palettes used have sensible indexes, and the tiles use them.


yay

Nice! Thanks for the tip!


Mappy is the cause of my frustrations - I have to be missing some sort of step here.


Last night when I was trying I was using MapTools>Useful Functions:>Create Map from Big Picture. This was nice because it deleted any duplicate tiles I had in the source image, and placed the tiles for me how the source image had them laid out. I then modified and cleaned up the map, and ran into the issue cutting the result into multiple palettes.


Tonight I tried creating the separate source images, with pre-defined palettes. 4 images with separate palettes. My issue right now is that when I use File>Import... the blocks get overwritten by the second import. I'm now searching for information on how to import multiple source images to create a single map.


The tiles I am attempting to tackle or more closely akin to the background coral in Atlantean. This was a nearly full screen image that I am trying to optimize by instancing the duplicate elements through tileing. I am taking what was a 256x256 image and trying to cram it down into roughly half that size. and will need to use about 4 palettes.



Cabbage gave me a great explanation just now which makes a lot of sense to me which is basically maintain coordinates of each tile even though they're split into smaller bits

So I need to create paletted texture atlases with the intention of combining them for mappy,

PCX paletted tilemap 1 A 1 2 3 ...
PCX paletted tilemap 2 B 1 2 3 ...

Then create a BMP with those stacked into one image, import that into mappy and create the map layout, and then export the FMP. The code then is setup to compensate for the image's coordinates  in the same way the fmp is looking for.


My confusion was how to reference all the tiles at once in mappy, but in code still reference multiple images, so this representation made a lot of sense to my tiny brain

Unfortunately I did not design my level art with tile maps in mind, it was created as a stand alone image, so it might be easiest for me to just clean up the mappy export, since I have one large image I am trying to shrink into a smaller size using tileset optimizations of instancing repeated elements. Good times, thanks again for everyone's help and input!

[Arkhan]

You have to use like, "Import At" with the last tile selected, and it will append the tiles to the end.

It can get kind of goony.  It sometimes selectively ignores tiles it feels are irrelevant, even though they are important

[Gredler]

You have to use like, "Import At" with the last tile selected, and it will append the tiles to the end.

It can get kind of goony.  It sometimes selectively ignores tiles it feels are irrelevant, even though they are important

That's the exact issue I was having. It also seems to have issues if you import two different palette indexed images, forcing the index of the second image imported into the first. Using a bmp of all the tilesets combined seems like the easiest solution, just a bit of organization and consistency is needed to keep everything functional

[Arkhan]

Tiles that it deemed useless for us were "blank tiles".


I just colored on them to shut it up. it seems to not understand that you sometimes want various black tiles.

I think it's racist.

[Gredler]

Alright, I think I got it all together, and I have to say once I got the workflow going I was pretty happy with iterating adding updated tiles with "import at".

Thanks again for all your help, hopefully I have a in game shot to show soon with my efforts.