.MBIN files format (creating HUD)
August 30, 2016 at 4:02 am #166284
These are my fairly incomplete and incorrect notes about .MBIN files format that I used to build my own hud in MINIHUD mod, taken from assorted sticky notes and memory, I hope this will help someone to take it further. For editing I use HxD, for extracting / packing file – psarc.
.MBIN files have hierarchical structure, contents of one file are included into another etc. Most values are represented by 4 byte blocks, everything is written backwards as it does, to convert floating point numbers into bytes you can use http://www.h-schmidt.net/FloatConverter/IEEE754.html
For example 0000803F = 0x3F800000 = 1.0
Color value are represented as RGBA, each number is in the range of 0.0 – 1.0.
There are three types of objects – layer, graphic and text, layers can include other objects, a typical layer header is shown on the image below (artificial example combined from many files):
The first 8 blocks are the name of the layer, optional, followed by (in cyan) 0x50 byte header containing coordinates, scales and anchor points as follows: the first two blocks are layer ID, zero block(?), x and y coordinates, width, units (0 – pixels, 1 – percents), height and units, 1.0, units (normally 01000000, if 01010000 – x and y are in percents), anchor points – the first block vertical value, the second horizontal (0,1,2 – top middle bottom / left middle right).
Thus in the example x=100%, y=0%, width & height=100%, anchor point topright.
Blue section is RGBA of the background color, purple – border color, brown is three flags: shape (0 – rectangle, 1- circle), fill / no fill, type of gradient (1 – solid, 2 – horiz linear, 3 vertic linear).
Bright green is RGBA of gradient color pairing one in the first blue section, red is rounded border flag, followed by the border thickness (2041).
Somewhere below in high level blocks – health, hazard, weapon there are a couple of 02 values, those are responsible for the type of animation when HUD appears/disappears, and parameters of that animation, around offset 1EC from the object ID.
This sums up the first x290 bytes, graphic objects are shorter and end up here, layer objects go further:
The next purple block (05000000) is the number of children of this object.
Green is the reference to the original object in another file. If present then the contents of the object in the current file will be disregarded and replaced by the contents of the reference (maybe some parts mix, like positioning). The simplest way is to remove this reference (fill with zeroes) to make sure the content only exists in the current file.
Red numbers are offsets pointing to children blocks below, each followed by the layer type. Each block is 0x48 bytes, the last one is 0x50.
Text objects have a shorter header 0x40 instead of 0x50, containing x,y,width,height,anchors in the same way as in layer, followed by RGBA, text size, letter spacing, 2blocksidontknowthemeaningof, bold flag, bold amount. Somewhere down the line there is a value (if set to 1.0) to turn on a thin border around the text.
Certain parts of the HUD are of course manipulated by the game .exe, certain parts are required and/or required to be at a specific order or position. For example, the object with ID 3BDEB1CB F5010000 in weapons needs to sit before 040D1BB3 F5010000; the energy bar requires to have 3 techicons inside it, otherwise the game crashes, although it doesn’t seem to use them.
Calculating all the children offsets is a nightmare, so attached is a simple vc++ 2010 express compatible main .cpp that I slapped up to assemble HUD.MBIN. It’s not a pro tool for assembling files and you do have to recompile it every time to if you want to change the order of objects, add/remove some but it does the job which otherwise will take forever to complete. In it’s current setup it should be able to assemble the first version of MINIHUD.
Attachments:You must be logged in to view attached files.
August 30, 2016 at 4:52 am #166305
An important note: there is some (postprocess?) procedure that adjusts all grey (equal rgb values) colors in the HUD by an overall yellowish color (RGB 242/255/197). I couldn’t find where it sits and it’s probably not written as RGB but the effect is that RGBA colors in .MBIN files will mix with that overall color, so for example 0000803F 0000803F 0000803F 0000803F will produce RGB 242/255/197.
There is also some procedure that gives all texts black outer glow, probably not set in .MBIN files themselves.
September 2, 2016 at 2:06 am #166904
Not a criticism, just a clarification: your comment “…everything is written backwards …” is more accurately stated as “… data is stored big-endian …”. I suspect due to the Playstation’s CPU being opposite ‘endianness’ to x86.
Wonderful work you’re all doing to bring extra enjoyment to this game. Thanks.
You must be logged in to reply to this topic.