Forum posts

Posted 2 days ago2020-10-22 10:17:50 UTC
in Programming video tutorials Post #344794
fox*

Though it does look like a dog. After all, foxes are dog hardware on cat software lol.
Admer456 Admer456If it ain't broken, don't fox it!
A
Admer456 Admer456If it ain't broken, don't fox it!
Posted 3 days ago2020-10-21 10:09:57 UTC
in Programming video tutorials Post #344784
"I'm not sure why you brought Visual Studio 6.0"
There are some folks, I'm guessing, who believe that modding old games is best with old tools. With some specific games it's true, but not with HL.
Other than that, you might also find some people who still think HL SDK 2.3 is the latest, in context of code. Also not true, since the latest one is on GitHub.
So in short, I just wanted to pay some attention to all that, with the message being "always use modern tools if you can."

Speaking of the SDKs and that type of stuff, one might ask why I didn't mention and explain them in this part. I actually planned that for the next part, where I'll cover choosing an SDK, setting up a mod and making the first change. And then, in the part after that one, I'll start doing some simple entity stuff.

Either way, I'm very happy with how it turned out, and people seem to like it, so this series is definitely going to go forward.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 3 days ago2020-10-20 19:02:42 UTC
in Programming video tutorials Post #344781
Inspired by Dimbeak's "Gaming for Your Sins", I've decided to start a video tutorial series as well, however, it's programming instead of mapping. Programming for Your Sins, anyone? xD

Here, I'll post each part as it gets released. Hopefully, the frequency of uploading will be once per one or two months.
Part 0: Introduction
This first video is long by design, but videos after it are gonna be a bit faster-paced. The first few videos are gonna be meant more for beginners, with rough explanations of what classes are, what pointers are and whatnot, but once the series progresses and I start showing some really fancy stuff (complicated entities, weapons, NPCs, money system etc.), then it'll be even faster-paced. I'm hoping that the videos will be no longer than 6 minutes, while some short ones will be up to 2 minutes.

Note: the audio quality is not what I wanted it to be, but given the conditions I'm in, I think it turned out good enough. I'll record in the basement next time, for complete silence and free reverb. xD
Or maybe the attic, wherever's more quiet.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 6 days ago2020-10-18 16:52:37 UTC
in Gaming For Your Sins Post #344779
You are legit inspiring me to also do a tutorial series. xD
Admer456 Admer456If it ain't broken, don't fox it!
Posted 1 week ago2020-10-17 13:27:30 UTC
in Post your screenshots! WIP thread Post #344777
Time to show some dumb screenshots from my even dumber ioquake3 fork.
User posted image
Since school started, I decided to start working on a little engine project for next year's Bosnian gamedev competition. It's gonna be a heavily modified Quake 3 engine that shares some of its ideas and philosophy with GoldSRC and CryEngine. What that actually means will be explained some other day.

So... what is this? A blue dynamic light entity? No. It only looks like it. I'll explain what's going on. Simply put, the engine is managing two entity systems at once.

The engine was originally written in C, and as such, the concept of entity classes isn't achieved via classes themselves. It still does it the way Quake and Quake 2 did it, by using structs and function pointers. Nothing wrong with the approach, depending on the scale of the game.
For example:
void func_breakable_pain( gentity_t* self, gentity_t* attacker, int damage )
{
    if ( self->health - damage <= 0 )
    {
        // Gib me
        GibEntity( self, 0 );
        // Remove entity from world
        G_FreeEntity( self );
    }
}

void func_breakable_use( gentity_t* self, gentity_t* other, gentity_t* activator )
{
    // Damage itself when triggered
    func_breakable_pain( self, activator, self->health );
}

void SP_func_breakable( gentity_t* self )
{
    G_SpawnInt( "health", "50", &self->health );
    G_SpawnString( "model", 0, &self->model );

    trap_SetBrushModel( self, self->model );

    // Link entity into world
    trap_LinkEntity( self );
    self->takedamage = 1;
    self->pain = func_breakable_pain;
    self->use = func_breakable_use;
}
I'm not satisfied with that though. To get what satisfies me, it'd take much more work to modify the existing system, than to make a new one from scratch. So the latter is exactly what I'm doing.

