recent articles

NPC and Item Placement Theory 17/03/05 11:35pm PST Non-Player Character (NPC) and item placement can influence both the gameflow and immersion of a level. This article aims to give some pointers on how to properly place them. - Hugh 'Hugh' Lloyd

Got Props? 13/03/05 08:32am PST A common problem in HL2 mapping is props not showing up in game. This article explains why and offers solutions. - Jeff 'Yesukai' Pritchard

Simulating Randomness 18/12/04 11:29pm PST This article focuses on how to properly simulate random events that should occur at a certain average frequency, or within a certain probability per period of time. - Skyler 'Zipster' York

Adding Single-Player Weapons to Half-Life 2 15/12/04 06:52pm PST Covers the process behind adding weapons to a single-player Half-Life 2 modification. - Skyler 'Zipster' York

Your world in HL2 06/12/04 12:17am PST This article gives tips and advice to anyone wanting to make custom photorealistic textures to be used in Half-Life 2. - Oksid

Hiding in Shadow 21/08/04 01:11pm PDT Describes how to create a function that has monsters disregard you if you are hiding in a certain level of "darkness," which can be set from within map properties. - Anders [Wolf] Jenbo (NoBody)

XSI EXP for Half-Life 2 Tutorial - Camera Control 23/09/04 12:43am PDT A SOFTIMAGE|XSI tutorial explaining all of the camera controls available to you in XSI! - Josh Enes

Bump Mapping in Half-Life 08/08/04 11:58am PDT Details a method of achieving real-time bump mapping in Half-Life, and provides an implementation of the algorithm. - Francis 'DeathWish' Woodhouse

Real-Time "TRON 2.0" Glow For Low-Spec Hardware 19/06/04 02:06pm PDT A sequel to the original "Real-Time 'TRON 2.0' Glow" article, this describes how to implement real-time glow that works on low-spec graphics cards. - Francis 'DeathWish' Woodhouse

Hitboxes and Code 05/06/04 06:25pm PDT How do I make only one part of a monster take damage? Learn about the relationship between model hitboxes and what you can do with them in a characters code. - Jonathan 'Teh_Freak' Smith

