VBM Specification by Heiko Herrmann - Revision history

Goober at 05:26, 31 January 2024

2024-01-31T05:26:11Z

← Older revision		Revision as of 05:26, 31 January 2024
Line 1:		Line 1:
	{{~~Template:RF1Editing~~}}		{{BubbleNav\|RF1Modding}}

	===Introduction===		===Introduction===
	The VBM file format, used in Summoner and Red Faction is a very simple non-compressed bitmap animation format with mipmap support (mipmaps are used for lower detail levels). So it is a lot easier to read/generate than the ANI file format, which Volition Inc. used in Conflict/Descent: FreeSpace and its successor FreeSpace 2. VBM supports 16-bit color depth, with an optional alpha (=transparency) channel (see color formats below for details).		The VBM file format, used in Summoner and Red Faction is a very simple non-compressed bitmap animation format with mipmap support (mipmaps are used for lower detail levels). So it is a lot easier to read/generate than the ANI file format, which Volition Inc. used in Conflict/Descent: FreeSpace and its successor FreeSpace 2. VBM supports 16-bit color depth, with an optional alpha (=transparency) channel (see color formats below for details).

Goober at 12:55, 9 February 2021

2021-02-09T12:55:53Z

← Older revision		Revision as of 12:55, 9 February 2021
Line 1:		Line 1:
	{{Template:RF1Editing}}		{{Template:RF1Editing}}

	~~==VBM Specification by Heiko Herrmann==~~

	===Introduction===		===Introduction===

Goober: Goober moved page .vbm to VBM Specification by Heiko Herrmann

2021-02-09T12:55:41Z

Goober moved page .vbm to VBM Specification by Heiko Herrmann

← Older revision	Revision as of 12:55, 9 February 2021
(No difference)

Goober at 18:40, 6 November 2020

2020-11-06T18:40:21Z

← Older revision		Revision as of 18:40, 6 November 2020
Line 1:		Line 1:
			{{Template:RF1Editing}}

	==VBM Specification by Heiko Herrmann==		==VBM Specification by Heiko Herrmann==

Goober: Goober moved page VBM File Specification to .vbm

2020-11-06T16:40:15Z

Goober moved page VBM File Specification to .vbm

← Older revision	Revision as of 16:40, 6 November 2020
(No difference)

Goober at 09:14, 3 October 2019

2019-10-03T09:14:38Z

@@ Line 1: / Line 1: @@
-I'm posting Heiko Herrmann's VPP and VBM file specifications here to archive so they're not lost to the sands of time.
+==VBM Specification by Heiko Herrmann==
-'''NOTE:''' If you're looking for the source code for the VPPBuilder32 software (which utilizes these file specifications), you can find it here: [https://www.factionfiles.com/ff.php?action=file&id=517652 VPPBuilder32 Source Code].
+===Introduction===
 The VBM file format, used in Summoner and Red Faction is a very simple non-compressed bitmap animation format with mipmap support (mipmaps are used for lower detail levels). So it is a lot easier to read/generate than the ANI file format, which Volition Inc. used in Conflict/Descent: FreeSpace and its successor FreeSpace 2. VBM supports 16-bit color depth, with an optional alpha (=transparency) channel (see color formats below for details).
 ''These specs were hacked out and written by Heiko Herrmann. They are by no means "official" and so I give no guarantee for the correctness of the information you find here. Of course I would love to get feedback when you find errors or missing information in these specs :).''
-'''File format'''
+===File format===
 The file begins with a 32-byte header, directly followed by the first frame first mipmap data. If the file has more than one mipmap the second mipmap level of the first frame with half the width and half the height follows next. The second frame (with all mipmaps) starts after all mipmaps of the first frame. And so on. There is no file footer, so the file ends directly after the last mipmap of the last frame. Here are the specs:

Goober at 09:12, 3 October 2019

2019-10-03T09:12:54Z

← Older revision		Revision as of 09:12, 3 October 2019
Line 16:		Line 16:
	The file has the following structure:		The file has the following structure:

	<blockquote><~~code~~>//At offset 0x0000: Header		<blockquote><pre>//At offset 0x0000: Header
	int signature; //0x51890ace		int signature; //0x51890ace
	int version; //0x00000001		int version; //0x00000001
