Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[murlock]

Sweet

It's always cool to see the nifty tricks devs had to do with their data structures. Keep forgetting we are spoiled today with the tools we have.

[Hungry Horace]

And more!!


the attached three pictures should explain the floor-offset thing a bit better.

basically the white grid is the current floor we are editing (floor 4) and the dark-grey grid is the floor below (floor 3)

- when both floors are offsetted to 0,0, they are in-line, at in the top left of the editing area.
- when the offset of floor 4 is changed to 1,1 (picture 2) the stacking of the two grids changes, and the floor is no longer in-line with the top left of the editing area.
- in picture 3, i have adjusted the offset of floor 3 to 2,2... but we are still viewing from floor 4 (for the sake of reference) ... we can see here a further push away from that top corner.


Although my editor puts limitations on offsets of floors, in order to keep everything on the editable screen, I *beleive* that in-theory you could use vastly higher offset values (just as you could floor sizes, which i do not allow) , with only a very small overlap. This would mean that you could continually move further and further from your original start position.

There's no real reason to do this however, other than "because you can".

[Hungry Horace]

Hope this is all helping.

Was really interesting to read those differences in the amiga and ST files.... i havent yet exported the "common format" from any of the later versions of the Amiga BW binary though (it would require a fair bit of jigeery pokery in my editor to do that) - perhaps some of those may be the same as the ST though... who knows.


Is there any chance you could post a copy of the main ST binary file here so I can have a peek through it with my hex editor? I especially want to have a look for that woodtrap stuff because thats hard-coded into some of the 68000 asm code.

[Hungry Horace]

Header Data for The Keep

Code: [Select]

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

Post: Hacking : Map-Data Structure now updated with this info


edit 2: this also tells us that the ST version has the starting floor (3) as the "special" floor in the Keep, unlike the Amiga version having Floor 1 (aka The Maze), and that this and the bronze key door are our only differences!

[murlock]

Doh, just typed a reply and lost it because the forum didn't like my attachment...

Anyway, have now attached "CODE" as "CODE.txt" but it's really just the main binary.

Not sure what version of ST bloodwych it is, other than it's a true STX image of an original disk - not a trainer or demo.

Your offset explanation makes perfect sense - hoping to get some more time to work on my code later this week.

Is there any significance to the "special" floor, any why it would be different between ST/Amiga?
And what are the wood traps?

Below are the ST addresses for this binary:

From      To      Ingest      Notes
0x00000   0x589D   No   Unknown
0x0589E   0x058DD   Yes   Buttons K
0x058DE   0x0591D   Yes   Buttons S
0x0591E   0x0595D   Yes   Buttons M
0x0595E   0x0599D   Yes   Buttons D
0x0599E   0x059DD   Yes   Buttons C
0x059DE   0x0601D   Yes   Buttons Z
0x0601E   0x06DB3   No   Unknown
0x06DB4   0x06E33   Yes   Triggers K
0x06E34   0x06EB3   Yes   Triggers S
0x06EB4   0x06F33   Yes   Triggers M
0x06F34   0x06FB3   Yes   Triggers D
0x06FB4   0x07033   Yes   Triggers C
0x07034   0x070B3   Yes   Triggers Z
0x070B4   0x0EE3B   No   Unknown
0x0EE3C   0x1023D   Yes   Floors And Objects K ($28 bytes other header data still to account for)
0x1023E   0x1163F   Yes   Floors And Objects S
0x11640   0x12A41   Yes   Floors And Objects M
0x12A42   0x13E43   Yes   Floors And Objects D
0x13E44   0x15245   Yes   Floors And Objects C
0x15246   0x16647   Yes   Floors And Objects Z
0x16648   0x17474   No   Unknown
0x17474   0x17476   Yes   Monster Count K
0x17476   0x17478   Yes   Monster Count S
0x17478   0x1747A   Yes   Monster Count M
0x1747A   0x1747C   Yes   Monster Count D
0x1747C   0x1747E   Yes   Monster Count C
0x1747E   0x1747F   Yes   Monster Count Z
0x17480   0x1777F   Yes   Monsters K
0x17780   0x17A7F   Yes   Monsters S
0x17A80   0x17D7F   Yes   Monsters M
0x17D80   0x1807F   Yes   Monsters D
0x18080   0x1837F   Yes   Monsters C
0x18380   0x1867F   Yes   Monsters Z
0x18680   0x590FA   No   Unknown

