Showing posts with label ScummVM. Show all posts
Showing posts with label ScummVM. Show all posts
Friday, September 25, 2015
Sunday, August 17, 2014
Revisiting Cinepak
While working on an as-of-yet-unnamed engine last year, I realized I needed to dither some videos. My only hope was that it wouldn't be as painful as DrMcCoy had it several years ago (and I'm pretty sure the "beauty" part was sarcastic). Looking at how the game dithers the graphics, I figured out that it relied on Video for Windows to handle dithering. VFW promptly handles it by making the codec handle it.
For this game, that codec was Cinepak. The Cinepak decoder has been in ScummVM since 2009 (I wrote it in late 2007 or so, so it's really even older). I refused to use some other dithering algorithm that would have been different and given different results. If I was going to implement this, I was going to do it to match the original 100%. That meant it was time to figure out what it does.
Basically, the algorithm is based on pre-dithered tables that are for a given hardcoded palette. For custom palettes, it finds the nearest (using a simple distance equation) color in it and maps from the Cinepak palette index to the custom one. It then uses the pre-dithered tables to generate 4x4 blocks based on the contents of the codebook which is then mapped to the custom palette.
I pushed the code for the curious.
QuickTime also does something similar (but with a different dithering algorithm in Cinepak, of course), which I'll be working on for Myst.
Here's the result, using one of the Cinepak samples from the MPlayer samples archive (in this case, the Lara Croft one):
The result looks pretty decent. I was mostly glad it wasn't a ridiculous amount of extra code.
For this game, that codec was Cinepak. The Cinepak decoder has been in ScummVM since 2009 (I wrote it in late 2007 or so, so it's really even older). I refused to use some other dithering algorithm that would have been different and given different results. If I was going to implement this, I was going to do it to match the original 100%. That meant it was time to figure out what it does.
Basically, the algorithm is based on pre-dithered tables that are for a given hardcoded palette. For custom palettes, it finds the nearest (using a simple distance equation) color in it and maps from the Cinepak palette index to the custom one. It then uses the pre-dithered tables to generate 4x4 blocks based on the contents of the codebook which is then mapped to the custom palette.
I pushed the code for the curious.
QuickTime also does something similar (but with a different dithering algorithm in Cinepak, of course), which I'll be working on for Myst.
Here's the result, using one of the Cinepak samples from the MPlayer samples archive (in this case, the Lara Croft one):
 | |
| Normal decode to 24bpp |
 |
| Dither to 8bpp |
The result looks pretty decent. I was mostly glad it wasn't a ridiculous amount of extra code.
Saturday, August 16, 2014
Hidden in Plain Sight
With the DVD/GOG version of Pegasus Prime, there was a slight problem before release. We had an invalid function call entering the three new chase sequences when compiled in gcc with optimizations. I was unable to figure out the exact cause at the time and I ended up writing a hack around it in final release.
Since a bad function was getting called, I had feared gcc was overwriting a return address somewhere and sending the program counter where it shouldn't be. valgrind wasn't helping and only showed the after-effects of the bad function call. It was pretty hard to pinpoint in gdb too, due to the calling function being called numerous times during execution without breaking. I had shelved the issue for some time so I could return later, perhaps with another idea of tackling it. I found my hope in the AddressSanitizer.
Armed with my shiny new PC and gcc 4.8.1, I recompiled with the address sanitizer to see what I would get. The game would now crash as soon as the sequence would start, due to the sanitizer kicking in. The information the sanitizer gave helped in really one way: I had a way to make it stop as soon as it broke from the stack buffer overflow error. Perhaps not quite the way the tool was intended to be used, but it was enough of a hint for me.
With some logging to a file, I saw that it crashed here the first time _inputHandler changed. Going with LordHoto's suggestion to check the vtable of the pointer, I noticed something funny: It was the vtable for the wrong class!
Once I saw where the _inputHandler field was populated, I quickly saw what my mistake was. Instead of relying on the compiler to upcast from the subclass to the InputHandler class, I had a manual C-style cast in there. The Neighborhood pointer (only known through forward declaration) was being cast to the InputHandler pointer. Normally this would be OK, as long as the compiler knew about the class hierarchy (in this case, with multiple inheritance and virtual functions), and then generate a static_cast. But if it didn't know that, it would have to go with a reinterpret_cast. The code was doing a reinterpret_cast and throwing away the hierarchy, and therefore causing undefined behavior. It just so happened that it called into the wrong vtable in this case.
But why did it happen only during optimization? Probably because the function was getting inlined. If the include order had Neighborhood defined in the translation unit before getting to the constructor of GameInteraction, it would have output the correct static_cast. It's likely one other place had this situation and that version ended up being the actual used function.
Definitely one of the hardest bugs I've had to track down.
Since a bad function was getting called, I had feared gcc was overwriting a return address somewhere and sending the program counter where it shouldn't be. valgrind wasn't helping and only showed the after-effects of the bad function call. It was pretty hard to pinpoint in gdb too, due to the calling function being called numerous times during execution without breaking. I had shelved the issue for some time so I could return later, perhaps with another idea of tackling it. I found my hope in the AddressSanitizer.
Armed with my shiny new PC and gcc 4.8.1, I recompiled with the address sanitizer to see what I would get. The game would now crash as soon as the sequence would start, due to the sanitizer kicking in. The information the sanitizer gave helped in really one way: I had a way to make it stop as soon as it broke from the stack buffer overflow error. Perhaps not quite the way the tool was intended to be used, but it was enough of a hint for me.
With some logging to a file, I saw that it crashed here the first time _inputHandler changed. Going with LordHoto's suggestion to check the vtable of the pointer, I noticed something funny: It was the vtable for the wrong class!
Once I saw where the _inputHandler field was populated, I quickly saw what my mistake was. Instead of relying on the compiler to upcast from the subclass to the InputHandler class, I had a manual C-style cast in there. The Neighborhood pointer (only known through forward declaration) was being cast to the InputHandler pointer. Normally this would be OK, as long as the compiler knew about the class hierarchy (in this case, with multiple inheritance and virtual functions), and then generate a static_cast. But if it didn't know that, it would have to go with a reinterpret_cast. The code was doing a reinterpret_cast and throwing away the hierarchy, and therefore causing undefined behavior. It just so happened that it called into the wrong vtable in this case.
But why did it happen only during optimization? Probably because the function was getting inlined. If the include order had Neighborhood defined in the translation unit before getting to the constructor of GameInteraction, it would have output the correct static_cast. It's likely one other place had this situation and that version ended up being the actual used function.
Definitely one of the hardest bugs I've had to track down.
Tuesday, April 02, 2013
I'm not dead! I feel happy!
It's been so long since the last post that Blogger completely changed their editing interface (OK, not really a joke since Google seems to change their GUI with everything at regular intervals to confuse the public at large).
A few things for this update:
1) The Journeyman Project: Pegasus Prime is now supported in daily builds of ScummVM. Rejoice! And stay tuned for more news!
2) ScummVM April Fools Jokes™ will return next year with a vengeance (blame DrMcCoy, probably).
3) If you're able to recall when posts happened more regularly than yearly, you might remember this post, which I followed up saying I uploaded modified ScummVM code to a branch. Then last year I wrote a small player for the videos so I didn't have to hack directly in ScummVM anymore -- and then added support for Outlaws (proper 1/4 sized raw frames), Mysteries of the Sith, and (partially) Rebel Assault SegaCD.
Oh, and I apologize if your comment didn't show up over the past few months. I screwed up with the admin settings on the blog and it never forwarded me e-mails! Sorry!
A few things for this update:
1) The Journeyman Project: Pegasus Prime is now supported in daily builds of ScummVM. Rejoice! And stay tuned for more news!
2) ScummVM April Fools Jokes™ will return next year with a vengeance (blame DrMcCoy, probably).
3) If you're able to recall when posts happened more regularly than yearly, you might remember this post, which I followed up saying I uploaded modified ScummVM code to a branch. Then last year I wrote a small player for the videos so I didn't have to hack directly in ScummVM anymore -- and then added support for Outlaws (proper 1/4 sized raw frames), Mysteries of the Sith, and (partially) Rebel Assault SegaCD.
 |