Line 29:		Line 29:
	char filename[60];		char filename[60];
	int size;		int size;
	}</~~code~~></blockquote>		}</pre></blockquote>
	The first file starts at the next offset adress after the directory that is dividable by 0x0800. The second file starts again at the next offset adress after (offset of first file+size of first file) that is dividable by 0x0800.		The first file starts at the next offset adress after the directory that is dividable by 0x0800. The second file starts again at the next offset adress after (offset of first file+size of first file) that is dividable by 0x0800.

Line 37:		Line 37:

	Here is some example code:		Here is some example code:
	<blockquote><~~code~~>		<blockquote><pre>
	//Load header		//Load header
	f->Read(&m;_Signature,4); ASSERT(m_Signature==0x51890ace);		f->Read(&m;_Signature,4); ASSERT(m_Signature==0x51890ace);
Line 78:		Line 78:
	BOOL _0passed=FALSE;		BOOL _0passed=FALSE;
	for(int i=0;i		for(int i=0;i
	</~~code~~></blockquote>		</pre></blockquote>
	----		----
	------		------
Line 91:		Line 91:
	The file begins with a 32-byte header, directly followed by the first frame first mipmap data. If the file has more than one mipmap the second mipmap level of the first frame with half the width and half the height follows next. The second frame (with all mipmaps) starts after all mipmaps of the first frame. And so on. There is no file footer, so the file ends directly after the last mipmap of the last frame. Here are the specs:		The file begins with a 32-byte header, directly followed by the first frame first mipmap data. If the file has more than one mipmap the second mipmap level of the first frame with half the width and half the height follows next. The second frame (with all mipmaps) starts after all mipmaps of the first frame. And so on. There is no file footer, so the file ends directly after the last mipmap of the last frame. Here are the specs:

	<blockquote><~~code~~>#define COLORFORMAT_1555 0		<blockquote><pre>#define COLORFORMAT_1555 0
	#define COLORFORMAT_4444 1		#define COLORFORMAT_4444 1
	#define COLORFORMAT_565 2		#define COLORFORMAT_565 2
Line 110:		Line 110:
	unsigned char bitmapdata[widthheight2/pow(4,mipmap)]; //(*)		unsigned char bitmapdata[widthheight2/pow(4,mipmap)]; //(*)
	}		}
	}</~~code~~></blockquote>		}</pre></blockquote>
	'''''() Note:''''' The first mipmap always has the full widthheight pixels. The second has half width * half height, so we need to divide it by 4 (=pow(4,1)). Each following has pow(4,x) pixels, since both the width and the height are always divided by 2.		'''''() Note:''''' The first mipmap always has the full widthheight pixels. The second has half width * half height, so we need to divide it by 4 (=pow(4,1)). Each following has pow(4,x) pixels, since both the width and the height are always divided by 2.

Line 121:		Line 121:
	5 bits of color for the RG and B channels, 1 bit for alpha. Use this when you have alpha, but it's only the "on/off" variety. Pixels are either totally opaque or totally transparent. Useful largely for interface art.		5 bits of color for the RG and B channels, 1 bit for alpha. Use this when you have alpha, but it's only the "on/off" variety. Pixels are either totally opaque or totally transparent. Useful largely for interface art.

	<~~code~~> byte 0 byte 1		<pre> byte 0 byte 1
	01234567 01234567		01234567 01234567
	RRRRRGGG GGBBBBBA </~~code~~></blockquote>		RRRRRGGG GGBBBBBA </pre></blockquote>
	<blockquote>COLORFORMAT_4444 (=1)		<blockquote>COLORFORMAT_4444 (=1)
	4 bits for each RGB channel, 4 bits for alpha. Use this format when you want a full, varied alpha channel with semi-transparency.		4 bits for each RGB channel, 4 bits for alpha. Use this format when you want a full, varied alpha channel with semi-transparency.

	<~~code~~> byte 0 byte 1		<pre> byte 0 byte 1
	01234567 01234567		01234567 01234567
	RRRRGGGG BBBBAAAA </~~code~~></blockquote>		RRRRGGGG BBBBAAAA </pre></blockquote>
	<blockquote>COLORFORMAT_565 (=2)		<blockquote>COLORFORMAT_565 (=2)
	5 bits of alpha for the R and B channels, 6 bits for Green, and zero for alpha. Use this when the image needs no alpha transparency at all.		5 bits of alpha for the R and B channels, 6 bits for Green, and zero for alpha. Use this when the image needs no alpha transparency at all.

	<~~code~~> byte 0 byte 1		<pre> byte 0 byte 1
	01234567 01234567		01234567 01234567
	BBBBBGGG GGGRRRRR </~~code~~></blockquote>		BBBBBGGG GGGRRRRR </pre></blockquote>

	[[Category:Red Faction]]		[[Category:Red Faction]]
	[[Category:File Specifications]]		[[Category:File Specifications]]

