I've made some analysis of how many float-to-int conversion appear in my code and it's creepy that every tile a ray passed takes a float-to-int conversion. That's a real fucking lot and made me think about how to reduce this effectively. Most of the time, I only add a step vector and need to float's integer part. Therefore, I could also store the integer part seperately and add another "detail" value representing the post-comma part. But two variables with always occuring overflow around the lower values will result in a lot of conditions to check and equally much calculation to be done. Maybe even slower, it is not the optimal solution - even you get the integer part for free. So I thought about using fixpoint numbers where I can get the int by a single bitshift and use number iteration as I'd normally. Sure, it takes more than one operation to do the initial division each ray requires when shot, but the iteration itself and the completely eliminated float-to-int conversion pays off. I'm not afraid of using floats for EVERYTHING, but they are not made to be converted into integers so quickly and often as I want. So I'm tackling again a different path that's hopefully the way to go for positioning. If it doesn't work as expected, it'll be abandoned as soon as you can say "Cowabunga!".