Real-Time "TRON 2.0" Glow For Low-Spec Hardware [Sat Jun 19, 2004 / 02:06pm PDT] Francis 'DeathWish' Woodhouse - comments (47) I won't take long to introduce the effect this article demonstrates, mainly because I introduced it before in the previous article. It received a good response, but the main complaint was that the method used (vertex and pixel shaders) made it unsuitable for anything but fairly high-end hardware. This article aims to rectify that. Using the same basic algorithm as before, I will describe how you can implement this glow effect without the use of any vertex or pixel shaders. All the hardware requires is the GL_NV_texture_rectangle OpenGL extension (or better), which is supported on even fairly low-end cards. As before, this article will walk you through the steps necessary to implement this in your modification. Here's an image of a scene with no effect applied and this article's effect. More examples of how the effect looks can be found in the previous article. Attached to this article is a pre-compiled version of the effect, bundled into a mini-mod. Extract it into your Half-Life directory, then load up one of the HL maps to see the effect in action. As before, this effect only works under OpenGL, which is no great loss as the majority of people use OpenGL in preference to Direct3D with Half-Life. Let's get moving. First things first, go to your project's settings (Project->Settings in MSVC++) and add 'opengl32.lib' as a library to link with. This enables us to use OpenGL commands as required. Next, open up tri.cpp. At the top, add these two include directives: #include <windows.h> #include <gl/gl.h> Notice that we're not using gl/glext.h, despite the fact that we'll be using an OpenGL extension. This is because all we need is one constant, which we can add in ourselves. Below #define DLLEXPORT, add this: #define GL_TEXTURE_RECTANGLE_NV 0x84F5 Then, after the extern "C" block, add this block of code: #include "r_studioint.h" extern engine_studio_api_t IEngineStudio; We need IEngineStudio to retrieve which renderer is being used - software, OpenGL or Direct3D. After this, add in this block of definitions: // TEXTURES unsigned int g_uiScreenTex = 0; unsigned int g_uiGlowTex = 0; // FUNCTIONS bool InitScreenGlow(void); void RenderScreenGlow(void); void DrawQuad(int width, int height, int ofsX = 0, int ofsY = 0); Now that we've added all the definitions that we require, we can move on to creating the functions. I'll go through them step-by-step, explaining as we go along. After the definitions, add this: bool InitScreenGlow(void) {      // register the CVARs      gEngfuncs.pfnRegisterVariable("glow_blur_steps", "4", 0);      gEngfuncs.pfnRegisterVariable("glow_darken_steps", "3", 0);      gEngfuncs.pfnRegisterVariable("glow_strength", "2", 0); These three CVARs will be used to control the glow. The first one controls how much the screen is blurred, the second one controls how much darker colours are decreased by before blurring, and the third one controls how strongly the glow is applied to the scene.      // create a load of blank pixels to create textures with      unsigned char* pBlankTex = new unsigned char[ScreenWidth*ScreenHeight*3];      memset(pBlankTex, 0, ScreenWidth*ScreenHeight*3); We create a block of memory with which the textures we create will be initialised.      // Create the SCREEN-HOLDING TEXTURE      glGenTextures(1, &g;_uiScreenTex);      glBindTexture(GL_TEXTURE_RECTANGLE_NV, g_uiScreenTex);      glTexParameteri(GL_TEXTURE_RECTANGLE_NV, GL_TEXTURE_MIN_FILTER, GL_LINEAR);      glTexParameteri(GL_TEXTURE_RECTANGLE_NV, GL_TEXTURE_MAG_FILTER, GL_LINEAR);      glTexImage2D(GL_TEXTURE_RECTANGLE_NV, 0, GL_RGB8, ScreenWidth, ScreenHeight, 0, GL_RGB8, GL_UNSIGNED_BYTE, pBlankTex); This is the texture we use to grab the screen and store it so that we can re-combine it with the glow later on. Notice that we're using rectangular textures, as the screen is never a size that is a power of two in both dimensions.      // Create the BLURRED TEXTURE      glGenTextures(1, &g;_uiGlowTex);      glBindTexture(GL_TEXTURE_RECTANGLE_NV, g_uiGlowTex);      glTexParameteri(GL_TEXTURE_RECTANGLE_NV, GL_TEXTURE_MIN_FILTER, GL_LINEAR);      glTexParameteri(GL_TEXTURE_RECTANGLE_NV, GL_TEXTURE_MAG_FILTER, GL_LINEAR);      glTexImage2D(GL_TEXTURE_RECTANGLE_NV, 0, GL_RGB8, ScreenWidth/2, ScreenHeight/2, 0, GL_RGB8, GL_UNSIGNED_BYTE, pBlankTex); This texture is used to store the blurred and glowing version of the scene. It's half the size of the screen to conserve fillrate.      // free the memory      delete[] pBlankTex;      return true; } All that's left is to delete the memory we allocated. Next is a small utility function to make the code easier to read: void DrawQuad(int width, int height, int ofsX, int ofsY) {      glTexCoord2f(ofsX,ofsY);      glVertex3f(0, 1, -1);      glTexCoord2f(ofsX,height+ofsY);      glVertex3f(0, 0, -1);      glTexCoord2f(width+ofsX,height+ofsY);      glVertex3f(1, 0, -1);      glTexCoord2f(width+ofsX,ofsY);      glVertex3f(1, 1, -1); } This function is fairly self-evident. All it does is draw a quad with dimensions 1x1, and applies the specified texture coordinates with offsets if required. (Remember that the offsets are given a default value of 0 in the prototype for this function.) The last function we need to create is the one that does all the work, and which will be called every frame to do the actual blurring: void RenderScreenGlow(void) {      // check to see if (a) we can render it, and (b) we're meant to render it      if (IEngineStudio.IsHardware() != 1)           return;      if ((int)gEngfuncs.pfnGetCvarFloat("glow_blur_steps") == 0 || (int)gEngfuncs.pfnGetCvarFloat("glow_strength") == 0)           return;      // enable some OpenGL stuff      glEnable(GL_TEXTURE_RECTANGLE_NV);           glColor3f(1,1,1);      glDisable(GL_DEPTH_TEST); We first check to see whether the user's running OpenGL mode - if not, then we just bail and leave the screen as-is. We also check to see if the effect should be rendered at all, by looking at the CVAR settings. Finally, some OpenGL commands are issued that are required for the upcoming stages.      // STEP 1: Grab the screen and put it into a texture      glBindTexture(GL_TEXTURE_RECTANGLE_NV, g_uiScreenTex);      glCopyTexImage2D(GL_TEXTURE_RECTANGLE_NV, 0, GL_RGB, 0, 0, ScreenWidth, ScreenHeight, 0); We need to store the original scene's image so that we can re-combine it with the glowing version later on. If we didn't do this, we'd have nothing to combine the blur with, since the on-screen image gets mangled when we do the blurring.      // STEP 2: Set up an orthogonal projection      glMatrixMode(GL_MODELVIEW);      glPushMatrix();      glLoadIdentity();            glMatrixMode(GL_PROJECTION);      glPushMatrix();      glLoadIdentity();      glOrtho(0, 1, 1, 0, 0.1, 100); The orthogonal projection makes it much easier to render quads exactly across the whole screen. We map the screen from (0,0) to (1,1), meaning the DrawQuad function draws across the whole screen.      // STEP 3: Render the current scene to a new, lower-res texture, darkening non-bright areas of the scene      // by multiplying it with itself a few times.      glViewport(0, 0, ScreenWidth/2, ScreenHeight/2);      glBindTexture(GL_TEXTURE_RECTANGLE_NV, g_uiScreenTex);      glBlendFunc(GL_DST_COLOR, GL_ZERO);            glDisable(GL_BLEND);      glBegin(GL_QUADS);      DrawQuad(ScreenWidth, ScreenHeight);      glEnd();      glEnable(GL_BLEND);      glBegin(GL_QUADS);      for (int i = 0; i < (int)gEngfuncs.pfnGetCvarFloat("glow_darken_steps"); i++)           DrawQuad(ScreenWidth, ScreenHeight);      glEnd();      glBindTexture(GL_TEXTURE_RECTANGLE_NV, g_uiGlowTex);      glCopyTexImage2D(GL_TEXTURE_RECTANGLE_NV, 0, GL_RGB, 0, 0, ScreenWidth/2, ScreenHeight/2, 0); To make darker colours have much less of a glow, we multiply the scene by itself a few times (as determined by the glow_darken_steps CVAR) to make darker colours get even darker, leaving brighter colours still relatively bright (0.2*0.2 = 0.04, which is a 0.16 difference, but 0.9*0.9 = 0.89, which is a 0.01 difference). The result is then stored in the glow texture.      // STEP 4: Blur the now darkened scene in the horizontal direction.      float blurAlpha = 1 / (gEngfuncs.pfnGetCvarFloat("glow_blur_steps")*2 + 1);      glColor4f(1,1,1,blurAlpha);      glBlendFunc(GL_SRC_ALPHA, GL_ZERO);      glBegin(GL_QUADS);      DrawQuad(ScreenWidth/2, ScreenHeight/2);      glEnd();      glBlendFunc(GL_SRC_ALPHA, GL_ONE);      glBegin(GL_QUADS);      for (i = 1; i <= (int)gEngfuncs.pfnGetCvarFloat("glow_blur_steps"); i++) {           DrawQuad(ScreenWidth/2, ScreenHeight/2, -i, 0);           DrawQuad(ScreenWidth/2, ScreenHeight/2, i, 0);      }      glEnd();            glCopyTexImage2D(GL_TEXTURE_RECTANGLE_NV, 0, GL_RGB, 0, 0, ScreenWidth/2, ScreenHeight/2, 0); Now that we've corrected the colours, the next step is to blur the image. We first blur it in the horizontal direction by averaging the pixels around each other. The number of pixels sampled is controlled by the glow_blur_steps CVAR.      // STEP 5: Blur the horizontally blurred image in the vertical direction.      glBlendFunc(GL_SRC_ALPHA, GL_ZERO);      glBegin(GL_QUADS);      DrawQuad(ScreenWidth/2, ScreenHeight/2);      glEnd();      glBlendFunc(GL_SRC_ALPHA, GL_ONE);      glBegin(GL_QUADS);      for (i = 1; i <= (int)gEngfuncs.pfnGetCvarFloat("glow_blur_steps"); i++) {           DrawQuad(ScreenWidth/2, ScreenHeight/2, 0, -i);           DrawQuad(ScreenWidth/2, ScreenHeight/2, 0, i);      }      glEnd();            glCopyTexImage2D(GL_TEXTURE_RECTANGLE_NV, 0, GL_RGB, 0, 0, ScreenWidth/2, ScreenHeight/2, 0); To complete the blur, we take the horizontally blurred image and blur it in the vertical direction. This gives a Gaussian blur-like appearance, with the number of pixels sampled again controlled by glow_blur_steps.      // STEP 6: Combine the blur with the original image.      glViewport(0, 0, ScreenWidth, ScreenHeight);      glDisable(GL_BLEND);      glBegin(GL_QUADS);      DrawQuad(ScreenWidth/2, ScreenHeight/2);      glEnd();      glEnable(GL_BLEND);      glBlendFunc(GL_ONE, GL_ONE);      glBegin(GL_QUADS);      for (i = 1; i < (int)gEngfuncs.pfnGetCvarFloat("glow_strength"); i++) {           DrawQuad(ScreenWidth/2, ScreenHeight/2);      }      glEnd();      glBindTexture(GL_TEXTURE_RECTANGLE_NV, g_uiScreenTex);      glBegin(GL_QUADS);      DrawQuad(ScreenWidth, ScreenHeight);      glEnd(); All that's left is to combine the blurred version with the original to give the finished glow effect. The glow_strength CVAR controls the number of times that the blurred version is added to the original (try setting it to 50 to get some weird psychadelic effects!).      // STEP 7: Restore the original projection and modelview matrices and disable rectangular textures.      glMatrixMode(GL_PROJECTION);      glPopMatrix();      glMatrixMode(GL_MODELVIEW);      glPopMatrix();      glDisable(GL_TEXTURE_RECTANGLE_NV);      glEnable(GL_DEPTH_TEST);      glDisable(GL_BLEND); } Finally, we clear up after ourselvs by resetting the projection matrix back to what it was and enabling or disabling what we disabled or enabled, respectively. All that's left now is to add in the code to make it actually apply the blur. Open up cdll_int.cpp and before the second extern "C" block, add this: // SCREEN GLOW extern bool InitScreenGlow(); extern void RenderScreenGlow(); Then, go to HUD_VidInit (around line 170) and after VGui_Startup() is called, add this:      // SCREEN GLOW      if (!InitScreenGlow())           gEngfuncs.Con_Printf("ERROR: Could not initialise screen glow!"); Last but definately not least, go to HUD_Redraw (around line 210) and add this before gHUD.Redraw() is called:      RenderScreenGlow(); // SCREEN GLOW That's it. You now have the "TRON 2.0"-esque glow effect without any of the vertex or pixel shaders involved in the previous article. All that remains is to compile it, run it, and bask in the warm glow! attached files    tronglow.zip (760.75KB) article created on Sat Jun 19, 2004 / 04:58am PDT this item has been viewed 12134 times [Half-Life / coding]

