I've been working on Alone in the Dark for several years (since late 2015) with LotBlind and NHG. There's an official topic and guide on Speed Demo Archive if you want more information.
After NHG published its run (2016), some of us continued to discuss the game privately (for many years).
Game objectives
Trigger the end as quickly as possible (by beating Pregzt and getting out of the mansion).
Routing
Based on the NHG run (6:21). Here are a few improvements:
The crack on the 3rd floor can be skipped by entering the inventory and introducing a lag. This causes a snap (e.g. a move by a large offset), allowing to pass over the crack.
Similarly, the space snap can be used to rotate the player suddenly, in a single frame (up to a maximum of 90 degrees).
Fast rotation allows the player to turn twice as fast when running (can only be used for the first 90 degrees).
Instead of opening the doors to exit the library, it's possible to clip against the doors.
Glitches used
It is possible to run through certain walls due to a glitch in the collision engine.
Nightgaunts on the 3rd floor can be avoided by touching the triggers leading to the 2nd floor when the camera is not focused on the player.
Gravity can be deactivated by interrupting the jumping action (e.g. by dropping an object on the ground).
Things more difficult than expected
The lantern cannot be picked up at the beginning because the game hasn't been running for more than 5 seconds. There's a mechanism that prevents an object from being picked up if it's been found recently. Most players and speed runners will never experience this mechanism as it only occurs after a cold start and timers are not reset when a new game is started.
After taking the stairs or tunnels (in the attic or cave), the player sometimes immediately returns to the previous room/floor. This is due to the game running faster than it should. One way to alleviate this issue is to optimize/delay things a little (as this is related to FPS periodically going up and down) or to enter the trigger from a slightly different angle (this works for the cave entrance). If you're unlucky, you'll need dozens of tries to get it right.
It is not possible to edit a previous segment as the slightest change (even if it has no direct impact on gameplay) will always result in desync. This is because libTAS / PCem are not in sync (more on that later).
Similarly, optimizing interaction with inventory is difficult because the number of frames to do something varies (e.g. moving the current item down may take 2 or 5 frames).
PCem / libTAS synchronization
Some of the problems reported above are due to the fact that the game is not synchronized with libTAS.
One frame in libTAS will translate into 2 or 3 frames in AITD. Additionally, a new frame in libTAS will almost always starts in the middle of a frame in AITD (not at the beginning).
This is because libTAS runs at 100 FPS to match PCem's 10 ms increments, whereas the game runs at 70 FPS. The game uses vertical synchronization, but this is a kind of spin-wait that cannot be detected by libTAS. On top of this, there's a bug in the game that causes FPS to exceed 70 FPS every 2 seconds (e.g.: 70, 292, 69, 287,...). The game should cap at 70 FPS.
PCem v17+st-2 can be used to improve this. This is a special version that allows a specific framerate to be used in libTAS (to match the game's framerate). Using this version and a patched game executable (to cap it at 70 FPS), make game frames to be 1:1 with libTAS. This makes everything much easier to control (and in finer gradients).
At the time of writing, PCem v17+st-2 is not authorized by tasvideos. Moreover, this patch is not official (it may not be approved).
Configuration
Early 90s is used as it seems to be the best configuration for this run. Using a slower CPU (eg: Late 80s) slows down the run considerably as 2D backgrounds take longer to load. Using a faster CPU (eg: Late 90s) causes FPS to go really high every 2 seconds and prevents the player from running (even with frame advance). PCem v17+st-2 and the right patch (as explained above) should make it possible to use such a fast configuration.
Special thanks
LotBlind on SDA (this run wouldn't have been possible without him, many of the tips came from our internal discussions) and the tasvideos Discord community (the guys there were very helpful).
eien86: Those of us who played this game back in the day know how uniquely terrifying it can be. They would also remember how hard it is to make it out alive; many different things are there to kill you mercilessly. But above all things, how long the game takes to solve. You can play it for weeks until you beat it without assistance. And even with a walkthrough it might take you a few hours to get it done.
Well forget all I've said above. Here the author exploits all kinds of skips, glitches, sequence breaks, and clever shortcuts to go straight to the sewers and set the evil thing on fire. Only to flee in style thereafter. You can tell many of years of an active community have been poured into making all these discoveries. Nevertheless, the execution itself as provided by the author here is flawless.
The movie has received great feedback from the community and I personally loved every second of it. I have a candidate for Rookie Taser and DOS movie of the year.
Those glitches were very silly. Love little unexpected things like that in TASes. Also shoutouts to LotBlind.
According to this TASVideos page, v17+st-1 or newer are acceptable. I'm no judge but this run looks optimized enough to be acceptable already, and an improved run can be done later on st-2 if you want.
tigrou wrote:
player sometimes immediately returns to the previous room/floor. This is due to the game running faster than it should
Is this due to the aforementioned FPS issue or is the (133MHz) processor too fast? If it's the latter, maybe the Late 80s config (or another processor between 16-133 MHz) would run the game better. Though, game setup might take much longer.
Joined: 10/12/2011
Posts: 6511
Location: The land down under.
CoolKirby wrote:
Though, game setup might take much longer.
In fairness to circumvent that you can make a verification movie installing the game instead.
As for the TAS, I enjoyed being confused with all the out of bounds shenanigans for a title I've only played once. 👍
WebNations/Sabih wrote:
+fsvgm777 never censoring anything.
Disables Comments and Ratings for the YouTube account.Something better for yourself and also others.
Is this due to the aforementioned FPS issue or is the (133MHz) processor too fast?
High FPS. This makes the player move in smaller increments. So small player often ends up touching the trigger (that goes back the other way) once the animation is over. Unlike many games, AITD doesn't use a fixed update loop (eg: the number of tics between frames is constant, regardless of FPS). Instead, it measures the elapsed time between frames and moves actors accordingly.
CoolKirby wrote:
If it's the latter, maybe the Late 80s config (or another processor between 16-133 MHz) would run the game better. Though, game setup might take much longer.
The main problem is that loading the resources will take much longer. There are +100 2D backgrounds loadings during the run and each of them take time (about 10 seconds in total). I don't know how long this would take on a 386, but it should be 40 seconds or more. The reason why it's so slow is those are stored in PAK archives which are compressed.
There have been some experiments using the most powerful tasvideos configuration (PII @450) to make loading even faster, but there are problems with running action. Running requires the up key to be released for a maximum of 3 frames. With such a configuration, the FPS skyrockets every 2 seconds, making it impossible to trigger running in some cases (even with frame advance). v17+st-2 does not have such issue (as FPS are limited) so it should be possible to use such a config.
This was an absolute blast to see, true classic and beautifully destroyed in a positive way.
Thank you a lot for making this! : )
Would love to see a v17+st-2 version - hopefully it's actually compatible with the rules : )
Hi Tigrou, unfortunately I am not able to sync your movie.
I have a fresh install of Ubuntu 22.04 for the only purpose of running this. I followed your instructions precisely, but I am still unable.
If I remove flash.bin, it seems your movie presses Escape way too early so it never continues through BIOS. If I don't remove it (use the one that comes with the BIOSes), it does progress towards the installation phase but then it desyncs and never loads the game.
Can you please do the following:
- Give me the exact contents of your .cfg file. Using pastebin or similar is fine.
- Have you modified the FPS? It doesn't look like, but still worth asking.
- Is there any other setting in LibTAS or PCem or anything else that might be relevant?
- Are you 100% sure you can resync your movie without a flash.bin?
- Can you give me the md5sum of all relevant files as you have them NOW in your file system.
Let's get this movie synced!
> This is my first TAS.
Amazing. id like to see more in the future.
Can saving the game interrupt jump? Saving the game could be faster than dropping the item?
With so many glitches is it not possible to corrupt a save file to trigger the ending?
Can you jump to move during the cutscene?
Can you not throw the lamp first and then insert the talisman?
Can you delay throwing the lamp so that you can open the door with the hook during the fire cutscene?
The final battle against the tree looks like the most complex sequence of events in the whole run so maybe you could find some way to do it faster? Maybe walk backwards so that the knockback is useful?
Does the fireball hit the player's head? Looks funny!
Please add a direct link to the amazing guide: https://kb.speeddemosarchive.com/Alone_in_the_Dark_(1-3)/Game_Mechanics_and_Glitches
>
Can saving the game interrupt jump? Saving the game could be faster than dropping the item?
Can you not throw the lamp first and then insert the talisman?
Can you delay throwing the lamp so that you can open the door with the hook during the fire cutscene?
The final battle against the tree looks like the most complex sequence of events in the whole run so maybe you could find some way to do it faster? Maybe walk backwards so that the knockback is useful?
What moment would be suitable to save game? (instead of dropping item(which item))
The game cannot progress unless the powers of Pregzt (not "the tree") are held by the talisman. It has to be put upon the altar first, only then the (lit) lamp will be able to burn him.
Lamp can be thrown later, but throwing from the ledge where the stone slab is (openable by the hook) is very unlikely (although it does look impossible at first glance because of the height difference and the angle of the corner). Also, that would mean additional turning which would lose time.
edit: Not only that - the lamp has to travel across the room, which costs even more time!
Flying objects travel faster than the player.
Walking backwards is slower than walking forwards (not even mentioning running forwards). Pain animations are slowish and in general don't accelerate backward movement too well because of temporary pausing the movement of the player as well.
Hi Tigrou, unfortunately I am not able to sync your movie.
Here is my INI file. Only cdrom_path and hdc_fn have been modified (compared to Early 90's config).
100 FPS is used. Here is the MD5 hashes calculated from my installation, should be the same as in annotations.
I have re-downloaded the movie I uploaded on tasvideos.org (just to be sure) and it play nicely to the end.
The file gd5430.bin ROM is different from what is suggested in tasvideos. I use 7138354ba08f606ba51df60c18015635 while tasvideos recommend d4ba691ce5e04d950ca7624050e6b409.
Tasvideos file is for pcem v16 rom set, here v17 is used. The one from tasvideos will produce visual glitches in text mode (visible during game installation). I discussed this with feos and he told me v17 was the right one to use. I have the old file (starting with d4ba691c) named as gd5430.bin1 in my rom folder. I don't think it has any consequences.
pb570.nvr : tasvideos mention 9228bf13f3fe46351b1885e073558b67 but I'm not sure from where it came from. The one I used is from the Early 90's package, which is 4c885df878a4c302e1050232f4b3c866. Is this the reason you can't sync it ? I wish I had seen that discrepancy before.
flash.bin : I use a script that delete the file .pcem/roms/pb570/flash.bin before any run. I have checked and it's not there (in case script wouldn't work).
Can saving the game interrupt jump? Saving the game could be faster than dropping the item?
I have tried and it does not work (it does not interrupt the jump).
Dropping an item itself is not time consuming btw. Most of the time is spent for entering menus (which would also be needed for saving the game).
alexheights1 wrote:
With so many glitches is it not possible to corrupt a save file to trigger the ending?
Good question. I have been thinking recently about possibility to trigger the ending by loading a corrupted save (that would have been hex edited before, as a proof of concept)
Maybe it's possible to corrupt a save within the game by forcing too much items to be loaded in the inventory. There is 2 things that came to my mind : forcing VAR33 to be set to 1 (this would allow to use main doors without beating final boss) or arbitrary code execution (then you can do pretty much do anything).
The guide has many crashes documented but none of them where able to do something useful.
alexheights1 wrote:
Can you jump to move during the cutscene?
During the cutscene there is a flag being set that prevents you doing most things with the keyboard (including jumping). You can't enter inventory anymore which is required to jump after throwing or dropping an object.
alexheights1 wrote:
Can you not thrown the lamp first and then insert the talisman?
Good idea. I have tried quickly and wasn't able to do so.
The major issue is you will spend some time in the inventory (to drop the talisman) and once you exit it, the lamp will go forward by a big chunk (the same as the amount of time that elapsed in inventory), making the lamp hit the final boss before talisman is in place (one frame right after you exit inventory).
alexheights1 wrote:
Can you delay throwing the lamp so that you can open the door with the hook during the fire cutscene?
I have been thinking about throwing the lamp from far away but issue is you can only do that from a trigger that is near the final boss.
alexheights1 wrote:
The final battle against the tree looks like the most complex sequence of events in the whole run so maybe you could find some way to do it faster? Maybe walk backwards so that the knockback is useful?
I have tried that already. If you get knocked backwards, you get indeed get a push towards the exit but then you have to turn by 180 degrees to pursue the run and it takes a long time.
alexheights1 wrote:
Does the fireball hit the player's head? Looks funny!
Yes, but for whatever reason, she does not take any damage (probably because it occurs during a fall).
i can crash the game by throwing item out of bounds. i don't know what happens if i save the game just before the crash. loading a new floor by stairs just before the crash and saving the game is the best idea i have for a big load of crash but i dont know if it does anything.... i think particles from gunshot and dead monsters can summon lag for even bigger crash opportunities.... edit: i mean crash the game at the exact moment when the colored zombie balls are loaded!
the guide says something about throwing items through walls? lol. maybe you can throw the lantern at the boss from the opposite direction through the walls? the shot probably fails but everything is as hot in the dark anyway....
O, that is all, i am out of ideas.... although i do know about a glitch but you have to be at the skill level of NHG to do it. (pun)
please make more videos of monsters swapping places with other actors. the "true ending" video where the giant bird walks out of the house is very funny.
