| *** Zehra <Zehra!~Zehra@unaffiliated/zehra> has joined #bzflag | 00:25 | |
| Zehra | I've looked through StateDatabase .h/.cxx, BZDBCache.h, BZDBLocal.h, DefaultBZDB.h, looking to check if some server variables are either float or double, any recommendations on where to look? | 01:29 |
|---|---|---|
| Flash | that's kind of vague | 01:29 |
| Zehra | Let me reword it, in StateDatabase.h, variables like "static const std::string BZDB_EXPLODETIME;" appear, however this does not tell me the type of variable it is, I'm looking for where to find it. | 01:32 |
| Zehra | Some variables can easily be known by name and I've found quite a bit, but none of the ones I am specifically looking for. | 01:32 |
| CaptainRoberts[m | They are all strings | 01:33 |
| CaptainRoberts[m | Ppl | 01:33 |
| Flash | ~lart CaptainRoberts[m | 01:34 |
| * infobot eats CaptainRoberts[m's liver with some fava beans and a nice chianti | 01:34 | |
| CaptainRoberts[m | Deep fry it, it’s kinda fatty | 01:34 |
| Flash | dread pirate or not | 01:35 |
| blast007 | there *are* all strings, though :) | 01:35 |
| blast007 | the value can even have mathematical operations that refer to other variables | 01:35 |
| CaptainRoberts[m | Yeah bzdb transmits and stores all values as strings then does an eval | 01:35 |
| CaptainRoberts[m | So the float or double precision is pointless | 01:36 |
| Zehra | Alright. I believe that solves my question. | 01:37 |
| Flash | regardless, chianti and liver ... Friday night is complete | 01:38 |
| blast007 | Zehra: what you may be looking for is how a variable is *evaluated*. So just 'git grep _whateverVar' and see what eval function is used to convert the BZDB variable into a number/boolean. | 01:39 |
| Zehra | blast007: Ah, I also realized one thing I overlooked too, no bz_getBZDBFloat() exists, thus making my earlier question quite invalid to an extent. | 01:49 |
| blast007 | hmm, some of that stuff is a bit weird. The actual BZDB system returns a float, not a double. | 01:53 |
| blast007 | and for some reason we don't use the other eval variants for the BZFS API functions. We could use isTrue, evalInt, etc. | 01:55 |
| blast007 | bool StateDatabase::evalTriplet(const std::string& name, float data[4]) <--- I also assume that 4 should be a 3, cuz.. "Triplet" | 01:56 |
| Flash | doesn't matter .... float[4] == float* | 01:57 |
| Zehra | No wonder I've gotten confused at certain points. | 01:58 |
| Flash | C/C++ is a wonderfully [im]precise language | 01:59 |
| Flash | unless painfully explicit, assume double in most cases | 02:04 |
| blast007 | Flash: are you talking about BZDB specifically? | 02:06 |
| Flash | no, C/C++ generally | 02:13 |
| Zehra | Float to double conversion does not result in much issues, double to float is loss in precision... | 02:19 |
| Zehra | Depending on application it is used for, it may or may not be "permitted", either due to "precision" or "memory" requirements. | 02:20 |
| CaptainRoberts[m | Nothing in bzflag needs double precision | 02:20 |
| Flash | on the other hand, 64 bit processing defaults to double, and shouldn't be negated, except by well defined exception | 02:22 |
| CaptainRoberts[m | Most optimizers will pipeline floats to process faster than doubles when the precision is not needed. | 02:23 |
| CaptainRoberts[m | And the graphics are all going to be float, so you have to convert back to float before display anyway, so you loose speed converting back. Nothing in bzflag will need the precision to justify it. | 02:24 |
| CaptainRoberts[m | 98% of the time bzflag is drawing | 02:24 |
| CaptainRoberts[m | Unless you are looking at worlds being larger than several thousand units. | 02:25 |
| blast007 | are there precision differences when building for 32-bit versus 64-bit? on Linux, at least, collisions behave differently in 32-bit versus 64-bit. (It's possible to get stuck in teleporters in 32-bit builds) | 02:26 |
| CaptainRoberts[m | Collision detection and response may be more consistent with doubles. | 02:27 |
| Zehra | IIRC on spldart's server, I did get stuck in a teleporter, but this did not occur on another build, but the system was Windows. | 02:27 |
| blast007 | I've not see the 'stuck in teleporter' issue on Windows | 02:28 |
| blast007 | only 32-bit linux builds | 02:28 |
| CaptainRoberts[m | Good thing those are dying | 02:28 |
| blast007 | yeah, though some of our users apparently are still using 32-bit :) | 02:28 |
| blast007 | bumping the minimum GL version will probably take care of those, though | 02:29 |
| blast007 | hmm, though I suppose a Pentium M/4 might still have a card that can do GL 2.0 | 02:30 |
| CaptainRoberts[m | You would probably get more consistent results by transforming the collision checks to be relative to the tank instead of doing them in world space too. Then you’d always be checking things in a small relative area. | 02:30 |
| blast007 | we should do fewer collision checks too. when you're cranking out 400 FPS, the dt is real small and results in wonky math. | 02:31 |
| CaptainRoberts[m | Yeah that will run into float precision errors | 02:32 |
| CaptainRoberts[m | Frame limit your simulation to 60 | 02:32 |
| blast007 | Yeah, that was my thought. Limit the simulation and then the graphics could dead reckon between simulation updates. | 02:33 |
| Flash | CaptainRoberts[m: why do you say "optimizers will pipeline float to process faster"? On modern hardware, double is faster | 02:35 |
| Flash | GPU is an exception | 02:35 |
| CaptainRoberts[m | I have not seen that in my experience with floats in 64 bit compiles. But maybe that’s just me. | 02:37 |
| Flash | YMMV but the hardware does 64-bit operations | 02:38 |
| Flash | except for REALLY old HW | 02:38 |
| CaptainRoberts[m | Yes but the hardware also can do operations on 32 but floats at a faster IPC in some cases. | 02:41 |
| Flash | REALLY old HW | 02:42 |
| Flash | and, for almost all cases, "your attempt at optimization is worse than your compiler ... do you REALLY want to play in that space?" | 02:43 |
| blast007 | Flash: what if I install an 8087 math co-processor? | 02:45 |
| Flash | and do we care? | 02:46 |
| CaptainRoberts[m | Yeah for bzflag it does not matter. | 02:47 |
| BZNotify | bzflag: blast007 commented on pull request #251 "Fix multiple issues with SDL 2 window creation" by macsforme (https://git.io/JfCsQ): @macsforme mentioned to me that the resolution change infinite loop... | 02:54 |
| *** I_Died_Once <I_Died_Once!~I_Died_On@unaffiliated/idiedonce/x-1828535> has quit IRC (Ping timeout: 260 seconds) | 04:07 | |
| *** Zehra <Zehra!~Zehra@unaffiliated/zehra> has quit IRC (Quit: Gone for now.) | 04:35 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@unaffiliated/idiedonce/x-1828535> has joined #bzflag | 09:44 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@unaffiliated/idiedonce/x-1828535> has quit IRC (Ping timeout: 260 seconds) | 14:09 | |
| BZNotify | bzflag: blast007 commented on pull request #251 "Fix multiple issues with SDL 2 window creation" by macsforme (https://git.io/JfCd7): I tested older BZFlag versions with SDL 2.0.9, back to 2.4.8, and t... | 16:49 |
| *** Zehra <Zehra!~Zehra@unaffiliated/zehra> has joined #bzflag | 17:05 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@unaffiliated/idiedonce/x-1828535> has joined #bzflag | 18:45 | |
| *** Zehra <Zehra!~Zehra@unaffiliated/zehra> has quit IRC (Quit: Gone for now.) | 21:09 | |
| *** Sgeo <Sgeo!~Sgeo@ool-18b982ad.dyn.optonline.net> has joined #bzflag | 23:52 | |
| *** disco- <disco-!~disco@unaffiliated/disco-> has quit IRC (Remote host closed the connection) | 23:54 | |
| *** Sgeo_ <Sgeo_!~Sgeo@ool-18b982ad.dyn.optonline.net> has quit IRC (Ping timeout: 272 seconds) | 23:55 | |
Generated by irclog2html.py 2.17.3.dev0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!