[Hungry Horace]

the "woodtraps" are my name for the wooden doors that are automatically closed behind you and effectively "locked" by the clever use of two sets of doors.

These only occur once, in the Keep, for the two gem-hole rooms on Floor 2. However, they are are hardcoded in 68K ASM to affect a particular X/Y coord.. it's this coord in the ASM code that is is stored and can be edited.

I've just done a quick search, and the ASM code is the same on both versions  

the address of woodtrap 1 coord is:  $7442 (ST) (values: 000D000C) and $745A (ST) (values: 00030000) for woodtrap 2


i have no idea what the significance of a special floor is, or why it should differ on each version. Perhaps we should list the special floors of each Tower and then see if we can guess at what is common between them all?

I hope to have a list of all the ST addresses soon, with support added to my editor

[Hungry Horace]

ok, i worked out all the addresses, but i'm getting some wierd things happen.

1) all the addresses you gave me were $4 bytes out.
2) The serpent tower void-lock doors at the start are rotated the wrong direction (yet i thought you had done a comparison on the .map files, with only differences in the Keep?)
3) one of the floors (4) of the Chaos tower seems really screwed up!
4) one of the bluish-gem [positions in the Keep aligns to x0B y0D instead of x0B y0A like it should.
5) the Monster data seems to "slip out" by 1 byte between the dragon and chaos towers... see the addresses below.

I dont know if calling it .txt caused a problem on the download - the file i used was 364773 long (which seems strange in itself, to have an odd-number length file) .... perhaps you could zip the file first then upload it?

Code: [Select]

BW_ST:

LOOKUPTOWER(0)=$EE38 : Rem -- mod0.map
LOOKUPTOWER(1)=$1023A : Rem -- serp.map
LOOKUPTOWER(2)=$1163C : Rem -- moon.map
LOOKUPTOWER(3)=$12A3E : Rem -- drag.map
LOOKUPTOWER(4)=$13E40 : Rem -- chaos.map
LOOKUPTOWER(5)=$15242 : Rem -- zendik.map

LOOKUPSWITCHES(0)=$589E : Rem -- mod0.switches
LOOKUPSWITCHES(1)=$58DE : Rem -- serp.switches
LOOKUPSWITCHES(2)=$591E : Rem -- moon.switches
LOOKUPSWITCHES(3)=$595E : Rem -- drag.switches
LOOKUPSWITCHES(4)=$599E : Rem -- chaos.switches
LOOKUPSWITCHES(5)=$59DE : Rem -- zendik.switches

LOOKUPTRIGGERS(0)=$6DB4 : Rem -- mod0.triggers
LOOKUPTRIGGERS(1)=$6E34 : Rem -- serp.triggers
LOOKUPTRIGGERS(2)=$6EB4 : Rem -- moon.triggers
LOOKUPTRIGGERS(3)=$6F34 : Rem -- drag.triggers
LOOKUPTRIGGERS(4)=$6FB4 : Rem -- chaos.triggers
LOOKUPTRIGGERS(5)=$7034 : Rem -- zendik.triggers

LOOKUPOBJECTS(0)=LOOKUPTOWER(0)+$1002 : Rem --  mod0.ob +2
LOOKUPOBJECTS(1)=LOOKUPTOWER(1)+$1002 : Rem -- serp.ob +2
LOOKUPOBJECTS(2)=LOOKUPTOWER(2)+$1002 : Rem -- moon.ob +2
LOOKUPOBJECTS(3)=LOOKUPTOWER(3)+$1002 : Rem -- drag.ob +2
LOOKUPOBJECTS(4)=LOOKUPTOWER(4)+$1002 : Rem -- chaos.ob + 2
LOOKUPOBJECTS(5)=LOOKUPTOWER(5)+$1002 : Rem -- zendik.ob +2

LOOKUPHARDCODE1=$7442 : Rem -- woodtrap1.location  
LOOKUPHARDCODE2=$745A : Rem -- woodtrap2.location  

