The adventures of BurekTech pt. 2

5th of January 2021, roughly a month after the last journal, "The adventures of BurekTech", a series where I document my progress with my ioquake3 fork.

New ents

While this isn't directly part of the engine, some entity classes have been implemented:

• env_explosion
• func_button
• func_bobbing
• func_door
• func_toggle (basically like Half-Life's func_wall_toggle)
• trigger_once
• trigger_multiple

Mapping limits and otherwise

I've upped several limits now. Max visible entities are now 1024, max models are 1024, max sounds are also 1024 for now. Each of these were 256. Max brush models are thus also raised to 1024, I believe. Nonetheless, these limits are very easy to raise. It's just a matter of choosing sensible values, and for now, it's perfectly enough for me.

I've done some research and been reading the code. Max lightmaps seem to be 512, which is way, waaaaay more than enough for me at least. Max world faces (wpolys) are 131 072, max visleaves are also 131 072, max brushes are 65 536. Clipnodes aren't used in idTech 3, so I don't have to worry about those.

Stupid Mover Bug

While I was implementing and testing func_bobbing, I noticed a really bizarre bug with player movement. On the clientside, the player would "detect" the moving entity fine, and try to move along with it. But on the server, that wouldn't happen. Ultimately, the answer was somewhere in the serverside collision code.
Solid entities need to have an absolute bounding box defined in order to be taken into consideration when clipping against. My entity's abs bbox wasn't being correctly set up due to its origin. Quite an unusual thing. I decided to name it Stupid Mover Bug, inspired by the Stupid Quake Bug.

Custom compiler

Ah yes, I've FINALLY managed to clone gtkRadiant just to get its q3map2 compiler. It's cleanly written for the most part and it's not too complex for a compiler. Miles cleaner than VHLT, although I guess its light stage could use some neat things from VHLT...
The first thing I've done was adding Valve 220 support, mostly copied from XaeroX's J.A.C.K. version of q3map2. The difference is, It's a compile parameter now, -valve220. This makes it easier for us TrenchBroom users who like the Valve 220 format. Until TB gets patch support and brush primitives, it'll mostly stay this way.

Some other features I'd add to the compiler in the future include:

• writing vegetation data
• writing entity event data (a la Source I/O)

Crazy networking

Near the end of December, I found out idTech 3 supports multiple instances on a single machine, which is AMAZING for basic multiplayer testing. This way, I can ensure co-op and deathmatch work. Coming from GoldSRC, this feels like discovering alien technology.

Animation system in progress

So, I was quite... saddened... to find out that you can't just place a point entity in the map, assign a model to it and an animation number, and expect it to animate. On the other hand, I was relieved to find out that idTech 3's animation system is literally 3 variables: frame, oldframe and backlerp. This is on the client. On the serverside, it's only one: frame.
I decided to add a couple of variables:

float    framerate;        // framerate of the animation
byte    animation;        // ID of the animation to play
byte    animationFlags; // look at AnimationFlags enum above

animationFlags will be a nice way of telling the renderer "Hey, I wanna handle animation manually, i.e. I wish to increment frames on the server", or "Hey, I want this to be looped".
Right now, models will only support monolithic animations, but in the future, they will support up to 4 animation channels. For example, the torso plays one animation, and the legs play another.

What's left til v0.1?

Several things. First, I need to remove every single mention of gentity_t, since all code related to it is dead, i.e. won't ever be executed. It just makes compile times unnecessarily longer.
Second, I need to finish writing the entity classes. I still haven't written func_ladder, func_breakable, func_train and so on.
Third, I need to implement the animation system.

What's left for the (far) future?

A TON of things.

• a vegetation system so game entities aren't used
• rewrite almost the entire UI system (because my GOD, it's so inflexible)
• hitboxes (that's correct, there are no hitboxes in idTech 3)
• write a "GUI-in-world" solution that either renders to a texture (so it can be wrapped) or directly renders the polys in the world (significantly cheaper but only works on flat surfaces)
• a save system
• a subtitle system
• an optional day-night cycle that alternates between a number of external lightmaps
• projected light textures (think HL2 flashlight, GMod lamps)
• various sky additions (e.g. blending skyboxes, thunders etc.) etc.

Some of these will make it to 0.2, some will be in 0.3, some won't be until 0.5.
Right now, however, I'm working on a game demo with this. It will be in a different repository, once released, and various features will be ported.

Edit: SMH I should really make a blog somewhere