Only registered users can post comments. Have you registered yet?

47 results, 3 pages, viewing page 1.
prev [ 1 2 3 ] next

user comments

displaying comments of normal or higher rating

1. Hugh 'Hugh' Lloyd Sat Jun 19, 2004 / 02:17pm PDT   Wonderful stuff, getting ye olde download to see if it destroys my computer.

2. Skyler 'Zipster' York Sat Jun 19, 2004 / 03:04pm PDT   * DirectX people demand Tron glow *

3. Chris 'autolycus' Bokitch Sat Jun 19, 2004 / 06:37pm PDT   I don't remember that from Black & White. ;) A DirectX version would make a good tron3 article.

4. Negativity Sat Jun 19, 2004 / 07:08pm PDT   Wait....Tron 3? What the?..... What do you mean with the "would"? Are you guys messing with the Half-Life engine? So many more questions...

5. Steven 'SEThorian' van de Graaf Sun Jun 20, 2004 / 03:16am PDT   DW, tough the effect is niftay, once more I need to bug ye about some disadvantages of this low-end effect. I tried it out on one of my Starlabs maps and there was a nice glow present. The downfall however, was that there was an constant "red-dot-effect" on my screen and that my fps dropped from the normal and steady 75fps to a mere 17 to 22fps. As you may understand, this also doesn't make it quite the ideal option for low-end machines. I made a screenshot and made an example image for you to enjoy / dislike.. Here take a peek at this image. (120kB JPG). That 800x600 image should provide you with the visuals needed to explain my situation. Furthermore, here are my system specs which might help in determening what's causing it: Intel Pentium 4 1.5GHz 512MB DDR GeForce 2 MX400 32MB Running Half-Life in 16bit mode, in OpenGL on a resolution of 1024x768. Windows XP Pro. Fully patched and the like. Edit: Some people may notice the r_speeds are a bit high for such a corridor, but that's because there's something big around the corner. Just before people start clubbing me and the like.. Heheh.. comment modified on Sun Jun 20, 2004 / 03:18am PDT

