Print

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

[MadMunky]

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.

[Bit]

About decoding the graphic files.
Like this? 

[MadMunky]

Bit,

I've never been so pleased to see the PC Graphics lol, how about a monster file?

[Bit]

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 

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.

[MadMunky]

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

[Bit]

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...)

[MadMunky]

Keep up the good work bit, it sounds like we will have a good running PC version very soon!

[MadMunky]

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

[Bit]

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? 

Now looking where the monsters are...

[Bit]

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.

[Bit]

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.

[MadMunky]

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?

[Bit]

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).

[Bit]

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...) 

[Bit]

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.