Ultimate Amiga

Please login or register.

Login with username, password and session length
Advanced search  
Pages: [1] 2 3   Go Down

Author Topic: Hacking: A Guide to the Data-Structure of Bloodwych  (Read 49573 times)

0 Members and 14 Guests are viewing this topic.

Hungry Horace

  • Amorphous Blue-Blob Man
  • Site Admin
  • A4000T
  • ******
  • Karma: 307
  • Offline Offline
  • Gender: Male
  • Posts: 3,364
  • Don't forget... Ameboid's need love too!
    • AUW
Hacking: A Guide to the Data-Structure of Bloodwych
« on: January 23, 2011, 10:12:15 PM »

Hacking : General Overview

The intention of this section is to provide a reference for all the information known about the Bloodwych data structure.

I have attempted to compile as much knowledge about how the game binary can be modified and where possible show where this data is  shared within save games. It is my hope, that with this, more life can be breathed into the game and I have the goal of hopefully one day creating a completely new set of dungeons for Bloodwych.


This research has all been done using the Amiga version of the game, although where known, reference will be made to where data is shared between other 16-bit versions (PC and Atari) , and is in no way complete.

Where reference to memory locations is given, ($EAD4) will represent a memory location, which (unless stated) is the location in the memory of an Amiga 500 512k with kickstart 1.3 booting from the Bloodwych_103.ipf SPS release. BloodwychDataDisksVol.1 _43 is used for the Extended Levels.

A location given as [$656] refers to the location of the data within the Bloodwych binary itself, found in the 'c/' folder of the original disk.

Bloodwych is referred to as BW for short-hand, and The Extended Levels Volume 1 is referred to as BEXT .

The game binaries are here; BLOODWYCH  BEXT


The resource is broken down into the following sections;

      Map-Data Structure
          Map-Location Data - (0) Spaces
          Map-Location Data - (1) Stone Walls
          Map-Location Data - (2) Wooden Walls
          Map-Location Data - (3) Misc.
          Map-Location Data - (4) Stairs
          Map-Location Data - (5) Metal Doors
          Map-Location Data - (6) Pads, Triggers & Holes
          Map-Location Data - (7) Magic Locations

      Map-Location Data Table
      Pad / Floor Traps & Triggers
      Switches  
      Teleportation Gems
      Tower Entrance / Exit Locations
      Wall Scrolls

      Object Data Structure
      BW Object Lookup Table
      BEXT Object Lookup Table

      Monster Data Structure
      Monster Lookup Table

      BW Champion Data Structure
      BEXT Champion Data Structure
      BW Pockets Data Structure
      BEXT Pockets Data Structure

      Menu Layout
      Keyboard Controls

      Joystick / Mouse Control
      Quickstart Defaults
      Keyboard Reading Routines
« Last Edit: June 07, 2011, 12:22:43 AM by Hungry Horace »
Logged
Quote from: KillerGorilla
because winuae is made of code and your amiga is made of stuff

Hungry Horace

  • Amorphous Blue-Blob Man
  • Site Admin
  • A4000T
  • ******
  • Karma: 307
  • Offline Offline
  • Gender: Male
  • Posts: 3,364
  • Don't forget... Ameboid's need love too!
    • AUW
Re: Hacking: A Guide to the Data-Structure of Bloodwych
« Reply #1 on: January 23, 2011, 10:22:04 PM »

Hacking : Map-Data Structure

The main structure of a the BW map data, is contained with a $1000 byte block for each Tower or Dungeon.

In the PC version of the game, this is found as a self contained .map file.

In the Amiga and ST versions, these blocks are found at various offsets in the BW game binary - see Data Locations below.


Data Definition:

Each block contains $38 bytes of 'header' data, giving information about the layout of the Tower / Dungeon, this is then followed by $FC8 bytes of data containing the map data itself.

$00-$07 : contain the Width values of the respective Floors of the the Tower, starting with the lowest floor.
$08-$0F : contain the Height values of the respective Floors of the the Tower, starting with the lowest floor.

$10-$1F : are used to contain the offset values of the respective Floors of the the Tower, starting with the lowest floor - these are equivalent to the offset values used to assign the position of objects within a map (see: Object Data Structure)

$20-$27 : contain the X-alignment values in relation to each other floor,  for each of the respective Floors of the the Tower, starting with the lowest floor.
$28-$2F : contain the Y-alignment values in relation to each other floor,  for each of the respective Floors of the the Tower, starting with the lowest floor.

$30-31 : contains the width of one specifically specified floor for each tower - the relevance of this is unknown.
$32-33 : contains the height of one specifically specified floor for each tower. (as above)
$34-35 : contains the offset value of one specifically specified floor for each tower. (as above)

$36-37 : contains the number of the top floor of the tower.