Goober: Created page with "I'm posting Heiko Herrmann's VPP and VBM file specifications here to archive so they're not lost to the sands of time. '''NOTE:''' If you're looking for the source code for t..."

2019-10-03T09:11:45Z

Created page with "I'm posting Heiko Herrmann's VPP and VBM file specifications here to archive so they're not lost to the sands of time. '''NOTE:''' If you're looking for the source code for t..."

New page

I'm posting Heiko Herrmann's VPP and VBM file specifications here to archive so they're not lost to the sands of time.

'''NOTE:''' If you're looking for the source code for the VPPBuilder32 software (which utilizes these file specifications), you can find it here: [https://www.factionfiles.com/ff.php?action=file&id=517652 VPPBuilder32 Source Code].

------
'''VPP Specification'''
------
'''Introduction'''
VPP files are essentially file archives like *.ZIP or *.RAR files. However VPP files are not compressed. They serve to "package" all the files needed by the game (maps, interface graphics, models, textures, music and all other game data).

The VPP file format is similar but still different from the VP format, that Volition Inc. used in the FreeSpace series. The biggest differences are probably the clustering into 0x0800 blocks (see below) and the missing of a directory structure. As a minor difference you will also note that VPPs do not save timestamps for the files anymore and that filenames' maximum length has been extended from 32 to 60 characters.

''Please note that the following information is unconfirmed and was hacked out by myself (Heiko Herrmann) of the Summoner Demo PC V1.0 summoner.vpp file. While it seems to be unchanged in Summoner Full Version (both PC and PlayStation), as well as all versions of Red Faction, I give absolutely no guarantee that the information on this page is correct.''

'''File format'''
The file has the following structure:

<blockquote><code>//At offset 0x0000: Header
int signature; //0x51890ace
int version; //0x00000001
int num_files;
int filesize; //Size of the complete .VPP file

...2032 unused bytes...

//At offset 0x0800: Directory (64=0x0040 bytes long for each entry)
for(int i=0;i<num_files;i++)
{
char filename[60];
int size;
}</code></blockquote>
The first file starts at the next offset adress after the directory that is dividable by 0x0800. The second file starts again at the next offset adress after (offset of first file+size of first file) that is dividable by 0x0800.

Example: Summoner Demo PC 1.0 has 0x0962 files, so the directory ends at 0x00000800+0x0962*0x0040=0x00026080. So the first file starts at 0x00026800, since that is the next adress that is dividable by 0x0800. The first file is 0x00010515 bytes long, so it ends at 0x00026800+0x00010515=0x00036d15. So the second file starts at 0x00037000.

In other words, Volition uses "clusters" of 0x0800 (=2048 bytes) in Summoner for each file, the directory and even the header. The non-used space is just filled up with "00" bytes. In the worst case this means that 2047 bytes are wasted, which happens when a file is 1 or 2049 or 4097 or... bytes long. I am not sure why they do this, but my guess would be that there are performance reasons reading files in 2048-byte-blocks into memory.

