◄►469 Patch Discussions◄►

[Raynor]

I'm curious can someone explain following OpenGL renderer options in 469b?

ShaderType=SHADER_ARB
UseDrawGouraud469=True
ShaderAlphaHUD=False
UseHDTextures=True (replaces UseS3TC ?)
UseSamplerObjects=False

[OjitroC]

Isn't "too dark" supposed to be an issue with the Direct3D drivers instead? Weird.

It looks alright to me, though. This might sound like a dumb suggestion, but did you check the Brightness option? I remember them doing nothing in v436 for me, only for them to suddenly work again in v469, and me having to adjust it. Or something like that, I don't remember very well. Weird.

Solved it - just set UseShaderGamma=False and it looks fine.

[1337GameDev]

OK... let's then talk about function replacement for a moment.

First off, if there are problems with existing UScript functions, rather than a new function to replace these functions, why not simply fix those functions directly at the source as part of a new patch?
UScript is open for anyone to make changes and submit pull requests to make them into the patch, no one is stopping you from doing it.

Secondly, that's a fairly dangerous feature to have in general, and I am not sure if a patch should actually have that kind of thing in the first place (not up to me to decide, just my opinion).
Replacing any function directly by your own is something that should not actually be allowed at all, as that amounts pretty much to hacking, and it would be abused to no end if it was part of the base game.

Thirdly, the introduction of new native functions is not something that can be easily made available in future patches, and that's because new patches must be compatible with previous versions of the game, down to 436 (the last official version), thus if they introduce new functionality like that, and if something uses it, their stuff will not work in previous versions of the game, as it will downright crash.

It's a gray area on whether mods only compatible with new game versions is something Epic would allow or not, even if the base patch was itself compatible, but just in case, even new functions which were introduced in 469a are not really allowed to be used by mods for now (Anthrax makes an automatic check for those during compilation, to make sure no one uses them).

For this I have personally written a fairly complete technical specification on how this problem could maybe be solved a long while ago (long before the patch was publicly released), in such a way that new native functionality could be introduced without crashing previous versions of the game, including new functions, properties, etc.

This spec is not something available to the public for now, as it's not known yet if it will ever be pursued at all, since it involves some modifications in the UScript compiler itself and would need to be very well tested to make sure the engine performance stays about the same for new features like this.

Considering that the focus for now in 469 is bug fixing and performance improvements, new features are hardly a priority for now, so it's very likely you won't see anything like that for now, maybe ever, so if you want anything fixed, you have better chances by fixing it directly (my first point).

Furthermore, function replacement is a functionality that XC_Engine provides already, which you likely already know, so you can use that already instead if you want, as long as those replacements are server-side, which seems to be your major concern to begin with.

Why do we care about previous versions of the game....

Just indicate a version mismatch, and indicate a new version is available if somebody mistakingly uses mods with newer functions / joins a newer server, etc....? A lot of mods, maps, etc can easily do a game version check, and just halt execution if trying to be ran on an older game version....

Why does it need to be backwards compatible with v436? Why would epic care about mods, maps, assets, servers, etc not working with an OLD version? Then what's the point of a patch, if not to improve the game as a whole for EVERYBODY?

This mindset really upsets me, and I feel it'll really limit what improvements can be made... for a IMHO very silly ideal....
If epic simply doesn't want to deal with hosting / pushing out a patch to steam, gog, etc... then ok? That's part of game distribution and should be pretty easy for them and they shouldn't be selling the game, if they won't simply push out a patch co-worked on by a community.

[1337GameDev]

I'm curious can someone explain following OpenGL renderer options in 469b?

ShaderType=SHADER_ARB
UseDrawGouraud469=True
ShaderAlphaHUD=False
UseHDTextures=True (replaces UseS3TC ?)
UseSamplerObjects=False

I'm kind of curious on these too... Are older options deprecated? (eg: UseS3TC)

[sektor2111]

Why do we care about previous versions of the game....
...
Why does it need to be backwards compatible with v436? Why would epic care about mods, maps, assets, servers, etc not working with an OLD version? Then what's the point of a patch, if not to improve the game as a whole for EVERYBODY?

