Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: ARSPR on May 05, 2006, 01:46:01 am
-
Well, I think this one goes to Taylor.
Yesterday I updated nVidia drivers from 84.25 to 84.56, and FSOpen didn't work. Then reverted to 84.25 and FSOpen didn't still work so I thought I was going to get mad.
Finally, I noticed that the problem is that if you run FSOpen in OGL with a higher colour depth (32 bits) than Windows desktop (when ForceWare is installed, it defaults to 16 bits), FSOpen has a funny error saying your OGL version is 1.1 and you need 1.2 (although the driver and card are 2.0.1). There's no problem if you run FSOpen in 16 bits with windows desktop in 32 bits or if both have the same colour depth.
So:
+ Did you know about it? Is it a FSOpen bug or a nVidia driver bug? Should I mantis it?
+ I've got a AGP 7800GS card with 84.25 drivers. Can anyone with another card/driver version make a try?
+ Does it happen with ATI cards too? (Please, someone make a try)
+ Does it happen with other OS than Windows?
(I'm at work so I haven't searched about this topic. Forgive me, if it has been already spotted).
-
I don't think that I've ever noticed this before. It just looks like an OpenGL init error, where it's falling back on the software renderer (that has happened before). It's been a while since I've run the Windows version of FS2_Open so I'll have to fire up my Win2k box and see what I can find here. I probably just need to tweak the WGL init a little and that will be that. But if you can, please post a debug log for me to look at, it should provide me with some interesting info.
-
I'll post the fslog from latest Redmenace's debug build ASAP (probably this afternoon) and also the error mesages I get (copy-pasted in a text file).
But, "Attach file" has disappeared from "Additional Options ...". So how do I do it? Do you prefer that I open a mantis bug?
-
Do you prefer that I open a mantis bug?
Yeah, go ahead. You can just attach the log file there. I'm working on something else OpenGL related right now (and for the next few days) but I'll try and get this problem fixed over the weekend if at all possible.
-
Well, I've mantised all the info in bug nº 902 (http://lore.maxgaming.net/~scp/mantis/bug_view_advanced_page.php?bug_id=0000902)
If you need more info please ask.
-
I think this is acutally a windows issue. You can't create a 32-bit window if your desktop is set to 16-bits.
-
But I'm running FSOpen in full screen not windowed.
-
its still a full-screen window.
-
Well, I don't know ANYTHING about coding so surely you are right. But:
+ In D3D it seems there's no trouble with desktop at 16 bits and FSOpen at 32 bits.
+ I've tried FarCry (D3D game) that has only 32 bit option and it also runs fine. (I don't have any other OGL game so I can't make tries with this one)
-
Well i don't know anything about coding in d3d, so i can't say anything about how that works.
-
Part of the problem is just our code. We are still using the old API for setting up the visual rather than the newer WGL API. And since we no longer even support cards which don't support the WGL API there is no real reason to not fix it. Other than time that is. Doing what we do now doesn't really provide all pixel formats that are available, that's why you are getting a pixel format that isn't compatible with your OpenGL drivers and drops you down to the software renderer instead. The code just needs to be beefed up to handle all of this properly, and to make sure that you are given a sane pixel format in the end.
I've been holding off from doing the code upgrade myself since, at some point, we'll move to using SDL on Windows and the extra Windows init code would be obsolete. Given this issue though (and others for that matter) I suppose it's time to move it up on the todo-list priority scale. I'm busy working on other things this week but I'll try and find some time to write up the new code.