Hi fellow coders,
On running the code for Day 006, I find that while the y-axis is fine, the x-axis is inverted, in other words, as I press the left stick, the screen scrolls right and vice versa.
Please Note: I am using Casey's original code from the zip download, so I know that it cannot be a typo on my part. Also, this was working fine before with visual studio 2013 on Windows 7 64 bit, and only now since upgrading to Windows 10 and Visual Studio Community 2015, do I have this problem!
I have tested this on both an xbox 360 and xbox one controller, calibrated and apparently functioning correctly, until I run Day 006...
MY FIX:
I have found that if I change this:
XOffset += StickX >> 12;
to this:
XOffset -= StickX >> 12;
then this corrects the x-axis.
But I really want this to work as per the original code!
Can anyone please enlighten me as to what is actually going on here??? Thankyou in advance!
On running the code for Day 006, I find that while the y-axis is fine, the x-axis is inverted, in other words, as I press the left stick, the screen scrolls right and vice versa.
Please Note: I am using Casey's original code from the zip download, so I know that it cannot be a typo on my part. Also, this was working fine before with visual studio 2013 on Windows 7 64 bit, and only now since upgrading to Windows 10 and Visual Studio Community 2015, do I have this problem!
I have tested this on both an xbox 360 and xbox one controller, calibrated and apparently functioning correctly, until I run Day 006...
MY FIX:
I have found that if I change this:
XOffset += StickX >> 12;
to this:
XOffset -= StickX >> 12;
then this corrects the x-axis.
But I really want this to work as per the original code!
Can anyone please enlighten me as to what is actually going on here??? Thankyou in advance!
The x-axis isn't inverted and it is working as Casey saw it working too; it just looks that way because of the way the gradients are rendered.
From the MSDN documentation:
So pressing the thumbstick to the right results in a positive value.
If you look at the render gradient function, you will see that it's filling up the pixels row by row basing the colour of the pixel on the loop variables X and Y.
The x-axis movement comes from also adding the x-offset to the blue pixel's colour value (XOffset is passed in as the argument to the BlueOffset parameter).
If we think about the 8 bits that represent the blue pixel we find the source of your confusion about the thumbstick being inverted.
Lets say the XOffset is set to 0 and we look at the start of the loop in the gradient function where X and Y start out at 0.
If the X variable is 0, then the blue pixel equals 00000000, that means no blue colour (black) and as the loop increments to move across the row it reaches 255, which is 11111111, which means full blue.
As soon as you add 1 to the full blue colour it would normally become 100000000, but we only have 8 bits so the right-most bits gets discarded and we are left with 00000000 and the cycle happens again.
This is why you see the tiling that happens across the window instead of one big gradient.
This is also why the more black corner is in the top left, because the 0 values that mean no colour (black) start from the top left of each tile.
Now, lets say the XOffset equals +100, in other words you push the thumbstick ever so slightly to the right.
Now in the loop where X = 0 to start with, has an additional +100 added to it's value via the BlueOffset parameter.
So before, the top left corner had a value of 0, meaning black, but now it has 00000000 + 01100100, which is of course just 01100100, or in decimal, 100.
A value of 01100100 instead of 00000000 now means the top left corner is not black, but has more blue in it.
This applies to the entire row of pixels making it look like they are moving to the left because the more colourful pixels are now being drawn closer to the left side of the screen before they start wrapping back around to 0 again.
This all means that adding a positive BlueOffset (which is controlled by XOffset) value to the X variable in the loop gives the illusion of the tiles moving to the left, and since pushing the thumbstick to the right gives a positive value that's exactly what happens.
You can change the code: `X + BlueOffset`, to: `X - BlueOffset` and the pixels would move to the right instead.
From the MSDN documentation:
MSDN
sThumbLX
Left thumbstick x-axis value. Each of the thumbstick axis members is a signed value between -32768 and 32767 describing the position of the thumbstick. A value of 0 is centered. Negative values signify down or to the left. Positive values signify up or to the right. The constants XINPUT_GAMEPAD_LEFT_THUMB_DEADZONE or XINPUT_GAMEPAD_RIGHT_THUMB_DEADZONE can be used as a positive and negative value to filter a thumbstick input.
So pressing the thumbstick to the right results in a positive value.
If you look at the render gradient function, you will see that it's filling up the pixels row by row basing the colour of the pixel on the loop variables X and Y.
The x-axis movement comes from also adding the x-offset to the blue pixel's colour value (XOffset is passed in as the argument to the BlueOffset parameter).
If we think about the 8 bits that represent the blue pixel we find the source of your confusion about the thumbstick being inverted.
Lets say the XOffset is set to 0 and we look at the start of the loop in the gradient function where X and Y start out at 0.
If the X variable is 0, then the blue pixel equals 00000000, that means no blue colour (black) and as the loop increments to move across the row it reaches 255, which is 11111111, which means full blue.
As soon as you add 1 to the full blue colour it would normally become 100000000, but we only have 8 bits so the right-most bits gets discarded and we are left with 00000000 and the cycle happens again.
This is why you see the tiling that happens across the window instead of one big gradient.
This is also why the more black corner is in the top left, because the 0 values that mean no colour (black) start from the top left of each tile.
Now, lets say the XOffset equals +100, in other words you push the thumbstick ever so slightly to the right.
Now in the loop where X = 0 to start with, has an additional +100 added to it's value via the BlueOffset parameter.
So before, the top left corner had a value of 0, meaning black, but now it has 00000000 + 01100100, which is of course just 01100100, or in decimal, 100.
A value of 01100100 instead of 00000000 now means the top left corner is not black, but has more blue in it.
This applies to the entire row of pixels making it look like they are moving to the left because the more colourful pixels are now being drawn closer to the left side of the screen before they start wrapping back around to 0 again.
This all means that adding a positive BlueOffset (which is controlled by XOffset) value to the X variable in the loop gives the illusion of the tiles moving to the left, and since pushing the thumbstick to the right gives a positive value that's exactly what happens.
You can change the code: `X + BlueOffset`, to: `X - BlueOffset` and the pixels would move to the right instead.
Edited by Lucas89
on
There should be no differences between using VS2013 and VS2015. I tried with both of them and it produces exactly same result for me for day 6 code.
The data from controller is correct. If you move X axis of stick to right, that means it will return positive value. And assigning positive value to XOffset means that bitmap "0" column will be "XOffset" column - it will look like bitmap is moving left.
What is inverted is actually Y axis of rendering. Bitmaps are displayed top to bottom. Meaning Y at top of screen is 0 and is increasing down. If you assign positive value to YOffset (moving Y axis of stick up), that means that "0" row will be now "YOffset" row and it will look like bitmap has scrolled up.
The data from controller is correct. If you move X axis of stick to right, that means it will return positive value. And assigning positive value to XOffset means that bitmap "0" column will be "XOffset" column - it will look like bitmap is moving left.
What is inverted is actually Y axis of rendering. Bitmaps are displayed top to bottom. Meaning Y at top of screen is 0 and is increasing down. If you assign positive value to YOffset (moving Y axis of stick up), that means that "0" row will be now "YOffset" row and it will look like bitmap has scrolled up.
Edited by Mārtiņš Možeiko
on
Thanks for your detailed response and clearing this up for me! I had another look at the video and at the 1:20 mark, you can even see Casey hitting the left stick, and the screen indeed scrolling to the right
I also find that "XOffset -= StickX >> 12;" has the same effect as your suggestion "X + BlueOffset".
I also find that "XOffset -= StickX >> 12;" has the same effect as your suggestion "X + BlueOffset".