Triton’s HDV model format

Posted on Leave a commentPosted in Game, Into the Shadows, Uncategorised

There was a slight delay in publishing this article as I’d hoped to be able to find the time to delve a little deeper into the format, however this hasn’t been the case so I’ve decided to publish my findings thus far.

I really hope these serve as a good foundation for anyone else looking to take a dive into the demonstration. If you’re perhaps interested in continuing this work, you’ll be able to download the models that I’ve extracted from the demonstration here. Additionally I’ve recently published most of my notes regarding the demonstration, which can be found here.

One of my major goals when digging through the Into the Shadows character demonstration was to figure out a way to pull the models out from the game and then identifying them – this proved to be considerably easier than I anticipated, particularly because of the helpful prompts that Triton’s engine provides when loading the format.


Below I’ve provided my current interpretation of how the header for the HDV format is laid out. There are quite a few holes, especially the data following the variable containing the number of faces within the model.

char identity[32]; /* includes start indicator before text string */

uint32_t face_offset;
uint32_t vert_offset;

uint32_t file_size[2]; /* provided twice, for some reason */

int32_t unknown[2];

uint16_t num_vertices;
uint16_t version;
uint16_t num_faces; /* -2, due to some left-over data */

/* the rest of this is unknown - skip to the face offsets once done here! */

For a start, fudging the header ever so slightly gave me the opportunity to identify what each model actually was within the demonstration – if the model fails to pass validation then the engine will provide the name of the file it was attempting to load. This is partly how I determined the name of each model that was extracted, though I also used the paths and scripts visible within the executable as reference as well.

The header of a model begins with a single byte which is then followed by a string of 31 characters in length which is null terminated. This single byte before the rest of the string is the same for all of the models, so you can pretty much skip this when loading the format (or use it for validation as I have).

All the models are of the same version number, which is simply 514 (or as the engine displays in hexadecimal format, 0x0202).

Besides the header, there are two blocks of data; one for the vertices and the other for faces. The offsets are provided immediately post the identification tag and the offsets provided are relative to the beginning of the file.

Models in Into the Shadows are composed of both triangles and quads – unsurprising for the time.


You ready for this?

int32_t x;
int32_t y;
int32_t z;

Yes, that’s it. Nothing more to it.


The faces on the other hand are a little bit more involved and I’m afraid I didn’t have time to figure out the rest of the structure after finding the vertex offsets, but for the most part you’ll be able to load the model geometry with what I’ve uncovered thus far and should of course also serve as a good starting point for any further digging.

uint8_t u0[2]; /* u0[0] has relation to the number of vertices for the face */
uint8_t c_flag; /* somehow alters the colour of the face? */

uint8_t u1[8];

uint8_t u2;
uint16_t vertex_offsets[4];

int8_t unknown1[16];

The first unknown byte for the face appears to somehow determine the number of vertices, but for the most part if it’s anything but 4 you can assume it’s a triangle and if it does come back as 4 then it’s a quad. I’m perhaps forgetting something here but this was generally the rule to follow.

The second variable that I uncovered, which I’ve dubbed as c_flag, appears to alter the colour of the given face. I’m not sure why it exists but you can actually ignore it, because as far as I’ve seen it’s not actually used for any of the models within the demonstration.

So that’s it for the model format at this time. I’ve implemented an example loader which you’ll be able to find here on GitHub which might also serve as a good starting point with the format.

If anyone else makes any further progress with the model format then don’t hesitate to perhaps throw me an email and I can update this article with any additional information that’s found – it would be great to eventually have a complete understanding of the format, but I also understand there’s very little motivation for this especially when this was, after all, only a basic demonstration of the unfinished technology being built for the game.

Into the depths, of Into the Shadows

Posted on Leave a commentPosted in Article, Into the Shadows, Let's Speculate!

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).


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 800×600, Ultrasound, SoundBlaster, Pro Audio Spectrum and the Microsoft Soundsystem.

 tart New Game 0
 oad Game 0
 ave Game 0
 onfiguration 0
 uit to DOS 0

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

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

Music volume
 Sfx volume


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

 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.


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.

Iron Storm Packages

Posted on Leave a commentPosted in Article, Game, Iron Storm, Projects

