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-...

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/)

  5 4 7 6 1 0 3 2

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.

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.

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

  ~:"1/~&.#:i.2^8

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?

    <iframe sandbox="allow-scripts"></iframe>

    <script>
        document.querySelector('iframe').srcdoc=`
            <meta http-equiv="Content-Security-Policy" content="default-src 'none'; script-src 'unsafe-inline'">
            <span>Hello</span>
            <script>
                document.querySelector('span').innerHTML+=" world"; 
                fetch('/');
            </sc`+`ript>
            <img src='https://placecats.com/300/200'>
        `;
    </script>

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

    pixels[x][y] := (x OP y) BITWISE_AND mask

for example, multiply with different bit masks : https://files.catbox.moe/vhfd9x.mp4

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)

My python+numpy+matplotlib version from when I was playing around with it:

  import numpy as np
  import matplotlib.pyplot as plt
  n = 2048
  X, Y = np.mgrid[:n,:n]
  plt.imshow(X^Y, cmap=plt.cm.Spectral)
  plt.show()

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:

    color = ((x ^ y) & 1) ? black : white;

If you plot x^y against x+y, you get a Sierpinski triangle.

> 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/

It mentions the other texture generation articles but I can’t find them anywhere. Anyone got the links?

I'm wondering what it does if one convert x and y to gray code before the XOR

I must be missing something simple, where are h and w defined? Does the call to screen imply that somehow?

(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.