I gave myself a challenge this weekend, something I had actually wanted to do for a while but I’d unfortunately been too absorbed into other things to find the time to take a proper look. Now, there’s a considerable amount of information you can draw from what’s here so I would consider this the first part which might be followed up with some additional information at some stage; it’s very difficult for me to add every single little detail here as much as I would love to.

Into the Shadows; this is likely a very unfamiliar name for a video-game to many people, which is quite unfortunate given that it was truly a technical marvel for it’s time. The game itself has often been touted in public as a action fighter, compared to the likes of many fighter games of the day such as Virtual Fighter and not so much as an RPG, though from my analysis I think the game was actually very likely a combination of both - I’m not entirely sure why there were mixed messages regarding this, it’s possible the development team weren’t entirely sure themselves, we are after all talking about a game that was incredibly early into it’s development. Regardless the depth of the gameplay that was to be featured in the game has not been publically documented in great depth, very little is known about how the game actually played.

An earlier iteration of the Triton logo, unused in the demo.

Fortunately, despite the lack of publicity and information surrounding the game, in 1995, Triton released a technical demonstration of their game to the public - this referred to itself as the Character Demonstration and showed environments filled with animated characters and objects that were to be featured in the game. Unfortunately, there was absolutely no interactive element to this demonstration whatsoever, and it is a considerably cut down version of what was to be featured in the game, regardless there’s certainly more here than meets the eye.

But before we continue, who on earth are Triton? Triton actually have their own page available on Wikipedia that provides some very useful information about the team, but in essence their previous experiences were in the demoscene and on the Amiga. In 1995, Triton became one of the developers that teamed up with a then new publisher named Scavenger, Inc. - that was until Scavenger went under in 1997 due to financial difficulties, but I believe that would probably need it’s own article and I’m sure many others have already covered it.

The demonstration itself is credited to the following people.

 Programming         Magnus Hogdahl & Fredrik Huss
 Main art            Mikko Tahtinen
 Main 3D-design      Jens Schmidt
 Add. art & 3D       Magnus Hogdahl
 Music               Magnus Hogdahl

The engine Triton developed was dubbed the Triton Virtual Reality System, which is confirmed by looking through the strings of the compressed executable - though in one article it is also referred to as the Triton Advanced Physics Engine but I’m fairly certain this was a misunderstanding. For sure, Triton’s engine, which we’ll refer to as TVRS, was very ahead of it’s time featuring skeletal animation (using motion-capture no less), planar shadows for characters, animated sprites, transparent textures, lightmaps (which appear to even operate based on the transparency of any textures) and certainly much more. The development of the engine appears to have been primarily credited to both Magnus “Vogue” Högdahl and Fredrik “Mr. H” Huss, who were involved with programming the game and engine.

Internally, this particular demonstration of the game appears to have been referred to as ‘D1’, possibly implying an intention to release other demos in the future. Within the packed executable, method names can be found thanks to some packed debug information - the following methods using a ‘D1’ prefix can be seen which were very likely implemented solely for the demo.

0000:4F94 D1_Quit
0000:5042 D1_TestQuit
0000:514D D1_Menu
0000:588B D1_Time
0000:58C9 D1_TickTock
0000:5A10 D1_EndText
0000:5DE4 D1_TritonLogo
0000:634B CharacterDemo1
0000:6A2D D1_ReadParameters

0787:0233 CS_CharacterDemo1GetCamera
0787:035C CS_CharacterDemo1
0787:04ED CS_CharacterDemo1Close

4FAC:0004 D1_Loop
4FAC:0006 D1_TextY
4FAC:0012 D1_MixFrq

4FAC:29D4 D1_Fnt
4FAC:29D6 D1_TickTockTime

A few things of note before we go a little further. When we began digging through the executable, we discovered that the executable had been compressed - however upon further examination, we discovered there were actually two separate executables compressed separately. As it turns out, there are two copies of the demonstration within the files, the one near the start of the executable is the one that is actually executed upon launching ‘ITSDEMO.EXE’, however the second executable is not used and does not appear to operate (it presents an error message on launch). It’s very likely this is an earlier version of the demonstration that was accidentally bundled.

When decompressed, both applications within the demonstration are the same size, however they give a different checksum so they aren’t 100% 1:1 with one another.

7b91849c1eb382d8bcd6b6df37b7ebd4 ./_A.EXE (first executable, the one we usually run)
fd2ee0a985a02783adc5b159a1b346a1 ./_B.EXE (second executable, this one will crash on launch)

The demonstration also seems to use a separate subset of the game-data, meaning the developers specifically produced this as a separate build of the game with it’s own subset of assets. Interestingly, the executable for the game refers to assets with a direct path, including the specific drive the assets would have been located on. There’s some layer that would route these to a location within the packed executable, however we were unable to see anywhere this was being done within the demonstration - we couldn’t even find anything that matched the offsets for where files began within the executable - it’s a mystery right now how this is working.

This hasn’t stopped us from figuring out the names of some of the files the demonstration refers to however, and where these specific files are located within the packed executable (it’s just a longer and slower process).

Graphics