This is how it'd approximately be in the new system:
class FuncBreakable : public BaseQuakeEntity
{
public:
    void Spawn() override
    {
        health = spawnArgs->GetInt( "health", 50 );
        takeDamage = DamageTypes::All;
    }

    void Use( IEntity* activator, IEntity* caller, UseType useType, float value ) override
    {
        Pain( activator, health );
    }

    void Pain( IEntity* attacker, int damage ) override
    {
        if ( health - damage <= 0 )
        {
            SpawnGibs( GetOrigin(), 20, "models/somegibs.md3" );
            MarkForRemoval(); // next tick, this entity is gone
        }
    }

    const int GetEntityFlags() override
    {
        return EntityFlags::SolidBrushEntity | EntityFlags::Static; // will automatically set up a brush model, movement type and solidity
    }

private:
    int health{ 0 };
}
This is just there to get you the basic idea. There's a ton of other stuff I've had in mind for this project.

The blue light is there instead of a visible brush entity, because I didn't finish the networking code. The netcode treats the entity from the new system as if it were one from the legacy system, so it ends up writing the data entirely wrongly, and the client, of course, interprets it wrongly. It's a miracle that it didn't crash the game LOL

Other than that, I'm messing with it just so I can get an excuse to use TrenchBroom instead of J.A.C.K. (even though J.A.C.K. also supports Q3)
I'm loving it so far!
User posted image
Admer456 Admer456If it ain't broken, don't fox it!
Posted 1 week ago2020-10-14 19:36:28 UTC
in Post your screenshots! WIP thread Post #344773
I mean, I used to do it with smoke sprites too. It's just that smoke sprites are, well, entities. They use edicts, and you can't have too many of them. :|
Admer456 Admer456If it ain't broken, don't fox it!
Posted 1 week ago2020-10-11 19:02:57 UTC
in Post your screenshots! WIP thread Post #344760
In reality, I just worked on it sporadically throughout the last 3 years, which is basically how I work on any large map. Lol
Admer456 Admer456If it ain't broken, don't fox it!
Posted 1 week ago2020-10-11 17:12:27 UTC
in Post your screenshots! WIP thread Post #344758
User posted image
WILL I GET YOU INTO A PLAYABLE STATE THIS YEAR?!
I THINK SO!
User posted image
User posted image
My classmates have been waiting for basically 3 years at this point LOL
I will probably make a few new big textures to cover larger areas, and release some sorta preview.
Admer456 Admer456If it ain't broken, don't fox it!
Are you sure you provided the correct link to the tutorial? It leads to a forum thread where none of the 3 links in it are active, and in the Web Archive, nothing can be found regarding the water shader files.
Admer456 Admer456If it ain't broken, don't fox it!
Amazing concept! I'll have to try this out soon.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 3 weeks ago2020-10-01 17:18:48 UTC
in Post your screenshots! WIP thread Post #344745
Seedee's tools basically introduce a new tooltexture and fix the portal files.
Hammer, J.A.C.K., Sledge, basically any editor out there, refuse to open .prt files due to the way VHLT generates them. Seedee's tools basically fix that AFAIK. (so do my tools, but I won't mention those any time soon ;) )
Portal boundariesPortal boundaries
Nem's batch compiler should expose everything you need to do with VHLT for now. There are maybe some features that it doesn't expose, but they're rarely used anyway.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 3 weeks ago2020-10-01 09:46:45 UTC
in Post your screenshots! WIP thread Post #344743
Nice and welcome back. :3
Are you using ZHLT map compilers? Lots of stuff has changed in the last 12 years.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 1 month ago2020-09-20 14:35:55 UTC
in Post your screenshots! WIP thread Post #344732
Fog... or fumes?
:'D
Admer456 Admer456If it ain't broken, don't fox it!
Posted 1 month ago2020-09-07 12:43:06 UTC
in Post your screenshots! WIP thread Post #344701
"The renderer is certainly a massive discovery! you should be super proud! I cant wait until the next update!"
I'm super duper proud already, as with all my work so far.

