Is this actually a thing?

[kron]

I'm just curious how this currently plays or if anyone even plays it at all.
Will be home on vacation for a couple weeks with nothing to do, thought I'd pass the time with some mindless combos and raging, but the ut99 pug scene is dead rn.

[|uK|kenneth]

hollyyy shiet you still alive bro?
i miss your voice on ts man!

[Moskva]

Fu you

[kron]

yeah i'm alive son, thought my presence was needed
yall still play? is UT4 an actual thing or is it as shitty as mlut says it is

[UT-Sniper-SJA94]

Imagine the worst game ever made, it is worse than that.

Quite a lot of UT players have gone to Overwatch.

[|uK|B|aZe//.]

we still play siege come get rekt

[SAM]

UT4 is rubbish. I'm turning off the UT4 servers soon. Disappointing to say the least.

[TimTim]

Yeah UT4 got off to a solid start but eventually turned into a huge disappointment. The "dev team" obviously doesn't have a clue what they're doing. There's so much technical debt now that it would be better to start from scratch. I might pick up where I left off 2 years ago (before Epic decided to hop back on the UT train), porting UT99 to the web browser + updated graphics.

[Higor]

TimTim
How difficult would it be to replace Render.dll (and the individual renderers) with a single OpenGL/Vulkan interface that does a lot of usage of VBO's?
I always wanted to take up that kind of project within XC_Engine, but programming a whole new render interface is kind of... a big thing for me atm.

The good part is that it could be properly installed onto any UT99 game without a problem, provided the computer has the appropiate drivers.

- - - Updated - - -

I have profiled the rendering code in UT99 and there are a few things that can see changes:

- Vertex meshes are stored with their coordinates packed in single integers. x:11, y:11, z:10 (summing 32 bits), that also explains why Z coord is divided by 2 upon import.
When they're serialized off the package, they remain in memory with that format. A VTable hook could force unpacking of said coordinates and SSE instructions could process animation interpolation at greater speeds.
Optimizes nearly 3% of the render load.

- Lighting calculations are a whole clusterfuck, with light arrays cached in the BSP tree plus some funky actor lookup.
Finding lights and applying the changes onto meshes/surfaces is an expensive operation and the render interface uses a set of precached inverse angles (similar to SSE invsqrt's).
The lightmaps could be handled with shaders and the lights could be cached in a small table for quick change comparison, if something changes, lightmap is calculated again.
Optimizes nearly 20% of the render load.

- Polygons handling, in software rendering they're sorted further to nearest because it cannot do Z filtering, but new renderers don't need that.
Also, polygons don't need to be passed at once, mesh animations don't need to be cached in RAM memory, but video memory as well.
So unifying the Render interface with the renderer and directly handling meshes as VBO's could take care of at least 60% of the video load.

And then we can hack in some more UE2/3 render stuff if possible.

- - - Updated - - -

Problems:
I don't have the UE1 skeletal mesh rendering code, some reverse engineery would be necessary on that.
The BSP tree could be turned into a static mesh for rendering purposes, the moving brushes would need to be taken out of the equation (as they're dynamically mixed into the main BSP tree)
VBO's aren't multi-effect, so translucent/modulated effects would need extra handling.
Reject checks on actors/zones would need to be rewritten if possible.

[TimTim]

TimTim
How difficult would it be to replace Render.dll (and the individual renderers) with a single OpenGL/Vulkan interface that does a lot of usage of VBO's?
I always wanted to take up that kind of project within XC_Engine, but programming a whole new render interface is kind of... a big thing for me atm.

The good part is that it could be properly installed onto any UT99 game without a problem, provided the computer has the appropiate drivers.
My brother showed me a "new" renderer for Unreal Gold (227) years ago. It's probably been over 5 years now. I remember it looked amazing at the time when considering the fact that it was all the same textures and maps while the renderer improved the lighting and added some special tessellation (I think that's what it was called) to textures to make them pop - e.g., instead of flat brick textures, the lighting would make the bricks appear to stick out a bit like real ones. You probably already know what I'm talking about. The 227 guys at OldUnreal certainly do. With that said, I'm not sure if working on a 16+ year old engine just to improve graphics for UT99 would be worth the effort at this point in time. I would like to port everything to a newer engine (probably UE4 as it is sadly the best option right now) and start from there. I like knowing that those graphics upgrades were possible with 227 though.

[Higor]

You'd still need to write native packages in UE4 to:
- Load and execute unrealscript.
- Load vertex meshes and textures (unless all the content is ported).
- Load the maps.

[TimTim]

Also, I'll add that if I do ever get around to doing a port to UE4, I would probably write a converter for UnrealScript to Unreal.js (JavaScript) and use that as the base for everything, since UE4 doesn't officially support UnrealScript. JavaScript/Unreal.js is surprisingly close enough to UnrealScript that I think it would be feasible. It would also allow us to quickly reuse/repurpose all existing code/mods/etc., with some improvements of course, especially since JS is infinitely more flexible than UScript.

- - - Updated - - -

Earlier this year I had successfully tested Unreal.js. It works beautifully.

https://github.com/ncsoft/Unreal.js

[SogeKing]

Damn son, The Kron Dog