When I was in middle school, I had dabbled in coding but only knew how to make simple CLI applications that ran on the terminal. Then one day I stumbled on Lode's Computer Graphics Tutorial and I finally had easy to understand examples of how to open a window and draw some graphics on the screen. That led me to recreating a bunch of retro games (Pacman, Snake, Space Invaders, etc) that would not have been possible on the terminal.
I credit this site for really kickstarting my career in software development from a somewhat early age. Big shout out and thank you to Lode. Back then, I practically memorized all the pages and examples in https://lodev.org/cgtutor/, even if some of the math went right over my head at the time
I once made a small x86 asm program that generated an image with a similar technique, except with 1-bit colour. Instead of x ^ y, it was parity(x ^ y), i.e. if there are an even number of 1 bits, colour it one way, else colour it another. It had an interesting visual effect; it looks like a tiling that almost repeats but not perfectly.
Edit: Just looked through some old files and found the program. It was written in fasm in 2019 and generates an XPM2 file (which I had to manually convert to XPM3 to view). Here's the resulting image: https://i.postimg.cc/FsFhXSHG/xortiles.png
(I can post the code if anyone wants, though I don't know why you'd care.)
A similar effect, when animated with a function like `color = (y == (x ^ t))` for varying values of t, is called “munching squares.”
It was originally written for the PDP-1 in the early sixties. I’ve seen it demonstrated on the Computer History Museum’s PDP-1. I always wondered how the characteristic “XOR texture” could be produced if the PDP-1’s display can only plot points and does not use a bitmapped framebuffer.
Turns out it takes advantage of the long persistence of the screen’s phosphor, and the brightness of each point decreases over time.
I made a quilt that uses this texture. I used the same rainbow scale that one of the last pictures on the site illustrates, So it looks a lot like this. 6 ft by 6 ft decoration I've got hanging on the wall.
What is the state of JavaScript sandboxing these days?
I would like to build a site geared towards this kind of algorithmic art. Where one can paste the JS code snippets and see the resulting image. Similar to my html editor with instant preview:
Is it feasible these days to build something like this, but without the ability of the code to jump out of the result frame? Like no external http requests, no fiddling with the window etc?
If you were not worried about preventing external requests and were okay with it being able to make requests as an arbitrary webpage unrelated to your site could if opened, then loading the code in an iframe with the sandbox="allow-scripts" attribute is enough.
Wow, sandbox="allow-scripts" looks pretty good. Doing some additional research, it seems one can disallow all network requests via Content-Security-Policy directives:
Oh I hadn't thought of using CSP for that. CSP alone used to not be enough but combined with the iframe's sandbox attribute (or the relatively newer sandbox CSP directives, which both block navigation and form submissions by default) then I think it's enough to block external network requests. This combo seems like a good solution for many use-cases.
However there are certain things that it still doesn't protect against: CPU and memory exhaustion. Someone's script can hog those resources and possibly cause the browser to crash the tab. If you only execute one user's code at a time when a user of the site specifically browses to it / activates it, then it might be acceptable because a user can learn to not re-activate code that just crashed their tab and won't be missing out on anything else, but if you had a setup where it didn't take user action to run other users' code (like you have a homepage that automatically shows a running preview of other people's code, or you have a multiplayer programming game where each player submits code and everyone in the game sees it run together and interact with other players' code) then it could be purposefully griefed by players submitting code that exhausts resources. If you need to protect against local denial of service attacks like this, or if you needed strict determinism for some reason, then I think a WASM-based solution is still the way to go.
i frequently generate something resembling this and/or the hamming distance texture in a fairly dumb manual way, by just doing blend mode overlay on progressively smaller checkerboards.
it's my go-to for lining up pixel-perfect uv maps for more geometric/mechanical 3d assets -- the recursive nature means you can have an easy time hitting, say, the exact corners or centers of luxels if you feel the need.
This looks a bit like a fractal, specifically it reminds me of the Sierpinski triangle, though the XOR texture doesn't seem to be a proper fractal with an associated dimension.
However, according to these replies here the XOR texture and the Sierpinski triangle/tetrahedron are indeed mathematically related: https://math.stackexchange.com/questions/1080223/what-do-bit... (Admittedly I don't understand the mathematics behind this connection)
Similar to this, if you fill the texture with (x & y ? white : black), where x and y are the 0-indexed coordinates of the pixel in question, you get a Sierpinsky triangle.
That's a really neat demonstration! Would you mind if I use this code to jump off with my own tangent? (I want to hook the microphone audio into it, to control the patterns based off voice/music)
The way the patterns looked, felt natural enough that my brain was trying to make sense of the chaos.
It is a sizecoding/demoscene classic, which is a form of art.
Using it as-is tends to be discouraged though, because it is considered unoriginal and lazy for all but the tiniest of intros. Variations on it are fine.
A lot of this article seems to be conflating two things:
1. The ability for the code to process the error and recover from it
2. The ability to sensibly log, trace, and later for a human to understand the error after the fact
The later of these is best handled by using a tracing library systematically throughout your code to spit out open telemetr and “logging” the error within your local span. You can then debug the problem with a tool like honeycomb which’ll give you a much clearer idea of what’s going on. Having tracing in place will also help you debug in cases where you don’t have errors but your system is running slowly, doing something unexpected, etc.
This greatly reduces the problem domain you have to solve in actual error handling to just having the computer recover when something is recoverable. And in these situations it turns out that most recoverable errors are best expressed as “non-errors” once they migrate any distance from the origin of the error (e.g. the record not found turns into a standard “user not known” status return value - it’s no longer an error, but an expected behavior of the system!) So for these “short lived” errors that are either handled locally or bubbled up all the way to the top and never handled, I’ve found that Go’s native basic error framework is fine.
When I was in middle school, I had dabbled in coding but only knew how to make simple CLI applications that ran on the terminal. Then one day I stumbled on Lode's Computer Graphics Tutorial and I finally had easy to understand examples of how to open a window and draw some graphics on the screen. That led me to recreating a bunch of retro games (Pacman, Snake, Space Invaders, etc) that would not have been possible on the terminal.
I credit this site for really kickstarting my career in software development from a somewhat early age. Big shout out and thank you to Lode. Back then, I practically memorized all the pages and examples in https://lodev.org/cgtutor/, even if some of the math went right over my head at the time
I once made a small x86 asm program that generated an image with a similar technique, except with 1-bit colour. Instead of x ^ y, it was parity(x ^ y), i.e. if there are an even number of 1 bits, colour it one way, else colour it another. It had an interesting visual effect; it looks like a tiling that almost repeats but not perfectly.
Edit: Just looked through some old files and found the program. It was written in fasm in 2019 and generates an XPM2 file (which I had to manually convert to XPM3 to view). Here's the resulting image: https://i.postimg.cc/FsFhXSHG/xortiles.png
(I can post the code if anyone wants, though I don't know why you'd care.)
Reminds me of the Hamming distance texture: https://chalkdustmagazine.com/features/the-hidden-harmonies-...
Reminds me of glitching the integer circle algorithm: https://nbickford.wordpress.com/2011/04/03/the-minsky-circle...
If the Xor texture is Xor(x,y) then the hamming distance would be PopCount(Xor(x,y))
(I think, maybe?)
Yep!
I hadn't heard of this one; great article and website, cheers :)
A fun fact: Each point in the XOR texture is the smallest integer not appearing above it, or to its left
(Ducking while posting my own blog: https://nicknash.me/2012/10/26/happy-halloween/)
The row starting with 5 in your example matrix is wrong, it should look like
A similar effect, when animated with a function like `color = (y == (x ^ t))` for varying values of t, is called “munching squares.”
It was originally written for the PDP-1 in the early sixties. I’ve seen it demonstrated on the Computer History Museum’s PDP-1. I always wondered how the characteristic “XOR texture” could be produced if the PDP-1’s display can only plot points and does not use a bitmapped framebuffer.
Turns out it takes advantage of the long persistence of the screen’s phosphor, and the brightness of each point decreases over time.
The CHM has a video of it running online, but it does not capture the effect of the phosphor persistence: https://www.computerhistory.org/collections/catalog/10266415...
Edit: here’s a video of it running in MAME that somewhat shows how phosphor persistence creates the XOR texture: https://youtu.be/AxJzUiaQ7xM?si=X9K47c4WyD6AisUp
There is a website that contains thousands of such examples.
https://www.dwitter.net/
Dwitter is like Twitter, but for one-line javascript examples using canvas. Users are limited to 140 bytes in their creations.
Here is a sample of an animated XOR texture in just 122 characters of JS code: https://www.dwitter.net/d/255
And here are several variations using other binary operators to create the Sierpinski triangle: https://www.dwitter.net/h/sierpinski
I made a quilt that uses this texture. I used the same rainbow scale that one of the last pictures on the site illustrates, So it looks a lot like this. 6 ft by 6 ft decoration I've got hanging on the wall.
Oooo, link to a photo, please!
That's quite a neat site. I recommend going up a level and browsing some of the other pages.
Even though it is 20 years old, a lot of that stuff can still find a use somewhere, especially if you do shader work.
I wa recently playing with this pattern in J, where it can be expressed like so
See it here: https://jsoftware.github.io/j-playground/bin/html2/#base64=b...Heh, I assume you just read https://news.ycombinator.com/item?id=42414817 and stumbled upon XOR textures as well?
Lode's website is how I learned how raytracing worked back in the days.
Their website is pure gold. Also, I love the layout even more today.
XOR Texture is the cover photo for my LED matrix project. I love the simple beauty of this texture https://github.com/jsheedy/matrix-display
What is the state of JavaScript sandboxing these days?
I would like to build a site geared towards this kind of algorithmic art. Where one can paste the JS code snippets and see the resulting image. Similar to my html editor with instant preview:
https://github.com/no-gravity/html_editor
But with the ability to link to the code.
Is it feasible these days to build something like this, but without the ability of the code to jump out of the result frame? Like no external http requests, no fiddling with the window etc?
If you were not worried about preventing external requests and were okay with it being able to make requests as an arbitrary webpage unrelated to your site could if opened, then loading the code in an iframe with the sandbox="allow-scripts" attribute is enough.
If you needed tighter sandboxing than that, then I think WebAssembly is your best bet because you can control exactly what APIs are exposed to a WebAssembly module. You could then let users submit WebAssembly modules or let them submit JS that will be run in a JS interpreter running in WebAssembly. I think https://github.com/justjake/quickjs-emscripten or https://github.com/fermyon/StarlingMonkey (used by https://github.com/bytecodealliance/ComponentizeJS) look good for that.
Wow, sandbox="allow-scripts" looks pretty good. Doing some additional research, it seems one can disallow all network requests via Content-Security-Policy directives:
The JS runs, but no network requests are made. I wonder if that solves all headaches regarding the execution of user provided JS code?Oh I hadn't thought of using CSP for that. CSP alone used to not be enough but combined with the iframe's sandbox attribute (or the relatively newer sandbox CSP directives, which both block navigation and form submissions by default) then I think it's enough to block external network requests. This combo seems like a good solution for many use-cases.
However there are certain things that it still doesn't protect against: CPU and memory exhaustion. Someone's script can hog those resources and possibly cause the browser to crash the tab. If you only execute one user's code at a time when a user of the site specifically browses to it / activates it, then it might be acceptable because a user can learn to not re-activate code that just crashed their tab and won't be missing out on anything else, but if you had a setup where it didn't take user action to run other users' code (like you have a homepage that automatically shows a running preview of other people's code, or you have a multiplayer programming game where each player submits code and everyone in the game sees it run together and interact with other players' code) then it could be purposefully griefed by players submitting code that exhausts resources. If you need to protect against local denial of service attacks like this, or if you needed strict determinism for some reason, then I think a WASM-based solution is still the way to go.
You could take notes from https://www.shadertoy.com/ and https://www.dwitter.net/
Also known as GF(2) texture :) That's why the texture looks cyclic
Never heard of it, and I haven't seen it in long enough that it's no longer overused!
Really cool!
i frequently generate something resembling this and/or the hamming distance texture in a fairly dumb manual way, by just doing blend mode overlay on progressively smaller checkerboards.
it's my go-to for lining up pixel-perfect uv maps for more geometric/mechanical 3d assets -- the recursive nature means you can have an easy time hitting, say, the exact corners or centers of luxels if you feel the need.
You may modify the pattern by simply adding a bitmask
for example, multiply with different bit masks : https://files.catbox.moe/vhfd9x.mp4This looks a bit like a fractal, specifically it reminds me of the Sierpinski triangle, though the XOR texture doesn't seem to be a proper fractal with an associated dimension.
However, according to these replies here the XOR texture and the Sierpinski triangle/tetrahedron are indeed mathematically related: https://math.stackexchange.com/questions/1080223/what-do-bit... (Admittedly I don't understand the mathematics behind this connection)
My python+numpy+matplotlib version from when I was playing around with it:
Similar to this, if you fill the texture with (x & y ? white : black), where x and y are the 0-indexed coordinates of the pixel in question, you get a Sierpinsky triangle.
A simplified use case is to generate a checkerboard texture, just compute (x ^ y) and look at bit zero:
I wonder if someone has written a GPU shader that can play a game of chess inside a 8x8 checkerboard texture.
Googling finds a shadertoy that's halfway there ;) (knows about chess rules, but can't play on its own):
https://www.shadertoy.com/view/wstBz4
> It was shown how easy it is to create a XOR texture, which makes the XOR texture useful to test if a texture renderer is working.
> However, it's not suitable for applications such as art or games.
uhhh why not suitable for art? I'm digging into it right now and made some trippy stuff!
https://xor-pattern.netlify.app/
That's a really neat demonstration! Would you mind if I use this code to jump off with my own tangent? (I want to hook the microphone audio into it, to control the patterns based off voice/music)
The way the patterns looked, felt natural enough that my brain was trying to make sense of the chaos.
go right ahead! i can make a repo for it if you have any trouble copying.
PLEASE, for the love of god, send it to me later. I am extremely interested (not just saying that). tomomyrman@proton.me or reply here
or, let's collab!
It is a sizecoding/demoscene classic, which is a form of art.
Using it as-is tends to be discouraged though, because it is considered unoriginal and lazy for all but the tiniest of intros. Variations on it are fine.
>However, it's so overused that it's not a good choice to use in in a demo or intro release.
I guess because it's been seen before? Don't let anyone else yuck your yum though - if you like it and find a way to make it look cool, use it!
asked the same question. i think this is art itself!
If you plot x^y against x+y, you get a Sierpinski triangle.
It mentions the other texture generation articles but I can’t find them anywhere. Anyone got the links?
I must be missing something simple, where are h and w defined? Does the call to screen imply that somehow?
Height and width of the texture. They're whatever constants you choose.
https://lodev.org/cgtutor/examples.html#screen
They're set by screen, exactly!
I'm wondering what it does if one convert x and y to gray code before the XOR
(2004)
[flagged]
A lot of this article seems to be conflating two things:
1. The ability for the code to process the error and recover from it 2. The ability to sensibly log, trace, and later for a human to understand the error after the fact
The later of these is best handled by using a tracing library systematically throughout your code to spit out open telemetr and “logging” the error within your local span. You can then debug the problem with a tool like honeycomb which’ll give you a much clearer idea of what’s going on. Having tracing in place will also help you debug in cases where you don’t have errors but your system is running slowly, doing something unexpected, etc.
This greatly reduces the problem domain you have to solve in actual error handling to just having the computer recover when something is recoverable. And in these situations it turns out that most recoverable errors are best expressed as “non-errors” once they migrate any distance from the origin of the error (e.g. the record not found turns into a standard “user not known” status return value - it’s no longer an error, but an expected behavior of the system!) So for these “short lived” errors that are either handled locally or bubbled up all the way to the top and never handled, I’ve found that Go’s native basic error framework is fine.
I think you probably meant to post this on https://news.ycombinator.com/item?id=42447762