Basic Hud Modification

This article or section needs to be cleaned up to conform to a higher standard of quality.
For help, see the VDC Editing Help and Wikipedia cleanup process. Also, remember to check for any notes left by the tagger at this article's talk page.

Overview:

Change the HUD by adding a graphic

Route:

Adding a graphic to the HUD isn't that difficult.

Firstly, it is recommend that you read: Materials Creation

This article goes over how to convert a targa (*.tga) file into a valve texture file (*.vtf) so that you can use it in game. We will also go over these steps.

The possibilities are endless. You can have a graphic for anything, and it’s quite simple.

First things first, decide on an image you want to have in the game. The guidelines are

• The image has to be in targa format (*.tga)
• The targa has to be in 16, 24 or 32 bit depths
• The image has to be of a size multiplied by 2 up to 1024x1024

( i.e. 16x16, 32x32, 64x128, 128x128, 128x256, 512x512, etc. )

Transparency is fine, as you can see below. You are going to be saving this file in the materialsrc directory of your SDK extraction naming it whatever you choose, under a directory named by where your graphic is going to go. Here’s mine:

.../materialsrc/HUD/import.tga

Now create a text file that will be used with a program called vtex to convert our targa into a valve texture file. its going to have a series of variables in it that will tell vtex how to work in order to create our file as we want. Save this in the same exact directory as the targa file, under the same name, replacing .tga with .txt. You should have two files in this directory like this

.../materialsrc/HUD/import.tga .../materialsrc/HUD/import.txt

This is the one i used for the demo

"UnlitGeneric"
{
   "nomip" "1"
   "nocompress" "1"
   "nolod" "1"
}

Vtex .TXT file compile parameters Some of the variables and definitions are The parameters Vtex can parse and understand from the .TXT file are:

• $nolod

Do not use lower quality versions of this texture in lower DirectX versions. Used for non-world graphics such as HUD art.

• $nomip

Do not make mip-levels for this texture. This is used for materials like skyboxes and menu backgrounds.

• $clamps
• $clampt

Do not allow the texture to wrap in the S or T coordinate space, respectively. This is most often used for sprites that are not tiled.

• $skybox

Used for compiling skyboxes. This assures the edges match between each facet.

• $startframe (integer)
• $endframe (integer)

Used for animated textures. Textures must be named as texture000, texture001, texture002, etc. The $startframe defines the beginning frame and the $endframe defines the ending frame.

• $nocompress

Do not use compression on this texture. Useful for textures with fine gradation (like light halos).

• $nonice

Do not use NICE filtering on this texture’s lower mip-levels.

• $dxt5

Use DXT5 compression instead of full compression.[/list:u]

Now is when things get super fun.

once you have this text file with the appropriate variables turned on or off, you are now going to run a conversion utility called vtex.exe. It is hidden in your Source SDK binary directory.

.\steam\steamapps\swallowbush\sourcesdk\bin\vtex.exe

Now for some pre error solving; if you follow the next step you will most likely get an error. One thing that vtex cannot do is create directories. So we have to go into our game directory and add the various directories that we need for our material to work properly.

i had to add HUD because I had already been playing with the SDK’s materials earlier in time, but you might have to add them both. Feel free to just right click and create a new folder, but make sure you have HUD spelled the exact same way it is in the text file or you will have an error.

This is the file that will be converting our targa to a vtf file. Ease is always something i try to use to my advantage, so I opened up the SDK directory and windowed both of my directories.

All you have to do now is to drag one of the two files, this does not matter, onto vtex.exe and the conversion will be done.

vtex.exe converts the file and even copies the file into the directory that you gave it with the text file. Once it has finished we have to go over to our game directory and up to the materials directory. Here is where I am:

steam\steamapps\SourceMods\crap\materials\HUD

In here you will see a new file created. import.vtf! We are almost done, home stretch time. We have to create a new file, mine will be called import.vmt. This is going to be a text file as well, but the game is looking for a .vmt file. So let’s make that! You will want to have access to file extensions here. If you don’t know how to turn them on this is what you do

• Open an explorer window.
• Click on the "Tools" tab.
• Click on "Folder Options."
• Click on the "View" tab.
• Click on the check next to "Hide extensions for known file types" to remove it.
• Click "OK".

