Not really sure if this belongs here, but technically it is Splinter Cell related on dgVoodoo2. I'm working on a small widescreen project for Chaos Theory's Versus mode (it's an entirely separate UE2 build than the single player / coop, and runs on its own executable). It also needs dgVoodoo2's emulation to properly emulate many of the dynamic lights in the game similar to Pandora Tomorrow.

dgVoodoo2 has been very useful and is the only reason this widescreen project is possible. The best way to describe it is we simply zoom into the game as it is the only way to play in "16:9" resolution without the game stretching (in reality, its a higher 4:3 resolution than your native resolution that is zoomed in to crop into 16:9). Inside dgVoodoo.conf, I go to the [DirectX] section, and force a resolution to zoom-in the game. For example, if you have a 1920x1080 monitor, you will put 1920x1440 in the config file. (ResY * 4 / 3)

So here's the game to demonstrate what's going on:

Normal Mode (4:3, 1440x1080):

Stretched Mode (16:9 1920x1080) - There is no known way to make this game not stretch in 16:9. The single player for SC1-2 do cropping but Versus mode seems to sadly stretch.

Widescreen Mode (forcing 1920x1440 in dgvoodoo.conf on a 1920x1080 game.ini then modded the game's HUD to scale down / move into position. FoV modded from 75 to 90.)

Widescreen mode looks nearly perfect with only minor problems: because of using this strange method of zooming into the game, we are unable to see the menus entirely obviously, so I was going to see would there be any possible way to implement a way that a keybind like "+" toggles between 1920x1080 and 1920x1440 mode in real-time on the wrapper or would that be impossible? It would be nice to un-zoom into 1920x1080 for when using the main menus:

Normal Menu (un-zoomed, 1920x1080)

Widescreen Menu (zoomed-in, 1920x1440 in dgvoodoo.conf)

This clearly isn't a big dealbreaker, I think the widescreen modification I've managed to accomplish is very good, and I will continue using it even with the slight menu annoyances of it being zoomed in. If there's a simple workaround that would be nice or if it's possible to not make this game stretch when running in standard 16:9 resolutions like the single players do then none of these issues would exist in the first place. Anyways thanks for taking the time to read and I appreciate the hard work in dgVoodoo2.

Also one final note: the latest version of dgVoodoo2 that came out (2.78.1 ) crashes the game when trying to use this zoom-in technique, 2.78 works perfectly fine. I'm not sure if it was intentional and as one might think it's stupid a user could enter a ResY value that's higher than their native resolution but it has been proved to be extremely useful for this case! ScalingMode = centered_ar is also required for this zoom in technique to work.

It's the classic viewport/frame issue

When you "zoom" you avoid the problem just cropping the frame with the zoomed viewport, it's why it "works".
It's not related to the DX wrapping mechanism, it's related to how the engine handles the frames.

Hmm... this is a typical modding issue. I think achieving widescreen would be better by discovering and modifying the internal 'projection matrix' used by the game. It might not be that simple at all though, I admit.

But, I was already thinking on it earlier, that dgVoodoo could provide some debugging aid for such cases, to make modder's life easier.
I don't know how much demand there would be in general, but I think I could revive the half-finished add-on support in dgVoodoo in order to hook different points of D3D rendering.
That is, dgVoodoo would call into a custom external dll (I could create the sample on GitHub) where by using a debugger, one could control and dump the D3D device internal state and could achieve per-draw-call step-by-step visual debugging (along with the tracing log) and be able to locate the different parts of the game code that are related to the rendering. Like I do it. That way it's much easier to find the needed stuffs like projection matrices.

TBH, I don't want to have hotkeys built in in core dgvoodoo, they're too game- and case-specific.

Dege wrote on 2022-04-01, 13:16:

Hmm... this is a typical modding issue. I think achieving widescreen would be better by discovering and modifying the internal ' […]
Show full quote

Hmm... this is a typical modding issue. I think achieving widescreen would be better by discovering and modifying the internal 'projection matrix' used by the game. It might not be that simple at all though, I admit.

But, I was already thinking on it earlier, that dgVoodoo could provide some debugging aid for such cases, to make modder's life easier.
I don't know how much demand there would be in general, but I think I could revive the half-finished add-on support in dgVoodoo in order to hook different points of D3D rendering.
That is, dgVoodoo would call into a custom external dll (I could create the sample on GitHub) where by using a debugger, one could control and dump the D3D device internal state and could achieve per-draw-call step-by-step visual debugging (along with the tracing log) and be able to locate the different parts of the game code that are related to the rendering. Like I do it. That way it's much easier to find the needed stuffs like projection matrices.

TBH, I don't want to have hotkeys built in in core dgvoodoo, they're too game- and case-specific.

Yeah understandable, this is a very game-specific fix, and obviously it isn't the ideal way to achieve a widescreen fix, but I don't know how to do any of that complicated stuff. If we could figure out how to find the core problem of the game stretching while in 16:9, that would obviously be the best fix. I don't really know how to program, reverse engineer, or any of that stuff, more so just mod this game for fun since we have a small community who still plays it.

If you could construct a dgVoodoo2 build that's just specific hotfix for this game to have a hotkey to switch resolutions, that would be very nice, although that's probably a lot of work for something not worth doing so, for now, I'll stick to this very primitive widescreen fix 🤣.

lowenz wrote on 2022-04-01, 08:13:

It's the classic viewport/frame issue

When you "zoom" you avoid the problem just cropping the frame with the zoomed viewport, it's why it "works".
It's not related to the DX wrapping mechanism, it's related to how the engine handles the frames.

I think I understand how it works, but yeah I don't really understand much of how the engine handles frames or any technical things like that.

It's just annoying because the original Splinter Cell does what I want SCCT Versus to do, and I don't know why exactly they behave different anyways?

Try using 1920x1080 in SC1, it's going to basically crop your view while I'm achieving this with SCCT Versus but I'm cropping the ENTIRE game using dgVoodoo. You lose field of view trying to play in 16:9 75 FoV as it should be. SCCT Versus on the other hand, has the same exact view and just stretches the entire frame like shown in my previous post.

If there was some easy fix that could be applied to SCCT Versus to replicate how SC1 handles 16:9, that would be amazing but I would assume that is extremely difficult to modify if not impossible to do with these games.

Changing resolution during working is a feature only for Glide. For DX it's much more complicated, I didn't think it'd ever be a demand, so unfortunately I cannot do what you'd like.
Btw, cropping the view can be done with option GeneralExt\DisplayROI. If you set it to "16:9 subrect, centered" for a 4:3 resolution then the middle 16:9 area will be cut and stretched according to the scaling mode set.

Joshhhuaaa wrote on 2022-04-02, 02:12:

If there was some easy fix that could be applied to SCCT Versus to replicate how SC1 handles 16:9, that would be amazing but I would assume that is extremely difficult to modify if not impossible to do with these games.

Try to contact ThirteenAG!

https://thirteenag.github.io/wfp#splintercell

lowenz wrote on 2022-04-02, 16:23:

Joshhhuaaa wrote on 2022-04-02, 02:12:

If there was some easy fix that could be applied to SCCT Versus to replicate how SC1 handles 16:9, that would be amazing but I would assume that is extremely difficult to modify if not impossible to do with these games.

Try to contact ThirteenAG!

https://thirteenag.github.io/wfp#splintercell

He has no interest in doing work for the Versus modes. I've contacted a few people.

Dege wrote on 2022-04-02, 13:40:

Changing resolution during working is a feature only for Glide. For DX it's much more complicated, I didn't think it'd ever be a demand, so unfortunately I cannot do what you'd like.
Btw, cropping the view can be done with option GeneralExt\DisplayROI. If you set it to "16:9 subrect, centered" for a 4:3 resolution then the middle 16:9 area will be cut and stretched according to the scaling mode set.

It's alright, thanks alot for looking into it and of course dgVoodoo2. I wasn't really sure if it was possible or not.

Joshhhuaaa wrote on 2022-04-02, 18:33:

lowenz wrote on 2022-04-02, 16:23:

Joshhhuaaa wrote on 2022-04-02, 02:12:

If there was some easy fix that could be applied to SCCT Versus to replicate how SC1 handles 16:9, that would be amazing but I would assume that is extremely difficult to modify if not impossible to do with these games.

Try to contact ThirteenAG!

https://thirteenag.github.io/wfp#splintercell

He has no interest in doing work for the Versus modes. I've contacted a few people.

PT widescreen fix doesn't work?

lowenz wrote on 2022-04-02, 20:44:

Joshhhuaaa wrote on 2022-04-02, 18:33:

lowenz wrote on 2022-04-02, 16:23:

Try to contact ThirteenAG!

https://thirteenag.github.io/wfp#splintercell

He has no interest in doing work for the Versus modes. I've contacted a few people.

PT widescreen fix doesn't work?

Like I said, you really can't compare these two games at all, don't treat them as connected. They run on an entirely different Unreal Engine build than the single player of Pandora Tomorrow and Chaos Theory and run on their own .exe file. Even the console versions of the game do a hot switch of the executables and make your screen go black for a few seconds. The multiplayer team was their own studio based in France whereas the single players for Pandora were from Shanghai and SC1/Chaos Theory in Montreal.

PT (Pandora Tomorrow), not Chaos Theory of course.
I know it's different but it's more related to PT than CT!

lowenz wrote on 2022-04-03, 08:28:

PT (Pandora Tomorrow), not Chaos Theory of course.
I know it's different but it's more related to PT than CT!

Yeah I know they're still not relatable enough to be easy transitioned over. When Ubisoft made Splinter Cell 1, they gutted out all of the network code out of Unreal Engine 2 thinking they'd never need it I guess. Then just after SC1's development, a team started working on its multiplayer (for SC2) after a few ideas, and they had to start from a completely different build of Unreal Engine 2 that has network code. The two are pretty different, even Pandora Single Player vs Pandora Multiplayer. SCPT multiplayer and SCCT multiplayer are pretty relatable, Chaos Theory's multiplayer is more so Pandora Tomorrow in technology (feels like a big expansion for PT multiplayer, it only had 9 months of dev time but its way better) than Chaos Theory single player that ran on brand new Unreal 2.5 tech with DirectX9. Multiplayer didn't see an uplift to DX9 and Shader Model 3 stuff until SCDA.

All the Splinter Cell "classic" games (1->4) have a customized Unreal *ONE* engine with several features and dx support level but it's always the original engine, like you can see in Duke Nukem Forever too.
The same of DXIW and TDS (1.x).

It's why SCDA is so limited. It's precisely in the same position of Duke Nukem Forever as an "extreme case of use" and a living fossil 😁

Convictons is the first in the series using a "modern" version of the engine, still not the 3 but some kind of "2.5" (heavy customized too, like in BioShock).

lowenz wrote on 2022-04-03, 21:57:

All the Splinter Cell "classic" games (1->4) have a customized Unreal *ONE* engine with several features and dx support level bu […]
Show full quote

All the Splinter Cell "classic" games (1->4) have a customized Unreal *ONE* engine with several features and dx support level but it's always the original engine, like you can see in Duke Nukem Forever too.
The same of DXIW and TDS (1.x).

It's why SCDA is so limited. It's precisely in the same position of Duke Nukem Forever as an "extreme case of use" and a living fossil 😁

Convictons is the first in the series using a "modern" version of the engine, still not the 3 but some kind of "2.5" (heavy customized too, like in BioShock).

All of those games are based on Unreal Engine 2 (Splinter Cell, Thief DS, and Deus Ex IW) different builds of course and Ubisoft completely modified their engine to be their own but all of those games were Unreal Engine 2? Not sure what you mean they run on Unreal Engine 1, unless you mean they were all on ONE base build which is technically correct. Splinter Cell 1-6 (not including PT/CT/DA multiplayer, they use build 2110) all use Unreal Engine 2 (build 829) with the codebase expanded upon for years and years, Conviction/Blacklist didn't even restart I don't think. They just modified their engine so much and added newer revisions of UE2.5 into their code and by the end of it, their engine was like a zombie version of Unreal 3 but technically all originating from that ancient Unreal Engine 2 (829) being expanded upon. Either way, yeah you can't really use the PT widescreen fix (single player) on multiplayer. Also for SCDA being limited? Graphically I think that game looks better than Conviction, really good for 2006, Xbox 360 version of course.

No, they are Unreal Engine 1-based (with proper customizations), just take a look to Unreal2/UT2004 config files (how they're structured) and the ones I have listed.
If we consider Unreal 2 (and America's Army in summer 2002) the first UE2 games and not the "interim" builds by the number.

Don't get fooled by DirectX versions and features supported, there are dx9 versions of "plain" UE2 too (Shadow Ops: Red Mercury)

lowenz wrote on 2022-04-04, 00:37:

No, they are Unreal Engine 1-based (with proper customizations), just take a look to Unreal2/UT2004 config files (how they're structured) and the ones I have listed.
If we consider Unreal 2 (and America's Army in summer 2002) the first UE2 games and not the "interim" builds by the number.

Don't get fooled by DirectX versions and features supported, there are dx9 versions of "plain" UE2 too (Shadow Ops: Red Mercury)

Their config files look structured the same, I have no clue what you're on about 🤣. Not a single person has considered those games as Unreal Engine 1-based ever, Splinter Cell is filled with Unreal 2-only features, you couldn't even use StaticMeshes , Skeletal Meshes, or all of the lighting effects present in the game on Unreal 1. I don't really care to fight over which version we think they are, but they are Unreal 2, it's basically fact (although I'm curious why you consider them UE1-based??). I'm not being fooled by the DirectX versions, because if that's the case I mean Splinter Cell Blacklist has DX11 in 2013, it's not like Epic Games ever coded that for them, they were long gone by then.

If you use the builds numbers you're correct

Builds 1~613 = First Generation Unreal Engine
Builds 633~3369 = Second Generation Unreal Engine

To me the Unreal Engine 2 "era" starts with America's Army and Unreal 2 simply 'cause the engine interface through configuration files offers options like these:

UseHardwareTL=True
UseHardwareVS=True
UseCubemaps=True
UseCompressedLightmaps=False
LevelOfAnisotropy=16

etc. etc.

SC1 engine is way behind this point.

lowenz wrote on 2022-04-04, 10:51:

If you use the builds numbers you're correct […]
Show full quote

If you use the builds numbers you're correct

Builds 1~613 = First Generation Unreal Engine
Builds 633~3369 = Second Generation Unreal Engine

To me the Unreal Engine 2 "era" starts with America's Army and Unreal 2 simply 'cause the engine interface through configuration files offers options like these:

UseHardwareTL=True
UseHardwareVS=True
UseCubemaps=True
UseCompressedLightmaps=False
LevelOfAnisotropy=16

etc. etc.

SC1 engine is way behind this point.

I get your point but I still don't see how it discredits SC1 as a Unreal 2 game (maybe we can call it 1st generation Unreal 2, but still Unreal 2 nonetheless), it's just simply an older build. Unreal 2004 launched into much later builds than Splinter Cell in the 3xxx range, pretty sure it was considered Unreal 2.5 by then. SC1-6 are based through Build 829 in January 2002 but got gradually updated by Ubisoft. Chaos Theory and Double Agent still implemented many various features by taking code from newer builds.

However, since SCPT/SCCT/SCDA 's multiplayer modes do start from a newer Build 2110 base (October 2002), they do include the newer configuration with "UltraHigh" settings that you are talking about.

https://www.moddb.com/members/zhazelwood/mods

To be on topic, the game is getting remastered by Ubisoft so we wont have to play reverse engineer legally to make real changes. In other news im remastering Chaos Theory. Im uploading the final version of mission 2 right now, and ill be working on mission 3 more since some of it is already complete. Another person is also involved working on mission 4. This is not a run and gun upscale fest. Its not even trying to max x86 out on the entire game, but per mission which is a lot more ambitious. Just FYI. Anyone who wants to help, should.

It only lets me link 5 photos at a time and I dont want to double post, so that should give you an idea just how insane this project is, or how overkilled it is.

Also would like to know how to preserve transparancies or recreate them post upscale. Im not familiar enough with Unreal Engine but at least one of you seems like it. I could use your input.