r/unrealtournament

Unreal Tournament 2004 is an undisputed classic. But graphically it's frozen in the era of Direct3D 8 and flat textures — the Fixed-Function Pipeline. I always wanted to see what the legendary Unreal Engine 2 could look like with proper normal maps and honest Blinn-Phong specular, something closer to Unreal Tournament 3.

1 - diffuse only, 2 - normal, 3 - Blinn-Phong specular

In the fan and modding community there are plenty of failed attempts to bolt normal maps onto UT2004, but it was always considered impossible — no source code, fundamental engine incompatibility with modern techniques, and the sheer complexity of low-level graphics development. Then AI and agentic coding tools changed the picture.

After OldUnreal released their patch moving the game to full 64-bit and adopting OpenGL 3.3 with broad compatibility across both vintage and modern hardware, I finally had a real foothold for the experiment.

There were a few obvious obstacles going in:

I don't know C++. Not its idioms, not its syntax — I can barely read someone else's C++ code, let alone write it.

I had no game source code. (Yes, leaks from Unreal Championship 2 and Unreal Warfare exist, but the codebase differs substantially from UT2004.)

Zero knowledge of the engine's internal architecture or its quirks.

On top of that, buying a Claude Code or Codex subscription wasn't an option. I ended up working with Gemini Flash through the command-line Antigravity CLI — the cost of entry being roughly $6/year.

Still, after three months of constant experimentation, reverse engineering, and hundreds of Access Violation crashes, I managed to write a native DLL renderer module — ENDrv.dll. Here's the story of how it was done: through Antigravity CLI, UE2 architecture hacks, a lot of patience, and more sleepless nights than I'd like to count.

---

Stage 1. Flying Blind: Reconstructing the VTable and Getting the First Frame

Any renderer for Unreal Engine 2 is an external dynamic library that must implement the engine's internal URenderDevice interface. In plain terms, the renderer DLL is the bridge between the game engine and the GPU. The engine communicates with the library through virtual function tables — VTables.

In C++, the order of functions in a VTable is critical down to the byte. If you're off by even four bytes on a single function's offset, instead of calling the frame-draw routine the game jumps into a random region of memory and crashes instantly.

[ UE2 Engine ]  --->  ( VTable: offset +0x18 )  --->  [ ENDrv.dll ]
                +--       Off by 4 bytes?       ---> CRASH (Access Violation)

The first two weeks were pure guesswork: running UT2004 binaries through a disassembler, studying the UC2 and Unreal Warfare source leaks, trying to work out which functions UT2004 expected and at exactly which offsets, rebuilding the library and launching the game every five to ten minutes, logging crashes, and nudging offsets based on the fault addresses.

The game launched for the first time to a solid black screen without crashing — only after I managed to correctly guess six of the key base functions out of 32 (at that point I could only confirm 14 functions with any confidence). No image yet, but the DLL was accepted by the engine. That was the first real breakthrough: not only did the game stop crashing, but you could hear it working — clicking through menus, launching a match "blind," and hearing bots run and shoot each other. It was alive.

The next few days went into establishing vertex streaming and getting any geometry to appear on screen in wireframe mode. The stub functions that were just returning True or Null had to become real implementations. Things were complicated further by the fact that the engine was designed around DirectX, while OpenGL has its own coordinate system conventions and state-management model. At first all I got was a mess of random lines, but after dozens of iterations the DLL finally produced a correct wireframe.

---

Stage 2. From Fixed-Function to GLSL: Materials, Combiners, and Static Lighting

The original UT2004 handled materials through the old GPU state machine — the Fixed-Function Pipeline with its Combiners, Shaders, and FinalBlends. Modern OpenGL 3.3 Core Profile has no fixed pipeline at all: everything has to be written in GLSL shaders.

About four to six weeks went into reconstructing material logic from scratch. The UC2 and Unreal Warfare sources were nearly useless here — worse than useless, actually, because the AI kept getting confused by them. At times I had to pipe every agent response through a second AI just to sanity-check the logic and catch hallucinations. Eventually I decided to ignore the foreign source code entirely and work everything out independently.