6. Francis 'DeathWish' Woodhouse Sun Jun 20, 2004 / 04:48am PDT   The grid-like effect is unfortunate, and I have seen it before. I've tried to remedy it by various tweakings, but I've come the conclusion that it's due to the hardware's support for the GL_NV_texture_rectangle extension not being all that fantastic. As for the large drop in frame rate, that's again unavoidable. You can try lowering some of the CVARs to lessen the effect, which will lower the framerate drop.

7. Tony "FragBait0" Levi Sun Jun 20, 2004 / 05:43am PDT   Try running in 32bit color. EDIT: use -32bpp on the command line for HL. comment modified on Sun Jun 20, 2004 / 05:44am PDT

8. Tony "FragBait0" Levi Sun Jun 20, 2004 / 07:28am PDT   Okay I dont know about this version of the effect but i know in the shader version I got the dot effect. Running in 32bit color fixed this straight away.

9. CrAcKbRoCk Sun Jun 20, 2004 / 09:59am PDT   This is really great. GJ DW! Now, the question is, how can this be applied to only specific areas? ie: only lights, only env_glow entities, etc...

10. Skyler 'Zipster' York Sun Jun 20, 2004 / 01:15pm PDT   I second (or third?) running Half-Life in 32-bit mode. Lower color resolutions can and do cause these types of artifacts sometimes.

