Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Test Builds => Topic started by: taylor on December 30, 2004, 05:09:55 am
-
This is basically a test for 3.6.5 bugfixes and a couple of OpenGL things. All of this is ready for CVS on my end so if all works for the first couple of people then I'll commit. Changes are as follows:
- OpenGL spec mapping. Needs to be tested by everyone. ATI users make sure this works too. I think I've gotten all of the bugs out but if not you will be looking mainly for strange errors when viewing capships at certain angles and parts of the HUD going dark.
- The -novbo should no longer be needed. I've worked around the memory overwrite issue with VBOs and multitexture. The -novbo option is still there if you want it but using VBOs will give you a bit faster rendering, especially with hi-poly models. This was an OpenGL only problem so if you don't use OGL then ignore what I just said.
- Speed improvement for OpenGL frame flips. Don't know how much help this will be exactly but you may get a couple of fps boost out of it.
- Movies should play again. Wrong type specifier was used which caused the filename/path not to be converted to wide-character string properly.
- Fix issue with the pilot upgrade prompt always showing. There were two problems here: 1) the file handle was never closed so the old file couldn't be deleted after upgrade, and 2) due to some strange/random issue it would think the old file existed when it really didn't. I'm now using cf_exist() since it's a better solution anyway and should be a bit faster.
- Some OGG code changes. I mainly just moved some things around to make a little more sense and to provide a little help for me during the upcoming Linux code merge. After these changes I have been unable to reproduce the two OGG bugs in Mantis, no looping engine sounds and wrong hit sound. I didn't test before the changes however. Please let me know if this is actually fixed. If it's not then the tables and ogg files that don't work are going to be needed.
- An extra error check for Voodoo users in OpenGL. FSO requires a supported minimum texture size of 1024x1024 unless it's actually built to work for Voodoo cards. There will now be an error message if your video card doesn't support this texture size or higher. The error message is fatal so you will not be able play with an older video card. Sorry for the people who dealt with the rendering problems to still play but I want to squash future bug reports about these rendering issues.
UPDATED:
New build, don't want a new post on this though.
- capship turrets will shoot at asteroids now so you FSPort lovin players can rejoice.
- Made currently_enabled_lights for OGL dynamic, not that anyone cares.
- Work around nebula issue with ships being lit in fog. This isn't how I want it done but until I do it in a fashion that pleases my stubborness this should hold people over.
- updated to current CVS.
Also new is an option for a more realistic light model in OpenGL. The option is going in no matter what but I'm not sure whether or not to make it default or not. It will be a registry setting but for the purposes of this build it's a cmdline option: -rlm. It won't show up in the launcher though so you've have to put it in the custom flags yourselves. It is a little different looking and may be slower. It's not slower on my test systems but you never know. If no one likes the way it looks or it's too slow then I'll have it disabled by default.
Again the new (temporary) cmdline option for the new light model is "-rlm".
And now... the build: http://icculus.org/~taylor/fso/testing/20050103-win32.zip
-
Nothing new for us D3D users? :)
-
screw D3D. No shineys and I get better FPSage with OGL these days (and its quite stable too!)
-
Originally posted by Overlord
Nothing new for us D3D users? :)
The frame flip speed up will apply to D3D too but I didn't make the change for this test build. If there is some strange texture error or something because of it I didn't want to fix it in OGL and D3D. If it works fine here then when I put it in CVS it will be for both. Since I'm a Linux guy, if something doesn't help OGL (and therefore me) then I don't really care about it. ;)
Plus OGL is only really missing env mapping now but I've already got half the code in for that.
-
YaY
*downloads*
-
And like i've been preaching for the last wee(the K is optional :D ), OGL is better than D3D right now :)
Downloading
-
Originally posted by Hippo
preaching for the last wee
:lol:
Sorry, that phrase just struck me as hilarious. Sounds like a Scottish drinking song or something. :lol:
-
I'll drink a drink for me
I'll drink a drink for yous
And after another 12
I'll chuck up in the bogs
Or all over you
And when ye're all pissed
i'll preach a wee for youse
Makes Bob Dylan look a shower of ****e, eh? :D
-
:wakka:
Yes. It works even better when you cross-reference the Scottish and American definitions of "pissed" and "wee". :lol:
-
nice...OGL works flawlwssly for me...and is it just me or is the engine glow clipping bug gone ?
...or did it never exist in OGL ?
-
WHAT!? OGL SPECMAPPING!?!? THANK GOD!!!!!!!!!!!!!!!!!!!!!!!!!! Taylor you rule. harshly. Even if this doesnt work for me, props to you for trying. I want me shinemaps. I am shinemap deprived (ATI Radeon 9800 Pro)...*sniff* mmmmmmm....*downloads*
EDIT: IT WORKS!!!!!!! :D
I can't thank you enough. I don't care if there's bugs. LOL. None found yet though...
-
Before : (http://www.netcologne.de/~nc-muenchma2/glscreen00.jpg)
After : (http://www.netcologne.de/~nc-muenchma2/screen00.jpg)
Nice. Now I'll try some missions and let you know of the results.
Edit : uhm, that's the first mission in the nebula :
(http://www.netcologne.de/~nc-muenchma2/screen01.jpg)
The nebula has been just a blue wall before, but those ugly white squares on the Hercs are new. Using OpenGL with Radeon 9600 and Catalyst 4.4 (due to D3D), maximum graphics options. I'll try some reduced settings.
-
Just a second while I try nebulas myself. IF they dont have problems, then I suggest you upgrade to the latest Catalyst drivers like I have.
-
Originally posted by Gregster2k
IT WORKS!!!!!!! :D
Use an ambient factor somewhere between 75 and 78. Have Lightspeed's textures installed and load up a mission with a bunch of Shivans in it. I recommened "Into the Lion's Den". Approximately 1 minute and 32 seconds into the mission, in the inner corner of your left eye, a single tear will form. It's just beautiful. ;)
Originally posted by mitac
The nebula has been just a blue wall before, but those ugly white squares on the Hercs are new.
If you are using -2d_poof this it's probably causing the blue wall issue. That option is D3D only and in OGL it messes up. If you look around in the mission you will probably see a rectangle with all of the nebula bitmaps in it. The projection gets all wrong with -2d_poof, I'll go ahead a make sure that option gets turned off in OGL mode. If you are not using -2d_poof then let me know cause something else is wrong there.
White squares suck. I could have sworn the phreak already fixed that particular problem but I'll see if I'm missing something somewhere. If it's new then I may have changed something in the updated code that I didn't realize. I don't get that with my NVIDIA card but I'll try and track it down. You only get that problem in the nebula right? Does it happen anywhere else or with other textures?
-
By engine glow clipping do you mean the little white lines I see on the ends of the engine glows?
-
OK, theres no problems like the ones Mitac described, but I have an entirely different problem. All the fighters and ships are *BLACK* in that exact same mission (Mystery of the Trinity).
Im using -ambient_factor 75, by the way...and the sun in the nebula SHOULD still illuminate the ships...but it does not.
That's the only problem. EVERYTHING ELSE IS 100% WORKING AFAIK (W00T!) but in nebulae, the ships aren't illuminated by the sun. Have only tested Trinity to see if Mitac's problem occurred (it didn't.)
OpenGL VBO is NOT disabled (after reading that it is fixed). ALL graphical enhancements are on, including environment mapping, with the exception of PCX compression which is turned off.
Mitac, perhaps you could try turning PCX compression off, running out of video texture memory will do that but kinda sounds backwards to turn PCX compression off then LOL.
NOT using 2D-Poof here btw.
Catalyst Version: LATEST version (Radeon 9800 Pro)
----------------
In response to your (Taylor's) recommendation re. ambient factor: I installed the Z-Pack of the Media VPs cuz im lazy, and installed some of the latest HTL stuff (the "perfect" hercules with beautiful glowpoints and glows is one of them). I use 75 for "realistic" gameplay and I use 100 for between "realism" and "fs2" without compromising eyecandy.
Will try Into the Lion's Den, but can you look into that "ships are black in nebula" problem I've encountered?
-
I get a white square in the tech database. Just a small one though.
(http://img.photobucket.com/albums/v109/NarfPics/almost.jpg)
Also as soon as I try to go into the mission simulator, it gives me an illegal operation and quits.
I have a Radeon 9600 using Cat 4.4, I'm thinking the outdated drivers may be the problem here though.
-
it's.....it's.... beautiful...
-
Axem, I don't have those problems
(Radeon 9800 Pro and Catalyst 4.11)
NOTE: Just like 10 is greater than 4, with the ATI drivers, 4.11 is greater than 4.4.)
current officially released ATI catalyst version is 4.12.
Also, Axem, is your 9600 the normal 9600 or 9600 XT? The 9600 XT/SE whatever the heck it is called came AFTER the 9800 Pro and it is understandable that a driver set as old as 4.4 would cause problems with a more recent card like the 9600 XT/SE (again, whatever it is, either XT or SE).
Remember people, Taylor fixed our VBO so you can all turn it back on now...or off, if you think it IS causing the problem :)
Personally, I have mine on. I'll go turn it off and see if it fixes the nebula darkness-ness on ships ---- EDIT: IT DOESN'T. Meh...I don't care. I never paid much attention to details in nebula missions anyway, and this actually makes dem Shivans EASIER TO SEE. Ha. I'm not a nebula person, so this works for me. A minor annoyance until its fixed. At the moment, I'm so happy I got shinemaps (Star Trek compilation I made of Omni's conversions works even!) that I could care less about nebula ship lighting!
Did I mention I LOOOVE that new HTL herc with this build?
Now all I need to complete my fun is some experimental OpenGL shadowing code to screw around with...
-
Yeah, the way of numbering subreleases is kinda screwed up. (In reality 4.4 > 4.11 :p) But I don't upgrade cause I wanted my shiney in D3D.
Its just a plain 9600, no fancy dancy letters at the end of it.
-
Well you will upgrade if you want yer shiney in OGL!! PHEAR!
Err...Long Live Open GL? *grin*
...No luck yet with various settings. I'll try 2D-Poof now and see if purposely breaking the nebula fixes the lighting of ships inside it. More in a second...EDIT: Nope. Now I got black ships in a broken nebula. Meh. Might as well settle for what I had before. One last test....
Testing disabling of shinemaps *HERESY!!!* now...if this fixes the nebula then its definitely the shine code. EDIT: NOPE! Shinemapping has nothing to do with this nebula ship lighting problem...the ships are still dark, and I set my ambient factor to 175 (full bright)!!!
Meh, returning to normal settings...I don't care. Like I said, this isn't a huge problem. I can live with fully black ships in nebulae only. Everywhere else is beautiful...*sniff*
I say throw this code in Taylor...its a LOT better for OpenGL than what we had before, regardless.
-
Originally posted by Gregster2k
OK, theres no problems like the ones Mitac described, but I have an entirely different problem. All the fighters and ships are *BLACK* in that exact same mission (Mystery of the Trinity).
Im using -ambient_factor 75, by the way...and the sun in the nebula SHOULD still illuminate the ships...but it does not.
I tested the same mission without much issue. Ships aren't well lit by the sun but that's likely something with the fog. I'm setting emmisive light to get spec maps to look right so maybe that's causing a problem. I did notice that the Aquitaine is fogged in the hud tagetbox when it shouldn't be. Are you seeing the same thing? With fighters too?
I prefer a setting of 77 but I lowered it to 70 for this test and the fighters were very dark at a distance but when the spec shines on them or you're close enough they are fine. I'll try and play with the lighting a bit more and see if I can't find a better compromise.
And the -novbo option only fixed a bad crash and is a bit slower. It shouldn't have any affect on features or anything else. In some weird cases -novbo may actually be faster but that's because of crappy drivers.
The new HTL Herc is pure sweetness. I actually just followed a flock of them, staring into the cockpits, trying not to be noticed. I didn't even care that they were enemy fighters attacking the ship I was supposed to protect. Kinda sad really. :)
-
(http://img32.exs.cx/img32/3654/aquitaineunlit5jt.jpg)
"Mystery of the Trinity" - Unlit ships in nebulae in Taylor's 20041230 OpenGL test build
Fog still works nicely, looks as it should, big soupy mess. Just like good old times. Mmmm. Covers the ships normally. All thrusters show up perfectly. Using the Z-Pack media VP.
Look above:
Taylor, the fighters and ships are *black* no matter HOW close I am to them. I can be smashing into them, even. No matter what distance, they are black. In nebulae only, ALL ships are just plain black. Black, no matter whether its specular or not, whether or not scaling of lighting is at zero or 1000, it doesn't matter. ALL THE SHIPS ARE...BLACK.
LOL, Mitac's nebula looks like crap but his Aquitaine is lit. My Aquitaine and all fighters and everything made out of a 3d model (shivans included)... completely black. again, the nebula itself is perfect.
Opposite problems eh? LOL
Everywhere else, all ambient lighting and glows and shines and everything works F L A W L E S S L Y.
-
GTF Hercules (HTL glowpointed) - Taylor's 20041230 test build - techroom screenshots at 1600x1200 resolution compiled into a 1024x768 desktop wallpaper
(http://img153.exs.cx/img153/5250/dontcallitamig5hm.jpg)
*cries* We have achieved cutscene quality, folks, already. All we need now is native 1280x1024 resolution support, for that is the native res of my LCD flatpanel (17")...the above ones are 1600x1200 (were hard to take though)...it looks...like...*looks again*
damn....
This new OpenGL code has GOT to go into CVS.
-
Originally posted by Gregster2k
Taylor, the fighters and ships are *black* no matter HOW close I am to them. I can be smashing into them, even. No matter what distance, they are black. In nebulae only, ALL ships are just plain black. Black, no matter whether its specular or not, whether or not scaling of lighting is at zero or 1000, it doesn't matter. ALL THE SHIPS ARE...BLACK.
Freaky. Alright I'll work on this tonight. There is certainly something wrong here and I don't know if it's driver related (something I need to work around) or if I just missed copying something from my unstable code tree. The nebula is drawn unlit no matter what so this problem would only affect models. Also note that models in the hud targetbox are rendered without specmaps (for speed) and without special lighting so the fact that they are black points to another problem. I made some changes to how lighting is handled in order to have specmaps look good so how light settings get changed during and/or between the rendering passes may be causing this.
-
Awesome man. I could say you've done enough already, but that would be very biased seeing as I hate nebulas anyway and don't care ALL that much about the looks of a ship stuck in one...i suppose theres people out there unlike me who looove their nebulas ^_^ By the way...does this wonderful build have TruForm code (npatches) in it?
-
a few probs here (radeon 9000, 4.12 catalysts)
it's in the nebula missions, obviously..
without the 2d_poof tag
(http://img.photobucket.com/albums/v625/Turnsky/screen05.jpg)
with, the 2d_poof tag
(http://img.photobucket.com/albums/v625/Turnsky/screen06.jpg)
this is from homesick, since it was the only one that had a nebula mission on hand. :nod:
-
Originally posted by Gregster2k
By the way...does this wonderful build have TruForm code (npatches) in it?
Nope. I don't think that code ever made it to CVS as a matter of fact. The cmdline option is there but it doesn't do anything. I keep meaning to ask Bobboau about that but always forget. On my OpenGL wish list right now I've got envmaps, shadows, TruForm and settable anisotropic filtering in that order. Probably won't get done in that order but functional envmapping in OGL shouldn't be far off.
@Turnsky: 2d_poof is known not to work in OGL and it probably never will. I'm going to make it disabled when in OGL mode so that it's not rendered wrong. The hull intersects like in the first picture are annoying but I don't think it's going to be fixed any time soon.
-
This might sound incredible but...okay maybe it doesnt but...ive been deprived of shinemaps for so long that your build made me forget environmental mapping even exists at all LOL
Re. the two screenies above. I get the exact same effect to the nebula when I turn 2D-Poof on.
-
Originally posted by Turnsky
this is from homesick, since it was the only one that had a nebula mission on hand. :nod:
Ooh... underwater missions. ;7
-
Originally posted by Goober5000
Ooh... underwater missions. ;7
dude.. now that's an idea! :nod:
-
Coming Soon...
(http://tvwp.hard-light.net/misc/seasick.jpg)
A Deus Ex Machina Production
:drevil:
-
hmm... speaking of wich.. i made this a while back
(http://img.photobucket.com/albums/v66/FireCrack/CarrierRach.jpg)
to scale (more or less)
[/hijack]
-
Originally posted by Gregster2k
This might sound incredible but...okay maybe it doesnt but...ive been deprived of shinemaps for so long that your build made me forget environmental mapping even exists at all LOL
Re. the two screenies above. I get the exact same effect to the nebula when I turn 2D-Poof on.
For all future references:
2d-poof is not supported in OGL-mode
Thanks for your attention, this Tri-Op public relations.
-
Alright, I followed your suggestion and disabled 2d_poof. It brought back the nebula, but I still got those white squares. Seeing that Axem got the exact same drivers with the exact same problem on the exact same video card, I'll try and upgrade my drivers. Thanks for the help!
Edit : ah, and to Goober & Firecrack : those pics are hilarious. ;)
-
www.huiswerksite.nl/fsoscreens/
There, a complete comparision of OGL and D3D.
-
Updated to 4.12, changed nothing else except the 2d_poof setting. The white squares are gone, so it's probably just a driver issue.
taylor, may I suggest you edit your initial post and include that information? Ah, and btw : thanks for the spec. :)
kasperl, I suggest you also try and update your drivers, since yours are just plain old. 6387 = Catalyst 3.8.
P.S. : Kind of ironic, eh? Catalyst 4.4 breaks shinemapping for OpenGL. ;)
-
Yeah, odd. I'll update.
-
Originally posted by kasperl
www.huiswerksite.nl/fsoscreens/
There, a complete comparision of OGL and D3D.
I too noticed some differences in D3DvsOGL shinemapping, in OGL the whole poly gets lit a tad more, making it look more faceted.
-
Originally posted by Col. Fishguts
I too noticed some differences in D3DvsOGL shinemapping, in OGL the whole poly gets lit a tad more, making it look more faceted.
Is that affect better or worse? I've set the shininess to 65 though values of 85-90 appear to match D3D better. I made it 65 because I think it looks better but that's just my opinion. If you'd rather have it more D3D like then let me know.
Here is 65 (current code):
(http://icculus.org/~taylor/fso/pics/spec65.jpg)
Here is the same basic shot with 85:
(http://icculus.org/~taylor/fso/pics/spec85.jpg)
-
what the hell is 2D-POF?
-
Originally posted by taylor
Is that affect better or worse? I've set the shininess to 65 though values of 85-90 appear to match D3D better. I made it 65 because I think it looks better but that's just my opinion. If you'd rather have it more D3D like then let me know.
Hard to say, it's a matter of personal preference I think. And we are all used to the D3D shiny look.
So...err....what have the others to say ?
-
Personally, I prefer the D3D style.
-
Originally posted by Drew
what the hell is 2D-POF?
2d_poof is an option used for rendering nebula to not use HTL. Basically it restores to default look by not rendering the bitmaps in 3D space. You can check out Mantis bugs 167 and 168 which deal with this. I mostly fixed the overwhite problem and magnification pixelation in OpenGL so the 3D version looks much better than it did.
Originally posted by mitac
Personally, I prefer the D3D style.
I changed it to 90. It's never going to match D3D exactly though. The numbers in OpenGL go from 0 to 128 with the lower end being a less focused and broader light and the higher numbers being more focused and narrower light. Just in case anyone cares. :)
If it really turns out to be a big deal then I can make it a settable value or something later.
-
I think 65 looks better, actually. To me, 85 looks even less like D3D, it's darker with not as much shine.
-
Originally posted by WMCoolmon
I think 65 looks better, actually. To me, 85 looks even less like D3D, it's darker with not as much shine.
That screenshot just doesn't do 85 much justice. It's still got the same amount of shine it's just more focused. At the angle of the model it doesn't show that very well. It still looks good in game though. My vote is still for 65 but I'm happy either way. I might lower it to 80 when I commit the code and change it later if the populous revolts.
-
Could you code it so it accepts a parameter just like the ambient factor?
For all the debates about shinyness and metal/plastic/matt ships, that option would be a godsend solution enabling everyone to set it to their taste.
Just my 2 cents - WONDERFUL progress you made in this regard BTW.
-
Originally posted by Flaser
Could you code it so it accepts a parameter just like the ambient factor?
For all the debates about shinyness and metal/plastic/matt ships, that option would be a godsend solution enabling everyone to set it to their taste.
There will most likely be an option but not at first. If an option like that were put in place then it should affect OGL and D3D equally. I'm not familiar enough with the D3D code to start making changes which may be visually harmful. I don't want to put something like that in just for OGL now only to have what it does change in 2 months when D3D makes use of the same option.
It's also possible that a future material and/or shader system would do a better job of setting this stuff. I'll send Bobboau a quick message after the weekend and see what he says. If he doesn't think it's a bad thing to do then we should be able to come up with something that works well for both OGL and D3D pretty quickly.
-
well, what about the fade on the ships?.. they don't fade out too well in nebulas...
it's a pity about 2-d poof not working, but them's the breaks.. at least i gets the shinies. ;)
-
Originally posted by Turnsky
well, what about the fade on the ships?.. they don't fade out too well in nebulas...
No they don't and that kinda pisses me off whenever I see it in mission. I want to say that's be discussed before but I don't know for sure. I'll have to check on that one again. It's not very high on my list of things to fix though, not being a big nebula fan.
-
Originally posted by taylor
No they don't and that kinda pisses me off whenever I see it in mission. I want to say that's be discussed before but I don't know for sure. I'll have to check on that one again. It's not very high on my list of things to fix though, not being a big nebula fan.
i like my neb missions, only because how cool it looks when a ship comes out of the fog, particularly the sath when you first see it.:nod:
just outta curiousity.. what is on the higher levels of your to-do list? :p
-
Originally posted by taylor
Is that affect better or worse? I've set the shininess to 65 though values of 85-90 appear to match D3D better. I made it 65 because I think it looks better but that's just my opinion. If you'd rather have it more D3D like then let me know.
Honestly, I don't like them that low, but since I rarely if ever use OGL, I guess it isn't important to me. There's no command line argument for it?
-
This is odd....im noticing very little different from the normal ambience to that of ambient_factor 75.......
I'll see if i can get screenies later...
-
nm that. another issue: I'm getting MASSIVE load times in OGL and D3D for this, especially while playing Inferno. Is this normal at all? I'm currently at the mission where the Diablo shows up and wastes everyone, but even the earlier missions load slowly. It can't be the .ibx models because the second time it loads after I die, its STILL slow.......
-
On my dads rig, using LAN multiplayer, this builds sometimes hangs when in debrief of a multi mission. The screen goes all stripy, like two frames got mixed in some kind of "blinds" effect. If an options screen pop ups, you get a green-blueish background instead of the acutal image. This has already been reported. It happens when you press pause during a mission, for instance. It happened on my Radeon 9800, but NOT on my brothers computer. (GF2, P4 1,2Ghz, 384MB RAM, Windows ME). I also think I saw it happen on my dads rig. (Radoen X800, AMD64 3k+, 1GB DDR, winXP home). Me and my dad ran OGL, my brother D3D and OGL. It happened on OGL nor D3D on my brothers computer.
Also on multi, even during LAN play there is some stutter for some ships. Which is odd, since all object updates were set on LAN, and it's a 100MBit network. Loading times were good here,but these systems shouldn't show any slowdown on any game, so they're useless for checking slowdowns.
-
Originally posted by Turnsky
just outta curiousity.. what is on the higher levels of your to-do list? :p
- Linux/OSX code merge
- working for Windows
- Mod requests (not going to elaborate)
- Official Linux and OSX releases
- cmdline pilot conversion tool to change between various pilot file versions
- fully document pilot file and campaign savefile changes since original release
- OpenGL env mapping
- Ultimate removal of DevIL dlls as a requirement for OpenGL
- more dynamic allocation of various structs
- try and cut overall memory footprint by at least 10%
- more profiling data to help fix slow points in the code
- have every bug currently assigned to me in Mantis fixed or closed
... ( goes on like that for a while )
- try and fix ship outlines and fogging in nebula
... ( I'll spare you the next page )
Originally posted by Singh
I'm getting MASSIVE load times in OGL and D3D for this
As much time as I've spent fixing slow loading it better not be slower!! What is the official 3.6.5 like speed wise? Compared to the 3.6.5 beta?
I would like to see those screenshots too. There should be a deffinite difference with the various ambient factors.
Originally posted by kasperl
On my dads rig, using LAN multiplayer, this builds sometimes hangs when in debrief of a multi mission. The screen goes all stripy, like two frames got mixed in some kind of "blinds" effect
Feaky. Does 3.6.5 do this too? Does this only happen in OGL or does D3D show the same thing? Does your dad's box hang only on the debrief or in mission too?
As far as the popups and stuff go it's a known problem with Radeon's but I've never been able to recreate it. I haven't figured out what to do to fix it since everything I do will end up breaking NVIDIA in a similar way. I'm going through ATI's docs on their website but I'll probably have to track down a Radeon to test with before I can make a fix.
For slowdown stuff let me know if you are using all of the MediaVPs. The current set still doesn't have all of my memory conservation recomendations in it and with a few minor changes could have about 30 megs shaved off of every mission. I'm betting that the slowdows are just memory issues with Windows hitting the pagefile too much. Could be build releated though so I'd like to rule something out.
-
I'm using all the VP's and stuff, but the stutter is more of a ship jumping 20m in a milisecond, like in lag, then low FPS. FPS is at a steady 120 most of the time......
It only hagned during debrief, and even then not all the time.
365 worked pretty ok on it IIRC, but heavy testing is rather hard, since my dad is somewhat picky about allowing people on his computer.
-
I just found out that I can actually fly through Sobek class corvettes with that new build, regardless of the mission. I have not yet checked other capships, but I found that worth mentioning.
-
Originally posted by mitac
I just found out that I can actually fly through Sobek class corvettes with that new build, regardless of the mission. I have not yet checked other capships, but I found that worth mentioning.
Yeah, it's something with the model. Same problem gets mentioned in the 3.6.5 MediaVP thread too.
-
....probably furbared bounding boxes IMHO.
-
I was somewhat mistaken by the ambient lighting. It is indeed correct...apperantly, i had some other settings on which made it look different :nervous:
further proof of the matter:
bewarned! >200kb, and massively large!
(http://img.photobucket.com/albums/v107/anandraj/Lilith.jpg)
-
Imputiny, meet Mr. Stiletto and his little friend, Mr. Maxim and Mr. Kayser.
-
Originally posted by Moonsword
Imputiny, meet Mr. Stiletto and his little friend, Mr. Maxim and Mr. Kayser.
also, meet mr helios, who wants to be your aquiantance.
-
:p
I have another one of the herc....hmm...maybe should create a seperate thread for this :D
-
Originally posted by taylor
Yeah, it's something with the model. Same problem gets mentioned in the 3.6.5 MediaVP thread too.
That's a problem that was pointed out, about the max to pof converter. You'll notice that the turrets are shown as obstructed when they are in view, and unobstructed when they should be obstructed. :blah:
-
Originally posted by Raa
That's a problem that was pointed out, about the max to pof converter. You'll notice that the turrets are shown as obstructed when they are in view, and unobstructed when they should be obstructed. :blah:
Ah. I will say that it doesn't have to be fixed anytime soon though. The insides of a Sobek is a rather nice place to hide when you have need of such a thing. ;)
@Everybody: The build has been updated so check the first post. And there is a little something just for you in there Turnsky. :)
-
Originally posted by taylor
Ah. I will say that it doesn't have to be fixed anytime soon though. The insides of a Sobek is a rather nice place to hide when you have need of such a thing. ;)
@Everybody: The build has been updated so check the first post. And there is a little something just for you in there Turnsky. :)
this, i've gotta see
-
hmmm...dont notice any difference with the new lighting stuff. perhaps its my eyes but here's a pic from the FSport anyway:
(http://img.photobucket.com/albums/v107/anandraj/newlightingtest.jpg)
-
i did notice a difference, the abscence of shield and escort guages ingame
-
Originally posted by Turnsky
i did notice a difference, the abscence of shield and escort guages ingame
any energy guages too.
-
Originally posted by Turnsky
i did notice a difference, the abscence of shield and escort guages ingame
Damn. It's more up-to-date CVS wise than the previous build and has some more of WMCoolmon's HUD stuff. Something must have broke since the last update. Should have noticed that before posting. Sorry.
dont notice any difference with the new lighting stuff
Load up a mission like "The Sicilian Defense" and take up a position where that Sobek is on the right side of the screen and the sun is on the left. When you move the spec reflection on the Sobek will move too. With -rlm the lighting is true so the light won't change any since the Sobek and sun aren't moving. I think this is the same way that the D3D code is doing it. There are many more lighting calculations with this though so the more ships, especially hi-poly ones, that are on the screen the more chances for a big slowdown. If your video card can handle all of this then you probably won't notice. If it can't then you'll definitely notice.
-
With Galactic Emperor's shine maps you're not bound to see to much of a difference since what he made was more of a shine highlighting than actual mapping what Lightspeed seems to do.
-
i saw the the lighting, very nice. :)
-
Originally posted by taylor
UPDATED:
New build, don't want a new post on this though.
- capship turrets will shoot at asteroids now so you FSPort lovin players can rejoice.
Do you know any of the details of this? Is it: a ) a command line addition, b ) a mission flag, c ) controled on an individual ship basis within each mission by a box in the ships editor, d ) controled by enable/disable sexps, or e ) is this just a blanket enabling? I am concerned over this because since FS2_retail turret AI could not target asteroids and certain FS2_retail missions were ballanced to account for this. Suddenly allowing all turrets to fire on asteroids for missions such as these would break ballance. Please fill us in.
-
Originally posted by Trivial Psychic
Suddenly allowing all turrets to fire on asteroids for missions such as these would break ballance. Please fill us in.
Originally it was going to be a mission flag but it was decided that the one or two missions in FS2 OC probably should have had this working. The briefing said so anyway. Part of this code was already there so :v: may have just screwed up and not finished the changes from original FS1. The new code will only fire lasers, dumbfire missiles and AAA beams at asteroids and is balanced as close to FS1 behavior as I can get it. Bombs and other ships will be preferred targets over asteroids by all turrets per FS1 behavior.
If this does cause a balance problem though please file a bug on it. It has been tested and doesn't appear to make much difference in original FS2 missions but if you notice otherwise then it will be made into a mission flag.
-
i had a look at a neb mission, (played "mystery of the trinity over again") looks sweet, had to exit to check if i hadn't put 2d-poof on by accident ;)
-
minor problem: Brightness doesn't seem to return to normal after exiting from the opengl engine. It stays bright.
-
Originally posted by phatosealpha
minor problem: Brightness doesn't seem to return to normal after exiting from the opengl engine. It stays bright.
What's your video card and driver version?
This has been reported before but I'm not sure why it's happening. The code does tell it to reset on exit so it should return to normal. You can use the -no_set_gamma cmdline option and it will avoid setting the gamma completely. Not the best solution but maybe it will hold you over until a proper fix is made.
-
So, the light moving accross the hull when you move works in both OGL and D3D, or just OGL?
-
Originally posted by Raa
So, the light moving accross the hull when you move works in both OGL and D3D, or just OGL?
Just OGL I think. It's the faster light model but not very realistic. I think it looks kinda neat but prefer the realistic way instead.
-
(http://img.photobucket.com/albums/v625/Turnsky/screen07.jpg)
-
Yea I get some of the guages go missing too, but the ships and everything else in nebula missions look awesome now. :)
-
:sigh: Taylor, is/was NEW_HUD defined in your version of hudparse.h?
-
Originally posted by WMCoolmon
:sigh: Taylor, is/was NEW_HUD defined in your version of hudparse.h?
I didn't define it, just what's in CVS.
*Looks* Yep it's defined. That's the way it in in CVS too by the way. It was uncommented in your last update to huparse.h. I see why the energy gauges are not working at least, hudparse.cpp line 69: "#ifdef NUDE_HUD". Ya know there is a point when the word "ironic" just doesn't cover it. ;)
-
Originally posted by DrunkenPirate
Yea I get some of the guages go missing too, but the ships and everything else in nebula missions look awesome now. :)
the lack of guages irks me, but it doesn't spoil the awesomeness of it, i'm happy with just this minor snafu.. :nod:
just to note, the screenie was meant to show off the neat nebulas. :D
-
That's on purpose, my way of commenting out code already using block comments. :p If you un'comment' them, you'll probably get a host of compiler errors
Anywho, that's the problem. It should be fixable by just commenting out/removing the flag from hudparse.h.
-
Originally posted by taylor
What's your video card and driver version?
This has been reported before but I'm not sure why it's happening. The code does tell it to reset on exit so it should return to normal. You can use the -no_set_gamma cmdline option and it will avoid setting the gamma completely. Not the best solution but maybe it will hold you over until a proper fix is made.
Geforce Ti200, 66.93 Detonators.
Incidentally, resets properly on exit in vanilla 3.6.5. Crashes if I try to play any missions in OGL in 3.6.5, but it resets properly, heh.
Also, if I load up 3.6.5 after this build, run in OGL, it returns it to normal on exit.
-
Newest build works flawless and looks good. :)
-
Originally posted by Turnsky
(http://img.photobucket.com/albums/v625/Turnsky/screen07.jpg)
That just convinces me to replay desperation all over again :drevil: :D
-
Originally posted by phatosealpha
Incidentally, resets properly on exit in vanilla 3.6.5. Crashes if I try to play any missions in OGL in 3.6.5, but it resets properly, heh.
Strange, there haven't been any changes to that code since 3.6.5. Something else must be going on. I'll look at this a bit more carefully on my test systems and try to figure out the problem.
@WMCoolmon: One stupid error on my part seemed to be the reason -loadonlyused still crashed in some cases. With my commit yesterday it's worked perfectly for me with every mission I can get my hands on. If you don't mind verifying this yourself to make sure, I'll close the bug.
-
OK. maybe it's actually going into the missions that is causing it to not reset properly, because I can't do that at all in 3.6.5.
Incidentally, the HUD also seems darker in OGL then in D3D. I dunno if it's supposed to be like that though.
Anyway, don't mean to sound like just a complainer. The new lighting system looks better then the old one, and OGL seems to yield higher framerates then D3D too. Pity bout the env mapping, but very cool nonetheless. Once env mapping gets done, seems like I'm gonna have to switch to OGL.
Edit: Next time, I'll read the whole thread before opening my mouth.
-
I've been playing through the FSPort. The lighting is definately better. No notable frame rate losses as of yet. The only losses that do occur is when it loads a new texture, but even then its just the first time, after which it goes smoothly :D
This is what made me look up and notice it the most :D
(http://img.photobucket.com/albums/v107/anandraj/lilithorange2.jpg)
(http://img.photobucket.com/albums/v107/anandraj/lilithorange1.jpg)
-
Originally posted by taylor
Just OGL I think. It's the faster light model but not very realistic. I think it looks kinda neat but prefer the realistic way instead.
I think D3D uses the faster light model. Can someone verify this (and in that case, offer the realistic one as a command line alternative both for OGL and D3D?).
-
Alright I've updated the build at the same link in the first post. It mainly just fixes the HUD problem so if you don't care about that don't bother downloading again. It also contains a fix for the gamma not getting reset and the HUD and fonts being slightly darker than they're supposed to be. My fault phatosealpha, sorry about that. And I had never even noticed that the HUD was darker.
Also included is a debug build which makes the download bigger (4meg) so have that in mind if you are on a slow connection. I probably won't release a new build (or update this one) for at least a month. In the next build though it will have the ability to disable vsync in OpenGL and if possible I'll get envmapping fixed too. Undoubtedly some other new things will be included as well but that's what I know for sure.
-
Works perfectly now. Killer.
-
Originally posted by taylor
What's your video card and driver version?
This has been reported before but I'm not sure why it's happening. The code does tell it to reset on exit so it should return to normal. You can use the -no_set_gamma cmdline option and it will avoid setting the gamma completely. Not the best solution but maybe it will hold you over until a proper fix is made.
I reported that glitch. The only workaround I found (haven't tested the build you posted in the OP yet) was to move the slider in the opposite direction of where its supposed to go and then go to 1.0. Would've posted this earlier, but I've been busy.
-
About FSport, i have one mission where I don't have the Avenger weapons instead of that i've got a twin ML-16.
So impossible to finish the mission.
-
Ok, I've found a rather large bug in this build. If you play a mission that requires alot of IBX caching, it will crash. With the way my HDD access skyrocketted, it seemed like a memory leak. It crashes on the openglnt library everytime.
C:\Games\FreeSpace2\fs2_open_T-20050103.exe -spec -glow -pcx32 -d3dmipmap -d3d_no_vsync -nobeampierce -orbradar -tbpwarpeffects -fps -mod RR
Specs:
AMD Athlon XP 2800+ running at stock freq
Leadtek K7NCR18-D Pro running the latest nvidia mobo drivers (5.10)
PNY Geforce 4 Ti4600 128MB AGP 8x with fast writing enabled. (running latest dets, 66.93)
WinXP Pro SP2
I'm using OpenGL (obviously).
The reason why I think it has to do with ibx caching is because once I relaunch FS2_Open, I can load the mission like normal.
Theres also a bug where sometimes the loading screen will stay onscreen after the mission loads and gameplay is active. HOWEVER, if I alt-tab out and back in the screen is updated and I can play without any ill effects. This happens completely at random and have yet to narrow down a possible cause.
All VPs are 3.6.5, with the exception of RR.vp which is the "Renegade
Ressurgence" mod, which is available here (http://www.hard-light.net/forums/index.php/topic,28321.0.html). (Which is a really good campaign, I really recommend checking it out.)
Here's what showed up in Event Viewer:
Faulting application fs2_open_t-20050103.exe, version 1.0.0.1, faulting module nvoglnt.dll, version 6.14.10.6693, fault address 0x00076781.
-
I just finished testing out this new light model thing, and I must say that it realy looks cool. It also seems to help out in spotting large ships in nebulae. It's almost as good as having the shadowing that Bob was playing with a while back.
-
Originally posted by Vertigo1
Ok, I've found a rather large bug in this build. If you play a mission that requires alot of IBX caching, it will crash. With the way my HDD access skyrocketted, it seemed like a memory leak. It crashes on the openglnt library everytime.
Is this happening on a particular mission or all of them? Where it's crashing is way past where the IBX code comes into play. By the time you're past the third bar on the loading screen the IBX has done it's job and doesn't do anything else.
I've just tried mission one so far but the memory usage is very high. at least 191meg in textures alone. That's with the current MediaVPs and Lightspeed's textures. With that info I'd say that the thrashing is just memory issues. I am curious about the crashing though since it really should give an error message of some kind. There appears that there may be an issue with the VP as well. There are two m01_RR.fs2 files in the same directory and at least m02_rr.fs2 has a few corrupted "$AI Class:" entries causing parsing errors. The parsing problem alone could lead to all sorts of random things happening. I don't know if you are seeing this particular problem or something else though. I'll play through more missions and see what I can find.
Originally posted by MetalDestroyer
About FSport, i have one mission where I don't have the Avenger weapons instead of that i've got a twin ML-16.
And the Avenger is not in the weaponselect screen? Let me know which mission that was and I'll take a look. I have to say though that this sounds sort of like a corrupted pilot file which either got converted that way or was used with another build before 3.6.5 that had pilot issues.
-
No, i 've just beginning the FS Port campaign, and the mission if i remember, i had to destroy all the cargo from the Hammer of Light, 2 mission after we've got to escort the first prototype for shield.
IIRC, it is the first mission we encounter Hammer of light having shield system. And no selection for the Avanger into the weapons select screen.
-
unfortunately, you have to make a brand new pilot for this..
i suggest that we put in one small feature that tells people which pilot is used in which campaign/mod, and having a separate pilot file for each mod in question.
E.G: if i make a pilot in Homesick, i can only play that pilot, with that campaign, and it cannot be selectected from the pilot selection at startup...
alternatively, one pilot, keeps the details from each campaign separate, like.. for example (details shrunk to save space)
Pilot: Turnsky
Freespace 2 Campaign : 508 kills
-insert stats for campaign here-
FSport :400 Kills
-stats-
Derelect :700 kills
-stats-
Totals: 1608Kills
-overall Statistics-
that way, you can have the one pilot, it'll keep track of the pilot's stats..
i'm just trying to figure out a method in which we don't have to mess around with making a new pilot for each campaign/mod
although, a medal box for each campaign would be cool, as well, select a medal box for each campaign, so you can keep just your rank, and Ace qualifications intact.
-
Originally posted by Turnsky
i suggest that we put in one small feature that tells people which pilot is used in which campaign/mod, and having a separate pilot file for each mod in question.
Campaign information (stats, medals, ships, weapons, current mainhall, etc.) is already kept in separate files. The pilot file itself no longer has anything in it that is specific to a campaign or mod. All of that got moved to the campaign savefiles with the new formats. It can handle tables/mods switching without messing up the files now.
Unfortunately though if information is already wrong when the pilot gets converted to the new format it's still going to be wrong. There were also some builds which had a bug which could make one campaign get saved with information from another set of data. This was fixed for 3.6.5 and should no longer be a problem.
-
I just noticed, the "target subsytem in reticle" thing (default button "V") doesn't work anymore. The "bzzz" sound is played though, indicating that there's nothing to target (even when there is something to target in the reticle)
-
Yeah, I've noticed that too. I'm wondering if that's related to Bobboau's non-targeting subsystem code. :rolleyes:
-
Originally posted by taylor
Is this happening on a particular mission or all of them? Where it's crashing is way past where the IBX code comes into play. By the time you're past the third bar on the loading screen the IBX has done it's job and doesn't do anything else.
It happens on any mission with alot of ships. The crashing happens right around the second or third bar everytime it does crash though. Any mission (ie: recon or the like) thats relatively simple, the loading bar just flies through. I can literally play for several missions in a row without any real issues, and then the crash bug will appear.
I've just tried mission one so far but the memory usage is very high. at least 191meg in textures alone. That's with the current MediaVPs and Lightspeed's textures. With that info I'd say that the thrashing is just memory issues. I am curious about the crashing though since it really should give an error message of some kind. There appears that there may be an issue with the VP as well. There are two m01_RR.fs2 files in the same directory and at least m02_rr.fs2 has a few corrupted "$AI Class:" entries causing parsing errors. The parsing problem alone could lead to all sorts of random things happening. I don't know if you are seeing this particular problem or something else though. I'll play through more missions and see what I can find.
I do recall the it crashing on the second mission, and a couple more after that one.
As for an error message, I looked through the error log and this is the most recent entry:
fs2_open_T-20050103 caused an Access Violation in module nvoglnt.dll at 001b:69576781.
Exception handler called in Freespace 2 Main Thread.
Error occurred at 1/5/2005 23:18:42.
C:\Games\FreeSpace2\fs2_open_T-20050103.exe, run by Vertigo1.
1 processor(s), type 586.
512 MBytes physical memory.
Read from location 0a286000 caused an access violation.
Registers:
EAX=058cf3c8 CS=001b EIP=69576781 EFLGS=00010212
EBX=156b2d80 SS=0023 ESP=0012f78c EBP=05d300c0
ECX=0000002c DS=0023 ESI=0a286000 FS=003b
EDX=00000100 ES=0023 EDI=058cf418 GS=0000
Bytes at CS:EIP:
f3 a5 8b ca 83 e1 03 f3 a4 8b 74 24 14 56 53 55
The rest is just the stack dump.
I seriously doubt its a hardware problem since I can perform tasks just as intensive (and more) without any issues.
-
Originally posted by Goober5000
Yeah, I've noticed that too. I'm wondering if that's related to Bobboau's non-targeting subsystem code. :rolleyes:
... it is... it's backwards... fixing it...
[edit]
God that was a stupid mistake, stupid double negitives...
-
hi. long time no post... i know. but i've been following in the shadows and gotta say i like whats been going on.
anyway... i have a quick q-
i have the latest build and here is my features list:
C:\Games\FreeSpace2\fs2_open_T-20050103.exe -spec -glow -pcx32 -jpgtga -orbradar -3dwarp -tbpwarpeffects -snd_preload -env -alpha_env -decals -loadonlyused -rlm
i use opengl and was wondering are there any things i have turned on that i dont need turned on and/or are there any options i need to turn on. my system is quite capable
thanks lots
-
-pcx32 generally isn't very helpful, and has been known to cause issues. -env and -alpha-env are D3D only just now, so they don't do anything in opengl mode.
-
Originally posted by Goober5000
Yeah, I've noticed that too. I'm wondering if that's related to Bobboau's non-targeting subsystem code. :rolleyes:
fixxxed and commmmitted (since bob hadn't yet)
-
Originally posted by phatosealpha
-pcx32 generally isn't very helpful, and has been known to cause issues. -env and -alpha-env are D3D only just now, so they don't do anything in opengl mode.
so unless i use d3d i wont get any env stuff?
-
As of now, correct. Implementing env-mapping in OGL is on taylor's to do list, but it's not in yet.
-
Originally posted by phatosealpha
As of now, correct. Implementing env-mapping in OGL is on taylor's to do list, but it's not in yet.
so then do i get all of the visual enhancements with d3d? and if so what is the advantage of opengl?
-
Most. Taylor's new lighting system from this build is OGL only, but pretty much everything else is in D3D.
Why use opengl? A couple of reasons - ATI users get no shinemaps in D3D with more recent catalysts, but they get them in OGL. Framerates can differ too - I know on my own system, D3D runs pretty well at 1024x768, but in OGL I can kick up the resolution to 1600x1200 and get comparable framerates.
I'm sure there are other reasons too, but those are the ones that pop to mind.
-
i cant get my joystick to work! i've selected it in the launcher but i get nothing ingame.
-
Originally posted by KyJelly
i cant get my joystick to work! i've selected it in the launcher but i get nothing ingame.
Run the original FS2 launcher and hit the "Detect Available Joysticks" in the Joystick tab, and then it should work.
btw....someone should put something similar into the FSO launcher.
-
Originally posted by phatosealpha
Most. Taylor's new lighting system from this build is OGL only, but pretty much everything else is in D3D.
Why use opengl? A couple of reasons - ATI users get no shinemaps in D3D with more recent catalysts, but they get them in OGL. Framerates can differ too - I know on my own system, D3D runs pretty well at 1024x768, but in OGL I can kick up the resolution to 1600x1200 and get comparable framerates.
I'm sure there are other reasons too, but those are the ones that pop to mind.
I like the OGL things but when playing Fs2 or any other mods the game crashes during loading randomly.
But in D3D i never met any crash.
The OGL work perfect with the TBP 3.0.
-
Originally posted by Col. Fishguts
Run the original FS2 launcher and hit the "Detect Available Joysticks" in the Joystick tab, and then it should work.
btw....someone should put something similar into the FSO launcher.
still nothing
in the regisrty area of the launcher under currentjoystick it says 0. is that the problem?
-
Originally posted by KyJelly
still nothing
in the regisrty area of the launcher under currentjoystick it says 0. is that the problem?
check to see that whether your joystick is actually connected or not, in the control panel under "game controllers"
-
Originally posted by Turnsky
check to see that whether your joystick is actually connected or not, in the control panel under "game controllers"
it is connected and working as it works in starlancer and is in the game controlers control panel
-
Originally posted by KyJelly
it is connected and working as it works in starlancer and is in the game controlers control panel
huh.
(http://img.photobucket.com/albums/v625/Turnsky/launchermenu.jpg)
there's actually a few joystick options available, try looking through that if the launcher doesn't automatically detect your primary game controller. :nod:
-
Originally posted by Turnsky
huh.
there's actually a few joystick options available, try looking through that if the launcher doesn't automatically detect your primary game controller. :nod:
i've tried all available options in the pulldown menu. whats strange is that i have a generic gamepad that works but my flight stick don't. also if i run the original launcher and choose the controller then run the original game i get an error, but can still get into the controler config screen in the original fs2 and the controller works!!!
also i'm using launcher 5.2. would that matter?
u got a link for 5.0?
-
Originally posted by KyJelly
ialso i'm using launcher 5.2. would that matter?
u got a link for 5.0?
i'm not terribly sure, pick the codies brains over it, i'm just an artist, and not knowledgable in such fanciful objects :p
-
I was ripping my hair out for two days trying to get my usb MS ffb2 jostick working using the launcher. By accident I opened the XP game controllers settings > Advanced > "select the device you want to use with older programs" and I'll be damned if it didn't start working! I've never seen this simple fix posted anywhere else either.It has always worked with every other program except FS2 SCP until now.
Awesome program by the way-long live open source!!
-
Originally posted by rainbearnorth
I was ripping my hair out for two days trying to get my usb MS ffb2 jostick working using the launcher. By accident I opened the XP game controllers settings > Advanced > "select the device you want to use with older programs" and I'll be damned if it didn't start working! I've never seen this simple fix posted anywhere else either.It has always worked with every other program except FS2 SCP until now.
Awesome program by the way-long live open source!!
i'll try it when i get home, but last time i played scp was about 6 months ago and the controller worked fine at that point. kinda weird... we'll see.
-
well amazing!!! thank you it worked. but still strange :)
edit: i have noticed that force feedback doesn't work tho.
-
Update on the crashing issue:
Taylor, I can get it to crash on mission 12 every single time. HOWEVER, if I switch to Direct 3D as my API (1024x768@32-bit) it plays like normal.
Just incase you want to test my pilot, you can download the relevant files here (http://www.bakercountyonline.com/md-2389/FS/). (stick in the /data/players/single/ dir)
-
Originally posted by Vertigo1
Taylor, I can get it to crash on mission 12 every single time. HOWEVER, if I switch to Direct 3D as my API (1024x768@32-bit) it plays like normal.
Alright I'll test it out. Got rather distracted by TBP 3.0 and hadn't gotten that far in RR yet. :D
I'll test it tonight or in the morning and get back to you tomorrow.
-
With the latest incarnation of this exe, -nobeampierce seems to be broken. With it enabled beams from any hostile ship from whatever race are unaffected by shields, whereas it functioned normally in the 20041230 build.
Also, enabling -loadonlyused causes a hard crash with the MS error reporting dialogue after 1-2 minutes of play on any level.
No other problems I can find however.
-
I noticed that some people earlier in the thread were saying that they get much higher framerates in OpenGL than D3D when using this build. For me, it's the exact opposite; OpenGL is much choppier than D3D, and if I happen to be looking at an HTL model, it slows to an absolute crawl. (This happens with every HTL model in the Tech Room; I seem to remember it also occurring in-mission as well.) My PC isn't anywhere near fast (Radeon X300, 512 RAM, 3.0 ghz processor), but D3D runs very smoothly. I'm beginning to wonder if the problem is just shinemaps, but I think I was getting the same problem in OpenGL after turning off specular effects. I'll have to try it again and compare results, though. I'd love to use OpenGL and see those absolutely stunning shinemaps, but obviously if it makes the game unplayable, I can't. Oh well; even without them, everything looks fantastic, and the build is great. I just downloaded the new VP files, and the new effects are jaw-dropping. :D
-
Originally posted by Mongoose
I noticed that some people earlier in the thread were saying that they get much higher framerates in OpenGL than D3D when using this build. For me, it's the exact opposite; OpenGL is much choppier than D3D, and if I happen to be looking at an HTL model, it slows to an absolute crawl. (This happens with every HTL model in the Tech Room; I seem to remember it also occurring in-mission as well.) My PC isn't anywhere near fast (Radeon X300, 512 RAM, 3.0 ghz processor), but D3D runs very smoothly. I'm beginning to wonder if the problem is just shinemaps, but I think I was getting the same problem in OpenGL after turning off specular effects. I'll have to try it again and compare results, though. I'd love to use OpenGL and see those absolutely stunning shinemaps, but obviously if it makes the game unplayable, I can't. Oh well; even without them, everything looks fantastic, and the build is great. I just downloaded the new VP files, and the new effects are jaw-dropping. :D
actually, i've noticed that my framerates albiet a little lower than the D3D build, they've been far more consistant, and hardly ever drop below the 20-25 FPS mark (it usually hovers at 50+ any other time)
anything more than 20 is pretty good, as that's the usual framerate for any television picture to maintain smoothness. :nod:
-
Originally posted by taylor
Alright I'll test it out. Got rather distracted by TBP 3.0 and hadn't gotten that far in RR yet. :D
I'll test it tonight or in the morning and get back to you tomorrow.
*looks at calendar*
;)
-
Originally posted by Vertigo1
*looks at calendar*
:D Yeah I was trying to wait until I had a better response than "Works for me!". That mission is using a ton of memory, bit over 600meg total in my case. And that's with some memory optimization fixes that aren't in CVS yet. Mission 1 is pretty high too but the ones in between that and 12 weren't so bad. Can't remember how much memory you said you had (1gig?) but run it in OpenGL mode, in a window, with Task Manager going and see how much memory it's really taking. You'll have to position the two windows so you can see what you need without switching back and forth but I'd be interesting in seeing what you get. That mission did have some -loadonlyused problems as well but you weren't using that option.
Originally posted by Mongoose
OpenGL is much choppier than D3D
What drivers are you using? You can also try the -novbo option. It was orginally to fix a crash but I'm leaving it in because some video drivers aren't optimized properly and VBOs, which are supposed to make HTL models faster, are actually slower. It's been my experience that if you have a major difference in D3D and OGL framerates then your drivers tend to suck. Don't know if that's the problem here but get me your driver version and I'll see if I can find any known speed issues.
Originally posted by Mongoose
With the latest incarnation of this exe, -nobeampierce seems to be broken
Hmm, I don't see anychanges between the builds that would cause this. Goober made a change to the beam code just before the last build but it looks ok to me with a quick look. I'll look at it, or Goober may say something.
The -loadonlyused issue is known. It should also be fixed with the changes I just put in CVS. Check the next build that someone puts out and see if it's still a problem. If so then let me know.
-
Originally posted by taylor
:D Yeah I was trying to wait until I had a better response than "Works for me!". That mission is using a ton of memory, bit over 600meg total in my case. And that's with some memory optimization fixes that aren't in CVS yet. Mission 1 is pretty high too but the ones in between that and 12 weren't so bad. Can't remember how much memory you said you had (1gig?) but run it in OpenGL mode, in a window, with Task Manager going and see how much memory it's really taking. You'll have to position the two windows so you can see what you need without switching back and forth but I'd be interesting in seeing what you get. That mission did have some -loadonlyused problems as well but you weren't using that option.
Half a gig actually. What's funny is that the game runs like a dream when its running. I'll get back to you on the memory usage though. Though it might be nice if you checked your ICQ every now and then. I left you a couple of messages that you haven't responded to.
-
Originally posted by Vertigo1
Though it might be nice if you checked your ICQ every now and then.
I'm seldomly available to chat and when I get online people swamp me so I tend to just not run it. I usually set it to away when I do run it but I'll get on tonight when I get the chance and try to keep it going more often.
I'm actually hoping that your problem isn't just memory related since that's much more difficult to fix. The way it's crashing I would say it's something in the code that transfers VBOs to the card but that can be memory related (in a weird case). If you haven't already try running it with no cmdline options except what's required for the mod. If it's ok then add them back one at the time until it crashes. If it's -glow or -spec that makes it crash then it could be VBO related. Not using any cmdline options can greatly reduce the memory footprint as well. Using -glow with the MediaVPs will probably add about 30-40meg to that mission by itself.
-
I've been playing with this and it seems to crash from time to time, always after accepting a finished mission...
Here are the cmdline and specs:
D3d 1024x768x32 EAX
C:\Games\FS2Open365\fs2_open_T-20050103.exe -spec -glow -pcx32 -jpgtga -3dwarp -dnoshowvid -fps -stats -allslev
AMD64 3000+ Geforce4 MX-440 1Gb RAM WinXP SP2 SB Audigy 2
I'm adding this to mantis #299.
-
I'm using the latest Catalyst drivers available for download off of ATI's site. The version number of the drivers is 6.14.10.6497. Hope this helps.
P.S. I didn't make the post about -nobeampierce. :p
-
Originally posted by Mongoose
P.S. I didn't make the post about -nobeampierce. :p
Slight cut and paste error. ;) I'll check on the performance issues and get back to you.
<wonders exactly where I pasted "DrunkenPirate" and if I need to apologize to anyone... :nervous: >
@mrduckman: Try the debug build and see if it gives you anything. It may not happen enough to make that a worth while thing to do but according to the mapfile it's anim related and that doesn't make much sense. It's always when you hit the accept button in the debriefing though right?
-
Right. I'll try when I get back from work. I'll be on ICQ/MSN.
-
Been testing this build for a while now. Since I KNOW that whenever I'm out of memory I get white boxes, that has to be why other people do, so its not the game's fault. I now have 1 gig of PC3200 and the White Box of Death problem never happens anymore unless I've been running way too many missions back-to-back or running background applications while the game is running.
BTW...Load Only Used Weapons crashes a lot of missions, so I turned it off. I don't notice a speed difference anyway.
I do have questions about 4 things though.
1) What does TBP Warp Effects exactly DO?
2) I run in 32 bit color mode with ALL media vp's installed. Will turning off PCX32 make things worse eye-candy wise, or will it all look the same?
3) Compression...PCX compression that is. Will it affect performance or quality whether it's on or off in OpenGL?
4) Mip mapping only works in D3D, right?
P.S. Oops. I just checked the first post and realized you released a new build. Regarding your RLM tag, I'll run off and test it right now and take comparison shots of a shiny ship...hmm...artemis
*runs off*
UPDATE 1: I don't notice a difference (at least, in the tech room with the artemis that is). I wonder however if your new lighting code will fix my nebula blackness issue. I'll go test that right away...
UPDATE 2: Okay, so I didn't test the nebula yet, but I noticed that the Deimos is much more better lit with RLM active. Seems to be most noticeable on large HTL ships (note to self, test on the star trek ships later)...more on nebula working or not in a bit.
UPDATE 3: Sorry...the Trinity mission's ships are still all jet black as night any settings whatsoever. =( Bummer. What gets me is that I'm using the same card (Radeon 9800 Pro 128mb) as someone else in this thread who sees the Aquitaine fine in that mission...I AM using Catalyst 4.11 instead of latest 4.12 but...well...erm...im not in an upgradey mood tonight. As for RLM, its a massive improvement over what I had before with lighting. The Deimos looks realistically metallic now and some other ships also look a lot better. It is subtle though and since ppl are used to the old one I say leave RLM off by default but offer it as an option for now
I have to say though, RLM makes already-smooth ships (e.g. the Perseus HTL and the Herc HTL and other sleek ships) look awesome. Even without TruForm. Combine this RLM feature with TruForm support, and we'll have absolutely uber looking lighting capabilities for those lucky few (not me though, i dont have an X800, just the 9800 Pro) with awesome radeon cards
-
GregSter2K --> You forgot to mention the HDR emulation from the ATI Smartshader that you can grab it here :
http://www.hard-light.net/forums/index.php/topic,29291.0.html
There are not official but the effect is pretty cool.
-
@Gregster2k:
1) Not a clue. Never actually looked at what it's supposed to do in fact.
2) I don't use PCX32 since it's pretty much just a waste of memory. The PCXs only have 256 colors in them and the little magic it does to go 32-bit does nothing for me visually. They go 16-bit by default but that's mainly for blending purposes.
3) Umm, actually I don't recall if the OpenGL PCX loader will compress it to DDS or not. I'll look into that and get it fixed for the next build. The quality will decrease though since the files are being compressed.
4) Only D3D but that's just because I haven't added the code to OpenGL. OGL is fully capable of it though. In D3D how much of a performance difference do you see with and without mipmapping?
I am just going to make RLM a cmdline option for now, off by default. I can be set to on by default at a later date if people want. It is a single line of code in OpenGL to switch to use this new light model though so it's not like I slaved over a bunch of new code. I gave a quick look at MSDN and will see about making a similar light option available there as well. I think it's currently similar to the new OpenGL one though rather than the old model.
-
Erg, doesn't PCX32 change the internal storage of all textures - tga, jpg, pcx, dds?
-
Originally posted by Gregster2k
1) What does TBP Warp Effects exactly DO?
In B5, a ship warping in will have a different effect color that those warping out, so TBPwarpeffects will switch to an alternate texture/effect between arrival and departure warps. I didn't realise this until someone in Lightspeed's warp effect thread posted about the new effects only being visible during warpin, but that disabling the TBPwarpeffects flag fixed this.
-
Originally posted by WMCoolmon
Erg, doesn't PCX32 change the internal storage of all textures - tga, jpg, pcx, dds?
Nope, just makes pcx data load come out of pcx_read_bitmap_32(). So basically all it does is make an 8-bit image take up 32-bits of memory space, adding an alpha channel along the way, which will most likely never get used anyway. Rather useless if you ask me.
-
@Taylor:
*turns off PCX32*
Um...I personally don't use mip maps most of the time because I prefer not having games dictate to me when its the right time to make a texture change to a smaller version. I never really took the time to check the difference between d3d mipmap or nonmipmap...i could, but im lazy atm. will do SOMETIME tho *puts on to-do list*
as for DDS compression, well, meh, its not tat big of a deal. The only reason I asked if they were D3D only is that I wanted to ensure no flags were wasted on the program --- not a request for them to be put into OGL. lol. Even if you do add mip maps and dds compression to OpenGL, its very unlikely I'll ever use them...
@Trivial:
thx for the info about TBP Warp FX. i guess i dont need that then...
@MetalDestroyer:
OMFG!!!!!!!!!!!!!!!!!!!!!!!HOOOOOOOLEEE MUST TEST THAT NOW RRR!!!
UPDATE for MD: Erm. I am experiencing the ugly "Everything is WHITE" problem with taylor's build and that shader utility. Ugh...I think it's time I updated to ATI Catalyst 4.12 RIGHT NOW. *goes to ATI.com* Weeee...
UPDATE 2: It works now. WOO HOOOOOOO! Hell yes! Thank you Taylor for the build, thank you MD for telling me about that thread, and thank you DaBrain for MAKING that thread with the pixel shaders in it! I've always wanted a toy to let me beautify ANY game I want...now i have it...yay!!!
-
Sorry for the bumpage, but taylor, I think my slowdowns may have been a fluke. I just tried Open_GL again the other day, and it ran as smooth as D3D. Could it have been due to the fact that .ibx cache files were created for the models, meaning that they would display without using so much memory?
-
Gregster2k --> ehehe, it's nothing ^^ I will enjoy to make the good configuration for the blur because into Kotor, it is a total mess.
-
For some odd reason, the game crashes when I try to view the Herculese in the techroom. I do have the prevent fog intersect hull function to on and am running it on D3D since OpenGL doesn't support AA.
-
Hm, this build is getting on a bit now, I would try taylors T20050208 build (http://www.hard-light.net/forums/index.php/topic,30386.0.html) or wait a few days for his latest.
However saying that, this one worked great for me for a long time.
-
Allow me to introduce myself, i am new on this forum, but not new to this game.
We are in the process (along with my brother) of making our own game and for that, i had been playing with the Open FS2 build to gather information on what are the key essentials to making a good spaceflight sim game.
The build you guys talk about here works very good on my current machine, with the exception of "OpenGL 1.2 not present" box that i have to press everytime and the constant "Crash" after playing 10 or 12 missions.
My machines is as follows:
Athlon64 3200+ (2700Mhz)
MSI K8N Diamond (NF4-SLI)
XFX Geforce 7800GTX
SB Audigy2
The game works perfect be in D3D or OGL in 1024x768x32 with 4xAA and 16x AF, 8xAA works also, but, no noticeable difference in quality.
The OpenGL version looks better than the D3D version, but, the D3D version seems A LOT more stable (never ever a crash).
Any news on this? new build?
Thank you guys for all the hard work and congrats.
Eagle / Daniel
www.maximopc.org
-
This is a really old build and not what you want to be using. Grab anything more recent and you should be better off. Many/Most/All of the OGL related crashes, graphical glitches and performance issues have been worked out since this build was released. That "not present" message should be fixed too since based on that vid card you are using OGL 2.0 and previously it would see that as 1.0 rather than something that was actually newer than 1.2.
I recommend just using Sticks new build (the D3D white square test thing) since it has all but one OGL related fix in it. That one fix is a gamma ramp reset but if your monitor isn't fully calibrated then it shouldn't hurt you. The next build released should have it properly reset the gamma ramp to the original desktop setting. Aternatively, you can use http://icculus.org/~taylor/fso/willrobinson/20050812-win32.rar as it already has that fix in it.
-
This new version works wonders !!! thank you soooo much!
I'm gonna try network playing now :)
What is your advice on this new version? D3D or OpenGL?
Thank you again !
-
Open GL ^^ is better.
-
I greatly prefer OGL from the programming point of view. And since I use Linux I only use OGL. More and more people are using OGL as well so it's getting a bit more attention on the bug fixing and optimization side of things. The current OGL code has numerous speed and memory optimizations that D3D just doesn't have and probably won't get unless Bobboau does it.
Also, NVIDIA has fantastic OGL support so you should get great quality, speed, and reliability out of it. In the end just use what you prefer and what works best for you. But I do agree with MetalDestroyer, OGL is better. :)
-
Yes, OpenGL on NVIDIA side is wonderful, don't forget that they have a mutual agreement with Silicon Graphics and they are the responsables for the creation of that standard.