Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Test Builds => Topic started by: taylor on April 05, 2004, 08:27:46 pm
-
I don't foresee any big problems but this build has a "use at your own peril" status.
20040405-win32.zip (http://icculus.org/~taylor/fso/testing/20040405-win32.zip)
There are three main things I'm looking to test with this build:
- The is based on the Linux code tree. Verification is needed that no new bugs exist in the Windows version in general and specifically D3D.
- This build contains PhReAk's new OpenGL changes as well as my changes and bug fixes. Lines and shaders should work now. 32-bit texture support is available with DevIL (dlls included). There are a couple of minor performance fixes to OpenGL in here but I don't know if they will be noticed. The command line options "-jpgtga", "-pcx32" and "-glow" will work as expected now. If you have a nVIDIA card and get crashes when entering a mission using OpenGL please try the "-novbo" command line option.
- Since the previous build reduced memory usage it's time to make better use of some of the savings with new preload options for sounds and planets. A new commandline option exists "-snd_preload" which will preload game sounds when you start a mission. This should only add about 10megs to the memory footprint but will have all of the mission sounds preloaded to help reduce stutters. The second thing is that planets will now preload into OpenGL texture memory at mission load now. This should help reduce the delay when viewing tga planets for the first time. The planet preload is OpenGL only.
What I'm looking for is things that are broken, whether the stutters are reduced and if there are any new OpenGL related issues. Please DO NOT file new bugs into Mantis on this build. If you see that bug in Mantis that's fixed in this build please list the bug number here. Add any new bugs to this thread. I'm not sure yet how many of these changes will make it into CVS before 3.6 so it's up to the testers to decided if any of these changes are worthy/required/needed.
Additional changes:
- ani's are used by default (if found) for all ship textures (may not get in CVS)
- mods will now be searched with an absolute path, probably won't make a difference for most people
- OpenGL mouse cursor saves now use the proper 32x32 rather than 24x24 size
- neb poofs are no longer preloaded unless in a FULLNEB mission
- mods don't list normal pilots on the pilot select screen (may not get in CVS)
- other stuff that I don't remember
-
even if env_mapping will only be in 3.6, dont you guys need to test it before then?
oh, and work on the whole collaboration thing, I'm swiftly becoming confused
-
env_mapping is after 3.6
-
I'm not sure what to classify this as, but I think I found a bug in the game reguarding damage/destructability of a capital ship. Playing "Proving Grounds"(the mission where you test the delta-wing shaped ships), I was unable to destroy the Corvette Timat, as it became progressively harder to inflict a precentage point of damage on it, ending with me getting it down to 1%, and unable to do another precent after putting 2 banks of those dumb-fire missiles in it(the previous 1% taking almost the whole 2 banks). Unless I'm mistaken, this ship is supposed to be destructable(as a bonus target), so it would seem the game has a bug in it reguarding that.
-
I was playing that mission where the Aquitaine is leaving the nebula and the one after it, with the Erinyes, and it all seemed to work fine. Of course, I didn't bother trying to destroy any capships. No Stuttering! very good, shove it together with Bobbau's work and we'll have a kickass build
-
my stuff is all currently in CVS, after I commited I started trying to get a better shield renderer
-
Originally posted by ViRGE
I'm not sure what to classify this as, but I think I found a bug in the game reguarding damage/destructability of a capital ship. Playing "Proving Grounds"(the mission where you test the delta-wing shaped ships), I was unable to destroy the Corvette Timat, as it became progressively harder to inflict a precentage point of damage on it, ending with me getting it down to 1%, and unable to do another precent after putting 2 banks of those dumb-fire missiles in it(the previous 1% taking almost the whole 2 banks). Unless I'm mistaken, this ship is supposed to be destructable(as a bonus target), so it would seem the game has a bug in it reguarding that.
in the original game, damage stopped being dealt once a big ship like covette or destroyer hit 10% hull. then you need trebs or bombs to finish it off. now it gets exponentially harder to kill big ships with small weapons once their health approaches zero.
-
Turambar: I was actually trying to be less confusing by doing all of this testing on one build rather than 2 or 3. It's possible that I was unsuccessful ;) It helps me this way since I would only have to fix things in one code tree and then intergrate them into a Windows only CVS later. I'm alreay moving some of the smaller OpenGL fixes into a Windows only tree with the 32-bit changes coming last. None of these changes are really new, it's just that everything is together for the first time in a build that is available for Windows rather than just Linux.
I had done a CVS update a couple of hours before making this build so everything that Bobboau had committed to CVS as of Monday afternoon is in this build.
Bobboau: Did your full nebula brightness fixes make it into CVS with your update? I think I saw at least one but it didn't have any affect with OpenGL for me and it still pretty much whites out. Picture (http://icculus.org/~taylor/fso/pics/ogl-nebs.jpg) - that's pretty bad and not always that white but it should give you and idea of how unplayable neb2 missions are in OGL. That screen shot was taken about 3 seconds after entering "A Game of TAG".
-
Originally posted by taylor
Turambar: I was actually trying to be less confusing by doing all of this testing on one build rather than 2 or 3. It's possible that I was unsuccessful ;) It helps me this way since I would only have to fix things in one code tree and then intergrate them into a Windows only CVS later. I'm alreay moving some of the smaller OpenGL fixes into a Windows only tree with the 32-bit changes coming last. None of these changes are really new, it's just that everything is together for the first time in a build that is available for Windows rather than just Linux.
I think he's complaining about the fact that you, Kazan and Bob all have builds out for testing at the moment rather than anything you've done in this particular build.
Putting Bobs stuff in this build is certainly a step in the right direction.
-
Originally posted by Turambar
even if env_mapping will only be in 3.6, dont you guys need to test it before then?
oh, and work on the whole collaboration thing, I'm swiftly becoming confused
Hey, welcome to HLP, Turambar. :)
:welcome:
-
Originally posted by Turambar
even if env_mapping will only be in 3.6, dont you guys need to test it before then?
Bob was a little naughty working on the env mapping. The SCP are supposedly in a code freeze at the moment. The idea is that no one adds any new code except for fixing bugs.
The idea is to get 3.6 stable so that we can shout about it from the rooftops (rather than getting people here only to find that FS2_open doesn't work for them/has huge bugs in it.)
As such the env mapping stuff won't be in until 3.6 when new code can be added again.
-
and this is why i expect a 3.6.1 within a week after 3.6. and why i expect 3.6.1 to be the most feature filled, buggy release ever.
-
my nebula brightness fix was in there, but it seems like OGL doesn't suport the alpha level that you set when you set the bitmap.
-
The less buggy we can get 3.6, the less buggy 3.6.1 will be. :)
-
Originally posted by PhReAk
in the original game, damage stopped being dealt once a big ship like covette or destroyer hit 10% hull. then you need trebs or bombs to finish it off. now it gets exponentially harder to kill big ships with small weapons once their health approaches zero.
Ahh, so I'm not going crazy.:) Now, change it back to the way it was; if it stuck at 10%, I would have been able to figure out what's going on a lot easier.:eek2:
-
This way makes more sense as long s you can't actually kill the ship.
-
Another bug: with -stats, physical memory usage was reading 4000MB+ at one point(I think it was 4011 or something like that). I don't have 4GB of memory(768MB), and every other metric was right, so there's just something amiss in the phy. memory code.
-
So is this the one we're supposed to use to play and test? There's like 3 out there now and each of them doesn't have what the other did.
Are you guys planning on consolidating all these three releases into one so we can test?
-
Originally posted by ViRGE
Another bug: with -stats, physical memory usage was reading 4000MB+ at one point(I think it was 4011 or something like that). I don't have 4GB of memory(768MB), and every other metric was right, so there's just something amiss in the phy. memory code.
Hmm, I'm seeing the same thing here too. Rather peculiar.
-
What the hell is up with those little blue boxes around certain menu items!!
-
So is this the one we're supposed to use to play and test? There's like 3 out there now and each of them doesn't have what the other did.
This contains everything that the 20040401 build did plus fixes for what people were complaining about. Some, most, or all of Bobboau's stuff was commited to CVS and included in this build. Kazan and I posted our build's at almost the same time so I don't think it was intentional to have two builds to test from two different people.
The subject says "20040405 test build" so it's not meant to be used by anyone that doesn't intend to test that old bugs have been fixed and none added. It's not meant to be used as a build that people should use in lieu of a final 3.6 version. If I were to commit these changes before testing then it would cause serious integration issues for the other developers and any bugs would be in everyones build. That would waste all of the developers time trying to figure out what broke and why.
Another bug: with -stats, physical memory usage was reading 4000MB+
Is this problem new to this build or does it happen with Bobboau's as well?
What the hell is up with those little blue boxes around certain menu items!!
Does this happen with other builds? Are you using OpenGL or D3D, 32-bit on either?
-
D3D 32 bit on a GeForce FX 5600 using Starstorm 56.72 Drivers
-
Is this the blue boxes problem?
http://mgo.maxgaming.net/mantis/bug_view_page.php?bug_id=0000008
-
Originally posted by taylor Is this problem new to this build or does it happen with Bobboau's as well?
At this point, I can't confirm it, as I have been unable to figure out how to replicate it. If/when I figure that out, we'll see if it does it on Bobbau's build too.
PS For Turambar's problem, I'm using a 5700 Ultra with the WHQL'd 56.72 drivers, and am not seeing that problem
-
It would appear that this build perfers tga over pcx. I had pcx nebula in the effects directory, but it superceeded those and grabbed the tga versions out of mv_core.
-
Using the -jpgtga option will do load preference in the following order: TGA, JPG, DDS, PCX. Otherwise it's: DDS, PCX. That is the load order of D3D and with this build it's now the order with OpenGL as well. If you're not using the -jpgtga option and it's still loading TGA first then it's a bug.
-
I am using the -jpgtga command line. I'd just prefer to use the original pcx nebulae instead of Lightspeed's tga versions of these nebulae. Not only do they create less of a memory load, but they look less washy. No offence Lightspeed, after all these were pretty much your first high-profile pieces of work, and not up to standards of your new stuff. As far as I'm concerned, for an effect FS should ALWAYS default to whatever is in the effects directory, and NOT chose another file in a VP, no matter what its sequence of formats is. If there are 2 files of the same name in that directory, then it should resort to its format preference list.
This may sound like its getting a bit out of control, but perhaps the sequence described above should be the default, and have a command flag like -pcx_last should someone wish the sequence you described. The only problem I (a non-coder) can forsee, is the subsequent requests for flags for each desired sequence of format preference, which definitely constitute "going out of control."
On the good side, this build seems to not display the "CTD after alt-tab and restore" problem I was getting with Bob's builds since -21.
Later!
-
Having it look for PCXs first would pretty much invalidate the -jpgtga option since those high quality versions would seldomly, if ever, get used. The easy answer to the problem is just to not use -jpgtga and if you like the hi-res planets then you still have DDS as an option. Probably not the answer that you want but if it's just the nebula that you don't like the TGA versions of then just wait and those new uber cool ones should be available before too much longer.
FS does search the effects directory first but it searches with the full filename so the extension matters in that case. It would be possible to search just the directories and not the VPs first for all file types but it's a lot of code to change the behavior and it would be tremendously slow. I mean *slow*. Really slow. Searching the directories accounts for probably 90% of the search time for any file, everything else is cached so it's quick. I have tried caching the directories but it's very problematic so I gave up and decided it's not worth the time to get it perfect (it's perfect or non-functional, not much in between).
-
memory leak in -pcx32?
It's aweful...
-
Well, it was supposed to be fixed. In any case, I've stopped using -pcx32 for a while since I like have FSAA on and -pcx32 breaks that somewhat (known bug).
But with it on, I don't notice a speed drop other than loading time. I also notice that I'm using a lot more memory.
-
List of possible bugs...
Processor Duron 1.6 Ghz
Memory 256 MB DDR400
Video card GeForce 4 MX400
Sound card Audigy2 NX
Resolution OpenGL 1024x768x32
Extra stuff Media VPs core, shine, weapons, hiplanets + Lightspeed's newest weapons effects + hi-poly Fenris and Hercules in a VP
Mission The first one with the Knosses, Dashor, and Carthage
Edit: Green indicates info about that problem in D3D8
1) (Definite) The splash screen displays for a second or two, then the screen changes to be completely white
Did not occur in D3D8
2) (Always happened)The refresh rate wasn't as high as my monitor/video card can go - about 85 hz.
Did not occur in D3D8
3) (Always) Whenever the sun glare showed up, my framerate would drop by 1/2 almost exactly.
Framerate dropped by about 1/4 when the sun showed up
3) (Sometimes) When I targeted ships, there was a bit of lag. This almost always happened the first time I targeted a ship type, sometimes after.
Occured in D3D8
4) (Always) When I targeted debris, most of the HUD dissapeared (Screenshot (http://fs2source.warpcore.org/temp/debris.jpg))
Did not occur in D3D8
5) The build did not seem to lag as much on sound playing, though it did seem to lag occassionally. Usually this was when things appeared onscreen. I was thinking it might have to do with loading different LODs.
Occured in D3D8
6) (Always) After the Dashor and Carthage arrived, the pilot ani box simply displayed black when I received transmission. (Screenshot (http://fs2source.warpcore.org/temp/blackpilot.jpg))
Did not occur in D3D8
7) (Both times I got to this point) Also after the Dashor and Carthage arrived, a massive slowdown occured just before the bombers' arrival on one try, on another it appeared during the bombers' arrival.
Did not occur in D3D8...though there was one further towards the beginning
8) (2/4 or 2/5 times) Two other times, I ran into these errors after ordering All Ships Attack My Target:
Error: ai_find_path tring to find a path (17) that doesn't exsist, on ship Neqael
File:U:\Working\Projects\FS2_Open\code\Ship\AiCode.cpp
Line: 3845
Call stack:
------------------------------------------------------------------
fs2_openT-20040405.exe 005cd44a()
fs2_openT-20040405.exe 005cdd5e()
fs2_openT-20040405.exe 004caab7()
fs2_openT-20040405.exe 004ccbb8()
fs2_openT-20040405.exe 004ccd86()
fs2_openT-20040405.exe 004a5dac()
fs2_openT-20040405.exe 00434cbd()
fs2_openT-20040405.exe 011adbd8()
fs2_openT-20040405.exe 011add98()
fs2_openT-20040405.exe 011ae658()
fs2_openT-20040405.exe 011ae818()
fs2_openT-20040405.exe 011ae9d8()
fs2_openT-20040405.exe 011aeb98()
fs2_openT-20040405.exe 011aed58()
fs2_openT-20040405.exe 011aef18()
------------------------------------------------------------------
Error: ai_find_path tring to find a path (13) that doesn't exsist, on ship Maul
File:U:\Working\Projects\FS2_Open\code\Ship\AiCode.cpp
Line: 3845
Call stack:
------------------------------------------------------------------
fs2_openT-20040405.exe 005cd44a()
fs2_openT-20040405.exe 005cdd5e()
fs2_openT-20040405.exe 004caab7()
fs2_openT-20040405.exe 004ccbb8()
fs2_openT-20040405.exe 004ccd86()
fs2_openT-20040405.exe 004a5dac()
fs2_openT-20040405.exe 00434cbd()
fs2_openT-20040405.exe 011adbd8()
fs2_openT-20040405.exe 011add98()
fs2_openT-20040405.exe 011adf58()
fs2_openT-20040405.exe 011ae2d8()
fs2_openT-20040405.exe 011ae658()
fs2_openT-20040405.exe 011ae818()
fs2_openT-20040405.exe 011ae9d8()
fs2_openT-20040405.exe 011aeb98()
------------------------------------------------------------------
Did not occur in D3D8
9) (The one time I got that far) FS2 crashed (access violation) when the mission should've ended
Did not occur in D3D8
-
1 - It does this when it switches to play a movie, whether it plays one or not. I agree that it shouldn't turn white. I'll look into it.
2 - What was the refresh rate that you got?
3 - Do the new media vps include LS's new suns? I haven't experienced this one but my test computers are a bit faster than yours. What command line options are you using?
4 - Known. This has a related problem of the entire HUD or at least the radar and (if in view) the sun will disappear if debris is in view more than 500m away. My "got to fix it" todo list has this problem at number 1.
5 - The sound changes preload (with -snd_preload) all of the gamesounds in sounds.tbl. HUD messages and numerous other things don't get preloaded so those are still going to create some lag. I'm not sure how much better this can get but tinkering will continue.
6 - I've noticed this recently as well but I'm not sure how long it's been happening. If it only happens with this build then I'll attribute it to the 32-bit changes. I'll look into this tonight.
7 - I'll have to go through to mission and try to figure out what's getting loaded at that point. It may have been a swap out to virtual memory though. The recent changes do reduce the memory footprint but using 32-bit with all of LS's effects can push the memory usage above 200meg in large missions. With only 256meg of RAM that's going to cause a few swap outs for you.
8 - No clue. I haven't changed anything in the AI code so I'll have to do some searching to try and find the problem there. Was there a particular target that does this?
9 - Is this the same mission from your other reports or a different one? Is it bug 0000165 (http://mgo.maxgaming.net/mantis/bug_view_page.php?bug_id=0000165) ?
Great bug report by the way. :D
-
2 - What was the refresh rate that you got?
It looks like it's about 60 hz. This is based on eyeballing a comparison b/t a screenshot of the main hall in FS2 and in Windows at 60, 70, 72, 75, and 85 hz.
3 - Do the new media vps include LS's new suns? I haven't experienced this one but my test computers are a bit faster than yours. What command line options are you using?
Yes, and my command line flags were "-spec -glow -pcx32 -jpgtga -fps -snd_preload". So they were being loaded and displayed.
8 - No clue. I haven't changed anything in the AI code so I'll have to do some searching to try and find the problem there. Was there a particular target that does this?
It was the Maul and Nequael, both cargo-carry transports. The Maul, at least, is scripted to drop its cargo.
9 - Is this the same mission from your other reports or a different one? Is it bug 0000165 ?
Yes, this is all the same mission, and it's not that bug. I'd completed all objectives, hit alt-j, the wormhole had closed, and then the screen went black and an access violation appeared. The mission did not register as completed, so I was able to go back and play it again with D3D8. Next time I'll have to go to the tech room. (I got an Allied Defense Citation, though :D)
One thing I forgot to add about my D3D experience - when the Carthage and Dashor jumped in, the Carthage (a GTD Orion) appeared before the subspace wormhole while the Dashor (GVCv Sobek) appeared out of the wormhole.
Great bug report by the way. :D
Good to hear. :D
-
It looks like it's about 60 hz. This is based on eyeballing a comparison b/t a screenshot of the main hall in FS2 and in Windows at 60, 70, 72, 75, and 85 hz.
I'm not sure what the problem is here but I'll check in to it. I usually play in a window rather than fullscreen so this is something that I would probably never notice if you didn't point it out.
Yes, and my command line flags were "-spec -glow -pcx32 -jpgtga -fps -snd_preload". So they were being loaded and displayed.
"-spec" doesn't really work yet in OpenGL but shouldn't hurt anything. I've made changes since this test version to not do any setup for spec maps/lighting if the command is used to save time and memory. Try the sun glow thing again without "-pcx32" and let me know if it still does it, probably shouldn't matter but I'm curious.
I'd completed all objectives, hit alt-j, the wormhole had closed, and then the screen went black and an access violation appeared.
I'll look into this one but if you can recreate it in OpenGL then please try it again with the "-novbo" option and see if it still happens.
-
one question about the OGL mode (i just tried this btw - fantastic stuff, my FPS actually went above 30!!!) is Ambient lighting enabled in it yet? Cause thats the one thing missing that would make using this soooooo worth it!!
Edit: Wait a sec...so OGL doesn't have spec??
-
Ambient lighting yes. If you mean specular lighting then no, sort of. Most of the code is there and just needs a couple of other things to be enabled correctly. This is on the todo list but I'm not really sure who was going to actually do it.
I working mainly on trying to fix a few OpenGL bugs:
- debris making HUD go away
- jump nodes not showing up right
- invisible brackets around targeted subsystem in targetbox
- improperly rendered lightning arcs on critically damaged ships/debris
Those problems have a bit higher priority on my todo list at the moment than the specular lighting. Hopefully someone else will get spec lighting done for 3.6 though.
Stuff that is fixed:
- full nebula missions are no longer impossibly bright
- full nebula lighting rendered correctly.
-
ok on the spec - but how do I activate ambient lighting? i have the command line there, but it doesnt seem to work!
-
Oh you mean "-ambient_factor"? Well I guess that doesn't work, or rather it's just not implemented yet ... But it is now ;) I'll get some OpenGL updates in CVS this weekend and will put this in as well.
-
Is it bad that I'm doing my hi-res textures in .tga format?
-
no, but if they are really big you might want to use JPG instead, unless you need the Alpha channel for something.
-
I haven't tried your suggestions (yet), but I've found that Unreal Tournament also seems to run OpenGL at the same refresh rate as FS2. I also had to force it to use it by showing all graphics APIs, rather than just the ones it thinks my card can handle.
So it may just be a system-specific issue. Yes, I do have the latest nVidia drivers. ;)
-
http://dynamic4.gamespy.com/~freespace/fsdoc/index.php/media%20VP
PLEASE KEEP THIS UPDATED.
really, please do, it is hell to write a guide without a single, reliable listing not somewhere halfway down a page in some thread.
-
Updated.
Incidentally, how do you set a password? (Or can you?)
-
ok, herre is how you log into the wiki.
you select a new username, a WikiWord, a word wich has at least2 caps, neither at the end. You input a random password, you only need to remember it. there, you're done, and you have your own login.
now, if you mean password protect a certain page from unauthorized editing, talk to Sanwich.
-
No, I signed in with no password the first time. I couldn't find any way to make that a password. Is there a way?
Back to the build, I found that disabling -jpgtga got rid of the sun problem. -novbo didn't help the crash-on-warpout problem though. :sigh:
-
I think the targas look better, and they arent too big, so its all good. Did wonders for the herc 2, just in making it look sharper and cleaner, instead of all blurry and sloppy. All the capships that use that basic lights texture look better now, cleaner, and hi-resified.
-
You don't need a password on the Wiki unless you want to do admin stuff.
-
Originally posted by Turambar
Is it bad that I'm doing my hi-res textures in .tga format?
I am not sure if DDS has a alpha channel but you might want to consider using DDS for memory concerns. bigger downloads but more efficient.
-
The only reason why you wouldn't want to use .dds is if there a smooth gradients in your textures.
Otherwise DXT5 should handle it just fine (it has an alpha channel in case you're wondering).
So be sure to check after compression if it's acceptable.
-
Originally posted by WMCoolmon
It looks like it's about 60 hz. This is based on eyeballing a comparison b/t a screenshot of the main hall in FS2 and in Windows at 60, 70, 72, 75, and 85 hz.
Sorry if you already know this, but 2k/XP won't display OpenGL games at above 60Hz unless you force it to (I assume just when fullscreen - I don't play windowed). Something to do with MS removing the "Optimal" setting for the refresh rate, and it defaults to the lowest specified rate - 60Hz.
I use RefreshForce to do it:
http://www.pagehosting.co.uk/rf/
-
With regard to the 4000+mb memory usage, um, this is just pure speculation, but perhaps the extra MB above your system capacity is actually virtual memory on your hard drives? I wouldn't rule out the possibility that FSO could be using over a gig on my virtual memory swap file...
-
Over a gig is certainly plausible (note the size of the FS2 root dir if you had a full install), but 4GB+? Something's not right there. :nervous:
-
Okay, maybe not the sum total memory FS2 is using, but *MAYBE* its actually reporting all the memory in the system plus the total sum size of the virtual memory swapfile, whether that swapfile is being used by FS2 or not...i mean, swapfiles are often larger than 3GB, especially if you have a "static" (unchanging) swapfile customized in your System Properties...and even if you don't...it can be rather huge anyways.
I'm out of ideas...
-
I get that sometimes too. And I KNOW I don't have 4GB of virtual memory (page file + real memory).
-
FS2 should not, with today's technology, be taking up 4GB of space, unless you are utterly insane and
Originally posted by TopAce in another thread
Make a 65536x65536 subspace texture, remove the HTL flag and try to destroy the Lucifer. ;)
Including swapfiles. Especially swapfiles, because it means that accessing them would only be slightly faster than grabbing the data from a file.