I know very little of the Iron Storm game, admittedly, but Saturday evening I decided to take a look at the game and wrote a loader for it’s package format. The package format used in Iron Storm is made up of an LST file, which is basically an index of all the files within the IBF file – the IBF being the actual file that contains the data used by the game.

There isn’t a whole lot to say about either of these but I’ve provided the information below for prosperity; hopefully someone will make something neat out of it!

All the data used by Iron Storm that I’ve seen is unsurprisingly stored as little-endian, but this is worth keeping in mind if you’d like your loader to work on multiple architectures.


The LST format is very simple really. The first part of the file appears to be some sort of identification which will always be ‘_TSL1.0V’, I’m not aware of any exceptions to this, and this is then followed by a 32-bit unsigned integer, which represents the number of indices within the LST file, and finally this is immediately followed by the first index.

So in other words, you could imagine the header structured like so…

struct {
    char ident[8];
    uint32_t num_indices;
} header;

Each index is essentially structured in the following way…

struct {
    char name[64];
    uint32_t data_offset;
    uint32_t data_length;
} index;

So first you have the name of the file within the IBF, this has a maximum length of 64 bytes. This is then followed by the actual offset of the data within the package and then the length, both of which are 32-bit unsigned integers.

Keep in mind that the names are null terminated, although there may be some garbage after each null.


What immediately threw me off while looking at the IBF format, is that Iron Storm appears to use the Resource Interchange File Format (RIFF) for not just audio data, which is typically where you’ll see this used, but for it’s textures and models as well. It’s certainly not something I’ve seen done before for game content, but there’s not really any reason why you wouldn’t do it I guess.

In the case of audio data, it’s worth noting the offset provided in the LST will actually skip over the additional RIFF information before the start of the actual WAV, which is very likely because the engine had no need of it itself and it’s only specific to whatever tools the developers were using to produce these packages.

Otherwise there’s nothing much else to say about the IBF format, if you use the offset and length from each index you’ll be able to find that data within the IBF which you can then copy into memory and do whatever with.

If you’re thinking of producing modifications and other alterations to the game, I think it would be possible to do by repackaging the IBF and LST when altering their contents (if the size is different anyway), but otherwise the game is quite clearly not produced with community modifications in mind. You’re going to be incredibly constrained by what you can do here.

That’s it for now, I’m planning on looking into both the model format and texture formats if I find the time. The texture format appears to be incredibly simple though and even provides descriptors within the RIFF block so that you know exactly what type of image data it is (DXT5 and TGA are two I’ve seen).

A closer look at the Unreal Technology Demo

Posted on Leave a commentPosted in Game, Unreal, Unreal 2, Unreal Tournament, Unreal Warfare

At the European Computer Trade Show, on September 6th 2000, Epic Games unveiled a technology demonstration of the Unreal Engine, showing new features and capabilities that they were introducing to the engine. A number of new features were shown that Epic Games were looking to introduce to the engine in the short term, along with PlayStation 2 support, but with the long term goal of producing a new engine entirely. This iteration of the engine eventually came to be known as the Warfare engine, now known as Unreal Engine 2, the predecessor to Unreal Engine 3.

The technology demonstration was unsurprisingly comprised of a number of different demonstrations but a lot of these provide some fascinating insight into the development of the engine and the upcoming games at the time. We’ll be going over each of these as they appeared in the video below and doing a short analysis on each.

Skeletal Animation

Warrior as shown in the Unreal Technology Demonstration.

The first scene in the video shows us a demonstration of the then new skeletal animation introduced to Unreal Engine. The model shown here, which you can see again in the above screenshot, doesn’t appear to be related to any particular game that was in development at the time, it merely appears to have been produced for the purposes of the demonstration. I do recall hearing somewhere that Epic Games outsourced the production of the model, but don’t take my word on that.

Previously, animations in Unreal Engine were done per-vertex, which meant that the engine would interpolate the vertices to a new coordinate on each frame, essentially by storing multiple copies of the whole mesh for each frame of an animation. For this, Unreal Engine had it’s ‘3D’ model format implementation which was split between two separate files; one containing the mesh and the other containing the transformation of the vertices for each frame of the animation.

