| 00:31.49 | *** join/#bzflag bertman (~bert@unaffiliated/bertman) |
| 00:46.21 | macsforme | not to distract from our productive discussions today already, but I have been wondering if anyone who has argued for decoupling the game's simulation from the rendering loop has ideas for how to viably do that? |
| 00:47.54 | macsforme | I think the idea was suggested mostly because our simulation has issues at very low and/or very high framerate, and both of these conditions have happened to players |
| 00:48.32 | macsforme | but this seems to me like an issue with math precision that may be able to be solved in other ways |
| 00:48.59 | JeffM | at very high frame rates at the units bzflag uses a float will run out of room |
| 00:49.06 | JeffM | your DT becomes very small |
| 00:49.23 | JeffM | decouping is relativly easy |
| 00:49.39 | JeffM | bzflag is already halfway there. |
| 00:49.55 | JeffM | you'd have a loop that updated the sceenenodes and tank/shot postions on a fixed clock. |
| 00:50.28 | JeffM | and the render nodes would run at it's own frame rate, pulling from the current sceennode set when the frame started |
| 00:50.44 | JeffM | optimaly the sceennode updates would run in it's own thread. |
| 00:51.34 | JeffM | every rendernode is linked to a sceennode. so that split is already done. |
| 00:52.50 | macsforme | well, to make it as smooth as possible, you would still want to do a "soft" physics update (to get extrapolated positions) when the frame is drawn |
| 00:53.07 | macsforme | but I can think of only a few reasons to do a full simulation update: 1) you need to draw a frame, 2) you need to process user input, 3) something significant is going to happen in the game (e.g., a flag capture) |
| 00:53.49 | macsforme | and not even necessarily #1, if you can extrapolate from the last update |
| 00:56.24 | JeffM | possibly |
| 00:56.32 | macsforme | it seems to me that if you have completely separate loops for simulation and rendering, and rendering just pulls the last simulation update straight in, you're going to get glitching, skips, etc. |
| 00:56.49 | JeffM | I'd have the last sim update provide extrapolation hints to the renderer for it to do animation interpolation. |
| 00:57.04 | JeffM | depends on how slow your sim update is |
| 00:57.23 | JeffM | like a sim update of 10 fps is going to do that |
| 00:57.33 | JeffM | but a sim update of 30 would look fine. |
| 00:57.43 | JeffM | with some short extrapolations for animations |
| 00:58.12 | JeffM | you'd just be making sure that any animation interpolations are relativly short, not on the scale of a lag based interpolation. |
| 00:58.57 | blast007 | there's probably better ways to do the math too. currently, I think we only keep the last state and nudge those values along based on the dt from the last update, so the floating point inaccuracies stack up. |
| 00:59.00 | JeffM | the main advantage of splitting is not for high frame rates, it's for low. |
| 00:59.29 | JeffM | if you arn't worried about low sim rates, just limit the FPS to 120 and be done. |
| 00:59.39 | JeffM | or swap your sim over to doubles ;) |
| 00:59.59 | JeffM | ram is cheap |
| 01:00.00 | macsforme | yeah, if it's as easy as that then it seems silly not to |
| 01:00.17 | JeffM | I had FPS's limited to 120 in 2.9 |
| 01:00.37 | JeffM | and if the frame time was over some min time, I'd do multiple sim steps before drawing |
| 01:00.43 | blast007 | didn't 2.99 also have segmented simulation in cases where the dt got too high? |
| 01:00.51 | JeffM | that's what I just said ;) |
| 01:00.57 | blast007 | :) |
| 01:01.05 | macsforme | I play at 120 as well, but everyone seems to have a different opinion about what framerate feels ideal |
| 01:01.07 | JeffM | it ensured you got at least 15 sim frames a second or something like that. |
| 01:01.17 | JeffM | most human eyes can't see over 60 |
| 01:01.17 | macsforme | 60 feels mushy to me |
| 01:01.26 | JeffM | usualy over 80 is fine |
| 01:01.26 | blast007 | at around 200FPS, you start to bounce off walls |
| 01:01.28 | macsforme | I believe that has been debunked :P |
| 01:01.37 | macsforme | hence why we have 144Hz gaming monitors |
| 01:01.48 | JeffM | or that could be marketing materials ;) |
| 01:01.58 | JeffM | but sure, pick SOME sane limit |
| 01:02.12 | blast007 | nah, 144Hz is night and day difference when moving windows around |
| 01:02.16 | JeffM | the limit itself isn't important, just so long as the math works in it. |
| 01:02.37 | macsforme | if you just flick your cursor back and forth on the desktop, you can see the stuttering between frames on 60 FPS |
| 01:03.18 | JeffM | making the simulation be doubles would not be too hard ether. |
| 01:04.17 | blast007 | there is some weird things we do. for instance, if you drive up against an obstacle, you will be pushed away from said obstacle at a distance based on your speed. less noticable at normal speeds, but exagerated when you crank up the tank speed. |
| 01:04.53 | JeffM | yeah all that was fine when 15fps was "good" |
| 01:05.01 | macsforme | but for bz specifically, I think the movement is so slow that the difference would not be significant... I rendering at 60 FPS feels fine, if there was a way to process input and/or update the simulation at a higher rate |
| 01:05.05 | JeffM | the collision responce code is kind of childish |
| 01:05.58 | JeffM | it tries to minimize square roots |
| 01:09.52 | macsforme | the collision code kind of evolved over time, right? was it written by multiple people? |
| 01:10.05 | JeffM | it's been tweaked by multiple people |
| 01:10.09 | JeffM | mostly for new object support |
| 01:10.19 | JeffM | but old objects still have holdover code |
| 01:10.25 | JeffM | hence mesboxes vs boxes |
| 01:11.27 | blast007 | vs meshified boxes :) |
| 01:11.37 | JeffM | really for collions, a surface is a surface is a surface, it should not matter what map object created the surface. |
| 01:12.05 | blast007 | wonder if we ever fixed OO not being able to drive through meshified boxes |
| 01:12.23 | JeffM | "oh that board was put down by an old guy, you levetate over it, try this new board I just put in" :) |
| 01:16.44 | macsforme | not every surface is equal, though... for example, you can't truly represent a cylinder or cone as a triangle mesh in your physics simulation |
| 01:20.34 | *** join/#bzflag infobot (ibot@rikers.org) |
| 01:20.34 | *** topic/#bzflag is https://BZFlag.org || http://ohloh.net/p/bzflag || https://bzflag.org/help || Channel Logs: http://infobot.rikers.org/%23bzflag/ || 2.4.12 released! https://forums.bzflag.org/viewtopic.php?f=62&t=19720 |
| 01:20.34 | *** mode/#bzflag [+v infobot] by ChanServ |
| 01:26.18 | blast007 | are our macOS binaries 64-bit (or at least hybrid 32/64-bit)? |
| 01:26.47 | macsforme | yes |
| 01:26.51 | blast007 | k |
| 01:27.24 | blast007 | saw that Apple is going to start throwing warnings for 32-bit software :) |
| 01:27.51 | JeffM | thats very brave of them |
| 01:46.45 | macsforme | if they keep up with this courage, the next macbook might even have TWO usb-c ports... actually nevermind, that would be too radical |
| 01:50.31 | blast007 | macsforme: nah, they'll probably make a new one called USB-D that nobody else has and then drop support for it in several years |
| 01:51.10 | the_map | wait, you didn't hear? they're eliminating all ports entirely! you just have to buy special Apple adapters to use USB of any kind |
| 01:51.58 | the_map | starting at $19.99 for a single USB-A converter, special deal of $29.99 for a two port converter |
| 01:53.23 | allejo | wireless charging for laptops! |
| 01:54.16 | the_map | does the apple power cord use a "port"? it's just a magnetic connection |
| 01:54.26 | the_map | and that is actually something they did right |
| 01:55.07 | blast007 | afaik, they don't do the magsafe plug anymore |
| 01:55.30 | allejo | yea, newer laptops charge over USB-C |
| 01:55.35 | the_map | it was too popular and too many people were using it so they decided to switch from it? |
| 01:56.07 | allejo | either that, or standardize USB-C for laptops |
| 01:56.19 | blast007 | it had some problems, such as collecting small metal fragments over time |
| 01:58.20 | blast007 | dunno how common that was though |
| 02:03.16 | allejo | depends a lot if you carry stuff with your laptop. like paper clips or stuff |
| 02:03.54 | blast007 | well, by fragments I mean tiny pieces, not "a paperclip" :) |
| 02:06.03 | allejo | takes out his jar of metal shavings from his backpack |
| 15:57.30 | *** join/#bzflag nadir (uid134094@gateway/web/irccloud.com/x-qjzjizffsrmzmqyz) |
| 18:15.51 | *** join/#bzflag bboles (~quassel@2607:fcd0:100:8300:1c::a3ed) |
| 22:29.32 | *** join/#bzflag The_Noah (6163fde4@gateway/web/freenode/ip.97.99.253.228) |