Bitwise bug?

[Erik]

Hello all.

I have made several platform games using "gamemaker studio 2" in the past and
i have never had this problem before. Bitwise seems broken.

I have always used bitwise to align my object with the tileset grid. It would look something
like this.
y=y&~7
(Lining up with a 8 pixel grid by rounding off to the closest 8 pixels)

It seems like this is no longer an option. Earlier i got exact numbers divisible by 8. It was
pixel perfect and worked every single time. Very reliable.

I have been away from GMS2 for about 2 years and now when i return bitwise functions no longer
seem to function. When i perform the above operation will get values that are of by 0-1 pixel...?
Sometimes i get 120 as a result. But sometime the same bitwise will return 119 or even 119.5 (!?)
How is this even possible. It is supposed to drop all the 1s from the end.
This renders bitwise functions completely useless?
Is this something that has crept into newer versions of GMS2 because i never had this happen
before.
My old reliable platform-engine has been rendered useless now that the numbers come out
within a 1 pixel margin, instead of dead accurate. Seeing as GMS2 is most commonly used to create
2d pixel-based games this is a big problem. Pixel accuracy is vital. The results of the same mathematical
operation can not be allowed to differ with -1/+1 from time to time.

Has anyone else encountered this problem? Is this a known bug? A new bug?
As far as i know this was not the case in earlier versions.

 

[chamaeleon]

Hello all.

I have made several platform games using "gamemaker studio 2" in the past and
i have never had this problem before. Bitwise seems broken.

I have always used bitwise to align my object with the tileset grid. It would look something
like this.
y=y&~7
(Lining up with a 8 pixel grid by rounding off to the closest 8 pixels)

It seems like this is no longer an option. Earlier i got exact numbers divisible by 8. It was
pixel perfect and worked every single time. Very reliable.

I have been away from GMS2 for about 2 years and now when i return bitwise functions no longer
seem to function. When i perform the above operation will get values that are of by 0-1 pixel...?
Sometimes i get 120 as a result. But sometime the same bitwise will return 119 or even 119.5 (!?)
How is this even possible. It is supposed to drop all the 1s from the end.
This renders bitwise functions completely useless?
Is this something that has crept into newer versions of GMS2 because i never had this happen
before.
My old reliable platform-engine has been rendered useless now that the numbers come out
within a 1 pixel margin, instead of dead accurate. Seeing as GMS2 is most commonly used to create
2d pixel-based games this is a big problem. Pixel accuracy is vital. The results of the same mathematical
operation can not be allowed to differ with -1/+1 from time to time.

Has anyone else encountered this problem? Is this a known bug? A new bug?
As far as i know this was not the case in earlier versions.

I think it would be beneficial to have a small code snippet that exhibit the issue. Meanwhile, this appears to work fine for me..

for (var a = 110; a < 130; a += 0.5) {
    show_debug_message(string(a) + " => " + string(a & ~7));
}

110 => 104
110.50 => 104
111 => 104
111.50 => 104
112 => 112
112.50 => 112
113 => 112
113.50 => 112
114 => 112
114.50 => 112
115 => 112
115.50 => 112
116 => 112
116.50 => 112
117 => 112
117.50 => 112
118 => 112
118.50 => 112
119 => 112
119.50 => 112
120 => 120
120.50 => 120
121 => 120
121.50 => 120
122 => 120
122.50 => 120
123 => 120
123.50 => 120
124 => 120
124.50 => 120
125 => 120
125.50 => 120
126 => 120
126.50 => 120
127 => 120
127.50 => 120
128 => 128
128.50 => 128
129 => 128
129.50 => 128

My gut reaction is that you have some other code that modifies y somewhere after you perform the bitwise operation. show_debug_message() immediately after setting y, rather than relying on what the value is as displayed on the screen would show whether this is the case.

 

[Erik]

--Horizontal--
if (vspd>0){
y=y&~7;
vspd=0;
}
if (vspd<0){
y=(y&~7)+8;
vspd=0;
}

