Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Scuddie on March 30, 2005, 12:26:38 pm
-
I'm curious what is going on with D3D8 and OpenGL as far as progress and dependability. The reason I ask is because the last time I heard anything official about either of these was back in the 3.6 days, where OpenGL was pushing the limits of everybody's video, while D3D8 was having real bad memory leaks. Since then, much has happened, but what has as far as I know is unknown.
What I see now is very different from back in the 3.6 days. With everything turned on, OpenGL runs at 120FPS at 1024x768x32 with 4x AA and 4X AF. Meanwhile, D3D8 seems to run flawlessly, although bringing my system to it's knees with the same setup. Also, env mapping doesn't seem to work on either renderer.
So basicly what I am asking is what is the progress on OpenGL as compared to D3D8?
-
OpenGL is missing envmapping so that's why that doesn't work. Other than that most everything else works. OpenGL is the only renderer that Linux and OSX use so I've spent a lot of time working on it, performance testing and optimizing as best I can. The new render-to-bitmap functions don't work in OpenGL yet as that is platform specific and I haven't had time to come up with a good method to do it three ways (Windows, Linux, OSX) that doesn't require a ton of code for each. Various rendering problems with 2d graphics in 3d space have been fixed as well. That was most noticeable in nebula missions when -2d_poof was used but would show up when us coders made mistakes as well.
I stay away from the D3D code as much possible since it's not something I know and as a Linux user, not something I use, so I can't reliably comment on changes/features there.
-
I'm not sure I would be sad if D3D went away entirely :)
Oops, did I say that out loud?
-
Careful, you might anger Bob ;)
-
Well... I'm a OGL-"Fan", too...
But I think I am and will be very glad if /when D3D and OpenGL have the same features...
-
I'm also a pretty big OpenGL fan, which is why I have the question. I have no idea why OpenGL is so much faster than D3D8, but I bet it might have something to do with the draw distance. For example, I get "polygon rip" in OpenGL that is dependant upon the distance of the object from the view. The farther away it is, the thicker the line, or "rip". This rip has the appearance of a textured, but non-shaded polygon; meaning whatever effects the rendering engine is supposed to pass upon that polygon (including obstruction from other polygons), has no effect within the thickness of the rip. The way it passes thru is somewhat mysterious. It seems to rotate, but not hub of a wheel, more like the face of a wheel. Ugh, just trying to explain it gives me a headache. I don't know how to describe it without making myself confused. It's not a VSync thing either. Oh well, maybe someone else can explain what I mean...
EDIT: Oh yeah, this doesn't happen in D3D.
-
I like OpenGL, the problem is it seems to crash during loading for random missions, even though the mission loads fine in D3D. It also seems to run a lot slower and have various disturbing bugs that D3D doesn't.
-
@Scuddie: Got a screenshot? And what build are you using (cmdline too)?
-
Shot 1(http://img41.exs.cx/img41/286/ripshot12jr.jpg) (http://www.imageshack.us)
Shot 2(http://img41.exs.cx/img41/6206/ripshot28mc.jpg) (http://www.imageshack.us)
Notice how far the distortion moved in 44 meters. It is this way no matter which recent build, and no matter which flags. However, for the record:
C:\Games\FreeSpace2\fs2_open_ex.exe -spec -glow -pcx32 -jpgtga -2d_poof -rlm -pcx2dds -dualscanlines -ship_choice_3d -targetinfo -3dwarp -ballistic_gauge -smart_shields -snd_preload -decals -fps -stats -show_mem_usage
-
fix the urls on those pics, we cant see anything.
-
That seems to be your problem. I can see them fine.
-
I think what he means is that from the pics you posted there's not much to see. I see a little bit of clipping on the thrusters, but that's hardly unusual for a model with the glowpoints on the surface of the engines. Plus, you've got the pics there hyperlinking to Imageshack, but the link doesn't take us to a larger version of the image, as we all would expect. If it weren't for the fact that you've got target info displayed, I wouldn't know what on earth you were trying to show. Can you replicate this with the hud off at least?
EDIT: Actually, the best way to get a good screenshot of the effect would be to make the FOV insanely small so that the defects are larger and more clearly identified. Because that just looks like a z-buffer imperfection.
-
Well, I figure it must be a ZBuffer problem, because when I made the FOV .15, it was just as far away from the view as it was with the default FOV value. I didnt notice any problems until it was 8 clicks away. Plus, that would explain why D3D doesn't do that. So is there a problem on my end? Or is FS2Open OpenGL unfinished in regards to buffering? Or is ZBuffer issues just the nature of the beast for OpenGL entirely?
-
Zbuffer issues are just the nature of the beast in ALL 3D
-
I just thought of something. Is the ZBuffer for 32bit OpenGL 24bit or 32bit? I may as well bring that up, because I realized by accident that the GeForce4 / Raideon 8xxx cards and older can only support a 24bit ZBuffer, and the other 8bits are reserved for stencil. I did some research, and it has shown that 32bit ZBuffer on older DX8 cards had problems with flickering whenever stenciling was present. Also if a stencil was not present, the ZBuffer wouldn't work right in 24-bit. I thought I might bring it up, perhaps to get a workaround for it, like maybe a -Z24 commandline flag or something :nervous:.
-
Wouldn't dropping DirectX close certain doors in the graphical enhancement department though? I'm pretty much a DirectX only user, simply because most games that offer a choice will default to that, so I don't know much about the abilities of OGL.
-
I wouldn't mind seeing D3D go either but the truth is that most of the new graphics features are done by the people who know D3D and not OGL. It means that the OGL code always has to play catch-up but the new features get in that way. I don't know of anything that D3D can do that OGL can't and in fact D3D keeps picking up new features from OGL. The same goes the other way as well. OGL is still a little behind in this case because I don't think there is anyone on the SCP team that really knows OGL that great. Most stuff, yes, but my experience pretty much ends with version 1.2 and everything else is learn as I go. Makes things a little slow going. Also ATI drivers in OGL (in general if not in practive) suck fat a$$ which means more time troubleshooting graphics bugs that could be wasted on other things, such as new features.
@Scuddie: It's been 24-bit but I recently changed it to 32-bit to test fixes for ATI cards. It was done per stuff I read on MSDN and Google searches. I don't have an ATI card myself and can't reproduce the errors with my NVIDIA card so it's hit or miss on the fixes. It's only been like that only on builds this month though so if you don't have that same graphics glitch on earlier builds then it's not related.
-
d3d cannot do anything openGL cannot do
-
Originally posted by taylor
@Scuddie: It's been 24-bit but I recently changed it to 32-bit to test fixes for ATI cards. It was done per stuff I read on MSDN and Google searches. I don't have an ATI card myself and can't reproduce the errors with my NVIDIA card so it's hit or miss on the fixes. It's only been like that only on builds this month though so if you don't have that same graphics glitch on earlier builds then it's not related.
Bingo. I just downloaded and ran your Jan 3 build (T-20050103), and there were nothing to see whatsoever. I tried while close, I tried while far away, and not a single rip, tear, artifact, or any other abnormality occured. At all. I'd call this a big confirmation. Unless it would require a re-write of the OpenGL renderer, I believe a commandline flag is in order.
-
Originally posted by Scuddie
Bingo. I just downloaded and ran your Jan 3 build (T-20050103), and there were nothing to see whatsoever. I tried while close, I tried while far away, and not a single rip, tear, artifact, or any other abnormality occured. At all. I'd call this a big confirmation. Unless it would require a re-write of the OpenGL renderer, I believe a commandline flag is in order.
Well there have been other thruster rendering changes since that build too so it could be a combination of stuff. Try and find a build as close to March 3rd as possible without getting anything newer and see if the problem occurs there as well. Either way I am just going to go back to 24-bit since changing it to 32 didn't seem to help any with the ATI problems. You can just wait for any build after today to test again if you want. If it really doesn't fix it in a newer build then make sure I know so that I can search for the real problem. If it does turn out to be needed later on it will be a cmdline to go with 32-bit since 24-bit worked for a couple of years without issue.
-
You can try the -clipdist parameter with a value higher than 1.0 (ie 3.0).