11. Anders [Wolf] Jenbo (NoBody) Sun Jun 20, 2004 / 04:38pm PDT   the reason why the 16bit gets all grided is because you are multiplying (or rater adding) the 16bit dirter on to of it self, this will casue the colors to be more distinct from it nabore, even with out glow you will be able to see the dither on a good monitor, but scaling and readding dosn't help mask it

12. Steven 'SEThorian' van de Graaf Sun Jun 20, 2004 / 05:01pm PDT   Well, I tried the 32 bit version and the grid effect most certainly went away. The fps problem however, remained. Not only that, but it got worse as well! Half-Life ran on my system on a steady 12fps. Tough the effect now looks good, it's useless since even on my fairly high end system (except for the vid card) it doesn't work fast enough. So it works, but is quite useless in the end. So here's a question to the coding people: Will a directX based version of this effect have a much less heavy effect on the fps? Furthermore: Have the people with the original verison of this effect (the previous article) experienced any slow downs in their Half-Life experience? Like I said before: I like the effect, but currently it's not very functional. Lastly: can you trigger this effect to only make it apply in certain areas? That would most definitely be useful.

13. Francis 'DeathWish' Woodhouse Mon Jun 21, 2004 / 03:52am PDT   A DirectX version of this is impossible to my knowledge, due to certain aspects of the DirectX API and the Half-Life engine. I'd love to be proved wrong on this, though. A slow-down will ALWAYS occur, as there's quite a lot of screen pixels being modified to achieve this effect. It's unavoidable. Try lowering the quality or the resolution you play HL at. Applying the effect only on certain areas would require custom rendering of the entire map and all the models within it. While custom-rendering the map itself is easy, I'm not sure about rendering all the models within it. It's probably possible, but I haven't experimented properly yet, and don't really have time at the moment.

14. Graham 'Gonnas' Smith Mon Jun 21, 2004 / 04:11am PDT   I experience a slight drop in fps for both the high-end and low-end effects, but it's not nearly enough of a drop to make playing a problem. Bare in mind however that I'm on a Radeon 9600 Pro, which probably helps matters somewhat. I'm thinking the effect is perfectly functional, but your graphics card is, you know, old. Oh, and I get the etching effect in both the high-end and low-end versions too. I'll try the 32-bit colour thing to see if the improves things.

