Don't get too excited. The maps this thing makes are extremely messy. It's only meant to be
helpful, not
perfect.
You can get it here.
Link.
You can see what it did for Z1A1 of Sonic Pocket Adventure here.
Link.
You can see the community map for that same stage here (to compare, not as something this script can do).
Link.
---
EDIT: The camera behavior in that game is worth some brief mention. The camera coordinate that I found when I was just searching RAM didn't quite match the "real" camera coordinate. Given a coordinate address that matches the "real" position of the camera, it may produce a fairly reasonable map. In other words, if you can find a coordinate that is at least "close" to the camera's "real" position, that is the worst the output should (reasonably) be. Provided you also mark the HUD and character for removal, of course.
---
When you run this, do the lua script to collect frames and data first, then run the python file to assemble them into a map after.
In order to run this you will need:
* Bizhawk
* the memory addresses for the camera and character in-game.
* the ability to read reasonably okay documentation in code and make your own changes
* Python 3
* Python 3 pillow library
* Python 3 pyaml library. Windows users might look here after installing Python 3 as PIP cannot do compilation on Windows.
Link.
I don't think that code is doing anything too funky/new if you already have Python 2 installed and want to try it. Still will need pyaml and pillow.
If people are interested in this enough I am willing to:
* move it into my github repository
* clean up the code and add some new features
* create an actual requirements.txt for python
* take error reports and suggestions on configuration/etc for it via github
---
Caveats:
* this can only work on one map at a time. So if you change screens or stages, you need to stop collecting data and screenshots or you'll get something funky, I'm sure.
* this was written for myself and only decided to be given to the community later on. It reflects that.
* I'd hope this would be obvious, but this only works when the stage keeps a consistent camera viewpoint. It will most certainly also break in mode 7 (and similar such display transformations).
---
Future plans:
* map out character paths based on their coordinates. May be useful for examining routes people take through stages.
* create some sort of reverse-mechanism to match frames to character locations. In theory, this would enable you to race another player's ghost in-game. In practice, it feels too ambitious but there's no reason it can't work, really.
* disable need for some of my own libraries (am I even using these?)
* eliminate dead code left over from when I was still getting this to a working state.
* incorporate TQDM in python assembly script. Trying to figure out if YAML can report status on file load, took quite a while to make itself work before. Uncomfortably so. Still could use TQDM in map assembly (and other things).
---
Why this?
I thought that Sonic Pocket Adventure didn't actually have maps, and needed to see the big picture to do route planning of my own. This had output that was useful enough; I later found that the maps did exist but were a bit out of my usual goto for them.
Still, there must be many games with no maps made. While this won't make something nice and pretty for you, it will make probably make something useful. A lot of times seeing the map as a whole can give some insight into a route possibility.