Here is some example code:
<blockquote><code>
//Load header
f->Read(&m;_Signature,4); ASSERT(m_Signature==0x51890ace);
f->Read(&m;_Version,4); ASSERT(m_Version==0x00000001);
f->Read(&m;_NumFiles,4);
f->Read(&m;_Filesize,4);
f->Seek(_2048isize(f->GetPosition()),CFile::begin);
int offset=_2048isize(2048+64*m_NumFiles);

//Load directory
for(int i=0;i<m_NumFiles;i++)
{
m_Files''.filename=ReadString(f,60);
f->Read(&m;_Files''.filesize,4);
m_Files''.offset=offset;
offset+=_2048isize(m_Files''.filesize);
//TRACE("File %s, size %i\n",m_Files''.filename,m_Files''.filesize);
}
(...)

//Chunks
int _2048isize(int x)
{
if(x%2048==0)
return x;
x-=x%2048;
x+=2048;
return x;
}

//Read a null-terminated but fixed-length string
CString ReadString(CFile *f, int len)
{
char *t=new char[len];
f->Read(t,len);

CString ret="";
BOOL _0passed=FALSE;
for(int i=0;i
</code></blockquote>
----
------
'''VBM Specification'''
------
'''Introduction'''
The VBM file format, used in Summoner and Red Faction is a very simple non-compressed bitmap animation format with mipmap support (mipmaps are used for lower detail levels). So it is a lot easier to read/generate than the ANI file format, which Volition Inc. used in Conflict/Descent: FreeSpace and its successor FreeSpace 2. VBM supports 16-bit color depth, with an optional alpha (=transparency) channel (see color formats below for details).

''These specs were hacked out and written by Heiko Herrmann. They are by no means "official" and so I give no guarantee for the correctness of the information you find here. Of course I would love to get feedback when you find errors or missing information in these specs :).''

'''File format'''
The file begins with a 32-byte header, directly followed by the first frame first mipmap data. If the file has more than one mipmap the second mipmap level of the first frame with half the width and half the height follows next. The second frame (with all mipmaps) starts after all mipmaps of the first frame. And so on. There is no file footer, so the file ends directly after the last mipmap of the last frame. Here are the specs:

<blockquote><code>#define COLORFORMAT_1555 0
#define COLORFORMAT_4444 1
#define COLORFORMAT_565 2

char signature[4]; //".vbm"
int unknown; //sometimes 1, sometimes 2 - not sure what it means
int width;
int height;
int color_format; //see COLORFORMAT_* constants
int fps;
int num_frames;
int num_mipmaps; //excluding the primary mipmap

for(int frame=0;frame<num_frames;frame++)
{
for(int mipmap=0;mipmap<num_mipmaps+1;mipmap++)
{
unsigned char bitmapdata[width*height*2/pow(4,mipmap)]; //(*)
}
}</code></blockquote>
'''''(*) Note:''''' The first mipmap always has the full width*height pixels. The second has half width * half height, so we need to divide it by 4 (=pow(4,1)). Each following has pow(4,x) pixels, since both the width and the height are always divided by 2.

The multiplication with 2 is needed because every pixel needs two bytes (see below).

'''Color format'''
Each pixel needs two bytes, since they are always stored with 16-bit color depth. The format of the color depth can be one of the following (as specified in color_format):

<blockquote>COLORFORMAT_1555 (=0)
5 bits of color for the RG and B channels, 1 bit for alpha. Use this when you have alpha, but it's only the "on/off" variety. Pixels are either totally opaque or totally transparent. Useful largely for interface art.

<code> byte 0 byte 1
01234567 01234567
RRRRRGGG GGBBBBBA </code></blockquote>
<blockquote>COLORFORMAT_4444 (=1)
4 bits for each RGB channel, 4 bits for alpha. Use this format when you want a full, varied alpha channel with semi-transparency.

<code> byte 0 byte 1
01234567 01234567
RRRRGGGG BBBBAAAA </code></blockquote>
<blockquote>COLORFORMAT_565 (=2)
5 bits of alpha for the R and B channels, 6 bits for Green, and zero for alpha. Use this when the image needs no alpha transparency at all.

<code> byte 0 byte 1
01234567 01234567
BBBBBGGG GGGRRRRR </code></blockquote>

[[Category:Red Faction]]
[[Category:File Specifications]]