Closed GoogleCodeExporter closed 9 years ago
Very strange. When this happens, is the screen white too?
Original comment by acaudw...@gmail.com
on 22 Feb 2010 at 2:58
Nope, although insanely slow (and seems to miss updates if you pull another
window in
front) it shows the start of the sequence just fine.
Original comment by niemueller
on 22 Feb 2010 at 8:42
It sounds like glReadPixels() is returning all white for some reason, like its
pointing at the wrong buffer, somehow.
Could you try and replace the glReadPixels call in src/ppm.cpp with:
glReadBuffer(GL_BACK);
glPixelStorei(GL_PACK_ALIGNMENT, 1);
glReadPixels(0, 0, display.width, display.height,
GL_RGB, GL_UNSIGNED_BYTE, next_pixel_ptr);
And see if that helps.
Original comment by acaudw...@gmail.com
on 22 Feb 2010 at 10:04
Nope, that didn't do it. Still the same result. I have re-verified and after the
initial ASCII header there are only 0xFF values.
Original comment by niemueller
on 22 Feb 2010 at 10:51
I guess another thing would be to check if glReadPixels is in fact setting
values to
0xFF (ie next_pixel_ptr[0] == 0xFF after call but not initially or something
like
that) and if glReadPixels() is setting an error so that glGetError() returns a
non
zero value.
It could also be that 'char' arrays (pixel1, pixel2, pixels_shared_ptr and
next_pixel_ptr) need to be changed to be 'unsigned char'.
Original comment by acaudw...@gmail.com
on 23 Feb 2010 at 9:19
Can you provide some patch to try? I have also tried the (new) Fedora package,
no
success either. I have asked the package for more info, e.g. if the problem
appears
also on his box and on 32-bit
(https://bugzilla.redhat.com/show_bug.cgi?id=567559).
Original comment by niemueller
on 23 Feb 2010 at 9:34
Ok I wrote a patch to try:
This test patch changes char to unsigned char and will print some debugging to
STDERR
each time we call glReadPixels().
This will tell us (hopefully):
- was an error set by glReadPixels(), and what was it.
- did glReadPixels() modify the input array or leave it the same.
- did glReadPixels() modify the input array to 0xFF.
Original comment by acaudw...@gmail.com
on 23 Feb 2010 at 10:29
Attachments:
Tried it. Still the same result, prints the following on the screen:
glReadPixels(0, 0, 1024, 768, 6407, 5121, next_pixel_ptr)
next_pixel_ptr[0] == 0xFF (changed to 0xFF)
Anything else you want me to try?
Maybe you can also try it with the F-12 x86_64 Live CD from
http://download.fedoraproject.org/pub/fedora/linux/releases/12/Live/x86_64/Fedor
a-12-x86_64-Live.iso
on your system?
Original comment by niemueller
on 23 Feb 2010 at 12:10
[deleted comment]
I've got the same issue on a WinXP box.
BUT: when runned without --output-framerate the program window is just white.
Case 1) gource.exe some_log_file
Everything is just fine.
Case 2) gource.exe some_log_file --output-ppm-stream some_file
--output-framerate 25
I can see the animation in the program window, but it runs much much slower
than in
case 1, and it seems to be displaying a single white frame for a fraction of
second
every second or so.
The stream is all white frames.
Case 3) gource.exe some_log_file --output-ppm-stream some_file
The program window is all white.
Original comment by tomasz...@gmail.com
on 23 Feb 2010 at 2:16
Can you try commenting out these 3 lines in FrameExporter::dump():
display.renderToTexture(screentex, display.width, display.height, GL_RGBA);
display.fullScreenQuad(true);
...
display.fullScreenQuad(false);
If this fixes it, you will see upside down images in the ppm file.
Also if this doesn't work, could you try version 0.23 from the Downloads
section as I
made a lot of changes between 0.23 and 0.24 and it may be one of those.
Cheers
Original comment by acaudw...@gmail.com
on 23 Feb 2010 at 8:54
It's upside down but otherwise it contains the expected output! So how do we
get it
flipped without loosing content again?
Original comment by niemueller
on 24 Feb 2010 at 1:48
Great, I wasn't sure if we were going to figure this out.
Can you apply this patch to the original source. It does the flip in software
now.
Original comment by acaudw...@gmail.com
on 24 Feb 2010 at 3:28
Attachments:
The patch works just fine. Thank you! Will you put out a new release? Would
make the
life much easier for packagers.
Original comment by niemueller
on 27 Feb 2010 at 8:03
Now in 0.25
Original comment by acaudw...@gmail.com
on 1 Mar 2010 at 1:22
Original issue reported on code.google.com by
niemueller
on 21 Feb 2010 at 9:46