Ultimate Amiga

Please login or register.

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

Author Topic: Hacking: Open Contribution Thread  (Read 25560 times)

Hungry Horace

  • Amorphous Blue-Blob Man
  • Site Admin
  • A4000T
  • ******
  • Karma: 305
  • Offline Offline
  • Posts: 3,283
  • Don't forget... Ameboid's need love too!
    • Amiga Online
Re: Hacking: Open Contribution Thread
« Reply #15 on: June 06, 2011, 08:44:00 PM »

the images are in some horrible ST raw format (even on the amiga) , and I'm afraid I know little about ripping them, because I've never had any success. The 4/5 amiga sounds are also just a raw format, and pretty easy to find in the data if you just load the game binary into an amiga sample player or tracker.


I think you will find much of even the 68000k asm code is the same between the ST & Amiga versions.

It would certainly be amazing to have a fully commented source code of the original game engine, as then I (or others) could consider remakes / sequels on either the original platform, or others, based on that code. (i for example, would like to do a full sequel on the Amiga, with new spells, weapons, monsters etc, but without losing the original RPG engine)

In 5-6 weeks time, I will finish year one of my college course, and i'll get a summer break - I try add upload some more data info to the main thread for you then (plus, it's a project I'd quite like to get into again)

in the meantime, please feel free to post anything here you'd like to contribute that you find!!

edit:

just for fun i updated : Hacking: Wall Switches to the kind of standard I want to maintain the info at, because this was one of the things that really bugged me for many years!! I was so very happy when i finally cracked this one (along with Pad Triggers) because it really opened up the game in terms of editing.

I'll try and do pad triggers in the next few days, and then maybe update the Map data-type definitions. (Spaces and Misc should be quite short!)
« Last Edit: June 06, 2011, 09:37:12 PM by Hungry Horace »
Logged
Quote from: KillerGorilla
because winuae is made of code and your amiga is made of stuff

Hungry Horace's Artwork Available
Buy my work

http://twitter.com/horaceandspider

murlock

  • Chaos Wizard
  • A600
  • *
  • Karma: 2
  • Offline Offline
  • Posts: 34
Re: Hacking: Open Contribution Thread
« Reply #16 on: June 07, 2011, 03:57:06 AM »

If I recall the horrible ST raw format uses some interesting 5bits/colour per pixel or something equally as horrid. I'll look into it and see what I can find...

I guess the ST may have used some kind of ST chip synth instead of raw sound samples, because it all sounds so clanky.

The 68000 asm decompiling will probably be a large task, I have found some website in the past that might assist with this, so I might have to go searching to see if there's any 68000 decompiler to make this task easier.

Yeah, my thought was to recreate the engine on the PC using .NET, if only because it'll be heaps easier to debug and extend. Appreciate this is a mammoth task though (but I can dream...)

Thanks for the wall switch info. I guess that you've probably already discovered the items that I have developed, although if my c# code can help describe the logic, do give me a shout! :)
Logged
Look to the towers my friend

Hungry Horace

  • Amorphous Blue-Blob Man
  • Site Admin
  • A4000T
  • ******
  • Karma: 305
  • Offline Offline
  • Posts: 3,283
  • Don't forget... Ameboid's need love too!
    • Amiga Online
Re: Hacking: Open Contribution Thread
« Reply #17 on: June 08, 2011, 07:45:36 PM »

i started to add some cross-reference links to the main contents of the hacking thread


I added again the  object lists:
BW Object Lookup Table
BEXT Object Lookup Table

which had somehow been lost. This is actually the very first data I started to edit when I began hacking Bloodwych back in the 1990s! it was nice to be able to stuff the champions pockets full of goodies right at the start!!

I also began to update the Pad / Floor Traps & Triggers information, although map data (6) needs updating to go with this (just as map data (1) does for the switches)  , and I havent put any descriptions yet for some of the more wierd and wonderful action that are performed by a few of these!!


Let me know if the format i'm adding this info in is of any help, and if there is anything you'd like to know about first (e.g. map data, pocket layouts etc etc)

edit... i also need to make links easier to see on this Crypt forum theme at some point!!
Logged
Quote from: KillerGorilla
because winuae is made of code and your amiga is made of stuff

Hungry Horace's Artwork Available
Buy my work

http://twitter.com/horaceandspider

