HnH Cartographer - app to create local maps

[dagrimreefah]

Awesome app, ty for this

[Leny-m]

I'm super curious how did Ando break my code without me releasing the actual source lol ^^

[Leny-m]

I could use someone with pretty decent amount of map files to process to share it with me for testing purposes.

At least 1000+ tiles in one of the main folders (map or cave or simplemap) in 10+ subfolders. No data will be shared with public or used by myself to gain anything in-game. It would be strictly for testing. The more tiles and folders the better. Preferably in .zip format (but I can work with pretty much any archive). And shared over any filesharing website. Link messaged to me via PM.

And the reason for that? I'm actualy planning on creating a progress bar of some sort and I'm still thinking about how to improve the speed.

[Rhonan]

nice work!
keep it up

[EyeOfRa]

Leny here, great guy. 100 %

[Leny-m]

Currently I'm trying to find another way to compare two images. Right now, I'm comparing them pixel by pixel which is pretty harsh on the performance. But I haven't found any better way so far.

Just a fun fact - earlier today I received a map folder from EyeOfRa which contained 23 848 tiles and when I tried to estimate the time needed to process such amount of data I ended up with 987 hrs that's 41 days ^^

I still haven't found any good source code for extracting crc from png. That might be the way.

[mvgulik]

Right now, I'm comparing them pixel by pixel

But I haven't found any better way so far.

I don't know what your general targets are. (application features in relation to supported image input.)
But storing some short checksum on a processed image would not be a bad idea.

I still haven't found any good source code for extracting crc from png. That might be the way.

The png-image-stream(IDAT)-crc code is only useful if you only going to support unmodified client map-tile images. (in which case you could just use a whole-file-crc to do the comparing.
- Map tile from client only have a single IDAT chunk. While PNG images have there data generally store in multiple IDAT chunks (around ~8k seems to be the default used split size. See the png tile images from online World-map.)
- http://www.w3.org/TR/PNG/ [PNG specs]
- http://entropymine.com/jason/tweakpng/ [Good PNG tool to have around while messing with PNG specs.]

[Leny-m]

...

An example how the combining part of app works:

1 folder in map folder = 1 local map
compare 2 local maps tile by tile
if you find a match, adjust 1 whole local map to match the other (renaming, moving together)
cleanup

Pixel by pixel has 100 % results. Tried checksum with a bit worse results but it took the same amount of time.

And I can't really store any processed data. There still would be users who are trying to use my app for the first time on big amounts of data.

[mvgulik]

Pixel by pixel has 100 % results. Tried checksum with a bit worse results but it took the same amount of time.
And I can't really store any processed data. There still would be users who are trying to use my app for the first time on big amounts of data.

True, if your processing two new sessions.
Using and storing those checksums is key to any potential major speedups. (will make it more complicated of course, and present its own set of potential problems.)
Just to give you a more practical example, here is what I do it. I store the checksum's in a database(SQLite) file inside the session map. And when merging two sessions I also merge the checksum data. That way I kinda eliminate the need to do more than one scan on any tile.
So if I got a big session that exist out of a lot of merged sessions ... I don't have to do any tile scanning anymore. Big time saver ... And kinda needed to maintain a general workable speed with big merged sessions.

On the used source date used for the checksum ... well, I used a full file scan, mainly because that was the easy way out. But try to switch to real image data to make it possible to also use downloaded tiles from alg's online world map. (but coding progress is slow on this end.)

[Leny-m]

True, if your processing two new sessions.
Using and storing those checksums is key to any potential major speedups. (will make it more complicated of course, and present its own set of potential problems.)
Just to give you a more practical example, here is what I do it. I store the checksum's in a database(SQLite) file inside the session map. And when merging two sessions I also merge the checksum data. That way I kinda eliminate the need to do more than one scan on any tile.
So if I got a big session that exist out of a lot of merged sessions ... I don't have to do any tile scanning anymore. Big time saver ... And kinda needed to maintain a general workable speed with big merged sessions.

On the used source date used for the checksum ... well, I used a full file scan, mainly because that was the easy way out. But try to switch to real image data to make it possible to also use downloaded tiles from alg's online world map. (but coding progress is slow on this end.)

This trully is a great idea. Sir, thank you I just wish I had more time to work on it. It's real fun to create maps ^^