Wikipedia:Reference desk/Archives/Computing/2020 June 9

Computing desk
< June 8	<< May | June | Jul >>	June 10 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is a transcluded archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

June 9

Testing accuracy of ball-brick game

So I can tell if the positions are 32-bit floating point or 64- or what from how the rounding errors look? What are the algorithm details? Are they like calculating the angle between the last pixel the screen felt in aim phase and the center of the screen bottom and drawing the balls x times a second but the pixels the ball centers are on are just for visuals and don't contribute to rounding errors per se? What are the system requirements? Are there any phones new enough to download the ball string games from the app store but too slow to run them properly (at the intended pixels per second ball-speed and so on) and would they just run slow or would they fail less gracefully? Why do balls or strings of balls sometimes bounce back and forth on the same exact pixel row or column (at least on 1080p) up to hundreds of times then suddenly switch to a totally wrong direction then bounce correctly again (to the naked eye)? Or is that just the programmers intentionally preventing you hitting the jackpot and getting guaranteed removal of any brick protruding onto the pixel row due to the finite possible bounce angles in 32 or 64 bits and brick boundaries seeming to sometimes make nearly perpendicular hits perfectly perpendicular? At other times balls or strings of balls that do this will instead eventually veeery slooowly accumulate visible rounding errors which is especially striking in a string of tens or hundreds of balls as the angles and maybe millimeters per minute disperse at an ever increasing snail pace. That behavior's much more like what I'd guess a limitations of computer discreteness error would look like. I often see strobophobic effects, is actually drawing the balls computationally cheaper than smearing them into semitransparent averages of what the flight path pixels theoretically looked like during a full one to four 120ths of a second or is it done for other reasons? (aesthetic?) Sagittarian Milky Way (talk) 03:15, 9 June 2020 (UTC)

Are you talking about one specific game, or a class of games in general? The IEEE 754 32-bit floating point uses 23 (or 24, depending on how you count) bits for the mantissa. So on a width of between 1024 and 2047 pixels, a one-off on the least significant bit is an error that is less than 2048/2²³ = 1/2¹² = 1/4096th of a pixel. It is unlikely one would notice that in any way, as this is much smaller than the resolution of the human eye. What you call "strobophobic effects" (stroboscopic?) may be spatial aliasing, a visual artifact that is not related to rounding errors.  --Lambiam 11:48, 9 June 2020 (UTC)

I only play one game but the number of bounces it takes a ball string bouncing perpendicular to the naked eye to disperse into an x-pixel wide swath of almost perpendicular bouncing ball should be the same for any game that does its physics the same way. It is most definitely drawing the visuals only 1 time each frame causing stroboscopic effects (no idea why I wrote strobophobic, I don't really understand spatial aliasing from the article (is moire SA?)) but can't be detecting collisions with such temporal inaccuracy as the balls move c. 2700 pixels per 1.2 seconds (balls do not collide with each other btw) So a high hertz cycle of bounces in a cramped area can appear as several balls with little to no motion. You are correct, the eye shouldn't be able to detect any error in 2,047 pixels but balls can bounce hundreds of times and hundreds of thousands of pixels accumulating errors, shouldn't you be able to glean info on the physics by discovering how many bounces off the left and right sides of the screen it takes for visible errors to appear? (I can see pixels with my eyesight) A train of non-interacting balls, bouncing perpendicularly off the screen edges yet dispersing into balls slightly ascending and balls slightly descending must be an error of some type and I'm wondering what it is. If the ball line didn't disperse and just went up or down x pixels an hour it could just have been not horizontal from the beginning, that is not the case so this is a genuine effect of the limitations of smartphones. There are other times where it will suddenly switch to a random vector after staying on the same pixel line for hundreds of bounces and many bricks destroyed and I'm wondering what causes that too. It is not a brick effect for bricks are completely flat and undeformed till the destroying bounce or touch (even e.g. 1820 "brick health" to 1819 and so on till 1 dents nothing, 1 hitpoint to 0=instant disappearance, ball unaffected) Sagittarian Milky Way (talk) 20:11, 11 June 2020 (UTC)