It's not much of a discovery TBH. People have done it multiple times in the past, they just didn't share too much stuff around. I primarily wanted to do the experiment when I saw this old video again:
In fact, I once saw a Vulkan renderer from the same guy in 2017. There were screenshots on the old Valve Developer Union Discord, but that place is gone now. IIRC engine updates broke some things so he stopped working on it.

The thing is, however, a lot of these renderers from scratch tend to never get released, and most of them that do are mostly renderer additions, not rewrites. The most significant releases I can think of are Trinity Renderer, Paranoia's renderer (in the Paranoia Toolkit) and MetaRenderer. But they all have flaws. Paranoia's renderer is slow and sometimes buggy IIRC, MetaRenderer can get you a VACation due to its usage of a hacked opengl32.dll etc.

So, I thought it'd be a good time to plant the seed of a fast, safe & public renderer rewrite. The best part about this IMO is that it doesn't use any extra DLLs, and it doesn't do anything yet that would trip VAC. We'll see about it in 5 years lol.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 1 month ago2020-09-06 19:40:52 UTC
in Post your screenshots! WIP thread Post #344699
I like what I'm seeing there. ^^

Recently, I've been experimenting with OpenGL and I'm pretty happy to have found out that modern OpenGL is, indeed, possible in HL.
If I were to rewrite the entire renderer, provided I know what I'm doing, it could dramatically increase the performance, and allow maps to use custom shaders and stuff like that. Think about a shader for real-time moss growth. :walter:

However, before I can even think about working on such a renderer (which would replace the entire GoldSRC game renderer, except for the main menu, HUD and stuff), I'll have to focus on bugfixes in my mod base, and then on my ioquake3 fork. But, who knows, maybe it'll be there sooner. :)
Admer456 Admer456If it ain't broken, don't fox it!
Posted 1 month ago2020-09-01 19:37:40 UTC
in Does anyone know what this texture error is? Post #344683
That is caused by linear texture filtering, where the edges between each individual pixel are blurred. OpenGL does not care about the texture boundaries, nor any neighbouring faces, so it blurs every single pixel in the texture.
If you use gl_texturemode gl_nearest_mipmap_linear, this should be gone.

Otherwise, you probably have no option but to shift the texture 1 or 2 texels toward that other texture, so you can prevent the artifact from appearing.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 1 month ago2020-08-26 14:20:01 UTC
in How do i insert prefabs in jack editor Post #344653
Also, something that I find good in J.A.C.K. are the entity connections. It draws lines between triggers and targets, so you can know what entity should be triggering what entity at all times. It definitely helps with the direction arrows too, so I can know exactly how my light_spot or light_environment is rotated.

Other than that, you can toggle NULL, CLIP, HINT and SKIP, and AAATRIGGER. All those except NULL are transparent too, so it doesn't clutter the 3D view.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 2 months ago2020-08-21 12:34:37 UTC
in How do i insert prefabs in jack editor Post #344637
There's no prefab support in J.A.C.K. Your only option is to open two maps at once, and copy-paste from one to the other. There are several prefab maps out there with all HL1 prefabs.
Admer456 Admer456If it ain't broken, don't fox it!
That's a side effect, you'd have to do quite some effort to carry items and other data across transitions in multiplayer.
Admer456 Admer456If it ain't broken, don't fox it!
changelevel2 will never work in multiplayer, as far as I know.
Your best bet is using just changelevel and pass the next map's name.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 2 months ago2020-08-08 14:38:30 UTC
in Post your screenshots! WIP thread Post #344610
You could try opening the .map file in J.A.C.K. I wonder if it'll complain about too many visible objects lmao.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 2 months ago2020-08-04 14:14:25 UTC
in Post your screenshots! WIP thread Post #344595
"Oh! and the tools, lockpicks and the such!"
Oh wait, don't get it confused with Utopia at Stake. xD
They're not the same thing, albeit UAS will be based on ADM.

