New answers tagged

0

The problem is your multiplication code. When you do: m00 = m00 * matrix.m00 + m10 * matrix.m01 + m20 * matrix.m02 + m30 * matrix.m03; You change m00, so you are not allowed to reuse it later in that function. Same for m01 and all the other ones. Use temporary values instead: float temp_m00 = m00 * matrix.m00 + m10 * matrix.m01 + m20 * matrix.m02 + m30 * ...


0

Your z rotation is messed up, it should be negative at (0; 1), and positive at (1; 0)


0

Translating a camera is the equivalent to translating the world in the opposite direction. In other words, at the very bottom of your matrix stack, your camera's matrix exists. You need to translate this wherever your camera must be in the opposite direction. If you wish to move up 5 paces. You translate the world down five paces. This is typically the ...


3

Yes and no. Yes, generally: the convolution operation is usually very computationally heavy and if you are sampling 7x7 area, that is 49 times more samples than you would usually do. No, in your case: One important thing about FPS is that it is inverse of a function. Because with 5000 FPS the time to render a frame is 0.20 ms and with 1500 FPS it is 0.66 ...


0

Treat all the chunks around player, as offsets (shown in one axis but applies for both): -3 -2 -1 0 +1 +2 +3 <- 7 offsets for 1 axis; for x * y that would be 49 offsets. 0, 0 is the offset where the player is - the origin of "player space". 3, -2 might be roughly to the northeast or whatever, depending on your coordinate system setup, and so forth. Now ...



Top 50 recent answers are included