SSAO+FakeDR for Tribes 2

Let's face it, Tribes 2 is child's play for your modern machine. It would probably run on your phone.

What to do with all that excess processing power?

Well how about we apply 2011 graphical operations to a 2001 game?

This is using QindieGL to wrap T2's OpenGL to DX9 (the D3D of T2 is DX7 and rather assy). This allows it to be hooked by an ENBseries mod to add dynamic Bloom, Color Correction, and Ambient Occlusion.

This is a work in progress still, and there are issues with BSP rendered buildings and trees being ignored by the depth map, but it's still a hell of a trick. I've also done a lot more tweaking to keep the gamma in the same range as the original game, and you have to hotkey it off during main menus and loading screens. There is a noticeable performance hit on my old 8800s (like... 300+FPS to ~45FPS), but any modern card should have little trouble.

Comments

  • Followup (and reserved space):

    What it lacks when it misses BSP objects (buildings and such in 'optimized' original maps) it definitely makes up for by working perfectly in Construction Mod.

    Don't worry, I cleaned up my spam...
  • This is awesome dude! Keep it up can't wait to download your first release! >=)
  • As far as the issue of getting people on the 'HD' version and not porking the people on basic, you could follow Eve Online's strategy, which I think was brilliant. They came out with a version of their client that supported high res textures, with all new models, but the game remained the same, people with 'classic' clients were still playing in the same universe. The only difference is a classic pc renders lowres_model_A at x,y,z coordinates, and the premium client loads highres_model_A at the same x,y,z coordinates.

    Assuming the engine can be made to support high res textures and models, then you just make a dloadable pack that has the high res content, and you're basically good to go - you could play on the same server and see HD content as another player running lowres... much akin to custom skins.

    Don't get me wrong, I'm not implying it's a walk in the park, but the theory is good.
  • any updates on this? i wanna see this work!
  • Same here!
  • When it comes to graphical stuff, I'm an idiot. I'm too left-brained and into the nuts 'n bolts of how things work rather than how they look. That being said, in my humility, being a layperson, what do some of these terms mean such as "bloom" and "SSAO"?

    B
  • edited March 2013
    Probably just better off picking up something like GLIntercept ...

    http://code.google.com/p/glintercept/

    Directly calling OpenGL functions will prove fruitful in the hands of someone who knows what they're doing...

    First screenshot:
    What I happened to get at some point when trying to render a 3D triangle. A catastrophe.

    Second screenshot:
    The closest I had managed to get, where the triangle stuck to your face indefinitely (think, screencap one) until you walked into a building for which the triangle would stick at the door and render in front of everything until you walked back out.

    Third screenshot:
    Working direct injection of OpenGL commands to draw arbitrary junk on screen in TWO DIMENSIONS. As demonstrated in the other pictures it's much harder to achieve in three dimensions ...

    Point is, you can possibly find a better way to do things through this with direct access to OpenGL.
    • fail.png
    • weird.png
    • testing.png
  • ThythThyth Apotheosis Incarnate
    Depending on what stage you inject geometry into the OpenGL pipeline, eventually it drops to 2D (+depth) normalized clipping space. In order to get 3D positioning of new objects (like your triangle), you'll have to inject the geometry prior to the worldspace->cameraspace conversion, which is then followed by cameraspace->projected normalized clipping space conversion. Or, you'll need to extract the camera position/parameters from the game simulation, and use those to recreate the view transformation, and perspective projection matrices -- then transform them on your overlaid points (though this will likely render over the existing scene).

    To do things like shader effects (like SSAO, bloom, dynamic range compression emulation, etc.) is more complicated with GL Intercept, because T2 uses "legacy" OpenGL (1.x). The various matrix transformations are done in fixed pipeline, which would be challenging to reconcile with a new vertex shader (designed to do those transformations in the programmable pipeline).

    In any case: doing a full graphical overhaul of T2 without source code is out of the scope of the TribesNext project. While it is possible to replace the rendering pipeline by swapping out bits of Tribes2.exe compiled code with pieces of the Torque Game Engine, doing so would be more work than it would be worth. You could apply global shaders (especially ones that work primarily on the fragment level) in the way Ranzear did, but, to get good results, you'll need to tag different objects with different shaders (and hope the game's scenegraph is arranged in a way that shader program context switches don't kill your performance). Easier to just write a new Tribes game from scratch, though, in my opinion.
  • Depending on what stage you inject geometry into the OpenGL pipeline, eventually it drops to 2D (+depth) normalized clipping space. In order to get 3D positioning of new objects (like your triangle), you'll have to inject the geometry prior to the worldspace->cameraspace conversion, which is then followed by cameraspace->projected normalized clipping space conversion. Or, you'll need to extract the camera position/parameters from the game simulation, and use those to recreate the view transformation, and perspective projection matrices -- then transform them on your overlaid points (though this will likely render over the existing scene).

    To do things like shader effects (like SSAO, bloom, dynamic range compression emulation, etc.) is more complicated with GL Intercept, because T2 uses "legacy" OpenGL (1.x). The various matrix transformations are done in fixed pipeline, which would be challenging to reconcile with a new vertex shader (designed to do those transformations in the programmable pipeline).

    In any case: doing a full graphical overhaul of T2 without source code is out of the scope of the TribesNext project. While it is possible to replace the rendering pipeline by swapping out bits of Tribes2.exe compiled code with pieces of the Torque Game Engine, doing so would be more work than it would be worth. You could apply global shaders (especially ones that work primarily on the fragment level) in the way Ranzear did, but, to get good results, you'll need to tag different objects with different shaders (and hope the game's scenegraph is arranged in a way that shader program context switches don't kill your performance). Easier to just write a new Tribes game from scratch, though, in my opinion.

    Yes, it was just an idea as I remember having messed around with this in the past but this isn't exactly where my knowledge is as of now so I just figured I'd mention it.
Sign In or Register to comment.