MapMatic +2

Creating game materials? Monsters, spells, classes, adventures? This is the place!
User avatar
Clever_Munkey
Posts: 221
Joined: Fri Sep 11, 2015 12:08 am
Location: Ames, Iowa

Re: MapMatic +2

Post Sat Jun 03, 2017 12:02 pm

I didn't have any specific plans. I tend to use color in my maps as a quick reference code. For instance Blue might be GM's eyes only, and red is what has already been explored. Sometimes I also forget little but important details, so it could just be to remind me that the walls are a different material, or that a door is stuck.

I would be willing to palette swap the images if I had the originals.

I'd also like to add a few new symbols so that I could create overland (large scale) maps. I'd probably just make a few kind of lines for rivers/roads/ridges, a couple mountains, some trees, and a few buildings.
Call me Joe. Mr. Munkey is my father.
User avatar
Solomoriah
Site Admin
Posts: 6971
Joined: Thu Nov 13, 2008 8:15 pm
Location: LaBelle, Missouri
Contact:

Re: MapMatic +2

Post Sat Jun 03, 2017 10:53 pm

Okay, so you don't just want to color the map, you want the map in multiple colors.

Much more complicated; let me think on that...
My personal site: www.gonnerman.org
User avatar
Clever_Munkey
Posts: 221
Joined: Fri Sep 11, 2015 12:08 am
Location: Ames, Iowa

Re: MapMatic +2

Post Tue Jun 13, 2017 12:05 am

*Nudge*

I could just colorize each tile with a different color in GIMP, and you could add the set. In the UI there could be a color selector, which just changes which set is being used.

Unless that's more work than adding a way of using hex code for individual tiles somehow.

If I'm smart about it palette swapping a single set wouldn't take more than half an hour per color (81 images?). If I'm really smart I do one image in a bunch of colors at the same time.
Call me Joe. Mr. Munkey is my father.
User avatar
Solomoriah
Site Admin
Posts: 6971
Joined: Thu Nov 13, 2008 8:15 pm
Location: LaBelle, Missouri
Contact:

Re: MapMatic +2

Post Tue Jun 13, 2017 4:50 pm

The tiles are PNGs with transparency; as far as I know, the entire tile is just black with varying levels of alpha. Color-swapping shouldn't be hard... but I've never done it, so I'm not really sure.

Re-engineering the MapMatic engine for color could be done in a couple of different ways; how, exactly, I do it depends on what strategy for color selection I use.
My personal site: www.gonnerman.org
User avatar
Solomoriah
Site Admin
Posts: 6971
Joined: Thu Nov 13, 2008 8:15 pm
Location: LaBelle, Missouri
Contact:

Re: MapMatic +2

Post Tue Jun 13, 2017 8:51 pm

I've thought this over. Ultimately, I want colorization to be an option accessible with any MapMatic, not just the "GUI" MapMatic +2. This means that we need to get colorization into the language.

Presently, every "word" on a line either names an image and specifies its transformation, or in the case of words starting with #, defines a room number or label. Altering the syntax of image-tile words would make the parser much trickier, and as it works now, I hate to screw it up.

I'm inclined to add a new word type, introduced by a symbol (like the # used to signify a label or room number). I lean towards something simple and easy to type, such as an exclamation mark or question mark or something like that. Following that we could name colors (i.e. !red, or ?blue) or we could use RGB colors.

All tiles images and/or room numbers or labels following the color declaration get painted in that color, until another declaration is found or the words run out. Specifically, for tile images, all pixels that are (0, 0, 0) get changed to that color, regardless of alpha value, while all other colors are left alone. This will protect the white fill of doors, for example.

The advantage of doing it this way is that color would become available instantly in MapMatic +2 by means of manually typing color declarations, even before I touch the GUI code; the back-end which actually draws the map is the only thing that would need to be changed to test this.

However, I'll have to review each and every tile to ensure they are properly composed to work with this method.
My personal site: www.gonnerman.org
User avatar
Clever_Munkey
Posts: 221
Joined: Fri Sep 11, 2015 12:08 am
Location: Ames, Iowa

Re: MapMatic +2

Post Thu Jun 15, 2017 11:07 pm

Solomoriah wrote: I'm inclined to add a new word type, introduced by a symbol (like the # used to signify a label or room number). I lean towards something simple and easy to type, such as an exclamation mark or question mark or something like that. Following that we could name colors (i.e. !red, or ?blue) or we could use RGB colors.
RGB would be nice.

Could the color itself be the symbol denoting the change e.g. "(150,46,78) fill (0,0,0) wall" ? If you need a single symbol I guess it would be the open parenthesis in this case, but that might make parsing it a little awkward. Otherwise I like $ and % because they aren't used very often (i.e. at the end of a label).
Solomoriah wrote: All tiles images and/or room numbers or labels following the color declaration get painted in that color, until another declaration is found or the words run out. Specifically, for tile images, all pixels that are (0, 0, 0) get changed to that color, regardless of alpha value, while all other colors are left alone. This will protect the white fill of doors, for example.
How does this work with the smoothing on the images? I guess I don't know whether those pixels are just less opaque, or are actually a different color. The grey that makes up fill, pool, et al. is opaque, and might not react as nicely, but that would need testing.
Last edited by Clever_Munkey on Sat Jun 17, 2017 11:10 am, edited 1 time in total.
Call me Joe. Mr. Munkey is my father.
User avatar
Clever_Munkey
Posts: 221
Joined: Fri Sep 11, 2015 12:08 am
Location: Ames, Iowa

Re: MapMatic +2

Post Thu Jun 15, 2017 11:52 pm

Just had a shower thought; something to have written down, but probably not considered soon.

