Ultimate Amiga

Please login or register.

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

Author Topic: Bloodwych PC Disassembled  (Read 26993 times)

0 Members and 6 Guests are viewing this topic.

Bit

  • A600
  • *
  • Karma: 5
  • Offline Offline
  • Posts: 69
Re: Bloodwych PC Disassembled
« Reply #30 on: June 10, 2014, 03:06:02 AM »

 8)
Basically I have sound!
There must be one small bug somewhere, because it is not absolutely correct, and, because it depends now on the thread timing, it may get somewhat out of rhythm when those slow ega-routines forbid the timed thread to blit (and handle the sound), but - it works!
The datas of Bloodwych don't have a complete MIDI-track, things are calculated on the fly, so I can't use the old Allegro's midiplayer which just plays complete songs.
The Roland-sounddriver is kind of a MIDI-player, but depends on bloodwych's internal data format. Now I could cut out the midiOutmsg things from Allegro and use the Winmm.lib directly with it. And I was pretty surprised that it worked immediately! Good luck this time!

I will do a 2nd translation of the sounddriver to find the bug and verify that one, because, being part of the 'interrupt'-thread, it isn't allowed to use any emu-command. Will bring in the experience of the first quick and dirty translation, and this should happen fast.
Then I will cleanup the whole program, checking the main program again for all CALL, JUMP and OPEN_END (which will be the only reason for possible bugs in the main file at all) and especially try to translate all graphics-functions to real pixel functions that then can replaced all in once. It's not possible just to change one of them, because all drawing also depends on the data-format of the current drawing screen.
Once this is done, we do have the very basic source to work with.

It's fine if you test a little bit and write down bugs (maybe have a savegame nearby),  but I hope that the cleanup will kill most of them.

edit: just tried the 2-player-option for the first time - that... looks... like *some* wrong offsets  ;D
« Last Edit: June 10, 2014, 05:40:52 AM by Bit »
Logged

MadMunky

  • Forum Mod
  • A600
  • *****
  • Karma: 2
  • Offline Offline
  • Gender: Male
  • Posts: 244
Re: Bloodwych PC Disassembled
« Reply #31 on: June 16, 2014, 07:13:28 PM »

Hi Bit,

Hows things progressing? not heard from you for awhile :) hope there is not any show stoppers
Logged

Bit

  • A600
  • *
  • Karma: 5
  • Offline Offline
  • Posts: 69
Re: Bloodwych PC Disassembled
« Reply #32 on: June 18, 2014, 02:49:19 AM »