$38-$0FFF : contain the map data for the tower.


Data Locations: (Amiga - IPF: 102)

[$0EC7C]    The Keep    
[$1007E]    Serpent Tower    
[$11480]    Moon Tower    
[$12882]    Dragon Tower    
[$13C84]    Chaos Tower    
[$15086]    Zendicks Tower


Example Data: The Keep

0C 15 0F 1F 13 04 00 00  <<< Widths of Floors 0-7
01 15 0F 1F 13 05 00 00  <<< Heights of Floors 0-7

00 00  << offset at which floor 0 begins
00 18  << offset at which floor 1 begins
03 8A  << offset at which floor 2 begins
05 4C  << offset at which floor 3 begins
0C CE  << offset at which floor 4 begins
0F A0  << offset at which floor 5 begins
0F C8  << offset at which floor 6 begins (although there is no floor 6 in the Keep)
00 00  << offset at which floor 7 begins

08 05 08 00 06 0B 00 00 <<< X offsets of Floors 0-7
05 05 08 00 06 0C 00 00 <<< Y offsets of Floors 0-7

00 15 00 15                   <<<< Width / Height of "special" floor (floor 1 for the keep)
00 18                             <<< offset at which "special" floor begins (floor 1 for the keep)

00 05                             <<<  Number of Top Floor
« Last Edit: June 18, 2011, 07:48:56 PM by Hungry Horace »
Logged
Quote from: KillerGorilla
because winuae is made of code and your amiga is made of stuff

Hungry Horace

  • Amorphous Blue-Blob Man
  • Site Admin
  • A4000T
  • ******
  • Karma: 307
  • Offline Offline
  • Gender: Male
  • Posts: 3,364
  • Don't forget... Ameboid's need love too!
    • AUW
Re: Hacking: A Guide to the Data-Structure of Bloodwych
« Reply #2 on: January 23, 2011, 10:27:02 PM »

Hacking : Map-Location Data Table


Stored as two bytes (word) per map-location; AB CD

Value for D represents one of the following map types:

          0 - Spaces
          1 - Stone Walls
          2 - Wooden Walls
          3 - Misc.
          4 - Stairs
          5 - Metal Doors
          6 - Pads, Triggers & Holes
          7 - Magic Locations

C is usually used for "generic" detail (such as N/E/S/W rotation) for wall-types which fill the space.
For map-data which is not "occupied" (e.g wood walls, trigger pads etc) , a more generic system is used for C which defines any other occupancy in that location. This can be found in the sub-section regarding 'Spaces'.

 AB are used to define the detail of the map-data. This would be such as, colours of gems used, types of doors and locks etc.
« Last Edit: June 07, 2011, 12:26:17 AM by Hungry Horace »
Logged
Quote from: KillerGorilla
because winuae is made of code and your amiga is made of stuff

Hungry Horace

  • Amorphous Blue-Blob Man
  • Site Admin
  • A4000T
  • ******
  • Karma: 307
  • Offline Offline
  • Gender: Male
  • Posts: 3,364
  • Don't forget... Ameboid's need love too!
    • AUW
Re: Hacking: A Guide to the Data-Structure of Bloodwych
« Reply #3 on: January 23, 2011, 10:28:34 PM »

Hacking : Map-Location Data - (0) Spaces

Spaces are identified within the map data, in the second byte within the location's map data word (AB CD), whereby the final digit (D) is equal to '0'.

please await post update or comment on this topic in: The Open Contribution Thread


« Last Edit: June 07, 2011, 12:39:53 AM by Hungry Horace »
Logged
Quote from: KillerGorilla
because winuae is made of code and your amiga is made of stuff

Hungry Horace

  • Amorphous Blue-Blob Man
  • Site Admin
  • A4000T
  • ******
  • Karma: 307
  • Offline Offline
  • Gender: Male
  • Posts: 3,364
  • Don't forget... Ameboid's need love too!
    • AUW
Re: Hacking: A Guide to the Data-Structure of Bloodwych
« Reply #4 on: January 23, 2011, 10:29:23 PM »

Hacking : Map-Location Data - (1) Stone Walls

Stone Walls are identified within the map data, in the second byte within the location's map data word (AB CD), whereby the final digit (D) is equal to '1'.

To best understand the definition of each wall, it is best to translate the two bytes (AB) and (CD) to binary, and consider which binary bits (right to left) contain defining information.


The Type of Wall

Bit 7 of the (CD) byte is used to determine that the wall is not 'plain' - i.e. contains a Shelf / Sign / Switch or Gem Hole, and is switched 'on' or 'off' for this purpose.

Bits 0-1 of the (AB) byte are used to allocate the wall a number from 0-3.
This number will define the type of wall in occurrence. A plain wall will use a zero here.
    0 = Shelf
    1 = Sign
    2 = Switch
    3 = Socket (Crystal/Gem Hole)