The hard part wasn't "just drawing a texture." The UE2 material system is a full node graph. A single UShader material can have separate slots for Diffuse, Opacity, Specular, SpecMask, SelfIllumination, and SelfIllumMask — each of which can itself be another material. The Diffuse slot might contain a UCombiner blending node that has Material1, Material2, and a Mask, each of which can in turn be another Combiner, a texture with animated UVs (TexPanner, TexRotator, TexScaler), or a cube map. All of that had to be unrolled into GLSL, which doesn't support recursion or dynamic loops from that era — only a linear graph with a fixed number of steps.

The solution was a "combiner register" system: before the main color calculation, the shader sequentially evaluates up to 32 nodes and stores the results in an array. Each node knows the indices of its inputs (a texture slot or another register), the blend operation (Multiply, Add, AlphaBlend, Modulate, etc.), and its mask. On top of that: 16 texture slots with independent UV transform matrices, cube map reflection support, projective textures (Projector), animated panoramas, and FinalBlend mode with alpha testing. Near the end of the texture work I found the 32-bit game source code — but it wasn't much help since the original was entirely tied to Direct3D 8 / Fixed-Function. It did help fix a couple of nasty logic bugs involving complex layered textures, alpha-channel materials, and depth buffer issues.

One example of a creative workaround: UTexture field offsets are unknown without source code, so the code locates them at runtime by scanning memory and checking logical conditions. Once found, they're cached permanently.

Post-processing was integrated in about a week after that with almost no friction, since screen-space effects (Depth of Field, Bloom, Chromatic Aberration) are fairly straightforward to write in GLSL and have little dependency on engine internals.

Bloom on Bio Rifle's globs

---

Stage 3. The Hardest Part: Normal Maps, BSP, and Optimization

UShader with specular and normal map on BSP geometry

The whole point of the project was proper PBR-style lighting and normal maps. And this turned out to be even harder than the original VTable guesswork.

For normal mapping to work, the renderer needs per-polygon tangent and bitangent vectors from the engine — and the engine simply doesn't provide them. Getting the effect into the shader was actually quick: screen-space derivatives (dFdx / dFdy) let you compute a tangent basis directly in the fragment shader, eliminating the need to change the game's vertex format. But the performance was catastrophic: a couple dozen meshes with normal maps in the frame would bring the game to its knees.

