+- Renegade Projects Network Forums (https://forums.renegadeprojects.com)
+-- Forum: Inject the Battlefield (https://forums.renegadeprojects.com/forumdisplay.php?fid=60)
+--- Forum: Ares General Discussion (https://forums.renegadeprojects.com/forumdisplay.php?fid=19)
+--- Thread: Re: Screenshots (/showthread.php?tid=1999)
Re: Screenshots - XTF - 08.09.2011
Opening a new topic, as both the old topic and the issue are closed.
http://forums.renegadeprojects.com/showthread.php?tid=1488
I'm working on the RA2 screenshot code. Most time appears to be spend in lock(). lock() takes about 882 ms in my case (1600 x 1200, Q9450) while the entire function takes 925 ms. So the PCX part appears to be trivial.
How did you avoid this in the YR code?
I guess lock() copies the primary surface from video mem to system mem, but I've no idea why it's taking so long.
Nevermind, it's my loop that transforms the data from 16b to 24b that's taking so long. No idea why though. The memory returned by lock() is already in system memory, right?
RE: Re: Screenshots - DCoder - 09.09.2011
No, the game has its own ideas about which surfaces go into which memory. In Ares we added code to force all surfaces into system memory, and rewrote the screenshot function to write 16 bit BMPs. This makes the lock itself cheap, and the screenshot writer only needs to copy data from the surface without recompressing it in any way. It still feels slow to me, but that might be because I'm running 1920x1080.
Search for Game_MakeScreenshot in http://svn.renegadeprojects.com/filedetails.php?repname=Ares&path=%2Ftrunk%2Fsrc%2FMisc%2FSurfaces.cpp for how it was done.
RE: Screenshots - XTF - 09.09.2011
(09.09.2011, 06:41:01)DCoder Wrote: No, the game has its own ideas about which surfaces go into which memory. In Ares we added code to force all surfaces into system memory,I assume that was done to improve performance?
Did you do any benchmarks?
RA2 might benefit from doing that too. And it'd certainly solve the screenshot issue. Otherwise one could do a blit from video to a system memory surface.
Quote:and rewrote the screenshot function to write 16 bit BMPs. This makes the lock itself cheap, and the screenshot writer only needs to copy data from the surface without recompressing it in any way. It still feels slow to me, but that might be because I'm running 1920x1080.Saw that one already. My code writes PNGs now.
Search for Game_MakeScreenshot in http://svn.renegadeprojects.com/filedetails.php?repname=Ares&path=%2Ftrunk%2Fsrc%2FMisc%2FSurfaces.cpp for how it was done.
RE: Re: Screenshots - DCoder - 09.09.2011
Yes, that was mainly done to improve performance. Several testers reported significant speed improvements after applying that change. It makes sense, because if a surface was in VRAM, Lock() has to transfer it all into system RAM before it can give you a pointer to it, and Unlock() has to push it back to VRAM... and in some places the geniuses at WW draw stuff pixel by pixel, causing repeated lock/unlock cycles.
Why are you working with PNG? I'm pretty sure that a simple read/write loop into a 16 bit BMP will work faster than read/process/write into a PNG, doing image compression here feels like a waste of time to me.
RE: Screenshots - XTF - 10.09.2011
(09.09.2011, 18:53:27)DCoder Wrote: Yes, that was mainly done to improve performance. Several testers reported significant speed improvements after applying that change. It makes sense, because if a surface was in VRAM, Lock() has to transfer it all into system RAM before it can give you a pointer to it, and Unlock() has to push it back to VRAM...Or lock() maps the video memory into the app's address space, which looks to be happening in my case. That's even slower.
Quote:and in some places the geniuses at WW draw stuff pixel by pixel, causing repeated lock/unlock cycles.Ouch.
Quote:Why are you working with PNG? I'm pretty sure that a simple read/write loop into a 16 bit BMP will work faster than read/process/write into a PNG, doing image compression here feels like a waste of time to me.PNG can be uploaded to the web as-is. XCC Mixer doesn't even support BMP.
Compression time is no problem.
RE: Re: Screenshots - XTF - 13.09.2011
What are the surfaces used for? VideoBackBuffer=0 doesn't move the primary and hidden surfaces to system memory.
RE: Re: Screenshots - DCoder - 13.09.2011
Yeah, that's why we had to write custom code. There are lots of surfaces in the game for various things, we just made a blanket change to force all of them into system RAM.