The Direction of the Wall

Any wall which is not plain, i.e. with Bit 7 of (CD) set, can face in one direction only, N/E/S/W.
Bits 4-5  of the (CD) byte,stores a 0-3 value number, which translates to the direction; N/E/S/W.


Shelves

Where a wall has been designated a shelf, there is only one parameter available.

Bit 3 of the (CD) byte, if set, will designated the shelf as "Concealed", as in how it is becomes after the use of the Conceal spell. No shelves in the original games begin in this state.

All other values are redundant.


Signs

For all wall signs, including wall Scrolls, additional information which will define the appearance of the scroll is contained with Bits 2-7 of (AB). These bits can be converted to a number, from 0-63, which will act as a reference.

Where a sign has a '0' reference value, a seeded colour sign, determined by the game itself, will be placed.

Where a sign has a reference value greater than or equal to 5, the sign will be of the 'wall text' type, and will directly link to a numbered scroll from the scroll data block. Note that the 'starting reference' (i.e. wall scroll number 1) will refer to a different section of text within the Wall Scroll Data, depending on the Tower.

The text which is linked to this particular reference number, including it's layout, is defined in a separate data-block. For information on this see: Wall Scrolls

The value defined by bits 2-7 of (AB) therefore, produces the following signs;

   0 = 'generated colour'
   1 = Serpent Sign
   2 = Dragon Sign
   3 = Moon Sign
   4 = Chaos Sign
   5-63 = Wall Scroll Sign, with reference number (value minus 5)


Switches

Where wall data is defined as a 'switch', used to trigger some other in-game event, such as the removal of another wall, there are two parameters available.

Bit 2 of the (AB) byte will determine if the switch is 'lit' or 'dim' - the 'on' value determines the switch as being dim (assume used)

Bits 3-7 of (AB) assigns the switch to a pre-defined function  These bits can be converted to a number, from 0-31, which will act as a reference to the action performed by the switch.

The action performed by the Switch / Trigger;

The action performed by this reference number is defined in a separate data-block. For information on this see: Wall Switch



Sockets (Gem / Crystal Holes)

Where wall data is defined as a 'socket', for teleportation gems, or crystals, there are two parameters available.

Bit 2 of the (AB) byte will determine if the socket is 'full' or 'empty' - the 'on' value determines the socket as being empty.

Bits 3-5 of (AB) assigns the socket to a particular type / colour. These bits can be converted to a number, from 0-7, which will determine this as follows;

   0 = Serpent Crystal
   1 = Chaos Crystal
   2 = Dragon Crystal
   3 = Moon Crystal
   4 = Grey *
   5 = Bluish
   6 = Brown *
   7 = Tan

It should be noted that the Grey and Brown gems do not appear in the game, and do not appear to operate.

The Bluish and Tan gems act as teleports, and for each tower use two location references (x/y coordinates) between which to jump. There is no 'floor' coordinate specified, and as such teleports will operate across the same floor only.

The locations specified for each pair of teleportation gems in each tower is defined in a separate data-block. For information on this see: Teleportation Gems

« Last Edit: March 22, 2014, 10:04:06 AM by Hungry Horace »
Logged
Quote from: KillerGorilla
because winuae is made of code and your amiga is made of stuff

Hungry Horace

  • Amorphous Blue-Blob Man
  • Site Admin
  • A4000T
  • ******
  • Karma: 307
  • Offline Offline
  • Gender: Male
  • Posts: 3,364
  • Don't forget... Ameboid's need love too!
    • AUW
Re: Hacking: A Guide to the Data-Structure of Bloodwych
« Reply #5 on: January 23, 2011, 10:29:43 PM »

Hacking : Map-Location Data - (2) Wooden Walls

Wooden Walls and Doors are identified within the map data, in the second byte within the location's map data word (AB CD), whereby the final digit (D) is equal to '2'.

To understand this data block, it is necessary to translate the map data word (AB CD) into a wall-data parameter by taking the first byte (AB) alone.

The value of (AB) should then be split into 4 items of data, which are read in "base 4". However, it is much easier to look at this data in Binary (base 2) in order to break it down and translate it.

So, any given number for (AB) should be represented as an 8 bit binary value, and spaced into 4 blocks, each of which represent the possible wooden walls in the North, East, South and West directions of the floor-space.

Bits 0/1 define what is present in the "north" of the location.
Bits 2/3 define what is present in the "east" of the location.
Bits 4/5 define what is present in the "south" of the location.
Bits 6/7 define what is present in the "west" of the location.


Each N/E/S/W location can then be defined as one of 4 possibilities;

