TUTORIAL #22 – MAP TILE DATA

TUTORIAL #22 – MAP TILE DATA “Is used to define all the byte information for each 2 x 2 sized MAP TILES used on the world map”. 

All the MAP TILES in Ultima 1 are made up of 2 bytes wide by 16 byte deep, that are drawn in memory regions which corresponds to locations on the screen.  Each individual map tile is a two byte wide shape and when they are read from the data string it is referenced by a number from 0 to 15 or the HEX equivalent to $00 thru $0F.

 

The following are the order in which the tiles are referenced:

 

0 = SHIP

1 = RAFT

2 = PLAINS

3 = TREES

4 = CASTLE

5 = TOWN

6 = SIGNPOST

7 = FIGHTER or main character

8 = TROLL

9 = DUNGEON ENTRANCE

10 = CART

11 = HORSE

12 = SPEEDER

13 = SPACE SHIP

14 = OCEAN

15 = DUNGEON

 

Since there are 82 horizontal line that make up the Ultima 1 world map, you will see a data string represented by a MAP## going from MAP1 all the way to MAP82.

 

To break down how each MAP TILE DATA STRING is read by the program I will use MAP70 as an example.

 

 

This example will be the same for all the MAP TILE DATA STRINGS!

 

First, you see the MAP70 with correlates to the 70^th line on the World Map that will be shown on the screen.

 

Second, you see DFB which stands for Defined Byte for a defined data string.  So everything after the DFB will represent the MAP TILES for the entire horizontal 70^th line of the World Map.

 

Third, the first HEX value after the DFB will represent the number of HEX values that make up the entire MAP DATA string for MAP70.  So $1E in this case is equal to the decimal value of 30, which if you count all the HEX values after the $1E will give you a total of 30 HEX values!  The program uses this number to verify how many HEX values it can read in the DATA STRING before it gets to the end, without this HEX verifier it would cause the program to error by continuing to read the data string and not knowing where to end its read function.

 

Fourth, all the 30 HEX values after the $1E represent the amount and type of each MAP TILE shown on the world map.  So for this example, the first $FE represent F = 15 and the E = OCEAN TILES.  That is, there are 15 OCEAN TILES at the start of World Map horizontal line 70!  The next amount and type of MAP TILE would be $1E or [1] OCEAN TILE.  Then you have [3] PLAINS TILES, [1] TREE TILE, [1] PLAINS TILE, [7] OCEAN TILES, [13] PLAINS TILES, [6] OCEAN TILES, [3] TREES TILES, [1] OCEAN TILE, [3] PLAINS TILES, [1] TREES TILE, [3] PLAINS TILES, [9] OCEAN TILES, [1] DUNGEON TILE, [4] PLAINS TILES, [2] DUNGEON TILES, [15] OCEAN TILES, [13] OCEAN TILES, [4] TREES TILES, [1] PLAINS TILE, [14] OCEAN TILES, [4] TREES TILES, [8] OCEAN TILES, [5] DUNGEON TILES, [14] OCEAN TILES, [3] PLAINS TILES, [3] OCEAN TILES, [3] PLAINS TILES, and [11] OCEAN TILES.  All of these data reference types make up the entire horizontal line for MAP row 70!

 

The reason this was created this way was the compression system I was talking about earlier in the blog.  By doing each data string in this way I was able to save thousands of memory locations, which in turn allow me to have more programs on the disk.

 

To try and write this without the data compression would cause me to store each of these bytes in a separate memory location and if you add up all the type of each MAP TILE you would get just for this horizontal line alone, 171 bytes. Now multiply that by 82 horizontal map line and you can see that this is a lot of memory usages wasted!  Remember, assembly language stores everything in a cells which are a $## HEX value of bytes, which are only readable up to 256 in numerical value.

 

This example is read exactly the same for each MAP DATA STRING from 1 to 82 so I’m not going to show each code line like I have been doing in the past because it is just easier to show each image from the lines of code that make up the MAP lines from MAP1 to MAP82.

 

As always, if you have any questions please email me at:

Joe “kingspud”