Hacker News Reader

Comment by otikik | Hacker News Reader

Fun fact: PICO-8 only provides turn-based trigonometric functions

https://pico-8.fandom.com/wiki/Sin

> PICO-8 uses an input range of 0.0 to 1.0 to represent the angle, a percentage of the unit circle. Some refer to these units as "turns". For instance, 180° or π (3.14159) radians corresponds to 0.5 turns in PICO-8's representation of angles. In fact, for fans of τ (tau), it's just a matter of dropping τ from your expression.

View on HN

Back in the early 80's a common thing to do in games on 8 bit computers was to implement sin and cos as lookup tables with the angles being 0-255 or 0-128 or something like that and the result also an integer that was some fixed point representation, so you'd do something like:

  vx = (cos[angle] * speed) >> 8;
  vy = (sin[angle] * speed) >> 8;

Ouch. Less than 1 degree of accuracy? Well, I guess if it’s good enough for Asteroid, it’s good enough for me

The original Asteroids source code has been released, we can look at what it did! (Also, even before that the EPROM images had been disassembled, but looking at the original sources is more fun.)

It indeed used (-128, 128) for (-180°,180°)

For instance, here it is using 64 (written as "40", because hexadecimal) for "PI/2":

    COS:    CLC                     ;COS(A)=SIN(A+PI/2)
            ADC I,40
    ;       JMP SIN

It implements COS in terms of SIN, and SIN wraps everything to be in the domain [0,64] (that is [0°,90°] ) then retrieves that from the lookup table.

code: https://github.com/historicalsource/asteroids/blob/main/A351...

table: https://github.com/historicalsource/asteroids/blob/main/A351...

Pico8 is 128x18 res, so I think the maximum number of visibly unique lines you could draw from one point is 512. You can't even express sub-one-degree (sub-1.422222 really) rotations on Pico8 visually without subsampling etc.

Interesting. I couldn't imagine asteroids without at least 1 degree accuracy feeling right, but I just fired up a pico8 emulation of asteroids and it had what seemed like about 24 steps of rotation, and played beautifully. Funny how my memory gave it way higher resolution.

https://sazazel.itch.io/pico-8-asteroids

The objects you are shooting at have large angular width.

You can always do one cycle of newton-raphson to get nearly double the accuracy with only one extra lookup-multiply-add.

The MOS 6502 didn't have a multiply.

Great, now I'm banging my brain against newton-raphson trying to understand it

The sin/cos lookup tables would only contain an octant of the circle and use various symmetries to map other values to that range. Thus the resolution is ~0.176 degrees for a 256-entry table.

sin(x) = -sin(-x) = sin(pi - x) = cos(pi/2 - x)

cos(x) = cos(-x) = -cos(pi - x) = sin(pi/2 - x)

The limit on precision wasn't the size of the lookup table, it was the size of the integers. The CPU's integers were only 8-bits. So if you're using native integers (i.e.: [0,256) == [0°,360°) ), you can't get angles more precise than 1.4°.

Here are the algorithms for PICO-8's sin(), cos() and atan2(), as implemented by the Picolove emulator: https://github.com/picolove/picolove/blob/4b79a3b7ebd1d1bc6c...

Also, since PICO-8 coordinates have their origin in the top-left corner (y goes down), sin()'s result is also inverted.

Reply on news.ycombinator.com