;=============================================================================
Documentation about CaDan's new "Resource Table" structure:

There's a nice 256 byte table that points to various resources located
throughout CaDan and the loaded level packages. The purpose of this
table is to limit the amount of hardcoded addresses to help facilitate
relocatability throughout the game environment.

The table is structured as such:
------------------------------------------------------------------------------
00-0E : byte: Resource index
0F    : byte: Resource EOL
10-FF : word: Resource fields
------------------------------------------------------------------------------
Pretty simple, eh? Let's try to further break this one down.

Every object that wants resources such as script or graphics must choose a
spot in the first 16 bytes of the table. Their ResourceID is kept by the
object and is directly mapped to the resource table. For example, say you
had an enemy that wanted resources. It would try to search the table for an
empty resource slot, which is indicated by $00. Once a resource slot has been
found, the byte at ResourceID is changed to a byte that refers to the starting
position on the table. If the resource table is empty, then this would be
$10, which is the first byte after the end of the index/EOL.

ResourceFields come in addresses, which is the address of the resource in
question. It doesn't actually matter *what* is at that address, as long as the
object can distinguish between possible things that are there.

The Resource EOL indicates the last byte that is being used. This is important
when additional resources need to be allocated for another object, or by the
same object. If this byte is $00, then the table is full. If this byte is $10,
then the table is empty.

Now, let's look at two enemy objects that are on the table. Keep in mind that
the data in ResourceTableFields is not entirely accurate but rather a
representation of what is there. It will be explained afterward

ResourceTableIndex:
10,14,00,00,00,00,00,00,00,00,00,00,00,00,00  ;
ResourceTableEOL:
1A
ResourceTableFields:
4000,A700,8D00,A780,A800,0000,0000,0000
0000,0000,0000,0000,0000,0000,0000,0000
0000,0000,0000,0000,0000,0000,0000,0000
0000,0000,0000,0000,0000,0000,0000,0000
0000,0000,0000,0000,0000,0000,0000,0000
0000,0000,0000,0000,0000,0000,0000,0000
0000,0000,0000,0000,0000,0000,0000,0000
0000,0000,0000,0000,0000,0000,0000,0000
0000,0000,0000,0000,0000,0000,0000,0000
0000,0000,0000,0000,0000,0000,0000,0000
0000,0000,0000,0000,0000,0000,0000,0000
0000,0000,0000,0000,0000,0000,0000,0000
0000,0000,0000,0000,0000,0000,0000,0000
0000,0000,0000,0000,0000,0000,0000,0000
0000,0000,0000,0000,0000,0000,0000,0000

In this example, an enemy whose ResourceID of 0 shows that its resource field
area starts at address $10. It's length is not known in any way other than
the object that is in front of it. In this case, there is another enemy, where
its ResourceID is 1. That enemy's resource field area starts at $14, which
tells you that the previous entry is 4 bytes long.

The EOL is at $1A, which tells you that enemy ResourceID 1's size is 6 bytes.

In reading this table, ResourceID 0 will see the address at its resource 0 to
be $4000, whereas ResourceID 1 will see its resource 0 to be $8D00.

The table is structured in this manner so that no single object needs to keep
track of what IDs are taken by any other given object.

...
...
...
It's quite alright if you didn't understand any of this. I mean, if you did,
then more power to you. But it's just fine. The purpose of this document was
just to help me collect my thoughts about the resource table, since I was
doing it wrong wrt menus vs graphics.

------------------------------------------------------------------------------
MENU SYSTEM WHILE NOT IN GAME MODE

MenuID's 0, 1, and 2 are allocated in a very static fasion. The following
MenuIDs are as follows:

MID 0 = Menu system core data (i.e. X,Y,etc.)
MID 1 = Menu system text data
MID 2 = Image data

------------------------------------------------------------------------------
RESOURCE TABLES WHILE IN DANMAKU (GAME) MODE

That information will be found in "loader.txt", where stage information is
actually loaded to CaDan's 4KB slice of RAM.