The core problem: all the static lighting in the game (there's almost no dynamic lighting at all) is baked into the level at build time — texture color and brightness are modulated by lightmap textures and per-vertex color. Roughly speaking, it's like applying a gradient to a texture in Photoshop's Multiply blending mode. The renderer doesn't "see" any light sources at all — it just draws textures onto polygons. But since the DLL is a native module running inside the game process, it has direct access to everything happening under the engine's hood: light sources can be found and their parameters read directly.

Recalculating every light source per pixel every frame for all geometry was too expensive — especially since the engine's architecture hard-limits it to a single CPU core. A deep caching strategy was necessary: all geometry preserves its original static lighting (lightmaps and vertex colors) baked by the map authors 25 years ago. The dynamic per-pixel GLSL calculation only handles the normal map delta and the Blinn-Phong specular highlight.

Final color = (Lightmap * Diffuse) + (NormalMap_Affect * DirectLight) + BlinnPhong_Specular

Where NormalMap_Affect isn't the full light value, but only the "uplift" from the surface relief — how much the normal direction deviates from flat geometry. The lightmap stays as the foundation: the 25-year-old author lighting doesn't go anywhere, it just gets a relief "cap" on top.

Even that wasn't enough for acceptable framerates: with a few hundred meshes carrying normal maps on a level, FPS would collapse to 10-20. The entire pipeline needed its own caching layer. In effect, on top of the already-baked static lighting, we additionally bake normal map data during the first few frames of a map load.

The BSP Problem

If caching for StaticMesh geometry came together relatively quickly, BSP wall surfaces fought back with everything they had. Unreal Engine 2's architecture slices BSP surfaces into dynamic nodes during the frame itself. The engine resisted caching at every turn: texture coordinates would drift, caches would invalidate every frame, and the normal map and specular effects would flicker in and out alongside a full zoo of visual artifacts — or an FPS collapse into single digits. I had to roll back to week-old backups several times and redesign the architecture from scratch. The problem was eventually solved by building a light-source state hash table and an array of 128 static-dynamic lighting slots directly in the shader, tied to the geometry streaming.

---

Just shipping the renderer upgrade wasn't enough without a proper visual showcase, so I ported two maps from UT3 to UT2004. Compared to building the renderer itself, this was a walk in the park. The UT3 maps were chosen deliberately: they have clean UV unwraps and high-quality next-gen normal maps — exactly what was needed for the demo. The BSP geometry, static meshes, their properties, and placement were ported in five to ten minutes with a couple of CLI prompts. The meshes were converted from pskx to ASE format using a 3ds Max script that the AI assembled in about five minutes, after reading the UModel documentation itself and extracting everything needed into a separate folder. Importing models and textures into UnrealED went the same way. The only thing that actually required real hands-on effort was assembling the shaders in the editor. Two evenings later there was a near-complete port of both maps. The goal was never full playability — just a great-looking screenshot — so missing lifts and scripted events will stay missing. If you're interested in the game and these maps, they're definitely finishable, and stripped-down versions without normal maps for the original renderer would be easy to put together.

---

In last version i add support for MSAA 2/4/8, Anisotropic filtering, settings for draw distance normal maps, restore emitters rendering, improve normal maps stability and quality.

Testing dual normal maps for water shader

Results

Three months of work. No C++ knowledge going in. No game source code. The result is ENDrv — a working OpenGL 3.3 renderer for Unreal Tournament 2004 that runs on original unmodified maps and brings proper surface lighting to a 22-year-old engine.

What it actually does:

- True per-pixel Blinn-Phong specular and normal mapping via screen-space derivatives — no vertex format changes, no engine modification required.

- Dual Normal Map support for convincing animated water surfaces.

- Post-processing pipeline: Depth of Field, Bloom, and Chromatic Aberration — Bloom works on many original maps with zero asset changes.

- Playable framerates on original content, thanks to a multi-level OpenGL state caching system and a hybrid lighting model that layers dynamic per-pixel calculation on top of the original baked lightmaps.

Modern AI in the hands of someone with a working understanding of 3D graphics, basic engine architecture, and a large enough reserve of stubbornness can compensate for a complete lack of knowledge of any specific programming language.

---

tl;dr: Spent three months reverse-engineering UT2004's renderer interface with no C++ knowledge and no source code, using an AI coding assistant ($6/year). The result is a working OpenGL 3.3 renderer with normal maps, Blinn-Phong specular, and post-processing effects that runs on original unmodified maps.

Mostly finished the work on the streaming UI for the AS One Day Cup happening this Saturday. This is mix of in-game and OBS browser source overlays enabled by a three part mod:

• A base mod that's installed on the server that collects game events and stats and delivers them to the client.
• Client-side mod that draws part of the UI and allows the third app - a custom Flask app to talk to the game and get the data. This mod draws the scoreboard and a list of objective with times (not shown here).
• Flask app besides working as a bridge to the game also hosts overlays for the OBS that work with all that data and a dashboard to update the browser source overlays and in-game scoreboard from another device on the local network. The team progress timelines and the event pop-ups are OBS overlays

Public release will hopefully happen later on, right now it's a bit messy due to tight timeline for the cup.

I know this might not be the best place to post it, but I didn't know where else to put this.

Anyway, after scouring the internet to find a scan of the original mousepad from the merch catalog (See picture 3 for reference) and coming up short, I decided to recreate it to the best of my abilities, and I believe it turned out alright.

I also thought why not just make a deskmat version too, since people mainly use that nowadays, and while it didn't end up as accurate as the standard one I am pretty satisfied with the final result.

All of this was only possible thanks to GamesHarder on the OldUnreal forums and their absolutely insane collection of Unreal media (including the original screenshot used on the mousepad). You can access the forum post to see it for yourself.

Alright, enough yapping, you can download the uncompressed mousepad and deskmat pictures here if you want to print your own Unreal mousepads, with 2x and 4x upscaled options for higher resolution prints.

Just as a side note, I'm not promoting myself, rather I'm just posting here in case anyone ever wanted to print their own custom Unreal mousepads.

For years since it came out I’ve loved the original Unreal and have pondered different things about it that seem mysterious. In particular, its first level, Vortex Rikers, where you wake up unequipped with 12% health in a cell of a crashed prison starship, has haunted me for years. Over the years a lot of things about the level have struck me as very odd and raising a lot of questions, starting just with the fact that the ship is very clearly smaller when you get out of it than it is when you’re in it, and there are things about the ship when you’re in it that suggest it’s even bigger than it actually turns to be from the outside.

The obvious easy answer to all of my questions about it, of course, is that it was 1998. The game’s creators and the audience weren’t thinking about this stuff that much because we were so enamored with this new game that had such cutting-edge fidelity and immersion for the time. Just the technical feats of the game engine (which the first level in particular was built to showcase different aspects of very early on) and how it was used to create a somewhat believable and immersive space was the point, and any logical limitations or holes in what was made with that toolkit were incidental, ignorable even. Besides, the game itself is called Unreal. It’s supposed to be wildly fantastical, even when it’s using different tricks to convey a place that would make some logical sense to exist on another planet.

And yet it is interesting and fun to speculate, and try to think of at least somewhat logical explanations for odd things in the game that, even within the frame of its own Unreality, are still not explained or elaborated on, and don’t seem to add up. I think of it along the lines of how, to name a popular example, the TV show Lost started with a simple premise of people surviving a plane crash on a seemingly normal island, and then the show went on to not only expand into so much more, but also later reveal several things that happened as a cause or effect of the crash, including things that turn out to have been happening around the crash site the entire time.

There are various little things about the design of the Vortex Rikers that are odd, such as the large vent you can walk through, the reflective “ice-skating” room with lockers and a suit of armor behind the easily deactivatable forcefield, the structure of the captain’s room, the computers from the far future that still have P1 monochrome screens and large floppy drives, and the one medical kit in a comparatively large room that you can only access by breaking the big glass window. Also, the premise of the Universal Translator is very odd for multiple reasons.

However, the first major odd thing that stands out about the level is that, even accounting for places on the ship presumed to exist that you just can’t access, the ship is pretty small, with seemingly just one cell block. You would think that a prison starship would be much bigger, even dystopianly giant and full of cell blocks to house many prisoners. And when you consider that you encounter not only several bodies throughout the ship but several more throughout the game of people who were implied (if not outright stated in translator messages) to have been aboard the Vortex Rikers, and then add to that the amount of screams you hear in the ship (which I’ll get into later), this is a small, cramped, and overcrowded prison ship. There are 12 cells in all, which with the two bunk beds in each cell suggests two people per cell, for a likely total of 24 prisoners. But this is Vortex Rikers, “the rankest prison vessel this side of the Milky Way”. It’s not hard to imagine that it’s a nightmarishly overcrowded place. One could imagine the prison putting in maybe four prisoners per cell and having two of them each share a bunk, or maybe even putting in more prisoners than that. Even so, it seems odd that there would be so little to this ship.

The most mysterious thing to me about the Vortex Rikers, however, is the screams. It’d be one thing if there were just a finite amount of screams that you heard, based on time passed or as triggered when you walk through a certain area (as some
indeed are). But these screams are frequent, recurring, and heard all throughout the ship from different directions, suggesting that there are still dozens, maybe hundreds of still-living people aboard the ship. Sometimes it sounds as though there are screams happening just behind a wall near you. And yet you only encounter the one Skaarj that runs away from you both times. It is as though most of the action is somehow taking place outside of the main areas of the ship that you’re going through. Why is that? How is that even possible?

You can more understand the screams with ISV-Kran because it’s a much larger and more complex ship. But with Vortex Rikers it just doesn’t seem to make much sense. I’ve thought of some possible explanations for the screams in Vortex Rikers.

-Not only are there crawlspaces where most living people aboard the ship are, but said crawlspaces are probably among the places (including apparently the escape shuttle room) accessible from one of the doors in the opening cellblock that you can’t get through. It seems likely that most of the ship’s inhabitants got through one of those doors (maybe before the crash) and most of the Skaarj got in there, and maybe closed the doors so the people couldn’t get out. It’s not clear how they would’ve done that, since the only clear opening in the ship is the one you climb out of. So could the Skaarj have gotten onboard through the same opening you exited the ship from, then gone into the main area behind the doors you can’t access, and then locked/blocked the doors off?

-Despite there seeming to only be one small ship, it’s possible there’s still more to the ship than you can see. For example, there may be another level to the ship that’s buried underground, and what you see of the ship from the outside is just the upper part that didn’t get buried. That wouldn’t necessarily explain why you seem to hear more from other angles than more below you, but it would be one piece of the puzzle.

-Maybe there are secretly teleportation gates on the edges of the ship that you can’t access and don’t even know about, and they lead to remote places. These remote places could be other sections of a total ship that broke off during the crash, and instead of being in the entire ship you are in just one of different sections that was previously connected by something like a starbridge. This could mean there is at least one other section of the Vortex Rikers somewhere on Na Pali.

-The Skaarj set up teleportation gates at the edges of the ship, which may lead to remote locations you can hear through said gates.

-There are not that many people screaming. It’s the same handful of people who are repeatedly screaming from crash injuries, being tortured but not killed by a Skaarj, or maybe just being slowly killed by crawlspace infestations of Skaarj-pupae eating them.

-You hear recurring periodic announcements from the ship computer. It would make sense that occasionally a person would want to record their own announcement depending on the situation and have that play over the speakers
periodically. So maybe the recording equipment was turned on inadvertently and captured screams, or maybe someone meant to record a message but wound up screaming instead, and what you’re hearing are repeated broadcasts of screams of people who are probably now already dead.

-The Skaarj secretly installed sound devices that would play screams to scare, mislead, and demoralize any survivors, to make them easier to kill or control.

-The prison system installed sound devices before the crash to scare, mislead, and demoralize prisoners in order to further punish them and make them easier to control, and these got turned on maybe accidentally and stayed on even after the crash.

-The ship is now haunted and you are hearing the screams of victims past. Unreal by its very title is fantastical with supernatural themes where you encounter ghost Nali and the like, so it’s not inconceivable that such an already nightmarish place of death and suffering would have screams of tormented souls in it. The Vortex Rivers was already hellish as a prison and now it has literally descended down into a place that for its inhabitants is an even greater hell, even if it seems to offer freedom from prison, so it makes sense that it would sound like hell.

-The player character is insane and at least a lot of the screams are hallucinations. That wouldn’t necessarily explain why you don’t hear the screams as much after you leave the ship. However, when you consider that the player is perhaps already an insane hardened criminal with a dark history who has waken up badly battered in a crashed, dilapidated, carnage-filled ship in an unknown destination with mysterious sights and sounds, it’s not inconceivable that they may have a brief psychological episode in which they hear things that aren’t necessarily there.

-The Vortex Rikers canonically really is much larger and more complex than it appears from the outside, and Epic were just sloppy about it or basically following old-school open-world RPG logic where distinct locations in the open world are depicted as tiny places that are not to-scale. This opens up the possibility that there is at least one other cell block on the ship, as well as the crawlspaces and the escape shuttle room. Maybe there’s canonically an entire giant part of the ship you can’t access, that is much larger than what you can.

Feel free to offer any theories, ha ha.

The OG 1999 Big Box…. the art on this is amazing. This was definitely one of the best PC games ever back in the day!

Hey all ! I finally finished remaking Malevolence in UT3, it was really fun to do !
Hope you'll like it and have fun
Download on Moddb
Video preview on Youtube

Recently physics engine Box3D was released and I thought it'd be cool to add ragdoll physics to older games. And I thought ut99 could benefit from that extra physical feel.

Disclaimer: using DeepSeek-v4-flash but please don't call out only AI Slop, I'm software engineer and this is my cool hobby idea. It would take me months to get to that stage without agentic coding.

For now, I'm using boxes, as it seems old Unreal didn't use skeletons but relied on keyframed animations. Next step is to extract the models and build proper skeletons.

Update 1: Work in progress on using real player models for ragdolls, currently you can see buggy work in progress on my account. I won't spam this subreddit with these dev progress, will post proper video when these bugs will be resolved

Here are two beautiful Egyptian themed Capture the Flag arenas for some variety. Both maps are very small but are well designed. There is a reason why I chose to share these today. More on that below. Screenshots are taken at my PCs full resolution of 1920x1080 enjoy.

<========>

Map Name => CTF-Immorality by <{Ui}>Ark

This arena is set in a small Egyptian tomb with a simple direct path to the enemy's flag and an upper indirect path. Both paths add variety to how you retrieve the enemy's flag. This arena has some nice Egyptian architecture which includes nicely designed doorways, wall cutouts, statures and well-chosen textures. This arena also has some trees, foliage and banners hanging from the walls and some nice lighting. There is also good verticality with the use of jump pads allowing you access to the upper area.

My overall score 3.5:5

Download => unrealarchive.org/unreal-tournament-2004/maps/capture-the-flag/I/ctf-immorality_d44107f1.html

<========>

Map Name => CTF-Templus2k4 + BR-Templus by Jos "Sjosz" Hendriks

This arena is set in a small Egyptian temple that is made up of one large room with four smaller rooms attached. There is only one main path between the enemy bases, but the large columns create cover. This map has some good Egyptian architecture which includes large columns, well placed statues, banners hanging from the ceilings, cartouches, well-chosen textures and good lighting. There are also some nice lighting effects coming from the skylights.

After looking through every Bombing Run map in the archive this is the only one that looked the prettiest and the best. That is why I decided to share it today.

My overall score 3.5:5

CTF Download => unrealarchive.org/unreal-tournament-2004/maps/capture-the-flag/T/ctf-templus2k4_5c4c3fed.html

BR Download => unrealarchive.org/unreal-tournament-2004/maps/bombing-run/T/br-templus_36c9a7b5.html

Also known as Old Haven this environment is set in a cozy costal town complete with a number of nicely designed buildings with decent architecture. This city is complete with differently designed buildings built using bricks, many windows and copious amount of trim. The streets are paved with cobblestones and ornamented with light poles, benches and some trees.

This town is also complete with a small dock that opens up to a nice bay area. Stretching out into the bay are many rock faces animated water and there is even a statue erected on one of the small islands. In the distance there are shrines fitted on top the surrounding cliffs overlooking the town. This environment also features some nice exploration which features some platforming while jumping from rooftop to rooftop. This would be a great map to add to one's collection.

Map Name => DM-AMDK-OldHaven

My overall score 4:5

Download => unrealarchive.org/unreal-tournament-2004/maps/deathmatch/A/dm-amdk-oldhaven_7afcedf1.html

Here are two subterranean environments by authors that I already showcased. Both maps are set somewhere underground and have light foliage and some atmosphere. Screenshots are taken at my PCs full resolution of 1920x1080 enjoy.

<========>

Map Name => DM-1on1-Amnidios by Mario "nELsOn" Marquardt

This arena is set somewhere underground and features brick walls, stone floors, metal pipes, wooden support beams and planks. There are also some crates, limited light sources and minimal foliage. This arena is basically two rooms attached via connecting tunnels and caves.

My overall score 3:5

Download => unrealarchive.org/unreal-tournament-2004/maps/1-on-1/A/dm-1on1-amnidios_d87b97bd.html

<========>

Map Name => DM-1on1-TK23 by Thomas "Kuckekind" Kuske

This arena is set in a cave structure underwater which features metal supports cables on the ground and windows looking out towards the deep ocean. There are minimal haze, light sources and foliage. There is also the UT shark like creatures swimming outside the windows. Because this map is set in an underground cave it has some good interconnectivity between the larger cave areas.

My overall score 3:5

Download => unrealarchive.org/unreal-tournament-2004/maps/1-on-1/T/dm-1on1-tk23_e0356c81.html