search

omf2097 / openomf

One Must Fall 2097 Remake
http://www.openomf.org
MIT License
362 stars 35 forks source link

Screenshot functionality adds distorted graphics if screen resolution is not 4:3 #324

Closed Rondom closed 7 years ago

Rondom commented 8 years ago

When using a non 4:3 screen resolution (as it is common these days) and running the game in fullscreen, the screenshot functionality adds some distorted graphics from some buffer on the right side of the image, filling up the image. Runnig with valgrind shows many errors, when taking a screenshot. The screenshot taken is 1920x1080 (16:9), while the actual game is 4:3. Thus the size used for creating the screenshot should probably be the size of the actual "drawing area" and thus have 4:3 dimensions as well as avoiding the out-of-bounds read.

screenshot_16440

katajakasa commented 8 years ago

Cannot reproduce on Windows 10 (directx backend, SDL 2.0.3).

Tested with resolutions (both with fullscreen on and off):

Please supply valgrind reports, it might help locate problems.

Rondom commented 8 years ago

This happens on Debian testing (SDL 2.0.4).

video_screnshot in src/video/video.c gets the full 16:9 dimensions. Other ways of getting the dimensions such as SDL_GetRendererOutputSize get the same 16:9 dimensions. This is correct behaviour as far as i understand (not very familiar with SDL), SDL_RenderReadPixels does not seem to assign the "leftover" pixels (that's what I conclude from valgrind). What is the behaviour on windows?

==11602== Conditional jump or move depends on uninitialised value(s)
==11602==    at 0x59F8B8B: ??? (in /lib/x86_64-linux-gnu/libpng12.so.0.54.0)
==11602==    by 0x59FC7C0: png_write_row (in /lib/x86_64-linux-gnu/libpng12.so.0.54.0)
==11602==    by 0x59FC9E7: png_write_image (in /lib/x86_64-linux-gnu/libpng12.so.0.54.0)
==11602==    by 0x4207E5: image_write_png (image.c:192)
==11602==    by 0x459EB5: engine_run (engine.c:307)
==11602==    by 0x45A8B9: main (main.c:221)
katajakasa commented 7 years ago

This may in fact be an SDL bug. I can't get this to reproduce on windows or my linux systems at all. Maybe driver specific ? Does this still happen on SDL 2.0.5 ?

katajakasa commented 7 years ago

Cannot reproduce on linux or windows on SDL 2.0.5. Closing as wontfix. If this pops up again, please open a new ticket.

Rondom commented 7 years ago

I had already forgotten about this... Indeed it sounds like a bug outside of OpenOMF. For the record, I can still reproduce this (on a different Laptop) with Debian Testing using the system SDL (2.0.5) with Intel graphics. I will do more debugging as time allows.