Inspired by a question on #fractal forums dot org, I wrote a small #MandelbrotSet renderer that classifies pixels (modelled as little squares) according to whether they are interior, exterior, or boundary.

I added (adaptive) #supersampling to reduce the #ZoneOfUnknown surrounding the boundary, due to the fact that distance estimates are only good to a factor of 4 each way.

Not a trustworthy mathematical proof, because the factor 4 is optimistic (the distance estimate must be small, and there are other factors omitted from the simplified form that make it more like 4+k where k depends on the distance estimate), and because rounding errors might ruin everything.

I think I also have a bug in the factor of sqrt(2), probably it only belongs in one of the classification inequalities and not in the calculated pixel spacing.

Code:
https://code.mathr.co.uk/mandelbrot-graphics/blob/f13203d0286471212f0569d6dc7404a30b9bb172:/c/bin/m-classification.c

Working on 'et' (my escape-time #fractal program) this morning.

I added #supersampling presets from 1x1 through 8x8, selectable by keypress. It already did supersampling but you had to enter 3 numbers in a modal dialog.

The calculations of the array used for progressive image rendering were annoyingly slow, so I'm now caching them on disk using the xdg-basedir and vector-mmap packages (et is written in #Haskell). I also need the directory and filepath packages for this part.

The arrays get quite big, almost 700MB total for all supersampling sizes with a base resolution of 1024x576 pixels (it takes up 6 bytes per pixel). Changing the base resolution size means recalculating and storing another set of arrays. Cache will bloat!

So I'm thinking there might be a better procedural way to do what the arrays do, which is #Adam7 style interlacing (coarse pixels getting gradually finer in a multipass rendering) with the pixels in each pass ordered so that the center gets rendered first and it spreads out towards the edges.

So in short I need a cheap function from (ImageWidth, ImageHeight, PixelIndex) to (PixelX, PixelY, PixelWidth, PixelHeight), because using anything other than #atomics to increment PixelIndex is much too slow in #concurrent #multicore Haskell.

#Playstation:

#Firmware_Update bringt #Supersampling und #Elternkontrolle ...

https://www.golem.de/news/playstation-firmware-update-bringt-supersampling-und-elternkontrolle-1803-133232.html

#Playstation:

#Firmware_Update bringt #Supersampling und #Elternkontrolle ...

https://www.golem.de/news/playstation-firmware-update-bringt-supersampling-und-elternkontrolle-1803-133232.html

#Playstation_4_Pro:

#Firmware_5_50 bringt #Supersampling für Full-HD-Fernseher ...

https://m.heise.de/newsticker/meldung/Playstation-4-Pro-Firmware-5-50-bringt-Supersampling-fuer-Full-HD-Fernseher-3988856.html