Nono, I just got a cold or some flu (in spring, i hate that, it's always worse than in winter) and a lot to do with the job.
In fact I'm at the last bug that I can see. If you take a look at my screenshot of the icons, you will find, that there is three times the same mead-picture. It should have a pink symbol how much is left in it - but - no - that got somehow filtered. Tbh - I won't spend too much time into this detail.
The program runs smooth now, those delays and mouseclick problems are solved. (Still, I cannot solve Allegro's resize-to-original-mousefactor-wrong-problem myself - that one is ridiculous, but annoying as the second system bug, that you lose the 'DirectX-plane' when closing a notebook while the program still runs)
For the other bugs that you told me (except leadership and position - that was serious and is solved), you better check those again because I'm not sure what you mean exactly, or where to check it quickly. Expect a new release the next two days. In it, a lot of routines and variables got names now - although I think, that you still got an immense knowledge advantage. But now that I have a lite idea where I am, Hungry Horace's tables will be extremely worthful and save a lot of time. Maybe I'm even to be able to answer the one or other question.
Once that new version will be confirmed okay, the next phase has to be done to get it readable, because all emu-things have to vanish in the end.
Logged

MadMunky

  • Forum Mod
  • A600
  • *****
  • Karma: 2
  • Offline Offline
  • Gender: Male
  • Posts: 244
Re: Bloodwych PC Disassembled
« Reply #33 on: July 12, 2014, 06:46:44 AM »

Hi Bit,

Not heard anything from you for awhile so just interested in how things are going. We are getting close to a point with the HTML version where we are having to guess a lot of the logic of the game so it would be good to try and use your reversed version to understand the logic we dont currently know.
Logged

Bit

  • A600
  • *
  • Karma: 5
  • Offline Offline
  • Posts: 69
Re: Bloodwych PC Disassembled
« Reply #34 on: July 13, 2014, 04:16:54 AM »

I'm very busy with it - but it's no fun anymore.
I have to assume that it's really been programmed in assembler, which, after all, makes it really aweful to convert it to a good C-source.
They don't use local variables - it's all global - which wouldn't be that bad - but - in several parts of the program some registers are preserved for a special purpose.
There's i.e. some kind of cursorposition for the textoutputs. A function like 'blitchar' increments that one. The returning value of this has to be carried up through a hundred routines, and if you think it's really dead now - it comes back alive.
Even more weird the behaviour of that thing that finally distinguishs between both players in the two player game (which, IMHO, has a few severe bugs!). A harmless function like textout decides to which player to print to - and this result is then carried back (like this cursorposition).
So - after all - it's all bottom up. A routine gets called to get a pack of values, instead of giving arguments to a function - can't describe it a better way.
And then - there are hundreds of minimal functions, not longer than five lines - and then we got those that have switch-cases, that got it all in one and are extremely unreadable huge.
Right now I am tracking a few things to make at least 'the master plan' a bit understandable (and verify really important things). I'm close to get that finished, but, as I said, this beast has a lot of holes to hide something...
At least I can report to have (except of a very few) labels and gotos replaced by blocks and loops. I just waited for the results of those trackings and wanted to bring it to that point that I can replace a lot of constants by enumerations and names of HH's tables, so that we can have a light idea what the routines do - because I still treated all the abstract way. Somehow it's time then to find a way to bring the 68000-disassembling stuff to the i86 one to make it comparable and my results usable. Will make a new release as soon as possible - right now it's pretty diseased by a lot of bookmarks...

edit: just to point on it: The most evil situation happens when it's about to reset the icon of the used cursorkey having done a step. There happens one extra push of the adress of the resetting routine to the stack. Means: whatever is done next (and that can be a lot!), *after* this one the next action is this reset, and then it finally returns to the main routine (which is the clickhandler). Good luck that those evil technics aren't used more often. It would have crashed any try to make that in a higher language. For that one thing, there's surely a workaround. Wonder if that all fits to your researches on the Amiga-version.
« Last Edit: July 13, 2014, 04:31:59 AM by Bit »
Logged

Bit

  • A600
  • *
  • Karma: 5
  • Offline Offline
  • Posts: 69
Re: Bloodwych PC Disassembled
« Reply #35 on: July 29, 2014, 02:16:45 AM »

Just a short note about the state:
I revealed all stuff that has something to do with player0 or player1 and their datapackage, so that a class pointer replaces that ugly es-segment-register and all situations when other registers are temporary used for that purpose. wasn't easy, but did solve in the end. even (hopefully) fixed those few original bugs on the fly.
I want to do this now for the hero/champion-things too.
I already wrote a lot of macro-expressions, which looks nice, but leaves a lot of unrevealed things that also belong to the champions.
But creating classes and pointers for that may end in a desaster!
Two reasons for that:
1. all champion releated things don't work with a segment-register (like for the players), but with offsets only. Because the register that handles this may be used for several other (integer) purposes there is a pointer/integer-type-problem returning the value when the routine ends. (and this happens in hundreds of routines...)
2. three different types for champion-datas, the basic 32 byte-database for the 16 heroes, this 16 byte-database for (still don't know, but assume) the 128 'living' ones, and this one 1 * 16-byte slot for ... (who knows...).

Munky, are you sure that the 16-byte-datas are really in the same meaning and order of the first 16 bytes of the 32-byte-datas? - this would mean that there is no x and y with the champion/monster and only the map keeps track with the index of them... (which would be enough).

However: It's going really critical now.
If I can't solve this pretty clean, any more work is doomed  :o
If I can - we will win!  8)

Here is the current state of my player-class with all revealed and unrevealed things:

Code: [Select]
  class c_player
  {
    protected:
      ui8 mode; // 0
      // bit0 = 0: is player0      bit0 = 1: is player1 (for both players presetted by default)
      // bit1 = 0: not attacking   bit1 = 1: attacking   
      // bit2 = 0: not sleeping    bit2 = 1: sleeping
      // bit3 = 0: not defending   bit3 = 1: defending   
    public:
      ui8 mousestate; // 1
      ui16 mouse_x;   // 2
      ui16 mouse_y;   // 4
      ui8  boss;      // 6
      // replaced ESWORD(6) & 0x0FFu and ESWORD(6) & 0x0F into
      // (i16)boss
      i8   byte7;     // 7 TODO: requested, but no setting found
    protected:
      ui8  gfx_y;     // 8
      // the highbyte 9 is never used, ESWORD(8) readonly,
      // so I replaced the one appearance into (i16)get_gfx_y
      i8   byte9;     // 9 fillbyte now
    public:
      ui16 screenoffset; // 0x0A
      i16 option; // 0x0C
      // will be the option in BW_mainscreen_clickhandler!
      // gets set in BW_csel_find_clickedrectangle, but in another places too

      u_bbw word_e; // 0x0E
      // 0xE as word, but also 0xE and 0xF as byte
      // byte 0xE maybe the boss' formation index

      ui8 color; // 0x10
      ui8 bytex11; // fillbyte?
      ui8 iconmask; // 0x12
      ui8 bytex13; // fillbyte?

      u_bbw dispmode; // 0x14
      i16 word_16; // 0x16

      i8 hero[4]; // 0x18...0x1B, there's a special 0x40 mask on them

      i8 map_x; // 0x1C
      ui8 bytex1D; // fillbyte?
      i8 map_y; // 0x1E
      ui8 bytex1F; // fillbyte?

      i8 facedir; // 0x20
      // the highbyte 0x21 is never set, ESWORD(0x20) is readonly,
      // so I replaced the two appearances into (i16)es->facedir
      ui8 bytex21; // fillbyte

      i16 word_22; // 0x22
      i16 word_24; // 0x24

      ui8 hpos[4]; // 0x26...0x29  hero's position in party formation

      i8 byte_2a; // 0x2a
      i8 bytex2B; // fillbyte?

      u_bbw word_2c; // 0x2C adressed as word and as byte, 0x2D not seen
      u_bbw word_2e; // 0x2E adressed as word and as byte, 0x2F not seen

      i16 wordx30; // fillword?
      i16 wordx32; // fillword?

      i8 byte_34; // 0x34
      i8 byte_35; // 0x35

      i16 wordx36; // fillword?
      i16 wordx38; // fillword?

      i8 byte_3a; // 0x3a
      i8 byte_3b; // 0x3b
      i8 byte_3c; // 0x3c
      i8 byte_3d; // 0x3d
      i8 byte_3e; // 0x3e
      i8 byte_3f; // 0x3f

      u_bbw word_40; // 0x40
      i16 word_42; // 0x42
      u_bbw word_44; // 0x44   note: b.lo should be unsigned
      i16 word_46; // 0x46

      i16 wordx48; // fillword?

      i16 texttimecnt; // 0x4A
      // set to 0xC8 or 1, counts down in timerroutine depending on
      // es->texttimermode

      i16 wordx4c; // fillword?

      i8 byte_4e; // 0x4e
      u_bbw word_4f; // 0x4f - TODO: odd alignment okay?

      i8 bytex51; // fillbyte?

      i8 texttimermode; // 0x52
      // 0, 1 or 0x80u signed
      // mode 1 means: count down es->texttimecnt and set to mode 0x80u if
      // this one reaches 0.
      // sub_1455A sets back to 0 then

      i8 byte_53; // 0x53

      i8 bytex54; // fillbyte?

      i8 byte_55; // 0x55
      i8 byte_56; // 0x56
      i8 byte_57; // 0x57

      i8 floor; // 0x58 from HERO_FLOOR

      i8 bytex59; // fillbyte?

      i8 byte_5a[4]; // 0x5A...0x5D
      i8 byte_5e[4]; // 0x5E...0x61
      ui16 word_62;  // 0x62

    public:
      c_player();

      // functions on mode:
      bool is_player0(void) const   { return (mode & 1) == 0; }
      bool is_player1(void) const   { return (mode & 1) != 0; }
      void attack_on(void)          { mode |= 2; }
      void defend_on(void)          { mode |= 8; }
      bool is_defending(void) const { return (mode & 8) != 0; }
      bool is_battleing(void) const { return (mode & 0x0A) != 0; }
      void stop_battleing(void)     { mode &= 1; } // also resets sleep mode!
      void sleep(void)              { mode |= 4; }
      bool is_sleeping(void) const  { return (mode & 4) != 0; }
      void wakeup(void)             { mode &= 0xFBu; }
      bool is_in_no_special_mode(void) const { return (mode & 0x0FEu) == 0; }
      i8   get_index(void) const    { return mode & 1; }
      ui8  get_index_ascii(void) const { return (mode & 1) + '0'; }
      ui8  get_other_index_ascii(void) const { return ((~(mode)) & 1) + '0'; }

      ui8  get_gfx_y(void) const  { return gfx_y; }
      void set_gfx_y(ui8 n)       { gfx_y = n; }
  };
« Last Edit: July 29, 2014, 02:20:57 AM by Bit »
Logged

MadMunky

  • Forum Mod
  • A600
  • *****
  • Karma: 2
  • Offline Offline
  • Gender: Male
  • Posts: 244
Re: Bloodwych PC Disassembled
« Reply #36 on: July 29, 2014, 09:22:18 PM »

Munky, are you sure that the 16-byte-datas are really in the same meaning and order of the first 16 bytes of the 32-byte-datas? - this would mean that there is no x and y with the champion/monster and only the map keeps track with the index of them... (which would be enough).

Hi Bit,

Looks like this is keeping you busy :) I dont believe the monsters store any X/Y that I have found and like you said its track via the map, and the 16 byte data does change when its unpacked into the 32 bytes as most of the stuff is then timers/cool downs or leveling stats.

http://www.ultimateamiga.co.uk/index.php/topic,9736.0.html

Here is a extracted table of data taken from steam as blodwyn levels, its is backwards due to steam
Code: [Select]
F SPD D Y X FOD SB4 SB3 SB2 SB1 AC SPM SP VIM VI HPM HP CH IN AG ST LVL
-------------------------------------------------------------------------------------------------------------------------------
0 0 255 11 0 3 235 2 255 255 0 0 255 0 0 199 0 0 0 128 5 6 6 31 31 35 35 13 13 17 35 1
0 0 255 24 0 3 212 2 255 255 0 0 255 0 0 195 0 0 0 128 5 7 7 34 34 53 53 15 15 18 41 2
0 0 255 40 0 3 214 2 255 255 0 0 255 0 0 193 0 0 0 128 5 8 8 42 42 63 63 17 17 21 43 3
0 0 255 50 0 3 204 2 255 255 0 0 255 0 0 193 0 0 0 128 5 13 13 44 44 82 82 18 18 27 45 4
0 0 255 53 0 3 196 2 255 255 0 0 255 0 0 193 0 0 0 128 5 14 14 51 51 98 98 19 20 30 51 5
0 0 255 60 0 3 165 2 255 255 0 0 255 0 0 193 0 0 0 128 5 16 16 52 52 121 121 20 24 35 59 6
0 0 255 65 0 3 162 2 255 255 0 0 255 0 0 190 0 0 0 128 5 16 16 60 60 137 137 22 25 41 60 7
0 0 255 70 0 3 144 2 255 255 0 0 255 0 0 189 0 0 0 128 5 22 22 64 64 152 152 23 28 42 63 8
0 0 255 65 0 3 148 2 255 255 0 0 255 0 0 189 0 0 0 128 5 24 24 72 72 162 162 25 32 47 71 9
0 0 255 65 0 3 129 2 255 255 0 0 255 0 0 188 0 0 0 128 5 26 26 76 76 174 174 27 36 53 73 10
0 0 255 70 0 3 132 2 255 255 0 0 255 0 0 187 0 0 0 128 5 27 27 82 82 188 188 28 38 57 75 11
0 0 255 120 0 3 131 2 255 255 0 0 255 0 0 187 0 0 0 128 5 31 31 86 86 212 212 29 39 58 82 12

As for what each byte does the way I normally play around is load up the game in DosBox and run CheatEngine this allows you to see the memory in real time and change values

Easiest way to find the data is do a Hex Array search for 0501 (the door infront of the quick start) open the door and search for a changed value of 0500 which is the door open if you browse this area your see all the data, you can then also see the player data and champion/monster data.

If your interested in seeing it and that doesn't quite make sense ill try write a little tutorial on how to find some of the addresses

Logged

Bit

  • A600
  • *
  • Karma: 5
  • Offline Offline
  • Posts: 69
Re: Bloodwych PC Disassembled
« Reply #37 on: July 30, 2014, 03:41:47 AM »

Thanks, but this is coming too soon. Still busy to track the 32-byte-hero-things. It's that hard, because there's rarely a push/pop for a register, so that you could say, life of the access ends here. So have to carry back a lot of stuff all the time that probably isn't needed anymore.
Then again, sometimes it is, and guess - maybe with a wrong type.
I still got the original Bloodwych-box, but, for Atari. Like Dungeon Master, I loved the game because being bugfree all the time. I have no idea if that's the same for the PC-version, because in fact there are *some* bugs, especially in the 2-player-game. That I'm sure about!
Question is, if the circumstances and conditions appear while 'normal' gameplay. Not sure if I will be able to reproduce them during gameplay.
Logged

MadMunky

  • Forum Mod
  • A600
  • *****
  • Karma: 2
  • Offline Offline
  • Gender: Male
  • Posts: 244
Re: Bloodwych PC Disassembled
« Reply #38 on: August 06, 2014, 10:47:42 AM »

Hi Bit,

Just checking in :) The PC Version was not know too be bug free and there was a save game hack to remove a pillar next to the 'Welcome Back' stairs, maybe these are the bugs your seeing.
Logged

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: Bloodwych PC Disassembled
« Reply #39 on: August 06, 2014, 12:54:26 PM »