murlock

  • Chaos Wizard
  • A600
  • *
  • Karma: 2
  • Offline Offline
  • Posts: 34
Re: Hacking: Open Contribution Thread
« Reply #18 on: June 09, 2011, 03:10:38 AM »

That's great :)

The button info confirms some of the hunches I had so far, and the remaining new info will save me a lot of time trying to figure things out :)

What I plan to do eventually is create a spreadsheet to map out the areas of the "CODE" file to determine the areas of data and areas of suspected code/content.

The Atari ST source also consists of a few other source files - the auto bootloader, a resource file and some empty saved games, so I'll probably investigate those too at some point.

One thing I notice is that the colour of buttons seem to be random, and some banners (out side of specific Green Serpent/Blue Moon/Red Dragon/Yellow Chaos) also seem to be random colours. Is this determined by X,Y or something else?

If you'd like me to post my C# Logic for determining values then I'm happy to push it up into this thread. :)

Logged
Look to the towers my friend

murlock

  • Chaos Wizard
  • A600
  • *
  • Karma: 2
  • Offline Offline
  • Posts: 34
Re: Hacking: Open Contribution Thread
« Reply #19 on: June 12, 2011, 12:29:41 PM »

ATARI ST Monster Data:
[$17474] = 12 bytes of Monster Data - counts of monster per tower - i.e. 6x2 bytes
[$17480] The Keep
[$17780] The Serpent Tower
[$17a80] The Moon Tower
[$17d80] The Dragon Tower
[$18080] The Chaos Tower
[$18380] Zendik's Tower

For each tower, assume we are looping through the monster data, 6 bytes at a time. ID is just the counter.
This method inits a monster data, so we can then store in a list and render out at the relevant F/X,Y later.

(One thing i did find here is that the floor is 1-based, whereas I generally stored as 0-based, hence needed to subtract 1.)

public Monster(int id, List<byte> data)
        {
            if (data == null || data.Count != 6)
            {
                throw new ArgumentException(string.Format("Incorrect Monster Data size {0}",
                                                          data == null ? "null" : data.Count.ToString()));
            }

            ID = id;

            Type = EnumType.None;

            /* AB CD EF GH IJ KL
            A = Type of Monster
            B - The number of the tower floor on which the monster starts. (1-based)
            CD - The X-coordinate postiioning of the tower floor on which the monster starts.
            However, if between two and four monsters are to start in the same location (teamed) this number is left void and given a value of FF on the second to fourth team-members.
            EF - The Y-coordinate positioning of the tower floor on which the monster starts.
            GH - The level of the monster. This determines the monsters strength, speed, available spells, and for non-humanoid monsters also the colour of the monster.
            IJ - This is the form / look of the monster. This number represents those given in the monster lookup table.
            KL - This is the rather unusual "team-data" number. In the majority of cases this is left blank with the value of FF.
            However, when two monsters are to begin the game "teamed" with the same starting postion, this value simple increases from 00 and beyond, for every teamed-monster.

             */

            int ab = data[0];
            int cd = data[1];
            int ef = data[2];
            int gh = data[3];
            int ij = data[4];
            int kl = data[5];

            int type = ab >> 4;
            int f = ab % 0x10;

            F = f-1; //-1 to make 0-based
            X = cd;
            Y = ef;
            Level = gh;
            AppearanceID = ij;
            TeamPosition = kl;

            switch (type)
            {
                case 0x00:
                    Type = EnumType.Normal;
                    break;
                case 0x01:
                    Type = EnumType.Spellcaster;
                    break;
                case 0x03:
                    Type = EnumType.None;
                    break;
                case 0x04:
                    Type = EnumType.ArcBolt;
                    break;
                default:
                    Type = EnumType.None;
                    break;
            }
        }

