An entire ray traced video game made from a single mathematical formula.

I have been watching a Youtuber named Inigo Quilez recently. He made something called Shadertoy. Where he creates these animated gifs using math. It is literally a giant math formula that takes a pixel on the screen and a moment in time, then calculates the color of the pixel. f(x,y,t) = [r,g,b] So... Could you possibly use this technique along with Tupper's formula from computer graphics (which returns a Boolean 1 or 0 from a grid) to also calculate collision? And then add a player x and y to our formula. f(x,y,t,playerX,playerY) = (r,g,b) To create an entirely ray traced video game that all contained into a single math formula? So a god with infinite time could calculate and play this game with pen and pencil. For example: Let the user hold down a button to increase or decrease their x or y. Modulo their x and y and pass them to Tupper's formula. If the formula returns a 1, a collision occurred. Negate the 1 by (1 - Tuppers(x,y)) which gives us a 0 Multiply this quantity by the vector we are adding to the players velocity. 1 keeps the velocity, 0 cancels it out and stops the player thus we have collision while preserving branchless programming? Flaw in my logic?

Look up "Three-body problem"

>Tupper's formula is just a very inefficient way to encode the process of displaying pixels on a screen in a closed formula >ray tracing with a single mathematical function Yes, this is how computers display things on the screen, they do lots of math. >So a god with infinite time could calculate and play this game with pen and pencil. You probably don't need infinite time, and also, this can be done with literally any computer program. >branchless programming Why? You're just emulating the branch with slower logic. You're overcomplicating things by imagining that 'program' and 'mathematical formula' are distinct. They are different ways of describing the same things, except that programs are usually better suited for running on physical computers efficiently.

>>25653 >displaying pixels on a screen I know that was why it was discovered. But I was more thinking, of using it to store a result in a math formula. Like the result of a collision in a maze. We could use an online site to draw a maze in Tupper's formula, use the 1's as walls and then multithread the whole thing containing no branching logic. Doesn't branching logic ruin multithreading? Could I multithread several object navigating the maze I drew with Tuppers? I am ignorant of some large areas of Computer Science. Just trying to do some weird stuff over here, experimenting and what not.

>>25654 >Doesn't branching logic ruin multithreading? No, why would it? Parallel memory accesses are what ruin multithreading. >Could I multithread several object navigating the maze I drew with Tuppers? If there was no interaction between the objects, yes. If there is interaction between the objects, you would need to add some synchonization which would slow it down, but you can be very clever and still get most of the benefits of multithreading.

>>25655 I thought multithreaded meant that they perform actions in lock-step. The same actions at the same time. Branches cause both branches to be explored and useless branches results just ended up being nullified by the correct one. Where as, a single math formula which uses thing like max and min which are implemented on hard ware without using conditionals, would avoid that problem? Am I filled with miss-info? >yes. ... but you can be very clever and still get most of the benefits of multithreading. Thank you.

>>25656 >I thought multithreaded meant that they perform actions in lock-step. The same actions at the same time. No, not at all. Multithreading means you have either: two CPU cores doing stuff entirely independently until they access memory, or a scheduler that has one program run while another one is waiting for disk accesses or something. >Branches cause both branches to be explored and useless branches results just ended up being nullified by the correct one. This is called speculative execution, it actually speeds up programs.

>>25657 >speculative execution Yes this, I heard about branch prediction and that if it fails to correctly predict the branch, it has to take time loading things from memory. I was wondering if I could avoid all of this. The memory loading and the branch prediction, all of that time, by using Tupper's formula in place of all that. To reduce memory access and branches. It would all be contained in the math. Not sure why I am doing it. But I want to. Maybe I could then make lots of game/math/equations and train an AI to make games?

>>25658 Multiplying numbers is almost always going to take more time than you would lose by branching. Multiplication is a very slow thing for computers to do, relative to comparison and jumping.

>>25659 Do you have a source for that? A quick google search doesn't seem to agree. Remember, we're not comparing with comparison and jumping per se, but with incorrect branch prediction.

>>25666 >Do you have a source for that? I speak mostly from my experience designing an ALU in a class. Multipliers and dividers are some of the slowest circuits in an ALU. >Remember, we're not comparing with comparison and jumping per se, >but with incorrect branch prediction. Incorrect branch prediction is rare though, and if you're only dealing with registers it doesn't have a significant performance penalty. The reason why incorrect branch prediction is bad is because it can mess up the cache. In other words, just don't do conditional memory reads and you'll be fine.

>>25667 one nice trick you can do to avoid most of the benefits of bad branch prediction is to write your functions like this: instead of say, if a < b { c = longcomputation(a) } else { c = longcomputation(b) } write it like this: c = longcomputation(if a < b {a} else {b}) This keeps the branch smaller. In this case each branch will compile to a compare, a jump, and a register move, which will *always* be faster than a multiply and will certainly not cause any cache penalties.

>>25668 s/benefits/problems/

>>25651 check this out https://codeparade.itch.io/marblemarcher

>>25668 I was about to say that the compiler would optimize those two examples to the same source code, but surprisingly, GCC actually does treat the two differently, using a cmov instruction (which doesn't branch) for the latter code instead of a conditional jump. I guess the reason it doesn't optimize the first code identically is that the first one would actually be faster if the CPU can predict the branch correctly most of the time. Clang generates the same machine code for both.

>>27071 s/source code/machine code/

>>27071 Yeah I was going to post the same note. C compilers tend to go to SSA, which does a good job at marking and allowing this kind of flow analysis easy to make. What one should be weary of, is if there are function calls obscuring this fact from the compiler, as SSA isn't known for being when it comes to dealing with inter-function optimizations. Compilers do a lot these days to make code fast!

>>25651 > Inigo Quilez I checked his channel, that's so fuarrrking cool. I hate being a fool and I didn't understand anything though.

Interesting idea. I'll try to build on it a little, just a thought. As >>25652 has mentioned, this is essentially an n-body problem. Your best bet for including a player would be to treat that entity as a separate system. Of course, this is then no longer contained within a single equation, but this would open up all the possibilities of dynamical system studies / differential equations. You essentially track your particle system with some function f(x, y, z, ...) and your player in a function g(x, y, z, ...). You could then describe interactions using differential equations, or even systems of differential equations (https://en.m.wikipedia.org/wiki/System_of_differential_equations). A better idea, however, would be to just make your player freely moveable, since, you know, you'd like a user to actually control it, rather than it's movements to be determined by a function -- and certainly not by the same function that controls your environment. I don't quite see how you'd include a player in a single function, since the point in the range of e.g. f(x, y, z, ...) are essentially all governed by the same ruleset (namely the term of f). In short, you'd basically just be describing the behavior of one or more n-body systems, and any potential interactions.

I have little to no freehand artistic ability so i use SDFs to make UI art for games. The bonus is that they are way easier to animate than anything someone working in raster can possibly pull off. You get free calculated drop shadows for working against light backgrounds and it's just cool in general.