It was a little inefficient but it was quicker for the CPUs of the time to process when compared to using skeletal animation, the only downfall was that it used more memory, which inflicted heavy limitations on the complexity of animations which artists could create. The same method was used by id Software for Quake, Quake II and Quake III, though Quake III extended on this to take greater advantage of the higher memory available on systems at its time of release by using greater precision for the coordinate of each vertex (the MDL and MD2 formats, used in Quake and Quake 2 respectfully, used a very low level of precision that resulted in a wobbly effect for animations).

This format saw continued use in Unreal Engine 2 certainly to a lesser extent than before. An example are the flags used throughout Unreal Tournament 2004, which took advantage of per-vertex animation.

The addition of support for skeletal animation to the engine meant that artists could introduce far more complex animations, as well as the ability to blend multiple animations together or for programmers to alter how bones moved during run time to allow characters to look in specific directions, without even requiring a predefined animations. Obviously the implications at the time were huge.

A wireframe view of the Warrior mesh, showing the skeleton as well. This gives a good glimpse at the bones used to perform the facial animation.

Skeletal animation saw a surge in use at the end of the 90s, and by 2001 almost all commercial games appear to have been heavily using skeletal animation over per-vertex animation. Regardless, the technology certainly wasn’t new, it was developed in the late 1980s and saw use within films such as Toy Story, released in 1995, and was a major hallmark of the cancelled game Into the Shadows, which was in development by Triton in 1995.

One key feature Epic Games seems to have chosen to point out here is the ability to add facial animations to characters, likely to demonstrate the level of complexity that artists could expect from the addition of this new technology. The system did not introduce anything on the level that we would later see brought by Valve’s Source Engine, which used a combination of skeletal animation for typical motion and per-vertex animation for facial animations, which gave animators a greater degree of control than was achievable from skeletal animation for facial animation.

From the screenshot below which came from Epic Games’ Unreal Developer Network, you can see the environment in which the facial animations would be produced.

Screenshot taken showing Unreal Warfare soldier being manipulated in Maya.

Another downside of Epic Games’ implementation of facial animation, from my understanding, is that the facial animation wasn’t very flexible; the facial animation was only controllable from modelling tools such as Maya and would have been baked down into individual animations. This would have meant that any changes for an expression would have had to been made outside of Unreal Engine’s UnrealEd, then imported back into the engine again once completed.

To a limited extent, it was possible to export a number of different facial animations, each for various expressions, and for these to have blended together to be combined with animations for speech or other bits of animation, so that characters could express themselves using the same mouth movements without having to create unnecessary duplicates of animation, but this technique would have been very limited to those seen in the years to come that allowed more precise control over facial animation.

Valve opted to use an alternate method for facial animation in the Source Engine; per-vertex animation.

By comparison, Valve introduced a more flexible method which was supported by their own tool, rather boringly dubbed the “Choreography Tool”, or “Faceposer” as it’s more commonly known. By comparison, this tool allowed Valve to produce entire scenes, using their own library of animation overlays and flexing the faces of the characters throughout the scene, and then to preview them within the tool before placing the scene within a level.

It’s worth noting that skeletal animation was eventually introduced to Unreal Tournament in a subsequent update and also used widely for the PlayStation 2 release of the game, however it didn’t see such extensive use until developers began utilising Epic Games’ then new Unreal Warfare engine in 2001.

In an IGN article produced for the demonstration, Epic Games apparently put forward a statement on the new feature that reads the following.

The skeletal animation system, using quaternion-based interpolation, allows for both loss-less and lossy compression of the motion data. The rendering pipeline of the engine is being modified so that characters (and additive solid geometry) can be processed through the hardware T&L pipeline of Direct3D cards with that feature. That means the theoretical limit for polygons and, more importantly, the numbers of characters on screen jumps substantially for applications intended for Microsoft Xbox or computers equipped with hardware T&L-capable cards like Nvidia GeForce or ATI Radeon and the myriad of others that will follow. The new features of DirectX 8 in particular will enable skeletal characters to make full use of the hardware to accelerate rendering of smooth-skinned meshes.

It’s interesting to hear Epic Games refer to the Xbox here, considering that Unreal Championship ended up becoming an Xbox exclusive.

High Detail Models