15. Aaron Huff Mon Jun 21, 2004 / 08:14am PDT   Hmm, I get 40 fps max on with this effect and about the same with the more high end effect, but I have all the cvars turned down to 1. Then again my specs are P4 2.4 ghz, 512 pc 2700, Geforce FX 5200 128mb. This effect is pretty cool, but IMO 'singleplayer only', because its no fun playing MP with 20 fps

16. Tony "FragBait0" Levi Tue Jun 22, 2004 / 03:40am PDT   Of course you computer is great... the GFFX 5200 IS NOT. Sorry to all you people that just smashed their faces into walls. It seems to me people are expecting that because the article is labeled "low-end" then that means their card-x MUST be able to play at a resonable speed with this. Wrong. In this case "low-end" simply means it will *RUN* and does NOT imply any quality or speed difference between the two effects. It seems to me that the effects are almost perfectly the same but one uses shaders. comment modified on Tue Jun 22, 2004 / 03:56am PDT

17. Tony "FragBait0" Levi Tue Jun 22, 2004 / 03:59am PDT   (continuing from the last one...it seemed to cut some off..meh) What can you expect then?* Im working on the idea you are running at 1024x768 with no AA of AF.... NVIDIA GF2 or older: Unplayable FPS. GF3: Almost playable <30 FPS. Dont use the shader version. Use low blur steps. GF4MX: Cannot use shaders. Very slow at best 30fps or so with low blur steps. GF4Ti: Shader version possibly slower. Use low blur steps. About 30, 40. GFFX 5200: Very slow either way. Below 30 fps. GFFX 5600: Playable. Between 30 and 40 fps. GFFX 5800: Good fps. 40 to 60 at least on most scenes. 6800: Huge. 150+ FPS ATI RADEON 7000/8000: non-shader only. very slow. RADEON 9200/9100: slow between 20 and 50 fps max. RADEON 9500/9600: Great with blur steps 4 or 8. 60+ FPS. RADEON 9700/9800: Awesome really. Safe to use 8 or 12 blur steps. RADEON X800: Out of this world. 150+ KYRO, 3DFX etc No shaders. Very slow. max 40 fps probably. Matrox Pharelia Shaders and non-shaders in theroy. FPS ala vanilla 9500 or GFTi 4200. *Don't slap me around if these are wrong.. Its a total guess ableit educated. EDIT(s): fixed my less than sign stuffing it up etc comment modified on Tue Jun 22, 2004 / 04:02am PDT

18. Laurie Cheers Tue Jun 22, 2004 / 04:14am PDT   For performance, try reducing the resolution of the offscreen texture to (ScreenWidth/4, ScreenHeight/4). Although it will make your glow look more pixelated, it should run faster. I guess it's just a question of finding a balance between the two...

19. Tony "FragBait0" Levi Tue Jun 22, 2004 / 06:03am PDT   Well...yeah you could do that (why didnt i think of that?) I dont think its going to get badly pixelated like that - it does have a biliner filter on it plus its just a little glow effect. One eigth would be pushing it...There you'd start seeing lights in the distance not glowing. *shrug* How much faster does it run at one quarter and does it look bad? Im busy merging this with the shader version ATM. Okay dumb question though: Why render the scene again? If you have the first one in a texture isnt there something to copy it? *shrug* Maybe i should just trust more |337 coders. Argh this could almost become a forum thread yet EDIT: While poking around here i find the code for the low end DrawQuad and the shader one is almost identical. The exception being in the lowend one you call glEnd() and glBegin(GL_QUADS) outside DrawQuads. Is it safe to make one function and keep the glEnd() calls in DrawQuad and take them out of RenderScreenGlow? comment modified on Tue Jun 22, 2004 / 06:06am PDT

20. Ruari O'Sullivan Tue Jun 22, 2004 / 08:05am PDT   Seems familiar... :p Just one point, though... a minor factual correction. You've done a basic box filter, not a Gaussian. "Gaussian blur" isn't a term relating to decomposing a 2D blur into two 1D blur passes; it's a specific convolution kernel which is better at stripping out high frequency information. -randomnine-

47 results, 3 pages, viewing page 1.
prev [ 1 2 3 ] next