[taylor]

This is just a quick and dirty build to test some newer code for screenshots and popup backgrounds when using OpenGL.  This is current CVS, debug build only, and without voice support.  All this is really for is to let me know if the new extension support crashes for people and whether there is any speed increase/decrease in taking screenshots or getting popup windows.

The two main changes are to test that speed increase:
 1) Is like the old code but with a few changes that will hopefully be either as fast for most people, or faster for those that have had trouble
 2) Is the same basic thing but using PBOs instead of plain in-memory handling

I'm not using the PBOs to their full extent so there is room for later improvement, but I'd like to get an idea if this is worth working on or not.

By default the game will just the plain old upgraded code (for speed changes just compare this with any other build).  You can try using the PBOs with the -use_pbo cmdline option.

Remember that this build is only for testing those small new changes and shouldn't be used as a general build.  I assume that everyone knows how to test the screenshot code, but test the popup related changes by going into the mission simulator (the background will save, the test part, then the popup window for missions will appear).  Another way to test the popup related changes is to hit ESC while in a mission, the background will save and then you'll be presented with the popup window.  If the game freezes for a long time when you take a screenshot, or before any of the popups appear, then let me know.  If any of that is faster than before then let me know that too, and whether it was the PBOs that gave you the speed increase.

http://icculus.org/~taylor/fso/willrobinson/20060417-win32d.rar

[DaBrain]

Worked fine for me so far, but I've got a Nvidia card.


I wanted to give you some feedback on the -no_emissive_light feature. If the sun doesn't shine on the ship, it's really dark. Very nice.

There is a problem though. Turrets don't seem to care about this...

http://img357.imageshack.us/img357/5565/emissive7kb.jpg

[StratComm]

Well, everything works ok without -use_pbo except for one thing: pausing the game after you have taken a screenshot (x800xt/Catalyst 5.8 IIRC) results in the screenshot (I think the last one, though I could be wrong about that) being displayed in the background rather than the capture from when you pressed pause.  Otherwise, delay is not bad and screenshots are saving out correctly.  I was trying to test the erronious case in -use_pbo but ran in to an int3 (Int3(): From C:\temp\fs2_open.t\code\Mission\MissionParse.cpp at line 2430) on Apocalypse and didn't get the chance to actually try that sequence.

[taylor]

There is a problem though. Turrets don't seem to care about this...

I've noticed that as well.  It's on my todo list.

Well, everything works ok without -use_pbo except for one thing: pausing the game after you have taken a screenshot (x800xt/Catalyst 5.8 IIRC) results in the screenshot (I think the last one, though I could be wrong about that) being displayed in the background rather than the capture from when you pressed pause.  Otherwise, delay is not bad and screenshots are saving out correctly.

Is the delay noticably shorter than it was before?  The reason I'm asking is that with my NVIDIA card this code is actually a bit slower, but that has more to do with NVIDIA's driver prowess and the old saving process.  Previously it grabbed screenshots in 24-bit color, but now it grabs them in 32-bit color (to try and get a faster read path) and then converts them to 24-bit on save.  There is room to optimize this, but if it's not already noticably faster then optmization won't help all that much.  The popup backgrounds should be the same speed or faster than before, but they don't get converted back to 24-bit color either.

I'm not sure what's up with the screenshot being displayed for the popup background.  I doesn't appear to do that for me, and they don't use the same buffer for reading (in either the normal or the PBO case) so I'm not exactly sure how it could mess up like that.  It may be the result of the previous attempts to prevent the single color screens on ATI cards but I'll test that later.

[StratComm]

It's hard to say.  The first couple of saves were laggy, but that may have just been memory stabilizing for what was onscreen (screenshots taken while in alt-pause mode); after two or so there was virtually no slowdown.  Same thing with pausing; it seems to be directly related with how much stuff is getting brought in to the mission at the time of pressing that button initially. 

As for that stupid screenshot-as-background, who knows.  If you recall, I've had issues like that since I got this computer, so it may be something quirky with the particular drivers or even the card that I'm using.  I admit to knowing very little about the architecture of GPUs so I'm hesitant to even offer up any possibilities as to why it's doing that.

[taylor]

I wanted to give you some feedback on the -no_emissive_light feature. If the sun doesn't shine on the ship, it's really dark. Very nice.

I forgot to ask before, but what do you think about this being a default option?  I was thinking about just making it disable automatically if -ambient_factor is set to less than 80, or maybe 85.  I really don't want to add this as a cmdline option if I can help it.

It's hard to say.  The first couple of saves were laggy, but that may have just been memory stabilizing for what was onscreen (screenshots taken while in alt-pause mode); after two or so there was virtually no slowdown.  Same thing with pausing; it seems to be directly related with how much stuff is getting brought in to the mission at the time of pressing that button initially. 

Can you tell any sort of difference when using PBOs and not, or previous versions and this one?  And when testing PBOs be sure they are actually enabled, the -use_pbo option only tells it to use them if it can.  To know if it will actually be able to use PBOs just check you fs.log file and in the OpenGL init part just look for Using extension "GL_ARB_pixel_buffer_object"., but if it doesn't then PBOs will always be disabled.  If it said that it was unable to find it then PBOs will be unavailable for use.