00 = No wall or Door Present.
01 = Wooden Wall
10 = Wooden Door (open)
11 = Wooden Door (closed)

The status of a wooden door, as to whether or not it is locked, is defined bit 0 of the (C) parameter of the map-data. If the bit is set (i.e. true) then all wooden doors within this location are locked with a common key.

Because all doors in the location are locked by setting a single bit, there is no data within the original game maps which defines two wooden doors from a single piece of map data. Adjacent doors are always defined on separate map-data entries.


Example Data

Map-Data value $00 02  = %00 00 00 00   =  No walls / doors defined
Map-Data value $41 02 = %01 00 00 01   =  Wall to the North, Wall to the West
Map-Data value $0C 12  = %00 10 11 00   =  Closed door to the East, Locked.


Location Occupancy

The value of C determines the current occupancy of this location, as previously defined in: Map-Location Data - (0) Spaces
« Last Edit: May 21, 2012, 10:36:19 PM by Hungry Horace »
Logged
Quote from: KillerGorilla
because winuae is made of code and your amiga is made of stuff

Hungry Horace

  • Amorphous Blue-Blob Man
  • Site Admin
  • A4000T
  • ******
  • Karma: 307
  • Offline Offline
  • Gender: Male
  • Posts: 3,364
  • Don't forget... Ameboid's need love too!
    • AUW
Re: Hacking: A Guide to the Data-Structure of Bloodwych
« Reply #6 on: January 23, 2011, 10:30:20 PM »

Hacking : Map-Location Data - (3) Misc.

Two miscellaneous items are identified within the map data, in the second byte within the location's map data word (AB CD), whereby the final digit (D) is equal to '3'.

The byte (AB) defines this map-data as one of two items;

00 = Bed
01 = Pillar

All other values for this byte produce the 'bed' graphic, but it is not known if they still function correctly as a bed in-game.

It should be noted that a bed is only visible from a maxium of 2 spaces away, and as such is always contained within a room of maxium width 3 (including the bed space) in the original map-data.

It should also be noted that the bed graphic does not rotate, and is therfore always 'contained' by surrounding walls (wood or stone) in the original game's map-data, in order that it can only be approached / viewed from one direction.


Location Occupancy

The value of C determines the current occupancy of this location, as previously defined in: Map-Location Data - (0) Spaces

« Last Edit: May 23, 2012, 08:11:34 AM by Hungry Horace »
Logged
Quote from: KillerGorilla
because winuae is made of code and your amiga is made of stuff

Hungry Horace

  • Amorphous Blue-Blob Man
  • Site Admin
  • A4000T
  • ******
  • Karma: 307
  • Offline Offline
  • Gender: Male
  • Posts: 3,364
  • Don't forget... Ameboid's need love too!
    • AUW
Re: Hacking: A Guide to the Data-Structure of Bloodwych
« Reply #7 on: January 23, 2011, 10:30:47 PM »

Hacking : Map-Location Data - (4) Stairs

A staircase is identified within the map data, in the second byte within the location's map data word (AB CD), whereby the final digit (D) is equal to '4'.

To best understand the definition of the staircase, we can translate the two bytes (AB) and (CD) to binary, and consider which binary bits (right to left) contain defining information.

The type of Staircase

The type of staircase, is changeable between the 'up' type staircase, and the 'down' type stair case. This is defined in bit 0 of the (AB) byte. If the bit is 'off' the staircase goes upwards, and if the bit is 'on' the staircase goes downwards.


The Direction of the Staircase

A Staircase can face N/E/S/W,  and this is defined by bits 1-2 of the (AB) byte, which should be translated into a value from 0-3.

    0 = North
    1 = East
    2 = South
    3 = West


Additional Considerations

Although a staircase will appear the same regardless of it's direction set, it should be allocated the correct direction in order to ensure correct operation.

When leaving a floor by a staircase, the player is moved an additional space forward in the given direction. This therefore requires all maps to align staircases on each floor with one space between them in their operating direction.

As such, staircases are always surrounded by walls. If the space behind the staircase is not solid, it is possible to move backwards whilst standing on the staircase, and move into the unoccupied space. There is one occurrence of this in Bloodwych, on the staircase closest to the Chaos Tower entrance, within the Keep.


Location Occupancy

The value of C determines the current occupancy of this location, as previously defined in: Map-Location Data - (0) Spaces
« Last Edit: March 22, 2014, 03:01:19 PM by Hungry Horace »
Logged
Quote from: KillerGorilla
because winuae is made of code and your amiga is made of stuff

Hungry Horace

  • Amorphous Blue-Blob Man
  • Site Admin
  • A4000T
  • ******
  • Karma: 307
  • Offline Offline
  • Gender: Male
  • Posts: 3,364
  • Don't forget... Ameboid's need love too!
    • AUW
