Reverse Engineering a Tile set for a Port/Remake

Questions
1

I’m currently testing out software that could help out to extract a tile set map, from a level image created by copy&pasting / gluing screenshots from an Arcade game.

The objective is to make a port/remake of the arcade game POW, for a ZX Spectrum.
I’m documenting the process on WOS on the following thread
https://www.worldofspectrum.org/forums/discussion/52769/p-o-w/

The main idea is to document the original tiles, so that a very accurate representation can be achieved in the conversion.

Obviously ZX Spectrum limitations, namely 8x8 color block limits will have a significant impact on the output, but I have a reasonable experiment already looking good.

Extract of original

And here is a first impression of the graphics remake

What I would like to ask, is if Tiled is suited for this reverse engineering task, eventually using some twist of the automapping or other feature.

I know I can use it to build the new ZX Tiles, which is great.

But can I use the Level images as a Tileset or automap, and try to map only some of the existing tiles, since there are a lot of repetitions, that I need to remove ?

The main goal would be to extract or detect the repetitions semi-automatically and later export only non repeatable tiles.
Eventually I might have to implement some code to do this.

Currently I have used the original level image as a tile set, and by hand I can see the repetitions and slowly select always the same original tile, when I find a repetition, while reconstructing the level on the tiled map. But this is very slow and error prone.

Ideally, it should be possible to detect repetitions, and only use a single tile from tileset or similar.

I noticed there is a selection icon “Select same Tile (s)”, that shows me the repeated tiles I have placed by hand.
But this probably works with tile IDs only.
What I probably need is something that can match the tile image pixel by pixel, so that it can detect repetitions in mutliples of the tile size, from a larger image…

Any ideas or suggestions on how to “abuse” the current Tiled features to accomplish this in a faster manner ?

Another necessity that seems a must, but that I can’t find, is a way to move or relocate tiles in the tileset, and update the corresponding IDs on map.

Thank you in advance for any useful feedback.

2

Importing a map from an image, while automatically generating a tileset with all the unique tiles, is a feature that could be added to Tiled but isn’t currently available.

The Import from Image wiki article covers a possible approach and features some Python scripts that could be used to perform such an operation.

There is also a program called ShoeBox that ships with an Extract Tiles tool that will generate a TMX map and accompanying tileset. Though since it is based on Adobe AIR it won’t work on Linux.

3

Thanks, I’ll have a look at the suggestion you mentioned.

I’ll get back with some news about it.

4

I tried the ShoeBox route, with mixed success.

It extracts the tiles, but doesn’t maintain any coherence between them, so we just get an horizontal sweep of tiles as they are found, while removing the repeated ones.
This would be great for a vertical scrolling game.
But for an horizontal scrolling game, is not that great.

NOTE: Tiled could also allow for tile indexes to be defined (increase index) vertically, so that it was easier to organize in memory for horizontal scrolling games.

However, nice ShoeBox is, it has several bugs, which break the “Extract Tiles” feature. Last Column or First Row might be missing depending on settings, and worse is that most of the times, it has offset errors.
I reported all these to developer, let’s see how fast he can fix them.

Meanwhile, I may try the scripts, or eventually, build my own java tool to do this.

5

It would be EXTREMELY useful to be able to select a TILESET and enter EDIT MODE.

While in TILESET EDIT MODE, we would be able to:

  • SWAP tiles (or groups of tiles) within the tileset (physically editing the base image), so that we could re-arrange the disposition of the base tiles, while preserving all the correct indexes in the MAP.
  • SLIDE tiles (or groups of tiles) like if it is “Sliding puzzle game” (https://en.wikipedia.org/wiki/Sliding_puzzle), while preserving all the correct indexes in the MAP.
  • Save (Replace pre-existing tileset image) or revert/abort all changes on exit EDIT MODE.

NOTE: a backup copy of the previous (original) tileset image file, would be a plus, in case of errors.

Sliding tiles, would be very useful to move tiles or tile blobs (groups of tiles) around using cursor keys or mouse drag.

A group or blob move, can always be decomposed as a sequence of simgle one tile moves (actual sequence depends on direction of move), which makes it easy to implement and support undo.

A simple one tile move, can be implemented to something similar to two calls to existing Map Tile Swap feature, NOTE: might required an intermediate ficticious tile index, to avoid losing existing tile locations, after first Map Tile Swap call.

6

I do not quite understand how adding such an option would make any difference.

It’s unfortunately to hear you’re running into several ShoeBox bugs. All the more reason to add such a feature to Tiled directly I guess (I noticed this is covered by issue #180).

Makes sense. Please feel free to open a GitHub issue about this with the details you posted. The main downside is that it will inevitably break existing maps referring to the tileset, and Tiled can’t magically know about all affected maps in order to adjust their tile references. Some solution for this may be expected when this feature it added.

7

If you consider a machine, that is limited on memory, where full tileset may not fit in memory all at once, and if you further consider an application that scrolls horizontally, then it makes sense to brake the tileset data into chunks every Nth tiles, horizontally, so it would be easier to manage if the index iterate vertically first, and horizontal second.
A possible workaround, is to pre-split the tileset, so that each chunk is separate, and then having horizontal first indexes on tiles, won’t be as much of a hassle.

To be honest I never though about several maps sharing a tileset, that can not be changed, due to the sharing dependency.
A simple solution, is to create a distinct image, for the map that started the edit, hence making it independent, of the original image.

Another parallel possibility could be detection of image changes, like you already do for width (height too ?), and prompt to adjust the indexes, but instead, determine that the image changed by keeping a HASH for each tile inside tilemap tileset reference, so that moves/swaps of tiles, could be automatically detected.

This tile Hashing, might give some edge cases, if the image is actually edited by an artist at the pixel level.
Which means some hashes will not have a match when compared with the new image, so either assume them as new/changed, instead of moved/swapped.
Users should be warned not to TILESET EDIT simultaneously with editing the pixel art on an external program.

8

Where is the code base in github, so that I can submit this ?

9
10

Added to github as requested, but improved the description, and added a very nice/easy implementation idea, that will make it a lot more useful.

1 Like