| LordHoto's favorite level (Sega CD version) |
 |
| Mysteries of the Sith, Level 1 Opening |
Thursday, April 12, 2012
Getting Pegasus to Run in ScummVM
The Journeyman Project: Pegasus Prime is very much a Mac game. And by that, I mean it uses the gamut of Mac resources it has available to it. Thus, it can be very hard to extract the data on a non-Mac system. This post is an attempt to document some sane way for everyone to play the game in ScummVM. I'll also update this as people give me more info since some information is not provided by myself. Much thanks to eriktorbjorn for his file list and his Linux extraction script. This is all assuming you can compile the source code at the "pegasus" branch of my github fork already.
Extracting the Full Game Data
Since this is different on different platforms, I shall cover the big three here.
Windows
For Windows you need to use either the HFVExplorer or HFSExplorer tools.
If you're using HFVExplorer, you'll want to dump the files according to this document. If you see "M" on a line, make HFVExplorer extract as MacBinary and as a "raw copy, data fork" for ones beginning with "R". Note that you'll have to rename any file or directory with "/" in the name to have an underscore ("_") in its place.
For HFSExplorer, you can pretty much use the same instructions as HFVExplorer, except that you want to extract AppleDouble instead of MacBinary.
Mac OS X
Extracting the data on a Mac is actually the easiest because a) you can use HFS drives directly and b) you can then run the game directly without changing any file names.
First thing you'll need to do is to enable hidden folders. Then merge the PP Data folders from all four discs into one folder on your hard drive. Any files with the same name are identical. That's it, you're done. You can also use the "macbinary" command line tool to make MacBinary versions of the files.
Linux
You'll need to have hfsutils installed on Linux. Then you should run this script provided by eriktorbjorn with this file list (pasted into a file called "filelist.txt"). It should be pretty self-explanatory to run beyond that, I hope.
Extracting the Demo Data
Since StuffIt is a completely awful tool that won't let you extract any of the resource fork data on a non-Mac system, you will have to wait until I upload a version of the demo that can be played with ScummVM directly. Mac users can use it pretty much right away. I will update this space as soon as possible with more details. Sit tight!
Extracting the Full Game Data
Since this is different on different platforms, I shall cover the big three here.
Windows
For Windows you need to use either the HFVExplorer or HFSExplorer tools.
If you're using HFVExplorer, you'll want to dump the files according to this document. If you see "M" on a line, make HFVExplorer extract as MacBinary and as a "raw copy, data fork" for ones beginning with "R". Note that you'll have to rename any file or directory with "/" in the name to have an underscore ("_") in its place.
For HFSExplorer, you can pretty much use the same instructions as HFVExplorer, except that you want to extract AppleDouble instead of MacBinary.
Mac OS X
Extracting the data on a Mac is actually the easiest because a) you can use HFS drives directly and b) you can then run the game directly without changing any file names.
First thing you'll need to do is to enable hidden folders. Then merge the PP Data folders from all four discs into one folder on your hard drive. Any files with the same name are identical. That's it, you're done. You can also use the "macbinary" command line tool to make MacBinary versions of the files.
Linux
You'll need to have hfsutils installed on Linux. Then you should run this script provided by eriktorbjorn with this file list (pasted into a file called "filelist.txt"). It should be pretty self-explanatory to run beyond that, I hope.
Extracting the Demo Data
Since StuffIt is a completely awful tool that won't let you extract any of the resource fork data on a non-Mac system, you will have to wait until I upload a version of the demo that can be played with ScummVM directly. Mac users can use it pretty much right away. I will update this space as soon as possible with more details. Sit tight!
Monday, April 02, 2012
Filler Post
While I'm sure you're all waiting for a Pegasus Prime update, something completely useless will have to do in the meantime. Hopefully there will be a real update soon, stayed tuned! You can only get a sneak peek by seeing my tool for allowing games made in ScummVM to be played in the original interpreter again. In the meantime, you can hopefully appreciate the fact that you can now properly hear Gehn singing in Riven.
Some more exciting news: I was able to grab a copy of the ultra-rare Return to Zork Macintosh MPEG edition. Pretty much the same as the regular Mac version (and just as unsupported) but with a new MPEG-2 video layer of fun added on top. One day I'll finish RE'ing all those exotic versions of the game.
Speaking of which, I wrote PSX stream decoder for use in Broken Sword 1 and 2 (and Return to Zork) so now one can play those videos in all their half-resolution glory. I know, you're all very excited!
Switching gears.... For the one of you that may be interested, we did have a third idea for April Fools' this year that was replaced by the C# port joke. I came up with this idea after playing through Gabriel Knight: Sins of the Fathers last year and it manifested itself in a photoshop that I happened to like enough to not just outright toss out.
Originally, there would have been a whole set of "advertisements in ScummVM" -- advertisements placed right into the games! The plan was going to insert a few things in such as making the soda machine in The Secret of Monkey Island a real Coca-Cola machine and using the pre-made "advertisement" of Foster's in a Beneath a Steel Sky.
Only one prototype was made of GK1, and hopefully someone out there gets the joke.
Some more exciting news: I was able to grab a copy of the ultra-rare Return to Zork Macintosh MPEG edition. Pretty much the same as the regular Mac version (and just as unsupported) but with a new MPEG-2 video layer of fun added on top. One day I'll finish RE'ing all those exotic versions of the game.
Speaking of which, I wrote PSX stream decoder for use in Broken Sword 1 and 2 (and Return to Zork) so now one can play those videos in all their half-resolution glory. I know, you're all very excited!
Switching gears.... For the one of you that may be interested, we did have a third idea for April Fools' this year that was replaced by the C# port joke. I came up with this idea after playing through Gabriel Knight: Sins of the Fathers last year and it manifested itself in a photoshop that I happened to like enough to not just outright toss out.
Originally, there would have been a whole set of "advertisements in ScummVM" -- advertisements placed right into the games! The plan was going to insert a few things in such as making the soda machine in The Secret of Monkey Island a real Coca-Cola machine and using the pre-made "advertisement" of Foster's in a Beneath a Steel Sky.
Only one prototype was made of GK1, and hopefully someone out there gets the joke.
Friday, June 17, 2011
Mac SCI1.1+ Games Update
I really should update here more :P
In an effort to catch up with stuff I've missed, I'll start by going over stuff I coded a few months ago. Remember last year when I wrote up two posts about SCI Mac code? Well, I don't. So, here's two links from last summer.
Back in probably February, waltervn and myself tackled the resource compression of the non-King's Quest VI SCI1.1+ Mac games. King's Quest VI wasn't good enough to receive the compression of the other games. Then we found out that they changed the sprite compression routine again (runs now a word instead of a byte) for QFG1 VGA Mac. The Mac versions of Hoyle Classic Card Games and Freddy Pharkas became playable too, especially after waltervn put in a bunch of work on the hardcoded menu bar of KQ6 and Freddy Mac (though, still not complete).
One of the problems we found with these Mac games is that they have their black and white palette indexes reversed from normal SCI (black = 0x00, white = 0xff). Why? Because on classic Mac OS, white is always at 0x00 and black is always at 0xff. Our solution was to swap black and white pixels so that our palette code from the DOS versions would still work and would keep the complexity down.
Then, I took a look at the SCI2.1 Mac situation (GK1 Mac is SCI2.1 instead of SCI2 like the DOS version). The four SCI1.1 Mac games began to switch various resources to store multi-byte values in big endian order instead of the little endian order of their DOS counterparts. Starting with GK1, Sierra began to, as I like to put it, "big-endian-ify" the remaining resources. I also added support for the high-res GK1 Mac fonts that the DOS version doesn't have. It currently is probably on the same page of support as the DOS version (minus the sound driver and one skippable timing bug in the Day 1 intro). Gabriel Knight 2 Mac also has some small amount of support, but with some more weird transparency issues. The later SCI2.1 Mac games have some Sound class changes (the SCI class, that is) that causes games like Phantasmagoria to not start without a couple hacks.
Going back even further, there's three SCI0 Mac games that we don't support yet either: Space Quest III, Hoyle's Book of Games I and Hoyle's Book of Games II. These three are special in that they run in a higher resolution than the usual 320x200 and have high-res views.
And now for some screenshots:
Clicking on the KQ6 menu
Looked at that awesome greyed out effect!
GK1 high-res fonts = awesome
Yeah, it's Mostly working (I am the king of lame puns)
In an effort to catch up with stuff I've missed, I'll start by going over stuff I coded a few months ago. Remember last year when I wrote up two posts about SCI Mac code? Well, I don't. So, here's two links from last summer.
Back in probably February, waltervn and myself tackled the resource compression of the non-King's Quest VI SCI1.1+ Mac games. King's Quest VI wasn't good enough to receive the compression of the other games. Then we found out that they changed the sprite compression routine again (runs now a word instead of a byte) for QFG1 VGA Mac. The Mac versions of Hoyle Classic Card Games and Freddy Pharkas became playable too, especially after waltervn put in a bunch of work on the hardcoded menu bar of KQ6 and Freddy Mac (though, still not complete).
One of the problems we found with these Mac games is that they have their black and white palette indexes reversed from normal SCI (black = 0x00, white = 0xff). Why? Because on classic Mac OS, white is always at 0x00 and black is always at 0xff. Our solution was to swap black and white pixels so that our palette code from the DOS versions would still work and would keep the complexity down.
Then, I took a look at the SCI2.1 Mac situation (GK1 Mac is SCI2.1 instead of SCI2 like the DOS version). The four SCI1.1 Mac games began to switch various resources to store multi-byte values in big endian order instead of the little endian order of their DOS counterparts. Starting with GK1, Sierra began to, as I like to put it, "big-endian-ify" the remaining resources. I also added support for the high-res GK1 Mac fonts that the DOS version doesn't have. It currently is probably on the same page of support as the DOS version (minus the sound driver and one skippable timing bug in the Day 1 intro). Gabriel Knight 2 Mac also has some small amount of support, but with some more weird transparency issues. The later SCI2.1 Mac games have some Sound class changes (the SCI class, that is) that causes games like Phantasmagoria to not start without a couple hacks.
Going back even further, there's three SCI0 Mac games that we don't support yet either: Space Quest III, Hoyle's Book of Games I and Hoyle's Book of Games II. These three are special in that they run in a higher resolution than the usual 320x200 and have high-res views.
And now for some screenshots:
Clicking on the KQ6 menu
Looked at that awesome greyed out effect!
GK1 high-res fonts = awesome 
Yeah, it's Mostly working (I am the king of lame puns)Monday, February 21, 2011
Just Some Code Lying Around...
Well, as promised by yesterday's post, I would come back with some more code. Oh look! There's two new branches on my fork of ScummVM.
First off, is jmp, which was supposed to be an engine for the Windows versions of The Journeyman Project (Turbo!) and its sequel, Buried in Time. However, other than an AVI player (KQ6 put this code to good use), not much was of use until recently when I added support for loading resources from the EXE/DLL. Both games are entirely hardcoded. Still not much is done, but it's got some good code in there for the Cinepak-based bitmaps I mentioned on my blog before. The codebase here dates back to 2006, so be gentle with it.
Probably the more important of the branches, at least to me, is pegasus. Unlike their predecessors, The Journeyman Project: Pegasus Prime (Mac only) is not hardcoded (minus some 'minigames'). It seemed like a better candidate to me. Well, it's a bit more functional than the others but still not much is done. You can traverse the menus a bit and the intro plays (with that recently-added QuickTime seeking), but not much else can be done yet. And thanks to a fellow fan's research, some of the resource types are also loaded in (but not all). I intend to continue on this when I'm done with Mohawk (at least the "core" Mohawk games :P).
It feels good to get this all off my chest. Have I mentioned how much I love git?
First off, is jmp, which was supposed to be an engine for the Windows versions of The Journeyman Project (Turbo!) and its sequel, Buried in Time. However, other than an AVI player (KQ6 put this code to good use), not much was of use until recently when I added support for loading resources from the EXE/DLL. Both games are entirely hardcoded. Still not much is done, but it's got some good code in there for the Cinepak-based bitmaps I mentioned on my blog before. The codebase here dates back to 2006, so be gentle with it.
Probably the more important of the branches, at least to me, is pegasus. Unlike their predecessors, The Journeyman Project: Pegasus Prime (Mac only) is not hardcoded (minus some 'minigames'). It seemed like a better candidate to me. Well, it's a bit more functional than the others but still not much is done. You can traverse the menus a bit and the intro plays (with that recently-added QuickTime seeking), but not much else can be done yet. And thanks to a fellow fan's research, some of the resource types are also loaded in (but not all). I intend to continue on this when I'm done with Mohawk (at least the "core" Mohawk games :P).
It feels good to get this all off my chest. Have I mentioned how much I love git?
Tuesday, January 11, 2011
Feeling Rebellious
Out of boredom the other day, I decided to play around with ScummVM's SMUSH player and see if it could be "convinced" into playing some Rebel Assault videos (not Rebel Assault II, that's basically already there).
These version 1 videos are very similar to their version 2 brethren (Rebel Assault II, The Dig, Full Throttle, etc.), but have some differences. The delta palette code is different, providing fewer entries (smaller color sizes?). Audio and text seem to be handled differently as well. At least the audio flags are different. There's also a 'PVOC' chunk that probably deals with audio and a 'GAME' chunk that I can only speculate what it's for. Of course, I completely ignored the 'IACT' (interactive, for the INSANE code).
So, minus audio, text, and palette changes, I was able to render a couple frames. A couple at any rate. Without further ado:
The cutscene after the hardest level in the game. Seriously, who makes a level that hard and difficult to navigate? Damn Kolaador...
Now someone should go implement the game (not in ScummVM)!
These version 1 videos are very similar to their version 2 brethren (Rebel Assault II, The Dig, Full Throttle, etc.), but have some differences. The delta palette code is different, providing fewer entries (smaller color sizes?). Audio and text seem to be handled differently as well. At least the audio flags are different. There's also a 'PVOC' chunk that probably deals with audio and a 'GAME' chunk that I can only speculate what it's for. Of course, I completely ignored the 'IACT' (interactive, for the INSANE code).
So, minus audio, text, and palette changes, I was able to render a couple frames. A couple at any rate. Without further ado:
The cutscene after the hardest level in the game. Seriously, who makes a level that hard and difficult to navigate? Damn Kolaador...Now someone should go implement the game (not in ScummVM)!
Wednesday, December 15, 2010
Some Carmen Images
Well, we don't support Where in the World is Carmen Sandiego? yet beyond showing images. But we added support for the DOS images of Where in the World is Carmen Sandiego? Deluxe Edition yesterday, so I figured I'd show it off. Also, I don't update my blog enough, so here's a post.
Where Wile E. Coyote Shops
Police Squad! ...In 256 Colors
These are the same (well, similar) images from the intro of the two games. The former is in EGA from Deluxe and the latter in VGA from v2. They went full screen for Deluxe game and decided to size it down for Windows (The first image is actually three 640x160 images put together).
Surprisingly (or I guess I shouldn't be surprised considering how much Brøderbund likes to reuse things), the CSWorld Deluxe archive format is the same one used in Prince of Persia 2!
I cracked the archive format before I realized PoP2 used it, so I only found this info out afterward. Same with the simple SND resource format. I checked out the specs for the bitmap decompressor and applied a modified version to the ScummVM source (thanks to fuzzie for helping figure out the data was EGA planar). And lo and behold, it uses the exact same modified LZ decompression that was used in all other Mohawk games (minus Riven). It looks like the planar part isn't in PoP, but I'm not sure.
One last note: We will not support Prince of Persia 1/2 in ScummVM no matter how much you ask. ;)
Where Wile E. Coyote Shops
Police Squad! ...In 256 ColorsThese are the same (well, similar) images from the intro of the two games. The former is in EGA from Deluxe and the latter in VGA from v2. They went full screen for Deluxe game and decided to size it down for Windows (The first image is actually three 640x160 images put together).
Surprisingly (or I guess I shouldn't be surprised considering how much Brøderbund likes to reuse things), the CSWorld Deluxe archive format is the same one used in Prince of Persia 2!
I cracked the archive format before I realized PoP2 used it, so I only found this info out afterward. Same with the simple SND resource format. I checked out the specs for the bitmap decompressor and applied a modified version to the ScummVM source (thanks to fuzzie for helping figure out the data was EGA planar). And lo and behold, it uses the exact same modified LZ decompression that was used in all other Mohawk games (minus Riven). It looks like the planar part isn't in PoP, but I'm not sure.
One last note: We will not support Prince of Persia 1/2 in ScummVM no matter how much you ask. ;)
Monday, November 29, 2010
Surprise Update #2
Poof again!
bgK has finished coding the Selenitic age for Myst! Feast upon the glory that is the best looking (IMO) and also the hardest (by far). I cannot be paid to solve the maze runner puzzle with all the bleeps, sweeps, and creeps (Yes, I just went there) so I don't blame you if you cheat on the maze runner. If anyone wants to try, they'll need to use the debug console and run "changeStack Selenitic 1282".
Screenshot time!
Does the door really need to close behind you?
Actually, this has always worked. I just like fire.
In Your Tunnel
Does anyone actually do this puzzle?
bgK has finished coding the Selenitic age for Myst! Feast upon the glory that is the best looking (IMO) and also the hardest (by far). I cannot be paid to solve the maze runner puzzle with all the bleeps, sweeps, and creeps (Yes, I just went there) so I don't blame you if you cheat on the maze runner. If anyone wants to try, they'll need to use the debug console and run "changeStack Selenitic 1282".
Screenshot time!
Does the door really need to close behind you?
Actually, this has always worked. I just like fire.
BRING ME THE PAGES
In Your Tunnel
Does anyone actually do this puzzle?
What hell truly looks like
Sunday, November 28, 2010
Surprise Update #1
Poof!
fuzzie has done some great work on Living Books code for Mohawk in ScummVM and the games are very very very playable. Go try them out (along with our collection of near-infinite demos)! v1 games (the older, 512x384 ones) work near perfectly while the v3 games (640x480) have some new features that aren't fully supported yet. And now time for obligatory screenshots along with random semi-humorous subtitles provided by me.
A Way-Too-Happy Book
Fast Decaying Ham
Riding a Dog
Creeping Logo
Arturo, por favor
Eternal Third-Grade Punishment
fuzzie has done some great work on Living Books code for Mohawk in ScummVM and the games are very very very playable. Go try them out (along with our collection of near-infinite demos)! v1 games (the older, 512x384 ones) work near perfectly while the v3 games (640x480) have some new features that aren't fully supported yet. And now time for obligatory screenshots along with random semi-humorous subtitles provided by me.
A Way-Too-Happy Book
Fast Decaying Ham
Riding a Dog
Creeping Logo
Arturo, por favor
Eternal Third-Grade PunishmentSunday, August 01, 2010
"You've already got me, you lucky devil"
This blog post is a special one. Most of you know that SCI testing is going on already for all those boat loads of SCI games you have. That's for SCI0-SCI1.1, of course. I'm here to announce something different, though. No, not another LordHoto joke. No joke at all, actually!
I'm here to announce that GABRIEL KNIGHT: SINS OF THE FATHERS is completable in ScummVM. Not without bugs of course. And note that it will still NOT be tested in our current SCI testing nor be supported with the rest when they make it into a full release eventually.
EDIT: DrMcCoy has a quick trigger finger and found out that the hi-res (Windows) version is not completable. The DOS CD version is (and almost definitely the floppy version). This should be fixed now.
There are two major bugs with it still, but both are fixable if you use the fan made patches. In other words, both of these bugs were in the original game so they're not "our fault". You can download said patches from here. You'll want the NRS patches for either floppy or CD. There will be some other problems too. The save/restore menu is not working 100%, the text wrapping isn't correct, and transparency does not work yet. You'll see what I mean about the transparency if you get to use the flashlight or arrive at Schloss Ritter.
We do NOT want bugs submitted about Gabriel Knight, we know there's plenty of them still.
Also, please don't play Gabriel Knight if you still have other SCI0-SCI1.1 games to test. We really need you loyal ScummVM users concentrating on those. We love you guys! :D And thanks for all those SCI games you've already played through... and a seemingly neverending amount of bugs :P
Last August, SCI32 games weren't even startable and look how far we've come in just under a year!
Ah, and the obligatory screenshot. This was taken two days ago when I beat it for the first time. Yes, I missed 7 points. No idea where though...
PS - My apologies to pgr on #scummvm (IRC). We had decided not to reveal this, but changed our minds after discovering that the Day 5 lockup was indeed in the original too. It's also skippable using the spacebar. I'll be comparing both the good and bad scripts to add a workaround to the code for it soon. Hopefully I'll be able to figure out something clean ;) I hope you can forgive me! :)
I'm here to announce that GABRIEL KNIGHT: SINS OF THE FATHERS is completable in ScummVM. Not without bugs of course. And note that it will still NOT be tested in our current SCI testing nor be supported with the rest when they make it into a full release eventually.
There are two major bugs with it still, but both are fixable if you use the fan made patches. In other words, both of these bugs were in the original game so they're not "our fault". You can download said patches from here. You'll want the NRS patches for either floppy or CD. There will be some other problems too. The save/restore menu is not working 100%, the text wrapping isn't correct, and transparency does not work yet. You'll see what I mean about the transparency if you get to use the flashlight or arrive at Schloss Ritter.
We do NOT want bugs submitted about Gabriel Knight, we know there's plenty of them still.
Also, please don't play Gabriel Knight if you still have other SCI0-SCI1.1 games to test. We really need you loyal ScummVM users concentrating on those. We love you guys! :D And thanks for all those SCI games you've already played through... and a seemingly neverending amount of bugs :P
Last August, SCI32 games weren't even startable and look how far we've come in just under a year!
Ah, and the obligatory screenshot. This was taken two days ago when I beat it for the first time. Yes, I missed 7 points. No idea where though...
PS - My apologies to pgr on #scummvm (IRC). We had decided not to reveal this, but changed our minds after discovering that the Day 5 lockup was indeed in the original too. It's also skippable using the spacebar. I'll be comparing both the good and bad scripts to add a workaround to the code for it soon. Hopefully I'll be able to figure out something clean ;) I hope you can forgive me! :)
Thursday, June 17, 2010
Are You Ready for the Summer?
Summer is just around the corner, though I've been off from Uni for over a month now (since my last post). So, what's been happening?
Continuing off my last post: SCI Mac. I began working on the KQ6 Mac icon bar interface. The picture below has a slightly off-centered position and slightly off-colored palette. The PICT code got moved from Mohawk to common code and was updated to allow for paletted images. The Mohawk QuickTime code was also moved to common code and updated to show the Cinepak-based movies. However, they don't show completely correctly due to "Cyan logo syndrome." Seeking support in QuickTime has a higher priority on my TODO list, so that comes first ;) I haven't made progress on other SCI1.1+ Mac games.
Mohawk. I fixed several bugs, such as the videos not showing when clicking on a stone in the rebel tunnel puzzle or when opening the cage in Gehn's office (not yet accessible from the beginning anyway). The boiler puzzle also got some fixes. There were a couple other minor fixes as well. Eugene changed some detector code to allow for detection through nested directories so Riven is playable directly off the DVD now (CD swapping will happen in the future :)).
SCI. Gabriel Knight is completable (albeit with extreme graphical glitches) up to trying to get inside Madame Cazanoux's house in Day 3 (door knocker not 'operatable'), thanks to various fixes from myself, md5, m_kiewitz, and Walter. Mostly (pun intended), that's all I've been working on in SCI. I've also promised myself to play one GK1 day each day (in DOSBox) starting tomorrow (June 18), meaning 17 years after the original game took place. Day 2 is clearly the best of the days.
That concludes this update. I'm looking forward to cheesecake on Saturday and Futurama next Thursday.
PS - Yay! (When sf.net stops throwing python exceptions)
PPS - Carmen Sandiego!
PPPS - In case you didn't get the title reference...
Continuing off my last post: SCI Mac. I began working on the KQ6 Mac icon bar interface. The picture below has a slightly off-centered position and slightly off-colored palette. The PICT code got moved from Mohawk to common code and was updated to allow for paletted images. The Mohawk QuickTime code was also moved to common code and updated to show the Cinepak-based movies. However, they don't show completely correctly due to "Cyan logo syndrome." Seeking support in QuickTime has a higher priority on my TODO list, so that comes first ;) I haven't made progress on other SCI1.1+ Mac games.
Mohawk. I fixed several bugs, such as the videos not showing when clicking on a stone in the rebel tunnel puzzle or when opening the cage in Gehn's office (not yet accessible from the beginning anyway). The boiler puzzle also got some fixes. There were a couple other minor fixes as well. Eugene changed some detector code to allow for detection through nested directories so Riven is playable directly off the DVD now (CD swapping will happen in the future :)).SCI. Gabriel Knight is completable (albeit with extreme graphical glitches) up to trying to get inside Madame Cazanoux's house in Day 3 (door knocker not 'operatable'), thanks to various fixes from myself, md5, m_kiewitz, and Walter. Mostly (pun intended), that's all I've been working on in SCI. I've also promised myself to play one GK1 day each day (in DOSBox) starting tomorrow (June 18), meaning 17 years after the original game took place. Day 2 is clearly the best of the days.
That concludes this update. I'm looking forward to cheesecake on Saturday and Futurama next Thursday.
PS - Yay! (When sf.net stops throwing python exceptions)
PPS - Carmen Sandiego!
PPPS - In case you didn't get the title reference...
Wednesday, May 12, 2010
SCI Mac Craziness
Mac versions of SCI games started out fairly nice. SCI0/SCI1 games used the normal map/volume that their PC and Amiga counterparts used. That held true until the SCI1.1 releases.
Now, the game data is stored inside of Mac resource forks (which I have covered here before). My resource fork patch was accepted earlier this week, so I went into greater work for these games. It was pretty straightforward to get SCI's ResourceManager to support these. Mainly, it involved mapping the resource fork types to the SCI types. Nothing is ever that easy, however.
Right from the get go, it was pretty obvious that various resources were no longer all in little endian order, as had been the case with all other SCI games (even Amiga and pre-SCI1.1 Mac games). I wrote a wrapper function around the pointer reads so that it would choose the right one for the right platform/version. After some work, I got scripts to work and I saw the KQ6 title screen. Then came view support. Thanks to m_kiewitz, we figured out that some view fields were really uint32's instead of uint16's and then we had "preliminary" support for those. See the screenshot below. Also, messages were also in big endian order.
After stubbing off cursors (a view could not be found), the game was playable. There's a cursor in the screenshot, but that's because it shows the last cursor shown, which was the GUI cursor (now with the current cursor palette). However, the views didn't appear right... they could almost be made out. Fortunately, the sound format (MIDI/sequenced) is still the same and the GM mapping works well enough (the Mac/Amiga format is not supported yet). The audio (sampled) has been replaced by Mac 'snd' resources. They were easy to code, based off the Apple specs. On the bright side, font and picture resources are also the same as the normal DOS ones.
I also have Quest for Glory I Mac that I've been looking at, and it seems they may have compressed the scripts/heaps...
Anyway, here's a screenshot of my current code, obviously WIP:
EDIT: m_kiewitz cracked the Mac SCI1.1+ View compression, so we have that working now too. I also fixed cursors. It turns out that the cursors are stored in Mac CURS resources and the view that is called is a "dummy" view telling the engine to use the CURS resources instead.
Now, the game data is stored inside of Mac resource forks (which I have covered here before). My resource fork patch was accepted earlier this week, so I went into greater work for these games. It was pretty straightforward to get SCI's ResourceManager to support these. Mainly, it involved mapping the resource fork types to the SCI types. Nothing is ever that easy, however.
Right from the get go, it was pretty obvious that various resources were no longer all in little endian order, as had been the case with all other SCI games (even Amiga and pre-SCI1.1 Mac games). I wrote a wrapper function around the pointer reads so that it would choose the right one for the right platform/version. After some work, I got scripts to work and I saw the KQ6 title screen. Then came view support. Thanks to m_kiewitz, we figured out that some view fields were really uint32's instead of uint16's and then we had "preliminary" support for those. See the screenshot below. Also, messages were also in big endian order.
I also have Quest for Glory I Mac that I've been looking at, and it seems they may have compressed the scripts/heaps...
Anyway, here's a screenshot of my current code, obviously WIP:
EDIT: m_kiewitz cracked the Mac SCI1.1+ View compression, so we have that working now too. I also fixed cursors. It turns out that the cursors are stored in Mac CURS resources and the view that is called is a "dummy" view telling the engine to use the CURS resources instead.
Thursday, April 01, 2010
Urban Runner Support: Postmortem
I'm sure you all saw ScummVM's April Fools' Day joke. It's been long enough since the last one (2007!) and last year's never really got anywhere.
This year, LordHoto and I were talking about it back in early February. He had an idea for one involving Urban Runner and DrMcCoy. Strangerke was quickly brought into the "group." LordHoto's grand plan was to plant images of Dr. McCoy into Urban Runner screenshots, which we all liked. He even wanted to make it of the reboot version of Dr. McCoy.
Then, while looking for some test images... I came to a realization. The actor portraying the new Dr. McCoy's name is Karl Urban! Brilliant!
That night, I quickly made the first two screenshots in Photoshop (to the approval of the other two). And then nothing happened again on it until March 30... I created the last two images (based on screenshots Strangerke made) that night.
Beyond our little April Fools' joke, I hope you all saw xkcd's console interface, YouTube's text mode, and the Monolith Action Figure.
And, for an April Fools' throwback, here are ScummVM's past ones:
This year, LordHoto and I were talking about it back in early February. He had an idea for one involving Urban Runner and DrMcCoy. Strangerke was quickly brought into the "group." LordHoto's grand plan was to plant images of Dr. McCoy into Urban Runner screenshots, which we all liked. He even wanted to make it of the reboot version of Dr. McCoy.
Then, while looking for some test images... I came to a realization. The actor portraying the new Dr. McCoy's name is Karl Urban! Brilliant!
That night, I quickly made the first two screenshots in Photoshop (to the approval of the other two). And then nothing happened again on it until March 30... I created the last two images (based on screenshots Strangerke made) that night.
Beyond our little April Fools' joke, I hope you all saw xkcd's console interface, YouTube's text mode, and the Monolith Action Figure.
And, for an April Fools' throwback, here are ScummVM's past ones:
Saturday, March 27, 2010
March Madness
I've been quite busy the last month, though sadly not much related to coding or reverse engineering.
In the ScummVM world, my main focus was working on rewriting the VideoDecoder system. In the current trunk, the VideoDecoder is limited in what it can be used for. It was designed for fixed-rate, 8bpp videos that do not run in the "background" (instead of say in Broken Sword where the cutscene is the only thing going on in the game and the event loop only handles the video) of the games. Because of the way this works, the QuickTime player in Mohawk does not use this (variable rate, >8bpp, and background videos needed) and I designed a different system to run the Myst and Riven videos.
DrMcCoy also had a similar problem with his Dark Seed II engine where >8bpp videos are used (in AVI files). So, I began working on a redesigned VideoDecoder system which took about a week's worth of my spare time up (with much help from DrMcCoy, especially on bug fixing and input on the new API) and we came up with this patch. Since writing the patch I haven't had time to fix some of the things in it or split it up (it's a whopping 130KB), but hopefully I'll get around to that soon. Also, the QuickTime code in Mohawk will eventually also be adapted to that and moved to common so it can be used in the SAGA and SCI engines.
Outside of the ScummVM world, I've done a bit more experimenting with my DOSBox + Windows 3.1 setup mentioned way back when. Now I'm running it at 640x480x24bpp using the S3 Trio drivers, and now Buried in Time doesn't crash on me at all and works in 24bpp. Buried in Time would be a great game to reimplement one of these, however it is entirely hardcoded and would be difficult to implement. The cursors and main menu graphics are stored in the executable too.
As for media, the audio is standard WAVE files (disguised with a .bta extension), the bitmaps are DIB's (disguised with a .btb extension, usually) and the videos are AVI's with Cinepak encoded frames (disguised with a .btv extension, usually). All of the data is normal, except for one image: TITLE/BKG.BTB. I wasn't able to open it in any image viewer, so I opened it in a hex editor only to see a very weird bitmap compression field: 'cvid' ('divc' when decoding because the field is really LE). Cinepak! I hacked together the Mohawk bitmap decoder and the Mohawk Cinepak decoder to display the image, and it came out fine. Apparently, the BKG.BTB file is displayed in the background so the main title video takes up much less room. Interesting, but again, a project that will probably never be realized because of its hardcodedness.
That's it for now... hopefully more posts soon. :)
In the ScummVM world, my main focus was working on rewriting the VideoDecoder system. In the current trunk, the VideoDecoder is limited in what it can be used for. It was designed for fixed-rate, 8bpp videos that do not run in the "background" (instead of say in Broken Sword where the cutscene is the only thing going on in the game and the event loop only handles the video) of the games. Because of the way this works, the QuickTime player in Mohawk does not use this (variable rate, >8bpp, and background videos needed) and I designed a different system to run the Myst and Riven videos.
DrMcCoy also had a similar problem with his Dark Seed II engine where >8bpp videos are used (in AVI files). So, I began working on a redesigned VideoDecoder system which took about a week's worth of my spare time up (with much help from DrMcCoy, especially on bug fixing and input on the new API) and we came up with this patch. Since writing the patch I haven't had time to fix some of the things in it or split it up (it's a whopping 130KB), but hopefully I'll get around to that soon. Also, the QuickTime code in Mohawk will eventually also be adapted to that and moved to common so it can be used in the SAGA and SCI engines.
Outside of the ScummVM world, I've done a bit more experimenting with my DOSBox + Windows 3.1 setup mentioned way back when. Now I'm running it at 640x480x24bpp using the S3 Trio drivers, and now Buried in Time doesn't crash on me at all and works in 24bpp. Buried in Time would be a great game to reimplement one of these, however it is entirely hardcoded and would be difficult to implement. The cursors and main menu graphics are stored in the executable too.
As for media, the audio is standard WAVE files (disguised with a .bta extension), the bitmaps are DIB's (disguised with a .btb extension, usually) and the videos are AVI's with Cinepak encoded frames (disguised with a .btv extension, usually). All of the data is normal, except for one image: TITLE/BKG.BTB. I wasn't able to open it in any image viewer, so I opened it in a hex editor only to see a very weird bitmap compression field: 'cvid' ('divc' when decoding because the field is really LE). Cinepak! I hacked together the Mohawk bitmap decoder and the Mohawk Cinepak decoder to display the image, and it came out fine. Apparently, the BKG.BTB file is displayed in the background so the main title video takes up much less room. Interesting, but again, a project that will probably never be realized because of its hardcodedness.
That's it for now... hopefully more posts soon. :)
Tuesday, December 29, 2009
The End
Today, December 29, 2009 at 23:23:31 (UTC), Mohawk entered the main ScummVM tree. You can now go grab a daily build and try out Myst or Riven. And now Strangerke can make his own gameplay videos and not coerce me into making them. :P
So, this is the end. Mohawk is now in the trunk and everyone can attempt to play Myst and Riven in ScummVM. :)
Or, perhaps the ending has not yet been written...
So, this is the end. Mohawk is now in the trunk and everyone can attempt to play Myst and Riven in ScummVM. :)
Or, perhaps the ending has not yet been written...
Friday, November 06, 2009
The ScummVM Logo: A Lookback
If you didn't notice, ScummVM has an updated logo. So, in honor of that (even though it's a week late), I've taken the liberty of compiling all the ScummVM logos throughout history. Much thanks to archive.org. I just thought it was interesting how far it has evolved. Of course, I came much later and missed out on the old logos... (And, does anyone remember that first one?)
Ancient (2001):
Early 2002: (Website Redesign)
Late 2002:
Late 2005: (Website Redesign)
Late 2009: (Capitalization)
Ancient (2001):
Early 2002: (Website Redesign)
Late 2002:
Late 2005: (Website Redesign)
Late 2009: (Capitalization)
Subscribe to:
Comments (Atom)