LOOKUPGEMTAN=$5820 : Rem -- gem-tan.locations
LOOKUPGEMBLU=$5838 : Rem -- gem-blu.locations

LOOKUPDUNGEONSTART=$7248 : Rem -- dungeon.entrances

LOOKUPKEEPFLOORSTART=$712A : Rem -- keep.entrances
LOOKUPKEEPSTART=LOOKUPKEEPFLOORSTART+$6

LOOKUPMONSTERCOUNT=$17470 : Rem -- monsters.totals

LOOKUPMONSTER(0)=$1747C : Rem -- mod0.monsters
LOOKUPMONSTER(1)=$1777C : Rem -- serp.monsters
LOOKUPMONSTER(2)=$17A7C : Rem -- moon.monsters
LOOKUPMONSTER(3)=$17D7C : Rem -- drag.monsters
LOOKUPMONSTER(4)=$1807B : Rem -- chaos.monsters
LOOKUPMONSTER(5)=$1837B : Rem -- zendik.monsters


LOOKUPCHAMPIONSTATS=$E812 : Rem -- champions.stats
LOOKUPCHAMPIONPOCKETS=$EA12 : Rem -- champions.pockets

LOOKUPWALLSCROLLREF=$1A212 : Rem -- scrolls.block
LOOKUPWALLSCROLLTEXT=LOOKUPWALLSCROLLREF+$92


Rem --  internal data, reference only.

LOOKUPSPELLTEXT=$19D84 : Rem --   spell names, armour terror etc
LOOKUPSPELLNAME=$1867B : Rem -- maryhadalittlelaaneeitwerragudd
LOOKUPNAMES=$D8F6 : Rem -- champion names (first occurance)

Return

edit:  i tried a quick and dirty hack of a .ST disk image (equinox crack) and found that it did not have the same differences as the file i downloaded above:

- the bronze door at the start of the game was normal!
- the chaos tower was fine
- the monster-lists were now equally spaced. ($300 each)

i definitely think there is something up with that file!!

I am also changing the output of the woodtrap 1/2 data (to include the preceding 4 bytes, even though they are never edited) to make it easier to locate this data in different versions..... The idea being, i may create a program to read in say... 6 bytes of my normal "output" files, then search for where this data is within a disk image or other binary.... this would mean i could add additional support for images, versions, etc much quicker.

[murlock]

Yep I definitely think something went awry uploading to the forum. I'll zip it and re-upload it when I get home later.

I'm pretty certain that there must've been multiple versions released for the ST, as the start screen on my version shows F9/F10 for load/save, whereas my "real" ST 3.5 disk version (long lost now) never had that feature.

That bronze key difference is a weird one, but it kind of makes sense in the logic, I think it goes something like NoLock, MageLock, VoidLock, BronzeLock over a certain byte combo. My memory fails me but I'll dig the logic out later.

I like the idea of writing a "searcher" based on known byte strings. I might add this to my TODO list, as eventually I could removing the hard-coding on ingesting ST data and make it more configurable for any binary passed in.

[murlock]

Reattached CODE in ZIP, should be 364,794 bytes

Here is my code for parsing a Metal Door Cell (i.e. D = 5)

It's all based on A, except when A=0, then there are checks on B and C too.
You can see how the Bronze key fits snugly into args.B >= 0x8 && args.C == 0x1
Maybe the developer initially had another type of lock in mind? Regardless it's only the special bronze door on the Atari ST that uses this case.

switch (args.A)
            {
                case 0x0:
                    if (args.B < 0x8 && args.C == 0x0)
                    {
                        LockState = EnumLockState.NoLock;
                    }
                    else if (args.B < 0x8 && args.C == 0x1)
                    {
                        LockState = EnumLockState.MageLock;
                    }
                    else if (args.B >= 0x8 && args.C == 0x0)
                    {
                        LockState = EnumLockState.VoidLock;
                    }
                    else if (args.B >= 0x8 && args.C == 0x1)
                    {
                        LockState = EnumLockState.BronzeKey;
                    }
                    break;
                case 0x1:
                    LockState = EnumLockState.BronzeKey;
                    break;
                case 0x2:
                    LockState = EnumLockState.IronKey;
                    break;
                case 0x3:
                    LockState = EnumLockState.SerpentKey;
                    break;
                case 0x4:
                    LockState = EnumLockState.ChaosKey;
                    break;
                case 0x5:
                    LockState = EnumLockState.DragonKey;
                    break;
                case 0x6:
                    LockState = EnumLockState.MoonKey;
                    break;
                case 0x7:
                    LockState = EnumLockState.ChromaticKey;
                    break;

            }