Other notes:
- The monster type I found 4 to be the ArcBolt in the Dragon Tower, not 3 as in your notes. I also found only 1 monster of type 3 who lives in the serpent tower - still to investigate what's so special about it.
- The Behemoth in Zendicks tower starts at X=0x89, when he should be at X=0x09. I'm not sure if there is some kind of mod that should be applied to the X co-ordinate or if there's something special that "teleports" him in to the centre of the last floor.
- The team data seems to work by setting a unique number per monster in a team. The first monster (let's call him the leader) has an X co-ord as you state, the others in the same team have 0xFF. For a monster "leader" with team number N, the other monsters have N+1, N+2, N+3. So if you loop through the monsters in order with team data, you can look at the previous team member and do the following:

//now we need to fix up the teaming
            List<Monster> teamMonsters = Monsters.Where(m => m.TeamPosition != 0xFF).ToList();
            foreach (Monster m in teamMonsters)
            {
                if (m.X == 0xFF)
                {
                    Monster prevTeamMember = teamMonsters.Where(t => t.X != 0xFF && t.TeamPosition == m.TeamPosition-1).FirstOrDefault();
                    if (prevTeamMember != null)
                    {
                        Monsters.Single(z => z.ID == m.ID).X = prevTeamMember.X;
                        Monsters.Single(z => z.ID == m.ID).Y = prevTeamMember.Y;
                    }

                }
            }



Hope this helps! :)
Logged
Look to the towers my friend

Hungry Horace

  • Amorphous Blue-Blob Man
  • Site Admin
  • A4000T
  • ******
  • Karma: 305
  • Offline Offline
  • Posts: 3,283
  • Don't forget... Ameboid's need love too!
    • Amiga Online
Re: Hacking: Open Contribution Thread
« Reply #20 on: June 13, 2011, 11:41:02 AM »

actually, i think you may be right, in that monster 4 is the arc bolt machine - i need to check my editor code to confirm... but i seem to recall that it should be something like this:

     This can be one of three values;
     0 - Normal Fighting Monster
     1 - Normal Spell-casting Monster
     2 - Fighting Drone
     3 - Spell-casting Drone
     4 - Arc Bolt Machine

The "drones" dont seek out the players, and act in the same way as a Summon spell.... they simply walk along until they hit a wall and turn. Obviously, they do also attack players that get in their way in the process!!

I've used a number of these in Book of Skulls, but you are right, in the original BW there is only one in the serpent tower (he is a fat summon character who walks back and forth between 3 spaces)


You are also spot-on with the team data stuff ... I will update my post to include everything you've written! (including the ST addresses) Unfortunately, i did not update my notes when I was working on the editor!

This teaming also puts a restriction on the number of monsters you can have in a tower... because if too many "auto" team up when you start a tower, then the team-counter goes over a set value and causes the game to crash (not good!!)

thanks for this :)
Logged
Quote from: KillerGorilla
because winuae is made of code and your amiga is made of stuff

Hungry Horace's Artwork Available
Buy my work

http://twitter.com/horaceandspider

murlock

  • Chaos Wizard
  • A600
  • *
  • Karma: 2
  • Offline Offline
  • Posts: 34
Re: Hacking: Open Contribution Thread
« Reply #21 on: June 13, 2011, 12:33:37 PM »

Good stuff - I found that drone Summon in the Serpent Tower last night, as I was playing through. Haven't played Bloodwych in so many years it's good to relive the old memories. And my map generator is definitely helping! :)

I guess that limitation on the number of teams you mention explains why you often see "couples", so they can't team up with other "couples".

I'll start posting the rest of my investigations here... a lot of this is based on your posts anyway, so probably nothing new.

ATARI ST Floor and object data -

[$0EE3C] The Keep
[$1023E] The Serpent Tower
[$11640] The Moon Tower
[$12A42] The Dragon Tower
[$13E44] The Chaos Tower
[$15246] Zendik's Tower

/*
*  FLOOR DATA
($1402 total bytes per block)
[$00000] - (8 bytes) Width values of the respective Floors of the the Tower, starting with the lowest floor.
[$00008] - (8 bytes) height of each of the floors, starting with the lowest floor.
[$00010] - ($28 bytes) ?other header? not sure what this is for
[$00038] - ($FC8 bytes) Map Data
[$01000] - ($402 bytes) Object data - first 2 bytes signify amount of data used for object data
*/

Getting item stacks for a tower - assume we are parsing the $400 bytes of object data (from $01002)
where objectDataSize = the value parse from the first 2 bytes

