A Utopia At Stake Created 1 year ago2019-01-16 00:46:21 UTC by Admer456 Admer456

Created 1 year ago2019-01-16 00:46:21 UTC by Admer456 Admer456

Posted 4 months ago2020-02-16 08:51:30 UTC Post #343752
I think client entities are not read-only. Once the client receives all the data about the entity, then they should be able to write to them as they wish, without affecting entities on the server.

In hud_bench.cpp, I've seen something around line 750, where cl_entity_t's are getting modified. However, I'm not exactly sure how you meant "entities would be read-only".
Admer456 Admer456If it ain't broken, don't fox it!
Posted 4 months ago2020-02-29 05:49:28 UTC Post #343818
Oh I meant model_t.entities would be read only but a lot of the others should be modifiable.
Posted 4 months ago2020-02-29 16:42:10 UTC Post #343826
"entities would be read only but a lot of the others should be modifiable."
Yes, but what do you exactly mean by "entities"? cl_entity_t, sending the modified data back to the server etc.?

Anyway, I accidentally came across another little thing inside model_t:
char* entities;
Only worldspawn has this set, and apparently, it stores the whole entity lump of the BSP. So, that's cool. :3
Not that we can really use it for anything, but it's nice to know.
the image is a bit tall, so

Algorithm: (can be put in some of the HUD classes)
for ( int i = 0; i < 120; i++ )
{
    cl_entity_t *pEnt = gEngfuncs.GetEntityByIndex( i );

    // this doesn't guarantee that the entity exists or doesn't exist
    // but we needed something quick and dirty
    if ( (pEnt->curstate.origin != Vector(0,0,0)) || i == 0 )
    {
        if ( pEnt->model )
            gEngfuncs.Con_Printf( "\nEntindex %i - model->entities %s", i, pEnt->model->entities);
        else
            gEngfuncs.Con_Printf( "\nEntindex %i - no model here", i );
    }
    else
    {
        gEngfuncs.Con_Printf( "\nEntindex %i - no entity here", i );
    }
}
And it looks like vertex manipulation just isn't gonna work on studio models.
User posted image
Can't even read, let alone write to it, LOL. It looks like model_t only provides all data for brush models. For sprites and studio models, it doesn't do much.

In other news, yesterday I made a 65k x 65k units test map.
bigterrain2.bsp - J.A.C.K. could use a farther back clipping plane herebigterrain2.bsp - J.A.C.K. could use a farther back clipping plane here
User posted image
The two large maps before this one were 16k x 16k and 32k x 32k respectively.
bigterrain1.bsp - first large test mapbigterrain1.bsp - first large test map
airveh1.bsp - air vehicle testing mapairveh1.bsp - air vehicle testing map
This bigger size required a slight change in the map compilers (specifically HLCSG), so that the BOGUS_RANGE macro refers to g_iMaxEntityRange instead of a hardcoded value.
g_iMaxEntityRange is, of course, set by the -maxentrange param in HLCSG.

In spring or summer, I'm gonna test a 131k x 131k map, and then I'm done with testing large maps.

I'm very curious to see how feasible large maps will be. Because I'm pretty sure mappers can cram a lot into them even on that scale. :walter:
This test map ate 20% clipnodes (14% with -nohull2) and almost 10% AllocBlock. The other lumps were below 5%.
Considering the fact that this is basically a big box map, this could just be one of the worst possible scenarios, and with enough CLIPping etc., I'm pretty sure making large GoldSrc maps is very doable.
I'll talk about this mod's open map design in one of the future posts.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 4 months ago2020-03-01 05:07:23 UTC Post #343833
Yes that's what I thought - the client gets a read-only view of entities, and I remember trying to get the texture data for models or sprites but couldn't find a way.

Nice work with the big maps - looking forward to the tutorial.
Posted 4 months ago2020-03-01 08:38:00 UTC Post #343834
"I remember trying to get the texture data for models or sprites but couldn't find a way."
At that point I'd probably do a MDL and SPR parser, if I just wanted to read the texture data. It'd be easy too, there are several open-source apps doing that stuff, so, we can use it as a reference / steal the code. :walter:

