Open GoogleCodeExporter opened 9 years ago
I have tested with jpeg & bmp format for the screenshot and it shows the same
color blotches (same result on Mupen64).
I use 1964Video to take same screenshot in bmp format(convert to jpg) and it
looks good (see image1&3). The effect is greyish.
Original comment by pokefan0...@gmail.com
on 21 Jun 2010 at 4:39
Attachments:
Glide64 uses wxWidgets to create image files. As I know, wxWidgets uses its own
code to work with various image formats, so upgrade of lpng should not affect
it. I did not update wxWidgets for several month. So, the problem is really odd.
Original comment by gon...@ngs.ru
on 21 Jun 2010 at 6:21
[deleted comment]
[deleted comment]
[deleted comment]
Just attaching 2 screenshot from TWINE showing color blotching on parts of the
flag with black bg and parts of the suit with greyish bg or something.
Original comment by pokefan0...@gmail.com
on 28 Jun 2010 at 8:16
Attachments:
If it is normal or can't be fixed, please proceed to close as invalid.
Thanks
Original comment by pokefan0...@gmail.com
on 11 Jul 2010 at 7:43
If you look at image01(plugin screenshot), there are the polygons drawn around
the sun which is clearly visible.
In image02(window screen print) at the same location during gameplay, the
polygons are clearly suppressed/masked off by the plugin.
It seems to me that screenshot is not the same as window screen print which is
the exact screen display. Is it possible to do what window screen print is
doing?
Original comment by pokefan0...@gmail.com
on 11 Jul 2010 at 9:43
Attachments:
I guess I know what causes these color blotches. Glide64 uses glide3x API
functions to read frame buffer content to main memory. It's ok for 3dfx cards,
the content of the buffer returned as is, without any information loss. The
problem is that in many cases I use 16bit frame buffer with 3dfx cards.
Voodoo1-3 do not support 32bit rendering at all. On voodoo5 I also use 16bit fb
for games which use HWFBE because of small amount of available video memory.
The wrapper always renders in 32bit mode, but when frame buffer read functions
are used it converts the read buffer to 16bit to safely pass it to the plugin,
thus quality of screen shots degraded.
Original comment by gon...@ngs.ru
on 12 Jul 2010 at 4:42
[deleted comment]
Both read from video card's frame buffer. ReadScreen passes the data to the
emulator, while the code in the newSwapBuffers stores it in the screen shot
file.
Original comment by gon...@ngs.ru
on 18 Jul 2010 at 5:23
Original comment by gon...@ngs.ru
on 11 May 2011 at 11:50
Original issue reported on code.google.com by
pokefan0...@gmail.com
on 20 Jun 2010 at 5:23Attachments: