Show HN: A Stargate in 140 chars of JavaScript

The function z produces the puddle (ahem - "event horizon") through a technique I accidentally found from "orthogonal" raymarching. The accident being the value is supposed to be the distance of an incrementing ray for an SDF (signed distance function), but instead the distance is completely replaced on each recursion resulting in the reflected fluid appearance. I think this is due to the ray distance oscillating backwards and forwards in a way that is similar enough to neighboring rays to not appear noisy while giving the appearance of reflection. The exact functions used for the SDF are not so important so long as it incorporates itself.

fillRect is doing pretty much everything else, by painting each pixel. To achieve shading without fillStyle, the width and height arguments are varied between 0 and 1 to give grey scale shading due to subpixel anti-aliasing. Speculative edges are also achieved with negative values (0 to -1) which creates white gaps and fill adjacent pixels instead.

The chevrons are sampled from a radial fractal a*20-r&44 where 'a' is the angle of the current position wrapped in some periodic function (cosine), and 'r' is the radius. The bitwise AND operator is the key in generating these types of patterns (although OR and XOR also work very well producing other types of patterns), the constants are found through - a lot - of trial and error. In this case the result of the fractal is used as a "truthy" condition (i.e non zero) to toggle between the shaded sides (X/48 or Y/48) and 1 (the dark bits).

Some other hacky details: S and T are the X and Y pixel positions, these names are used so that they can be referenced before they have been assigned because these names have already been assigned unused functions by dwitter. This saves some characters by allowing me to define X and Y inside of atan2 while also passing them as arguments, at the cost of the fillRect X Y position being invalid for the first pixel and from the previous iteration on the rest.

I'm finding a recurring property of dweets that end up packing a lot in - is sharing significant portions of code for different purposes, in this case it's fairly straight forward but still a big win in terms of characters: S, T and r are only defined once and used for both the puddle and the ring. This type of size optimization always gives a lot more road than syntactic wrangling, which while important are only finishing touches. However they cannot be forced, ideas with enough shared code can only be found.

Feel free to ask me anything else.

window.location='https://www.dwitter.net/d/20584';

Unpacked = 303 chars (+109):

  document.body.innerHTML='<canvas id=c>';x=c.getContext('2d');t=0;setInterval(_=>{for(X=Y=C=Math.cos,t+=1/60,c.width=192,R=48,i=8064;i--;x.fillRect(X+96,Y+54,C(Math.atan2(X=i%97-R,Y=i/97-R,r=(X*X+Y*Y)**.5)*9)*20-r&44&&r>36?r<42?Y/R:X/R:1,r>36?r<R:z(3)/5))z=n=>n--&&C(Y/2+X*Y/R+t*9)*C(Y/4-z(n)*2)-r/6},16)

[0] https://github.com/zedeus/nitter

I tried deobsfucating as much as I could, but I had to go.

https://jsfiddle.net/omgz5xjd/16/

I also missed tomxor's explanation which made things more clear. Initially I thought there was some sort of scanline thing going on.

The code is run in this loop with those variables in non-strict mode to allow various hacky things e.g `with()` that are invaluable for code golfing.

The eval escape unescape trick extracts two chars in the ASCII space from each UTF16 character. Here's the encoder: https://www.dwitter.net/d/11852 You can see the content by removing the eval and just outputting the string... alternatively replace 'eval' with 'throw' on dwitter and it will print the source bellow the dweet.

  c = document.createElement('canvas');
  document.body.appendChild(c);
  x = c.getContext('2d');
  S = Math.sin;
  T = Math.tan;
  C = Math.cos;
  t = 0;

The escape function [0] converts unicode values > 0xFF into the string format '%uxxxx`, additionally it will produce two sequences if the unicode point is high enough to require two UTF-16 surrogate pairs. e.g escape() ing the first character '𩡯' results in '%uD866%uDC6F'. The regex throws away the 'uD8' parts of each sequence as we aren't exploiting the full capacity of the unicode space, just the lower 255 values of each surrogate pair. which results in '%66%6F'. Finally this is unescaped which converts these into the separate ASCII chars that were originally packed with dweet 11852 (don't ask me how it packs it I haven't looked yet.)

In all this means it's possible to fit 194 evaluable ASCII chars into a dweet (taking into consideration overhead of the unpacking code). There are also more esoteric methods of fitting more characters or data using unicode that are not generally evaluable, e.g image data. All of these techniques are using more than 140 bytes, but dwitter has a character limit not byte limit. But nothing is free, you must fit any decoders into the same dweet so there is always a balance.

[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Only need to save result of atan2 `a` (angle) and then tweak the ripple effect in z:

  C(a/3+r+t*9)*C(T/5+z(n)*2)

The other problem with this argument is that it never ends: If you write on "bare metal" one can argue you are relying on thousands if lines of firmware and microcode. Then you go even lower and one can argue that your high level CISC ISA is doing too much work for you. Eventually you end up with transistors and then people will end up arguing which transistor is the least complex design to fabricate. I will admit trying to compute with sticks, stones and crabs (for real) is a fun idea, but it's hard to achieve much beyond a ripple adder.