Huh ? After double posting I don't get the point.
First of all I see expected 469c because 469b it looks like still has problems - it's not what people were expecting in term of IMPROVEMENTS - and as result not all admins will update it too soon - browse UT servers and see yourself. UNTIL this patched version will run solid as rock and being widely tested I think it's normal to be an UT map or mod and nothing else. If 469 it looks like an experiment with adds that need fixed why things would be mandatory for it ?
If you don't like UE1, use UE4 or anything else, UT it's not a must after all, you can stick even with 227.

Note: I worked on some map in 469 and suddenly machine was rebooted - or doing another funky stuff, not a single time in these 469 versions - never happening in 436/440. Why would I lose my work that way ? Are you even editing/working at maps ? When such a reboot occurs nothing is being printed in logs because all tasks are canceled. This way there are chances to screw files on drive. Honestly I don't dare to start working on a special map using that Editor - why would I do it mandatory for 469 which is still running here and there and NOT EVERYWHERE ? Any logic here ?
Purpose was fixing UT and making all mods and maps to work fine in this patch - feel free to write yourself anything else running only special maps and... wait users... Me one I'll compile everything in 436 - I don't want to crash games calling functions which UT doesn't have. I'm using 469 for a temporary lab work for debugging purpose not for final work.

[OjitroC]

Why does it need to be backwards compatible with v436? Why would epic care about mods, maps, assets, servers, etc not working with an OLD version? Then what's the point of a patch, if not to improve the game as a whole for EVERYBODY?

Surely improving the game for everybody means ensuring that 469b is backwards compatible? If 'things' made with 469 are not compatible with 436/440/451 this will mean that some people lose out. There is no compulsion to update to 469b, some people may not be able to do so (because of 'old' machines or OS), some people may not choose to (just as some people continue to use the original renderers despite newer, better versions being available). The likely trajectory of the UT99 user base is downwards, rather than upwards, over time, so why accelerate that inevitable decline by alienating part of that user base?

Note: I worked on some map in 469 and suddenly machine was rebooted - or doing another funky stuff, not a single time in these 469 versions - never happening in 436/440. Why would I lose my work that way

As anth has noted in another context, a UT crash should not result in a system crash and reboot - so, in order to help everyone, you really should report that as an issue.

[1337GameDev]

Why do we care about previous versions of the game....
...
Why does it need to be backwards compatible with v436? Why would epic care about mods, maps, assets, servers, etc not working with an OLD version? Then what's the point of a patch, if not to improve the game as a whole for EVERYBODY?

Huh ? After double posting I don't get the point.
First of all I see expected 469c because 469b it looks like still has problems - it's not what people were expecting in term of IMPROVEMENTS - and as result not all admins will update it too soon - browse UT servers and see yourself. UNTIL this patched version will run solid as rock and being widely tested I think it's normal to be an UT map or mod and nothing else. If 469 it looks like an experiment with adds that need fixed why things would be mandatory for it ?
If you don't like UE1, use UE4 or anything else, UT it's not a must after all, you can stick even with 227.

Note: I worked on some map in 469 and suddenly machine was rebooted - or doing another funky stuff, not a single time in these 469 versions - never happening in 436/440. Why would I lose my work that way ? Are you even editing/working at maps ? When such a reboot occurs nothing is being printed in logs because all tasks are canceled. This way there are chances to screw files on drive. Honestly I don't dare to start working on a special map using that Editor - why would I do it mandatory for 469 which is still running here and there and NOT EVERYWHERE ? Any logic here ?
Purpose was fixing UT and making all mods and maps to work fine in this patch - feel free to write yourself anything else running only special maps and... wait users... Me one I'll compile everything in 436 - I don't want to crash games calling functions which UT doesn't have. I'm using 469 for a temporary lab work for debugging purpose not for final work.

If it's an experiment....

Why do we want it to be backwards compatible?

If you're saying it's not ready yet... Why do we want backwards compatibility?