And I get the laggy saves for the first one or two as well, but it's a split second lag (a little over 1/10th of a second by timed measure).  It's generally pretty instant after that.  I've heard horror stories about the lag from some ATI users so I'm trying to reduce it as much as possible, or at least get it more uniform performance wise across the two main video card makers.  Really this is our code though since there are numerous things that can be done to help speed this up.  The new code is trying to use most of those, whereas the old code was mainly optimized for NVIDIA, and code simplicity.

[StratComm]

Unable to find it.  How new of a feature are we talking here?  Because I've had really bad experiences with ATI's drivers of this year.

[taylor]

Unable to find it.  How new of a feature are we talking here?  Because I've had really bad experiences with ATI's drivers of this year.

I didn't think it was that new, but I don't see any support from ATI on it, now that I'm looking.  It is a relatively new extension though with it being about 2 years old in total.  It is a official ARB extension for at least a year I believe so I thought the newer ATI drivers would have it by now.  Guess that's ATI for you. 

I guess the async code that PBO allows will be restricted to NVIDIA for a little while longer.  Hoepfully the new base code will help ATI somewhat though, until they support PBO.

[taylor]

There is a problem though. Turrets don't seem to care about this...

I wanted to touch on this once again, so if I forget to do anything about this then you can bug me about it.

It's not a lighting issue but a render order issue.  All subobjects are drawn before the main hull, which creates a problem since the lighting on those objects is computed before the main part of the ship is even drawn.  This causes the turrets, and other subobjects, to get lighting applied as if there was no hull there.  Obviously that's just wrong since you'll get light that the rest of the model would otherwise block out.  It's also a lot slower since the video card is drawing all of that crap when most of it shouldn't be.

The fix is to adjust render order, something I've played with before, so that turrets and moving subojects are drawn after the main hull.  This way the video card can properly cull them out quickly rather than rendering them first.  I'm not 100% sure that fixes the lighting problem since it's code in another one of my old trees and I haven't used it in almost a year.  I'll try a quick cut-n-paste, see how it works, and if it doesn't screw everything up then I can send it to you via PM to test out for yourself.

I remember it was always an issue that it would draw the destroyed versions of subsystems as well, even when they didn't get shown.  That's something else that needs to get fixed for the sake of basic performance.

[StratComm]

That's going to destroy render effects for anything that's ever used transparency and subobjects (all cockpitted fighters).  Be careful with that one Taylor.

[taylor]

That's going to destroy render effects for anything that's ever used transparency and subobjects (all cockpitted fighters).  Be careful with that one Taylor.

The idea is to be selective about render order rather than the all or nothing approach used now.  Turrets and animated subobjects and damage subobjects would be set to render after the main hull, non-animated subobjects would still render first which means that cockpits should still work for all existing models.  I know for sure that it worked with the Perseus and Herc cockpits previously.  Of course that's all I had to test with at the time so I'm not sure if any other effects would mess up because of this.  That's why I never put the code in CVS last year.

The point is that the less subobjects we draw before the main hull the better performance can be.  You have to remember that the game originally relied on software clipping to avoid rendering unneeded objects.  With the HTL code path we bypass most, if not all, of that code which means that it's done in hardware.  But that doesn't mean we can send whatever we want to the card and have it perform well, we have to help it out a little (or a lot depending on how you look at it ).

[StratComm]

Yeah, well then it starts to get really murky.  I shouldn't be saying this publically but I know of at least one model underway that's got transparency on potentially damage subobjects and turrets (animated subobject class, don't know if that's universal or not) which would mean that making render order correct would add... complications.  It would actually make it easier, truth be told, if the subobjects could have transparencies of their own that would work correctly with the hull, but that would need to be known - and fixed - beforehand.  I would not object to just drawing the hull first all the time and fixing any cockpitted models in existance to work with the new code.  It's not like we're talking about a retail data issue, after all.

I would actually prefer to see cockpits done without the use of subobjects at all; it's pretty easily doable and is the method I tend to prefer now.  Unfortunately it's a tad bit harder to explain to new modders which is why I haven't made a big push for it.

[taylor]

Yeah, well then it starts to get really murky.  I shouldn't be saying this publically but I know of at least one model underway that's got transparency on potentially damage subobjects and turrets (animated subobject class, don't know if that's universal or not) which would mean that making render order correct would add... complications.  It would actually make it easier, truth be told, if the subobjects could have transparencies of their own that would work correctly with the hull, but that would need to be known - and fixed - beforehand.  I would not object to just drawing the hull first all the time and fixing any cockpitted models in existance to work with the new code.  It's not like we're talking about a retail data issue, after all.

The code I've got certainly isn't ideal, it's only best guess under the circumstances.  It would be simple to just add a name check where the subobject name would identify if it always needed to be drawn first or not.  The same type of name check is used to pick out turrets, thrusters, and damage subobjects already.

I don't know how far along that model is, but if it's usable in the game then I'll get you a build and you can just test it.  If it doesn't work then we'll have a better idea of what the code needs to work.  If it does work then there will be one less obstacle to getting the code in CVS.  I'll PM you the build link in a few hours and you can give it a try when you have the time.

I'm not in any hurry to get the code in CVS so there is no rush to test it.  It's just one in a very long list of things that I've played around with in the past and never got done with.  I've been going through my various old code trees and picking out the good stuff to go ahead and get in CVS (like PBO and FBO support, beam weapons counting for player stats, minor speed-ups, and a bunch of other things) so that it's easier to work on all of the new code I have coming.