Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: stofer on February 14, 2006, 01:03:11 pm
-
Many years ago I played the Freespace 2 demo and absolutely loved it. I could never find the game in stores so I was pretty happy to discover that I could now play an updated and modded Freespace 2...for free.
However I was pretty suprised when I read the installation guide (http://www.hard-light.net/wiki/index.php/Installing_fs2_open") in the wiki when I saw this line: "with Catalyst drivers above 4.3, shinemaps will not work in Direct3D. However, environment mapping will not work in OpenGL."
So in order to get the best performance I should downgrade my Catalyst drivers to version 4.3?
I'm sorry if this is a stupid person, or if I posted this in the wrong forum, but downgarding to drivers this old sounds like it will cause all sorts of problems for other applications. Of course I'm prepared to do it for the optimum performance. After all, I'd like the game to look as good as possible.
-
Env mapping is broken on D3D at the moment anyway. Just play on OpenGL instead and leave your drivers as they are.
-
Thank you for the quick reply :) I'll just stick with my current drivers then.
-
Can we just officially drop D3D support already? :p
-
Bobboau.
-
Hasn't coded in months.
Should learn OGL anyway.
Isn't above anyone else, despite the godly praise he receives.
-
render-to-texture
environment mapping
-
cross platform compatability.
is already ported to OGL.
-
render-to-texture
Not a valid reason to keep the broken D3D code. It's working in OGL anyway, just not in CVS since it really needs other changes to prevent link problems.
environment mapping
Also not valid, it's broken in D3D anyway. Plus it is also in experimental OGL code. It's just waiting for the gl function upgrade for RTT before work continues on it.
Not that I really care one way or the other about the fate of D3D support. But as far as excuses go, those two things aren't very good arguments for keeping broken D3D code around. If no one is going to work on D3D code then it's basically not supported anyway so the discussion is moot.
-
I motion to drop D3D support. Can I have a second?
-
I motion to drop D3D support. Can I have a second?
here! (or do you want a coder?):nervous:
-
here
but how exactly would it benefit us?
-
I don't really care either way. D3D is only useful in pre-3.6.7 builds anyway, where the environmental mapping works. That being said, it works just fine if the environmental mapping is turned off, so I don't see any harm in leaving it there even if it's not going to be updated. I seem to remember someone here saying a while ago that he was using D3D because OGL was not rendering correctly for him or something; there may be some obscure hardware configuration out there that works better with D3D.
-
I seem to remember someone here saying a while ago that he was using D3D because OGL was not rendering correctly for him or something; there may be some obscure hardware configuration out there that works better with D3D.
Which is about the only real reason to keep it at this point. The problem of course is that D3D *does* have to be updated when new graphics capabilities are added, otherwise it will either not work at all, or just not compile. When it gets to the point that D3D is actually slowing down the use of new features is when I'll second the motion. Until then I'm just hopeful that someone will come along and help us out in that area. With D3D gone there is no longer a reason to keep the multi-API rendering engine, which would make things a lot easier on us, but could come back to beat the crap out of us later if we did want to support an additional API again.
I'm more of the notion to completely drop non-HTL support rather than D3D at this particular point in time. Right now non-HTL doesn't work properly (ie. it crashes, period), isn't easily fixed, makes it more difficult to fix some graphics issues, and just generally gets in the way. D3D still has a ways to go before it's that much of a bother.
-
The only reason I'd favor dropping D3D at this point is threads like this (and those "OGL looks different than D3D"/"funny colors in OGL" bugs that keep appearing in Mantis). The only reason that I'd say leave it is if OGL support in Vista is going to be as absolute crap as everyone seems to think it is. So it's a toss-up for me.
-
How about we keep it in and just drop it from the launcher instead? That way we can still suggest it to people who have a problem but most people will go straight to OGL.
-
I'm more of the notion to completely drop non-HTL support rather than D3D at this particular point in time. Right now non-HTL doesn't work properly (ie. it crashes, period), isn't easily fixed
I'm surprised this hasn't been done already. It's commendable that you guys are trying to keep it in, but really what's the point? If people require non HTL support point them at an earlier stable release in which it does work.
-
I'm inclined to agree.
While it's up to you - I'd go with this as the course of action:
Create a stable D3D build at this point and freeze it. Do nothing more to it. Make it the last time that D3D be supported. That way if people really want D3D then they'll have a stable build to play with.
Cut D3D entirely out of future builds and focus on OGL entirely. If people ask about D3D then point them to the frozen final D3D build and point out that although it works, it doesn't include any features newer than the date on which it was created.
The result being a stable option for those who want D3D, and the evolution of the OGL build that is so badly needed yet held back by forcing yourselves to keep D3D in.
-
That would work but I think it's better to wait at least until the next major official release for this (3.6.8 or whatever). The current builds have a number of other problems at the moment and this final D3D build may be used by some people for a long time in the future, so it's better to make sure everything else works properly.
As for non-HTL, I agree that it should go at this point. It would have been nice to keep it so anyone who could run FS2 could also play FSO, but it's been broken for quite a while now.
-
Just how old a video card do you need to have anyway to not support HTL? My old comp with a Geforce 3 works just fine with HTL, so it would have to be older than that. Honestly, I can't see people with that old a system being able to properly run FSO anyway, so why bother? No matter what you do, there's always going to be retail to fall back upon for people with truely ancient systems.
-
Just how old a video card do you need to have anyway to not support HTL? My old comp with a Geforce 3 works just fine with HTL, so it would have to be older than that. Honestly, I can't see people with that old a system being able to properly run FSO anyway, so why bother? No matter what you do, there's always going to be retail to fall back upon for people with truely ancient systems.
Not ancient... cheap. This gorramn intel chipset on my laptop isn't HTL compliant. And it sucks.
-
Ick, ok, I admit I failed to consider on-board graphics. Never did trust those to do a proper job. Can fix that for less than the price of your average game these days though, quick check tells me a GF MX 4000 can be had for less than 40$ :p Well, for desktops anyway, obviously laptops are a different story.
I guess the conclusion of the day is that Intel = Suck. At least for graphics.
-
[q]Just how old a video card do you need to have anyway to not support HTL? My old comp with a Geforce 3 works just fine with HTL, so it would have to be older than that. Honestly, I can't see people with that old a system being able to properly run FSO anyway, so why bother? No matter what you do, there's always going to be retail to fall back upon for people with truely ancient systems.[/q]
Something older than a GF256 I guess, since that's where it was first introduced. I have some old cards that probably won't support it, although they're either collecting dust or are in my retro game system that I only use for Glide and DOS stuff.
Retail doesn't have all the extra sexps and gameplay related features, so any missions using those will only work with FSO.
-
I'm beginning to wonder which is better: Keeping on the few who still run something older than a GF256, or gaining a lot more by having the most up to date and advanced features possible.
I have a funny feeling that by keeping things limited to allow the FSO to be played on an original spec machine, one is sacrificing a much larger audience with more advanced PCs.
I know there are some sweeping generalisations there, but something tells me I'm right.
-
i'd be happy with just openGL only, i mean, since a couple of the nicer looking games that have recently come out have used it (doom 3, quake 4, etc) means it's still quite the api to use for some time to come.
just... be careful with the spec mapping lest it look like plastic :p
-
same here. OpenGL apparently uses a hell of a lot less memory than D3D since it doesn't have all the memory leaks. :p
-
I have a funny feeling that by keeping things limited to allow the FSO to be played on an original spec machine, one is sacrificing a much larger audience with more advanced PCs.
Well taylor and I have both thought about investigating some sort of "dual-boot" thing where the game could use either the up-to-date engine or the original DX5 engine. That's one of those "maybe one day I'll get around to it" sort of things, though. You never know, it could happen - just like multiple docking. :)
-
So I'm correct in assuming that there's still no hope for ATI users to get Shinemaps working at all. Also, am I correct in assuming that Environement Mapping is the same thing as Shinemaps, just that Shinemaps work in D3D and Env Mapping works in OGL? If Env. Mapping worked, would that yield the nicer lighting ingame?
-
So I'm correct in assuming that there's still no hope for ATI users to get Shinemaps working at all. Also, am I correct in assuming that Environement Mapping is the same thing as Shinemaps, just that Shinemaps work in D3D and Env Mapping works in OGL? If Env. Mapping worked, would that yield the nicer lighting ingame?
Unfortunately that's pretty much all wrong. Shinemaps work for ATI cards - in OGL mode. Shinemaps and environment mapping are quite different things (shinemapping gives specular effects, so some surfaces reflect more light than others, environment mapping gives you reflections of the background but doesn't treat light sources specially). Ordinarily they would be complementary, if they worked together.
-
hehe.. I stand so corrected. Thanks.
The reason why I asked was I've seen screenshots taken with people using nvidia cards, and they have these eerie-looking blue-ish reflections on the ships and such, but for me, it's looked just like retail. Certain effects DO work in OGL for me, but I'm not clear on what produces those nice shadows and reflections. I recall that if I did downgrade to 4.3, I WOULD get the nice reflections, but anything above and it looks like retail.
-
With spec and glow mapping enabled it doesn't look anything like retail IMHO, but what you're describing is environment mapping. It still works in D3D, or it would if it weren't currently broken.
-
-ambient_factor 75.. put that to the command line (custom flags line in the launcher).. with default ambient_factor it looks pretty close to retail even with glow sand spec enabled..
-
-ambient_factor 75.. put that to the command line (custom flags line in the launcher).. with default ambient_factor it looks pretty close to retail even with glow sand spec enabled..
:yes:
Anything under 100 looks far better than the default, really. When I first started using OGL mode I thought it looked like crap compared to D3D, and it was solely because of the default setting for this.
-
I tried D3D and OGL on my Riva TNT2 which is now in the trash pending new computer.
On D3D, before it stopped working with newer builds that were released Q4 of 2005, the game did look prettier, and rendered better on screen than with OGL. Ambient factor regardless.
It's hard to explain the difference. It had a lot to do with the edges being drawn nicely in D3D while always sort of... *shifting* in OGL. OGL was stable though, rendered exactly like retail (when I say rendered, I mean behaved exactly as retail did, of course, not with the added graphical functions) D3D crashed with anything near-complex on screen. But it did look prettier.
I ended up using OGL though, no crashings and better FPS was far preferable to a more polished look in the game, considering the ancientness of the card.
At any rate, sounds like it'd be a good idea to drop D3D alltogether. No hassle with the end-users, no hassle with the coders. Simplification = good.
Just my 2 cents.
-
I think all of the "D3D is better than OGL" topics all boil down to the fact that D3D does and has always done better with texture scaling than OpenGL in almost all standard driver packages. I don't know why, but there are a ton of games that exhibit the exact same behavior. And the problem is old; it's ultimately very similar to the super-low-res texture bug in HW1, only affecting maps scaled down rather than maps scaled up.
-
Well, what a goof I've been for the past little while. I didn't have specular turned on in the launcher, so I enabled it and started playing, I have the nicer colored lighting that I thought ATI users couldnt' have. That, and I think a long time ago I heard that specular was a huge performance hit, so I left it off. I've got it on now and everything plays quite smoothly, and looks much better.