Register - Login
Views: 99844534
 Main - Memberlist - Active users - Calendar - Wiki - IRC Chat - Online users
Ranks - Rules/FAQ - Stats - Latest Posts - Color Chart - Smilies 		05-04-22 12:02:03 AM
Jul - The Cutting Room Floor - Her Interactive .AVF Video Files New poll - New thread - New reply
Next newer thread | Next older thread
lue

Micro-Goomba
Level: 8


Posts: 3/11
EXP: 2012
For next: 175

Since: 01-01-14


Since last post: 8.0 years
Last activity: 6.1 years
Posted on 01-22-14 02:35:29 AM Link | Quote
For a while now I've been trying to decode the .avf video files present in some older Nancy Drew PC games, so that I may write a decoder and watch them without having to run the game and doing some symlinking to speed things up a bit. From the one scrap of info I've found on the format, it's a highly proprietary video format playable only in the game. I've so far only looked through games 1 (Secrets Can Kill, not the remastered version), 10 (Secret of Shadow Ranch), and 11 (Curse of Blackmoor Manor), and most of what I know on the file itself comes from the first game.

The files are used exclusively for video in the first game (and presumably the next four games as well, if the DreamCatcher connection gave rise to the format), and are almost entirely replaced by BINK files in games 10 and 11, with the AVFs used for various static-image puzzles and "fidgeting" animations by then. They appear to be a video-only format, as all the sounds associated with the game are in separate audio files.