[Hungry Horace]

i cant check right now,  (at work) but i suspect on the Amiga version this door will be openined with the serpent wand or something (the next item in the item list)... i seem to remember managing to do that myself when investigating data!!

my editor presently marks it as a "void" door rather than invalid.

[Hungry Horace]

i've adapted my editor to read the (now correct!!) binary file, which is great

I guess i will need a copy of the ST extended levels file soon!

I've attached a ZIP file with all of the files outputed using the ST version.


The ST bronze door is definitely a void-lock on the amiga version (see attached)... so it's a "non common" rule and I wont be letting my editor create that kind of data.  I guess if i'm going to play-through the ST data (to see if the special floor affects anything) i will need to manually fix this!


and here are the all-important address:

Code: [Select]

BW_ST:

LOOKUPTOWER(0)=$EE3C : Rem -- mod0.map
LOOKUPTOWER(1)=$1023E : Rem -- serp.map
LOOKUPTOWER(2)=$11640 : Rem -- moon.map
LOOKUPTOWER(3)=$12A42 : Rem -- drag.map
LOOKUPTOWER(4)=$13E44 : Rem -- chaos.map
LOOKUPTOWER(5)=$15246 : Rem -- zendik.map

LOOKUPSWITCHES(0)=$589E : Rem -- mod0.switches
LOOKUPSWITCHES(1)=$59DE : Rem -- serp.switches
LOOKUPSWITCHES(2)=$591E : Rem -- moon.switches
LOOKUPSWITCHES(3)=$595E : Rem -- drag.switches
LOOKUPSWITCHES(4)=$599E : Rem -- chaos.switches
LOOKUPSWITCHES(5)=$59DE : Rem -- zendik.switches

LOOKUPTRIGGERS(0)=$6DB4 : Rem -- mod0.triggers
LOOKUPTRIGGERS(1)=$6E34 : Rem -- serp.triggers
LOOKUPTRIGGERS(2)=$6EB4 : Rem -- moon.triggers
LOOKUPTRIGGERS(3)=$6F34 : Rem -- drag.triggers
LOOKUPTRIGGERS(4)=$6FB4 : Rem -- chaos.triggers
LOOKUPTRIGGERS(5)=$7034 : Rem -- zendik.triggers

LOOKUPOBJECTS(0)=LOOKUPTOWER(0)+$1002 : Rem --  mod0.ob +2
LOOKUPOBJECTS(1)=LOOKUPTOWER(1)+$1002 : Rem -- serp.ob +2
LOOKUPOBJECTS(2)=LOOKUPTOWER(2)+$1002 : Rem -- moon.ob +2
LOOKUPOBJECTS(3)=LOOKUPTOWER(3)+$1002 : Rem -- drag.ob +2
LOOKUPOBJECTS(4)=LOOKUPTOWER(4)+$1002 : Rem -- chaos.ob + 2
LOOKUPOBJECTS(5)=LOOKUPTOWER(5)+$1002 : Rem -- zendik.ob +2

LOOKUPMONSTERCOUNT=$17474 : Rem -- monsters.totals

LOOKUPMONSTER(0)=$17480 : Rem -- mod0.monsters
LOOKUPMONSTER(1)=$17780 : Rem -- serp.monsters
LOOKUPMONSTER(2)=$17A80 : Rem -- moon.monsters
LOOKUPMONSTER(3)=$17D80 : Rem -- drag.monsters
LOOKUPMONSTER(4)=$18080 : Rem -- chaos.monsters
LOOKUPMONSTER(5)=$18380 : Rem -- zendik.monsters


Rem ----