int objOffset = 0;
            ItemStacks = new List<ItemStack>();

            while (objOffset < objectDataSize)
            {
                //what we care about here is how many bytes are used for this ItemStack
                //This is a minimum of 5 bytes, with an additional 2 bytes added for each extra item in this location.
                //Format: AB CD EF GH IJ .. KL MN .. OP QR .. etc..
                int ef = DataObjects[objOffset + 2];

                //EF = The number of items in the given location, minus 1.
                int bytesToTake = (2*ef) + 5;
                List<byte> bytesForThisItemStack = DataObjects.Skip(objOffset).Take(bytesToTake).ToList();
                ItemStack itemStack = new ItemStack(bytesForThisItemStack);
                ItemStacks.Add(itemStack);

                //increment to the next ItemStack
                objOffset += bytesToTake;

            }


public ItemStack(List<byte> data)
        {
            Position = EnumPositon.None;

            //this should be a new object
            //This is a minimum of 5 bytes, with an additional 2 bytes added for each extra item in this location.
            //Format: AB CD EF GH IJ .. KL MN .. OP QR .. etc..

            int ab = data[0];
            int cd = data[1];
            int ef = data[2];

            //A = The position of the items in the location (4 positions for a standard floor, and 2 positions for a shelf)
            //00 - Position 1 - North West Space, North Facing Bottom Shelf,  West Facing Top Shelf
            //04 - Position 2 - North East Space, East Facing Bottom Shelf,  North Facing Top Shelf
            //08 - Position 3 - South West Space, West Facing Bottom Shelf,  South Facing Top Shelf
            //0C - Position 4 - South East Space, South Facing Bottom Shelf,  East Facing Top Shelf

            int a = ab >> 4;

            switch(a)
            {
                case 0x00:
                    Position = EnumPositon.NorthWest;
                    break;
                case 0x04:
                    Position = EnumPositon.NorthEast;
                    break;
                case 0x08:
                    Position = EnumPositon.SouthWest;
                    break;
                case 0x0C:
                    Position = EnumPositon.SouthEast;
                    break;
            }

            //BCD = The index number for the location.
            int b = ab % 0x10;
            int bcd = (b << 8) + cd;
            IndexNumber = bcd;

            //EF = The number of items in the given location, minus 1.
            //go through each this count to extract object data
            Items = new List<Item>();
            for (int oi = 0; oi <= ef; oi++)
            {
                //lets call each pair GH IJ for simplicity
                //GH - object code for the item in the location. based on the object lookup table
                int gh = data[3 + (2 * oi)];
                //IJ - This is the number of item GH to be "stacked" at this point.
                int ij = data[4 + (2 * oi)];

                Item item = new Item(gh, ij);
                Items.Add(item);
            }
        }


and an example of a map generated for the keep is attached... as you can see I have yet to ingest the champion data, only objects and monsters.

Logged
Look to the towers my friend

murlock

  • Chaos Wizard
  • A600
  • *
  • Karma: 2
  • Offline Offline
  • Posts: 34
Re: Hacking: Open Contribution Thread
« Reply #22 on: June 13, 2011, 12:42:21 PM »

ATARI ST Button Data:

[$0589E] The Keep
[$058DE] Serpent Tower
[$0591E] Moon Tower
[$0595E] Dragon Tower
[$0599E] Chaos Tower
[$059DE] Zendick's Tower

64 bytes ($40 bytes) per tower


ATARI ST Pad/Trigger Data:

[$06db4] The Keep
[$06e34] Serpent Tower
[$06eb4] Moon Tower
[$06f34] Dragon Tower
[$06fb4] Chaos Tower
[$07034] Zendick's Tower

128 bytes ($80 bytes) per tower
Logged
Look to the towers my friend

Hungry Horace

  • Amorphous Blue-Blob Man
  • Site Admin
  • A4000T
  • ******
  • Karma: 305
  • Offline Offline
  • Posts: 3,283
  • Don't forget... Ameboid's need love too!
    • Amiga Online
Re: Hacking: Open Contribution Thread
« Reply #23 on: June 14, 2011, 12:07:19 AM »

cool bananas :D

I've attached a .zip file of all the stuff which can be inputted/outputted from my editor. A couple of the files (.map .ob) are the swappable with the PC game files. I've used the original game data, so you can easily find this same data in the ST version, and see if it's identical (i think it will be)

I *think* these cover everything in the game, so if you can make these interchangeable in/out of your map program, we could be onto a real winner with swapping data between ST and Amiga versions (had you considered adding support for the amiga binary files?)

This list should also give you an idea of all the things that are easily editable relating to gameplay itself... there are a few others i'd like to look into (such as the menu-screen layout) but those may differ between versions... i've yet to confirm that.

