New version of OgreMap

[Misplaced Buckeye]

Originally Posted by GranitePenguin

yes, Mountains are available

Fantastic...Thanks GP

[offsides]

This looks really nice! A couple of notes:

1) It would be great to be able to load a saved map from the opening 'New Map' screen, so it doesn't have to create a new blank map first.

2) Running under WINE on Linux, it mostly seems to work just fine. The one problem I've had so far is that when I try to load a saved map (23x23), I get an out of memory error. Not sure if that's related to my setup or not, but it might be worth looking into. (Another datapoint - a map saved on Windows generates serialization errors when loading on Linux, and vice versa.)

Which segues into my other question. I created a blank (clear) 23x23 map, put one hex of each other type on it, along with one of each road/rail and some hexsides just to get a feel for how things worked. When I look at the save file, it's almost 6MB in size on Windows, and 10MB on Linux! I'm not sure what all you've got stored in there (file calls it TrueType font data, and I can see a bunch of other things in there before it turnes to 100% gibberish), but that strikes me as being rather inefficient. Given that the hex images are chosen from an existing known set within the program (even with, e.g., 4 different images for green clear terrain (which I have to say is pretty awesome!)), I would think you could simply store what image is at what hex location by numeric value using 1 or 2 bytes, and do the same for each hex side. Roads/Railroads could then simply be stored as 2-byte hex pairs (which would limit maps to 255x255, but that's probably a good thing :)) with a header for each type of road before the pair listing along with how many of them there are (4 bytes?).

Thus, a 23x23 map using 2-byte hex identifiers and 1 byte for hexsides, plus 4 byte headers for each 'road' type would need 4144 bytes for the hex data (plus some sort of header indicating the map size and shape, probably only 3-4 bytes there), plus an additional 4 + 2N bytes to indicate each type of road, where N is the number of sections (between 2 hexes) of that type of road (and that would max out at ~6Kbytes if every hex had 6 roads leading out of it). Even if you stored it as text (or even XML) it would still be a lot smaller that the current output.

Just a thought, since smaller files are easier to share, and the large size made me curious as to what you were storing in there (and how)... :)

In any event, thanks for making such a great tool!

[HeatDeath]

He's probably just using .NET's built-in object serialization code. Each hex is probably an instantiated object of the same type, so that multiplies out the overhead significantly. Sure it's not efficient, at all. But it's literally one line of code, that doesn't have to change even when you add new features to the program.

Memory, bandwidth, and HD space are cheap. Developer time and mindspace is expensive. And premature optimization is the root of all evil. :)

[tomc]

Originally Posted by HeatDeath

He's probably just using .NET's built-in object serialization code. Each hex is probably an instantiated object of the same type, so that multiplies out the overhead significantly. Sure it's not efficient, at all. But it's literally one line of code, that doesn't have to change even when you add new features to the program.

Memory, bandwidth, and HD space are cheap. Developer time and mindspace is expensive. And premature optimization is the root of all evil. :)

Exactly right on all points. Developer time is the scarce resource. Also, Dot Net isn't the best choice for graphics applications, but it's what I'm most familiar with and gave me the best chance to release something before life intervened again. (It worked!)

Offsides - you make a number of good points though. The next version won't require you to make a map before you load an existing one. I made OgreMap the default application (on my PC) to open .om2 files, so just double clicked the map file to start the program and automatically load the map, so I kinda forgot about the other scenario.

I expect your Wine problems are also related to the Binary Serializer in Dot Net. I don't Linux or WINE, but I'll see if there are any reasonable accommodations I can make.

Thanks for everyone's interest and feedback. Now go make some scenarios for me to play! :)

[offsides]

Originally Posted by HeatDeath

He's probably just using .NET's built-in object serialization code. Each hex is probably an instantiated object of the same type, so that multiplies out the overhead significantly. Sure it's not efficient, at all. But it's literally one line of code, that doesn't have to change even when you add new features to the program.

Memory, bandwidth, and HD space are cheap. Developer time and mindspace is expensive. And premature optimization is the root of all evil. :)

While I'll partially disagree on the 'X i cheap' argument, I can totally understand the 'one line of code' reasoning. Not how I would do it, but that's just me (and properly designing your file format is NOT premature optimization unless you try to squeeze things into too few bytes fo future expansion!).

Originally Posted by tomc

