Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Fineus on January 09, 2006, 07:35:18 am
-
Hey guys...
I've not really been keeping close tabs on the SCP for a while now - and I should very much like to "get back into it". However one thing always annoyed me and that was the problem regarding Radeon drivers not displaying shine mapping (I believe it was?) correctly.
Has this been corrected, if not which driver build should I use to see the SCP in all its glory (that is - with everything functioning as it should)?
Cheers :)
-
No, it hasn't been corrected. You have to use OpenGl to see shinies.
And if i remember correctly, then you have to use Catalyst 4.3
But it is easier to run it in OGL. At least thats what i do.
-
Is that:
You have to run it in OGL and with Cats 4.3?
Or you can just run it in OGL (and it doesn't matter if you're using the 4.3 drivers or not).
-
OGL needs newer than Cats 4.3 to work properly (otherwise there are some driver bugs). One or two random versions since then had minor problems as well I believe.
Of course then you can't get spec with D3D so it's a trade-off for spec or env mapping since OGL still doesn't have proper (or public) envmap support yet. OGL offers more than D3D in other areas now though: more speed and memory usage improvements, anisotropic filtering, bilinear and trilinear filtering, full support for mipmaps, etc. Just no envmapping, yet.
-
Fair enough...
In that case - does anyone know approximately how less efficient the 4.3 Cat Drivers are? I really do want to try the game out again with the new SCP spiffyness but seeing as I'm also trying to run Need for Speed Most Wanted I don't especially want to find everything else stops working.
-
Errg I hate OpenGL though it's so crappy. Why can't you fix it so that the Radeon drivers can read the shine and glow maps? They really make a huge difference graphically, and I hate missing out on them.
-
Errg I hate OpenGL though it's so crappy.
Well, looks like you don't know much about APIs and FS2_open. Right now OpenGL has only one drawback compared to D3D. The Envirounment mapping.
Appart from that it's faster and a lot more stable.
D3D is for maximum image quality, but on the other hand it's not as optimized as OpenGL.
FS2_open does not use any 'crappy' API atm.
-
The environmental mapping doesn't seem to work at all in newer builds anyway. You have to go back a few months to get a build with that feature functional. D3D does currently have somewhat better lighting and launcher support though.
-
D3D does currently have somewhat better lighting
I personally don't think so. But there is the -ogl_spec cmdline option to change specular lighting in OpenGL to try and match D3D values. It was added so that someone would tell me what value should be used as default, but so far no one has.
-
Not to demand anything (and I realise that's exactly what it looks like I'm doing) but it'd be really nice if there was generally the exact same features in both APIs... I know part of it is entirely a driver issue but when that's sorted out it'll be a lot easier all around.
-
[q]I personally don't think so. But there is the -ogl_spec cmdline option to change specular lighting in OpenGL to try and match D3D values. It was added so that someone would tell me what value should be used as default, but so far no one has.[/q]
Cool, I didn't know you had added that. I'll try playing around with it and see if I can get it to look the same as it does in D3D.
-
Not to demand anything (and I realise that's exactly what it looks like I'm doing) but it'd be really nice if there was generally the exact same features in both APIs... I know part of it is entirely a driver issue but when that's sorted out it'll be a lot easier all around.
You'll get no objection from me one that, but in practice it's rather impossible. D3D doesn't really have anyone working on it at the moment so it's missing some of OpenGL's features and optimizations. I don't use Windows so I can't use D3D which means that if I add something to OGL I'm unlikely to also add it to D3D since I can't test it.
That also brings up the cross-platform aspect. D3D works only on Windows so you don't really have anything to think about there. OGL has to work on 3 different platforms though, all with different capabilities. A feature that may be simple to add on one platform may prove more difficult or less optimal on another, and the other platform may not support that feature at all. That's basically the holdup on envmapping support in OGL, letting all of the various platforms catch up to each other so that nothing platform specific has to be done to support it. OGL does have basic envmap support now (in private builds) but actually creating those envmaps is the current issue. It's possible to do, I have the code for it, but if it's not properly handled for all platforms then it's just more work for me and more problems for everyone else.
-
Is there some way to separate features like that into the OS-specific defines? It's kind of annoying to hear "Yes, this works fine under Windows and Linux, but it doesn't work under OS X so it's not going in." I don't know if that's actually the case for anything, but regardless of the OS, it's hard to know that you could actually use the feature, except for those other people that use OS X (or Windows :D).
Not to mention that some kind of public release lets you work out the unlikely bugs and various hardware conflicts that work themselves in, before you add another platform or platforms that could each have their own individual sets of driver problems.
-
It does have to be said that (and I may be going out on a limb here) - most of us are still using Windows to run this thing, right?
Not that cross-platform development should be dropped or crippled. Just that maybe features for platforms that only a handful use could be prioritised below those that everyone would get something out of.
(Again, this is me "thinking out loud" so to speak - not actually wanting to tell you guys to do what I want over what you want :))
-
Is there some way to separate features like that into the OS-specific defines? It's kind of annoying to hear "Yes, this works fine under Windows and Linux, but it doesn't work under OS X so it's not going in." I don't know if that's actually the case for anything, but regardless of the OS, it's hard to know that you could actually use the feature, except for those other people that use OS X (or Windows :D)
The point is to not release OS-specific code and in most cases OGL allows for that (since OGL itself is cross-platform). In small peices perhaps it can be specific but not in large chuncks. The problem in the envmapping case is that there is an old method, which is OS specific and would require large chuncks of code to be #ifdef'd, and a new method that works much better but which, because of the way the code is set up, would be problematic to support properly on all platforms (due to linking issues, etc.). I'm changing the code to allow for this, not only for the envmapping stuff but for all future OGL code, but it's not high priority for me.
Not to mention that some kind of public release lets you work out the unlikely bugs and various hardware conflicts that work themselves in, before you add another platform or platforms that could each have their own individual sets of driver problems.
I don't release anything unless I'm happy with it. It doesn't have to be 100% done before I put it in CVS but the basic form and functionality does have to be complete. And if you half-ass something and assume that it would be eaiser to just get it working now and fix for other platforms later then that hits the first adage of stupid-porting-mistakes 101. If there was more active support for both Linux and OS X on the developers side then I wouldn't be so anal about it. But as it stands I'm the one that has to support all 3 platforms. If I stopped working on Windows bugs and issues then I'd have more time to do all that I want, but I don't think that most people would like that very much.
It does have to be said that (and I may be going out on a limb here) - most of us are still using Windows to run this thing, right?
Not that cross-platform development should be dropped or crippled. Just that maybe features for platforms that only a handful use could be prioritised below those that everyone would get something out of.
You'd be surprised just how popular the OS X version is becoming, not to mention the fact that most FS2_Open bugs (even ones specific to Windows) are tracked down and fixed using Linux or OS X machines. But it really doesn't matter what most people use, I don't use it, and I am writing the code. Any time I put something in CVS it has to be ready for multi-platform support and that's not optional. If it's not going to support multiple platforms then I don't support it. I'm part of SCP really only for Linux and OS X so if those two things are sacrificed for better Windows support then I get sacrified too. :)
-
OGL does have basic envmap support now (in private builds) but actually creating those envmaps is the current issue.
you mean creating an env map from the mission background setup (not the one in the shine map)? is it posible to set it up so that you could use a user defined bitmap for the environment under opengl, rather than have them generated automatically from the background?
-
taylor - that's totally fair enough. As I said you're the guy/s who're working on this not me - do what you feel is best.
That said.. would I be correct in assuming that the best way of being able to access all the major graphical ability of the current build is to have the 4.3Cats in use? Be that as it may, where can I find a copy of them?
-
[...]
OGL does have basic envmap support now (in private builds) but actually creating those envmaps is the current issue. It's possible to do, I have the code for it, but if it's not properly handled for all platforms then it's just more work for me and more problems for everyone else.
Very interesting. Will it work just as the D3D using the alpha channel?
And do you have any vague idea when the env mapping reaches the public release state?
I do like the env mapping a lot, but it's just too slow in D3D, or maybe due to D3D.
-
you mean creating an env map from the mission background setup (not the one in the shine map)? is it posible to set it up so that you could use a user defined bitmap for the environment under opengl, rather than have them generated automatically from the background?
Yes, that's how I've been testing it recently (easier than actually starting a mission). The feature needed (or what I'm going to use) to automatically generate the envmap isn't supported by all video drivers, but the ability to actually use an envmap should be. So I want to be able to let people who can't automatically generate a mipmap still use one. I'll probably set up some sort of cmdline option which will allow someone to generate an envmap for a mission and then have it automatically save to a file so that others could make use of it. That would also allow easier use of nice envmaps in the techroom and the lab.
The problem with the current code (on non-Windows systems at least) is that it links to the OGL libs at build time. That means that if the build computer has the required features, and someone using that build doesn't, it wouldn't run for them. The OGL commands (anything beyond the 1.2 feature set) really need to be properly virtualized basically so that they can not exist and it will still work for everyone. I'm also adding error checking into those commands so that it's easier to find problems, since we only report errors once per frame and it only says what the error is and not where it came from. This really should have been done a long time ago but it wasn't a concern for anyone using Windows and most of my time has just been spent trying to get OGL more feature complete as well as to get the Linux and OS X versions up to speed.
That said.. would I be correct in assuming that the best way of being able to access all the major graphical ability of the current build is to have the 4.3Cats in use? Be that as it may, where can I find a copy of them?
Not sure actually. You should be able to get older Cat versions from ATI's website. The main problem now is that with current builds envmapping in D3D appears to be causing crashes so env may not work for you. Specmaps would work in D3D with the older Cats though. But you need to use current Cats in order to run OGL so it's a trade-off and you'll have to decide for yourself which you want to use.
Very interesting. Will it work just as the D3D using the alpha channel?
And do you have any vague idea when the env mapping reaches the public release state?
I do like the env mapping a lot, but it's just too slow in D3D, or maybe due to D3D.
1) It will end up doing whatever D3D does so though it's not perfect now it will eventually do whatever is wanted
2) Nope. Just when I have time to do it and I have had very little time lately. The little time that I have had has been mostly spent on fixing bugs and not working on the rather massive amount of new features that I've started.
3) Maybe due in part to D3D. In OGL at least it shouldn't be too much slower than using specmaps. It will certainly be slower than not using envmaps though, more work needs to be done by the video card to handle environment mapping.
-
Kal; Just use OGL. If the shines look too off, just drop the ambience down to .75 and it looks remarkably like D3D used to.
-
What are the ranges for and default values of the ambient_factor and ogl_spec options? I can't seem to figure that out.
-
Raa, Taylor, Cheers guys - I switched over to OGL and tweaked the ambient lighting. It looks superb once again. My thanks to both of you (and everyone else) for all the help in sorting me out :)
-
If i read code correctly:
-ogl_spec has default value of 80 and accepts values from 0 to 128
-ambient_factor has default value of 128 and wiki states it uses percentage values... (0 to 100) recommended is something about 70. I must have gotten something wrong here though... :nervous: 128 ?
-
You guys seriously gotta fix shine mapping for radeon drivers! Please? It really makes a difference, and I can't stand using OpenGL... especially since it can't handle environment mapping...
-
not that i know much about gfx but ive got a few opengl sceensavers that have env mapping
the 3dtext screen saver that comes with xp has it ????
-
env mapping and cube mapping the same thing?
-
Not necesairly.
A cubemap is a method of Env-mapping, but there are others.
-
like sphere mapping, which looks better on curvy models.
-
You guys seriously gotta fix shine mapping for radeon drivers! Please? It really makes a difference, and I can't stand using OpenGL... especially since it can't handle environment mapping...
Ahem... OpenGL CAN handle environment mapping. It's just that it is not implemented in FSO (taylor's working on it, read his post)
You should really try OpenGL, it's a better API than D3D (and you'll live without env. mapping).
In a normal world, D3D would've been a massive failure, but M$ tricked hardware manufacturers into using their code to make driver development easier, and then M$ did not allow them to release their OpenGL drivers (because they contained M$ code) when 3d acceleration first appeared, giving D3D a headstart (imagine the frustration of the dev working on an OpenGL game). OpenGL has been around since 1992 IIRC, or even before (not primarily on PC's and of course not using 3d cards). D3D is just a(nother) crappy attempt to take over another segment of the computer industry and wipe out the competition, just something M$ always does. And they stuff stupid things in people's heads such as OpenGL is not good for gaming, it's for graphical design and it's slower and D3D is for fast graphics and games etc.
To me, D3D is and obsolete API: it supports one platform and OGL outperforms it even there, plus it's uglier to program (that's just my personal opinion though, some people can't stand the extension system in OGL).
Rant off
Oh, and by the way, been playing games like Quake or Doom or SW Jedi Knight recently? Well if you have, you've been using OpenGL
-
im actually starting to like ogl, ive been using it ever sence env was broke (the only reason to use d3d). so im actually looking forward to env working in ogl.
-
I haven't noticed much of a difference in the performance since switching to OGL, and the image quality is the same as D3D after playing around with those parameters a bit (the default value for ambient_factor is really bad, by the way). It's good to not have those big popup delays anymore though. While the D3D environmental mapping is very nice, the last build that worked correctly with it and had no other problems was the 9/17 one, which is missing some newer additions that I am using in my missions.
Although on ATI cards D3D would be a better choice if the specular lighting worked, since they are significantly slower with OGL in general.
-
I have an NVidia, and one thing that is noticeably different is mouse responsiveness.
-
the sooner we get env with opengl, the sooner i can fix up alpha channels for all my shinemaps
-
Well my main problem with OpenGL before was that it made the graphics of games look too "grainy" so to speak around the edges. However, I went into advanced graphics settings under properties on my desktop and modified the OpenGL settings to have some Anti-Aliasing and such so now it looks even better than D3D, AND for the love of god the game no longer has massive slowdowns! I love OpenGL now, never mind about fixing it for Radeon drivers. I don't care anymore, OpenGL > D3D. ;)
-
I just noticed something rather annoying about the OGL mode. I can't minimize the game with it; if I go back into the game after alt-tabbing, it actually crashes my machine (BSOD and auto-restart). The alt-tabbing works fine in D3D though. I tend to do this a lot when debugging a mission, so I might have to stick with D3D when I'm testing out stuff.
-
Alt-Tab works fine for me but as an alternative try running in a window when debugging.
-
I think I'm going to fix OpenGL so that it never minimizes. I would instead just switch between fullscreen and windowed modes (probably dropping back to the nearest standard resolution when going from fullscreen to windowed). This would allow Alt-Enter switching between windowed and fullscreen modes too. The constant minimizing is just plain irritating.
-
How do I upgrade my Open GL from 1.0 to 1.2 or greater for my Radeon 9800?
-
If you're refering to an error that FRED or FS2_Open is giving you don't bother. Just update them instead.
-
How do I upgrade my Open GL from 1.0 to 1.2 or greater for my Radeon 9800?
Even Microsofts software driver is 1.2, so you can't have 1.0. Which program told you that?
With NVidia, if you download the newest drivers, you get OpenGL 2.0. The same should be true for ATI, but I can't see OpenGL in their drivers' feature list.
-
I have the latest Cat drivers (5.13) but the opengl drivers neve updated. Anyway, I updated my FS_Open and I don't get the message and can run in open gl now so there's no problem, though I would like to know how to update them, I want a nice shiny opengl 2.0!
-
Could you post a screenshot of whatever is telling you your ogl version?
-
You have openGL 2.0 most likely. FS2 or FRED had it's own version of the Y2K bug where cause it wasn't checking anything before the decimal point it would think that 2.0 was 1.0 and therefore not good enough to run with.
-
However, I went into advanced graphics settings under properties on my desktop and modified the OpenGL settings to have some Anti-Aliasing and such so now it looks even better than D3D
I just gave this a go myself (usually I have my OGL/D3D settings to "application preference" but forcing 4x AA with OGL produced beautiful results. Nice tip!
-
I also notice that shimmering effect on ships at long distances (I think that's what you mean by "graininess") but haven't found a way to remove it completely no matter what I try. It's not due to the crappy default Nvidia AF either, since turning that off or using high quality / LOD clamp mode doesn't seem to do anything. It's actually more noticeable in FSO than any other game I have.
I think I'm going to fix OpenGL so that it never minimizes. I would instead just switch between fullscreen and windowed modes (probably dropping back to the nearest standard resolution when going from fullscreen to windowed). This would allow Alt-Enter switching between windowed and fullscreen modes too. The constant minimizing is just plain irritating.
That works for me. I basically like to leave FRED2 open in the background and go and fix any mission bug I find immediately, so I don't forget it later.
-
I am trying ogl now (I have a radeon 9800pro), but how do you use -ogl_spec and -ambient_factor? Do you just put them on the command line, something like "-ambient_factor 75" ?
Also, what is a good value to use for -ogl_spec? Did not see anything in wiki about these values.
-
Do you just put them on the command line, something like "-ambient_factor 75" ?
Yes, that's exactly it :)
-
Also, what is a good value to use for -ogl_spec? Did not see anything in wiki about these values.
-ogl_spec was only supposed to be a temporary option until someone comes up with values that more closely match the D3D affect. No one has though so it's still in there. Basically all it does is specify how tight/bright the specular light will be. Lower values create a wider light, which is also dimmer. Higher values create a more focused light, and get brighter. The range is 0 to 128 with the default being 80, so use that to help determine how you would like to adjust it.
-
Curiously I get an "Unrecognised command line parameter" whenever I try and use that function...
Running Launcher 5.3 and FS2 Open 3.6.7
-
Works fine for me. But I like it where it is, with ambince turned down to .75, personally.
-
To me, D3D is and obsolete API: it supports one platform and OGL outperforms it even there, plus it's uglier to program (that's just my personal opinion though, some people can't stand the extension system in OGL).
Rant off
It is unfortunate that in the next generation of Windows OGL will merely be "emulated" (meaning it will probably run slower than hell).
-
It is unfortunate that in the next generation of Windows OGL will merely be "emulated" (meaning it will probably run slower than hell).
That's for the MS native driver though. Video card manufacturers will still provide there own OpenGL layer (ICD). The ICD isn't the perfect option but for fullscreen games nothing will be different than before. In windowed mode it will likely (temporarily) disable compositing support for Windows but that shouldn't be a too big of a deal, and there will probably be work-arounds for that before long. Using the MS OGL will give you OpenGL 1.3 functionality (though I don't think extensions are supported) but you'll barely be able to run FS2_Open with it anyway. You'll need to use the full OpenGL ICD from your video card drivers, or use D3D directly. MS OpenGL support sucks, and it always has, so is there is no real change here.
-
The OpenGL in Vista *BETA* is a wrapper to D3D, version 1.4 and no extensions (this means that the function set will only include core 1.4 functions. Which sucks for games, of course).
And about half as fast, of course.
ICDs will work, as taylor said. But if Microshi Microsoft provides IHVs the info necessary to write drivers that work with the Vista desktop, they could easily do it. I'm guessing that MS just didn't want to do this in the beta stage yet, and someone simply panicked, and thought that MS is going to try to kill OGL (this wouldn't be their first attempt). First of all, in the EU at least, MS can be forced to provide software developers the code required to make their applications fully compatible with the operating system (just like MS software). Second, OpenGL is still the api of choice in every field except games. MS put OGL support into Windows NT to lure customers who needed OGL for professional simulation away from other operating systems. But, at the same time, they wanted OpenGL to stay in that field and never come to the gaming market, where they wanted D3D to be the only api (which was optimised for software rendering, and sometimes this origin caused problems when 3d accelerators came out, e.g. the way D3D stored vertex information was not optimised for modern 3d cards, while OpenGL's method was). So they told everyone that OpenGL was too slow for games, and was good for CAD only, whereas D3D is not as precise as OGL, but faster, and therefore well suited for game development. Which is of course BS.
D3D has been improved to the point where the difference in performance is very small, and depends more on the game. (I'm guessing FSO is optimised for OGL, right?). BUT all that effort put into making a software 3d api into a modern 3d api comparable to OGL in performance is just a waste. And I still hate D3D's approach to coding, where you have to decide what code will be best suited for the target machine. OpenGL does that for you (you give hints to the driver, like GL_Hint_Fastest or GL_Hint_Nicest). This requires a good driver of course, but NVidia has a habit of making good ones. And the less code you write, the less you have to debug, and the faster you'll be done.
If I had to choose between compositing and nice glass effects and opengl, I think you'll guess which one I'd choose. But I really doubt I'll have to make that choice
-
Two things.
D3D9 and below will also be going through WGF. So it's in the same boat as OGL. OF course, the new WGF system (aka D3D10) will have the access chewy gooey graphics cards.
Second. How do I enable antialiasing in OGL mode without having it explode the videos? I'm using the CVS 1/16 build with the beta MediaVP. There's no built-in option in the launcher to enable OGL AA and forcing it in the control panel makes the videos just display a black screen.
-
I'd be very interested in an OGL AA option as well. The control panel one doesn't seem to work very well.
-
I used to be able to "force" AA using Nvidia's control panel under OGL with the 10/28 build. All builds afterward disabled it.
-
I also recently noticed that forcing the AA is not working anymore. None of the modes have any effect. They work in D3D mode though.