files contained are:

scrolls.block               3380 ----rwed Today     00:59:42
champions.pockets            256 ----rwed Today     00:59:42
champions.stats              512 ----rwed Today     00:59:42
woodtrap2.location             4 ----rwed Today     00:59:42
woodtrap1.location             4 ----rwed Today     00:59:42
gem-blu.locations             24 ----rwed Today     00:59:42
gem-tan.locations             24 ----rwed Today     00:59:42
dungeon.entrances             24 ----rwed Today     00:59:40
keep.entrances                26 ----rwed Today     00:59:40
zendik.triggers              128 ----rwed Today     00:59:40
chaos.triggers               128 ----rwed Today     00:59:40
drag.triggers                128 ----rwed Today     00:59:40
moon.triggers                128 ----rwed Today     00:59:40
serp.triggers                128 ----rwed Today     00:59:40
mod0.triggers                128 ----rwed Today     00:59:40
zendik.switches               64 ----rwed Today     00:59:40
chaos.switches                64 ----rwed Today     00:59:40
drag.switches                 64 ----rwed Today     00:59:40
moon.switches                 64 ----rwed Today     00:59:40
serp.switches                 64 ----rwed Today     00:59:40
mod0.switches                 64 ----rwed Today     00:59:40
zendik.monsters              768 ----rwed Today     00:59:38
chaos.monsters               768 ----rwed Today     00:59:38
drag.monsters                768 ----rwed Today     00:59:38
moon.monsters                768 ----rwed Today     00:59:38
serp.monsters                768 ----rwed Today     00:59:38
mod0.monsters                768 ----rwed Today     00:59:38
monsters.totals               12 ----rwed Today     00:59:38
zendik.ob                   1026 ----rwed Today     00:59:38
chaos.ob                    1026 ----rwed Today     00:59:38
drag.ob                     1026 ----rwed Today     00:59:38
moon.ob                     1026 ----rwed Today     00:59:38
serp.ob                     1026 ----rwed Today     00:59:38
mod0.ob                     1026 ----rwed Today     00:59:38
zendik.map                  4096 ----rwed Today     00:59:38
chaos.map                   4096 ----rwed Today     00:59:38
drag.map                    4096 ----rwed Today     00:59:38
moon.map                    4096 ----rwed Today     00:59:38
serp.map                    4096 ----rwed Today     00:59:38
mod0.map                    4096 ----rwed Today     00:59:38


edit: mod0 is the name given for the Keep in the PC version, so i've used that filename here, although I always reference The Keep in my own listings, as it makes more sense!
« Last Edit: June 14, 2011, 12:08:59 AM by Hungry Horace »
Logged
Quote from: KillerGorilla
because winuae is made of code and your amiga is made of stuff

Hungry Horace's Artwork Available
Buy my work

http://twitter.com/horaceandspider

murlock

  • Chaos Wizard
  • A600
  • *
  • Karma: 2
  • Offline Offline
  • Posts: 34
Re: Hacking: Open Contribution Thread
« Reply #24 on: June 14, 2011, 04:52:14 AM »

Yep - I'd just need to add another layer to allow me to choose where i'm getting the bytes from, either the ST's "CODE" file, or lots of individual files as you note below.

Subsequently I will need to add logic to output data read in to either ST or AMIGA format.

My map application doesn't have any ability to edit data at this stage (probably a fair way off yet) but I can test my approach with a book of skulls map potentially...

This might be ready in the next week or two, depending on how much free time I have... ;)

I also still need to ingest champion and scroll data, to make my system more complete.
Logged
Look to the towers my friend

murlock

  • Chaos Wizard
  • A600
  • *
  • Karma: 2
  • Offline Offline
  • Posts: 34
Re: Hacking: Open Contribution Thread
« Reply #25 on: June 15, 2011, 04:12:18 AM »

Just to elaborate, what I'm thinking is:

Stage 1:
ATARI ST "CODE" -> intermediate format -> Render in my map tool
AMIGA "CODE" -> intermediate format -> Render in my map tool
PC "CODE" -> intermediate format -> Render in my map tool
intermediate format -> Render in my map tool

Where the intermediate format is the common format you have supplied above in the zip.
This will also allow me to check that the Amiga, ST and PC data is exactly the same.