Exactly right on all points. Developer time is the scarce resource. Also, Dot Net isn't the best choice for graphics applications, but it's what I'm most familiar with and gave me the best chance to release something before life intervened again. (It worked!)

Don't know anything about .NET other than that I won't touch it, but I understand about limited developer time. It's a fantastic program - don't think I'm saying otherwise - I was just surprised that the map file format was so big and had so much stuff in it (much of which I couldn't identify). Knowing that it's a serialization makes a lot more sense now, thought I'm surprised that each hex image appears to be stored separately, rather than just one copy of each image and pointers to the correct one - at least that's my assumption, given the file size.

Originally Posted by tomc

Offsides - you make a number of good points though. The next version won't require you to make a map before you load an existing one. I made OgreMap the default application (on my PC) to open .om2 files, so just double clicked the map file to start the program and automatically load the map, so I kinda forgot about the other scenario.

That makes sense. It's easy to miss little things like that when your both author and tester - I've done it enough myself :)

Originally Posted by tomc

I expect your Wine problems are also related to the Binary Serializer in Dot Net. I don't Linux or WINE, but I'll see if there are any reasonable accommodations I can make.

Thanks for everyone's interest and feedback. Now go make some scenarios for me to play! :)

Knowing what little I know about Wine, I would agree that it's related to the .Net Serializer working differently in Wine. Don't worry too hard about it, I can run it on Windows if I have to save in .OM2 format, iut's just less convenient. But that is one of the limitations of using a binary serializer - I wonder if .NET has some way to export to XML instead, and if that might work in a more cross-platform manner. Just a thought, even if XML is often overkill too :)

Thanks again for making this, and I already did - there's 2 of mine in the Scenario Contest winners :P

[Tim Kauffman]

Originally Posted by Misplaced Buckeye

I don't know about the rest of you but this looks like great tool to make terrain overlays for the main board.

Which is just a short step away from this:

https://www.flickr.com/photos/128248...57649789633815

Modular OGRE DE Map or "MOD Map"...lol

This would be so easy to create using whatever SJGs used to make the OGRE DE terrain tiles and maps. The black lines between the hexes on the map would be cut away, which would leave some wiggle room so the individual OGRE DE Mod Map terrain tiles would fit nicely inside the OGRE DE Mod Map Frame.

Basically this is the perfect sweet spot between the upcoming PC Game and OGRE DE for map customization, and best of all would be fully compatible with all the OGRE DE terrain tiles. You set the map frame size and then have fun filling it in as you customize the terrain.

[Eugee]

This is a snippet of the G1 map from a previous edition (I don't remember which one, I long ago lost my little plastic GEV tote to the ravages of growing up and moving.

https://puu.sh/rwhRP/c5ef957953.jpg

And this below is a screengrab of OgreMap @ DE Zoom with the hex numbers turned on:

https://puu.sh/rwipL/8bbc86e97d.png

Did the numbering system change with DE?

EDIT for clarity:

When Hex Numbers are turned on for High & Big maps, the top row of the odd columns starts with ##01, while the even columns start with ##02. Can that be fixed so the even columns start with ##01 as well?

When you export the map as a PNG, it numbers the hexes even if you have numbers turned off in the editor--so I can't add the correct numbers in post edit, unfortunately.

[ghostofjfd]

Nice. I used an earlier version to draw an Icepick map, and I recall some horsing around to get that printed the way I wanted. This new version seems even easier to use.

The speed and ease of editing, the fidelity to the original graphics, and the options for saving to PNG, etc. are sweet. Thanks again, Tom.

[GranitePenguin]

Originally Posted by Eugee

Did the numbering system change with DE?

EDIT for clarity:

When Hex Numbers are turned on for High & Big maps, the top row of the odd columns starts with ##01, while the even columns start with ##02. Can that be fixed so the even columns start with ##01 as well?

When you export the map as a PNG, it numbers the hexes even if you have numbers turned off in the editor--so I can't add the correct numbers in post edit, unfortunately.

No, the numbering did not change in DE; that is a bug in the map software.

[tomc]

Originally Posted by Eugee

When Hex Numbers are turned on for High & Big maps, the top row of the odd columns starts with ##01, while the even columns start with ##02. Can that be fixed so the even columns start with ##01 as well?

When you export the map as a PNG, it numbers the hexes even if you have numbers turned off in the editor--so I can't add the correct numbers in post edit, unfortunately.

Thanks for the clear info. I'll put these two issues on the list for the next release.