tkcmd: ?
for me armored fist works in rjpa's build: dosbox20040122.zip
and it crushes immediatelly after typing fist.bat with a screen covered with random characters with this:
dosbox20040131.zip
dosbox20040203.zip
and official release 0.61

did some more research
These problems indeed still exist BUT it seems that when u try a few times armored fist then runs
Weird bug
must be something time dependant

yeah,it seems to be random with core=normal

but always works with core=full and with core=dynamic 😀

*bump from hell*

Here's another game which definitely uses one of the 2/2.6/4 bit pack formats. I'll try logging not only DSP messages but full data streams as well. (or I can work out the data bank format, which should be easy since it doesn't appear to be compressed.)

None of the existing methods appear to be completely functional, either. I mean, at least the 4-bit decoder fully references its scale adjust table and masks off the sign bit, but appears to apply it absolutely instead of adding it to the current scale. Since the table is in the range of -2 ... +1, and the clipping is +2 ... +6, the scale factor is effectively stuck at 2. Or maybe I'm not reading this right.

Hmm, I recall Blaster Master supported packing and unpacking 2/3/4 bit files, but I don't remember how well it worked. Maybe that code can be reverse engineered, or even acquired with permission? (Assuming he did not just use the SDK, which it appears he did, at least for playback drivers...)

Anyway, I present... The Last Eichhof. Whee. (and since various links on the site are broken, (absolute links to the wrong/former server) here's the download link)

This implementation (for 4-bit at least) is from vdmsound. There is also one from Sox (removed) which was even less correct than this one.
I agree here. max(min(..)) always puts scale factor at 2. I had no idea how to calculate correct factor.
I 2-bit/3-bit implementation was based on assumption that it is same as 4-bit except for precision bit(s). At least it sounded better with DN2.

Ah, okay. I'll see what I can do now that I remembered that editor at the last minute, heh. Surprising that nobody has leaked the old SDK in an obvious way...

EDIT: Okay, here's a patch which changes the decompression to match what BLASTER Master is doing, and since it may access the data tables in an unsafe way, I threw in some assertion checks, but it seems fine so far... Perhaps it could use some optimization, or perhaps the original code was close to doing what this does, but at least the output is now consistent.

Gee, I hope I didn't just disassemble Mr. Maddox's hard work and not just Creative's SDK...

EDIT again: Haha, didn't know Duke Nukem 2 used that until I browsed around here and there yesterday, I wondered why its sound was so iffy on random implementations. (Yet, my original Packard Bell sound card / 14.4 modem managed to support that perfectly, even though Jim Dose's sound system (in Rise of the Triad and most Build engine games from 3D Realms) managed to hard lock it at frequencies over ~14KHz or something...)

Congratulations for successfully reverse-engineering Creative's ADPCM.
It now sounds exactly as it did on my old VIA board which had SBPro emulation. (new code Works OK with both DN2 and eichhof)

This should go in CVS, Qbix?😉

Btw. mplayer/libavcodec people recently implemented this codec (I think using Sox code?), they could be interested..[/b]

Mostly reverse-engineering existing decompression code. Dosbox debugger rocks.

Off-topic, no Duke Nukem 2 fun for me, unless I play with keyboard. For some reason, the game pauses itself (like I pressed P) every time I use the first button on either of my controllers. I guess I could find some way to remap the controller to the keyboard...

Srecko wrote:

Btw. mplayer/libavcodec people recently implemented this codec (I think using Sox code?), they could be interested..[/b]

According to this, those compression formats are not supported at all.

Hmm, and it's probably patented too. We can't have that, now can we? (Edit: Successfully trolled by the mplayer/ffmpeg projects. Since when are compression algorithm patents covered by software patent laws?)

I didn't ever try it with controller.
Hm, it seems libavcodec uses other thing than I thought it does(only 4-bit). And it mentions reference implementation...
It is patentable(in the USA at least), but they probably don't bother because it's outdated and mostly obsolete.

Yes, I have seen that. I believe that is CT ADPCM, which is not ordinarily supported by SB in "hardware", per se, but through uploadable ASP/CSP code. Dosbox is probably a long way off from that, anyway.

I only mentioned patents because the Mplayer and FFMpeg home pages morphed into "Fight the EU Software Patent laws!" propaganda. I am not really sure how the concept of software patents in the EU applies to existing patented compression algorithms. I suppose they could take the LAME approach and force the users to compile it themselves and/or provide binaries, and thus offset the patent infringement to them, I think...

Creative could apply for a patent in some of european countries to prevent mplayer have it implemented because patents are not recognized worldwide as copyright is (i.e US patent isn't applicable in EU).
(But they stil could prevent software from being legally used in the US.)