Vault Maker
Vault-Tec Cartographer
Hopefully I'm not being too presumptuous by starting a new topic for this.
I have worked out how to extract, view, edit, and modify the FOT Worldmap movement rates. Working had almost figured this out:
http://www.nma-fallout.com/forum/viewtopic.php?t=19513 ...but unfortunately he didn't describe it quite right, or at least not in a way that anyone else could understand.
The avatar I just uploaded is a reduced version of the eastern half of the Movement Bitmap, to whet your appetite. If you have a hex editor installed, jump down to Section C, and you can be viewing the Movement Bitmap in about 5 minutes.
However, I have also written a complete tutorial. Apologies in advance for the "plain text" setup, but I think it may be useful.
I have worked out how to extract, view, edit, and modify the FOT Worldmap movement rates. Working had almost figured this out:
http://www.nma-fallout.com/forum/viewtopic.php?t=19513 ...but unfortunately he didn't describe it quite right, or at least not in a way that anyone else could understand.
The avatar I just uploaded is a reduced version of the eastern half of the Movement Bitmap, to whet your appetite. If you have a hex editor installed, jump down to Section C, and you can be viewing the Movement Bitmap in about 5 minutes.
However, I have also written a complete tutorial. Apologies in advance for the "plain text" setup, but I think it may be useful.
Code:
[color=white]Fallout: Tactics
Worldmap Movement Rate Editing
Researched and written by Vault Maker
Version 1.0
11 Aug 2007
===============================================================================
CONTENTS
A. INTRODUCTION
B. HEXADECIMAL EDITING CONCEPTS
C. QUICK START
C.1 MOVEMENT BITMAP EXTRACTION
C.2 PUTTING THE MAPS TOGETHER
C.3 MOVEMENT BITMAP "SCALING"
C.4 MOVEMENT BITMAP "OVERSIZING"
D. MAKING A MOVEMENT BITMAP
E. CAM FILE STRUCTURE - THE BASICS
F. INSERTING THE MOVEMENT BITMAP
G. THE MOVEMENT BITMAP "SWITCH"
H. THE MOVEMENT BITMAP
H.1 MOVEMENT BITMAP HEADER
H.2 MOVEMENT BITMAP - PALETTE
H.3 PIXEL DATA - OVERVIEW
H.4 PALETTE ENTRIES AND MOVEMENT RATES
===============================================================================
SECTION A.1 INTRODUCTION
----------------------------
Below is a detailed explanation of how to extract, view, understand, and
finally modify the movement rates on a Fallout Tactics worldmap.
In my post-F3-trailer doldrums in June '07, I thought of Lenin's rhetorical
question, "What is to be done?" I answered myself by paraphrasing Mao,
"LET A THOUSAND FAN-MADE MODS BLOOM."
In the true spirit of modding, now that I have disposed of inspiration and
motivation right up front, let's get down to business.
I have the original US release patched to Version 1.27. Other localizations
or releases may differ. If they do, please try to figure out how and why and
post your findings to No Mutants or Duck and Cover, and I will update this
document with your contributions.
For foreign mod teams, if any are still operating, consider yourselves strongly
encouraged to translate this document as desired.
-------------------------------------------------------------------------------
A.2 TESTING
---------------
Most of what I describe in this document I have tested. However, there may be
a few things that I wrote when I was pretty sure about them, but either didn't
check thoroughly, or forgot to rewrite after checking them. In a few cases I
will call your attention to things that might be worth further investigation,
or that are just interesting coincidences.
There are a number of things that I know still need to be tested:
- Range of acceptable colors for the Movement Bitmap (Grayscale are known to
be used by BOS.CAM).
- Fill in the missing movement values in the Table at the end of the document.
- I think there were some others...
Also, there might be a way for someone to write a little applet that would
automate insertion of the Movement Bitmap into the .CAM file.
-------------------------------------------------------------------------------
A.3 "It's okay to be afraid."
---------------------------------
If you have never used a hex editor or done much image editing before, please
keep reading, as I have done my best to explain *almost everything* in great
detail. Before I dug into this about 2 months ago, I had rarely opened a hex
editor, and I didn't know a whole lot about image editing either.
-------------------------------------------------------------------------------
A.4 WHAT YOU WILL NEED
--------------------------
The list of tools and procedures I used to find all this out is embarrassingly
long, but all that's really needed are:
1. A Hex Editor. I used XVI32 v.2.51 by Christian Maas, which is a free
download from: [url]www.chmaas.handshake.de[/url]
2. A copy of your BOS.CAM file. This is important, since if you use XVI32 to
hex edit, there is no "undo" function.
3. Something to view, create, and edit bitmap files. Windows Paint should be
fine. Photoshop of course will work too. In Section D., "MAKING A MOVEMENT
BITMAP", I will describe an issue that Photoshop (and maybe other
applications) causes with worldmap movement and how to avoid it.
4. Red!Viewer v.1.6.0.15 by, of course, Red! There is a newer version of this
program modified by Dak, but on my computer it will not do the one thing
that we most need for experimenting with the default worldmap, which is the
ability to open BOS.CAM and export the entire worldmap as a single TGA file.
===============================================================================
===============================================================================
SECTION B. HEXADECIMAL EDITING CONCEPTS
--------------------------------------------
Below are listed a few essential terms for hex editing. This is by no means
exhaustive. I'm aiming for "barely adequate". Additional info can be found
on Wikipedia by just searching for "hex edit", or in many of the other "Pipes
of the Internets" (hope Alaska gets invaded soon).
-------------------------------------------------------------------------------
A "dword" is a group of 4 Bytes. You will see a lot of them in what follows.
They often appear in reverse order. If you look at strings of hex values, like:
"41 00 00 00 22 00 00 00 4B 00 00 00"
...these are often sets of dwords. This particular example, a few Bytes from
near the start of BOS.CAM, lists the "Worldmap Width in Tiles", "Worldmap
Height in Tiles", and the "Tile Width & Height in Pixels". Reversed, they are:
00 00 00 41 00 00 00 22 00 00 00 4B
Converted from hexadecimal to decimal values, they are:
65 34 75
Here's another example of a "dword reversed and converted to decimal", where
the four Bytes of the dword are read backwards, and then converted to their
base-10 format. For example, the size of the BOS.CAM Movement Bitmap file is
stored as:
26 5B 30 00
Reversed, it becomes:
00 30 5B 26 (or 00305B26) (Note that it *IS NOT* "62B50300".)
Converting the individual Byte values to Decimal yields:
00 48 92 38
Which means: 00 x 16,777,216 = 0
+ 48 x 65,536 = 3,145,728
+ 91 x 256 = 23,296
+ 38 x 1 = 38
---------
3,169,062 Bytes long
If you have Excel it's much easier to use the "hex2dec" function on "00305B26".
XVI32 also has a converter/viewer built in.
-------------------------------------------------------------------------------
The "first" Byte in a file is at "Address" or "Offset" 0, making it more like
the "0th" or "zeroth" Byte. This means that if you are looking for "Offset
1,078" you are actually going to the 1,079th Byte in the file.
Experienced hexers may be able to make their software call the first Byte
"Offset 1", but I'm assuming that you have XVI32, and it defaults to 0. I
think that some hex programs may also default to using 1 for the start Offset.
Likewise in the Palette (a list of colors used in the Movement Bitmap), the
"first" of the 256 entries is really the "0th", and the last is the "255th".
-------------------------------------------------------------------------------
In XVI32, the Offset shows up in the "status bar", in the lower left corner.
If you have a Byte in the left-hand pane selected, the Offset shows in
hexadecimal format, and is labeled "Adr. Hex." With a Byte in the right-hand
pane selected, the Offset will display in decimal format, labeled "Adr. Dec."
===============================================================================
===============================================================================
SECTION C. QUICK START
---------------------------
This section will get right you into being able to work with the Worldmap and
Movement Bitmap that are included in BOS.CAM. It includes how to marry the
Movement Bitmap and the Worldmap, so you can see how they interact.
The instructions for XVI32 and Red!viewer will be fairly detailed. Note that
since my version of Photoshop is old, I am not going to describe where in the
menus all the commands are (if I did, I would probably confuse anyone who
doesn't have Version *cough*5*cough*).
More detailed explanations are further down, in Section H.
-------------------------------------------------------------------------------
C.1 MOVEMENT BITMAP EXTRACTION
----------------------------------
Here's the quick-and-dirty way to extract and view the Movement Bitmap from the
game.
1. Open your copy of BOS.CAM in XVI32.
2. In the right-hand pane, scroll down to Offset 19,920,890 and put your
cursor in the box. In the right-hand pane the box should have a letter "A"
in it, followed by 3 blank boxes, then a double-apostrophe.
3. Look at the box highlighted in the left-hand pane. It should be "41",
followed by three "00"s, then a "22". These are the Worldmap Dimensions in
tiles (65 tiles wide by 34 tall), but converted to hexadecimal.
4. With your cursor still in the right-hand pane in the box with the "A",
go to the Edit menu, and select "Delete from cursor". This will delete the
entire tail end of the file, so it now ends in a pair of boxes that are
blank in the right-hand pane, and are "00" in the left-hand pane. The
Offset of the last Byte will now be 19,920,889.
5. In the right-hand pane, scroll up to Offset 16,751,827 and put your
cursor on it. In the right-hand window it should appear blank, and be
followed immediately by letters "B" and "M".
6. Look at the box highlighted in the left-hand pane. It should be "01".
This is the Movement Bitmap Switch.
7. With your cursor still in the Movement Bitmap Switch box, go back to the
Edit menu, and select "Delete to cursor". Your file now starts with
"B" and "M".
8. Now, Save as... and call it BOS.BMP (or whatever) and close the file.
9. It should now open up just like any other bitmap file. Beautiful shades of
gray and a fair amount of black will greet you right away. It will be set
to 256 colors, 2,450 pixels wide by 1,292 pixels tall, with print
resolution set to 71 dots per inch horizontal by 53 dots per inch vertical
(2800 dots per meter horizontal by 2,100 dots per meter vertical for the
metric-minded).
10. If it won't open, check the size of the file. It should be exactly
3,169,062 Bytes long. If it isn't, then...try again...or post a message.
-------------------------------------------------------------------------------
C.2 PUTTING THE MAPS TOGETHER
---------------------------------
1. Using Red!viewer v.1.6.0.15, open BOS.CAM. You can only view one Tile at a
time, but don't worry about that now. Go To "File", "Export Image as TGA",
and name it BOS.TGA (or whatever). This will make a 46 MB, 24-bit,
4,875 x 2,550 pixel image of the entire Worldmap.
2. If you use Photoshop, open the .TGA and save as a .PSD file (let's say it's
BOS.PSD).
3. Increase the Canvas Size by 100 pixels in each direction, centered on the
image (so you add 50 pixels around each side). The extra room isn't really
necessary, but it will give you room to experiment with.
4. Add a new Layer.
5. Now, open your Movement Bitmap in Photoshop.
6. Resize the image by 200%.
7. Select All, Copy, switch back to BOS.PSD, make sure the new layer you added
is current, and Paste.
8. You may want to set the new Layer to a reduced opacity, like 50% or so.
This will let you see the two maps better.
9. By putting the Movement Bitmap on it's own layer, and selecting just that
layer, you will be able to move the Movement Bitmap around relative to the
Worldmap. Now you need to line the maps up.
* The hard way: keep panning around, moving the Movement Bitmap a pixel at
a time, around Lake Michigan (the big black thing that Chicago uses for a
sewer). You'll never be totally happy with how the Movement Bitmap
pixels land on the Worldmap pixels, but you just had to try, didn't you?
* The easy way: set the upper left corner of the Movement Bitmap at the
upper left corner of the Worldmap.
The reason that the Movement Bitmap doesn't just fit right onto the Worldmap is
that the Movement Bitmap is "oversized" along the right and bottom edges.
-------------------------------------------------------------------------------
C.3 MOVEMENT BITMAP "SCALING"
---------------------------------
The Movement Bitmap in it's "raw" state, meaning not adjusted for "oversizing",
is 2,450 pixels wide by 1,292 pixels high.
This is just over 1/2 the size of the Worldmap. Each pixel of the Movement
Bitmap represents 4 pixels (2 wide by 2 high) of the Worldmap.
-------------------------------------------------------------------------------
C.4 MOVEMENT BITMAP "OVERSIZING"
------------------------------------
There are 17 extra rows. They run off of the bottom of the Worldmap. Because
of the way the pixel data is stored in bitmap files, they are the first 17
blocks in the file. They can be deleted from BOS.CAM without affecting the
Worldmap. If you experiment with this using a hex editor, you will also need
to modify the Bitmap Header (see Section H) to reflect the altered image
dimensions, or you can alter it by extracting, altering in a graphics program,
and reinserting.
There are also 12.5 extra Bytes in each row, running off the right side of the
Worldmap. Because of the way the pixel data is stored in bitmap files, they
are the first Bytes in each row. 12 Bytes can *probably* be deleted from each
row in BOS.CAM without affecting the Worldmap, but I haven't tested it.
===============================================================================
===============================================================================
SECTION D. MAKING A MOVEMENT BITMAP
----------------------------------------
This part is fairly easy. The map needs to be one-half the width and height of
your Worldmap, 256 colors, and the 256 colors should be Grayscale. See below
for the movement speeds signified by each color of the Palette. Many image
editing programs have a built in grayscale palette.
When you have made your Movement Bitmap, you will need to verify that the size
of the file is correct. You can compute it like this:
1. Take the number of pixels of width in your Movement Bitmap, and round it up
to the nearest multiple of 4.
2. Then multiply that by the height in pixels.
3. Add the size of the Header and Palette (1,078 Bytes).
My archaic version of Photoshop (v.5) insists on adding an extra pair of "00"
Bytes to the end of my Bitmap files. Most software may be able to handle this,
but FOT does not. If you bring one of these two-bytes-too-long Movement
Bitmaps into a .CAM file, you will get an error message if you try to open it
with either the game or the Campaign Editor. The extra Bytes can be easily
deleted from your Bitmap using XVI32. Note that your Bitmap file may need to
have up to three "00" Bytes at the end as end-of-row padding (see Section H.2)
===============================================================================
===============================================================================
SECTION E. CAM FILE STRUCTURE - THE BASICS
-----------------------------------------------
The structure of BOS.CAM is as follows:
Item
No. Description: Offset Range (decimal):
1 Campaign File Header 0 through 26
2 Worldmap 27 through 16,751,826
3 Movement Bitmap Switch 16,751,827
4 Movement Bitmap 16,751,828 through 19,920,889
5 Worldmap Dimensions 19,920,890 through 19,920,897
6 Worldmap Tile Spacers 19,920,898 through 19,929,737
7 Core Missions 19,929,738 through 19,935,414 +/-
8 Special Encounters 19,935,415 through 19,940,638 +/-
9 Random Encounters 19,940,639 through 19,967,877 +/-
10 Random Encounter Landscape Maps 19,967,878 through 19,969,733 +/-
11 Prefab Characters 19,969,734 through 19,969,932 +/-
12 Quartermaster List 19,969,933 through 19,983,631 +/-
13 Recruit List 19,983,632 through 19,986,948 +/-
14 Campaign File Footer 19,986,949 through 19,987,096
Note: Items #7 - #14 are listed with "+/-" because
I'm not exactly sure where they begin and end.
Fortunately, modders don't have to worry about hex editing for most of these,
because the campaign editor is able to take care of it. I think I have read
about a bug when starting a "new" campaign in the editor, so you may have to
use BOS.CAM as a base, but it seems that everything else can be imported or
replaced with the editor.
What we will be concerned with here are really just Items #3 and #4. But
first, you need to know what happens when you use the Campaign Editor to
import a Worldmap image, and otherwise modify a .CAM file.
1. When you import the Worldmap image ("Tools" menu, "Import Image"), you
have to specify a Tile Size. The Editor places some info about the map
into #1, the Campaign File Header. Specifically, it records the "Worldmap
Width in Tiles", the "Worldmap Height in Tiles", and the "Tile Size in
Pixels" (in decimal, these are 65, 34, and 75 respectively; in hexadecimal,
they will appear in BOS.CAM as "41 00 00 00 22 00 00 00 4B 00 00 00").
2. The Editor then goes to work on #2, and automatically cuts the map into
tiles. In the case of BOS.CAM, the map is 4,875 pixels wide and 2,550
pixels tall, and the Tile Size is 75 pixels, resulting in 2,210 tiles, 65
tiles wide by 34 tall.
3. The editor then inserts a single Byte "00" right after the end of the last
Worldmap Tile. This is #3, the "Movement Bitmap Switch". In BOS.CAM, this
is set to "01".
4. In a .CAM with a new map (or in the case of a modified BOS.CAM after using
"Import Image"), the Movement Bitmap (#4) does not exist. The file goes
straight to #5.
5. For #5, the Editor repeats the Worldmap Dimensions in Tiles, as was in #1,
(the Campaign File Header). For BOS.CAM, it is "41 00 00 00 22 00 00 00".
6. For #6, the Editor inserts four null-Bytes (or one null-dword) of
"00 00 00 00", for each Worldmap Tile. I have called these "Spacers", but I
don't actually know what their function is.
7. Importing the various "Lists", or all of "Campaign.TXT", in the editor takes
care of #7 through #13. The Editor creates #14, the Campaign File Footer,
automatically as well. More info about importing the Lists with the Editor
is available elsewhere.
===============================================================================
===============================================================================
SECTION F. INSERTING THE MOVEMENT BITMAP
---------------------------------------------
Once you have created your Worldmap and your Movement Bitmap, putting them
together in the .CAM file is relatively easy. However, you will be plunging
into the wilderness of hex editing, so you have to be *very* attentive.
1. Open the Campaign Editor and import your custom Worldmap. Go to "Tools"
and select "Import Image". Save the .CAM file, and exit the Editor.
2. Open the new .CAM file in XVI32. Find the start of the first Worldmap Tile,
which will start at Offset 27. The right-hand pane of XVI32 will show this
as "<campaign_tile>".
3. Scroll down until you see the start of the next Worldmap Tile. Make a note
of the Offset of the "<character>
+ Bitmap here + xx 00 00 00 The Worldmap Width in Tiles
++++++++++++++++++++++ xx 00 00 00 The Worldmap Height in Tiles
Lots of 00s The Worldmap Tile Spacers.
5. You may as well change the Movement Bitmap Switch to "01" now.
a. In XVI32, go to the "Tools" menu and make sure that "Overwrite" is
checked.
b. Now click on the Switch Byte in the left-hand pane and type "01". That
should do it, but be sure to check.
6. You will need to insert your Movement Bitmap next.
a. In XVI32, go to the "Tools" menu and *uncheck* "Overwrite". This puts
you into "Insert Mode". Using Insert Mode will add Bytes (or, in our
case, an entire file) at the currently selected Offset. This means that
the Byte at the currently selected Offset will move to be after the
inserted Bytes.
b. Select the Byte right after the Movement Bitmap Switch (which is the
Worldmap Width in Tiles).
c. Now go to the "File" menu, select "Insert..." and select your Movement
Bitmap file.
d. Your cursor will jump down to the Byte right after what you inserted (so
it will still be on the Worldmap Width in Tiles).
e. Make sure the 8 Bytes for the Worldmap Dimensions in Tiles are still
there.
f. Then go back to the Offset for the Movement Bitmap Switch, and make sure
(in the left-hand pane of XVI32) it is still "01", but is now followed
by "42 2D" (or, in the right-hand pane, "BM"). Your Movement Bitmap
should now be in place.
===============================================================================
===============================================================================
SECTION G. THE MOVEMENT BITMAP "SWITCH"
--------------------------------------------
In BOS.CAM, the Switch is at Offset 16,751,827.
If a movement map is present (as it is in BOS.CAM), this value is "01".
If no movement map is present, it is "00". The file will not include the
Movement Bitmap Header, Palette, and Pixel Data, so the file skips right
to the Worldmap Dimensions.
With no Movement Bitmap, all movement on the Worldmap is "full-speed".
Vehicles are still faster than going on foot, but the default speed of both
modes is the maximum, which is (very) slightly faster than it was anywhere in
BOS.CAM.
This value is set to "00" if you start a new .CAM file, or if you open BOS.CAM
and use the "Tools - Import Image" function (doing this will also delete the
entire Movement Bitmap).
If you have a Movement Bitmap in your .CAM file already, changing this to "00"
will prevent the Editor and the game from opening the .CAM file.
===============================================================================
===============================================================================
SECTION H. THE MOVEMENT BITMAP
-----------------------------------
This section gives more detail about the Movement Bitmaps, and about bitmap
files in general.
For each subsection below, I list the Offsets where the data is found, both in
the Movement Bitmap itself and in BOS.CAM. The entire Movement Bitmap fills
Offsets 16,751,728 through 19,920,889.
In my version of BOS.CAM (original US release, patched to version 1.27) the
Movement Bitmap covers the range of Offsets above, right after the last of
the 2,210 Worldmap Tiles (if you want a double check, the last tile ends in the
Bytes "E2 3D E4 E4 49 DD DD 12", the only sequence like that in the file).
The Movement Bitmap is a standard 256-color (8-bit), indexed-color bitmap file.
Quotes noted as [Source 1] are from [url]http://en.wikipedia.org/wiki/Bitmap[/url]
-------------------------------------------------------------------------------
H.1 MOVEMENT BITMAP HEADER
------------------------------
The header appears to comply with the "Windows V3" bitmap standard. I will
show it in four parts. The first is what I will call the "Basic Header",
apparently common to all .BMP files, and the rest is what I am referring to as
the "Extended Header". I only broke up the Extended Header to fit it onto
the page.
-------------------------------------------------------------------------------
H.1.0 BASIC BITMAP HEADER
---------------------------
Movement Bitmap Offsets: 0 through 13 decimal (00 through 0D hex)
BOS.CAM Offsets: 16,751,828 through 16,751,841
+--"Stores the magic number used to identify the bmp file. Typical values for
| these 2 bytes are 0x42 0x4D (ASCII code points for B and M)." [Source 1]
|
| +--"Store the size of the bitmap file using a dword." [Source 1]
| | Dword reversed and converted to decimal: 3,169,062 = total size
| | of Movement Bitmap (Header, Palette, and Pixel Data) in Bytes.
| | Header (54 Bytes) + Palette (1,078 Bytes) + 1,292 Rows of 2,452
| | Bytes each (3,167,984 Bytes) = 3,169,062 Bytes.
| |
| | +--Two pairs of Bytes, each is "Reserved. Actual
| | | value depends on the application that creates
| | | the image." [Source 1]
| | |
| | | +--"Store the offset, i.e.
| | | | starting address, of the byte
| | | | where the bitmap data
| | | | can be found." [Source 1]
| | | | Dword reversed and converted
| | | | to decimal: 1,078 (could be
| | | | defined as the size of Header
| | | | + Palette). Remember that
| | | | the "first" Byte is address
| | | | (offset) 0, so address 1,078
| | | | is the 1,079th Byte.
| | | |
+---+ +---------+ +---+----+---+ +---------+
v v v v v v v v v v
42 4D 26 5B 30 00 00 00 00 00 36 04 00 00
-------------------------------------------------------------------------------
H.1.1 EXTENDED BITMAP HEADER, PART 1
--------------------------------------
Movement Bitmap Offsets: 14 through 27 decimal (0E through 1A hex)
BOS.CAM Offsets: 16,751,842 through 16,751,855
+--"Size of this header (40 bytes)."
| Dword reversed and converted to decimal: 40
| The Basic Header is 14 Bytes; the total Header size is 54 Bytes.
|
| +--"Store the bitmap width in pixels." [Source 1]
| | Dword reversed and converted to decimal: 2,450
| |
| | +--"Store the bitmap height in
| | | pixels." [Source 1]
| | | Dword reversed and converted to
| | | decimal: 1,292
| | |
| | | +--"Store the number of color
| | | | planes being used. Not often
| | | | used." [Source 1]
| | | | This appears to be the value
| | | | set by default in new bitmap
| | | | files.
| | | |
+---------+ +---------+ +---------+ +---+
v v v v v v v v
28 00 00 00 92 09 00 00 0C 05 00 00 01 00
-------------------------------------------------------------------------------
H.1.2 EXTENDED BITMAP HEADER, PART 2
--------------------------------------
Movement Bitmap Offsets: 28 through 37 decimal (1B through 25 hex)
BOS.CAM Offsets: 16,751,856 through 16,751,865
+--"Store the number of bits per pixel, which is the color
| depth of the image." [Source 1]
| As stated above, this is a 256 color (8-bit) file.
|
| +--"Define the compression method being used." [Source 1]
| | No compression is used.
| |
| | +--"Store the image size. This is the size of the raw
| | | bitmap data (see below), and should not be confused
| | | with the file size." [Source 1]
| | | In a Windows Paint bitmap, this dword does contain
| | | the file size (when the dword is reversed and
| | | converted to decimal). However, Paint will still
| | | open a bitmap when this value is empty (set to
| | | 00 00 00 00). In a .CAM file, this d-word can be
| | | empty, or show the file size, with no apparent
| | | difference. It seems like a redundant
| | | data-integrity check, since we know that BOS.CAM
| | | has already established the size of the Movement
| | | Bitmap.
| | |
+---+ +---------+ +---------+
v v v v v v
08 00 00 00 00 00 00 00 00 00
-------------------------------------------------------------------------------
H.1.3 EXTENDED BITMAP HEADER, PART 3
--------------------------------------
Movement Bitmap Offsets: 38 through 53 decimal (26 through 35 hex)
BOS.CAM Offsets: 16,751,866 through 16,751,881
+--"Store the horizontal resolution of the image (pixel per meter)" [Source 1]
| Dword reversed and converted to decimal: 2,800 (71 dots per inch)
|
| +--"Store the vertical resolution of the image (pixel per
| | meter)" [Source 1]
| | Dword reversed and converted to decimal: 2,100 (53 dots per
| | inch). Unknown why these are different. Changing them
| | seems to have no effect on Worldmap movement.
| |
| | +--"Store the number of colors used." [Source 1]
| | | Dword reversed and converted to decimal: 256.
| | | As stated above, this is a 256 color (8-bit)
| | | file.
| | | +--"Store the number of important
| | | | colors used...can be 0 when
| | | | every color is important."
| | | | [Source 1]
| | | | Apparently all 256 colors are
| | | | important.
| | | |
+---------+ +---------+ +---------+ +---------+
v v v v v v v v
F0 0A 00 00 34 08 00 00 00 01 00 00 00 01 00 00
-------------------------------------------------------------------------------
H.2 MOVEMENT BITMAP - PALETTE
---------------------------------
Movement Bitmap Offsets: 54 through 1,077 decimal (36 through 04 35 hex)
BOS.CAM Offsets: 16,751,882 through 16,752,905
The Palette has 256 Entries. The Entries in the Palette are referenced from
the Pixel Data further down. Each Entry describes the R/G/B value of a color.
Photoshop users may recognize this as a Palette or a "Color Index".
The first Entry, which is really the "0th" Entry (similar to the addressing of
Bytes described in the Introduction), is never referred to. Why is that?
In Bitmaps, each row of pixels must be stored as a series of complete Dwords.
Any row whose length is not a multiple of 4 pixels will have 1-3 "null-bytes"
of "00" added to pad the end of a line. BOS.CAM only accepts "null-bytes" as
end-of-row padding, so if you have other "00" Bytes in the Pixel Data, the file
will not function correctly. Therefore, it shouldn't matter what you put in
for this Entry. See the "Movement Bitmap - Pixel Data" description below for
further explanation.
It seems that any or all of the other 255 Entries can be utilized. I don't know of
a reason why you would bother to use more than a handful of movement rates. I
think that the Fallout RPG Worldmaps only used a few.
In BOS.CAM, all but one Palette entry is Grayscale, meaning that the same value
is used for each of the R/G/B channels. It is possible that the Palette
Entries can be assigned any R/G/B value, but I haven't tested it so far.
-------------------------------------------------------------------------------
H.2.1 UNIQUE TO BOS.CAM
-------------------------
As described above, the "0th" Palette Entry is never used. Oddly, this Entry
is set to "97 97 97" (hex values). The Palette Entry for the impassable water
areas, "61", (decimal: 97) is "00 00 00". This may be a coincidence.
All but one Palette Entry use the same number for each R/G/B channel (meaning
that they are grayscale).
If put in numerical order, the R/G/B values defined by the Palette Entries in
BOS.CAM are "00 00 00", and the entire range from "91 91 91" through "F9 F9 F9"
(in hex), or 145 through 247 (decimal). Black color would be "00 00 00",
while white color would be "FF FF FF".
The oddball is Entry 105, which is "0F 14 16". This is the least used value in
the Pixel Data. Why this value is not grayscale is unknown. Interestingly
(coincidence?), "14 16" in Reverse Decimal is 5,652, which is the area of one
tile in pixels (75 x 75), rounded off to nearest 4.
Of the other 255 entries, only the first 106 are defined by the Palette Entries
in BOS.CAM. In the table below, they are marked with *.
-------------------------------------------------------------------------------
H.2.2 NO-MOVEMENT AREAS
-------------------------
As will be demonstrated below under Movement Rates, the no-movement (water)
areas in BOS.CAM are referencing Palette Entry 61 (hex...decimal 97) which has
the value "00 00 00". Testing has shown that Palette Entries from "01 01 01"
through "0C 0C 0C" have the same effect - no movement is possible.
-------------------------------------------------------------------------------
H.2.3 THE PALETTE IN BOS.CAM
------------------------------
+--Hex Number of Palette Entries
|
| +--Decimal Number of Palette Entries
| |
| | +--Extra Byte to "pad" palette values out to a full dword.
| | |
| | | +--Color value in Red, Green, Blue
| | | |
+---+ +-----+ | +------+
v v v v v v v
00-03 0- 3 * 97 97 97 00 99 99 99 00 * 96 96 96 00 98 98 98
04-07 4- 7 00 * 9A 9A 9A 00 9B 9B 9B 00 9C 9C 9C 00 9D 9D 9D
08-0B 8- 11 00 * 9E 9E 9E 00 9F 9F 9F 00 A0 A0 A0 00 A1 A1 A1
0C-0F 12- 15 00 A3 A3 A3 00 * A2 A2 A2 00 A4 A4 A4 00 A5 A5 A5
10-13 16- 19 00 * A6 A6 A6 00 A7 A7 A7 00 AD AD AD 00 95 95 95
14-17 20- 23 00 94 94 94 00 * AA AA AA 00 AC AC AC 00 AB AB AB
18-1B 24- 27 00 B1 B1 B1 00 B7 B7 B7 00 B5 B5 B5 00 B3 B3 B3
1B-1F 28- 31 00 B4 B4 B4 00 B8 B8 B8 00 BB BB BB 00 B9 B9 B9
20-23 32- 35 00 * BA BA BA 00 * B6 B6 B6 00 B0 B0 B0 00 AF AF AF
24-27 36- 39 00 * AE AE AE 00 A9 A9 A9 00 A8 A8 A8 00 * B2 B2 B2
28-2B 40- 43 00 BC BC BC 00 BD BD BD 00 * BE BE BE 00 BF BF BF
2C-2F 44- 47 00 C1 C1 C1 00 * C2 C2 C2 00 C4 C4 C4 00 C5 C5 C5
30-33 48- 51 00 * C6 C6 C6 00 C7 C7 C7 00 C8 C8 C8 00 * CA CA CA
34-37 52- 55 00 CC CC CC 00 * CE CE CE 00 CF CF CF 00 D1 D1 D1
38-3B 56- 59 00 D3 D3 D3 00 D4 D4 D4 00 D5 D5 D5 00 D7 D7 D7
3C-3F 60- 63 00 * D6 D6 D6 00 D8 D8 D8 00 D9 D9 D9 00 * DA DA DA
40-43 64- 67 00 DC DC DC 00 DB DB DB 00 DD DD DD 00 * DE DE DE
44-47 68- 71 00 * E2 E2 E2 00 E1 E1 E1 00 E4 E4 E4 00 E5 E5 E5
48-4B 72- 75 00 * E6 E6 E6 00 E7 E7 E7 00 E8 E8 E8 00 E9 E9 E9
4C-4F 76- 79 00 * EA EA EA 00 EB EB EB 00 ED ED ED 00 EC EC EC
50-53 80- 83 00 * EE EE EE 00 EF EF EF 00 F0 F0 F0 00 F1 F1 F1
54-57 84- 87 00 * F2 F2 F2 00 F3 F3 F3 00 F4 F4 F4 00 DF DF DF
58-5B 88- 91 00 E0 E0 E0 00 E3 E3 E3 00 CB CB CB 00 C9 C9 C9
5C-5F 92- 95 00 C3 C3 C3 00 C0 C0 C0 00 CD CD CD 00 D0 D0 D0
60-63 96- 99 00 * D2 D2 D2 00 * 00 00 00 00 F5 F5 F5 00 * F6 F6 F6
64-67 100-103 00 F7 F7 F7 00 F8 F8 F8 00 * F9 F9 F9 00 93 93 93
68-6A 104-106 00 91 91 91 00 * 0F 14 16 00 * 92 92 92
^
|
+--Entry 105
All of the remaining 149 Palette Entries (Entries 6B-FF,or 107-255) are set to
"00 00 00", so there are 149 x 4 = 596 "00" Bytes before the Pixel Data starts.
-------------------------------------------------------------------------------
H.3 PIXEL DATA - OVERVIEW
-----------------------------
Movement Bitmap Offsets: 1,078 through 3,169,061 decimal
(04 36 through 30 5B 25 hex)
BOS.CAM Offsets: 16,752,906 through 19,920,889
"This block of bytes describes the image, pixel by pixel. Pixels are stored
starting in the bottom left corner going from left to right and then row by row
from the bottom to the top. Each pixel is described using one or more bytes. If
the number of bytes matching a horizontal line in the image is not divisible by
4, the line is padded with null-bytes." [Source 1]
In BOS.CAM, the Data area has 1,292 blocks of 2,452 Bytes each.
Each block represents a row of pixels. Each row ends with two Bytes of "00".
The row is actually 2,450 pixels (at 1 Byte per Pixel), the extra two
null-Bytes are added to pad the row out to a complete dword (multiple of 4
Bytes). Again, this is why the "0th" Palette Entry is unusable.
-------------------------------------------------------------------------------
H.3.1 PIXEL DATA - DETAILS
----------------------------
The Bytes in the Pixel Data area are each calling Entries from the Palette
described above. For example, "02" in the Data is referencing Entry 02 in the
Palette, which is "96 96 96" (remember that the first Entry in the Palette is
the "0th", so 02 is the third entry).
Also, remember that all of the "00" Bytes in the Pixel Data are null-space at
the end of each line, so they aren't actually referenced to the Palette.
So here's our Palette from above, cropped down to just the Entries referenced
by the Pixel Data in BOS.CAM. I have also included the frequency with which
each appears, both in actual quantities and ranked from most common to least.
Pixel Pixel
Data Data Palette
Entry Entry Value Quantity of Quantity,
(Hex) (Decimal) (Hex) Ocurrences Ranked Notes
00 0 97 97 97 2,584 n/a 1
02 2 96 96 96 238,806 4
04 4 9A 9A 9A 125,110 10
08 8 9E 9E 9E 51,961 17
0D 13 A2 A2 A2 163,201 7
10 16 A6 A6 A6 353,268 2
15 21 AA AA AA 42,938 19
20 32 BA BA BA 258,705 3
21 33 B6 B6 B6 141,197 9
24 36 AE AE AE 41,914 20
27 39 B2 B2 B2 178,809 6
2A 42 BE BE BE 49,419 18
2D 45 C2 C2 C2 26,568 21
30 48 C6 C6 C6 20,167 23
33 51 CA CA CA 19,464 24
35 53 CE CE CE 18,696 25
3C 60 D6 D6 D6 21,316 22
3F 63 DA DA DA 111,896 11
43 67 DE DE DE 76,232 12
44 68 E2 E2 E2 60,026 15
48 72 E6 E6 E6 56,206 16
4C 76 EA EA EA 69,268 13
50 80 EE EE EE 143,449 8
54 84 F2 F2 F2 600,506 1 2
60 96 D2 D2 D2 18,149 26
61 97 00 00 00 64,688 14 3
63 99 F6 F6 F6 212,719 5
66 102 F9 F9 F9 520 27
69 105 0F 14 16 21 29 4
6A 106 92 92 92 181 28
Notes:
1. The only Data entries "00" should be end-of-row spacers.
2. The most common value by far, this is for pretty flat areas.
3. This is the value for the impassable "water" areas.
4. This is the "oddball" entry, where the R/G/B values are not all the same.
-------------------------------------------------------------------------------
H.4 PALETTE ENTRIES AND MOVEMENT RATES
------------------------------------------
This table shows what movement rates are possible for a sampling of the
grayscale values in the Palette.
Palette Entries used in BOS.CAM are (mostly) one value above those given in
this table ("F9 F9 F9" instead of "F8 F8 F8", etc.).
Movement Rates are in hours to cross one tile.
For the "Vehicle" rate, I only tested with the Hummer. The other vehicles may
vary from this a bit. I sampled every fourth value with the Hummer, and every
eighth value on foot. The movement rates listed may be a bit off, due to the
accuracy of my clicking around on the Worldmap.
Palette Palette Ratio,
Entry Entry Movement, Movement, Foot/
(Hex) (Dec) Vehicle Foot Vehicle
-------------------- -------- --------- --------- ----------
01 01 01 to 0C 0C 0C 1-12 N--O M--O--V--E--M--E--N--T
0D 0D 0D 13 170.07 485.67 2.86
10 10 10 16 138.13 408.00 2.95
14 14 14 20 110.20
18 18 18 24 92.07 278.50 3.02
1C 1C 1C 28 78.60
20 20 20 32 68.87 207.83 3.02
24 24 24 36 61.20
28 28 28 40 55.20 166.50 3.02
2C 2C 2C 44 50.20
30 30 30 48 46.07 138.17 3.00
34 34 34 52 42.53
38 38 38 56 39.53 118.33 2.99
3C 3C 3C 60 36.80
40 40 40 64 34.54 102.00 2.95
44 44 44 68 32.50
48 48 48 72 30.63 91.56 2.99
4C 4C 4C 76 29.00
50 50 50 80 27.63 82.78 3.00
54 54 54 84 26.33
58 58 58 88 25.04 74.89 2.99
5C 5C 5C 92 24.04
60 60 60 96 22.96 69.00 3.01
64 64 64 100 22.21
68 68 68 104 21.25 63.67 3.00
6C 6C 6C 108 20.42
70 70 70 112 19.67 59.00 3.00
74 74 74 116 19.04
78 78 78 120 18.38 55.22 3.01
7C 7C 7C 124 17.88
80 80 80 128 17.08 51.00 2.99
84 84 84 132 16.71
88 88 88 136 16.21 48.67 3.00
8C 8C 8C 140 15.75
90 90 90 144 15.33 46.00 3.00
94 94 94 148 14.88
98 98 98 152 14.50 43.56 3.00
9C 9C 9C 156 14.21
A0 A0 A0 160 13.83 41.33 2.99
A4 A4 A4 164 13.50
A8 A8 A8 168 13.08 39.56 3.02
AC AC AC 172 12.79
B0 B0 B0 176 12.50 37.44 3.00
B4 B4 B4 180 12.25
B8 B8 B8 184 12.00 35.78 2.98
BC BC BC 188 11.75
C0 C0 C0 192 11.46 34.22 2.99
C4 C4 C4 196 11.25
C8 C8 C8 200 11.04 33.33 3.02
CC CC CC 204 10.75
D0 D0 D0 208 10.58 32.00 3.02
D4 D4 D4 212 10.38
D8 D8 D8 216 10.17 30.78 3.03
DC DC DC 220 10.00
E0 E0 E0 224 9.88 29.44 2.98
E4 E4 E4 228 9.71
E8 E8 E8 232 9.46 28.56 3.02
EC EC EC 236 9.38
F0 F0 F0 240 9.04 27.67 3.06
F4 F4 F4 244 9.00
F8 F8 F8 248 8.88 26.78 3.02
FC FC FC 252 8.75
===============================================================================
That's it. It's really pretty easy to do. Who knew?
- Vault Maker[/color]