This part of the video is one of the more interesting segments historically, as it shows a look at an early version of one of the Locust soldiers, which were later found in Gears of War, and at this point they were referred to as the Geist (a German word, meaning “Ghost” in English). At this time, Gears of War was known as Unreal Warfare (the same name that was widely used to describe Epic Games’ upcoming technology) and was in the very early stages in development; very different to the game we received in the end, in terms of both gameplay as well as visually.

The character displayed uses the symbolism of the Locust prominently on his front as well as on his back, which appears to be one of the few designs which has survived the evolution from Unreal Warfare to Gears of War. It’s evident from this that the symbolism of the Locust was established very early on and surprising that Epic Games retained this throughout the game’s development.

The character’s design here, especially with regards to the human appearance and de-saturated skin, seems very similar to what we saw in a later Unreal Engine technology demonstration shown in 2002, which also showed content intended for Unreal Warfare. It’s likely this design, at least stylistically, for the Locust, remained for quite sometime and likely wasn’t entirely thrown out until the team ditched Unreal Engine 2 around the end of 2003, after which the designs in the final game retained the humanoid appearance of some classes of the Locust and the de-saturated skin tone, but overall it seems Epic Games settled upon a more alien design.

It’s possible the reason a less human appearance was chosen for the Locust was due to the team changing focus towards a single-player experience, rather than the class-based multiplayer they had originally envisioned for the game. As this change occurred, the primary enemy of the player within the game became the Locust; this meant opening up the range of characters they would be pitted against and to introduce more variety. This also likely helped create more of a divide between both the Locust and Cog generally, and was intended to make the Locust appear considerably less friendly.

When the scene switches over to show the model from the back we can see a panel with the label ‘SLARIOUX’. It’s possible that this is the name of the character we’re seeing here, the implication could be that this was intended to be a character of importance? It’s unlikely we’ll ever know for sure but this certainly wasn’t something we saw retained in later iterations of the game, as the Locust eventually had their own language and generally their armour did not feature names of any sort. Considering Warfare’s multiplayer focus at this point in its development, another possibility here is that the name plate would feature that player’s own name – something that Unreal Tournament 2004 would feature to a limited extent, displaying the player’s name on the number plate of a vehicle they’re occupying.

While not featured within the video, we can see that the Cog also retained the same symbolism which we see widely used in the final game, which is confirmed by several screenshots featured on the UDN from around the same time. This said, the Cogs design in these screenshots remains very different to that which we see in the final game, and the overall cog theme is perhaps not quite as pronounced as in the overall design below. Again it’s interesting that Epic Games seemingly settled on the symbolism for both sides so early on.

In the above images, it’s certainly interesting to see that the Cog soldier appears to be using the same skeletal rig featured in Unreal Tournament’s PS2 debut, which introduced skeletal animation. It’s also interesting to see the Cog weilding the weaponry also featured in Unreal Tournament; a possible implication that Unreal Warfare was initially using Unreal Tournament as it’s foundation when it started development, this is perhaps further supported by screenshots showing featuring Unreal Tournament’s HUD while displaying assets intended for Unreal Warfare, one of which can be seen below.

Since the HUD here is from the PlayStation 2 version of the game, which introduced the support for skeletal animation, it’s perhaps not surprising to see the Cog soldier making use of the same skeletal rig and animation set. As a matter of fact, it’s very likely that the support for skeletal animation featured in Unreal Engine 2 is simply an iteration of the skeletal animation introduced in the PlayStation 2 version of Unreal Tournament, as that iteration of the engine continued to evolve internally within Epic Games. It certainly seems to be the case that Unreal Warfare, as a game, was built from the PlayStation 2 version of Unreal Tournament.

High Level and Texture Detail

Again, this segment of the video is quite interesting for historical reasons, because it possibly gives us some insight into how other games being produced, using Epic Games’ then new technology, were progressing at the time. Initially we see a map I can’t identify, which was probably produced purely for the purposes of the demonstration, but afterwards we see something interesting; a rather futuristic setting.

Several games that Epic Games were involved with at the time featured a futuristic setting, these range from Unreal Warfare, Unreal 2 and the working title, Unreal Tournament 2, so these screenshots could in essence show any one of these.