Re: Hacking: A Guide to the Data-Structure of Bloodwych
« Reply #8 on: January 23, 2011, 10:31:09 PM »

Hacking : Map-Location Data - (5) Metal Doors

A Metal Door is identified within the map data, in the second byte within the location's map data word (AB CD), whereby the final digit (D) is equal to '5'.

To best understand the definition of the metal door, we can translate the two bytes (AB) and (CD) to binary, and consider which binary bits (right to left) contain defining information.


Open or Closed

Whether a door is currently open or closed, is defined in bit 0 of the (AB) byte. If the bit is 'off' the door is open, and if the bit is 'on' the door is closed.


The type of Metal Door

The type of Metal Door, is changeable between the ornate, decorated metal door and the portcullis style. This is defined in bit 1 of the (AB) byte. If the bit is 'off' the door is the decorated type, and if the bit is 'on' the door is of the Portcullis type.


The direction of the Metal Door

Whether a Metal Door is facing East/West or North/South is defined in bit 2 of the (AB) byte. If the bit is 'off' the door is facing North/South, and if the bit is 'on' the door is facing East/West.


Locked Doors

Metal Doors can be locked in a variety of ways. To lock a door in such a way that a Key or other unlocking method is required, it is required that bit 4 of the (CD) byte is switched to the 'on' position first.

Once a door is locked, the type of lock will be determined by bits 4-6 of the (AB) byte. These bits can be converted to a number, from 0-7, which will determine this as follows;

   0 = Magelock
   1 = Bronze lock
   2 = Iron lock
   3 = Serpent lock
   4 = Chaos lock
   5 = Dragon lock
   6 = Moon lock
   7 = Chromatic lock


'Void' Locked Doors

Metal Doors can also be locked in a special way, depicted as a 'black' lock, which is only released via a switch / trigger. By setting bit 3 of byte (AB) to 'on' the door will be locked in this way.

Special consideration should be given to the 'general' lock setting when using void locks. In order to ensure that the door is correctly unlocked after activation of a trigger, the normal lock settings - i.e. bit 4 of the (CD) byte, should be set to 'off' and bits 4-6 of (AB) cleared.

It may be possible by leaving these standard locking options in place, and additionally including a void lock option, that once the void lock is 'cleared' by a trap/trigger, the door is left as a standard locked door. However, this is untested.


Location Occupancy

The value of C determines the current occupancy of this location, as previously defined in: Map-Location Data - (0) Spaces

« Last Edit: March 22, 2014, 04:15:25 PM by Hungry Horace »
Logged
Quote from: KillerGorilla
because winuae is made of code and your amiga is made of stuff

Hungry Horace

  • Amorphous Blue-Blob Man
  • Site Admin
  • A4000T
  • ******
  • Karma: 307
  • Offline Offline
  • Gender: Male
  • Posts: 3,364
  • Don't forget... Ameboid's need love too!
    • AUW
Re: Hacking: A Guide to the Data-Structure of Bloodwych
« Reply #9 on: January 23, 2011, 10:31:41 PM »

Hacking : Map-Location Data - (6) Pads, Triggers & Holes

A Pad / Floor Trap or Trigger is identified within the map data, in the second byte within the location's map data word (AB CD), whereby the final digit (D) is equal to '6'.

To best understand the definition of each floor location, it is best to translate the two bytes (AB) and (CD) to binary, and consider which binary bits (right to left) contain defining information.


The Type of Floor Tile

Bits 0-1 of the (AB) byte are used to allocate the floor tile a number from 0-3.
This number will define the type of floor tile in occurrence.
    0 = Spell Fizzle
    1 = Floor Hole / Pit
    2 = Green Trigger Pad
    3 = Invisible Trigger Pad


Ceiling Hole / Pit Above

All floor locations have the option of having a hole in the ceiling at the location.
This is defined by bit 2 of the (AB) byte. If the bit is 'on' the hole in the ceiling will appear.


Spell Fizzle Zone

Where a location has been designated a Spell Fizzle area, there is only one parameter available, the appearance of a pit in the ceiling, as mentioned above.

All other values are redundant.


Floor Hole / Pit

Where a location has been designated a Floor Hole / Pit, there is only one parameter available, the appearance of a pit in the ceiling, as mentioned above.

All other values are redundant.


Trigger Pad

Where bit 1 of the (AB) byte is set, it is automatically designated a 'Trigger' pad, used to trigger some other in-game event, such as the removal of another wall, there are three parameters available.

By setting bit 0 of the (AB) byte, it will determine whether this 'Trigger' pad is visible (green) or invisible. The 'on' postion designates the pad as invisible.

The appearance of a pit in the ceiling can also be determined, as mentioned above, by setting bit 2 of the (AB) byte.

