I haven't even started playing yet, but the nightmare has well and truly begun.
After rapidly playing through two games that I’d completed previously, I’m very excited to tackle something challenging. Game 4 on the list is one I’ve never played, and in fact knew very little about until today. It’s full title is Déjà Vu: A Nightmare Comes True!!, and it was developed by a company called ICOM in 1985. ICOM Simulations was founded in 1983 in Wheeling, Illinois, and is best known for their MacVenture series of adventure games, of which Déjà Vu is the first. As the MacVenture title suggests, the series was created initially for Macintosh computers, before being ported to numerous other platforms later. The games are the first to be considered “point and click” adventures, which is no small achievement, especially given how successful other games of the subgenre (by companies such as LucasArts) would be in the years following. There were four MacVenture games in total, being Déjà Vu (1985), Uninvited (1986), Shadowgate (1987) and Déjà Vu II: Lost in Las Vegas (1988).
The original Macintosh version of the game
There are actually two versions of Déjà Vu released for PC. The first one was developed for DOS in 1987, while the second was developed for Windows 3.1 in 1991. The screenshots I’ve seen leave no doubt that the 1991 version is far prettier to look at, but since this blog follows the development of adventure games chronologically, it makes much more sense for me to play to DOS version. Unfortunately, from what I can see, the one I’ll be playing looks to be the ugliest of all the ports, but you get that. I’ve also read that the new graphics produced for the 1991 version don’t always adhere to the matching text descriptions (which were left unchanged), resulting in some confusion for players. Just as with Below the Root, I found Déjà Vu very quickly by Googling “déjà vu dosbox download”. I’ve also found the manual in text form here, although it’s clearly meant for the original Macintosh version.
The much prettier Windows 3.1 version which I will unfortunately not be playing.
Before I begin writing any posts for a game, I obviously want to make sure I’m going to be able to successfully play it. I’d had so little trouble running the first three games on the list that it actually came as a surprise when I ran into problems testing Déjà Vu. I’ve been using the latest version of DOSBox, which is version 0.74, up until now. I start games in it by dragging the game executable and dropping it on the DOSBox shortcut on my desktop, and this has worked fine for the likes of Below the Root. I started Déjà Vu using the same technique and everything looked great. I could even play the game successfully for a while, but ran into trouble the moment I tried to save my progress. Clicking Save brought up a screen asking me whether I wanted to save to the A: drive, or a different path, but whatever I clicked the game would simply lock up. After Googling the issue, I came across others having the same problem, and then discovered that the game only works in DOSBox 0.60.
The DOS version box cover.
So, I downloaded DOSBox 0.60, started the game and tried to save. If I tried to save the game to the A: drive, I’d get a Stack Overflow error, so I tried to change the path to the E: drive (my memory stick that contains the game files), only for the game to freeze up again. It was then that I read on a website that the game files need to be stored on the C drive for the game to work properly. I moved the Déjà Vu folder to the C drive, started up the game again, and this time I was able to save my game successfully. Unfortunately, as soon as I tried to restore, I received a message that there were no files available to restore. I could see my save file in the Déjà Vu game folder, but the game wouldn’t recognise it. After an hour of messing around and trying to run the game various different ways, I saved my game with the name “crap” and found I could restore it. A little while later I figured out that the restore process is only looking at the first file in the game folder. If that file happens to be a save file then it’s available to restore (a throwback to dedicated save game floppy disks I guess). Since my save files are appearing in the game folder, anything beginning alphabetically after DEJAGAME.D simply wasn’t being picked up. So, the game works fine once you know to use DOSBox 0.60, have the game folder on the C drive, and save your games beginning with A, B or C. I’m ready to go now!
Never have I been so happy to see crap!
It is really not recommended that you run games in DOSBox via drag'n'drop. Instead, it is intended that you put games in sub-folders of some folder (e.g. C:\users\public\games\dos) then use the MOUNT command in DOSBox to make this be the root of a virtual C: drive.
ReplyDeleteYou can add the mount command to your dosbox config file so that it runs automatically.
There are also frontend applications that can launch dosbox for you with an appropriate configuration.
Thanks for the tip HunterZ. I did actually try mounting Deja Vu but ran into the same problems.
ReplyDeleteI'm grateful that all the GOG purchased games I'm playing automatically start DOSBox in an optimised fashion as I don't really enjoy playing around with it. I just want to play!
Yes, GOG is great! I usually end up tweaking their DOSBox configs a bit, but they definitely get 90% of the way there for me.
ReplyDeleteSounds like Deja Vu is pretty finicky. I'm glad you managed to coax it into working though.
I also realized that I have Deja Vu (and Shadowgate I think) in my NES collection. I haven't spent much time with it since it was just one of many random games that came in lots that I purchased from eBay to get some other specific game.
I'm looking forward to Uninvited and Shadowgate. Mainly Shadowgate because I've spent the most time with it, and Uninvited because I've never beaten that one (last I tried was as a kid).
ReplyDeleteIf you're looking for a good resource for manuals, I suggest replacementdocs.com. They're pretty good for PC manuals, although it seems for Deja Vu they only have the Apple II ones (and NES).
I'd be intrested in hearing you compare the 90s version when you get that far. The graphics in it look pretty respectable.
ReplyDeleteI believe it's Ctrl+F11 / Ctrl+F12 to adjust the emulation speed up/down. The amount of adjustment per keypress can be set in the DOSBox config file.
ReplyDeleteNote also that the current version of DOSBox will default to 3000 cycles for old ("real" mode) games and 80% CPU usage for newer (32-bit protected mode) games. You should be able to override this by changing the line cycles=auto to cycles=auto x 80%, where 'x' is the value you want to use instead of 3000.
I should also mention that the number doesn't correspond to anything meaningful because DOSBox emulates 1 CPU instruction per cycle, but real CPUs take multiple clock cycles to execute some instructions. This is part of why a cycles setting that is good for one game may not be optimal for another.
See http://www.dosbox.com/wiki/Dosbox.conf for details.
HunterZ: While good enough, the technical omissions in your post about CPU cycles make me cringe, as I finished a basic 'how CPUs work' class last semester.
ReplyDelete@Canageek: I was trying to keep it simple, but I'd be curious to know what you think I missed since it's been a while since I studied that stuff myself :)
ReplyDeleteAll piplelined computers (So pretty much all of them) execute instructions in multiple cycles. HOWEVER, due to the piplelining once you process data you will only *wait* one cycle for an instruction to execute.
ReplyDeleteSo if you had a 1 Hz computer, that is 1 cycle per second, you would finish 1 instruction per second, even though it takes 3 cycles to do each instruction.
I don't see this as any different then how DOSbox does it, except that it uses the fact your computer is way faster then the system it is emulating to finish an actual instruction per cycle, instead of doing part of several instructions each cycle.
Now modern x86 computers break long instructions up into many, many mini-instructions because you can pipeline more that way, but you are still *finishing* one instruction each cycle.
I'm ignoring data conflicts and forwarding and such, but the take home message is that if you run a program that is just for{i=0; i; i++}; it will add 1 to i each cycle, assuming nothing else is running on the computer. The advantage breaking the instruction up is that you can do each part *faster* and thus do more cycles/second, and modern computers do fancy things like doing them out of order and crazy stuff, but the stuff going in and coming out the other end is the same.
Does this make any sense? I'm much better with paper and a pen or chalk board when I can draw diagrams and point at things.
It's worth mentioning that none of the CPUs relevant to the time these games were made implemented pipelining.
DeleteReally? I thought that was quite an early development. Huh.
DeleteAccording to Wikipedia, caching and pipelining didn't come to the x86 family until the 486. It may have been around earlier in other CPU architectures.
DeleteThat makes sense, but it's not 100% applicable - mainly because most games with speed-dependent timing issues were written for the older x86 CPU models that didn't have as many of those fancy features of modern CPUs.
ReplyDeleteAlso, I don't know much about pipelining, but my impression is that it doesn't get you one instruction per cycle for every instruction (and possibly not for every sequence of instructions?).
Also, this has been discussed on the DOSBox forums (VOGONS) in the past.
Sorry, left this sitting in my inbox: No, you don't get 1/instruction per cycle due to the fact that sometimes the next instruction relies on the previous one. However, this is mainly due to branching, which I think Adventure Games would have a very low amount of: Other types of hazards are generally resolved by forwarding as I understand it.
ReplyDeleteNow, I'm used to MIPS, not x86, but my understanding is that most of these general ideas are applicable to both.
Modern CPUs sometimes execute out of order for reasons such as branch predication/prediction, and that's because memory is slow, so it's very expensive to ever have to wait page some code in.
DeleteHowever in the prehistorical times of the 1980s, memory was (relative to CPUs of that era) very fast. In the early 1980s, no one even implemented any sort of cache at all.