When I use the screenshot key (F9), I get pictures like this:

I had to resize and compress the screenshot because the Pfhorums has a 256 KB (?!) upload limit. It almost seems like the picture data is one pixel wider than the stated resolution. And the colors are off, almost like the RGB components are misaligned. The problem happens with both the Classic and Shader renderers.

Also, when I use OpenGL Shader, the landscapes just give me vertical lines. This is the main reason why I've been sticking with OpenGL Classic.

Here is the relevant bug information:

Aleph One 1.0.2

Windows 7 Service Pack 1

Intel HD Graphics 3000, driver version 9.17.10.2843

Resolution 1366 x 768

Screenshot bug happens with both OpenGL Classic and Shader

Landscape bug happens only with OpenGL Shader

Not exactly gaming material with the Intel graphics, but good enough for Aleph One!

## Screenshot and landscape bugs

- fiddler_on_a_roof
- Born on Board
**Posts:**63**Joined:**May 31st '12, 07:16-
**Contact:**

- fiddler_on_a_roof
- Born on Board
**Posts:**63**Joined:**May 31st '12, 07:16-
**Contact:**

On close inspection, this turns out to be a pretty interesting bug. The screenshot in the original post is skewed to the right. In fact, if you look closely in Paint or any other program, the ratio between the amount of rightward skew and the vertical height of the image is almost exactly 2/3.

Now the image data is stored row-by-row, starting from the bottom-left corner, with each R, G, B component of a pixel using 1 byte, respectively. The amount of rightward skew strongly suggests that the image data actually has 2 more bytes per row than the image header says it does. This extra 2 bytes wraps around to the line above it, and since each pixel consists of 3 bytes, then you get a rightward skew of exactly 2/3.

Also note that the image colors seem washed out. The reason is that in only 1 out of every 3 lines are the RGB components correctly aligned. 2 out of 3 lines are have misaligned RGB components, and thus appear somewhat gray.

But why the misalignment in the first place? The reason seems to be that 1366 x 768 is an weird screen resolution. Note that each horizontal line should take 1366 x 3 = 4098 bytes. For efficiency reasons, modern computers like to store data in chunks of at least 4 bytes each, but 4098 is not divisible by 4, and in fact has a remainder of exactly 2. Now for one reason or another (perhaps due to an integer divide, which chucks off the remainder), the image incorrectly stores its number of horizontal bytes as 4096 instead 4098.

For almost all other screen resolutions, the number of horizontal pixels (i.e. 640, 800, 1024, 1280, 1440, 1920, etc.) is divisible by 4, so this isn't a problem.

Here is an example of a screenshot taken from Rubicon X (Gators of NY) at 1366 x 768 resolution. Now here is almost the same scene from Rubicon X, but now taken at 1360 x 768 resolution (Note that 1360 is divisible by 4): Interesting, isn't it? Anyway, problem solved.

By the way, thanks to Switch for changing the upload limits!

Now the image data is stored row-by-row, starting from the bottom-left corner, with each R, G, B component of a pixel using 1 byte, respectively. The amount of rightward skew strongly suggests that the image data actually has 2 more bytes per row than the image header says it does. This extra 2 bytes wraps around to the line above it, and since each pixel consists of 3 bytes, then you get a rightward skew of exactly 2/3.

Also note that the image colors seem washed out. The reason is that in only 1 out of every 3 lines are the RGB components correctly aligned. 2 out of 3 lines are have misaligned RGB components, and thus appear somewhat gray.

But why the misalignment in the first place? The reason seems to be that 1366 x 768 is an weird screen resolution. Note that each horizontal line should take 1366 x 3 = 4098 bytes. For efficiency reasons, modern computers like to store data in chunks of at least 4 bytes each, but 4098 is not divisible by 4, and in fact has a remainder of exactly 2. Now for one reason or another (perhaps due to an integer divide, which chucks off the remainder), the image incorrectly stores its number of horizontal bytes as 4096 instead 4098.

For almost all other screen resolutions, the number of horizontal pixels (i.e. 640, 800, 1024, 1280, 1440, 1920, etc.) is divisible by 4, so this isn't a problem.

Here is an example of a screenshot taken from Rubicon X (Gators of NY) at 1366 x 768 resolution. Now here is almost the same scene from Rubicon X, but now taken at 1360 x 768 resolution (Note that 1360 is divisible by 4): Interesting, isn't it? Anyway, problem solved.

By the way, thanks to Switch for changing the upload limits!

- Crater Creator
- Vidmaster
**Posts:**943**Joined:**Feb 29th '08, 03:54-
**Contact:**

That

*is*interesting. Nice troubleshooting.