А давайте придумаем алгоритм?

Хорошее мышление!

По картинке - вряд ли. Слишком накладно и геморойно. Вот если отследить позицию игрока, то тут думаю варианты есть.

Там вся карта на одном экране что-ли? Тогда гораздо проще.

Как-то же делают такие карты: http://maps.speccy.cz/map.php?id=IceTemple&sort=3&part=14&ath=

Вот так оно в динамике выгляидт http://www.youtube.com/watch?v=h-ibDnOkWNc

один город - одна карта.

Мышление одно - реализация другое )

Ну скорее всего так и делают. Либо вручную отфотывают

>Слишком накладно и геморойно.

Ну не знаю, скин весит не больше 20кб на эту маленькую игрушку, обновлятсья раз в 2 сек, сегодняшним компам просчитать все это добро будет не сложно.

А насчет отслеживания - это как? В принципе можно, но тоже через сравнение картинок, иначе сам ROM переписывать )

http://sacred.gameguru.ru/underworld/maps.htm как-то и такие делают )

>Ну не знаю, скин весит не больше 20кб на эту маленькую игрушку, обновлятсья раз в 2 сек, сегодняшним компам просчитать все это добро будет не сложно.

А как определить в какую сторону картинка сместилась? Это же надо какие-то алгоритмы выдумывать. А если мы знаем смещение или позицию игрока, то алгоритм упрощается. А вообще наверно проще найти карту в роме.

http://lurkmore.ru/Dwarf_Fortress
еще не придумали лучше рпг

Ну вот смотри, есть скрин. Персонаж отходит к правому краю экрана, карта следит за ним. Если сделать скрин сечас - то этот скрин будет содержать половину предыдущего.

Каким-то образом сравнить одинаковые части картинки, наложить друг на друга скрин в одинаковых местах и получится как-раз что надо.

Вот как это сравнить бы.

Посчитать корреляционную матрицу двух изображений - тогда можно будет определить примерное смещение(точно вряд ли получится из-за движения перстонажей).

Неужто нейронки применять придется )

зачем сразу нейронки?) можно написать вспомогательную прогу с гуйней, в которой квадратики изображений примерно на своих местах находятся и нужно их лишь слегка подвигать. Замучаешься, зато будет точная карта.

А вообще, можно же и этими неточными смещениями пользоваться, а потом просто все усреднить.

На хабре была статья про это.

Покажи.

Первое же, что пришло в голову:
0. Пусть размер скриншотов - 640х480.
1. Выбираем размер плавающего окна. Скажем, 16х16.
2. Существует (640-16)*(480-16) возможных расположений окна внутри скриншота. Каждому расположению соответствует двумерное смещение центра окна относительно центра скриншота.
3. Пробегаем окном по первому скриншоту с шагом в 1 пиксель и строим индекс: хеш-таблицу (std::tr1::unordered_multimap), где в качестве ключа выступает набор попавших в окно пикселей (можно просто сконкатенировать их в одну строку), а в качестве значения - смещение окна.
4. Пробегаем окном по второму скриншоту с шагом в 16 пикселей и строим рейтинг смещений. А именно, перед началом шага 4 все смещения получают рейтинг 0. Подставляем окно со второго скриншота в построенный на предыдущем шаге индекс, и рейтинг всех найденных в индексе смещений увеличиваем на 1.
5. Смещение с самым большим рейтингом - это и есть наиболее вероятное смещение второго скриншота относительно первого.

s/(640-16)*(480-16)/(640-16+1)*(480-16+1)/

Не надо ничего думать. Используй программы для склейки изображений, навроде autopano-sift-c.

Фигасе какая штука. Спасибо за наводку! http://en.wikipedia.org/wiki/Scale-invariant_feature_transform

>Покажи.

С удовольствием бы, но что-то не нашел. :( В общем, суть такова: делалась запись видео прохождения игры и хождения по всем локациям. Затем, брали тайлы, с помощью хитрой софтины генерировалась матрица карты, путем нахождения тайлов на видео. Потом это вручную корректировалось. Как-то так.

Все бы хорошо, да работают они уж больно медленно и слишком много шагов надо выполнить, чтобы связать картинки.