Create a new text file, and open it up. This is going to be very similar to the text file we created earlier.

This is the one i used for my demo

"UnlitGeneric"
{
      "$basetexture" "HUD/import"
      "$translucent"   "1"
      "$translucency" "1"
      "$ignorez" "1"
}

VMT Info

Creating a .VMT File

Once the .VTF file has been created, a .VMT file must be created to actually use the texture inside of the engine.

The .VMT will define how the .VTF file is rendered to the screen. There are many shaders that can be used to render a texture. To begin with, we’ll use a simple shader: LightmappedGeneric. This shader is used for world surfaces that should receive lightmaps.

The simplest definition of this shader is:

"LightmappedGeneric"
{
    "$basetexture" "test/MyTexture"
}

This will render the ”test/MyTexture” .VTF file opaquely and with lightmaps applied to it. This is most generally used for textures applied to brush surfaces (like walls). With a .VTF file and .VMT file created, we can use this texture inside of Hammer on surfaces.

One of the easiest methods of creating new .VMT files is to open an existing .VMT that has similar properties to the material you are creating. Edit the contents of the file and save it with a different name to create a new material.

With this file completed all that’s left is to change the HUD and add a class. Despite what some may believe, this is not very hard.

lets start with the class, open up your copy of MSVS.

do a search for "class CHud"

You should be able to cycle through a number of files. I recommend you keep all these stock and if you edit, back them up so you can keep them for reference.

Lets create our own. All we are trying to do is put a graphic on the screen. in hl2 there is a function we have to call in order to get this to happen, called paint. We are going to need a variable to act as a place holder for our sprite so that we can call it in the game via the paint function. It would also be nice to be able to turn this on and off, so I’m going to show you how to use cvars to control HUD elements in this way.

Here is my class definition

#include "hudelement.h"
#include <vgui_controls/Panel.h>

using namespace vgui;

class CHudImport : public CHudElement, public Panel
{
   DECLARE_CLASS_SIMPLE( CHudImport, Panel );

   public:
   CHudImport( const char *pElementName );
   void togglePrint();
   virtual void OnThink();

   protected:
   virtual void Paint();
   int m_nImport;
};

Drop that into hud_import.h.

The simpler you keep things now, the easier you will come to understanding this later if you have to alter your code.

Alright time to start defining these functions. Create a new .cpp file called hud_import.cpp.

Here are the required includes/pre function statements (top of your cpp file)

#include "hud.h"
#include "cbase.h"
#include "hud_import.h"
#include "iclientmode.h"
#include "hud_macros.h"
#include "vgui_controls/controls.h"
#include "vgui/ISurface.h"

#include "tier0/memdbgon.h"

using namespace vgui;

DECLARE_HUDELEMENT( CHudImport );

In order to kick this off we have to load the texture pointer variable. The best place for that is the constructor of the class.

What we are going to do

• Get the viewport and parent it
• make it invisible, but its alpha 100%
• create a new texture id for our texture/sprite
• connect the id to the texture
• have it show only if you have the suit and if you arent dead

Here is what that looks like:

CHudImport::CHudImport( const char *pElementName ) : CHudElement( pElementName ), BaseClass( NULL, "HudImport" )
{
   Panel *pParent = g_pClientMode->GetViewport();
   SetParent( pParent );   
   
   SetVisible( false );
   SetAlpha( 255 );

   //AW Create Texture for Looking around
   m_nImport = surface()->CreateNewTextureID();
   surface()->DrawSetTextureFile( m_nImport, "HUD/import" , true, true);

   SetHiddenBits( HIDEHUD_PLAYERDEAD | HIDEHUD_NEEDSUIT );
}

Alright, so our graphic starts out invisible and we have to paint it now. Let’s go on to the paint function. This one, although is simpler, has a very important part associated with sizing and spacing to deal with.

void CHudImport::Paint()
{
   SetPaintBorderEnabled(false);
    surface()->DrawSetTexture( m_nImport );
   surface()->DrawTexturedRect( 2, 2, 128, 128 );
}

First we set the paint border to false, I didn’t play with this because i was trying to duplicate another class and it had false set here. I’m assuming its the stroke around the panel. Next we draw our texture onto our surface. The next line is the important part. You actually define where you put your panel and how large it is in your HudLayout.res file, this last statement is attached to the image itself. you set its values like this...