And thanks, I will most likely write it around late May or early June. I'm trying to focus on my game project, school and some tough emotional problems, so it's gonna take a while.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 4 months ago2020-03-05 18:38:27 UTC Post #343856
Say hello to BOLIDHINT, our new tool texture family member!Say hello to BOLIDHINT, our new tool texture family member!
The other day, I was thinking about how SOLIDHINT was nice, but it didn't have the properties of BEVEL.
And that was a real dilemma for my terrain design decisions. D:
Should I use SOLIDHINT and have cleaner BSP cuts, or should I use BEVEL and have smoother collision on edges of brushes?

So, I thought to myself, why not both?
Today, I went ahead and made that happen. It works!

Definitely gonna release the compilers as soon as Advanced Development Mod 0.1 comes out.
In other news, I restructured the mod base code a little bit.
User posted image
The next step will be to separate all classes into their own files, since there are tons of .cpp files with multiple different entity classes defined in them. Yuck.
Next post will probably be in summer. :thebox:
Admer456 Admer456If it ain't broken, don't fox it!
Posted 3 months ago2020-03-07 06:16:45 UTC Post #343863
At that point I'd probably do a MDL and SPR parser, if I just wanted to read the texture data. It'd be easy too, there are several open-source apps doing that stuff, so, we can use it as a reference / steal the code.
Oh agreed - I was just hoping the data was modifiable at runtime.
Posted 3 months ago2020-03-07 12:39:25 UTC Post #343864
It seems that BOLIDHINT works. :D

In my test map, bigterrain2.bsp (shown somewhere above), I textured all the backfaces (except the one of the very flat ground) with BEVEL, NULL, SOLIDHINT and then BOLIDHINT. The results are kinda interesting.

Firstly, let's take a look at the wireframes:
Reference - approximately 130 facesReference - approximately 130 faces
NULL - 592 wpolys, bad subdivisionNULL - 592 wpolys, bad subdivision
BEVEL - 594* wpolys, bad subdivisionBEVEL - 594* wpolys, bad subdivision
SOLIDHINT - 446 wpolys, good subdivisionSOLIDHINT - 446 wpolys, good subdivision
BOLIDHINT - 446 wpolys, good subdivisionBOLIDHINT - 446 wpolys, good subdivision
*594, probably because one of my view angles was just 1 or 2° off, but it'd be 592 otherwise. :P

So, if we look directly at the wireframes, BOLIDHINT is apparently the same as SOLIDHINT. However, now let's look at the clipnode counts:
NULL - 7148 clipnodes
BEVEL - 4318 clipnodes
SOLIDHINT - 7158 clipnodes
BOLIDHINT - 4122 clipnodes
NULL and SOLIDHINT aren't supposed to create the same number of clipnodes, considering the fact that SOLIDHINT generally produces less wpolys. Keep that in mind.
Worldfaces, worldleaves, marksurfaces, vertices, nodes, leaves, surfedges and edges are smaller with SOLIDHINT and BOLIDHINT compared to the other two.

So, what do these results mean?
Not much. I think this texture is mostly applicable on terrain, and to be exact, ground terrain made out of quads and/or triangular prisms. I haven't tested this yet on tetrahedra. I don't think it should be used for walls (cliff sides, vertical terrain sides etc.) because the player can get kinda wedged into an edge. But those should be CLIPped to simplify their collision anyway.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 3 months ago2020-03-20 20:54:03 UTC Post #343934
slams table
Model data CAN be written to! :3