Unfortunately I can’t say for certain what we’re seeing here but I believe, on unfortunately very little evidence mind you, that this is Unreal 2. Why? Well there appear to be some subtle indicators here that we can pick out when comparing the shots to content that exists in Unreal 2. If this were the case however, Unreal 2 would have been at such a primitive state at this time – though there is certainly indication that the game was in development at this time.

Unreal 2, of course the sequel to Unreal, was in development outside of Epic Games, and was instead being produced by Legend Entertainment. Unfortunately after the release of the game and shortly after the release of it’s multiplayer expansion, the studio was closed down.

As you can see, there are some rather subtle indicators but of course it’s hard to know for sure – I believe there likely are other textures that match up though.

If there was more evidence to link this to Unreal 2, I would even go as far as saying that this appears to be an earlier iteration of the level found in this screenshot below which was released during Unreal 2’s development, in late May of 2002 (though this iteration of the level actually dates as far back as 2001, as it’s included in a leaked build of Unreal 2 from the time). It features the same crane mechanism, a similar looking table and uses textures from the same texture group, though clearly it’s considerably more varied and detailed, and that’s just speculation on my part.

If this is true, it does imply that the operating table, as it is, has the crane mechanism positioned in the wrong place in the video. Oops.

I hope you enjoyed this article! Eventually I want to cover more regarding the development of Unreal Warfare and the development of the Unreal Engine in general, so stay tuned!


GamesTM – Gears Of War intended to be like Battlefield, had mechs and class-based combat

Unseen64 – Into the Shadows

GDC 2001 Unreal Technology Demo

Postmortem: Epic Games’ Unreal Tournament

Unreal Developer Network

UT: New Tech!

List of Unreal Engine games

Weekly Update

Posted on Leave a commentPosted in Article, Game, Projects, Requiem Avenging Angel

I’ve kind of realised that I’m not doing frequent enough updates. Perhaps it’s time I got into the habit of doing weekly updates just so you know what’s going on and that I’m not totally idle.

So yes, I’ve certainly slowed down with producing videos. It’s not intentional but I’ve kind of lost the motivation a little due to how long the last few videos have taken to produce and the amount of crap I’ve had to deal with when it comes to the Source engine.

Generally I just don’t look forward to launching Hammer, dealing with the crap content pipeline and essentially basically showing things that I’d imagine most of you have already seen; it doesn’t make me feel especially productive. I’m looking to do videos on other things, but I’m afraid I don’t have anything in the pipeline quite at this time.

I’m gradually looking at switching my format to doing more analytical works which is something I’ve always wanted to focus myself towards, primarily in written articles as I can cover more than I could in a video. There are two articles in the works at the moment, one focusing on Unreal Engine 2 and another that covers the last Half-Life 2 video I produced.

On the side as well, I’m spending considerably more time now writing code for projects such as reverse engineering the model format in Requiem Avenging Angel and working towards my open-source Hogs of War project, though I’ve taken some time away from those two specifically to focus on a game I’m working on in my free time which unfortunately is unrelated to the purposes of this website but I might sneak a little plug in for it when it’s closer to completion in the future.

With regards to the Requiem Avenging Angel model format, I guess I might as well begin going into some of it here considering we already published some our work so far.

For starters, Requiem features two separate model formats. One specific for static meshes which is quite simplistic and then another for it’s models that use skeletal animation, which also appear to support multiple textures. Both of the formats use slightly different structures from one another but for the time being we’ve primarily focused on the more simplistic model format.

The very first byte in a static model is a flag that declares how the model will appear within Requiem’s engine. Through some experimentation we were able to determine that the default state for this, which is flag 0, causes the model to use standard Gouraud shading, where as flag 1 results in flat shading and flag 2 results in an unlit model.

After this the file then contains the name of the texture sheet the model will use. This begins with a 32-bit integer that lets us know the length of the string, this is a little unusual and doesn’t appear to have been retained in the animated model format as far as we could tell, but afterwards is followed immediately by the texture name itself. The texture name in each of the models never exceeds 64 bytes. We can then load in the texture name using the length provided within the file.

After which we then immediately stumble into some data declaring the rest of the contents of the model. This begins with a 16-bit integer outlining the number of vertices within the model, then followed by another 16-bit integer that unfortunately I don’t appear to have noted down, oops, and then finally one last 32-bit integer that lets us know how many faces the model features (I think we may have concluded that the vertices was a 32-bit integer as well? My notes suck!)

