FMF:MAP

This article is about the OHRRPGCE FMF project, which is an alternate implementation of the OHRRPGCE for Java mobile phones. Technical implementation details discussed here should not be confused with those of the RPG format

Maps received the most attention; the current format was too unweildy. All maps were now stored as "lumps of lumps"; each lump complying with the general lump format. However, there was an additional stipulation: sub-lumps must appear in the following order: .MN, .MD, .T, .P, .N, .E, .D.

All maps are named using the "new" convention XXX.MAP, where XXX is the ID of the map, padded with zeroes.

.MN

Consists of a single null-terminated string: the map's name.

.MD

Contains 20 integers, laid out in the standard MAP format. Compression on this lump was deemed un-necessary; there's just not enough space to save.

.T

Unchanged from its standard format; except that the BSave header was removed.

.P

Using the width and height from T, passability is encoded as a bitstream. A "0" in the bitstream means "all bits off", and a "1" means that the next 8 bits contain passability information for this tile, in the standard format.

For example, the hex bytes 13 01 80 translate to the binary string 100110000000110000000, which means the next five tiles have passability ids of
00110000 (block south & west)
0
0
0
10000000 (block north)

.N

Each .N sub-lump contains a one-byte header indicating the number of NPC definitions contained within. Following this header are the records, in the following format:

Data	Meaning
BYTE	ID of this NPC (to accomodate null NPCs)
15 INTs	Data as defined in N, except that offset 3 (the speed) is replaced with the actual speed. And the npc's picture is incremented by one; an id of zero now means "no picture+". Compression, again, was deemed insignificant and not worth implementing.
BYTE	Number of instances of this NPC
2 INTs and a BYTE for each instance	x position, y position and direction (see L) of this instance of the NPC

+ Walkabouts with every pixel in every frame set to 0 are deemed "null", and are not saved into the resulting XRPG folder.

.E

Enemy maps usually contain a lot of one number (be it zero or some formation set) and a handful of other numbers. This makes it the perfect candidate for prefix-free code replacement. The first byte of this sub-lump contains the number of dictionary entries. For each dictionary entry, a byte follows with the value of that entry. It is implicitly assumed that dictionary entries will be numbered as follows:
0
10
110
1110
...etc.

Then, a bitstream follows representing the foe-map.

An example will help to make this clear. Suppose we have the following hex steam: 05 00 05 01 03 02 00 01 6E BA 0E... This translates as follows

Hex	Binary	Meaning
05		There are 5 dictionary entries
00		The bit "0" corresponds to "0"
05		The bits "10" corresponds to "5"
01		The bits "110" corresponds to "1"
03		The bits "1110" corresponds to "3"
02		The bits "11110" corresponds to "2"
00 01	00000000 0000000	The next 15 tiles have no enemies
(01) 6E	10 110 1110	The next 3 tiles start battles with formation sets 5, 1, and 3, respectively
BA	10 1110 10	The next 3 tiles start battles with formation sets 5, 3, and 5, respectively
0E	0 0 0 0 1110	The next 5 tiles start battles with formation sets 0, 0, 0, 0, and 3, respectively

.D

Doors no longer have IDs, on the observation that it's very rare for multiple doors to link to the same destination door. Instead, this sub-lump contains a number of 7-integer records, in the following format

Data	Meaning
INT	Source door's x-position
INT	Source door's y-position + 1
INT	Destination door's x-position
INT	Destination door's y-position + 1
INT	Destination door's map ID
INT	First conditional tag ID
INT	Second conditional tag ID

List of Lumps specific to the XRPG format. Other lumps comply with existing .RPG lump specifications.

HEADER.LMP . _FNT.png . .PT4_# . .PT6_# . .HERO_#.png . SEZ . EFX . BFF . FOE . _TIL_#.png . _MXS_#.png . ###.MAP . HRO . ATK . SCRIPTS_#.HF . SCRIPTS.LST