Jump to content

Home

Serge

Members
  • Posts

    196
  • Joined

  • Last visited

Everything posted by Serge

  1. Late in... I haven't looked that much at it (although I bought it on release date), but telarium did notify me that it worked. And yeah, from what I've heard, I mostly heard reuse too. Although to be fair, they did up the sample rate, I think? (to give as good a quality as the original GrimE supported - but still lossy VIMA compression).
  2. I.e., "DXT5" [width] [height] [gzipped (and DXT5 compressed) data]
  3. ... and the image data in the .dxt files is gzipped.
  4. Just in case you haven't already done it, bg (I can't tell from the thread), the filename table offsets in .PAK should simply be ignored completely - the entries of the filename table are actually stored in the same order as the entires of the file offsets/size table, so for the first file, start from the beginning of the name table and just read the name up until the null terminator. For the next file, read from there until the next, etc. Still no idea where the hell those name table offsets come from, but since monkey1.pak had the file table in the same order as the actual file content (while monkey2.pak doesn't), there's probably a bug there, and they never actually use the filename table offsets in either game.
  5. Indeed. Add to that that iMUSE also allowed programmatic transposition of the individual instrument tracks, which was also used some places in MI2 and FOA. Then we're starting to add quite a few CPU cycles to the sound engine. This is, almost for sure, one of the places they'll compromise. And knowing how high the music department is on the budget list on most games these days (which is to say, not very high at all), I have a feeling it will be a lot more compromised than that. I.e., most of what MrC says, is not gonna happen in the Special Edition.
  6. HighLand is infected too - and it certainly doesn't run on Wordpress - not sure Wordpress even existed when that site was made. Predates lowercase HTML too ;-) And I don't remember the FTP account (as usual), so...
  7. It was a very conscious attempt to get the steel drum sound from COMI - the organ probably has a DOTT vibe - although I think especially the bit for the organ "solo" that telarium insisted should be reperformed, since it's in the original ;-) OK, now I like it too... - the organ playing chords through the rest was - at least intended to be - a more ska sound. Glad people like it. I personally was never quite happy with it, but at least more so than Opening 1 which has yet to be released.
  8. There's not enough interest/time from my side to actually do much. I meant generally
  9. I doubt it Merely saying that if a layout works, it's mostly a good idea to stick with it, rather than adding "too many cooks". I'm not a big believer in collaborative art/design/layout without one person to guide and veto the process. If you provide a template with some grid guidelines for illustrations etc., I'm sure there'll be plenty of people willing to work on filling it out LucasArts have changed (most current and former employees were quite reluctant to say anything at all about their employment at the time of CMI, GF and later on, for various reasons that probably won't be in the Secret History either ) -- so I'd say it's worth a shot. Their PR department ought to be well aware of how things work in the Web 2.0 culture -- and they've shown some efforts towards somewhat embracing that. Somewhere on some stashed away CD-R archives, I have some stuff that might be of use (when judiciously edited) -- if I can find it (and it'll take months before I can get to those CDs) -- and get permission from those involved. Still funny -- wouldn't have imagined such an interest in doing a fan-book just a year ago
  10. Nah, not at all, from what I can tell from web samples of the book (I haven't read it). I'm actually talking about a single body text column, with a left column for nothing but images and very short notes -- pretty much the kind of notes you'd write in the margin when studying -- even though that column's space is actually wider than the body text column. But it's not anything I'm proposing for this, just an example of my whitespace preference, so let's leave it at that Which is why I said "whatever you say" (which wasn't meant in a sarcastic way) -- you have a vision for the layout, and it works well, so you really should have the say, rather than adding random preferences from here and there. The only one I could really make an argument for is slightly more space between columns, but that might actually eat up more margin space, since the column width is around the ideal and shouldn't be narrower
  11. Don't take it the wrong way. I'm just a sucker for whitespace, and lots of it :-) My favorite non-fiction book layouts are the ones that have HUGE whitespace on the left and use it for occassional "side notes" or short "paragraph headlines" ;-)
  12. And don't use Verdana, Tahoma or Georgia for printed text either, please Whitespace is never wasted space, but whatever you say
  13. Looks good to me, for someone who claims not to know layout (and even someone who doesn't). What typeface is that? Myriad? Good choice too, in any event. Maybe add slightly more margin and column whitespace.
  14. And then the files are ordered by that CRC - figured search index or hash table - but it stumped me for some reason, because the table was numerically sorted :-P Thanks, Ben :-) I'd just given up on it, since it wasn't needed to unpack.
  15. ... and now I'll leave the SCUMM hacking community alone for a few weeks. Looking forward to hearing music and seeing CMI Guybrush in SOMI when I get back Have fun
  16. Ah, what the heck... BG wanted to do one, jott already did one, and I already did one. So might as well release it - this one with source, and pretty much public domain (since it was done in 20 minutes - except for the FileReader/FileWriter which are work in progress for SR6 - note, they aren't meant to be efficient, they're just meant to work ). It will only work with DirectX 9 format dds files (same format as jott's tool and Remonkeyed - and most others - save). Simply add dds files by clicking Add files... Then click Convert. It will place the dxt files in the same folder as the dds files. Warning: It will also overwrite already existing dxt files without prompting. http://highland.mixnmojo.com/other/DDStoDXT.zip For execution, you simply need the .exe (and the usual pesky .NET framework) ETA: Should check again before I post. Didn't see jott's post, which would have saved me some trouble. Oh well, the more alternatives the better, I guess
  17. Well, jott has already written on it. If you: - choose "DDS" for DXT output in the dropdown - pick the game folder with the MONKEY1.PAK file in it as Destination Folder - and save the file with "Include original subfolder" checked ... it will store the file in the same subfolder that the game expects to find it in - but in dds format, which a lot of graphics apps and image converters can open (there's a plugin for e.g. PhotoShop, I believe). Then, after you've edited the DDS, it needs to be converted back to DXT format - jott posted a tool for that above - and should stay in the same folder, with the same name (but with .dxt extension). Then the game should prefer that file to the one stored in the .pak.
  18. Yeah, you probably have .NET 2.0 or higher installed already (if you're on Vista, you have 3.0), which will allow the program to run, but as soon as it needs 3.5 libraries, it'll crash. Annoyingly, there's no really fool proof way of checking it at start up (which I actually assumed it already did). Might just wrap an installer around it sometime. No time at the moment, though (which will bite me in the ass when everyone starts asking why it crashes ;-)) Edited "release post" to add link to the .NET Framework 3.5 SP 1 Client Profile...
  19. Music and other audio is being worked on (by BG, me, and others)
  20. Looks like you don't have .NET Framework 3.5 (SP1) installed? Actually thought .NET would be more graceful about it - it used to be
  21. Misunderstood you then, but in that case, nothing codewise keeps it from running the original game with the sound effects, and turning the art projection off.
  22. This is a dangerous statement, but I'll make it anyway... Might be worth noting, that certain people would argue, that if the original had been more faithful to the spirit and tone Ron Gilbert originally set, instead of injecting it with more humour, it's less likely that it would have been the classic it is today. <end of cryptic remark that can't really be made less cryptic> While I do agree that some details are off (including the narrator), the tone isn't really my main issue
  23. So, releasing Remonkeyed Explorer (as described at the start of the topic) now... It only allows to dump files from monkey1.pak as-is, as well as convert .dxt to .dds. In other words, it does nothing that jott's tool doesn't do already. Except for having a pseudo-fancy GUI Specs for the monkey1.pak file as they're currently known are included. There's no installer - just run the file. Application requires .NET Framework 3.5 SP1, though - Client Profile will do, and if MS get their way, you'll need it anyway for other stuff, if you don't have it already The installer for the "small" version (280KB web installer which will then download the framework which is approximately 28MB - if it isn't installed already) - AKA "Client Profile" can be found here: http://go.microsoft.com/fwlink/?LinkId=123879 Not expecting to support this app much. It was done quickly, in order to get something out, and lots of code was simply copied from "that other project". Which means I can't be bothered maintaining that code in two places http://highland.mixnmojo.com/other/Remonkeyed_1.0.0.54.zip Also, hi Benjamin and Tomas
  24. @jott: Had a look at your source - we're very much in agreement Not sure about the constant 0 DWORD in the dir entries, but (potential) compression type might be right, since that's what I remember it used for in (I think) VIMA compression for either CMI or GF. I'm looking into the 0x28 table right now... I guess you did so already, but you might want to swap width and height when reading from the .dxt file, since height is stored first (FourCC - Height - Width). Blabbering here - just got confused (for the 29th time in the past 3-4 years) by DDS_HEADER storing height first
  25. I do - as mentioned above, I planned on Friday - not sure at the moment, since I have a lot of work-work and leaving on vacation tomorrow. But maybe. In any event, Jott already has something out. Source code: Not at the moment, simply because it shares a lot of code with a longer term "secret" project , which will probably be open source. Shares as in "copy/paste and quick hacks" which means it's not even close to clean and won't be maintained - since the original project already decodes PAK also. Only did this tool to get something out quick. As for 0x28 - no idea yet. Did all this rather quickly last night, so when it worked, I actually stopped looking at the package format and focused on the DXT stuff. Fast enough to not find any file count in the format either, which means at the moment, it simply reads the offset table until it reaches the known position of the name table. And yes, Remonkeyed Explorer also decodes all files to the same folders if wanted (that's what the "Use original subfolder" checkbox is there for). Great news that unpackaged resource use wasn't disabled for the release
×
×
  • Create New...