After grabbing a studiohdr_t pointer (header in the example code), we can access the bodygroup, then the submodel of said bodygroup, and then the vertices of the submodel.
void StudioExampleStuff( studiohdr_t* header, mstudiobodyparts_t* bodygroup, mstudiomodel_t* submodel, Vector& vert, int cntr )
{
    static float flWave = 0.0;

    flWave += M_PI/240.0;

    if ( flWave > M_PI )
        flWave *= -1;

    if ( header )
    {
        bodygroup = (mstudiobodyparts_t*)((byte*)header + header->bodypartindex);

        if ( bodygroup )
        {
            submodel = (mstudiomodel_t*)((byte*)header + bodygroup->modelindex);

            if ( submodel )
            {
                for ( int i = 0; i < submodel->numverts; i++ )
                {
                    float* vertFl = (float*)((byte*)header + submodel->vertindex) + i;

                    float indexWave = (float)i / (float)submodel->numverts;
                    float indexOffset = (indexWave * 2.0) - 1.0;
                    indexWave *= 4.0 * M_PI;

                    vertFl[ 2 ] += sin(flWave + indexWave) * 0.004 * (indexOffset*2.0) + sin(flWave*4.0 + indexWave)*0.01;
                }
            }
        }
    }
}
So, they aren't read-only.

Video: https://i.imgur.com/kYnorpP.mp4

This definitely opens up some new opportunities, such as having custom waves without the need of any vertex shaders (that alone would require doing... stuff to the renderer).
Of course, keep in mind that when one model is changed, it is common for all entities using that model. Meaning if you have 40 entities using models/something.mdl and you change the vertices on it, you will change it on them all. Maybe some mods will have a use for this, where for example, if the player damages one object and its vertices bend, it affects basically every other object in the map.

Imagine literally melting a Gargantua tho'. It'd look hilarious. Deforming terrain, yet again, except this time in the form of a 3D skybox. Anything can be done, really. Unfortunately, depending on the complexity of the model, it can potentially cause performance issues.

In other news, I made a small change to BSP and VIS. Now, BSP outputs two .prt files.
mapname.prt
mapname_viscache.prt

An example mapname.prt looks like this:
539
1330
4 0 123 (28672.000000 12288.000000 0.000000) (32768.000000 12288.000000 0.000000) (32768.000000 12288.000000 16384.000000) (28672.000000 12288.000000 16384.000000)
4 1 122 (28672.000000 12288.000000 16384.000000) (28672.000000 12288.000000 20480.000000) (20480.000000 12288.000000 20480.000000) (20480.000000 12288.000000 16384.000000)
4 1 28 (20480.000000 12288.000000 16384.000000) (20480.000000 12288.000000 20480.000000) (20480.000000 28672.000000 20480.000000) (20480.000000 28672.000000 16384.000000)
4 2 10 (26624.000000 28672.000000 1419.636364) (26624.000000 28672.000000 16384.000000) (26624.000000 30208.000000 16384.000000) (26624.000000 30208.000000 1280.000000)
mapname_viscache.prt:
539
1330
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
4 0 123 (28672.000000 12288.000000 0.000000) (32768.000000 12288.000000 0.000000) (32768.000000 12288.000000 16384.000000) (28672.000000 12288.000000 16384.000000)
4 1 122 (28672.000000 12288.000000 16384.000000) (28672.000000 12288.000000 20480.000000) (20480.000000 12288.000000 20480.000000) (20480.000000 12288.000000 16384.000000)
4 1 28 (20480.000000 12288.000000 16384.000000) (20480.000000 12288.000000 20480.000000) (20480.000000 28672.000000 20480.000000) (20480.000000 28672.000000 16384.000000)
4 2 10 (26624.000000 28672.000000 1419.636364) (26624.000000 28672.000000 16384.000000) (26624.000000 30208.000000 16384.000000) (26624.000000 30208.000000 1280.000000)
539 stands for the number of visleaves, 1330 is the number of visportals.
The 1s are the result of a recursive function called WriteLeafCount_r, so basically, each node writes its number of visleaves.
The problem is, map editors like J.A.C.K., or generally any map-related program like Crafty, not read the .prt file correctly because of these 1s.
Normally, you'd have to use a text editor and remove these 1s, but hopefully, once I release my compilers, there will be no need for that.

An optimisation could be made. Instead of mapname.prt and mapname_viscache.prt having the same content apart from the 1s, mapname_viscache.prt can ONLY have the 1s, and later on, VIS will read both and 'merge' the data.
Alternatively, per seedee's suggestion, VIS can just delete the 1s from mapname.prt once it's done its job.

