Hi, I'm looking for the tiles that make up the metatiles/levels. I can only seem to find the sprites and spritesheets, and fully assembled images of the levels, but not the tiles out of which the levels are made.
Is there a tilesheet available?
Thanks!
Ecco tiles
Re: Ecco tiles
Hey there.
Excellent question which I was going to address eventually after launching this board.
Short answer: unfortunately we do not yet have individual tiles metatiles are assembled from. The spritesheets as well as level maps currently presented on our website were obtained using a tool that Johnny has written, but it relies on using the data that's already in VRAM and decompressor for tile data in ROM seems to have been on the TODO list as development of the tool was abandoned. If you are technically inclined, you could take a look at his Github repo where source codes as well as VRAM dumps it operates on have been provided: https://github.com/JohnnyLdeAlba/ecco-lib -- we would greatly appreciate if you could share your findings with us if you do!
Overall this is definitely something I am going to address, as well as describing the password generator algorithms in detail.
Thank you for confirming there is interest in that topic!
Excellent question which I was going to address eventually after launching this board.
Short answer: unfortunately we do not yet have individual tiles metatiles are assembled from. The spritesheets as well as level maps currently presented on our website were obtained using a tool that Johnny has written, but it relies on using the data that's already in VRAM and decompressor for tile data in ROM seems to have been on the TODO list as development of the tool was abandoned. If you are technically inclined, you could take a look at his Github repo where source codes as well as VRAM dumps it operates on have been provided: https://github.com/JohnnyLdeAlba/ecco-lib -- we would greatly appreciate if you could share your findings with us if you do!
Overall this is definitely something I am going to address, as well as describing the password generator algorithms in detail.
Thank you for confirming there is interest in that topic!
Re: Ecco tiles
Thanks. I'm terrible with C/C++, but I had a quick look at the code and found a reference to 16x16 size. I took the entirety of the Home Bay foreground and put it inside the Godot tileset tool and it also autodetected 16x16 tiles. I then used imagemagick to cut the foreground into individual tiles of 16x16 pixels, which gave me around 33000 images. Then I used digiKam to detect all duplicates so I could delete them. That leaves me with 886 tiles, just from the Home Bay foreground. Unfortunately this also contains tiles that had sprites added to them, like the starfish, plus it has the Mega Drive shadow effect applied to a large quantity of them.
I just had a quick read on the tiles on this website and noticed it says 8x8 tilesize. With tiles that small, how does anyone know how combine them to a metatile? How is it determined which ones fit together?
I just had a quick read on the tiles on this website and noticed it says 8x8 tilesize. With tiles that small, how does anyone know how combine them to a metatile? How is it determined which ones fit together?
Re: Ecco tiles
Mega Drive operates with 8x8 tiles in video RAM. How they are then assembled together is dictated by the so called name tables or playfield: it's a table inside VRAM that tells the hardware which tile goes where onto the screen in a grid. The fact your tool is showing them as 16x16 may be coming from the way data is arranged in memory or just a happy accident...
Those nametables can be anywhere in video memory and VDP is made aware of where to look for them by loading their VRAM address into its registers. Taking Tides of Time Home Bay, for example, we can see that Plane A containing foreground is located at 0xC000, Plane B is at 0xE000, etc. -- the quickest way to check that would be in an emulator that lets you view current VDP registers. Format of the nametable is fairly simplistic, as you can see and they're merely referring what tiles to display, what palette to use where and whether to flip them. Sequential entries will fill up the screen left to right, top to bottom.
The downside to this, of course, when working with VRAM dumps would be that we will get tiles that have already been composited together as the game does this only once when map is loaded. In order to get plain rocks graphics that weren't composited with the gribbly bits, we would need to get at the data in ROM which so far has not been done yet.
Those nametables can be anywhere in video memory and VDP is made aware of where to look for them by loading their VRAM address into its registers. Taking Tides of Time Home Bay, for example, we can see that Plane A containing foreground is located at 0xC000, Plane B is at 0xE000, etc. -- the quickest way to check that would be in an emulator that lets you view current VDP registers. Format of the nametable is fairly simplistic, as you can see and they're merely referring what tiles to display, what palette to use where and whether to flip them. Sequential entries will fill up the screen left to right, top to bottom.
The downside to this, of course, when working with VRAM dumps would be that we will get tiles that have already been composited together as the game does this only once when map is loaded. In order to get plain rocks graphics that weren't composited with the gribbly bits, we would need to get at the data in ROM which so far has not been done yet.
Re: Ecco tiles
Hi, thanks for the insights. What I actually meant was how to know which tiles to use, in a practical sense. How would I know which tiles fit together?
Re: Ecco tiles
Sorry for the late reply, I actually was checking something to see if this could be answered reliably.
Essentially, the information on how tiles go together is stored within the game ROM proper: separate 8x8 tiles are assembled into what's currently has the working name of "metatiles" (or superblock) that are usually 128x128 pixels in size. These are then sprinkled with whatever details that are required and assembled into a level map that is also in the ROM proper.
Unfortunately, the latter has been very poorly documented so far: Johnny has gotten the level maps extracted, but did not really document much of his findings besides leaving us the source code. One thing for certain is that the graphics inside the ROM are compressed -- which is why he used emulator save states where tiles have already been unpacked into video memory. Level data isn't which is how he was able to reassemble it.
I trust that makes sense.
Essentially, the information on how tiles go together is stored within the game ROM proper: separate 8x8 tiles are assembled into what's currently has the working name of "metatiles" (or superblock) that are usually 128x128 pixels in size. These are then sprinkled with whatever details that are required and assembled into a level map that is also in the ROM proper.
Unfortunately, the latter has been very poorly documented so far: Johnny has gotten the level maps extracted, but did not really document much of his findings besides leaving us the source code. One thing for certain is that the graphics inside the ROM are compressed -- which is why he used emulator save states where tiles have already been unpacked into video memory. Level data isn't which is how he was able to reassemble it.
I trust that makes sense.