And when the patch actually gets finalized, why not make it the "mandatory" version of you want the latest? Obviously you can use an older version, but it won't play nice with the newest. That's generally how software works.

And miss out?

When the patch is final... Then who will miss out? They'll update. If they don't like the patch, they can stay on their old version, using their same stuff.

I use 469a for my daily build environment and develop daily. I usually build via ucc asked only open UED for minor dev map edits, but I run the game vis command line parameters daily. Never had any stability issues.

And I run it on a VM... On multiple MacBooks... So it works fine for me. Only bug I see is the UED browser window is all white and unusable on UED initial opening until I close the browser and reopen it.

=MERGED=

Why does it need to be backwards compatible with v436? Why would epic care about mods, maps, assets, servers, etc not working with an OLD version? Then what's the point of a patch, if not to improve the game as a whole for EVERYBODY?

Surely improving the game for everybody means ensuring that 469b is backwards compatible? If 'things' made with 469 are not compatible with 436/440/451 this will mean that some people lose out. There is no compulsion to update to 469b, some people may not be able to do so (because of 'old' machines or OS), some people may not choose to (just as some people continue to use the original renderers despite newer, better versions being available). The likely trajectory of the UT99 user base is downwards, rather than upwards, over time, so why accelerate that inevitable decline by alienating part of that user base?

Note: I worked on some map in 469 and suddenly machine was rebooted - or doing another funky stuff, not a single time in these 469 versions - never happening in 436/440. Why would I lose my work that way

As anth has noted in another context, a UT crash should not result in a system crash and reboot - so, in order to help everyone, you really should report that as an issue.

The part about older OS hardware and such is a good one, eg older servers.