Either way, this should speed up the workflow a little bit, at least for people who wanna optimise their maps and preview the effects their HINT brushes have on the portals. :)

Here's a video of it in action: https://i.imgur.com/N7al7uJ.mp4
Admer456 Admer456If it ain't broken, don't fox it!
Posted 3 months ago2020-03-29 07:12:58 UTC Post #343988
Ah of course! And the same should work for sprites as well.

And yeah it doesn't look like client.dll has any per-entity callback (looks like they're mostly per-frame). Too bad but better than nothing.
Posted 3 months ago2020-03-31 11:37:46 UTC Post #343994
Map textures can be modified too. So that's a good thing. uwu

video
video 2

Software water effect in OpenGL, anyone? :walter:
Admer456 Admer456If it ain't broken, don't fox it!
Posted 3 months ago2020-03-31 23:38:23 UTC Post #343995
Ooooh yes please.
Rimrook RimrookGoldsource Guru
Posted 3 months ago2020-04-01 14:03:11 UTC Post #343999
Oooh, I concur
UrbaNebula UrbaNebulaGoldSourcerer
Posted 3 months ago2020-04-01 14:13:34 UTC Post #344000
Definitely gonna have to finish that feature one day. Right now it only supports this on a single texture.
It's gonna affect any texture beginning with water or !, but I'm thinking of potential applications of this elsewhere too.

Since this works by modifying the texture's pixels in real-time (NOT affecting the actual WAD file itself), I think we can accomplish real-time moss growth, and potentially many other things!
Admer456 Admer456If it ain't broken, don't fox it!
Posted 3 months ago2020-04-05 05:34:40 UTC Post #344016
Nice work.
I guess that you are limited to the same size texture though? I assume the file is memory-mapped and that overwriting the texture data with a larger texture would overwrite the data that follows it?
Posted 3 months ago2020-04-05 08:45:27 UTC Post #344017
I could just create new textures, probably.
What textures have is an "OpenGL texture number". So by creating a new texture, we're creating a new texture number. Which means I can just do this:
GLint myNewTexture;
... // after some TGA parsing with DevIL and texture creation via gl functions
texture->gl_texturenum = myNewTexture;
As for resizing, i.e. updating the original texture, we'll see. I am definitely thinking of writing some tutorials about this.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 2 months ago2020-04-05 21:44:48 UTC Post #344023
// after some TGA parsing with DevIL and texture creation via gl functions
Oh yes good idea but why not with FreeImage :P
Release 3.18.0 is a maintenance release that mainly brings updates of its third party libraries.
The library has been updated with the new ZLib (1.2.11), LibJPEG (9c), LibPNG (1.6.35), LibTIFF (4.0.9), LibRaw (0.19.0), LibWebP (1.0.0), OpenEXR (2.2.1).
quoted textOther significant improvements concern better support for JPEG saving (when using 32-bit CMYK images) and PSD saving.
quoted textLastly, the library contains many bug fixes provided by our users (will concern especially plugins PCX, TIFF, XPM, GIF, TARGA, PSD, BMP, DDS, PNG, HDR).
quoted textAs usual, check the changes log for full details (especially for bug fixes) and check also the updated FreeImage documentation.
Do you mean resizing of textures?
I think sure that Trasnformation with Matrix. It works for scaling with GL-functions.
SourceSkyBoxer SourceSkyBoxerC# Developer and Linux Creator
Posted 2 months ago2020-04-06 00:17:30 UTC Post #344024
This must use software scaling. That's what I meant. However, if UV coords have a range of 0.0 to 1.0, then I'm completely fine, I won't have to resize the texture or anything.

