Hard Light Productions Forums
Community Projects => The FreeSpace Upgrade Project => Topic started by: Bas on February 16, 2009, 04:56:32 am
-
Huhu,
just wanted to ask, maybe it is possible to include the bloom effect converter?
http://boris-vorontsov.narod.ru/download_en.htm
Look for " GTA ViceCity/GTA3 v0.074f - this version contain convertor inside archive, see readme file." & "d3dx9_26.dll - reqired to run ENBSeries. This library actually from DirectX9, but not available on some users PCs, thanks to Bill Gates."
Not sure about if this would work for FS2, but I believe it would be worth a look.
-
FS2_Open doesn't support Direct3D rendering any more, and I assume that stuff isn't easily interchangeable with OpenGL as such...
-
He seems to be really open to suggestions though.
I wanted to contact him a while ago, but I don't have enough time right now to write a decent mail with all the informations, he should get.
Still, it's unlikely he'd pick it up. I'm pretty sure that a similar application for OpenGL would take a lot of work to create.
There might still be hope, as there are many old OpenGL games (Q3 engine), that would still profit from a subtle bloom and SSAO and maybe even motion blur.
-
Well we do have rudimentary frame buffer objects (FBO) support, which is a precursor to many of the OpenGL bloom and motion blur techniques, in the FS2Open engine.
-
Anyone capable of transferring the FS engine from OpenGL to DirectX9 = Win
It would certainly provides us with much, much more eyecandy.
-
Anyone capable of transferring the FS engine from OpenGL to DirectX9 = Win
It would certainly provides us with much, much more eyecandy.
Unfortunately it'd be a damn nightmare.
-
I tried that, with very little success. DirectX9 is very different form DirectX8, so you end up having to write a bunch of code that doesn't really work, and then you end up with a bizzare red haze over everything, after which the engine crashes. You'd have to be really, really dedicated to do that, because you'd be writing an entirely new renderer for a game with the most convulted rendering code I've ever laid eyes on.
-
And on top of that, there's whole only-works-on-Windows issue...I mean really Spectre, we're not going to just move to DirectX. It would have to work with both, and that's a giant pain compared to just having one API.
-
And to add on top of that, anything Direct3D can do can be achieved, one way or the other, by creative thinking and OpenGL.
-
Anyone capable of transferring the FS engine from OpenGL to DirectX9 = Win
It would certainly provides us with much, much more eyecandy.
Explain how.
-
Actually,
Anyone capable of transferring the FS engine from OpenGL to DirectX9 implementing all the already anticipated OpenGL features that haven't already been = Win
It would certainly provides us with much, much more eyecandy.
Fix0red.
-
Anyone capable of transferring the FS engine from OpenGL to DirectX9 = Win
It would certainly provides us with much, much more eyecandy.
Explain how.
Well, that's probably because some people think that D3D looks better than OpenGL for some reasons I have yet to understand...
Funny enough, it once was the other way around, where all the gamers thougt OpenGL was "better".
It's the same guys who see a bloom effect and talk about HDR effects. ;)
-
I want to point out that DirectX does have some significant advantages over openGL in the current market, mostly due to some very stupid decisions on part of whoever is developing openGL. But there isn't anything that can ONLY be done in direct3D, hence why most of the examples given in Nvidia's own GPU Gems 3 are written in GLSL. The fact that DirectX is windows-only will forever be a handicap that will keep it from completely dominating the industry. That and the fact it isn't open-source, although right now open-source isn't really helping openGL very much.
However the notion of converting the engine to directX in order to "enable" graphical features is absurd. You can do anything on openGL, some things are just a royal pain in the ass.
-
Well, I heard that OGL 3.1 is finally a step in the right direction again.
-
Indeed:
# Texture Buffer Objects - a new texture type that holds a one-dimensional array of texels
# Uniform Buffer Objects for fast data share/update
# Signed normalized textures (±1.0 range)
# A minimum of 16 texture units accessible by the vertex shader
# Primitive restart
# Instancing - drawing of objects multiple times through the re-use of vertex data
# CopyBuffer API for fast data copy; used in conjunction with OpenCL
-
Now, if only FSO didn't have such horrifically old graphics code so we could actually use those new features.