Mandala: A little plaground for testing pixel logic patterns(github.com)
github.com
Mandala: A little plaground for testing pixel logic patterns
https://github.com/gingerbeardman/mandala
20 comments
If anyone else want's to play around with it (I did) I made a shadertoy version https://www.shadertoy.com/view/XXfXWl
See also the 1D version of this, rendered as audio: "bytebeat" music. Surprisingly complex music from very simple modular arithmetic and bit shifting.
https://youtu.be/tCRPUv8V22o
https://youtu.be/tCRPUv8V22o
also the masterpiece perhaps of such artwork:
https://linusakesson.net/scene/a-mind-is-born/
I was so confused, expecting this to be some trickery related to the computational-graph-memoization-and-exploration tool "mandala" https://github.com/amakelov/mandala
At some point I built something very similar using shaders: https://antoinemopa.github.io/xor-explorer/
Meta: a bit late, but there is a 'y' missing from the word "playground" in the title.
Also it would be useful to clarify that this is about the Playdate handheld which explains the performance perspective.
Also it would be useful to clarify that this is about the Playdate handheld which explains the performance perspective.
I feel like this could be done on shadertoy fairly easily, no?
Here's a p5js sketch using WEBGL to do something similar. Not as flexible as the shadertoy, but arguably simpler to interact with: https://openprocessing.org/sketch/2203876
If somebody can explain why bitwise ands generate serpinski triangles I would sure like to know.
(y * 4 & x *4) % (frameCount / 10 % 300)
(y * 4 & x *4) % (frameCount / 10 % 300)
Oh duh, this is inherent in binary counting. When y is equal to one any even x will be a zero. The when y is equal to 2 you get groups of zeros two at a time 0, 1; 4, 5; 8, 9; etc. The pattern repeats in lengthening, self similar way as the values of y increase leaving ever lager gaps and sequences of zeros (with the top edges of the triangles corresponding to powers of two, which give long sequences of zeros or non zeros respectively.
I always think of this pattern geometrically so it’s weird to see it pop out in simple math.
I always think of this pattern geometrically so it’s weird to see it pop out in simple math.
> Generating a screen takes a couple of seconds on hardware as it requires per-pixel processing of the entire 400x240 screen = 96,000 pixels
This doesn't sound right - it should take a few milliseconds to fill a full-HD screen on any semi modern device
This doesn't sound right - it should take a few milliseconds to fill a full-HD screen on any semi modern device
Glancing at the code, it uses some library called “playdate”, so I presume it’s for this device: https://play.date/
Assuming some values of "modern device" :)
That readme should include a mention of its intended platform .... "on a playdate"
Luckily you can run it in the simulator without one!
That readme should include a mention of its intended platform .... "on a playdate"
Luckily you can run it in the simulator without one!
Per-pixel is pretty slow, most fast algorithms don’t do this. Also, this is on the Playdate, which uses a somewhat lean ARM chip (stm32f7).
Quake renders itself per-pixel. With a mid-90s CPU (no GPU). And it does vastly more computing than just one bit op per pixel. Any remotely modern computer could fill hundreds (if not >1000) of 96k frames per second. The STM32f7 could likely do it at real-time frame rates with some optimizations.
This goes to show just how much slower software has gotten, and how much poor, abysmal even, performance is now ingrained in programming culture.
Naw, Quake was heavily optimized by some of the best x86+pixel gurus ever, like Michael Abrash. It look a lot of work to get there. But there have been cycle-optimized pixel graphics since the very first video game. Quake was also lower res and far simpler lighting and lower quality than modern games. Rendering pixels on the CPU without a metric ton of optimization effort was always slow, and exponentially slower the further back you go. GPUs are the primary thing making pixel rendering fast now, and it’s because of hardware and a parallel programming model, not because of software.
I might be biased because I do perf work and everyone I know does perf work, but I feel like there’s more people doing optimization now than there were total programmers 20 or 30 years ago. You’re not wrong, and there are plenty of people who write software and don’t feel the need to worry about perf because there aren’t any people that it slows down. Michael Abrash might agree with that being reasonable, since he defined optimization to mean perceptible wait time:
“Before we can create high-performance code, we must understand what high performance is. The objective (not always attained) in creating high-performance software is to make the software able to carry out its appointed tasks so rapidly that it responds instantaneously, as far as the user is concerned. In other words, high-performance code should ideally run so fast that any further improvement in the code would be pointless.
“Notice that the above definition most emphatically does not say anything about making the software as fast as possible. It also does not say anything about using assembly language, or an optimizing compiler or, for that matter, a compiler at all. It also doesn’t say anything about how the code was designed and written. What it does say is that high-performance code shouldn’t get in the user’s way — and that’s all.”
http://twimgs.com/ddj/abrashblackbook/gpbb1.pdf
I might be biased because I do perf work and everyone I know does perf work, but I feel like there’s more people doing optimization now than there were total programmers 20 or 30 years ago. You’re not wrong, and there are plenty of people who write software and don’t feel the need to worry about perf because there aren’t any people that it slows down. Michael Abrash might agree with that being reasonable, since he defined optimization to mean perceptible wait time:
“Before we can create high-performance code, we must understand what high performance is. The objective (not always attained) in creating high-performance software is to make the software able to carry out its appointed tasks so rapidly that it responds instantaneously, as far as the user is concerned. In other words, high-performance code should ideally run so fast that any further improvement in the code would be pointless.
“Notice that the above definition most emphatically does not say anything about making the software as fast as possible. It also does not say anything about using assembly language, or an optimizing compiler or, for that matter, a compiler at all. It also doesn’t say anything about how the code was designed and written. What it does say is that high-performance code shouldn’t get in the user’s way — and that’s all.”
http://twimgs.com/ddj/abrashblackbook/gpbb1.pdf
Is it possible to JIT Lua mathematical expressions into native assembly for more efficient execution?
Yeah uh I came here to say the same... maybe if you run it as a nested loop in micropython on an underspecced device?
[deleted]