The remaining bits 3-7 of (AB) assigns the 'trigger' to a pre-defined function.  These bits can be converted to a number, from 0-31, which will act as a reference to the action performed by the switch.


The action performed by a Trap / Trigger

The action performed by this reference number is defined in a separate data-block. For information on this see: Pad / Floor Traps & Triggers



Location Occupancy

The value of C determines the current occupancy of this location, as previously defined in: Map-Location Data - (0) Spaces
« Last Edit: March 22, 2014, 03:27:27 PM by Hungry Horace »
Logged
Quote from: KillerGorilla
because winuae is made of code and your amiga is made of stuff

Hungry Horace

  • Amorphous Blue-Blob Man
  • Site Admin
  • A4000T
  • ******
  • Karma: 307
  • Offline Offline
  • Gender: Male
  • Posts: 3,364
  • Don't forget... Ameboid's need love too!
    • AUW
Re: Hacking: A Guide to the Data-Structure of Bloodwych
« Reply #10 on: January 23, 2011, 10:32:05 PM »

Hacking : Map-Location Data - (7) Magic Locations


Location Occupancy

The value of C determines the current occupancy of this location, as previously defined in: Map-Location Data - (0) Spaces


please await post update or comment on this topic in: The Open Contribution Thread
« Last Edit: June 07, 2011, 12:43:40 AM by Hungry Horace »
Logged
Quote from: KillerGorilla
because winuae is made of code and your amiga is made of stuff

Hungry Horace

  • Amorphous Blue-Blob Man
  • Site Admin
  • A4000T
  • ******
  • Karma: 307
  • Offline Offline
  • Gender: Male
  • Posts: 3,364
  • Don't forget... Ameboid's need love too!
    • AUW
Re: Hacking: A Guide to the Data-Structure of Bloodwych
« Reply #11 on: January 23, 2011, 10:35:20 PM »

Hacking : Pad / Floor Traps & Triggers

When the reference number of a Pad / Trigger has been allocated in the map data (see Map-Location Data - (6) Pads, Triggers & Holes) the "action" of that reference number is defined within a 128 byte block for each tower.

Each definition is 4 bytes long, following the below AA BB CC DD structure.

In some cases, these are universally set to the same special-case throughout the game, such as with the Vivifcation Machines in BW  (ref 4 & ref 5) and spinners.

Pad / Trigger Functions (AA)

00 - NONE
02 - SPIN 180 **
04 - SPIN RANDOM **
06 - OPEN VOID-LOCK DOOR (X/Y) *
08 - VIVIFY MACHINE EXTERNAL PAD **
0A - VIVIFY MACHINE INTERNAL PAD **
0C - WOOD DOOR CLOSER #1 (SPECIAL CASE) **
0E - WOOD DOOR CLOSER #2 (SPECIAL CASE) **
10 - TRADER DOOR **
12 - TOWER ENTRANCE (SIDE PAD) (X/Y OF OPPOSITE PAD)
14 - TOWER ENTRANCE (CENTRAL PAD)
16 - REMOVE (X/Y) *
18 - CLOSE VOID-LOCK DOOR (X/Y) *
1A - TOGGLE PILLAR (X/Y) *
1C - CREATE SPINNER (OR OTHER) (X/Y) *
1E - OPEN/CREATE WALL WITH SWITCHES? (X/Y) *
20 - CREATE PAD (F/X/Y)
22 - MOVE PILLAR AT PLAYER X,Y TO PLAYER X-1,Y-1 (SPECIAL CASE) **
24 - CREATE PILLAR (X/Y) *
26 - KEEP ENTRANCE (SIDE PAD) (X/Y OF OPPOSITE PAD)
28 - KEEP ENTRANCE (CENTRAL PAD)
2A - FLASH TELEPORT (F/X/Y)
2C - ROTATE STONE WALL (X/Y) *
2E - TOGGLE WALL (X/Y) *
30 - SPINNER (UNKNOWN DIFFERENCE) (X/Y) *
32 - CLICK TELEPORT (F/X/Y)
34 - TOGGLE GREEN PAD (X/Y) *
36 - ROTATE WOOD WALL COUNTER-CLOCKWISE (X/Y) *
38 - TOGGLE HOLE (X/Y) *
3A - GAME COMPLETION PAD **
3C - REMOVE PILLAR / OTHER EVENT (X/Y) **


Pad / Trigger Parameter (BB)
Functions marked * or ** use no parameter here

For Those marked (F/X/Y);
BB is the floor on which the action is taken.


Pad / Trigger Parameter (CC DD)
Functions marked ** use no parameter here

For Those marked (X/Y);
CC is the X coordinate at which the action is taken.
DD is the Y coordinate at which the action is taken.


Special Cases