LOOKUPHARDCODE1=$7442 : Rem -- woodtrap1.location 
LOOKUPHARDCODE2=$744C : Rem -- woodtrap2.location 

LOOKUPGEMTAN=$5820 : Rem -- gem-tan.locations
LOOKUPGEMBLU=$5838 : Rem -- gem-blu.locations

LOOKUPDUNGEONSTART=$7248 : Rem -- dungeon.entrances

LOOKUPKEEPFLOORSTART=$712A : Rem -- keep.entrances
LOOKUPKEEPSTART=LOOKUPKEEPFLOORSTART+$6

LOOKUPCHAMPIONSTATS=$E816 : Rem -- champions.stats
LOOKUPCHAMPIONPOCKETS=$EA16 : Rem -- champions.pockets

LOOKUPWALLSCROLLREF=$1A218 : Rem -- scrolls.block
LOOKUPWALLSCROLLTEXT=LOOKUPWALLSCROLLREF+$92


Rem --  internal data, reference only.

LOOKUPSPELLTEXT=$18680 : Rem -- maryhadalittlelaaneeitwerragudd
LOOKUPSPELLNAME=$19D8A : Rem --   spell names, armour terror etc 

LOOKUPNAMES=$D8FA : Rem -- champion names (first occurance)

Return


[Hungry Horace]

i've just had a thought.... is there any chance this Bronze Door is part of the copy protection?

The Equinox Crack on the ST doesnt have this different data (the door is the same as on the amiga) - perhaps if the copy protection is "passed" then the value of this door is changed? Have you tried making a copy of the disk , to standard DOS disk and seeing what happens?   It's the perfect location for something like this - you get to "see" the game but not actually get anywhere.

Does any ST emulator let you monitor the address this is loaded to in memory, so you can see when (if) it is changed.... what is the value of this map-data in memory once the game is started?

questions and thoughts

[murlock]

I have the CODE file for the Extended levels too, so will zip and post that over later on.

Started writing a rudimentary byte searcher to find the bytes that make "The key of hue is what i'm due" (including all the bytes for offsets, line breaks, etc.), which seems to be working ok. So I might extend this next to search a given file for all the byte strings - so it is easy to identify offsets in a file.

I'm also going to break out my hard coding of addresses into a configurable file, so you can choose which set of offsets to use easily.

That's a good point about the bronze key door - when I get a chance I'll modify the bytes in my ST binary and try and run it through STEEM emulator, just to see what happens.

It might just be a quirk of an early version of Bloodwych, which was resolved in later versions. Same with the special floor.

[Hungry Horace]

I'm also going to break out my hard coding of addresses into a configurable file, so you can choose which set of offsets to use easily.

a configurable file was what i have been starting to consider.... and those files can be generated by scanning a file for all the correct addresses. I am only identifying my files  by size at the moment though... perhaps later i will consider a better/proper way of identifying a file to be edited.

Whilst it would be nice to do "live" scanning when trying to edit a file, I am limited by the fact I am still writing the editor as an amiga program! (although i recommend running it on UAE with acceleration anyway)

It might just be a quirk of an early version of Bloodwych, which was resolved in later versions. Same with the special floor.

i would think if that were the case, the special floors shouldnt be in  extended levels as well.... iirc, they are :S

[murlock]

configurable file was what i have been starting to consider.... and those files can be generated by scanning a file for all the correct addresses. I am only identifying my files  by size at the moment though... perhaps later i will consider a better/proper way of identifying a file to be edited.

Yep, I'm thinking of basically something like: NiceName, FileName, Offsets. Given I have the luxury of .NET, either in XML or JSON. Possibly just having 1 main config file that you can add multiple definitions too, then on starting the app, you can choose a definition to work with.

This reduces the overhead of "Live" scanning a file every time, you just scan it once to get the offsets, then add it to your config for future work. Then you could feasibly export to any of these files, substituting in the bytes at the correct offsets.

i would think if that were the case, the special floors shouldnt be in  extended levels as well.... iirc, they are :S

Interesting... well it might just be a case of observing what these floors are and trying to see if there's anything common about them. Or if it's just a quirk of something that was not implemented, or perhaps a copy-protection feature? Short of finding the assembly that uses these values it'll be guesswork.