Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #2330

Re: 64 bit code

From BGB <cr88192@hotmail.com>
Newsgroups comp.programming
Subject Re: 64 bit code
Date 2012-10-12 12:36 -0500
Organization albasani.net
Message-ID <k59kkr$f65$1@news.albasani.net> (permalink)
References <e5cd117b-219b-49a3-9054-3553ca359f21@googlegroups.com> <507595db$0$6898$e4fe514c@news2.news.xs4all.nl> <k5488o$cbv$1@dont-email.me> <k54j49$cns$1@speranza.aioe.org> <162dnU-Rw5IpVOrNnZ2dnUVZ8qCdnZ2d@bt.com>

Show all headers | View raw

On 10/12/2012 2:40 AM, Chris Uppal wrote:
> Rui Maciel wrote:
>
>> And let's not forget about the ever elusive 80-bit extended precision
>> floating point format, also known as "why bother".
>
> For one answer, people might like to read:
>
>      http://www.cs.berkeley.edu/~wkahan/Stnfrd50.pdf
>
> linked to from Kahan's page:
>
>      http://www.cs.berkeley.edu/~wkahan/
>

the upside of 80-bit floats: higher precision than 64-bit doubles;
the downside of 80-bit floats: slightly bigger than 64-bit doubles, and 
they are an inconvenient size.

but, I remember vaguely recently running into an issue:
32-bit floats are pretty much the standard in gaming.

so, originally, I used floats, and all was well (actually, many places 
were sub-float, as I had a "float28" which basically shaved the low 4 
bits off, mostly to allow essentially twiddling a float into a 32-bit 
pointer, or a so-called "flonum").


but, then there was a problem:
much more than about 1km from the origin (in a game from a first-person 
POV), there was obvious/noticeable jitter.

there was some rendering jitter (twitching geometry), and also the 
camera movement would jitter/shake, and if a weapon was fired the 
projectile itself would jitter and shake around as it moved, ...


so, there was a problem then: floats were not really sufficient.

second problem:
doubles don't actually work in the graphics hardware (they all assume 
"floats are plenty good enough" here as well).


so, partial solution:
many intermediate (server-end) calculations (and storage), are done 
using doubles (mostly things involving the object origin);
the client-side scene-graph also uses doubles.

however, there is a "reference point" which is now subtracted out of 
origins when sending them between the client and server (the main place 
where the 28-bit truncation occurs, but sending full doubles through 
here would be much more costly), and also the client-side rendering is 
performed relative to this reference-point (it is subtracted out when 
things are sent to the renderer).

note that only about a float-28 worth of accuracy is sent, but since it 
is relative to a point near the camera, they are more "the bits that count".


suddenly, now, the scene is no longer limited to around 1km or so (or, 
at least, not by jitter), however the second problem is that scenes are 
voxel-based, similar to Minecraft, and going too much over 1km^2 
requires large amounts of RAM. a partial way to combat this issue 
essentially involves RLE-compressing the voxel-chunks in RAM, and 
decompressing the chunks as-needed, though, there is still a limit as 
there is currently still no mechanism to "unload" chunks or regions 
which are out of range.


or such...

Back to comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

