| 00:19.11 | Juesto | What |
| 00:25.54 | the_map | 3 is .:_ , 12 is .::._ , 42 is :_: , and 7 is -_- |
| 00:47.02 | Juesto | and i dont really care about open source as long its free |
| 01:02.27 | the_map | oh...those numbers aren't free |
| 01:09.49 | Juesto | nono |
| 01:09.51 | Juesto | about software |
| 01:09.54 | Juesto | stop sarcasm |
| 01:52.52 | *** part/#bzflag Juesto (juest@unaffiliated/juest) |
| 02:07.36 | *** join/#bzflag Void7 (~NULL@205.157.147.198) |
| 02:52.26 | Delusional | the way to find out whatâs sent as a mesh, and what isnât, is to do a /saveworld and check the output. In my experience a box will save as a box if you keep to the four properties mentioned in the bzw manpage: name position,size, rotation. When you add even âcolorâ to the objectâs definition, it will save as a meshbox. |
| 02:52.31 | Delusional | <PROTECTED> |
| 02:53.56 | Delusional | I havenât checked, but assume the pyramid, cone, sphere, tetra objects will behave the same way. |
| 02:54.59 | Delusional | they have more possible properties mentioned in the manpage, and will save az BZ_objects, but add a matref and theyâll be sent sas meshes |
| 05:08.23 | *** join/#bzflag Gnurdux (~Michael@c-73-149-20-29.hsd1.ma.comcast.net) |
| 06:28.12 | *** join/#bzflag dngor (~abuse@p3m/dngor) |
| 08:03.24 | *** join/#bzflag zuii (~cauchy@BC06BF93.catv.pool.telekom.hu) |
| 10:59.36 | blast007 | Delusional: that doesn't mean that they're sent as a "meshbox" object over the wire. They're sent as an arc obstacle with only 4 divisions. And the same for meshpyr (it's sent as a cone with 4 divisions). There is probably some magic added along with it so that BZFlag can actually spit that back out. The "meshbox" and "meshpyr" are only ever used (besides documentation/comments) in a single file in bz |
| 10:59.42 | blast007 | fs a single time each. |
| 13:38.07 | *** join/#bzflag zuii (~cauchy@BC06BF93.catv.pool.telekom.hu) |
| 14:19.04 | *** join/#bzflag Void7 (~NULL@205.157.147.198) |
| 14:22.49 | *** join/#bzflag KaadmY (uid135503@gateway/web/irccloud.com/x-dkaqclfaugauxqek) |
| 14:53.53 | *** join/#bzflag Void7 (~NULL@205.157.147.198) |
| 15:38.38 | *** join/#bzflag Void7 (~NULL@205.157.147.198) |
| 17:39.05 | *** join/#bzflag Juesto (juest@unaffiliated/juest) |
| 17:39.33 | Juesto | the prompt in the bottom of the console is too small with profont |
| 17:39.53 | Juesto | if i increase the font size from that point it begins to have a vertical spacing |
| 17:45.17 | *** join/#bzflag zuii (~cauchy@BC06BF93.catv.pool.telekom.hu) |
| 18:54.38 | *** join/#bzflag Void7 (~NULL@205.157.147.198) |
| 19:01.40 | echelon | i can't do anymore jumps to the base with my new geforce gtx 960 :/ |
| 19:02.21 | echelon | also, why does it take so long to burrow |
| 19:02.44 | echelon | is that a bug for people with high fps? |
| 19:04.56 | blast007 | yes, our physics system sucks. turn on energy saver and /localset fpsLimit 200 |
| 19:05.28 | blast007 | or maybe even 150, forget what I use |
| 19:21.52 | echelon | cool thx |
| 19:34.54 | Juesto | echelon: burrow is a setting, and you gotta jump slow |
| 19:35.17 | echelon | huh |
| 19:35.30 | Juesto | burrow speed is actually a server variable |
| 19:35.38 | echelon | oh |
| 19:36.00 | Juesto | about jumps jump slow |
| 19:36.07 | Juesto | go slow to jump* |
| 19:36.20 | echelon | but i've noticed a significant variation between different graphics cards |
| 19:36.30 | Juesto | then use vsync |
| 19:36.43 | Juesto | what's the engine fps? |
| 19:37.06 | echelon | on my hud, it shows 800-1100 |
| 19:37.48 | Juesto | i mean, at how many fps is the engine designed to be run |
| 19:37.57 | Juesto | blast007 ^ |
| 19:38.51 | blast007 | designed to be run? that implies there was any kind of planning or thought put into that at all |
| 19:39.24 | blast007 | it was designed to be run on an SGI workstation running IRIX |
| 19:39.29 | Juesto | you dont undestand the question? |
| 19:39.51 | blast007 | I understand the question, but you don't understand the history of this project |
| 19:39.56 | Juesto | Yeah i dont |
| 19:40.04 | Juesto | surprise me! |
| 19:40.45 | blast007 | there's just a bunch of stuff through into a codebase and held together with scotch tape and chewing gum |
| 19:42.03 | Juesto | why sarcasm |
| 19:42.25 | KaadmY | Juesto: he isn't joking |
| 19:42.37 | KaadmY | although it's not scotch tape and chewing gum exactly |
| 19:43.40 | Juesto | yeah... sarcasm != joke |
| 19:44.36 | KaadmY | Juesto: have you tried modifying bzflag's code? |
| 19:44.41 | KaadmY | because then you'll understand |
| 19:44.52 | Juesto | i dont know c++ |
| 19:45.45 | KaadmY | Juesto: then bzflag's code won't help you :) |
| 19:46.01 | Juesto | Oh well |
| 19:54.43 | the_map | it makes the about same amount of sense whether or not you know c++ |
| 19:55.11 | Juesto | dont have time to look at the code |
| 20:02.35 | *** join/#bzflag Void7 (~NULL@205.157.147.198) |
| 20:10.47 | macsforme | Juesto: while you are technically correct about burrow speed, your response was irrelevant to the actual issue he was experiencing, which is a known issue and requires a framerate reduction to correct |
| 20:11.06 | Juesto | Oh okay |
| 20:11.26 | Juesto | macsforme: hence i wonder about at what fps is the engine designed for |
| 20:11.32 | Juesto | too fast = glitchfest |
| 20:12.14 | macsforme | I have no idea what kind of framerate machines could put out when bzflag was first written, but I'm confident that nobody predicted it would be an issue |
| 20:12.38 | macsforme | echelon: try setting energy saver to vertical sync, too... if you can live with that level of responsiveness, that is probably the best way to get smooth rendering |
| 20:13.01 | Juesto | (re-volt is designed to run at 125fps) |
| 20:31.20 | blast007 | probably floating point inaccuracies |
| 20:31.39 | DTRemenak | bzflag's framerate on SGI boxen tended to be 15-30 fps. theoretically it shouldn't have a lot of problems until somewhere around 1000fps, where dt gets too small and float math starts diverging |
| 20:32.55 | blast007 | physics issues start well before 1000 FPS |
| 20:33.47 | Juesto | SGI boxen was the original system it was desgined on, right? |
| 20:34.21 | DTRemenak | blast007: wasn't saying they didn't, just that they shouldn't ;) |
| 20:34.26 | blast007 | "<@blast007> it was designed to be run on an SGI workstation running IRIX" |
| 20:34.47 | blast007 | https://wiki.bzflag.org/Project_History |
| 20:36.45 | DTRemenak | if bzflag had been fairly carefully designed with float math in mind, we'd still start having problems around 1000 fps. it wasn't, so I'm sure there's something stupid that's causing problems earlier. |
| 20:38.53 | DTRemenak | there are several possible ways to address it, too...find out what we're doing that's stupid, globally increase precision, or run physics cycles on a separate timer from drawing cycles. or just force vsync since there's no point in drawing that many frames anyway. |
| 20:40.06 | KaadmY | blast007: i've had burrow problems at 200 fps before |
| 20:40.17 | KaadmY | (on a different machine though..) |
| 20:40.44 | blast007 | I have my limit set to 160, it seems |
| 20:43.58 | macsforme | as long as the framerate is tied to other things, like input polling, there is a legitimate need to run the game at a faster framerate than the typical vsync of 60 |
| 20:44.29 | Juesto | Which is the stability maximium then? |
| 20:44.32 | macsforme | the difference in responsiveness between, say, 60 and 120, is very pronounced |
| 20:44.57 | Juesto | Of course |
| 20:45.06 | Juesto | but up to what point it can go |
| 20:49.22 | macsforme | no single perfect number has been found... there are tradeoffs whichever way you go |
| 20:52.54 | *** join/#bzflag zuii (~cauchy@BC06BF93.catv.pool.telekom.hu) |
| 20:53.26 | Juesto | a limit should be there by default |
| 20:54.32 | blast007 | the game should work correctly by default |
| 20:54.41 | blast007 | but there's a lot of things that don't |
| 20:57.30 | *** join/#bzflag zuii (~cauchy@BC06BF93.catv.pool.telekom.hu) |
| 20:58.17 | Juesto | workaround/fix for it? |
| 21:01.49 | macsforme | as we have told you multiple times, we are putting all current effort into the remake project |
| 21:02.26 | Juesto | Ok |
| 21:02.33 | Juesto | i forgot the channel |
| 21:03.37 | Juesto | the new project should be on /topic really |
| 21:06.01 | macsforme | public announcements will come when they are appropriate... for example, when there is an actual finished project proposal for people to look at |
| 21:08.50 | Juesto | I am intersted in the planning. |
| 21:21.11 | blast007 | no you're not |
| 21:53.13 | DTRemenak | huh, as I calculate it it, the core problem with burrow (and falling in general) is actually that lower framerates fall too fast...assuming 0.5 seconds at 100 fps, you fall 1.24 units, and in the same 0.5 seconds at 10 fps, you fall 1.47 units. Correct value is 1.22 units. |
| 21:53.30 | DTRemenak | Burrow is worse because it's faster than just falling (there's a factor of 4 in there) |
| 21:54.22 | DTRemenak | we're using instantaneous velocity at the end of frame to calculate a position update, when we should be using average velocity over the course of the frame. notably, non-vertical acceleration does not have this problem (just falling). |
| 21:58.29 | DTRemenak | (and whoever decided that burrow should be accelerated should have their head examined...what kind of machine burrows faster the deeper it gets??) |
| 22:02.37 | the_map | thanks for the riddle DTRemenak |
| 22:02.39 | the_map | :) |
| 22:09.48 | the_map | ok...I give up |
| 22:17.13 | *** join/#bzflag zuii (~cauchy@BC06BF93.catv.pool.telekom.hu) |
| 22:18.14 | Juesto | LOL! |
| 23:51.44 | *** join/#bzflag Void7 (~NULL@205.157.147.198) |