We just moved to a different server. Please be patient until all files and pages are restored and the MediaWiki software has been updated. Thank you

Hellbender

From REWiki
Jump to: navigation, search

Hellbender was developed by Terminal Reality in 1996 and is the successor of Fury³ and Terminal Velocity. Unlike the former two, which are basically identical in any technical aspect, Hellbender introduced some changes to the original engine and its files. Some are still compatible with TV / F³, others were expanded to add more features to the game. This article focuses on the differences between Hellbender and its 2 predecessors, not just the files themselves, because lots of things (especially the obsolete ones) make only sense when you know where they came from...

Hellbender maps are reduced in size, from 256 to 128 cells in both directions. In addition, the terrain resolution (mesh density) was doubled, which further reduces the "physical" area by half. As consequence, a map is now just 1/4 the size it was in Terminal Velocity and Fury³. A terrain cell is 524288 (2^19) units wide, the whole map is 67108864 (2^26) units, shifted in range from -33554432 to 33554431. The vertical scale is left unchanged and is still 8388608 (2^23) units, which is 16 times the width of a terrain cell. The cloud plane is at y-position 8388608 by default but can be changed. The corresponding entry in the LVL file is multiplied with 32768. So a value of 256 equals the old cloud height used in TV / F³. When 3 vertices of a terrain polygon have an y-value of 0, the polygon is not created. That allows to define holes or even remove the terrain completely to make "real" space levels without planet surface. Moreover, the engine supports mip-mapping, real-time terrain deformation, static shadowmaps as well as dynamic lights (per-vertex lighting). But the maximum texture resolution for terrain was reduced to 64. Higher resolution textures are scaled down on level loading.

Contents

Obsolete files

.TDF and .TUN

In Hellbender, tunnels are part of the terrain and are no longer separate like in TV/F³. That makes TDF and TUN files obsolete.

.TXT (Mission briefing)

The textual mission briefings were replaced with Smacker (.SMK) videos, even though the text files are still present and are also referenced in the LVL files.

Compatible files

.RAW .ACT .FOG .LTE(*) .MAP .MIX

These files are 100% compatible to the old engine and are not described here. See the Terminal Velocity article for more details. LTE is a special case, see details in the LTE section below.

.ANI and .TEX

Although these files are compatible to the old ones, the change from 8-bit to 16-bit texture indexes in Hellbender (see CLR and CLx sections below) allows the game to use up to 65536 textures.

Files with changed structure

They have the same file extension and share the same concept, but their structure was changed, which makes them incompatible to TV / F³.

.LVL

Describes a level:

