#Change altitude internal format to 24-bit fixed point

103 messages · Page 1 of 1 (latest)

haughty musk
#

1024 bit floating-point
that... doesn't sound right. Where does that number come from?

#

and honestly you could get away with 16 bits, since in-game altitude is only shown rounded to 0.1m. log2(8400*10) is 16.35 - you only need ever so slightly larger than 0.1 packing to make it fit.

vapid root
#

tetr.io's maximum number is roughly 1.7976e308, which is 2^1024

haughty musk
#

that's not how floating points work, you can get a number that large because of an exponent that's a factor of log2 smaller

#

you only need 10 bits to represent 1024

#

floating points are split into a mantissa (base value) and an exponent, and for 64 bit floats the standard is 1 sign bit, 11 exponent bits, and 53 mantissa bits

vapid root
#

oh

haughty musk
#

the max value is a result of the exponent maxing out

vapid root
#

64 bits, ok that's a lot smaller than i thought lol

haughty musk
#

so it's max_mantissa * 2 ^ max_exponent

vapid root
#

but even then, 24 bits is still a pretty big improvement over that

manic fable
#

you cant just change the number format tho

#

theres a shitload of math done with these numbers and also you have to abide by what the programming language allows

haughty musk
#

it would be no problem to pack everything into an array of bytes of stride 2/3

vapid root
#

you can just take a 24-bit integer (0-16777215) and divide it by 256...?

#

unless it doesn't work that way, in which case i apologize

#

i don't claim to be an expert on this stuff

haughty musk
#

no that's basically what fixed point is, you just take a value with the understanding it represents a smaller actual value

vapid root
#

better yet, since 256 is a power of two (wait no really???) you can just bitshift it left by 8

manic fable
#

tetrio is coded in JS right?

vapid root
#

it's a webgame

haughty musk
#

floats are unevenly spread out, one quarter of the possible floating point values are in the range 0..1

#

(the other three quarters are in -inf..-1, -1..0, and 1..inf)

vapid root
#

this does make me wonder

#

what if i become so good at mech heart that i go so high that i just stop moving

#

because floating point is supid

haughty musk
#

you just stop moving, nothing else weird would happen

manic fable
#

and you'd also have to be very very high, and attacks would still send and give the boost (until youre much further)

#

but like

vapid root
manic fable
#

overall, this is MUCH easier said than done

vapid root
#

like, in terms of ingame meters per second

manic fable
#

and garbage travel time is irrelevant to what i said (which is about the bonus height you get when sending an attack)

haughty musk
manic fable
#

javascript uses floats almost exclusively

vapid root
#

also

#

fixed points take SIGNIFICANTLY fewer operations than floating points

haughty musk
#

doubt it's noticeable on a modern cpu with hardware acceleration

manic fable
#

you cant just tell it "use a 24 bit fixed point" you have to CODE that 24 bit number USING floats

vapid root
#

again

manic fable
#

again
theres no 24 bit format in javascript

#

theres no 24 bit integer

vapid root
#

if there's 32s, use those instead

haughty musk
#

this is going in the protocol, not the working representation in engine memory

#

you just convert between the two at the network boundary

manic fable
#

this just LITERALLY isnt how it works

haughty musk
# 
let packed = new Uint8Array(3);
let unpacked = a[0] << 16 | a[1] << 8 | a[2];

???

manic fable
#

dude thats not worth it at all

haughty musk
#

drocelot would absolutely do this

manic fable
#

AFAIK in js theres number and bigint and both are 64 bits

haughty musk
#

especially for something sensitive like network bandwidth

vapid root
haughty musk
#

no I'm saying drocelot will do bit packing shenanigans without a second thought if it improves performance

vapid root
#

it seems the two of you are on semi-opposite sides of this

#

i do get that this is probably a VERY NQ suggestion, but I doubt it would take longer than a day to implement, as opposed to some things I have submitted here.

manic fable
haughty musk
#

I mean, it's already a custom binary protocol

#

I wouldn't expect doing a custom width field to be that hard

#

it's not like they're going from json or something similarly unoptimizable

#

and the number format is just three bytes, it's a couple of shifts to encode and decode

#

there's already examples of this kind of bit packing in the game, nothing as odd as 24 bits but like the radiance header definition looks like a c struct that you absolutely have to manually parse with a DataView or similar

vapid root
#

like color

#

represented as a 3 byte hexcode

manic fable
#

(four byte in many cases, transparency)

haughty musk
#

a similar form of this ^ exists in the game already, packing 24 bits into a continuously sent network packet is nothing in terms of complexity compared to potential savings vs a 32 or 64 bit number

manic fable
#

even 600 players sending a float 10 times per second is <0.4Mbps
this is FAR below average
and playing on Low makes the leaderboard update only every two seconds anyway

manic fable
haughty musk
#

-# but what if I want to play tetr.io on dial up

#

Either way, this is kind of a useless discussion at this point. Based on my knowledge of the tetrio dev team, I would expect that a 64->24 bit savings for a message sent hundreds of times per second is absolutely something they would consider doing if the only tradeoff to be considered was implementation complexity.

#

probably not a priority at this point, but saying dude thats not worth it at all and this just LITERALLY isnt how it works doesn't seem like a reasonable expectation

manic fable
#

rshrug i guess

#

yeah after your explanation i understand now woomy

haughty musk
#

besides, there's all sorts of insane things you could do to pack it in even tighter if you really wanted to:

  • Check what players are actually visible to the client and only send data for them
  • Players are generally pretty close together, so if you're sending all of them together anyway you could use delta encoding to cram it in tighter: each player's height is a (e.g.) 10 bit number representing how much higher they are than the previous player in the list. If the height difference exceeds the representable values, a blank entry can be inserted instead as a buffer.
    :P
#

this also requires bookkeeping an order of clients and sending additional bits when reordering is necessary, but theoretically it'd work

#

but it's much less sane than packing it into 24 bits instead

manic fable
#

checking what players are visible only relevant for rendering the boards, altitudes are still visible at all times on the leaderboard

haughty musk
#

true, but you're only looking at a tiny fraction of the leaderboard at any one time

manic fable
#

yeah idk whether or not the lb does culling

haughty musk
#

for players far away from the current scroll position, you can send updates very infrequently

#

either way none of anything in this channel is based on actual facts about the implementation so it's similarly fairly useless

manic fable
manic fable
neat nymph
#

source?

#

because uh, you're talking total nonsense

image.png
#

it's an 18bit decimal (written as float here, but its fixed point uint18)

#

you cant just make an assumption of how the game works and then make a thread about it as if it's true

#

our encodings pack tightly where needed

neat nymph
#

i mean max safe integer is only 9007199254740991

#

whatever i lock thread

wind loom
#

Like osk said amadeus uses bit packed structures but I assure you we don't have '1024-bit' values lol I've designed amadeus very well for exactly this kind of stuff!

solemn hatch