--Vertical--
if (hspd>0){
x=x&~7;
hspd=0;
}
if (hspd<0){
x=(x&~7)+8;
hspd=0;
}


Both of these return results with decimals and variations of +1 -> -1 which is a disaster.
Sometimes bitwise returns a value of say 223 or 119 (!?) those numbers are not even divisible by 8?
How can 223 or 119 even be the result of &~7 ? That should be impossible.

This seems to be related to another weird problem.
My room is 256*192 and my view is the same size.
But it is displayed as 1280x960 (viewport) to make it easier to see on a 24" monitor.
When my obj after a bitwise operation is placed at 119.5 it is visibly placed in between
two pixels.
Even though my sprite is 16x24 and placed at what shouuuld be pixel 120 of 192 it is
in fact placed in pixel 119.5 which seems to be a sub-pixel based on the resolution of 960 which
looks suuuuper weird. This is also a new phenomonon.
The sprite is only 24 pixels tall and the sprite next to it is 24 pixels tall. It should be impossible
to be offset from the other sprite by 0.5 pixels in a resolution of 192... But still, there it is.

I am realy tearing my hair out by now. I sometimes land 0.5 pixels above ground and sometimes 1 whole pixel above ground and sometimes on the ground and all landings use the same bitwise operation above. This did not happen two years ago. What changed? Did GMS2 use integers but stopped? Is it a rounding issue of floating point variables? Can i set GMS2 to only use integers in some way?

Why does half pixel coordinates exist in a 192 pixel resolution?
Why does the result of a bitwise operation differ by 1 pixel at random?
Does anyone else have the same two problems?

 

[Erik]

I think it would be beneficial to have a small code snippet that exhibit the issue. Meanwhile, this appears to work fine for me..

for (var a = 110; a < 130; a += 0.5) {
    show_debug_message(string(a) + " => " + string(a & ~7));
}

110 => 104
110.50 => 104
111 => 104
111.50 => 104
112 => 112
112.50 => 112
113 => 112
113.50 => 112
114 => 112
114.50 => 112
115 => 112
115.50 => 112
116 => 112
116.50 => 112
117 => 112
117.50 => 112
118 => 112
118.50 => 112
119 => 112
119.50 => 112
120 => 120
120.50 => 120
121 => 120
121.50 => 120
122 => 120
122.50 => 120
123 => 120
123.50 => 120
124 => 120
124.50 => 120
125 => 120
125.50 => 120
126 => 120
126.50 => 120
127 => 120
127.50 => 120
128 => 128
128.50 => 128
129 => 128
129.50 => 128

My gut reaction is that you have some other code that modifies y somewhere after you perform the bitwise operation. show_debug_message() immediately after setting y, rather than relying on what the value is as displayed on the screen would show whether this is the case.

Thank you Chameleon! You solved my problem!
I used your string command to write every landing as a debug message which gave me some new insight. This is why i come to the forums. To
gain some new perspective and i thank you for that.
I could see that i only got a message when the landing resultet in a nice number divisible by 8 which in turn told me that the bitwise operation did not run in every landing
but that there was some other piece of code that stopped the fall resulting in another less nice number like 119, for example. I have a finite state-machine running with every state and
it turned out that the falling state got interuppted and swapped to the idle state uppon landing without using the bitwise operation and this happened in even distributions.
So the result would come back in this pattern 120, 119.5, 119, 120, 119.5, 119, 120 .....
This resolves the issue.

It also seems like 256x192 blow up to 1280x960 (x5) is in actuallity handled like 1280x960 and GMS2 just multiplying all coordinate operations by 5 to compensate which would
explain the half pixel nonsense. Instead of pixel 119 out of 192 (595 of 960) it would be placed on 119,5 (597 of 960) which would not exist in a true resolution of 256x192. This got resolved with the
bitwise problem as all coordinates are now "decimal free" which will keep them within interwalls of 5 pixels (full virtual pixels of 256x192).