If you can let me know the best Amiga source and emulator to use, I can try and extract relevant file(s) to be used on a PC with my map tool.

I think I have a PC version of bloodwych kicking around somewhere.

Once we have this complete, then I can try the following:

Stage 2:

intermediate format -> write into ATARI ST "CODE"
intermediate format -> write into AMIGA "CODE"
intermediate format -> write into PC"CODE"

This would allow us to potentially take a "Book of Skulls" map in intermediate format and try and apply to the Atari ST source.

I would guess I would have a copy of the "CODE" in my solution to use as a template to write into. Then would manually have to get this file back into the emulator. (For the ST you can map a PC folder to be treated as a "hard drive" to copy in/out of the emulator).



Logged
Look to the towers my friend

murlock

  • Chaos Wizard
  • A600
  • *
  • Karma: 2
  • Offline Offline
  • Posts: 34
Re: Hacking: Open Contribution Thread
« Reply #26 on: June 17, 2011, 01:42:14 PM »

Ok, more progress.

I have named the intermediate format "BCF"... i.e. "Bloodwych Common Format".

My app now does the following:

Load ATARI ST -> BCF in memory
BCF as files (i.e. contents of your zip) -> BCF in memory

BCF in memory -> BCF as files

i.e. I can now save out in the same format as yours! :)

I am yet to ingest from the st the following:
champions.pockets
champions.stats
dungeon.entrances
gem-blu.locations
gem-tan.locations
keep.entrances
scrolls.block
woodtrap1.location
woodtrap2.location

(still work in progress to locate the bytes and ingest...)

---------------------

FINDINGS:

Using windows comp.exe on the files generated so far, nearly all files are exact matches, the only discrepancy is

mod0.map
Your export / ST export

Compare error at OFFSET 31
file1 = 15
file2 = 1F
Compare error at OFFSET 33
file1 = 15
file2 = 1F
Compare error at OFFSET 34
file1 = 0
file2 = 5
Compare error at OFFSET 35
file1 = 18
file2 = 4C

As far as I know these bytes are in the mysterious map "header" data which I'm not sure what it defines, so as yet I can't tell the difference

Compare error at OFFSET 8C8
file1 = 11
file2 = 9

Keep F3, x:15, y:13, i:1096
It's the first bronze key door in the game
I noticed this before as an anomaly in the ST version - the only bronze key door with ABCD = 0915 instead of 1115 - but it still works exactly the same

That's it!
Logged
Look to the towers my friend

Hungry Horace

  • Amorphous Blue-Blob Man
  • Site Admin
  • A4000T
  • ******
  • Karma: 305
  • Offline Offline
  • Posts: 3,283
  • Don't forget... Ameboid's need love too!
    • Amiga Online
Re: Hacking: Open Contribution Thread
« Reply #27 on: June 18, 2011, 12:28:50 PM »

i'll check my header interpretation from the editor source, but iirc one part of it is to define the X/Y "offset" of each floor (and therefore 16 "words" are avaialble for this... enoguh to cover the max of 8 floors, in each coord.

This allows you to "arrange" the way the floors stack up on top of each other.... it's a bit hard to explain but obviously this is really important in allowing you to make sure your stairs etc match-up between floors of different sizes. i'll see if i can post a few pictures that help explain.

There is also a prt of it that seems to represent a different floor in each tower/dungeon .... i think it's two values, the offset-value presenting 0,0 of the floor and the offset representing the coord for floorwidth,floorheight .... by 'offset-value' in this case, i mean the same values that are used to position objects in a level.


I've also had a look into my wall-scroll reading/editing data, and i have attached the code for that section of the editor. I'll try and write up a meaningful interpretation of it soon! (It's a bit tricky because it's very much variable-length)


these locations will be needed though:
scrollref = $1a058
scrolltext = $1a0ea

and these funtions are defined:
DEF FN FINDSCROLL = deek (scrollref+(scrollnumber*2))
DEF FN FINDSCROLLTEXT = deek (scrolltext + findscroll + LOC)