Data Locations: (Amiga - IPF: 102)
($70D0)  [$6D66] The Keep
($7140)  [$6DE6] Serpent Tower
($71D0)  [$6E66] Moon Tower
($7240)  [$6EE6] Dragon Tower
($72D0)  [$6F66] Chaos Tower
($7340)  [$6FE6] Zendik's Tower

Example Data:  The Keep
00000000 - none
02000000 - special case - spin 180
04000000 - special case - spin random
06000E06 - ref 03 / 1B - open black-locked metal door @ x0E y06
08000000 - ref 04 / 23 - special case - vivify machine external
0A000000 - ref 05 / 2A - special case - vivify machine internal
0C000000 - ref 06 / 32 - special case - bluish gemhole wood doors closer @ (hardcoded x,y)
0E000000 - ref 07 / 3A - special case - tan gemhole wood doors closer @ (hardcoded x,y)
06001403 - ref 08 / 42 - open black-locked metal door @ x04 y03
10000000 - ref 09 / 4B - special case - trader door (closes Northwards wood door in location to the left)
12020A01 - ref 10 / 52 - serpent tower entrance left
14040000 - ref 11 / 5A - serpent tower entrance middle
12030801 - ref 12 / 62 - serpent tower entrance right
12040A11 - ref 13 - 6A - moon tower entrance right
14080000 - ref 14 - 72 - moon tower entrance middle
12050811 - ref 15 - 7A - moon tower entrance left
1206110A - ref 16 - 82 - dragon tower entrance right
140C0000 - ref 17 - 8A - dragon tower entrance middle
12071108 - ref 18 - 92 - dragon tower entrance left
1208010A - ref 19 - 9A - chaos tower entrance right
14100000 - ref 20 - A2 - chaos tower entrance middle
12090108 - ref 21 - AA - chaos tower entrance left
120A0103 - ref 22 - B2 - zendik tower entrance right
14140000 - ref 23 - BA - zendik tower entrance middle
120B0101 - ref 24 - C2 - zendik tower entrance left
16000002 - ref 25 / CB - remove pillar @ x00 y02
16000202 - ref 26 / D3 - remove pillar @ x02 y02
00000000 - unused
00000000 - unused
00000000 - unused
00000000 - unused
00000000 - unused


« Last Edit: June 18, 2011, 07:49:33 PM by Hungry Horace »
Logged
Quote from: KillerGorilla
because winuae is made of code and your amiga is made of stuff

Hungry Horace

  • Amorphous Blue-Blob Man
  • Site Admin
  • A4000T
  • ******
  • Karma: 307
  • Offline Offline
  • Gender: Male
  • Posts: 3,364
  • Don't forget... Ameboid's need love too!
    • AUW
Re: Hacking: A Guide to the Data-Structure of Bloodwych
« Reply #12 on: January 23, 2011, 10:37:37 PM »

Hacking : Wall Switches

When the reference number of a switch has been allocated in the map data (see Map-Location Data - (1) Stone Walls) the "action" of that reference number is defined within a 64 byte block for each tower.

Each definition is 4 bytes long, following the below AA BB CC DD structure.

Switch Functions (AA)

02 - REMOVE
04 - TOGGLE STONE WALL
06 - OPEN VOID-LOCK DOOR
08 - ROTATE BRICK WALL
0A - TOGGLE PILLAR
0C - PLACE PILLAR
0E - ROTATE WOOD WALLS

Switch Parameter (BB)
Always unused

Switch Parameter (CC DD)

CC is the X coordinate at which the action is taken.
DD is the Y coordinate at which the action is taken.

Because the floor is never specified as a parameter for any of the switch actions, switch functions can be cleverly re-used on multiple floors of a dungeon to increase the variety of of puzzles.

Data Locations: (Amiga - IPF: 102)

[$5860] The Keep
[$58A0] Serpent Tower
[$58E0] Moon Tower
[$5920] Dragon Tower
[$5960] Chaos Tower
[$59A0] Zendick's Tower


Example Data:  The Keep
00000000 - ref 0 - no action
02000108 - ref 1 - remove pillar @ x01 y08
02001101 - ref 2 - remove pillar @ x11 y01
02000607 - ref 3 - remove pillar @ x06 y07
0200020C - ref 4 - remove wall @ x02 y0C
02000109 - ref 5 - remove wall @ x01 y09
04000901 - ref 6 - toggle wall @ x09 y01
00000000 - ref 7 - no action
00000000 - ref 8 - no action
0200151E - ref 9 - remove @ x15 y1E
02000B08 - ref 10 - remove @ x0B y08
02000E02 - ref 11 - remove @ x0E y02
02000C04 - ref 12 - remove @ x0C y04
0200110C - ref 13 - remove @ x11 y0C
02001117 - ref 14  - remove @ x11 y17
00000000 - ref 15 - no action
« Last Edit: June 18, 2011, 07:50:00 PM by Hungry Horace »
Logged
Quote from: KillerGorilla
because winuae is made of code and your amiga is made of stuff