Looking at a YouTube video of the PC version, one bug is that the "eyes" of the beholder creatures between normal and attacking are the wrong way around! (I.e. It picks the opposite graphic)

If they can miss that, they could miss anything....



Sorry I am not around to answer many BW questions ATM - my work and my near wedding are taking over all of my time at the moment!
Logged
Quote from: KillerGorilla
because winuae is made of code and your amiga is made of stuff

MadMunky

  • Forum Mod
  • A600
  • *****
  • Karma: 2
  • Offline Offline
  • Gender: Male
  • Posts: 244
Re: Bloodwych PC Disassembled
« Reply #40 on: August 06, 2014, 12:56:00 PM »

Another one was the characters in the shields are the wrong size :)

So I think it clear to say the PC Port was not so well done..
Logged

Bit

  • A600
  • *
  • Karma: 5
  • Offline Offline
  • Posts: 69
Re: Bloodwych PC Disassembled
« Reply #41 on: August 07, 2014, 03:27:53 AM »

It's all pretty annoying. I did setup one last pack that I want to handle with modified tools automated (from my dm-works). But in the meantime I also learned how this source can fool those tools!

I'd better like to drop this and move over to the Atari-version instead.
I'm not afraid of the hardware calls and the 68000, I'm pretty familiar with it, so, I'm sure I could make a disassembly well splitted in code and data, but I know very well how the other endianess can give headaches to make it finally run. Maybe I first try to dig out the original discs that I own for sure, and check if I can read them somehow, so that we have that stuff at least.

And - my best wishes to you HH!
« Last Edit: August 07, 2014, 03:30:01 AM by Bit »
Logged

MadMunky

  • Forum Mod
  • A600
  • *****
  • Karma: 2
  • Offline Offline
  • Gender: Male
  • Posts: 244
Re: Bloodwych PC Disassembled
« Reply #42 on: August 07, 2014, 07:39:41 AM »

Hi Bit,

Not sure you have seen this http://www.ultimateamiga.co.uk/index.php/topic,9733.0.html Im pretty sure the Atari and Amiga versions are Very close

I have the Atari Automation 122.st & med_038.st if they are any help to you
Logged

Bit

  • A600
  • *
  • Karma: 5
  • Offline Offline
  • Posts: 69
Re: Bloodwych PC Disassembled
« Reply #43 on: February 09, 2015, 08:34:56 AM »



Nah Blodwyn - it's not that devastating!
(Atari-version of normal and extended level-version running fine (except sound - but still much to do).
Logged
Pages: 1 2 [3]   Go Up
 

TinyPortal 2.2.2 © 2005-2022