Finally, we can move onto actually loading the data of the model, such as the vertices and faces. This I will leave for a more dedicated article at another time; we’re planning on going over the model format again over the course of this week but I can say that the vertex coordinates made very little sense to us and they’re something we’re actually still very stuck on. The other noteworthy feature of Requiem’s model format is that faces do not use fixed sizes, and can have any number of triangles per-face (we’ve seen instances of at least 6/7 triangles per-face).

Anyway that concludes this weekly update, hopefully I can keep this up!


Gears of War development ‘previews’

Posted on Leave a commentPosted in Game, Gears of War

Below is a collection of thumbnails that were generated for Epic Games’ Gears of War, which were packaged with the game, and preview several different levels that were produced during the development of the game.

It should be obvious why these are interesting in a lot of respects, especially as they show a lot of content that didn’t make the final cut. Each of these previews appear to have been generated either for levels that were produced purely for testing mechanics of the game but as well as levels that were used to lay out prefabricated areas.

Unreal Warfare Soundtrack, or portions of it

Posted on Leave a commentPosted in Game, Gears of War, Unreal Warfare, Video

Here’s something that might be interesting for a few of you, but here we have three songs used in the Unreal Engine technology demonstration from GDC 2002 and one additional song that wasn’t used in the demonstration.

These songs were packaged with Star Wars Republic Commando, among some other things which we’ll discuss at some other stage in the future.

For those that don’t know what Unreal Warfare is, Unreal Warfare is what eventually became the Gears of War you know today. It was also often used as the name to describe the second iteration of Epic Games’ Unreal Engine, as it initially served as the driving force for many of Epic’s innovations at the time, and before Epic Games had dubbed their new technology as “Unreal Engine 2”.

It’s hard to know exactly when development began on the game, but it’s apparent that the game was in development from as far back as 2001 and didn’t cease to exist as Unreal Warfare until 2004, when Epic Games moved the project to the then in-development Unreal Engine 3 and recycled assets from the game for Unreal Tournament 2004.

Many of the key concepts, such as the Cog and Locust (known at the time as the Geist), the iconography and elements of the universe, were well established very early in the game’s development.

That being said, the game changed dramatically in-terms of gameplay during its development cycle, having originally been intended to be a tactical class-based first-person shooter before then becoming the over-the-shoulder experience when making the move to Unreal Engine 3.

I don’t currently have an article available here on the website regarding the game but it is something I would love to do at some stage. I’m sure a quick Google search should pop up some results.

If you’re interested in downloading the tracks then I’ve made them available here.

Collection of early Unreal Warfare screenshots…

Posted on Leave a commentPosted in Game, Gears of War

Most of these are taken from Epic Games’ UDN, and there’s plenty more there I haven’t included so I highly encourage people take a look!

If you’re not sure what Unreal Warfare is, it’s essentially what became Gears of War. The screenshots below show content from the game back when Epic Games were still developing Unreal Engine 2, which should give you a good idea of how long this game was actually in development for.


Half-Life 2’s Evolution : aaron/canals_01_15 (2002/12/12)

Posted on Leave a commentPosted in Game, Half-Life 2, Video

It’s been an incredibly long time since the last video, but the next one in the series is finally here.

Keep in mind that this ended up getting a little rushed in the end, as I wanted to get it out of the way so I could move onto other things. Turns out moving to Source Filmmaker ended up causing the video to take longer due to a few technical faults along the way, and then work got in the way, and it’s likely in future I’ll be producing these very differently to how I have been previously to save myself more time.

As usual, keep in mind that this series is solely focused on displaying the geometry of the levels rather than playing through each one individually. If you enjoyed this video and want to see more in the future then I highly recommend supporting me on Patreon, as this goes towards supporting the website, the archive and videos such as this.

This is part of a video series showing the gradual evolution of Half-Life 2. It’s not intended to demonstrate gameplay, as most of these levels, in their original form, weren’t playable. Because of the number of levels to cover and the amount of time it takes to clean them up enough to be viewable, these will be kept as quick glances.

This level is produced from the VMF, canals_01_15. The level was likely created by Aaron Barber.

The original VMF can be downloaded here.