Hungry Horace

  • Amorphous Blue-Blob Man
  • Site Admin
  • A4000T
  • ******
  • Karma: 307
  • Offline Offline
  • Gender: Male
  • Posts: 3,364
  • Don't forget... Ameboid's need love too!
    • AUW
Re: Hacking: A Guide to the Data-Structure of Bloodwych
« Reply #13 on: January 23, 2011, 10:40:05 PM »

Hacking : Teleportation Gems

Data Definition:

The locations for the Tan & Bluish Gem teleports are stored in two consecutive 24 byte blocks.

Each gem has two locations for each tower, stored as a single X / Y coordinate. As a result, teleport Gems are only used on one floor for each tower in the original games, although it would be possible to be used on more than one floor, they would need to be located at the same X / Y coordinates on each floor.

The X / Y locations referred to are the location at which the player is standing when using the Gem. Transfer of the Gem item to the correct Wall-Socket is handled automatically.


Data Locations: (Amiga - IPF: 102)

Tan Gem: ($5B4C) [$57E2]
Bluish Gem: ($5B64) [$57FA]


Example Data: Tan Gem

01 00 - The Keep - Location 1
05 00 - The Keep - Location 2
11 11 - Serpent Tower - Location 1
07 02 - Serpent Tower - Location 2
09 12 - Moon Tower - Location 1
12 00 - Moon Tower - Location 2
0E 0D - Dragon Tower - Location 1
0B 03 - Dragon Tower - Location 2
0A 03 - Chaos Tower - Location 1
08 0C - Chaos Tower - Location 2
04 11 - Zendik's Tower - Location 1
0B 09 - Zendik's Tower - Location 2


Example Data: Bluish Gem

0C 0C - The Keep - Location 1
0B 0A - The Keep - Location 2
0C 0E - Serpent Tower - Location 1
04 03 - Serpent Tower - Location 2
0B 12 - Moon Tower - Location 1
02 00 - Moon Tower - Location 2
0C 0D - Dragon Tower - Location 1
09 03 - Dragon Tower - Location 2
0C 02 - Chaos Tower - Location 1
0C 11 - Chaos Tower - Location 2
00 11 - Zendik's Tower - Location 1
08 02 - Zendik's Tower - Location 2
« Last Edit: June 18, 2011, 07:53:49 PM by Hungry Horace »
Logged
Quote from: KillerGorilla
because winuae is made of code and your amiga is made of stuff

Hungry Horace

  • Amorphous Blue-Blob Man
  • Site Admin
  • A4000T
  • ******
  • Karma: 307
  • Offline Offline
  • Gender: Male
  • Posts: 3,364
  • Don't forget... Ameboid's need love too!
    • AUW
Re: Hacking: A Guide to the Data-Structure of Bloodwych
« Reply #14 on: January 23, 2011, 10:41:49 PM »

Hacking : Tower & Dungeon Entrances and Exits

Tower Entrance Locations


Located at ($7564) [$71FA] : 0000 0000 0107 0307 0101 0301 0101 0103 0701 0703 0607 0609

- 00 00 | 00 00 - not used
- 01 07 | 03 07 - Serpent Tower door pads
- 01 01 | 03 01 - Moon Tower door pads
- 01 01 | 01 03 - Dragon Tower door pads
- 07 01 | 07 03 - Chaos Tower door pads
- 06 07 | 06 09 - Zendik Tower door pads


Keep Entrances / Tower Exits

Located at ($7446) [$70DC] : 00 04 04 04 04 05

00 - not used
04 - Returning Floor from Serpent Tower
04 - Returning Floor from Moon Tower
04 - Returning Floor from Dragon Tower
04 - Returning Floor from Chaos Tower
05 - Returning Floor from Zendik's Tower


Located at ($744C) [$70E2] : 0801 0A01 0811 0A11 1108 110A 0108 010A 0101 0103

- 08 01 | 0A 01 - Return Pad Locations from Serpent Tower into The Keep
- 08 11 | 0A 11 - Return Pad Locations from Moon Tower into The Keep
- 11 08 | 11 0A - Return Pad Locations from Dragon Tower into The Keep
- 01 08 | 01 0A - Return Pad Locations from Chaos Tower into The Keep
- 01 01 | 01 03 - Return Pad Locations from Zendik's Tower into The Keep

Logged
Quote from: KillerGorilla
because winuae is made of code and your amiga is made of stuff

Pages: [1] 2 3   Go Up
 

TinyPortal 2.2.2 © 2005-2022