Ultimate Amiga
Games Corner => The Crypt of Bloodwych => Bloodwych Editors and Modifications => Topic started by: MadMunky on May 07, 2014, 12:21:52 PM
-
Bit, over on the Dungeon Master forums has told me he is currently disassembling the PC version of Bloodwych, I will post up as he makes progress or advises he can not progress this but hopefully with this we will get two things
1. A Windows version of Bloodwych (crappy PC graphics unfortunately, but maybe one day these can be replaced with the Amiga/ST graphics)
2. An understanding of all the functions used in the game so we can fully understand how the logic works for Monster AI, Combat etc..
-
a real shame he is not disassembling one of the 68k versions :/
Still ... you are right that an understanding of the general game code would be of great help to producing sequels/remakes etc!
-
a real shame he is not disassembling one of the 68k versions :/
Agreed but the logic for all versions will be the same so will hopefully make remakes a lot easier
-
Hi folks!
MadMunky brought me to this place, and I'm pretty surprised about the activity :)
After he presented his project in our forums, I spontaneously decided to support him in any way, because I ever loved this game too and it was already a theme this year.
About the progress: It works fine - but I'm still not sure if I just work on an interpreter language compiler - sure that this was done in C?
Amiga conversion - well - if at all, I'd prefer the Atari - if there weren't the endianess problem. All data formats longer than one byte are 'upside down' and I've been through with this when I worked on DM-stuff. BW for PC is pure 16-bit-code, but on the 68000 it's probably not - the compilers will have done their optimizationx...
Perhaps - if I got the PC-version running at all, we can have a look on it.
Until then, simply press thumbs that it comes up at all.
Edit: Ouch. I just realize what you are talking about when you say AMOS. So it *is* a basic program after all? If so, I maybe bring it alive at all, but no one can bother me to analyze basic tokens then. That's a shock! >:(
-
Hi Bit,
I believe they are talking about wanting to port it to AMOS not that it was originally written in AMOS :)
-
I just hope that you are right and that it wasn't vain.
Let's see how far I'm after the night - keep you informed.
-
The 68k code of the amiga and Atari versions are almost identical. I am sure from everything I have read about development that the games were written directly in 68k asm... Having disassembled some parts, it's obvious from how clean and tidy it is in structure.
The comments about Amos, yes I am talking about using that for a remake on the amiga (Bloodwych pre-dates AMOS!).... And purely to make additional development easier/quicker.
-
Well hopefully from all the information Bit finds on the PC it will make writing a clone very easy as we will already have most of the functions/logic
Only disappointing part is there is no Data Disk for the PC though I don't believe they really added much which we couldn't work out ourselves once we know more about the original
Maybe Bit could take a look at the ST version of the DD if he manages to get somewhere with the PC Version.
Best of luck Bit :) Keep us updated, exciting times for Bloodwych :)
-
something's working :-*
-
something's working :-*
This looks very promising!
-
Don't be too excited, that's just a beginning. It shows that the translation was basically successful and the emu is working at all, first dos-interrupts too.
So it loads the sounddriver fine then - which is pretty obsolete, because that one will surely be replaced (not knowing yet how the sound gets generated at all).
In the next part it sets some interrupts - for that workarounds are necessary too, and then it comes to the graphics.
Once I got the character selection screen in the window, with a working mouse, we can celebrate having the biggest problems solved, because then it should run until it hits one of those couple of leftover jumptables. Think I'm not too far away from that.
Those estimated two months seem to shrink :)
-
This all sounds VERY promising, it would be so good to finally know all the inner workings on the game :D :D :D
Keep up the good work Bit, I cant believe how quickly you are getting this done, all them late night doing Dungeon Master has paid off
-
Now, this one really means a lot more!
It means:
- the graphics driver gets loaded
- it can read, inflate and convert the original PC pictures to truecolor(!)
(so the emu-code survives a lot!)
- which also means, the workaround for local memory (de)allocations works
- the combined linking of allegro42 and allegro5 works - need the old one for a MIDI-driver. Both libraries don't bite each other.
- Multithreading works! Eventqueue (incl. timer-ticks) runs in a separate thread.
TODO-list: sound, mouse, keyboard, timer, leftover jumptables.
btw: it runs in windowed mode only, but you can resize the window as you want, so also click it fullsize. still, the basic resolution stays for 320x200 (for now!).
-
Excellent work!!!!
-
Will answer the PM here, because of the picture:
Yup, even with better graphics, for analysis the EGA-chip is a showstopper. That's why I proceed with CGA (which is still slow enough in decoding). Once analyzed, the driver part can be replaced completely to handle even hires-truecolor-pics (if available).
I do have some stops in it because of unrevealed indirect jumps and sound is bypassed yet, but there are not much problems left.
Still - obviously is smth wrong with the map here - the view should have some elements. Will fix that. But well - a lot of things work! 8)
Newer VS-versions - ... probably - don't have them. There will be surely people that can test too once I got the source stable.
ps.: see the resolution? that's all done on a simple notebook ;D
-
Awesome bit! It looks like you don't have a lot left apart from cleaning bits up :)
I have a VS2013 so I can test that once you have the source ready to share.
-
About decoding the graphic files.
Like this? 8)
-
Bit,
I've never been so pleased to see the PC Graphics lol, how about a monster file?
-
Once decoded (by the current program, then saved buffers), I found basically two types of files - those like ICONS with a 4 byte directory, and those like WALLS and ... monsters and body parts... with a 6 byte directory. The first two bytes are always the offset of the real graphic datas, not sure about the other ones - either some type-enumeration, or something with width and height (multipliers). Pretty sure that this riddle will be solved soon, and then you'll get a monster file too.
Somehow I have to grab the text character patterns from the CGA-version (which makes the same in the end).
The 17 graphicfunction do work pretty different in both modes, so it's still a good guess what's really happening. But with those decoded files, it makes life easier and once that is done, it's just the sound which is left to do. Because this always accesses register 0x388, it should be MIDI, and I hope that I just have to find the right position of the song datas to feed Allegro with it. A 'little' sound enhancement will happen then ;D
One important question for that you surely have a quick answer:
Does the shape of the mouse cursor ever changes? If not, I just drop all original mouse stuff, because that's a fun stopper too.
-
One important question for that you surely have a quick answer:
Does the shape of the mouse cursor ever changes? If not, I just drop all original mouse stuff, because that's a fun stopper too.
Nope its always the same image, only different colours for 1 or 2 player
-
What here looks a bit silly, is an important step.
Left side shows the game in CGA-mode, right side in VGA (it's nothing but EGA also) - the same time.
It tells me that the rewritten EGA-decoding and drawing/blit-routines deliver the same result as the CGA-version (which works by simple decoding). Of course the new routines are a lot faster and allow to bring in each type of graphics-file - in fact the screen you see is already truecolor. So far a little more than 50% of the decoding and blitting functions are replaced. All the rest can be done pretty fast now (hope so...)
-
Keep up the good work bit, it sounds like we will have a good running PC version very soon!
-
Hi Bit,
Hows things progressing? maybe you should also post up some of your plans for your version like you told me you wanted to add network support :)
I'm really interested in trying to find out how BW pieced together all the images for monsters, thing is causing wishbone and myself a lot of issues :)
-
Had some hard fights the last days with the source - a dumb bug in a simple emu-command fooled me a lot and did cost a lot of time.
For the graphics thing I could read out some basics from the source of DosBox (which is for old DOS-games the same as UAE for the Amiga).
Then found the basic chip-description of the VGA-chips in an Intel-PDF.
But - even this needed a lot of analysis and tests - and then this bug, which caused to compute false values for the table which manipulates the floor graphic.
Now about those graphics:
Once inflated, there are two types of files:
Both begin with a directory, then the datasets of those entries.
- first one got a directory in the beginning with four byte: word data offset, then two bytes.
- second one got a directory in the beginning with six bytes: word data offset, then follow four bytes.
While the extrabytes of the first one simply describe kind of bitmap-width and height, are the additional bytes of the second one for
masked blitting.
Told you already that there are 17 graphic routines.
Here a short description:
gfxfunc01 - loads the behemoth, shows it on the screen, and inflates then all graphic-files.
gfxfunc02 - palette setting
gfxfunc03 - clear screen
gfxfunc04 - blit framebuffer to screen
gfxfunc05 - icon 4-type I
gfxfunc06 - viewportrendering - ceiling/floor. There is an extra table needed to blit those perspectivic lines.
gfxfunc07 - helper for inventory/stats,/scroll
gfxfunc08 - icon 6-type I
gfxfunc09 - icon 4-type II
gfxfunc10 - icon 6-type II
gfxfunc11 - not hit yet, but is solved
gfxfunc12 - not hit yet, can't say if I got that one
gfxfunc13 - text, blits characters
gfxfunc14 - draw vertical line
gfxfunc15 - draw horizontal line
those two also used for filled (background) rectangles
gfxfunc16 - and ...
gfxfunc17 - are about the mice - don't know if I will keep them (costs massive time)
with other words - this chapter leaves just a few questions.
One of them is: can that be easily translated into routines that can be used for all purposes, like truecolor-PC-graphics, perhaps enhanced amiga-gfx and in the end for your Java-script-project.
At least I should make a bundle and send the inflated gfx-files to you.
Allegro allows to load png-files (that include alpha-channel infos), so probably we end up with those.
I have to continue now - wondering why it will not blit walls and other characters - that's the next one.
Then (and those are not so good news):
I made a subroutine-tree.
There are three issues where routines may call (over some indirections) recursively. And there is a problem:
The assembly knows jumps and calls.
Now, a lot of routines simple jumps (or runs) into each other, local stacks are almost never used, parts of routines are here and here, and often another routine calls the same one that it finally runs into.
That is PURE SPAGHETTI!
No idea if that one was programmed in GFA-Basic that also could compile. But must be something like that - that really doesn't look like a C-compiler did that! Has the good thing, that we don't have to fear stack-problems (except recursivity), all variables are global and for that structures probably can be analyzed with not that much problems. But routine parametrization can hurt.
So far now.
I do have a plan (in different steps) how to continue to make that all readable in the end, but for now all those emu-glyphes are necessary to keep it as bugfree as possible.
A first complete version could be ready by the end of the next week, I hope...
Plans ..... - what is a plan? :P
Now looking where the monsters are...
-
So, just a short report.
The graphics are all running in VGA-quality - and if other heroes are monsters too, then we got monsters! Haven't left the base level now.
And they are also moving!
Though - in this first version there was a lot of manually typing - so dangerous, and I want it really bugfree. Having learned a lot of the source and detecting some patterns lately, some more switch-gates give the source much more sense. So, currently I'm setting up a 2nd main file, progressing well. I do that also for the reason, that I have some problems in the overall blitting process. Walls and doors vanish and come back randomly.
The reason that I had no elements in the viewport in the beginning was really hard to find - and in the end it was a bug in the handling of the flags in the decrement-command. Wonder why this bug did never affect all the DM-things, because that was a pretty old bug.
btw: a big thanks to HH's tables. This helped me now to find (and confirm) a lot of things in the data-area. For a longer time I thought it calculates messy when collecting the offsets to the map-location. But then it came out that this was pretty right.
-
Now, I can move around, open and close doors, all user-interface things work, and there are only two visible bugs now.
First one shows wrong colors on arms, and the right one gets not mirrored (no problems with legs ::))
And the cursor keys don't flash, their clicked picture will not reset to normal. Once clicked, the icon stays. But A LOT of things work very fine.
Edit: Arms fixed :)
Therefore I spotted that dialogue texts vanish too fast...
This one - and the cursor keys not being handled - that could be the effect of the one really hard to solve problem.
-
Excellent Bit,
Is the problem with text fading that everything is running too fast? When do you think your have a source your release? did you manage to get the monster/character sprite sheet decoded like you did for items?
-
Now that I call emulator-commands, graphics should be very slow, but the timer ticks all 50ms. Probably when the text appears, the timer already says 'clean it' again. The heroes don't jump left/right fast as they do in the DOSbox, but they don't stay in one place very long.
Heroes and monster are basically the same, so yes, they are decoded now. Though - in pretty slow code, because:
I already did write that there are two types
- one are the items, in a 4-byte-directory (2 offset in the file, and then two bytes that are not directly width and height, but close to it). Basically their datas come in 4 color-planes, so, starting with the first plane, whereby each byte is for 8 pixels. Then come the bytes for the next 8 pixels, etc. After that come the datas for the next plane, until all planes done. Each pixel has now 4 bit informations which together now give an index 0...15. That is NOT directly the palette index, in fact there's one more indirection. (The first four colors can be changed that way, depending if the picture is for player 1 or player2)
Heroes/Monster do have a 6-byte-directory. There are not only 2 bytes more in the directory, their datas start with an extra 'plane' - (just giving it that name because it's as big as one color plane). The extra bytes obviously are used for another offset, and this extra plane gots i.e. a mirrorscheme (depends on the 'interpreter'-routine).
Because all of this is pretty optimized for the EGA/VGA-chip, it's now a pain to 'draw' that to an emulated EGA-bitmap, then translate it to an emulated 256-color-VGA-bitmap (because of the palette), and finally translate it to truecolor... That really costs time!
But all of this is now harmless compared to another problem (which also could bring up the cursor and text problem):
While there are 'compact' subroutines, there are also a lot of branches left - after all those are pieces that belong to indirect jumps (there are about a dozen jumptables). But here it gets wild! A lot of them become sometimes 'jumped' by a JMP/goto - command, but also with a CALL (so, a treated as a subroutine with a proper return). I could solve that with a macro that calls such branches always as a subroutine, assuming that sooner or later comes a return, means, a line like
if (condition) JUMP(sub_12345)
gets in fact expanded to
if (condition) { sub_12345(); return; }
That works fine until there are no indirect recursive processes (i.e. routine1 jumps to routine2, this one to routine3, and that one back to 1)
But there are!
And - much more evil:
There are 2 stack-issues in the whole program. I wonder if Hungry Horace spotted those in the Amiga-disassembling too.
There's one routine that pushes a function-adress to the stack, which means, the next upcoming return will not jump back to the caller, but to this 'hooked' routine (which could correct the cursor i.e.).
Tracking to which routines that goes, one could surely give a note to those routines that there is something left to do before they end - but exactly here is the most weird switch with 36 cases, some of them with 'gotos' (so adresses within the function), but also a lot of JUMP (so branches that need to be outside because called as a subroutine from other parts as well).
The second problem is a routine that got a mysterious 'pop' in the end.
This one is called one time when it solves an leftover push - that's fine, but it's also called a second time when the stack is okay, so, here it kills its own return. This could be easily fixed, but at the moment I have no idea if that is serious (that would be evil!!!), or if it's really an original bug...
There is also a third thing that writes to memory location 6, so, into the startup-code. That's surely not meant that way. That is an original bug!
I'll get Hungry Horace's Amiga disassembly and try to find those ones.
Maybe he already knows what to do there.
btw: with the second setup of the main file, I did translate the original IDA-listing with a lot of regular expressions into my code, so either a bug happens more often and can be detected soon - or it's really bugfree...
edit: give me 24 more hours to checkout those known problems and then i'll send you a first source, also containing the inflated graphicfile-buffers and the IDA databases for the main program and the drivers, which is now pretty good splitted into code and data (but most datas aren't structurized now - still, jumptables and texts are).
-
The evil critical first problem is solved!
That was really the hook for the reset of the cursor-icons.
I call it immediately instead of pushing the adress and all works fine.
Puh!!!
The thing with the text: well, usually gfxfunction 03 is called with every drawing cycle - and that cleans the whole screen. I now wonder which routine is responsible to draw the communication text again. If that will not happen, it's no surprise if it just flashes up for one cycle. Pretty sure that this one can't hide for long.
Have to adjust keycodes and will check a bit for the sound too today.
Then savegame has to be checked. But I don't care for the two player mode in this first version!
edit: 2nd problem solved too (miss a bang-head-smiley here...) ::)
-
All old problems done.
Save/Load game works, quickstart works, keys are adjusted.
I'm with the sound now - a first impression gives also one really mysterious pop, and it's a bit tricky because both threads access it.
-
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
-
Hi Bit,
Hows things progressing? not heard from you for awhile :) hope there is not any show stoppers
-
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.
-
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.
-
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.
-
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:
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; }
};
-
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
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
-
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.
-
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.
-
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!
-
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..
-
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!
-
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
-
(http://www.akluwi.de/bw/blodwyn.png)
Nah Blodwyn - it's not that devastating!
(Atari-version of normal and extended level-version running fine (except sound - but still much to do).