Well, hello there. Been a few months since I posted here. Figured I'd post about something, y'know.
Had a busy summer... busy fall too. Played a few games recently, including one classic game -- The Journeyman Project: Pegasus Prime. Let's reminisce a bit (WARNING: Contains spoilers; just skip to the very bottom for the good stuff).
The essential title screen; usually in most games. Let's move onto gameplay.
We should probably wake up, and not be late for work.
Too late! The commissioner doesn't look too happy. Also, bad temporal rip incoming and whatnot.
Time to go recover that log and not jump off the cliff though!
Avoid dinosaurs too, always good. Let's go to Mars instead.
Watch out! (Aside: For fun, you can try to attack this guy with any inventory item -- I bet you didn't know that!)
Freeze the lock, let's take a look at that bomb. Don't just pry it out though! Now, let's get out of here.
The maze isn't the same without the original music, but it's still enjoyable. Let's go catch that robot!
Bang bang! Pew pew! Now, tractor her in and board her!
Need to stop a robot down under too.
Being under the sea more to your liking? This guy doesn't seem to think you're much of a match for him, though. Probably should stay out of his way or maybe crush him or something.
I hope you don't need a map to solve this one.
Watch out! Robot on the loose!
Who needs lockpicks? Let's just blow the door open.
Why are there no tasers in the future?
How come James Bond never had to go through this level of difficulty when diffusing a bomb?
Mission Accomplished!
Well, that was a fun little aside don't you think! Talking about a classic adventure game randomly, just like that. Or was it really random? Maybe there's something common about those screenshots; no, not just in PNG format. They're all taken from within ScummVM. Yeah, you heard correctly. This is definitely happening, and I'll hopefully be done fairly soon. Ah, now you see what I'm getting at? There's still some graphical glitches with the videos, but it's in very good shape overall.
Oh and it's even completable.
More updates to come soon (And no, this code isn't on my github account yet, but will be soon).
And, of course, much thanks to Presto Studios for making all this possible and providing the original source code!
Thursday, December 15, 2011
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:
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:
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?
Labels:
Buried in Time,
Pegasus Prime,
ScummVM,
The Journeyman Project
Sunday, February 20, 2011
Git 'er done
Now that ScummVM has moved to git, I figured I would do a couple things with a fork of the project. I love git so far!
First off, I brought my Rebel Assault changes mentioned recently to a fork called ra-smush. I also got audio (mostly) working in it (there's a slightly different SAUD frame header). No, don't even think about asking support for it in ScummVM!
Secondly, my old Star Trek engine (for 25th Anniversary and Judgment Rites) has found its way into another fork.
And maybe there will be more forks soon.......
First off, I brought my Rebel Assault changes mentioned recently to a fork called ra-smush. I also got audio (mostly) working in it (there's a slightly different SAUD frame header). No, don't even think about asking support for it in ScummVM!
Secondly, my old Star Trek engine (for 25th Anniversary and Judgment Rites) has found its way into another fork.
And maybe there will be more forks soon.......
Tuesday, February 15, 2011
Monkey Island FM-Towns for Sale
...at the low low price of $1200! Even Zak isn't going for that much. You know a game is expensive when it's for sale at double the price of Zak McKracken FM-Towns.
But, hey, look on the bright side: there's free shipping.
And now back to our irregularly scheduled program.
But, hey, look on the bright side: there's free shipping.
And now back to our irregularly scheduled program.
Saturday, January 29, 2011
Riven iOS
My father wanted to buy Riven iOS for his iPod Touch, so I figured I'd take a quick look at it. The game itself seems to work well, but the videos are a bit jittery. Now onto the more important part: A look at the data files.
No, I'm not going to reimplement this engine. But at least this would be a good starting point for anyone who wants to.
It was pretty easy to figure out everything that was going on immediately. Ron Hayter already updated his Riveal tool to extract the images from the game. So, here's pretty much what's going on with those formats:
Images
PNG in the main directory and in zip files with the stack name in it, for example: "aspitimages" is the zip file holding images for aspit, also known as the main menu.
Sounds
CoreAudio Format in the main directory.
Movies
MPEG-4 with h.264 video and AAC audio.
Scripts
Now, here's the interesting part. The scripts are all in a SQlite database (version 3). They're also named by the stack, such as "aspitdb" for the scripts for the main menu. The actual scripts seem to be all in strings, probably based on the original HyperCard source (which was never released). I matched up some script segments for a comparison:
Riven iOS Script
Riven Win/Mac Script (dumped using ScummVM)
The card scripts start with the script type. The hotspots have the name followed by the rect followed by their scripts. It's pretty much the same setup as CARD/HSPT in the Win/Mac version.
Miscellaneous Observations
The entire main menu seems to have been converted, but is unused. Anyone who finds a debug mode in the app and goes to the original setup page gets a cookie from me.
No, I'm not going to reimplement this engine. But at least this would be a good starting point for anyone who wants to.
It was pretty easy to figure out everything that was going on immediately. Ron Hayter already updated his Riveal tool to extract the images from the game. So, here's pretty much what's going on with those formats:
Images
PNG in the main directory and in zip files with the stack name in it, for example: "aspitimages" is the zip file holding images for aspit, also known as the main menu.
Sounds
CoreAudio Format in the main directory.
Movies
MPEG-4 with h.264 video and AAC audio.
Scripts
Now, here's the interesting part. The scripts are all in a SQlite database (version 3). They're also named by the stack, such as "aspitdb" for the scripts for the main menu. The actual scripts seem to be all in strings, probably based on the original HyperCard source (which was never released). I matched up some script segments for a comparison:
Riven iOS Script
Riven Win/Mac Script (dumped using ScummVM)
The card scripts start with the script type. The hotspots have the name followed by the rect followed by their scripts. It's pretty much the same setup as CARD/HSPT in the Win/Mac version.
Miscellaneous Observations
The entire main menu seems to have been converted, but is unused. Anyone who finds a debug mode in the app and goes to the original setup page gets a cookie from me.
Sunday, January 23, 2011
The Riven Easter Egg Shortcut
Hopefully the couple readers I have remember a post I did back in August entitled Riven Easter Egg Plus. For those who don't, it was about there being some script fragments on how to shortcut the full Riven easter egg.
Tonight, I present to you the full version of that shortcut. There is a trick to doing it and the game itself will try to block you at various occasions (disabling the shortcut just because you turned one way by accident). Oh yes, with the original interpreter as well. So, here's my best attempt at explaining this. You should *not* click on any red-shaded areas.
1) After the intro videos, walk over to the handle and click it *one* time.
2) Turn around to the cage (avoiding red spots) and look up. Then click the star on top of the helmet *one* time.
3) Turn right from the helmet and avoid red hotspots to walk over to Cho.
4) Click the hotspots on Cho in this order:
At this point, you have just taken a shortcut through the first four parts of the Riven easter egg. The last part is to go press the RAWA hotspot over by the maglev.
Yes, that's right. You can get the entire easter egg setup from the beginning without ever leaving Temple Island. So what are you waiting for? Go try it out! :)
Tonight, I present to you the full version of that shortcut. There is a trick to doing it and the game itself will try to block you at various occasions (disabling the shortcut just because you turned one way by accident). Oh yes, with the original interpreter as well. So, here's my best attempt at explaining this. You should *not* click on any red-shaded areas.
1) After the intro videos, walk over to the handle and click it *one* time.
2) Turn around to the cage (avoiding red spots) and look up. Then click the star on top of the helmet *one* time.
3) Turn right from the helmet and avoid red hotspots to walk over to Cho.
4) Click the hotspots on Cho in this order:
At this point, you have just taken a shortcut through the first four parts of the Riven easter egg. The last part is to go press the RAWA hotspot over by the maglev.
Yes, that's right. You can get the entire easter egg setup from the beginning without ever leaving Temple Island. So what are you waiting for? Go try it out! :)
Tuesday, January 11, 2011
Riven Update
Been a while, but here's a Riven update! Today, I finally finished QuickTime seeking support, so I quickly jumped at the opportunity to implement another puzzle, and here are the results:
Also, the telescope actually moves now instead of just jumping from place to place. Stay tuned for more updates soon, hopefully, maybe!
Also, the telescope actually moves now instead of just jumping from place to place. Stay tuned for more updates soon, hopefully, maybe!
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:
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)!
Subscribe to:
Posts (Atom)