Would it be possible to create either a hexagon grid feature, or a different mapmatic that handles hex grids? HexMatic if you will. I'm aware of other software packages that do this already, but MapMatic does layers, so my mountains don't have to be brown, and there doesn't have to be 400 tiles to cover every topography-ecology combination.

Again this was just an idea that probably shouldn't be taken seriously anytime soon.
Call me Joe. Mr. Munkey is my father.
User avatar
Solomoriah
Site Admin
Posts: 6971
Joined: Thu Nov 13, 2008 8:15 pm
Location: LaBelle, Missouri
Contact:

Re: MapMatic +2

Post Fri Jun 16, 2017 8:55 am

Clever_Munkey wrote:Just had a shower thought; something to have written down, but probably not considered soon.

Would it be possible to create either a hexagon grid feature, or a different mapmatic that handles hex grids? HexMatic if you will. I'm aware of other software packages that do this already, but MapMatic does layers, so my mountains don't have to be brown, and there doesn't have to be 400 tiles to cover every topography-ecology combination.

Again this was just an idea that probably shouldn't be taken seriously anytime soon.
I've actually started on something like this half a dozen times, but never gotten past the planning stage. I don't use hex maps much myself, so I don't have an "itch to scratch" as they say.
My personal site: www.gonnerman.org
User avatar
Solomoriah
Site Admin
Posts: 6971
Joined: Thu Nov 13, 2008 8:15 pm
Location: LaBelle, Missouri
Contact:

Re: MapMatic +2

Post Fri Jun 16, 2017 9:02 am

Clever_Munkey wrote:RGB would be nice.

Could the color itself be the symbol denoting the change e.g. "(150,46,78) fill (0,0,0) wall" ? If you need a single symbol I guess it would be the open parenthesis in this case, but that might make parsing it a little awkward. Otherwise I like $ and % because they aren't used very often (i.e. at the end of a label).
Works for decimal color codes, but I was actually thinking hex codes as used on web pages. Since we already use the # sign as a code symbol, I'd need an alternative.

Understand that parsing this language is dead simple. The line is split on white space, then each "word" thus extracted is parsed individually. So, a # in the middle of a word does nothing special... only at the start does it matter. It's also why you have to use underscores for spaces in labels... the parser needs to keep the labels together.
Clever_Munkey wrote:How does this work with the smoothing on the images? I guess I don't know whether those pixels are just less opaque, or are actually a different color. The grey that makes up fill, pool, et al. is not opaque, and might not react as nicely, but that would need testing.
All of the black and grey in the existing PNG images should be (0, 0, 0, ???) values, but I know for sure that's not always true. It would be necessary to re-edit most of them to make them compatible. Fully transparent areas are generally (255, 255, 255, 0), i.e. "white transparency." This isn't important per se, just a fact of the matter.

Doors, for instance, include the short wall sections on either side. Do you want them to change color too? If so, no big deal, but if not, I'd have to be sure they were colored something like (0, 0, 1, ???) to protect them from being matched by the color changer.

I'd probably start by running the images through a filter designed to make every non-white space (0, 0, 0, ???). I suppose I could just do ALL the spaces... it doesn't really matter if I have "white transparent" or "black transparent" for my purposes. But non-transparent, non-black pixels would need manual editing.

Maybe running the filter at the END of the process (after manual review) is the way to go...
My personal site: www.gonnerman.org
User avatar
Clever_Munkey
Posts: 221
Joined: Fri Sep 11, 2015 12:08 am
Location: Ames, Iowa

Re: MapMatic +2

Post Fri Jun 16, 2017 1:24 pm

Solomoriah wrote: Works for decimal color codes, but I was actually thinking hex codes as used on web pages. Since we already use the # sign as a code symbol, I'd need an alternative.
If hex code was used then changing color could not be a transformation simply because f is already used. I guess it's case sensitive so F is not used. But I see that labels are not affected by transformations, and it might be annoying to have to color each layer separately.
Solomoriah wrote: Understand that parsing this language is dead simple. The line is split on white space, then each "word" thus extracted is parsed individually. So, a # in the middle of a word does nothing special... only at the start does it matter. It's also why you have to use underscores for spaces in labels... the parser needs to keep the labels together.
That is simple. That would make editing much easier.
Solomoriah wrote: All of the black and grey in the existing PNG images should be (0, 0, 0, ???) values, but I know for sure that's not always true. It would be necessary to re-edit most of them to make them compatible. Fully transparent areas are generally (255, 255, 255, 0), i.e. "white transparency." This isn't important per se, just a fact of the matter.
So then is the RGBA code converted to the RGB equivalent before producing the image? For example fill is (0, 0, 0, 0.5) which an eyedropper interprets (on white background) as (127, 127, 127).
Solomoriah wrote: Doors, for instance, include the short wall sections on either side. Do you want them to change color too? If so, no big deal, but if not, I'd have to be sure they were colored something like (0, 0, 1, ???) to protect them from being matched by the color changer.
It's fine with me if they change color. Unless it were possible to change them separately. I think that would require there be doors without wall bits, and then wall bits without doors, and you'd have to use them both for every door, and that sounds like too much work.
Solomoriah wrote: I'd probably start by running the images through a filter designed to make every non-white space (0, 0, 0, ???). I suppose I could just do ALL the spaces... it doesn't really matter if I have "white transparent" or "black transparent" for my purposes. But non-transparent, non-black pixels would need manual editing.

Maybe running the filter at the END of the process (after manual review) is the way to go...
Wouldn't running the filter convert every non-black, non-transparent space to a
(0,0, 0, ???), and all other spaces would be unchanged? I guess I'm not sure on how the filter works.
Last edited by Clever_Munkey on Sat Jun 17, 2017 10:25 am, edited 1 time in total.
Call me Joe. Mr. Munkey is my father.
Post Reply