 |
Implemented saving image _menuLastGameFrame in svn rev 10938. Added "textures/common/menuLastGameFrame" material in svn rev 17303. Getting the image is achieved with the same code which gets a screenshot for savegames. It seems that GUI overlays are excluded, which is OK. I won't be surprised if underwater and X-ray overlays are ignored too, unfortunately... Also, it turns out this way does not work correctly with non-standard RenderScale. It affects both this image and savefile screenshots. |
|
|
Unfortunately, I had to revert this due to complaints about random textures popping briefly on screen when player opens in-game menu: https://forums.thedarkmod.com/index.php?/topic/22635-beta-testing-213/page/4/#findComment-500576 (svn rev 10945 and 17309) |
|
|
I returned to this problem after seeing how the new "Displacement" map just uses _currentRender and hacks around various settings (like force-disabling antialiasing). However, trying to run any kind of solution like this in a real map resulted in a log of artifacts on the captured screenshots =) The hardest part about these artifacts is that they happen on a single frame, which is hard to capture in RenderDoc. After a lot of blind attempts I finally realized that programmatic RenderDoc capture (sometimes multi-frame capture) is the proper way to debug such issues. So I have added RenderDoc integration: r11042 Integrated RenderDoc API: now we can trigger or start/end RenderDoc captures programmatically. r11043 Supported triggering capture of several frames in a row with RenderDoc. r11044 Added cvars to trigger RenderDoc capture on menu start or on menu exit. r11047 RenderDoc_TriggerCapture console command now accepts number of frames as argument. This allows to trigger frame capture at exact moment (e.g. opening menu) or around exact scope. In fact, I have added some cvars/commands for this. For instance, I mostly used "renderdoc_capture_startmenu 10" + "com_maxfps 5", then opened and closed menu very quickly to fit everything into 10-frame capture. This new tool finally allowed me to actually find and understand what's going wrong and why, instead of just guessing and hacking. I uncovered some really nasty bugs deep around our framebuffer abstraction: r11045 Added validation of Framebuffer state and fixed various state issues present there. r11046 Fixed FrameBuffer::Generate changing bound texture on active texture unit. Also I fixed one threadsafety issue in volumetric lights implementation: r11048 Moved some weird function definitions from renderer frontend into Intersection.cpp. r11049 Fixed threading bug: volumetric light backend code used fronend-owned frustum. After all these fixes I finally got no differences, glitches, and random flickers on the captured shots. Initially I tested all of this using CaptureRenderToImage command, which schedules screen-to-texture copy but does not run backend commands immediately. However, it generated the output image with all the HUD, and upside-down. So in the end I decided to revive the old code which I originally done for this issue (in fact, I simply forgot I have already done it before): r11051 Reapplied back rev 10938, which was reverted in rev 10945. r17385 Reapplied rev 17303, which was reverted in 17309. The last part is removing the one-frame flicker on quicksave and starting menu: r11052 Call R_IssueRenderCommands without SwapBuffers inside CaptureRenderToBuffer. |
- Anonymous