There are a number of assets packaged within the demonstration which go unused. First and foremost, as you see below, there are a number of separate ILBM images left within the game’s resources. Some of these you will recognise from the Character Demonstration, while there are many you won’t, such as those displaying window elements, mouse cursors, HUD icons and some other oddities.

It’s perhaps unsurprising that the team chose the ILBM format here given their previous experience with the Amiga and the wide use of ILBM on that platform.

You’ll likely notice that each of these images are considerably large and feature a lot of unused space, I’m not exactly sure why this is but it’s highly possible that the team intended to cut these down to a more appropriate size once they were settled with the artwork - for example, the image featured here shows what appear to be a number of different takes on Erik’s portrait splashed about quite randomly, however in actuality I think you would find that they were likely using the images found in the left upper corner within the game itself. The portrait of Erik seen in the left corner on that image is actually featured in some screenshots of the game which were shared by one of the game’s artists.

One thing to keep in mind is that these would have been incredibly early iterations of the interface elements within the game’s development, as the game continued development onward through 1996 until Scavenger’s demise.

While inaccessible in the demonstration, there’s evidence to suggest that menus were implemented within the game to an extent. Various strings are left within the executable that describe a main menu, load game, save game, configuration, sound setup and several other menus that were to be featured within the game, which actually gives us a good insight into how far along the game was at this point in development.

The menu also indicates that at this point in development, the game featured or was intended to support resolutions up to 800x600, Ultrasound, SoundBlaster, Pro Audio Spectrum and the Microsoft Soundsystem.

INSERT NAME #
 tart New Game 0
 oad Game 0
 ave Game 0
 onfiguration 0
 uit to DOS 0

CONFIGURATION
 Screen resolution:
 320x200 +
 320x400 +
 640x400 (Hi-res.) +
 i-res config.
 Window size:
 Music volume
 Sfx volume

SOUND SETUP
 Sound board:
 None +
 Ultrasound +
 SoundBlaster +
 Pro Audio Spectrum +
 Microsoft Soundsystem +

Music volume
 Sfx volume

KEYBOARD HELP F
 Esc
 F1
 F2
 F3
 F4
 F5
 F10
 Tab
 Enter

= Main menu 1
 = Help 1
 = Save game 1
 = Load game 1
 = Volume 1
 = Detail level 1
 = Quit 1
 = Items/Actions
 = Fight/Search switch

SELECT MODE #
 320 x 200 0
 320 x 400 0
 640 x 480 VESA 0
 800 x 600 VESA 0
 320 x 200 Tweaked 0
 640 x 400 Tweaked 0

According to the debug information left within the game, the code implemented for the main menu, VR_MENU.PAS was comprised of about 2,390 lines of code (keeping in mind this figure isn’t excluding commented lines). Although we’re obviously unable to see the code itself, this does seem to indicate that there was quite a substantial amount implemented for the menu and possibly HUD already within the game.

As seen from the images we saw earlier, the game was possibly intended to feature windows within the menus of the game, which were likely intended to display messages, dialogue and other prompts within the game - very likely featured heavily within the main menu of the game though impossible to say for certain.

Source Tree

Thanks to the additional debug information left within the executable, we could generate a list of files that made up the source tree of the game. If you haven’t guessed already, yes, the engine was written in Pascal.

 TVR.PAS
 VR_MOVIE.PAS
 DSCRIPT.PAS
 VR_OBJDR.PAS
 VR_ACTVP.PAS
 VR_AI.PAS
 VR_ACTRL.PAS
 VR_INPUT.PAS
 VR_MENU.PAS
 VR_NET.PAS
 VR_FX.PAS
 VR_WDEF2.PAS
 VR_WDEF.PAS
 VR_WPROC.PAS
 VR_WIN.PAS
 VR_WINGR.PAS
 VR_WTWEK.PAS
 VR_WTMUS.PAS
 VR_LENSF.PAS
 VR_SSRVC.PAS
 VR_SPRLD.PAS
 VR_SFX.PAS
 VR_LOADR.PAS
 VR_CAM.PAS
 VR_APLAY.PAS
 VR_MOVER.PAS
 VR_VSRVC.PAS
 VR_EVENT.PAS
 VR_GRUND.PAS
 VR_FLTAB.PAS
 VR_FLOOR.PAS
 VR_TPROC.PAS
 VR_WDRAW.PAS
 VR_UTIL.PAS
 VR_SANIM.PAS
 VR_VANIM.PAS
 VR_PHYS.PAS
 VR_OBJ.PAS
 VR_GLOB.PAS
 VR_VECLD.PAS
 VR_SPACK.PAS
 PMVMB.PAS
 VR_VIEWT.PAS
 PMIMATH.PAS
 PM_VGRPH.PAS
 PM_VESA.PAS
 PMVMM.PAS
 PMPLAY.PAS
 G:\SOUND\PMP_MAIN.PAS
 PMSOUND.PAS
 G:\SOUND\SND_SB.PAS
 G:\SOUND\SND_GUS.PAS
 G:\SOUND\SND_MIX.PAS
 G:\SOUND\SND_NONE.PAS
 PMUTIL.PAS
 PM.PAS

And there’s more to come!

I’m currently working on reverse engineering the rest of the content within the game. This is a very slow process though but I believe I’m making significant progress.