DevIL supports Targa too:
Truevision Targa - .tga
Tagged Image File Format - .tif
Gamecube Texture - .tpl
Unreal Texture - .utx
Quake 2 Texture - .wal
Valve Texture Format - .vtf
Oh, look at that, one can potentially implement Source texture support in a HL mod. :P
FreeImage looks good too, but I'll see about all that.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 2 months ago2020-04-07 23:28:28 UTC Post #344045
Ah right - didn't even think on playing with gl_texturenum
Looking at texture_t though I see offsets and paloffset which I guess give access to the texture data and palette but as I look now I'm not sure what the offsets are relative to - any ideas?
Posted 2 months ago2020-04-08 19:26:21 UTC Post #344070
Also, one thing to keep in mind is, you're gonna need an updated header file for BSP models.
As for the offsets, I'll try to check these out this weekend.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 2 months ago2020-04-18 04:55:56 UTC Post #344127
Any luck figuring what they offset into?
Posted 2 months ago2020-04-18 09:34:39 UTC Post #344128
I forgot I was gonna do that. Oops. Well, now is the weekend, so... time to see.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 2 months ago2020-04-26 05:32:27 UTC Post #344143
Any luck figuring this out? I poked around again and Mod_Extradata returns raw model data - maybe the offsets work on that point for .mdl files, but not sure about .bsp or .spr files.
Posted 2 months ago2020-04-26 10:48:32 UTC Post #344145
offsets is a byte offset for each mipmap level: https://github.com/id-Software/Quake/blob/bf4ac424ce754894ac8f1dae6a3981954bc9852d/QW/client/model.c#L372-L381

paloffset is an index into a global array of palettes. The Software version uses it to render the images, the OpenGL version passes the palette data to glColorTableEXT.

The layout of texture_t in Software mode seems to be quite different from what's in the SDK, so i wouldn't rely on that type for anything. The type also differs between Software and OpenGL modes.
Posted 2 months ago2020-04-26 16:11:31 UTC Post #344146
@tschumann I haven't even touched it, sadly. I must've forgotten again.
Anyway I am gonna take a look at it today. uwu

@Solo
Thank you very much for the info! I'm planning to poke around just in OpenGL mode, as the experimental branch is already crashing in Software mode, LOL.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 2 months ago2020-04-27 05:29:52 UTC Post #344148
Hm, and it doesn't look like the global palette array is exposed to client.dll - in that linked code it looks like raw pixels get copied right after the texture_t for some reason? Possibly that still happens in GoldSource?

I wasn't planning on playing with this in software mode but I assume the GLQuake texture_t is the same as what is in GoldSource though?

Maybe it isn't possible to modify the raw texture data at a runtime - IEngineStudio.StudioSetupSkin looked promising but it looks like it only loads the texture (https://www.mail-archive.com/search?l=hlcoders@list.valvesoftware.com&q=subject:%22%5C%5Bhlcoders%5C%5D+p%5C%2Fw+model+skins%22&o=newest&f=1) so I'm not sure why it's even exported to client code.
Posted 2 months ago2020-04-27 14:38:50 UTC Post #344150
My assumption is that even if you modify that texture data, you won't see any changes.
texture_t isn't exactly the same as in GoldSrc IIRC. There is a gl_texturenum for detail textures AFAIK but you need an updated com_model.h for that. uwu
Admer456 Admer456If it ain't broken, don't fox it!
Posted 2 months ago2020-05-02 05:28:04 UTC Post #344159
Yeah I see references to an mextrasurf_s but that looks like Xash3D stuff - not sure how regular GoldSource handles it.
Posted 1 month ago2020-05-23 13:40:42 UTC 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 1 month ago2020-05-24 07:45:00 UTC Post #344291
Hm, I might have to do some digging (though the offsets and paloffset have both gone missing?) - fb_texturenum was definitely Xash3D specific I thought anyway.
Too bad there is no proper vanilla updated com_model.h - the one that always gets shared around I think has an out of date decal_t at least.
Posted 1 month ago2020-05-30 05:38:33 UTC Post #344326
Also, in model_t textures is a texture_t** - is this to deal with animated textures or something? I never noticed it before to give it any thought.
Posted 2 weeks ago2020-06-14 21:35:00 UTC 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!
You must be logged in to post a response.