You are wrong, Khawk. From MSDN:
void glReadPixels(
GLint x,
GLint y,
GLsizei width,
GLsizei height,
GLenum format,
GLenum type,
GLvoid *pixels
);
width, height - The dimensions of the pixel rectangle. The width and height parameters of one correspond to a single pixel.
Really, it's not hard to figure out even without a reference. Why would those parameters be width-1 and height-1? According to you, they are. At least Dragon88 was thinking logically, even if he was wrong.
~CGameProgrammer( );
EDIT: Even the Red Book (OGLPG) says on page 296 that those parameters are the width and height of the array of pixels to read.
[edited by - CGameProgrammer on December 3, 2002 12:19:34 AM]
Screenshots: how to save screen to TGA?
Kevin, by OGLPG I assume you mean your book, OpenGL Game Programming. I had a look at the source for chapter 7, and it does not work correct. Sure, it looks like it works, but in this case you're lucky you can't see what's wrong, at least not by looking at the screenshot.
When you allocate memory, you allocate a 800x600 block and you clear with a black color. When saving, you're reading only 799x599 pixels, leaving the upper row and right column untouched. Because the image background is also black, you won't see anything. But, reset the memory with 0xFF instead of 0, and you will see a white border in the upper and right edge in the screenshot. You can also change the clear color in OpenGL and see that the edge has a different color than the background.
It can also be seen by changing the pack alignment right before glReadPixels. The default pack alignment is 4, and 800 is a multiple of 4. So if you only read 799 pixels per row, OpenGL will move the "store pointer" to next multiple of 4 (*) at the end of each row, which is 800, where it will store the next row. Change the pack alignment to 1 and the screenshot will look 45 degrees skewed.
(*) It's not the actual address that is rounded up to nearest multiple of 4, but the offset from the start address. But assuming the start address is a multiple of 4, it is the same thing.
[edited by - Brother Bob on December 4, 2002 7:18:15 AM]
When you allocate memory, you allocate a 800x600 block and you clear with a black color. When saving, you're reading only 799x599 pixels, leaving the upper row and right column untouched. Because the image background is also black, you won't see anything. But, reset the memory with 0xFF instead of 0, and you will see a white border in the upper and right edge in the screenshot. You can also change the clear color in OpenGL and see that the edge has a different color than the background.
It can also be seen by changing the pack alignment right before glReadPixels. The default pack alignment is 4, and 800 is a multiple of 4. So if you only read 799 pixels per row, OpenGL will move the "store pointer" to next multiple of 4 (*) at the end of each row, which is 800, where it will store the next row. Change the pack alignment to 1 and the screenshot will look 45 degrees skewed.
(*) It's not the actual address that is rounded up to nearest multiple of 4, but the offset from the start address. But assuming the start address is a multiple of 4, it is the same thing.
[edited by - Brother Bob on December 4, 2002 7:18:15 AM]
quote:Original post by CGameProgrammer
Really, it''s not hard to figure out even without a reference. Why would those parameters be width-1 and height-1? According to you, they are. At least Dragon88 was thinking logically, even if he was wrong.
~CGameProgrammer( );
EDIT: Even the Red Book (OGLPG) says on page 296 that those parameters are the width and height of the array of pixels to read.
[edited by - CGameProgrammer on December 3, 2002 12:19:34 AM]
Yes, I know they''re the width and height. I don''t know where you got the impression that I was saying it wasn''t the width and height.
The reason they are width-1 and height-1 was (from what I remember when doing the book/code) because values of (0,0,800,600) did not work.
The explanation from Brother Bob is more valid, and he''s probably correct (I can''t check myself now). The book has plenty of minor defects like this, and we''re always documenting them for the revision.
Kevin "Khawk" Hawkins
CEO and News Director, GameDev.net
Software Engineer, Raydon Corporation
Author, OpenGL Game Programming
Developer Diary
When you say "OGLPG" you mean the OpenGL Programming Guide, right? aka the Red Book?
Also you said values of 301,301 specify a 302x302 area, indicating you felt they were really width-1 and height-1. Not only does that make zero logical sense, but all documents I have found indicate it is width and height. If your code did not work, I would guess it is the fault of some other part.
~CGameProgrammer( );
Also you said values of 301,301 specify a 302x302 area, indicating you felt they were really width-1 and height-1. Not only does that make zero logical sense, but all documents I have found indicate it is width and height. If your code did not work, I would guess it is the fault of some other part.
~CGameProgrammer( );
quote:Original post by Khawk
Author, OpenGL Game Programming
I used OGLGP, not OGLPG.
I also admitted the code in the book is wrong. Bob has a valid point in that the memory buffer is not completely filled by the glReadPixels function because of the (799, 599) when the memory buffer is 800x600. For whatever reason I did that (it was written about 2 years ago - I can't remember), it's not 100% accurate - it will work and not crash, but it doesn't complete its desired functionality of giving the entire 800x600 client window area.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