surface()->DrawTexturedRect( xspacing , yspacing, xsize, ysize );

So you would put your own values in there according to the size of your picture.

Wow, that was easy and all that is necessary to get an image on the screen for the class. there are still two steps, our cvar toggle as well as the hudlayout.res editing. Neither of which are too complex.

First let’s define the cvar. Go back up to the top of the cpp file and paste this:

static ConVar show_beta("show_beta", "0", 0, "toggles beta icon in upper right corner");

This is the variable name that I’m using. I’m actually creating the series of pictures on the second post.

This variable will allow us to type show_beta 1 into the console.

But what will that do for us, we need a function to test it.

void CHudImport::togglePrint()
{
   if (!show_beta.GetBool())
      this->SetVisible(false);
   else
      this->SetVisible(true);
}

Not too complex, just is it 1 or not? And since its something that can happen at any time, we should put it into our think function so it is tested always.

void CHudImport::OnThink()
{
   togglePrint();

   BaseClass::OnThink();
}

And that’s it. Start this one building and we will move onto our last file.

Open up HudLayout.res and paste this

    HudImport
   {
      "fieldName" "HudImport"
      "xpos" "r86"
      "ypos" "6"
      "wide" "80"
      "tall" "34"
      "visible" "0"
      "enabled" "1"
      
      "PaintBackgroundType"   "2"
   }

That’s it. There are a number of settings to choose from, but for the most part, this will do it.

Schemes & BuildMode

A VGUI scheme defines the general "Look&Feel" of your panels by specifying used colors, fonts & icons of control elements. Schemes are defined in resource files, for example hl2\resource\clientscheme.res. A new panel inherits by default the scheme settings used by its parent. The VGUI scheme manager can load a new scheme with LoadSchemeFromFile(char *fileName, char *tag) which returns HScheme handle. To make a panel using a loaded VGUI scheme call the panel member function SetScheme(HScheme scheme).

Schemes set the general look of panel elements, but they don’t arrange specific control elements of your panel. One way of adding elements to your panel is by doing that in source code. You can create them (usually in the constructor of the parent panel) and set properties like size and position manually using the panel member functions. This will become quite complex and time-consuming for larger dialogs with lots of control elements.

The most common way to define the layout of your panel elements is to describe all elements in an external resource file like "hl2\resource\UI \classmenu.res" (a KeyValues text file). When the parent panel is created, this file is loaded and executed with LoadControlSettings(char *dialogResourceName). In this resource file each control element is defined in a separate section. A typical control definition looks like this:

"MyControlName"
{
   "ControlName"   "Label"      // control class
   "fieldName"   "MyControlName"   // name of the control element
   "xpos"      "8"      // x position
   "ypos"      "72"      // y position
   "wide"      "160"      // width in pixels
   "tall"      "24"      // height in pixels
   "visible"      "1"      // it’s visible
   "enabled"      "1"      // and enabled
   "labelText"   "Hello world"   // show this text
   "textAlignment"   "west"      // right text alignment
}

Each control property has a key name and a value. Properties defined by the base class Panel are available for all controls (like xpos, ypos, wide, tall etc). A list of all available key names is returned by the panel member function GetDescription(). Derived panel classes may add new fields for their specific properties. Processing these new fields must be handled by overwriting the virtual function ApplySettings(KeyValues *inResourceData). Here you can also lookup how values for an existing control property are interpreted.

Even simpler to use is the VGUI Build-Mode that allows you to modify and save the layout of a panel resource file while the application is running. To edit a panel, just start the game and open this panel, so it gets the input focus. Then press SHIFT+CTRL+ALT+B to open the VGUI Build-Mode editor. In Build-Mode you can easily rearrange existing elements and change their control properties (press ‘Apply’ to update changes). To add a new control element, just choose the desired class from the combo-box on the lower right side and an empty control object of that class will be place in your panel for further editing. To save the current layout in the associated resource file press the ‘Save’ button (make sure the resource file is not write-protected).

You are now looking at your HUD, with a graphic in the upper right corner of the screen drawn with rounded corners

External Links

• gneu.org