Here's what I've discovered on the file format so far (presented values come from the first game's Intro.avf, the largest avf in the game):

Each one starts with a text string identifying the file and the developer who presumably generated them (always Wayne Sikes). It appears to be null-terminated, since a null character follows the text, and the resulting odd number of characters would explain why other numbers in the header start on odd offsets.

00000000 41 56 46 20 57 61 79 6e 65 53 69 6b 65 73 00 |AVF WayneSikes.|

Next up are a couple of numbers whose significance I don't know. Note that in a couple of avf files I've looked at from 10 and 11, the 01 is instead 00. These numbers are consistent between all files in the game.

0000000f 01 02 00 00 00 00 |......|

Next up are three two-byte values:

00000015 52 01 78 01 cd 00 |R.x...|

The first value indicates the number of entries in the index, which will be presented shortly. Next up is the width and height of the video. Remember that this is Windows thus Intel processors thus little-endian .

Next up in the header are some more unknown values, but these appear as-is in all of the first game's AVF files as well as those of 10 and 11.

0000001b 10 42 00 00 00 02 |.B....|

Immediately after that comes the index, which consists of a series of 19-byte entries pointing to where each frame's data is. Here's one such entry taken from the middle of the index:

00001062 db 00 dd 9c c6 00 5b 9c 00 00 30 5a 02 00 00 ff |......[...0Z....|
00001072 ff ff ff |...|

Each entry begins with an entry number, zero-indexed. Afterwards is the start offset for the frame's data. Following it is the size of the data. After those numbers comes two constants. The file-local constant is constant throughout all entries in a file's index, but changes between files. The game-local constant is the same throughout all files in the game. I've noticed that in games 10 and 11, the 0xff values are instead 0x00. I'm not as sure that the leading 00 00 is constant across files, though I've yet to see it be anything else.

...And that's all I know the meaning of. As for the frame data itself? All I know is:

  • There's no discernible header to the frame data, it just starts.

  • The frames are compressed. Not only is this not surprising for a video format, the variable size parameter in the entries suggests this.

  • Whatever compression format it uses, slight changes to the image don't appear to affect the entire block of compressed data (i.e. no checksum-style cascading changes)

  • The game requires you to have at least 16-bit color, meaning that's how many bits of color it uses for the stuff that appears on-screen. No telling if this correlates with the number of bits per pixel used in storage though.


Let me show a relatively simple image, which may make figuring out the compression used a bit easier. This image is insertcd.avf, a one frame 536x292 video which produces this within the game (hopefully it's obvious that the cursor's not part of the image):



And here's the first 64 bytes of the frame's data:

00000034 7b 01 06 f1 f9 06 06 08 08 f7 01 19 0e 18 0f 0f |{...............|
00000044 30 0c 04 29 15 2b 17 0f 0b 2d 30 1e 1e 26 3e 0e |0..).+...-0..&>.|
00000054 16 42 1d 1b 4e 2c 50 34 68 23 23 3f 31 6d 35 59 |.B..N,P4h##?1m5Y|
00000064 3f 2b 2b 79 37 55 2f 2b 48 c3 3f 35 3b c5 43 65 |?++y7U/+H.?5;.Ce|

Since it's logical for this data to start in the very top-left, we merely have to figure out how this corresponds to a bunch of black pixels, right? Ha ha no of course not:



The components of each background pixel is either 00 or 08, leading to a variety of colors more visible when the contrast and brightness are increased. You'll notice that the silhouette is colored similarly, and now you'll notice the background has a slight red tint to it . (It should be noted at this point that I'm running these games through Wine, so that potentially is what's causing the weird background coloring, though I doubt it.)

The entirety of that frame's entry can be seen at this location for those of you wanting to play with it.

Anyways, that's where I'm currently stuck. I've not had much luck poking around in the main executable, hoping to find a decompression routine, though that may be my inexperience with Windows things . I fear my general inexperience with doing this kind of stuff (reverse-engineering a video codec, specifically) is now getting in my way. So, I thought that is was time I shared what I knew and asked all of you for any help or hints you may be able to give me. I've still got quite a number of games to look through, perhaps one of them spills some secrets by accident.

(I'm half-hoping someone will take all of five seconds to say "Oh, that's simply DEFLATE-compressed data XORd with the string 'AVF '" or something .)

____________________
U+110000 END OF POST
Joe
Common spammer
🍬
Level: 111


Posts: 3077/3392
EXP: 14502112
For next: 366248

Since: 08-02-07

From: Pororoca

Since last post: 13 days
Last activity: 25 min.
Posted on 01-22-14 04:42:09 AM Link | Quote
Based on your description, this might be possible to reverse-engineer just by feeding corrupt files to the game. (I'd say insertcd.avf is a prime candidate.)

Since there are no "cascading" changes between similar frames, the smallest coding unit is probably 8 bits, but that's not a guarantee.

Originally posted by lue
Since it's logical for this data to start in the very top-left,
Or the bottom-left. Windows is funny like that. (Try corrupting the last few bytes in a frame to see where the end of the data is; the start is most likely in the opposite corner.)

____________________
ふにゃあ。
GuyPerfect
Catgirl
Level: 68


Posts: 901/1096
EXP: 2665847
For next: 62953

Since: 07-23-07


Since last post: 1.7 years
Last activity: 220 days
Posted on 01-22-14 01:20:28 PM (last edited by GuyPerfect at 01-22-14 01:23:00 PM) Link | Quote
Originally posted by lue
Remember that this is Windows thus Intel processors thus little-endian .

Little-endian makes more sense, honestly. The only case I've seen for big-endian is humans reading data in a hex editor, and if that's the issue, why not list bytes right-to-left instead?

Think about it. For any bus address X, you can store data Y as an 8-bit, 16-bit, 32-bit, etc. value without moving the starting location around. If the least-significant bytes are always first, it won't matter what size the data type is. With big-endian, a field occupied by both 8-bit and 32-bit data will need to do something like "X + 3" to read the 8-bit field.

Originally posted by Joe
Or the bottom-left. Windows is funny like that.

Once again, bottom-left makes more sense. The old top-left paradigm probably started from textmode console output, where lines of text were read left-to-right, top-to-bottom. But geometrically, positive Y is typically "up". You'll see this even in things like GPU textures like those used in OpenGL and DirectX: the first row of texels in the data is (nearly?) always the bottom one.

Some image file formats like those intended for use on the internet (GIF, PNG, JPEG) list the top scanline first so that while they're being downloaded (over dial-up), the image gradually appears on the page in the same direction the rest of the content does. But other formats, like Windows Bitmap or the aforementioned GPU textures, begin with the bottom scanline.
lue

Micro-Goomba
Level: 8


Posts: 4/11
EXP: 2012
For next: 175

Since: 01-01-14


Since last post: 8.0 years
Last activity: 6.1 years
Posted on 01-22-14 10:22:25 PM Link | Quote
The little endian thing was just a jab at my least preferred number format. Not trying to start a war or anything . And that whole "could start in bottom-left" thing shows you how much I know about image formats . However, the minimal amount of GUI programming I've done prefers (0,0) to be in the top-left, so a more Cartesian coordinate system would seem pretty weird to me for computers.

Anyway, I've messed about with replacing various values in the frame data, and got some interesting results. The idea crossed my mind before, though I dismissed it immediately because I worried that there was no way to mess with it blindly without crashing the game. Thankfully that doesn't appear to be the case .

First thing I did was replace the first 64 bytes of frame data with 0xFF and then filling it with 0xFF00 instead. These are the results I got:



(Left: 0xFF, Right: 0xFF00)

Yeah, the text is printed over the picture. I can blank the text later if/when I need to see behind the text (found where it is), but I'm just examining the corruption in general at the moment.

Next thing I tried was messing with just the first byte, first flipping the bits and then simply incrementing the original number by one:



(Left: flip bits, Right: increment)

Changing the last byte merely changes the bottom-rightmost pixel (picture enhanced for clarity, this is impossible to see otherwise):



Then I figured out which byte was at the halfway point and set it from 0x77 to 0x00, getting this:



(That block of dark green color in the bottom-right is the cursor; I'll get to that in a second)

This closeup shows where the crazy coloring starts, which is not on the left edge of the image, adding another point in favor of compression:



Additionally this tells me the image data does start in the top-left. Unless, that is, some jerk decided to store the data in a boustrophedon fashion. Doubt it though .

Interestingly, changing that middle byte to 0xFF instead causes the same sorts of changes, though the color change is far less severe:



And for some reason the center byte was the only change that caused other graphical glitches in the game (that block of rectangles which is supposed to be the cursor, for instance):



And pressing exit causes Wine to encounter an error, where all the other changes let it work normally.

At this point it seemed pretty clear to me that this is LZSS or similar (makes me think of the GBA), so I wondered what would happen if I changed some even-numbered bytes. So I modified the second byte and then the fourth byte separately, and got these results:



(Left: second byte (replaced by 0xFF), Right: fourth byte (replaced by 0x00))

Massive changes as usual, except I only changed the background color, no color corruption or image shifting. So my current guesses are as follows:

  • Compression likely belongs to the LZ77 family of compression formats.

  • Colors are possibly stored in RGB555 format, which normally leaves one bit unused.

  • That unused bit would be used to indicate whether the incoming data is a color value or instructions for decompressing.

  • Such decompression instructions may be longer than 2 bytes.

If these assumptions are true, then the first two bytes in the data should be a color value. Unfortunately interpreting it as RGB555 results in a light blue color, putting a dent in the LZ theory.

That's what I've got so far. I've got a better idea on what kind of compression was used, something involving sliding windows I'm sure (you may note that the OK and Exit buttons are shifted out of place in some images, which is the most prominent form of that image-shifting I mentioned earlier). More scientific and fine-grained corruption of the image data will be needed before knowing more though . I still don't anything about the format specifically, so the corruption will still have to be done blindly (i.e. without knowing what my changes will do beforehand). But at least I know what I can be looking for.

____________________
U+110000 END OF POST
Joe
Common spammer
🍬
Level: 111


Posts: 3078/3392
EXP: 14502112
For next: 366248

Since: 08-02-07

From: Pororoca

Since last post: 13 days
Last activity: 25 min.
Posted on 01-23-14 01:17:35 AM Link | Quote
Can you try flipping individual bits in the first few bytes? See if any of them cause single bits to change in the color used by the first pixel (and all the other pixels that use that color). Literal values may not be encoded the way you're expecting.

It's also possible it's using a dictionary of some sort, although I have no idea where to begin looking for something like that.

____________________
ふにゃあ。
Sails
2800
as a video game‎‎‎‏‏‎ grows old its content and‏‏‎ internal logic‏‏‎ deteriorateÿ
Level: 102


Posts: 2711/2803
EXP: 10923064
For next: 166903

Since: 07-04-07

Pronouns: He/Him
From: MA

Since last post: 120 days
Last activity: 29 days
Posted on 01-23-14 11:13:30 PM Link | Quote
My sister used to play the shit out of these. Flashback central in here

____________________
lue

Micro-Goomba
Level: 8


Posts: 5/11
EXP: 2012
For next: 175

Since: 01-01-14


Since last post: 8.0 years
Last activity: 6.1 years
Posted on 01-25-14 04:38:47 AM Link | Quote
Hey look, more info!

So, first thing I did was flip each bit in the first three bytes, one at a time. In the image below, all images (except "Original") are positioned according to what bit was flipped to get that picture, most significant bit on the left of course.

( Here are the first three bytes again, in text form: ) 

00000034  7b 01 06                                          |{..|



So it seems to me that the first byte contains some instructions to the decompresser, and the second and third bits are the color value that's in the first pixel and then repeated all over the place.

The color data appears to be stored thus: 

GGGBBBBB

XRRRRRGG

which is seemingly a little-endian stored RGB555 value, complete with unused bit. However, the fact that turning off all the blue bits makes it brighter made me a bit suspicious. So I set all the bits in those two color bytes to zero and turned each bit on, one at a time. Then I turned all the bits on and turned them off one at a time. Except for "All On" and "All Off", the pictures are organized by color value modified, and images within the rows positioned based on which bit was toggled for the picture, MSb on the left.



Yes. Yes, all bits off is a lighter version of all bits on, neither of which involves a grayscale color. Yes, having green's MSb be the only one on is nearly identical to having green's second-most significant bit be the only one off. Yes, there is an unusual lack of distinctly green coloration in this collection of images. And yes, there's a weird affinity towards purple and pink colors.

I'm still confident that this is some kind of RGB555 value, though I certainly have no clue what's going on with the interpretation of them. Next thing I need to do is run the same kind of test as the last image, except turn on/off various color values, instead of bits (e.g. "all green bits on only").

After I figure out what's going on with these color values, the next step is to find the next color value in the data, so I can understand how the compression information works. I don't see how that "unused bit signals what kind of data" idea pans out anymore, It looks as though perhaps there's a one byte header for each chunk of data, with the first byte of the frame data perhaps guaranteed to be a header. I'm still confident the decompression algorithm itself belongs in or near the LZ77 family of algorithms.

Also interesting is that one pixel you can see in the bottom-right area of the pictures, the area that shows the top-left corner of the message box. I wonder how the compression is doing that (if you look closely, that pixel in the message box isn't colored exactly the same as the background color, but tinted to varying degrees by the main background color.)

My best guess for the color data is that at some point it's XORd with some value, or maybe it's stored in a weird DirectX-specific format. There's another possibility that I'm severely unfamiliar with non-8-bit color formats . It'll be interesting tomorrow to see what turning on/off entire color values brings us.

In any case, we're getting closer to figuring this out, I'm just glad it's not taking forever to make headway into this .

____________________
U+110000 END OF POST
Joe
Common spammer
🍬
Level: 111


Posts: 3080/3392
EXP: 14502112
For next: 366248

Since: 08-02-07

From: Pororoca

Since last post: 13 days
Last activity: 25 min.
Posted on 01-25-14 08:42:33 AM Link | Quote
I think there's a colorspace conversion going on, but your all-on and all-off tests might be outside the possible range of values. Try using numbers that are further away from zero/maximum.

____________________
ふにゃあ。
lue

Micro-Goomba
Level: 8


Posts: 6/11
EXP: 2012
For next: 175

Since: 01-01-14


Since last post: 8.0 years
Last activity: 6.1 years
Posted on 01-26-14 03:00:49 AM Link | Quote
I've got a couple more small things to share.

Here's the result of turning whole color values on and off ("white" and "black" are in my last post as "all on" and "all off", respectively):



Definitely some color space weirdness. No clue what exactly is happening though.

I also went through all the bit-by-bit images in the last post and converted the RGB888 pixels to RGB555 manually (essentially, chop off the three least significant bits, put in right spot in RGB555 layout), and compared them to the values I had entered into the file to begin with. This is the comparison chart that resulted. If you look closely, you'll spot that the mapping between what went into the file and what went to screen is not 1:1 .

The problem here is that I don't know how all 215=32768 possible values to put into the file come out on screen. I've only written down the mapping for 32 of them so far. If I want to continue with this method, that's only 32736, or 99.9% of all possibilities left!

Trying to be a bit smarter about this then, it seems that possibly somewhere in the pipeline the colors are stored in a smaller format (e.g. RGB444), though I don't know if the one duplication of output color is a sign that there are many more such duplications, or if it's somehow a fluke.

What's really weird about this, going through the process of finding how the colorspace conversion happens, is how difficult it is to come across a predominantly green color with the testing I've done so far. Obviously green is possible (look at that "Fun With Bits" picture earlier, as well as the UI), though for whatever reason you need a not-that-simple configuration of bits to get greens.

There are a couple more patterns to try out (flip on/off same bit position in every color value is one that comes to mind right now), though I think I'm reaching my limit for boring manual bit flipping .

I'm still open to trying to find the relevant code in the game executable, though I suspect I know so little about rooting around in Windows programs that anyone who could walk me through it would much rather do the investigating themself and save the frustration . Alternatively I could frustrate myself for hours on end looking at the same 5 assembler instructions in a bewildered fashion. Anyway...

I'll go looking for possible non-RGB 16-bit formats after posting this. All of a sudden my mind wants to consider CMYK-like 16-bit formats. I suppose looking into what kinds of colors DirectX can handle would be a good line of investigation.

____________________
U+110000 END OF POST
Joe
Common spammer
🍬
Level: 111


Posts: 3081/3392
EXP: 14502112
For next: 366248

Since: 08-02-07

From: Pororoca

Since last post: 13 days
Last activity: 25 min.
Posted on 01-26-14 03:28:56 AM (last edited by Joe at 01-26-14 03:29:22 AM) Link | Quote
Originally posted by lue
The problem here is that I don't know how all 215=32768 possible values to put into the file come out on screen. I've only written down the mapping for 32 of them so far. If I want to continue with this method, that's only 32736, or 99.9% of all possibilities left!
I have some ideas for what the algorithm might be, but your all-on and all-off tests aren't very helpful for that. Try setting the lowest two bits of each color, and toggling only the third bit of each color. Those eight combinations might be enough to figure out what's going on.

____________________
ふにゃあ。
lue

Micro-Goomba
Level: 8


Posts: 7/11
EXP: 2012
For next: 175

Since: 01-01-14


Since last post: 8.0 years
Last activity: 6.1 years
Posted on 01-26-14 04:44:06 AM Link | Quote
Here you go, Joe. Hopefully this isn't totally unexpected.



So that's where all the green's been hiding . The pattern I see in the resultant hex codes give me some small degree of hope. Tomorrow I'll be able to do more if there aren't yet enough colors to figure it out.

And yeah, I'm pretty sure I've gotten most, if not all, of the useful data I can get by starting from an all on or all off state.

____________________
U+110000 END OF POST
Joe
Common spammer
🍬
Level: 111


Posts: 3082/3392
EXP: 14502112
For next: 366248

Since: 08-02-07

From: Pororoca

Since last post: 13 days
Last activity: 25 min.
Posted on 01-26-14 09:05:59 AM Link | Quote
Each literal byte is encoded as itself (one half of a RGB555 color) plus its offset in the frame. To decode the first color, subtract from each byte the offset within the frame, and then interpret it as a little-endian word containing an RGB555 color.

The bytes "01 06" are at offset 1 and 2, so after subtraction they become "00 04". To choose a new color (e.g. white, "FF 7F") you would then add the offsets back to those values (becoming "00 81").

Okay, now that we can find colors, let's try decoding the first byte.

According to Fun With Bits, the first seven pixels still have the correct colors even if you change the 7B into FB, but not even the first pixel is correct if you change it to 7A or 7C. Interesting! It must be some sort of bit field, interpreted LSB-first. Let's flip it so that the LSB is first: 
11011110

So far so good. Now, referring to Fun With Bits again, let's split that up at each point where more correct pixels appear in the output: 
11 0 11 11 0

Most likely, a "1" represents a literal byte, and a "0" represents a run. If we assume each run is two bytes and each byte has its offset added to itself, things start to make sense: 
11: 01 06 = 00 04 = RGB #080000

 0: F1 F9 = EE F5

11: 06 06 = 01 00 = RGB #000008

11: 08 08 = 01 00 = RGB #000008

 0: F7 01 = EE F7


Congratulations, it's LZSS.

____________________
ふにゃあ。
lue

Micro-Goomba
Level: 8


Posts: 8/11
EXP: 2012
For next: 175

Since: 01-01-14


Since last post: 8.0 years
Last activity: 6.1 years
Posted on 01-26-14 07:29:00 PM Link | Quote
Thanks so much for this! Now all I have to do is figure out how the run data needs to be interpreted, and I'll be able to start decompressing frames .

____________________
U+110000 END OF POST
Joe
Common spammer
🍬
Level: 111


Posts: 3083/3392
EXP: 14502112
For next: 366248

Since: 08-02-07

From: Pororoca

Since last post: 13 days
Last activity: 25 min.
Posted on 01-26-14 09:32:57 PM Link | Quote
The run data contains a 12-bit offset, and a 4-bit length. The first byte of the run data is the low 8 bits of the offset, and the high four bits of the second byte are the high four bits of the offset. The length is the low four bits of the second byte plus three.

The decoder maintains a 4096-byte circular buffer, and probably fills it starting at offset 0xFEE (-18), which is why the first two runs refer to offset 0xFEE instead of 0x000.

It looks like the decoder here is an exact match, if you use 4096 for N, 18 for F, and 3 for THRESHOLD.

____________________
ふにゃあ。
lue

Micro-Goomba
Level: 8


Posts: 9/11
EXP: 2012
For next: 175

Since: 01-01-14


Since last post: 8.0 years
Last activity: 6.1 years
Posted on 01-28-14 03:13:27 AM (last edited by lue at 02-14-14 07:19:32 PM) Link | Quote
Here's the source code of the decoder tool I made. (EDIT: The tools have moved to hertools. Any bookmarks you have should redirect you, but update them to be safe ). It takes an AVF file and outputs a bunch of PNG files as a result. The README explains what you need to do in more detail. Fair warning, the code doesn't pay too much attention towards being easy to use at the moment.

Can't wait to come through a bunch of videos now .

Probably the next thing to do with AVF files is to is write an FFMPEG decoder (so you don't have to generate png files and then combine them into a new video), though that means becoming more familiar with C, as opposed to C++. (If you looked at the source code up there, you saw just how comfortable I am with C++ )

Now that I know how those .AVF files are encoded, I imagine that similar encoding happens for those CIF files that presumably house UI elements and such. (The first game, and it seems most if not all of the games in the series, has at least a CifTree.dat. Additional related files would be named something.cif). Don't know if it'd be worth a new thread, or if it'd be better to transform this thread into a generic "Nancy Drew games hacking" thread for those files .

In any case, thanks Joe for figuring out the how the compression worked. I actually read about a 16-bit, 4096-byte buffer version of LZSS before your post, and thought about that being used here, though it starting at 0xFEE tripped me up when looking at the data. Also what got me was that this form of LZSS reminded me of the GBA's, though the compression between the two is slightly different (GBA ditches the special cyclic buffer and turns that absolute buffer offset into a more relative "how far back from the current position in the output stream" offest.)

____________________
U+110000 END OF POST
WayneSikes56
Random nobody
Level: 4


Posts: 1/2
EXP: 152
For next: 127

Since: 05-05-14


Since last post: 8.0 years
Last activity: 8.0 years
Posted on 05-05-14 01:58:30 AM Link | Quote
Hey guys - I just stumbled across this forum totally by accident but thought I'd contribute a bit. My name is Wayne Sikes. I'm the guy whose name you see in Her Interactive's early Nancy Drew games. I created the engine, all art processing tools, and all publication tools and formats including AVF's. Good job on starting to crack it! Actually I find it a bit flattering that after 20 years you're studying my work. I've published many other games since then but I still have a fondness in my heart for the old Nancy Drew games. We had a blast making them. We almost went broke a few times since back then women didn't generally buy computer games but after the first few titles they really caught on. I left Her Interactive years ago and miss some of the awesome folks I worked with in creating those games. (I did the first 13 titles, then moved on to greener pastures....). Since the AVF format is proprietary to Her Interactive, I won't give the details openly. I did see a private messaging system in this site so just private me and I might pass along a few tidbits of code for you if you're still interested. Also, i'm at wayneloe@gmail.com


Wayne
Sails
2800
as a video game‎‎‎‏‏‎ grows old its content and‏‏‎ internal logic‏‏‎ deteriorateÿ
Level: 102


Posts: 2725/2803
EXP: 10923064
For next: 166903

Since: 07-04-07

Pronouns: He/Him
From: MA

Since last post: 120 days
Last activity: 29 days
Posted on 05-05-14 02:23:33 AM Link | Quote
Well this is interesting. This happens like, never. I've alerted a few of the involved parties, I'm sure somebody will be getting in touch with you via private message

____________________
lue

Micro-Goomba
Level: 8


Posts: 10/11
EXP: 2012
For next: 175

Since: 01-01-14


Since last post: 8.0 years
Last activity: 6.1 years
Posted on 05-05-14 06:49:53 PM Link | Quote
I'm amazed you happened to stumble upon this site, Wayne. It's funny that Last Train to Blue Moon Canyon was your last game, as it happens to be one of the games that I particularly like (mainly for the trains, and desert aesthetic, and of course the laser light show that points you to the location on the map at the end of the game). But that's not to suggest they aren't all great games of course .

Now I kinda want to take a quick look at some games after 13, see how long it took for your name to disappear from everything, assuming it even would have .

I haven't posted here in a while, and the most notable thing I've done with these games is get into those CIF TREE files. If you want to see what I've discovered so far, I keep documentation of that here. Important to note is that, while I do know the 94-byte CIF TREE entries apparently actually began with Message in a Haunted Mansion, I haven't changed the docs to reflect that yet. I'll save that for after I'm done writing up all the unused stuff in Stay Tuned for Danger.

I do have some questions about various unknown values, which I've so far not needed. This would include the unknown values in the middle of the various AVF and CIF TREE entries (save the 94-byte version of the CIF TREE entries, as I've yet to examine those in detail). I'm also curious about those file-local and game-local constants I talked about towards the beginning of this thread, and I'm intensely curious about those 2KiB of what only looks like padding to me in CIF TREEs, and finally those two extra values in the CIF TREE header that have been there every game except the first one. I'll PM you if you want me to explain this a bit more clearly .

Thanks for stopping by Wayne, I'm surprised you just-so-happened to find this. These games (and Nancy Drew in general) are a part of my childhood, so it's only natural that I'd try to see what unused stuff is hidden in them. Admittedly though, I probably wouldn't've started looking into Nancy Drew games if I wasn't so sure we stumbled upon a debug/testing thing in Curse of Blackmoor Manor once . (I didn't figure out how to decode AVFs and the like until I next started looking at the first game, so if there truly was a debug thing, it's probably in a CIF TREE.) In any case, it's incredibly interesting to see what these games I've known since I was a kid are hiding, and hints into the evolution of each one.

If I were more interested in making mods of these games, I'd probably reinstate the 5x5 slider puzzle in Secrets Can Kill. I think I'd leave the 555-TONY bug in Stay Tuned for Danger alone, though .

____________________
U+110000 END OF POST
WayneSikes56
Random nobody
Level: 4


Posts: 2/2
EXP: 152
For next: 127

Since: 05-05-14


Since last post: 8.0 years
Last activity: 8.0 years
Posted on 05-06-14 02:32:30 AM Link | Quote
If you want to email me, I can help you out with a few things (wayneloe@gmail.com) Now you got me curious how long it took Her Interactive to get my name outta their code bank....hehe I'll have to snag a few new games and poke into them. I took a look at your CIFTREE analysis. Hey - you're pretty darn close... I wrote a tool for them called 'HIP' - for Her Interactive Processor - that was used for making CIFTREE's. They were the general storage system for all game scenes, static or animated art 'decals', etc. Everything in a ND game played (at least those games I did) as individual scenes. Each scene was defined by one location you could 'stand' in and each scene was defined by a 'HIF' file which outlined everything that could happen at that location including the conditional logic for possible things to happen. The HIF format was fairly primitive - almost a c-language script - and originally I had a fellow writing a cool editor to build every scene. Well....there's always drama with game companies and when Microsoft moved in and took over Her Interactive, the new Microsoft CEO immediately began firing much of the staff. The fellow that had written our great HIF editor was given a 1 hour notice to vacate and during that time he blew away all instances of the editor he'd worked for months on. So our game scene designers ended up using the primitive scripting system for all scene design from then on. I'm glad you like the old ND games. I had a blast making them. I remember the day one of our titles (Message in a Haunted Mansion) officially sold over a million copies. Made it feel worthwhile we were making people happy with the Nancy games.
lue

Micro-Goomba
Level: 8


Posts: 11/11
EXP: 2012
For next: 175

Since: 01-01-14


Since last post: 8.0 years
Last activity: 6.1 years
Posted on 05-06-14 07:46:33 PM Link | Quote
Heh, I've actually used those scene files as the basis for which of the audio and video is and isn't used by the game (by seeing if any scene, or Game.exe, refers to the filename of the audio/image/animation). As you might've been able to see, my focus so far has been to just be able to see all the files without running the game (esp. when it comes to files the game doesn't know about in the first place ). The best evidence for this is that I have an LZSS decompressor, but I've yet to write the accompanying compressor.

However, I'd like to at some point take a good look at those scene files, at least so far that I can generate an image of how all the files are connected, and discover scenes that don't get used at all. For instance, in the second game there's an obviously-unused "ART IN PROGRESS" image that I wouldn't have caught if I didn't do a manual check of all the video files at some point. It's because S1185.dat references the file, and I have no way of knowing which scene files are actually used. I suspect some less-obvious unused things slip by in similar fashion.

It's a shame that he threw away the editor. I wonder if in recent games someone else has created a new editor. The interface has changed a couple more times since game 13, so it's feasible they did. (The only interface changes I can recall off the top of my head are the ones starting at #10, #16, and #26, though I'm sure I'm missing at least one change.) I like to think that something as visible as the UI changing means a lot of the engine changed as well, so it'll be fun when I get around to those games (#6 is going to be another interesting one; it's the first one without The Adventure Company's logo on the back, and of course the Nancy Drew logo changed). Waitaminute...

Yep, as I remembered, game 14 (Danger by Design) features a new logo too (from serif to sans serif, the silhouette is in-between "Nancy" and "Drew"). It's also the one where they went to France. I think they took your leaving pretty hard, Wayne .

I haven't heard about Microsoft being involved with Her Interactive before, and a cursory googling didn't show anything. In any case, I can't imagine they're still involved, unless Microsoft is way more cool with OSX, iOS, and Nintendo consoles than I thought .

Those "decal" things — I noticed that in the first couple of games at least, the CIFLIST mentions that its contents are categorized as PLAIN, DATA, and DECAL. I've yet to see any DECALs though, as the first two games seem to prefer PLAIN-type images with green as the transparent color (the second game's CIFLIST mentions this designated transparent color, but the first game's talks about the transparent colors as being (0,0,0) and (1,1,1), which seems incorrect). Am I right in thinking the DECAL type, as well as that non-green transparent comment, are both remnants of Vampire Diaries, or even earlier?

I'll be sure to email you when I get back into that code of mine, which will hopefully be in a couple of days. I'm currently writing up what I've found in Stay Tuned for Danger (which is a lot, by the way; for example, 430 unused audio files!), and then who knows what I'll want to do with my free time !

In any case, thank you for stumbling upon this forum, and thank you for being so willing to help. I do very much appreciate it .

____________________
U+110000 END OF POST
Next newer thread | Next older thread
Jul - The Cutting Room Floor - Her Interactive .AVF Video Files New poll - New thread - New reply


Rusted Logic

Acmlmboard - commit 47be4dc [2021-08-23]
©2000-2022 Acmlm, Xkeeper, Kaito Sinclaire, et al.

31 database queries, 14 query cache hits.
Query execution time: 0.117428 seconds
Script execution time: 0.043530 seconds
Total render time: 0.160957 seconds