64 bit code bob <bob@coolfone.comze.com> - 2012-10-10 08:22 -0700
  Re: 64 bit code Jongware <jongware@no-spam.plz> - 2012-10-10 17:35 +0200
    Re: 64 bit code "BartC" <bc@freeuk.com> - 2012-10-10 17:37 +0100
      Re: 64 bit code Robert Wessel <robertwessel2@yahoo.com> - 2012-10-10 12:54 -0500
      Re: 64 bit code Fritz Wuehler <fritz@spamexpire-201210.rodent.frell.theremailer.net> - 2012-10-10 21:37 +0200
        Re: 64 bit code BGB <cr88192@hotmail.com> - 2012-10-10 21:46 -0500
      Re: 64 bit code Rui Maciel <rui.maciel@gmail.com> - 2012-10-10 20:43 +0100
        Re: 64 bit code "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-10-12 08:40 +0100
          Re: 64 bit code BGB <cr88192@hotmail.com> - 2012-10-12 12:36 -0500
          Re: 64 bit code Rui Maciel <rui.maciel@gmail.com> - 2012-10-12 20:57 +0100
            Re: 64 bit code "BartC" <bc@freeuk.com> - 2012-10-12 21:30 +0100
              Re: 64 bit code BGB <cr88192@hotmail.com> - 2012-10-12 16:33 -0500
                Re: 64 bit code "BartC" <bc@freeuk.com> - 2012-10-13 00:44 +0100
                Re: 64 bit code Ben Pfaff <blp@cs.stanford.edu> - 2012-10-12 20:07 -0700
              Re: 64 bit code Rui Maciel <rui.maciel@gmail.com> - 2012-10-13 11:11 +0100
                Re: 64 bit code "BartC" <bc@freeuk.com> - 2012-10-13 13:11 +0100
                Re: 64 bit code Willem <willem@turtle.stack.nl> - 2012-10-13 12:34 +0000
                Re: 64 bit code BGB <cr88192@hotmail.com> - 2012-10-13 09:50 -0500
                Re: 64 bit code "BartC" <bc@freeuk.com> - 2012-10-13 17:25 +0100
                Re: 64 bit code Rui Maciel <rui.maciel@gmail.com> - 2012-10-13 17:53 +0100
                Re: 64 bit code Rui Maciel <rui.maciel@gmail.com> - 2012-10-13 17:05 +0100
          Re: 64 bit code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-10-13 10:37 +0200
            Re: 64 bit code "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-10-27 12:18 +0100
              Re: 64 bit code "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-10-27 12:54 +0100
              Re: 64 bit code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-10-27 15:13 +0200
                Re: 64 bit code Robert Miles <milesrf@Usenet-News.net> - 2012-10-28 04:12 -0500
                Re: 64 bit code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-10-28 13:10 +0100
                Re: 64 bit code "LudovicoVan" <julio@diegidio.name> - 2012-10-29 04:38 +0000
                Re: 64 bit code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-10-29 09:30 +0100
                Re: 64 bit code "LudovicoVan" <julio@diegidio.name> - 2012-10-30 22:09 +0000
                Re: 64 bit code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-10-31 09:47 +0100
                Re: 64 bit code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-10-31 09:55 +0100
                Re: 64 bit code "LudovicoVan" <julio@diegidio.name> - 2012-10-31 14:32 +0000
            Re: 64 bit code Patricia Shanahan <pats@acm.org> - 2012-10-27 08:51 -0700
              Re: 64 bit code "LudovicoVan" <julio@diegidio.name> - 2012-10-27 17:23 +0100
              Re: 64 bit code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-10-27 20:43 +0200
                Re: 64 bit code "LudovicoVan" <julio@diegidio.name> - 2012-10-30 22:16 +0000
                Re: 64 bit code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-10-31 09:53 +0100
                Re: 64 bit code "LudovicoVan" <julio@diegidio.name> - 2012-10-31 14:33 +0000
                Re: 64 bit code Fritz Wuehler <fritz@spamexpire-201211.rodent.frell.theremailer.net> - 2012-11-01 00:25 +0100
      Re: 64 bit code Rui Maciel <rui.maciel@gmail.com> - 2012-10-10 21:04 +0100
        Re: 64 bit code "BartC" <bc@freeuk.com> - 2012-10-10 21:52 +0100
          Re: 64 bit code Ian Collins <ian-news@hotmail.com> - 2012-10-11 10:50 +1300
            Re: 64 bit code BGB <cr88192@hotmail.com> - 2012-10-10 21:54 -0500
              Re: 64 bit code "BartC" <bc@freeuk.com> - 2012-10-11 13:11 +0100
                Re: 64 bit code BGB <cr88192@hotmail.com> - 2012-10-11 11:17 -0500
      Re: 64 bit code Ben Pfaff <blp@cs.stanford.edu> - 2012-10-10 13:17 -0700
        Re: 64 bit code Fritz Wuehler <fritz@spamexpire-201210.rodent.frell.theremailer.net> - 2012-10-11 19:36 +0200
          Re: 64 bit code Ben Pfaff <blp@cs.stanford.edu> - 2012-10-12 08:13 -0700
    Re: 64 bit code Rui Maciel <rui.maciel@gmail.com> - 2012-10-10 20:38 +0100
    Re: 64 bit code Robin Vowels <robin.vowels@gmail.com> - 2012-10-10 15:22 -0700
  Re: 64 bit code Robert Miles <milesrf@Usenet-News.net> - 2012-10-12 02:13 -0500

csiph-web