ADM is the base which will have FMOD, vehicles and a bunch of other entities, while UAS is gonna be a total conversion mod that will actually introduce the new tools, weapons and such stuff.

The upcoming release will basically be ADM 0.1 alpha. This means it should have the following ents: (some of which aren't yet implemented, but will be there soon)
  • audio_2d
  • audio_music
  • func_novis
  • func_loadbar
  • func_lag
  • phys_box
  • phys_explosion
  • util_consoleprinter
  • util_kv_operator
  • util_servercommand
  • util_movewith
  • util_rotator
  • env_sky
  • filter_date_smh
  • filter_date_dmy
  • trigger_difficulty
  • trigger_timer
And some vehicle entities: chair, couch, bathtub car and a simple helicopter with a few seats (which is not yet implemented).
Other than entities alone, it should support up to 65k x 65k x 65k-unit maps out of the box (although some effects like explosions don't yet work outside of 8192 units).
I'm planning to host a testing session live with some buddies on TWHL Discord, too, right about before this gets released. It's either gonna be crazy, or it's gonna be a disaster. Maybe both. :D
Admer456 Admer456If it ain't broken, don't fox it!
Posted 2 months ago2020-08-03 15:46:50 UTC
in Post your screenshots! WIP thread Post #344591
I'm glad someone is excited. ^^
Can I know some of the features you're looking forward to?
Admer456 Admer456If it ain't broken, don't fox it!
Posted 2 months ago2020-08-02 16:47:54 UTC
in Post your screenshots! WIP thread Post #344585
That is excellent. :o

I haven't posted anything of my own in here for some time, hmmmmmm. :3c
Time to change that.

A smol debugging overlay:
User posted image
User posted image
Point ents -> boxes
Sprites -> spheres
Brush ents -> corner boxes

Some more progress on my old Quake map (it's been in sporadic development since 2017):
User posted image
User posted image
User posted image
While testing Advanced Development Mod with my brother one night, we decided to play on the 57k x 57k units map. Dang. He looks so small from a distance.
User posted image
Outside of Half-Life, I'm planning to start a 2-in-1 project with CryEngine 5. It'll be a game, but also a "game system", if I could call it that way...
The main thing about it is that it'll be a full-on FPS template that is good for beginners and people who are coming from GoldSrc and Source. The main thing about it will be the way entities work. I want to achieve something like GoldSrc or Source's trigger system in a modern engine.

And as a mini pet project, I am converting idTech 3 to C++, bit by bit. I've had success since the game, client and UI DLLs are in C++. The engine EXE and dedicated server EXE are also in C++. Now I just gotta actually C++-ify some parts. Efforts have been made in the entity system, since there's an engine entity interface, for example. There's a lot of work to be done, but yeah, I'm pretty happy with it so far.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 2 months ago2020-07-26 08:10:58 UTC
in Post your screenshots! WIP thread Post #344574
It's not showing cuz' you linked the album. You need a direct link ending with the extension, like fj39ud3.png or something like that.
[img:https://i.imgur.com/VHdUlnq.webp]
User posted image
There we go.
Admer456 Admer456If it ain't broken, don't fox it!
Make every angle 0.1. env_sprite has weird rotation logic when it spawns.
So if you want to set pitch to 90°, you should set yaw and roll to 0.1° each, e.g. 90 0.1 0.1 in the properties.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 3 months ago2020-07-20 10:55:54 UTC
in Dumb Question, But..... Post #344553
I think the 7G on security doors in HL1 means "Sector G, lab/area/room/whatever 7" or something like that.
Admer456 Admer456If it ain't broken, don't fox it!
You'll need to use a special Xash SDK for that. You'll need to do some digging to find a VS2019-compatible one tho'. Last time I checked, they built it with VS 6.0, lol.
Admer456 Admer456If it ain't broken, don't fox it!
That'd be pretty nice. I think it could go somewhere here:
https://twhl.info/wiki/page/Tools_and_Resources

Though, we'll have to see what Penguinboy thinks of that first. I'm just a regular community member, so I just think it'd be nice. :crowbar:
Admer456 Admer456If it ain't broken, don't fox it!
That will require some OpenGL programming, and that's not really meant for beginners.
Specifically, you would have to implement a projected texture, although if you really want to do it, you can probably take a look at Trinity Renderer's source code.
Admer456 Admer456If it ain't broken, don't fox it!
Welcome, new guy!

clientscheme.res ain't working, edit TrackerScheme.res instead. You can find the Half-Life TrackerScheme in Steam/steamapps/common/Half-Life/platform/resource/, just copy-paste it to the appropriate folder in your game.
Admer456 Admer456If it ain't broken, don't fox it!
GoldSrc does not support two-sided model rendering. You'll have to clone the mesh manually, and flip the cloned mesh's normals.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 3 months ago2020-07-05 21:42:23 UTC
in Good old Counter Strike 1.6 maps Post #344509
You mean, he inspired you.
Admer456 Admer456If it ain't broken, don't fox it!
This post was made on a thread that has been deleted.
Posted 3 months ago2020-06-29 13:50:10 UTC
in Recreated a scene from the Matrix in Goldsrc. Post #344484
I shall provide minor programming assistance if needed.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 3 months ago2020-06-26 19:29:10 UTC
in Recreated a scene from the Matrix in Goldsrc. Post #344471
Might wanna post this in the "Post your screenshots" WiP thread. But dang. That looks real pretty. owo
Admer456 Admer456If it ain't broken, don't fox it!
This post was made on a thread that has been deleted.
Posted 4 months ago2020-06-21 15:06:29 UTC
in Fix broken lighting Post #344445
Are there any leaks in the map?
Admer456 Admer456If it ain't broken, don't fox it!
Posted 4 months ago2020-06-19 22:26:37 UTC
in Wad capabilities Post #344432
The WAD can store maaaany textures, halflife.wad is an example. I'm not aware of how many exactly.

Also yes, you generally shouldn't make textures too big. Generally, you should stick to 240x240 and less. HLBSP is gonna subdivide polygons every 240x240 texture pixels. This means, if you have a 200x200-unit brush with texture scale set to 1.0, its top will be 1 face. However, if you scale it to 0.5, you'll get 4 faces.

Having large textures is okay if you aren't making the scale really small. 0.5 is the minimum acceptable texture scale IMO, 1.0 is the default, and in larger areas, you can get away with 2.0, sometimes even 4.0.

The error which you get by using low texture scales like 0.5 or 0.25 is typically "AllocBlock full", which means you've hit a limit of how many lightmaps can be allocated for the map. The engine, unfortunately, has a hardcoded value of allocating 1 lightmap pixel per 16x16 texture pixels.

Now, in regards to actual texture dimensions, I'd suggest you to use 240x240 and 480x480 for really HD stuff. HL used to have a "feature" where it would downscale any non power-of-two texture (e.g. 160x160) to the nearest power-of-two one (e.g. 128x128), so you'd lose quality. But, nowadays it's no longer a thing.

Also, the reason those textures might not be appearing in J.A.C.K. is, the texture dimensions maybe aren't divisible by 16. Not exactly sure.
Generally, you should use these values for X and Y:
32, 48, 64, 96, 128, 160, 240, 256, 320, 384, 480, 512, 544.

The maximum texture resolution is about 544x544, but it only works if it's embedded into the BSP.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 4 months ago2020-06-18 13:02:51 UTC
in MAX_MAP_CLIPNODES Post #344416
Do you have any leaks in the map? That could be a cause as well.
The map doesn't look like it needs so many clipnodes.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 4 months ago2020-06-17 13:09:12 UTC
in Mod source code downloads? Post #344412
There are.

HL1:
  • Half-Life: Invasion
  • Spirit of Half-Life (which was an open-source mod by definition, but anyway)
  • Half-Nuked
  • Arrangement Rebirth
... and probably a bunch of others.

For HL2, I don't know any, but they're out there for sure.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 4 months ago2020-06-16 16:34:21 UTC
in MAX_MAP_CLIPNODES Post #344409
There is a big problem with the map.
It's surrounded by a sky "box".
BadBad
Instead, you should "cap" the parts where you can see the sky, like this:
GoodGood
It looks the same in-gameIt looks the same in-game
Clipnodes are collision data for the map. If there were no clipnodes, then we'd fall through the floor as soon as we spawned.
The problem is, when you have a large sky "box" around your map, the compilers will generate clipnodes for literally everything. Even the outer parts that you aren't supposed to reach as a player.
If you seal a map properly and fix all leaks, this problem shouldn't happen.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 4 months ago2020-06-14 21:35:00 UTC
in A Utopia At Stake Post #344403
A small update on the current development status of UAS/ADM:
I've been a bit busy with Heffernan's "Delta City 2155" mod, but I should be back to this thingy next week.
Can't wait to do some more stuff about the FMOD implementation. :)
Admer456 Admer456If it ain't broken, don't fox it!
Posted 4 months ago2020-06-12 14:10:57 UTC
in Need help with broken buttons in mod Post #344398
Check the player use code in player.cpp. Maybe it's got something to do with that. SoHL added some sorta traceline to check if the player's view of the button is obstructed by any world brushes, and chances are, the SoHL "direct use" flag is messing with vanilla HL use code.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 4 months ago2020-06-11 16:28:42 UTC
in Need help with broken buttons in mod Post #344392
What are the changes between your code and the original?
Admer456 Admer456If it ain't broken, don't fox it!
Posted 4 months ago2020-06-09 15:35:25 UTC
in SharpLife - Dot Net Core based modding p Post #344385
I think that initially, when/if SL gets its true release, the compatible mods will only be mods that don't use custom code.
So mini mods with maps, models and stuff would be fine out of the box, but if it's got custom code, it'd have to be rewritten in C# following Sharp-Life-specific stuff.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 5 months ago2020-05-24 10:50:37 UTC
in How to create Pak files Post #344294
"i wonder what that means.. "custom graphics code" and where that should be "inserted""
We're going extremely off-topic from the original thread, but I believe I must show you an example of "custom graphics code" which will get compiled into client.dll:
Draws a quad on the screen, with a specific texture that gets modified every 10 framesDraws a quad on the screen, with a specific texture that gets modified every 10 frames
This can be taken to a whole new level, where you can replace the renderer entirely. So instead of using OpenGL 2.0 or whatever, you use OpenGL 3.3 with GLSL shaders.
A shader which transforms XYZ vertex coordinates into RGB colours, instead of applying a textureA shader which transforms XYZ vertex coordinates into RGB colours, instead of applying a texture
Admer456 Admer456If it ain't broken, don't fox it!
Posted 5 months ago2020-05-23 13:40:42 UTC
in A Utopia At Stake Post #344287
Oh nah, I'm not talking about mextrasurf_s but rather this:
typedef struct texture_s
{
    char                name[16];
    unsigned int        width, height;
    int                    gl_texturenum;
    struct msurface_s    *texturechain;        // for gl_texsort drawing
    int                    anim_total;            // total tenths in sequence ( 0 = no)
    int                    anim_min, anim_max;    // time for this frame min <=time< max
    struct texture_s    *anim_next;    // in the animation sequence
    struct texture_s    *alternate_anims;    // bmodels in frame 1 use these
    unsigned short        fb_texturenum;        // auto-luma texturenum
    unsigned short        dt_texturenum;        // detail-texture binding
    struct mextrasurf_s    *lightchain;        // used for drawing spotlights
    unsigned int        unused[2];            // reserved
} texture_t;
Allegedly, this works just fine with vanilla GoldSrc. I found this texture_s version with gl_texturenum in it on accident, in a Russian tutorial about mirrors.
I wouldn't be surprised if I can get a reference to detail textures this way, too, because then I can just do gl_texturenum = dt_texturenum; or if that doesn't work, I grab the actual texture handled by gl_texturenum and replace it with the one from dt_texturenum using OpenGL commands. It'd be pretty interesting to experiment with these.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 5 months ago2020-05-23 13:15:30 UTC
in How to create Pak files Post #344286
The only reason Paranoia has a custom opengl32.dll is because they didn't know how to achieve things without it. Everything they did with a modified opengl32.dll was entirely possible with the original one, by using proper graphics programming techniques.

They did 3 things: added a stencil buffer, added an alpha buffer and modified the depth range. The alpha buffer was, interestingly, used to support really old GeForce graphics cards, in terms of storing render data for dynamic lights. There are other ways to do that without using a hacked DLL.

But the funniest thing of all is, the stencil buffer was "needed" to prevent the flashlight texture from tiling itself, which was actually easily fixable without a custom DLL.
Here's an illustration:
Normal, with clamping to edgesNormal, with clamping to edges
Without clamping to edgesWithout clamping to edges
Instead of modifying opengl32.dll, they could've just used a simple flag for the texture: GL_CLAMP_TO_EDGE with, of course, a completely black border around the texture itself.
Here are 4 different options for texture wrapping:
User posted image
Taken from here.

The depth range modification was unnecessary, because they could've used some maths to adjust the depth values on the receiving end.
In case you're wondering, this is depth:
Black = close to the camera, white = far from the cameraBlack = close to the camera, white = far from the camera
These values go between 0.0 and 1.0, and it is generally used to blend fog, soft particles and such. I don't know how Paranoia's renderer utilised it, but editing the DLL was needless.

If you want to improve performance in Xash3D, or any HL mod, really, you have to learn about graphics programming with OpenGL. If you have access to Xash3D's source code, you can probably do some smaller optimisations without rewriting the renderer.
Otherwise, if you want a 2x, 3x, 5x improvement in framerates, you need to have quite some experience in modern OpenGL or Vulkan. The most ideal one IMO would be OpenGL 3.x.

One misconception is that rendering APIs like DirectX, OpenGL, Vulkan etc. automatically just render your frames and whatever you throw at them. People think they're like "plug'n'play", but no, they're not. Instead, you are the one who defines how OpenGL will work. You tell it how to render the triangles etc. There are many, many functions that the API provides to you, and you can use it. You are wrestling with your graphics card, yelling at it how to render your stuff.

The problem is, GoldSrc's renderer uses OpenGL in so-called immediate mode. And I've probably talked about this 120 times on TWHL Discord, but here's how immediate mode rendering works: (in a very very simplified way)
  • you tell OpenGL to "begin" rendering
  • you send texture data, vertex data (vertex positions, UV coordinates etc.)
  • you tell OpenGL to "end" rendering and wait for the next frame
The thing is, the CPU is always sending rendering data to the GPU, every frame. The GPU receives the polygons, the textures etc., but it immediately "forgets" it the next frame. This is reason #1 why GoldSrc and Xash3D can perform poorly with many wpolys and even more epolys. Of course, in the late 90s, video cards were built for immediate mode, so logically, it was the only option.
But, it's an issue today and it'll be an issue for God knows how long, because modern GPUs have to emulate this mode. Modern GPUs are built for something else, called retained mode.

Retained mode works this way:
  • upload data to the GPU's video memory (preferably when the map starts), and it stays there
  • render them and wait for the next frame
When you're not sending all the data every frame, you can theoretically render the entire map at 200fps, lol.

So, if you want better fps, learn graphics programming and rewrite a part of, if not the whole renderer to work more efficiently. Otherwise, don't make high-poly models.
Admer456 Admer456If it ain't broken, don't fox it!