11 March 2016 - Forum Rules

Main Menu

Looking for a Tileviewer with Tilemap Function

Started by Romsstar, October 14, 2011, 06:40:33 PM

Previous topic - Next topic


Is there a tileviewer that can display 8bpp, with palette support and also with support of a tilemap(Like placing the tiles in one image with the help of an array?)

I know probably not and that for that many functions I'd probably have to write it myself but maybe there is already a great program I haven't found yet.

I would be happy if someone could share their knowledge wteher there is a program that actually supports a Tilemap?

Tilemolester has support of 8bpp and palette but no Tilemap.


I believe that it's for NDS so i would check the last 2 utilities added to the "Newest Utilities" on the front page.


I'd be surprised if a general editor had a tilemap editing function. They are usually stored in game-specific formats and often compressed.
I know Tile Layer Pro has a clipboard that will allow you to manually arrange tiles so you can preview what they're like together, but that is only for preview purposes and has no effect on the game.
"My watch says 30 chickens" Google, 2018


KingMike do you have a document which could provide more information about this? My idea is if it is possible to rewrite Tile Molester in a way that it could apply a tilemap and give the output in a new screen.

But I don't know how tilemaps look like and I haven't found any good documentation on it.


Again...if you are working on NDS, then your document is LowLines Site


Quote from: Auryn on October 15, 2011, 04:23:39 PM
Again...if you are working on NDS, then your document is LowLines Site

But I'm working on PSX not NDS Auryn.
I'm looking for some documentation about tilemap on PSX


I haven't worked much at all on PSX.
Doesn't PSX use a bitmap-based graphics engine? I'd have to wonder how likely a tilemap-based system would come up.
Much of my experience in tilemap editing has been on stuff like title screens, and it would seem wasteful to me to use a tile-based engine to store what is essentially a large graphic.
(the difference being that in a bitmap-based engine, the color of every pixel on the screen is individually represented in VRAM, whereas in a tilemap-based engine (like most 2D consoles), individual graphics (such as a tree) are stored once in VRAM like stamps, and then the graphics processor just stamps that graphic across the screen. The tilemap is like a grid that states which tile should be stamped into each slot on the screen.)

But if you want some of the examples I've seen, I can give some NES examples.
Say we have a title logo graphic. The title is stored on 10 tiles per line, and say tile 0 is the blank tile.
An uncompressed full-screen tilemap.

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 01 02 03 04 05 06 07 08 09 0A 00 00 00 00
00 00 00 0B 0C 0D 0E 0F 10 11 12 13 14 00 00 00 00
00 00 00 15 16 17 18 19 1A 1B 1C 1D 1E 00 00 00 00

That's pretty wasteful with all those 0s.
So I've seen games that just store a tilemap for the title logo.

01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14

The game is then programmed to automatically go to the next line every 10 tiles.

The last technique I've seen I think is called Tile Squaroid Assembly or TSA.
It's where you have a table that's like

01 02 03 04 05

where each byte represents a 2x2 tile (16x16 pixel) region of the screen. Then you have a separate table that defines what 2x2 arrangement of blocks each byte in the earlier table represents.

01 02 0B 0C 03 04 0D 0E 05 06 0F 10 ...

While it makes sense for level maps, I have a hard time seeing why someone would code a title screen that way.

As mentioned, because the data is fairly simple and often contains repeat values, compression is common. I've seen RLE-type compression used on NES.

On SNES, each tile on the tilemap is represented by 2 bytes (one for tile number, the second containing data such as palette and flip attributes).
Since that data tends to be VERY repititous, it usually is compressed. Most often it's LZ variants, but I've seen RLE as well Usually interleaved (storing the "even" bytes in one block and the "odd" bytes in another).

Maybe that gives an idea how difficult such a feature would be to add? Having to have an editor find the offset, format, and such.

I know of one obscure tile editor that MIGHT have been able to do something similar. NESWrite. The idea was you could open one window and scroll to the font in the ROM, and the game would display the hex data in another window. Theoretically it could work to so degree for tilemaps. But I'm not sure since I don't know if it got far in development, it was a DOS program IIRC, and the biggest flaw: for some reason the author felt it needed to immediately write every change directly to the ROM.
Can't say how often I've been glad for a way to be able to close my ROM without saving changes to undo mistakes.

A bit off topic but similar, I'm guessing this is one reason no tile editor I know of supports MSX or PC-98. From what I've read, the graphics processors in those used interleaved formats (as in the entire tileset/bitmap is interleaved, unlike NES/SNES/GB which interleave each tile).
"My watch says 30 chickens" Google, 2018


Have a look at TiledGGD (google-codepage)

EDIT: My bad. The tools does NOT support tilemaps yet.


Thanks RetroHelix I will try.

KingMike: Hmm now I'm unsure if the game uses Tilemaps. Because you say it uses a bitmap bases graphics engine and yes I think that's true.
Maybe then it is not a Tilemap I need but something different? I have uploaded a screen when I open a Map in Tilemolester:

Uploaded with

The games uses a uncompressed format called TFS it seems.
I opened this in Tilemolester with:

8 bpp linear,
2-Dimensional mode
Palette Import from: This file at Offet 8, Size 512, Format 15bpp BGR(555)

Now with every TFS file there is always a MAP File also.
I tried just corrupting the MAP file on the ISO and then the Graphics of the Map in the game would be distorted. Which is why I think this is the Tilemap.

But maybe it uses some different sort of algorithm?

Maybe you have more experience with that KingMike.

I have uploaded the TFS file used in the screenshot and the corresponding MAP File. I think the MAP file should be uncompressed too, maybe you can take a look and tell me what exactly it is or if it is a tilemap at all?




Thanks for your help Nagato.

Thing I figured out:
The value  at offet 00 and offset 04 at each MAP tells you the widthxheight of the assembled picture.

for example:

20 00 at 00-01
00 18 at 03-04

= 200x 180 in hex and this is = 512x384 in decimal which is a legit resolution for PSX.

I tested this with other maps and it always seem to be right because I ripped some maps and the resolution of the maps assembled by myself and the values in the .MAP File always are the same


I'll give some info (from memory) about ToP PSX's tilemaps.  Keep in mind, that tilemap storage will vary.  It's similar to NES/SNES even though it's a pixel-based system instead of tiled.  (It just doesn't have hardware capabilities for tiles, so some code tells the PSX GPU to draw 2 triangle strips using the tile's texture, which creates a tile).

So ToP PSX sections its maps basically into two categories: "Top map" and "Bottom map", top map being mainly for collisions.  The graphics are stored in separate subfiles of the same might have 2-4 tileset files that each contain 16 tiles across and 16 tiles up and down (ie. a 256x256 image).  There was a file that contained tile properties (maybe one for Top map, one for Bottom map, I don't remember) and the individual tile properties contained the reference to the actual graphical tile.  Like: <tilepropshere like flipx, flipy> 01 F0 to reference a graphical tile in the second tileset...tile F0.

The map referenced the tile property index (not the graphical index).  So to display a map, you had to build a list of tile properties first.  Last is the tile data itself. which was conveniently stored in separate "Top map" and "Bottom map" files.  They had a map size (X, Y) in tiles and after that, the tile data.  So if 0240 was used, it references tile property #0240 from the list we built before.

Thankfully this was simple enough that we could deduce it without debugging the code...your mileage may vary.