Messages posted by: Soultaker

Update: on Windows XP, the game runs fine, so it's not a hardware issue per se.

I have the same problem, at full-screen resolution (1680x1050 in my case), with an AMD Athlon64 3000+ (2 GHz). Episode 1 had the same problem, but to a lesser extent, which is why I didn't complain about it then. I should note that the gameplay is so choppy that it makes the hard minigames practically unplayable (especially Gabe's en The Player's hard attacks, which require accurate timing).

Running at a lower resolution "solves" the problem, but I need to turn it down considerably (e.g. to 800x600) and not only does the game then look pretty blurry (TFT scaling sucks) but the view is windowboxed too. So I'm seeing an ugly image with a big black border all around; not really a solution i.mo.

I know my CPU is not the newest, but it's still twice as fast as the recommend minimum requirements, so I don't think I'm asking too much that I can play the game at full resolution (with graphics quality set to "normal", not "high").

ATimson wrote:

Iron Curtain wrote:Unless there is a book-cloning device of which I am not aware that allows its customers to make duplicates of books and send them through a pneuma-tube system, that is a flawed analogy.

Photocopiers and scanners.

I still don't think that's a valid analogy. Photocopying a typical novel of, say, 300 pages takes hours. If you have it in digital form, just printing it takes a lot of time as well, and at least $10 in paper, ink and printing supplies. Then you have a bunch of unbound papers that are too many to staple. While I've happily payed more for printed editions of public domain texts, just because it's nice to have a decent hard copy, I wouldn't think of paying for a stack of paper.

So the analogy doesn't apply, because:

unlike copied software, home-printed books are not nearly as nice as the commercially sold alternative.

unlike copied software, which is basically free (assuming you have an internet connection anyway, which seems fair, especially if we're talking about games that are distributed over the internet) , the cost of home-printed books is in the same order of magnitude as the price of the legitimate product.

unlike copied software, printing your own books takes a lot more effort than just buying it.

So I don't think book publishers are in real danger of missing out on sales because of illegal copies of books.

Have you tried copying the save files?

Where are the save files?

Grover wrote:I am impressed by your work so far. As an aside it took me a day to cook up the hha format, the writer is about 50 lines of python code .

You should've posted the file format then; would have saved us a lot of time.

In retrospect, the HHA file format is very simple and very clean, and it's surprising it took so long to figure it out. If any obfuscation/encryption was used, we wouldn't have had a chance at figuring it out (or at least not without examining the game binary which uses the files).

Ok, one more update to the HHA tool: support for creating archives. The created files are about 0.5% larger than the official ones, but that is good enough for me. The tool is now feature-complete as far as I'm concerned, so this should be the last update for a while.

Again, a Linux version is available (hha-0.3-linux32.gz) and a Windows version (hha-0.3-win32.zip).
There's also source code: hha-0.3.tar.gz (commit)

By the way, did anyone manage to mod anything interesting yet?

Thanks Bhelyer

In the mean time, I figured out how to decompress the LZMA (type 2 compression) correctly, so I updated the tool to version 0.2! Grab it for Linux (hha-0.2-linux32.gz) or Windows (hha-0.2-win32.zip).

Since the tool can now extract all files, it no longer modifies the original archive (that would be pointless). If you want to use modded files, make sure you rename the archive files, so the extracted files are used instead. Happy modding!

Oh, sure. I've set up a Git repository at git://hell.student.utwente.nl/pub/repos/hha
Accessible by web as well (but slow): http://hell.student.utwente.nl/gitweb.cgi?p=hha
A snapshot of the current version: hha-0.1.tar.gz (Also contains a file format definition as far as I figured it out.)

(NOTE: these files are of interest to programmers only; if you just want to use the tool, use the link I posted earlier.)

By the way, I think that type 2 compression is actually LZMA, although I can't decompress them yet.

Yeah, someone should buy me a MacBook so I can build a Mac version.

Actually, I already figured out type 1 compression (which is just a Deflate stream) so only type 2 remains. Unfortunately, most files are compressed with type 2. Also, I noticed that you don't need to repack the files into an .hha-file in order for the game to use them. They only need to be removed from the archive, and then the unpacked files (in the file system) are used.

So I wrote a tool to extract files from the archive. Get 'em here:
hha-0.1-linux32.gz (For 32-bit Linux)
hha-0.1-win32.zip (For 32-bit Windows)

To test, I replaced the texture for Anne's lamp with the texture on the floor:

It isn't much, but is shows that editing the files does work in-game.

Important note:
Extracting files removes them from the archive! (This is because if you keep the files in the archive, then the game will use those instead of the uncompressed files that you want to edit, and you can't throw the archives away, because they still contain unextractable files.) Therefore, before you do anything, make a copy of your "common.hha" and"parpg.hha" files. (Alternatively you can restore these files by reinstalling the game, but that's annoying.)

For Linux users:
File names are case insenstive in the archive, but case senstive in the Linux filesystem! The game does not refer to files using the same capitalization that is used in the archive, so on Linux files may need to be renamed after extracting them, or the game cannot find them and crashes. To detect when this happens, try running the game as follows:

And look for misspelled filenames. I noticed only two or three filenames that have this problem, but there may be more. (Maybe we can compile a list.)

I did some research of my own and it appears that there are three types of compression used, numbered from 0 to 1. Only a small fraction of the files are uncompressed. See this table:

Type 0 is uncompressed, so that means a maximum of 52 files. Type 1 is "deflate" compression, I believe, so it should be relatively easy to extract those as well, which brings the number of extractable files up to 227.

Also, I believe that it's possible to replace any file with a file using a different form of compression. So if you happen to know that, for example, file foo/bar.swf contains a cutscene even though it has compression type 2, you can still replace it with an uncompressed file you created.

mathboobs wrote:I actually have a working .hha extractor now, at least for the uncompressed files.

Source code or it didn't happen!

jandrese wrote:I couldn't get it to work under FreeBSD sadly, the game dumps core while trying to load the libraries from the looks of it.
The ktrace was horked up pretty bad so I didn't get a good picture of what was going on.

I tried with FreeBSD 7 emulating a 2.6 kernel and using Fedora Core 6 as the Linux base and I got a different result: the binary just runs in an infinite loop, using 100% CPU, but not showing any windows or making any progress (as far as I can tell). I tried to see what was going on with truss instead of ktrace but it crashed (maybe it's not meant to debug Linux binaries) so I gave up as well.

The OpenGL implementation is specific to the driver of the video card used in your system, so Hothead can't provide you with one (and that's disregarding the legal issues entirely). You probably need to install the 32-bit version of your graphics driver (in addition to the 64-bit driver) to get a working libGL.so for use in 32-bit applications.

I don't know about Fedora, but on most systems the support for 32-bit libraries alongside of the 64-bit libraries is called multilib support, so you may want to search for that. Some quick Googling seems to suggest the package you are looking for is called "xorg-x11-drv-nvidia-libs-32bit" but as I said: I'm not a Fedora user so I could be wrong.

I wouldn't recommend manually installing files in /usr/local. A better place for self-contained packages like this is /opt if you want it to be available globally (every user still has to activate individually though).