What are the demographics on that? Is that ACTUALLY a huge concern? (Recently did that calculation for a site to determine if IE 11 was worth polyfilling for and found it wasn't). I understand the concern, but curious if it's realized in any meaningful manner.

[1337GameDev]

Why does it need to be backwards compatible with v436? Why would epic care about mods, maps, assets, servers, etc not working with an OLD version? Then what's the point of a patch, if not to improve the game as a whole for EVERYBODY?

Surely improving the game for everybody means ensuring that 469b is backwards compatible? If 'things' made with 469 are not compatible with 436/440/451 this will mean that some people lose out. There is no compulsion to update to 469b, some people may not be able to do so (because of 'old' machines or OS), some people may not choose to (just as some people continue to use the original renderers despite newer, better versions being available). The likely trajectory of the UT99 user base is downwards, rather than upwards, over time, so why accelerate that inevitable decline by alienating part of that user base?

Note: I worked on some map in 469 and suddenly machine was rebooted - or doing another funky stuff, not a single time in these 469 versions - never happening in 436/440. Why would I lose my work that way

As anth has noted in another context, a UT crash should not result in a system crash and reboot - so, in order to help everyone, you really should report that as an issue.

The part about older OS hardware and such is a good one, eg older servers.

What are the demographics on that? Is that ACTUALLY a huge concern? (Recently did that calculation for a site to determine if IE 11 was worth polyfilling for and found it wasn't). I understand the concern, but curious if it's realized in any meaningful manner.

[Feralidragon]

I'm curious can someone explain following OpenGL renderer options in 469b?

ShaderType=SHADER_ARB
UseDrawGouraud469=True
ShaderAlphaHUD=False
UseHDTextures=True (replaces UseS3TC ?)
UseSamplerObjects=False

ShaderAlphaHUD: It makes translucent HUD elements to be rendered using alpha blending instead of actual translucency, which results in HUD elements being visible against white backgrounds.

It's false by default since this is experimental, simply because "HUD elements" is the canvas, and the canvas is not used only for HUD elements, and can also be used for all sorts of effects which the translucent effect is intended, so this is pretty much a "hack" which personally I have a big problem with, since it's a big turn off for new mods to be developed (mini rant: I already had to deal with BS like this in the form of ZRangeHack in UTGLR renderers in NW3, never again).

Ideally, in the future, it's best to do what was done with the sniper scope: redo/edit the HUD textures with alpha already applied to them, and import them from PNG, and then have the game render them "naturally", and that way these settings can disappear.

UseHDTextures: Yes, it replaces UseS3TC.


As for the others, I have an idea of what they do, but I prefer to not really say anything because I am not 100% sure.
I will link this to Higor so he can explain the others.

Why do we care about previous versions of the game....

Just indicate a version mismatch, and indicate a new version is available if somebody mistakingly uses mods with newer functions / joins a newer server, etc....? A lot of mods, maps, etc can easily do a game version check, and just halt execution if trying to be ran on an older game version....

Why does it need to be backwards compatible with v436? Why would epic care about mods, maps, assets, servers, etc not working with an OLD version? Then what's the point of a patch, if not to improve the game as a whole for EVERYBODY?

This mindset really upsets me, and I feel it'll really limit what improvements can be made... for a IMHO very silly ideal....
If epic simply doesn't want to deal with hosting / pushing out a patch to steam, gog, etc... then ok? That's part of game distribution and should be pretty easy for them and they shouldn't be selling the game, if they won't simply push out a patch co-worked on by a community.

The first and strongest reason right now is because that was the deal struck with Epic, meaning that new patches have to be network compatible with previous versions of the game.
This means that a 436 client must be able to join a 469 server without any issues.

The second reason is that UT99 only has a community nowadays because of the sheer amount of content there is.
Without the content made by the community this game would have been completely dead and buried 5 years later post-launch.
Therefore new patches ought to keep things compatible as much as possible, to keep that content playable with minimal issues, otherwise you loose what makes this game stand out 20 years later, and with that you loose the game itself and the community surrounding it.

The third reason is that UT99 as a game is pretty much now connected to life support.
The community is already highly fragmented by clans, smaller communities, communication channels (discord vs forums, for example), and so on, which means that although the game has a reasonable amount of players for a 20-year old game in total, that player pool is actually highly fragmented to a point that when 1 or 2 players leave the game from one of those groups, the rest of the group follows and you loose 10's of players at a time as a result, and the game is not getting any new players to compensate for that loss.

As such, if a new patch is distributed that requires the clients to update in order to connect to a server, that server will never actually get almost any players, especially considering that the patch, at least for the time being, cannot be distributed in the actual official channels such as Steam and GoG, and even EGS, so the vast majority of the players still playing the game will likely remain at 436 for a very long time, possibly leaving the game entirely before even considering updating it.

Having that said, there are things which have been broken from one version to another.
Namely, the renderer interfaces are different in 469, since 469 now draws mesh triangles as a batch, instead of drawing them one at a time, which boosted rendering performance massively (to the point I made a video showing NW3 at max settings without any lag whatsoever, something not possible before 469), meaning that working renderers for 436 no longer work for 469.

The same goes for most or all native packages, like ACE and XC_Engine, that's why they need to be updated in every 469 release, as you may have noticed.
So there are indeed things that break from one version to another, exactly to improve them to the point they need to be improved, but they are all made in such a way that network compatibility is kept, as well having most of the existing content working.

And lastly, I have also mentioned a few times that I already wrote a technical specification as a proposal to be able to introduce new features in new versions in such a way that network compatibility would be kept.
I won't indulge in the details about it, but it essentially boils down to a new UScript-side feature of flagging new functions as having been introduced at a specific version, and which can only be called/used in those versions.
This means that you as a developer could then indeed check the game version and do things in one way or another, or even establish that your mod only works starting at a specific version, without crashing an older client version.

But it's just a possible way to do it, which would require some work in the compiler itself, considerations in the replication, and some other details which aren't currently the focus of the patch, so it's something likely to only be revisited much later, once the new patches become more stable overall.
No point in bringing new major features without fixing the base game to the point it needs to be fixed first.

[Higor]

I'm curious can someone explain following OpenGL renderer options in 469b?

ShaderType=SHADER_ARB
UseDrawGouraud469=True
ShaderAlphaHUD=False
UseHDTextures=True (replaces UseS3TC ?)
UseSamplerObjects=False

ShaderType
- SHADER_None: use legacy OpenGL rendering, limited to 4 texture mapping units and render pass control for detail, fog.
- SHADER_ARB: use ARB vertex+fragment program, single pass rendering with internal brightness/gamma control (plus other programmable features).
(GLSL mode planned for future)

ShaderAlphaHUD
- Turns translucent tiles drawn by canvas into a (somewhat) premultiplied alpha blended version.
* Only active when in SHADER_ARB mode.
* This feature puts additional processing in the GPU, may impact framerate in older GPU's.

UseHDTextures
- Use a texture's compressed 'image' (supported compression formats: S3TC, RGTC, BPTC)
* UnrealEd now gives mappers an easy way to load high definition images onto textures.
* See source for SniperRifle for the import/merge commands.

UseDrawGouraud469
- Use the newly implemented DrawGouraudTriangles interface to draw meshes.
* Slightly faster on slower CPU's due to not applying some software level checks/clippings to the polygons.

UseSamplerObjects
- Let OpenGL's sampler objects control texture filtering.
* Experimental feature, doesn't work too well on some GPU drivers.

Additionally...

ShaderMasking
- Let the shader control texture masking.
* Only active when in SHADER_ARB mode.
* This setting is required to apply anti-aliasing to masked textures' pixels.

UseLightmapAtlas
- Tell the game's render interface that the render device wants to pack the level's static lightmaps into atlas textures.
* Huge performance boosts on complex levels, the more surfaces drawn the better the % in framerate gain (compared to not using this).

[Chamberly]

Making it backward compatible back to 436 is an important move because 436 is still an Epic's official patch release while 469 is the unofficial Epic patch release. Something that you would've think if the company approves or not. And if it's only 469, not everyone is going to move up to 469 because of so many other reasons that anyone can come up with. That's why it's still in progress, even 470 is going to be backward compatible.

Compatibility is actually a big thing. I'll let that stink in, because everyone deserve their share of fun of playing the game.

[1337GameDev]

I'm curious can someone explain following OpenGL renderer options in 469b?

ShaderType=SHADER_ARB
UseDrawGouraud469=True
ShaderAlphaHUD=False
UseHDTextures=True (replaces UseS3TC ?)
UseSamplerObjects=False

ShaderAlphaHUD: It makes translucent HUD elements to be rendered using alpha blending instead of actual translucency, which results in HUD elements being visible against white backgrounds.

It's false by default since this is experimental, simply because "HUD elements" is the canvas, and the canvas is not used only for HUD elements, and can also be used for all sorts of effects which the translucent effect is intended, so this is pretty much a "hack" which personally I have a big problem with, since it's a big turn off for new mods to be developed (mini rant: I already had to deal with BS like this in the form of ZRangeHack in UTGLR renderers in NW3, never again).

Ideally, in the future, it's best to do what was done with the sniper scope: redo/edit the HUD textures with alpha already applied to them, and import them from PNG, and then have the game render them "naturally", and that way these settings can disappear.

UseHDTextures: Yes, it replaces UseS3TC.


As for the others, I have an idea of what they do, but I prefer to not really say anything because I am not 100% sure.
I will link this to Higor so he can explain the others.

Why do we care about previous versions of the game....

Just indicate a version mismatch, and indicate a new version is available if somebody mistakingly uses mods with newer functions / joins a newer server, etc....? A lot of mods, maps, etc can easily do a game version check, and just halt execution if trying to be ran on an older game version....

Why does it need to be backwards compatible with v436? Why would epic care about mods, maps, assets, servers, etc not working with an OLD version? Then what's the point of a patch, if not to improve the game as a whole for EVERYBODY?

This mindset really upsets me, and I feel it'll really limit what improvements can be made... for a IMHO very silly ideal....
If epic simply doesn't want to deal with hosting / pushing out a patch to steam, gog, etc... then ok? That's part of game distribution and should be pretty easy for them and they shouldn't be selling the game, if they won't simply push out a patch co-worked on by a community.

The first and strongest reason right now is because that was the deal struck with Epic, meaning that new patches have to be network compatible with previous versions of the game.
This means that a 436 client must be able to join a 469 server without any issues.

The second reason is that UT99 only has a community nowadays because of the sheer amount of content there is.
Without the content made by the community this game would have been completely dead and buried 5 years later post-launch.
Therefore new patches ought to keep things compatible as much as possible, to keep that content playable with minimal issues, otherwise you loose what makes this game stand out 20 years later, and with that you loose the game itself and the community surrounding it.

The third reason is that UT99 as a game is pretty much now connected to life support.
The community is already highly fragmented by clans, smaller communities, communication channels (discord vs forums, for example), and so on, which means that although the game has a reasonable amount of players for a 20-year old game in total, that player pool is actually highly fragmented to a point that when 1 or 2 players leave the game from one of those groups, the rest of the group follows and you loose 10's of players at a time as a result, and the game is not getting any new players to compensate for that loss.

As such, if a new patch is distributed that requires the clients to update in order to connect to a server, that server will never actually get almost any players, especially considering that the patch, at least for the time being, cannot be distributed in the actual official channels such as Steam and GoG, and even EGS, so the vast majority of the players still playing the game will likely remain at 436 for a very long time, possibly leaving the game entirely before even considering updating it.

Having that said, there are things which have been broken from one version to another.
Namely, the renderer interfaces are different in 469, since 469 now draws mesh triangles as a batch, instead of drawing them one at a time, which boosted rendering performance massively (to the point I made a video showing NW3 at max settings without any lag whatsoever, something not possible before 469), meaning that working renderers for 436 no longer work for 469.

The same goes for most or all native packages, like ACE and XC_Engine, that's why they need to be updated in every 469 release, as you may have noticed.
So there are indeed things that break from one version to another, exactly to improve them to the point they need to be improved, but they are all made in such a way that network compatibility is kept, as well having most of the existing content working.

And lastly, I have also mentioned a few times that I already wrote a technical specification as a proposal to be able to introduce new features in new versions in such a way that network compatibility would be kept.
I won't indulge in the details about it, but it essentially boils down to a new UScript-side feature of flagging new functions as having been introduced at a specific version, and which can only be called/used in those versions.
This means that you as a developer could then indeed check the game version and do things in one way or another, or even establish that your mod only works starting at a specific version, without crashing an older client version.

But it's just a possible way to do it, which would require some work in the compiler itself, considerations in the replication, and some other details which aren't currently the focus of the patch, so it's something likely to only be revisited much later, once the new patches become more stable overall.
No point in bringing new major features without fixing the base game to the point it needs to be fixed first.

You explained my concerns perfectly. Thanks for the well thought out reply. I appreciate it.

Makes much more sense thinking in terms of content, fractured groups, and the idea of internal changes made that are not back compatible.

I'm curious, why were triangles not batched before? Was that simply not supported by earlier cards and cards relevant to the game during it's life?

[Raynor]

Big thanks to Higor and Feralidragon for the explanation

[Gustavo6046]

OpenGLDrv.so's UOpenGLRenderDevice::DrawComplexSurface(FSceneNode*, FSurfaceInfo&, FSurfaceFacet&) seems to segfault with the Intel driver (i915), which it didn't before; I suspect it's a configuration issue, but I simply set ShaderType to SHADER_ARB, then I set it back to SHADER_None and it still didn't fix it!

It does work with the Nouveau backend (switched by setting the environment vairable DRI_PRIME=1 prior to starting the game), but I'd rather it run on the iGPU. It was working so well before... :<

Code: Select all

Developer Backtrace:
[ 1]  Core.so(_Z12HandleSignali+0x20b) [0xf79746cb]
[ 2]  linux-gate.so.1(__kernel_sigreturn+0) [0xf7f3f560]
[ 3]  /usr/lib32/dri/i965_dri.so(+0x366d74) [0xf5815d74]
[ 4]  /usr/lib32/dri/i965_dri.so(+0xabac7) [0xf555aac7]
[ 5]  /usr/lib32/dri/i965_dri.so(+0x237fa2) [0xf56e6fa2]
[ 6]  OpenGLDrv.so(_ZN19UOpenGLRenderDevice18DrawComplexSurfaceEP10FSceneNodeR12FSurfaceInfoR13FSurfaceFacet+0xb09) [0xdfef7b39]
[ 7]  Render.so(_ZN7URender9DrawFrameEP10FSceneNode+0x132a) [0xe15c401a]
[ 8]  Render.so(_ZN7URender9DrawWorldEP10FSceneNode+0x351) [0xe15c6161]
[ 9]  Engine.so(_ZN11UGameEngine4DrawEP9UViewportiPhPi+0x972) [0xf7c6de72]
[10]  SDLDrv.so(_ZN12USDLViewport7RepaintEi+0x93) [0xf2dd3c83]
[11]  SDLDrv.so(_ZN10USDLClient4TickEv+0x1a6) [0xf2dccf06]
[12]  Engine.so(_ZN11UGameEngine4TickEf+0x19a6) [0xf7c72466]
[13]  XC_Engine.so(_ZN14UXC_GameEngine4TickEf+0xa2) [0xf17bbfc2]
[14]  ./ut-bin(main+0x1018) [0x804eb08]
[15]  /usr/lib32/libc.so.6(__libc_start_main+0xed) [0xf72f1a0d]
[16]  ./ut-bin() [0x804d84f]
Signal: SIGSEGV [segmentation fault]
Aborting.

Signal: SIGSEGV [segmentation fault]

History: UOpenGLRenderDevice::DrawComplexSurface <- URender::DrawFrame <- URender::DrawWorld <- UGameEngine::Draw <- USDLViewport::Repaint <- USDLClient::Tick <- ClientTick <- UGameEngine::Tick <- UXC_GameEngine::Tick <- UpdateWorld <- MainLoopIteration <- MainLoop <- main

note: I don't know the source code, I just demangled the C++ symbol "_ZN19UOpenGLRenderDevice18DrawComplexSurfaceEP10FSceneNodeR12FSurfaceInfoR13FSurfaceFacet".

[Feralidragon]

OpenGLDrv.so's UOpenGLRenderDevice::DrawComplexSurface(FSceneNode*, FSurfaceInfo&, FSurfaceFacet&) seems to segfault with the Intel driver (i915), which it didn't before; I suspect it's a configuration issue, but I simply set ShaderType to SHADER_ARB, then I set it back to SHADER_None and it still didn't fix it!

It does work with the Nouveau backend (switched by setting the environment vairable DRI_PRIME=1 prior to starting the game), but I'd rather it run on the iGPU. It was working so well before... :<

Code: Select all

Developer Backtrace:
[ 1]  Core.so(_Z12HandleSignali+0x20b) [0xf79746cb]
[ 2]  linux-gate.so.1(__kernel_sigreturn+0) [0xf7f3f560]
[ 3]  /usr/lib32/dri/i965_dri.so(+0x366d74) [0xf5815d74]
[ 4]  /usr/lib32/dri/i965_dri.so(+0xabac7) [0xf555aac7]
[ 5]  /usr/lib32/dri/i965_dri.so(+0x237fa2) [0xf56e6fa2]
[ 6]  OpenGLDrv.so(_ZN19UOpenGLRenderDevice18DrawComplexSurfaceEP10FSceneNodeR12FSurfaceInfoR13FSurfaceFacet+0xb09) [0xdfef7b39]
[ 7]  Render.so(_ZN7URender9DrawFrameEP10FSceneNode+0x132a) [0xe15c401a]
[ 8]  Render.so(_ZN7URender9DrawWorldEP10FSceneNode+0x351) [0xe15c6161]
[ 9]  Engine.so(_ZN11UGameEngine4DrawEP9UViewportiPhPi+0x972) [0xf7c6de72]
[10]  SDLDrv.so(_ZN12USDLViewport7RepaintEi+0x93) [0xf2dd3c83]
[11]  SDLDrv.so(_ZN10USDLClient4TickEv+0x1a6) [0xf2dccf06]
[12]  Engine.so(_ZN11UGameEngine4TickEf+0x19a6) [0xf7c72466]
[13]  XC_Engine.so(_ZN14UXC_GameEngine4TickEf+0xa2) [0xf17bbfc2]
[14]  ./ut-bin(main+0x1018) [0x804eb08]
[15]  /usr/lib32/libc.so.6(__libc_start_main+0xed) [0xf72f1a0d]
[16]  ./ut-bin() [0x804d84f]
Signal: SIGSEGV [segmentation fault]
Aborting.

Signal: SIGSEGV [segmentation fault]

History: UOpenGLRenderDevice::DrawComplexSurface <- URender::DrawFrame <- URender::DrawWorld <- UGameEngine::Draw <- USDLViewport::Repaint <- USDLClient::Tick <- ClientTick <- UGameEngine::Tick <- UXC_GameEngine::Tick <- UpdateWorld <- MainLoopIteration <- MainLoop <- main

note: I don't know the source code, I just demangled the C++ symbol "_ZN19UOpenGLRenderDevice18DrawComplexSurfaceEP10FSceneNodeR12FSurfaceInfoR13FSurfaceFacet".

There was a confirmed problem concerning one of the renderers using Shader 2.0 in 469b, and integrated GPUs not really supporting it.
But I think that was already fixed in the latest snapshot, but I am not entirely sure (feel free to report that in github, or the OldUnreal discord).

I'm curious, why were triangles not batched before? Was that simply not supported by earlier cards and cards relevant to the game during it's life?

This is something that can be better clarified perhaps by Anth himself.

But my own take at it, is the fact that the main renderer is SoftDrv, in other words, a software renderer that is capable of only working using the CPU (no GPU involved at all).
And it works this way as well (batching polys in SoftDrv won't really give you much gain).

And at the time OpenGL was still in its infancy, and although included it never really worked well, and they only had pretty much D3D7 as one of the main and tested hardware renderers, and graphic cards weren't really a thing yet back then, like they are nowadays.
So it seems to me that they simply replicated what they had done in SoftDrv to the hardware renderers, and it just worked fairly well over time, and it was easy to implement.

So there was no big reason at the time to really batch anything, there were no particular noticeable gains as far as I know doing that back then, especially in a game with such a small amount of polys being rendered overall.
I mean, even working like this, it was still one of the best and fastest engines around at the time.

However, as the years passed, GPUs became much more powerful and also much more autonomous (being even able to store everything in their own memory, and to the point they have their own programmable instructions: shaders).
All of a sudden, even the bus speed of AGP wasn't fast enough and adequate anymore and PCI Express had to created.
So it wasn't until much later on that this type of bottleneck was actually noticeable, especially when mods and maps started to have higher poly meshes and models.

Even nowadays you won't really notice the difference in performance if all you play is the vanilla game.
You will only notice a difference if you use mods that actually take advantage of this, like NW3 itself.

Having that said, one thing I need to clarify: at the moment, this batching is only applied to mesh polys, not BSP surfaces.
BSP surfaces are pretty much still rendered as before, also 1 at a time.

Trying to batch those seems to be more difficult, to the point it was already considered as a possible alternative to simply batch render the entire map, disregarding the BSP nodes completely, since in any GPU from the last 10 years that will likely be much faster than render each one of them at a time.

That's why maps like CTF-Blice (a map I released, meant as one of the benchmarks for 469 in the end) still lag a lot despite this improvement (not the only reason, but one of the reasons).

The ideal end goal is to pass pretty much everything that is currently involving the CPU in some way (rendering-wise) to the GPU.
But for that the rendering pipeline of the engine itself will require a significant rewrite, which will also lead to rewrites of the renderers themselves, which won't really be feasible unless we get rid of some of the renderers (like SoftDrv itself, which is nightmare fuel).

If we ever reach that point, then every single map and mod released to this date will be pretty much lag-free as far as rendering goes, with no FPS loss whatsoever in any reasonably modern system (anything from the last 5-10 years).
Even volumetric fog, one of the slowest engine features, could finally be fast and usable.

But for that the community has to help a bit, like letting go of SoftDrv completely, otherwise it will always be impossible.