View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000600 | FSSCP | OpenGL | public | 2005-10-23 07:37 | 2005-11-01 03:40 |
| Reporter | StratComm | Assigned To | taylor | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Summary | 0000600: OGL only produces a few unique screenshots until game is reset | ||||
| Description | I don't know what the best way to describe this is, but it's been hampering my attempts to gather screenshots of mods effectively for quite some time. Basically, when I try to take a sequence of screenshots in OGL, I get a set of tga files in my mod directory that corresponds to the number of times that I pressed printscreen, but only the first couple of them are unique. The rest are identical copies of the last unique screen cap. This has been present for quite a while. It seems to be dependent on the number and size of maps loaded into the mission; I can get more out in a nebula mission with only a few classes of ships present than in a mission loaded down with Lightspeed's nebulas and such. | ||||
| Additional Information | I've only seen this in OGL, but that's really the only mode C:\Games\FreeSpace2\fs2_open_r-20051018.exe -mod StratMod -spec -glow -jpgtga -nomotiondebris -2d_poof -ship_choice_3d -3dwarp -snd_preload -ambient_factor 85 I use since it's the only one that gives me spec. I don't know if it works in D3D or not, but the whole screenshot system is different there. I also run out of a custom mod directory 95% of the time, since I preserve the root level for stable retail data, if that's necessary to reproduce this. | ||||
| Tags | No tags attached. | ||||
|
|
Pasting my command line into the additional info window seems to have interrupted what I had already said. Sorry guys, the stuff before C: is supposed to come in the next paragraph, so parse that as best as you can. |
|
|
What video card and driver version are you using? I tried this under Linux and it worked fine so there doesn't appear to be anything basic wrong with the code. I am going to make some changes for the sake of error correction and failure but those things shouldn't hurt what's there now. The mission, and what's loaded in it, should have no affect on why it doesn't work (unless it's a driver issue) since all the code does is open up a file on the disk, grabs the image data off of the framebuffer and save it to that file. The only thing I can think of is that glReadPixels() is failing somehow or that the drivers perhaps are failing spec as far as possible defaults go. I'll go ahead and force a single front buffer read and we'll see if that helps in the next build. If not then I'll have to come up with something a bit more creative. |
|
|
For the record, it's a Raedon X800XT, drivers are somewhere in the 5.8 range. It's spanned driver versions though. And could this have anything to do with the bug I'm getting where lab screenshots don't reflect where I've rotated the model to? I'll have a look at the next build and check out both. |
|
|
It's likely the same basic problem but it's not the same code. And this does appear to be mostly an ATI thing though I don't know why. I'm hoping that when we go to SDL for video (in OGL at least) that this will largely get alleviated. I would prefer not to replace current the GL init process in Windows, knowing that it's going to be replaced with SDL anyway, unless it's absolutely needed. Hopefully what I've done will at least help the screenshot code though. |
|
|
Had a chance to test any newer builds yet? |
|
|
Got to it today, actually. Screenshots work now (albeit they take longer to save, which makes sense as I'm under the impression that they were getting pulled out of a buffer before); the lab is still goofy but you said you weren't going to touch it. I also see someone managed to get the lab interface to save as part of the screenshot for me, which is a new behavior though I suspect that it is unrelated to this fix. edited on: 10-26-05 20:22 |
|
|
I set it force read off of the front buffer which may be a little slower on some ATI cards/drivers than reading off of a back buffer like it was probably doing before. That can usually just be fixed with newer drivers though so maybe it will get better in time. Now that I know what the problem is I'll see if I can't optimize it a bit more. It's working at the same speed for me with my NVIDIA card so maybe there is some minor ATI optimization I can make there. The change I made probably would have made the interface show up in the screenshot but it shouldn't really have helped the model problem at all. I'll see if I can't work on that some as I've gotten my Windows computer working again (been a while). |
|
|
Going ahead and resolving this. It will take a bit more research to come up with a better solution for speeding it up but I do have a few ideas. Not really worth leaving this open just for that though. |
|
|
Fixered. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-10-23 07:37 | StratComm | New Issue | |
| 2005-10-23 07:39 | StratComm | Note Added: 0003641 | |
| 2005-10-23 10:19 | taylor | Status | new => assigned |
| 2005-10-23 10:19 | taylor | Assigned To | => taylor |
| 2005-10-23 13:24 | taylor | Note Added: 0003642 | |
| 2005-10-23 18:49 | StratComm | Note Added: 0003644 | |
| 2005-10-23 23:04 | taylor | Note Added: 0003645 | |
| 2005-10-26 20:04 | taylor | Note Added: 0003669 | |
| 2005-10-27 00:17 | StratComm | Note Added: 0003670 | |
| 2005-10-27 00:22 | StratComm | Note Edited: 0003670 | |
| 2005-10-27 00:41 | taylor | Note Added: 0003671 | |
| 2005-11-01 03:40 | taylor | Note Added: 0003699 | |
| 2005-11-01 03:40 | taylor | Status | assigned => resolved |
| 2005-11-01 03:40 | taylor | Resolution | open => fixed |
| 2005-11-01 03:40 | taylor | Note Added: 0003700 |