('Deek' is AMOS's way of peeking a word rather than a byte, and i cant remember what the variable LOC is for)
Logged
Quote from: KillerGorilla
because winuae is made of code and your amiga is made of stuff

Hungry Horace's Artwork Available
Buy my work

http://twitter.com/horaceandspider

murlock

  • Chaos Wizard
  • A600
  • *
  • Karma: 2
  • Offline Offline
  • Posts: 34
Re: Hacking: Open Contribution Thread
« Reply #28 on: June 18, 2011, 01:17:16 PM »

Thanks mate, this'll be a great help :)

Nearly played to the end of the serpent tower so far. Having a map handy makes life easier!

I think I get what you mean regarding the floor offsets. I was wondering how the different floors lined up, so the game would know when you went up/down where you should end up.

I've found the scroll text in the St code, so I'll attempt to ingest it in the next few days if I get a chance.

Cheers :)
Logged
Look to the towers my friend

Hungry Horace

  • Amorphous Blue-Blob Man
  • Site Admin
  • A4000T
  • ******
  • Karma: 305
  • Offline Offline
  • Posts: 3,283
  • Don't forget... Ameboid's need love too!
    • Amiga Online
Re: Hacking: Open Contribution Thread
« Reply #29 on: June 18, 2011, 01:33:19 PM »

Ok, a quick read-through of that scroll data, reminds me that we have two "sections" of the scroll information, within the scrolls.block file.

Part 1 - is a list of word-values, declaring how many bytes into the part 2 each scroll begins.

e.g. Scroll #001 will always begin at value $0000, so this is the first value.
If scroll #001 is $20 bytes long, then the next value will be $0020 , if scroll #002 is $12 bytes long, then the third value will be $0032 etc.

Part 1 is $0092 bytes long.

this is the original $92 bytes of data from BW, laid out in a meaningful way.

Code: [Select]
0000 0026 004E 008A 00B3 00CC 00DE 0127
0145 0180 019B 01B4 0207 0220 0252 0269
028A 02A9 02D3 02EB 0340 037B 03A8 03C0
03E9 040C 0444 047C 049D 04D3 0500 0525
054F 056D 0593 05C2 05FE 0642 0667 067E
06B7 06DB 0709 0731 076F 07A3 07D6 0802
0837 0858 087C 08A3 08BA 08E1 092E 0950
0987 09A6 09D0 0A0B 0A29 0A40 0A67 0AA2
0AED 0B14 0B4C 0B77 0BA2 0BCE 0BFA 0C32 0C5D

Part 2 is simply a list of the scrolls, with a specific "format", this is $CA2 bytes long.

here is the very first scoll entry from BW, also in a format to make it understandable:

Code: [Select]
FC 1E 04   54 48 45 20 4B 45 59
FC 1F 05   41 42 4F 56 45
FC 1E 06   44 4F 54 48 20 4C 49 45
FC 1F 07   42 45 4C 4F 57
FF

in-game this reads:

Code: [Select]
THE KEY
 ABOVE
DOTH LIE
 BELOW

- Byte 1: $FC should be seen as simply a "line declaration", so the first scroll can be seen to be 4 lines long.

the following two bytes, are effectively an X/Y coordinate for placing the scroll on the screen.

- Byte 2: X Coordinate
$1E should be seen as zero however, as any lower value than this will not be on the scroll on-screen.
In order to keep the text on screen, the length of the text on each row, determines the maximum value of the X coord. I.e. if you have a row of only 1 character long, you can have a maximum X value of 8 (therefore value $1E + $08 = $26 can be patched in) ... if you have a row of 3 characters, your maximum  X value is 6 etc.

You can fit a total of 9 characters into a row only.

- Byte 3: Y Coordinate
$03 should be seen as zero however, as any lower value than this will not be on the scroll on-screen
there are 7 possible rows which can be used for each scroll, so the maxium value of this byte should be $03+$07 = $0A, for the bottom row of the scroll.

-Byte 4+: Text in ASCII format.
Standard text data, continuing until either a $FC or $FF filled byte is reached.

After all data required for text layout is done, a single byte of $FF is used to terminate the scroll data.


When deciding which scroll is referred to in the map data, a standard reference number is used (as with switches etc), however, the starting point (i.e. which scroll is referred to by Reference 1) changes with each tower. I do not recall finding how this is determined from within the game-code... it must be somewhere though!
Logged
Quote from: KillerGorilla
because winuae is made of code and your amiga is made of stuff

Hungry Horace's Artwork Available
Buy my work

http://twitter.com/horaceandspider
Pages: 1 [2] 3 4 ... 11   Go Up