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 00That's pretty wasteful with all those 0s.
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
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 14The 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 05where 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).