Level type		// always 4
Briefing text		// .TXT (obsolete, ignored by the game)
Heightmap		// .RAW
Texture placement	// .CLR
Global palette 		// .ACT
Texture list		// .TEX 
Quake			// .QKE
Powerups		// .PUP
Texture animations	// .ANI
Tunnel placement	// .TDF (obsolete, ignored by the game)
Sky texture		// .RAW
Horizon gradient	// .ACT
Object definition	// .DEF
Navigation points	// .NAV
Music			// .MOD
Fog table		// .FOG
Light table		// .LTE
Sun light direction	// vector
???			
???			// vector
???
???	
;			
Level enter video	// .SMK
Level leave video	// .SMK 				
Transition video	// .SMK
Mission intro text	// .MIC (obsolete)
Mission end text	// .MIC (obsolete)
!			
Clouds Y-Position		
Courses			// .CRS (waypoints)
Light sources		// .GLT
???			// 0
@			
CDA track		// track number when Redbook audio is used
=			
Briefing video		// .SMK
Failure video		// .SMK
{			
Weather type		
Cloud movement speed	// 2D vector		
???			// 2D vector

.DEF

Defines object properties and the placing of them on the map (and in caves of course). It consists of 2 sections – the upper section is the property definition, the lower one is the placement of the objects. Every definition block has the following structure:

logic, unknown, bbox_size, cx, cy, cz, complex_model, simple_model
thrust_speed, rotation_speed, fire_speed, fire_strength, weapon
show_on_briefing, create_randomly, powerup_probability, powerup
num_rnd_fire_verts, fire_vert#1, fire_vert#2, fire_vert#3 ...
;
num_new_hboxes, hbox#1_vert, hbox#1_size, hbox#2_vert, hbox#2_size ...
!
attack_dist, retreat_dist, object_is_boss, unknown
Description line
#
fire_spread, 2nd_wpn, 2nd_wpn_dist, fire_velocity
%
boss_fire_sfx
boss_yell_sfx
:
path
=
cannon_damage
laser_damage
missile_damage
@
friendly
{
escape_sfx
destroy_sfx

See TV's DEF section for a description of the "inherited" properties except the logics, which are of course altered in Hellbender.

If an object should follow a predefined course, the path parameter is the index of the course defined in the .CRS file. Set this to -1 to use no path. Hellbender introduced a system that can be used to make certain enemies more prone, more resistant or even completely immune to weapons classes. The 3 parameters cannon_damage, laser_damage and missile_damage are multipliers for each weapon class. A Value of 65536 equals the factor 1. If the friendly flag is set to 1, only 2 instances of that object are allowed to be destroyed before failing the mission. The escape_sfx voiceover is played when the object escaped either through a waypoint that leads to a jumpzone or when the object uses the logic "takeoff and escape". No comment on the destroy_sfx parameter! This is what makes the voiceover annoying by constantly naming the damn object you have just destroyed.

All special characters ; ! # % : = @ { are section markers (tags) to tell the parser if the following line(s) are included in the current definition block or not.

.NAV

This is the list of navigation points the player has to "visit" in order to complete the level. The NAV system was improved a little and a few features were added. It's no longer possible to simply skip certain points. 13 types are available in the following order:

0 – Destroy Target
1 – Enter tunnel
2 – Checkpoint
3 – Jumpzone
4 – Exit tunnel
5 – Boss
6 – Starting point
7 – Synchronization point
8 – Drop beacon
9 – NAV list end
12 – Escort object
13 – Pickup message pod
14 – Nyx

All types share the following structure:

Identifier
X, Y, Z
!
Priority, Time
@				
Completion sound	// optional
<unused>		// optional
;				
Proximity sound		// optional
Description text

Identifier is one of the 10 above mentioned types. The vector is the position on the map. When the time parameter is != 0, the player must arrive at this NAV point before the countdown specified here runs out. If he/she doesn't make it, the mission fails. Oddly enough, there's a relatively long time span (around 3 seconds) between the mission fail trigger and the actual failing. The completion sound is played when the NAV point is, well, completed. In case of NAV type 0 and 5 it plays when all specified targets (or the boss) are destroyed. In any other case it plays when reaching the point. The proximity sound plays as soon as the point comes into view. Often used for the "mission objective detected" voiceover. And finally, the description text, which is displayed in the mission objective box on the left screen side. The special characters ! @ ; are section markers (tags) to tell the parser if the optional line(s) is/are included in the current definition block.

The following types have additional info added to the end of the block:

  • 0
Number of targets
Target #1
Target #2
Target #3
...
  • 5
Boss index number
Music file
;
!
Number of targets
Target #1
Target #2
Target #3
...
  • 6
Pitch, Roll, Yaw	// player's initial starting angles
  • 12 (Needless to say that the mission fails when the escorted object is destroyed)
Index of object to escort
  • 13
Index of the message pod
  • 14 (I don't know why the developers didn't just use type 5 for Nyx...)
Index of Nyx

There's a new synchronization point (7) that is used to group certain NAV points together, which can be completed in arbitrary order. That point has no actual level position.

So far, I have no idea why the end of NAV list (9) point was introduced. It seems to have no actual meaning, at least in the few tests I did.

.CLR

Like in TV / F³, these files describe where to place the textures on the terrain. They are 32768 bytes long and hold 16-bit indexes, which correspond to the ones found in the .TEX file specified for the current level.

.QKE

incomplete!

"Quake" files are used to deform terrain in real-time, move boxes around, define switches, secret caves and nasty traps that crush your ship when you least expect it! QKEs consist of 2 sections, the upper one for mesh deformation, the lower one for box movement and switch definition. Definition blocks in the upper section have the following structure:

?
y1, y2			
x1, z1, x2, z2, layer	
?, ?, ?, ?			
0,speed1,pause1,speed2,pause2		
?,?,?,?			// cyclic? Auto-run? Switch-controlled?
Sound1
Sound2
???
???
???
!
???

The two y parameters are the altitude values between which the vertices can move. They range from -32768 to 32768. Y1 must always be the high value, y2 the low value. If not, the behavior is undefined! The x and z parameters define a rectangle in which all enclosed vertices move at the same time. These are vertex numbers, ranging from 0 to 127. When moving a group of vertices they do NOT preserve their initial y positions. Instead, all vertices are moved until they all lie flat at the specified y position(s). If x1 = x2 and y1 = y2, a single vertex can be moved. Layer can be 1 (terrain), 2 (cave ground) or 3 (cave ceiling). The two speed parameters define how fast the vertices move to the respective y-position. Actually, it's the TIME it takes to play the animation, so the speed depends on how far the two y positions lie apart. Lower value means faster speed, one second equals 65536 units. The same applies for the pause parameters. Whenever the animation is activated, one of the two sounds is played, depending on which of the two y-positions the animation starts from. sound 1 plays when moving from y1 to y2 and sound 2 plays – you guessed it – when moving from y2 to y1.

QKEs exist since Terminal Velocity but were never used. It seems that terrain deformation was already planned for TV but that feature was dropped for whatever reason...

.PUP

Just like in the previous games, powerups can be placed on the map (and in caves of course) using PUP files. The game, though, does not use that feature. 23 powerups are available, some of them are unused and were leftovers from Fury³ (the old sprite animations are still in the game files):

HellbenderPowerupList.gif

New files

.RAx

Hellbender introduced 3 additional "Layers" to the topology of a map: a cave layer and 2 box layers. A layer is defined using 2 files, which hold the upper and lower y-position respectively. All RAx files have the same length as the heightmap of the terrain (16384 bytes). Only one box can be defined per cell but it can have arbitrary y-dimensions. A box is created when one of the two parameters is non-zero. The first y-position must always be lower than the second. If not, the box' normals are inverted and its collision detection is messed up. The vertical texture mapping is not axis aligned but stretched with the polygon. A cave is created in a similar way. There's only a "volume" when the two values differ. If both are the same, no polygons are created at that point. When all three vertices of a polygon in the cave ceiling layer are 255, the polygon is not created. This is needed to connect the upper terrain with the tunnel(s). The complete layer can be removed by setting all polygons to 255. The same applies to the cave ground layer but with a value of 0.

There are 6 RAx file types:

  • RA0 = Ground boxes, low values
  • RA1 = Ground boxes, high values
  • RA2 = Chamber ground
  • RA3 = Chamber ceiling
  • RA4 = Chamber boxes, low values
  • RA5 = Chamber boxes, high values

Those files are optional. On level loading, the game looks inside the DATA folder for RAx files with the same filename as the current level.

.CLx

  • CL0 = terrain box texture placement
  • CL1 = cave floor and ceiling texture placement
  • CL2 = cave box texture placement

CL0 and CL2 files are 196608 bytes long and contain 16384 (128x128) arrays of 6 texture indexes for the 6 sides of each box defined in the respective layer. CL1 files are 65536 bytes long, containing two interleaved 128x128 grids of 2-byte texture indexes for the cave floor and ceiling layer. Those files are optional. On level loading, the game looks inside the DATA folder for CLx files with the same filename as the current level.

.LTE

There are now two types of LTE files, the old ones used to define unlit palette colors and a new type that contains static per-vertex shadowmaps for all 3 terrain layers. The size of these LTEs is 114688 bytes, that's 7 interleaved RAW files with the same dimensions as the heightmap – in other words: the file contains 16384 arrays of 7 bytes:

  • Byte 1 = Terrain shadowmap
  • Byte 2 = ? (bool)
  • Byte 3 = ?
  • Byte 4 = Cave ground shadowmap
  • Byte 5 = Cave ceiling shadowmap
  • Byte 6 = ?
  • Byte 7 = ?

Those files are optional. On level loading, the game looks inside the DATA folder for an LTE file with the same filename as the current level.

.GLT

COMING SOON!

.CRS

Objects can follow predefined waypoints, either one time or in a loop. Block structure:

<unused>
<unused>
num, ground, loop
point #1
point #2
point #3
...

Files of unknown purpose

.TTY

I have no idea what these files are used for. Every TTY file in Hellbender contains just a zero (as character, not binary).

Personal tools