| Time |
Nick |
Message |
| 00:00 |
|
paradust joined #minetest-dev |
| 00:00 |
|
Pexin joined #minetest-dev |
| 00:00 |
|
Pexin joined #minetest-dev |
| 00:02 |
|
Calinou joined #minetest-dev |
| 00:02 |
|
fossdev2 joined #minetest-dev |
| 00:03 |
|
fluxionary_ joined #minetest-dev |
| 00:11 |
|
MTDiscord joined #minetest-dev |
| 01:41 |
|
YuGiOhJCJ joined #minetest-dev |
| 02:16 |
|
Baytuch joined #minetest-dev |
| 02:41 |
|
Baytuch_2 joined #minetest-dev |
| 03:06 |
|
Baytuch joined #minetest-dev |
| 03:46 |
|
Baytuch joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:22 |
|
erle joined #minetest-dev |
| 04:30 |
|
Baytuch joined #minetest-dev |
| 04:37 |
erle |
<sfan5> we should really have a reference rendering of devtest nodes that can at least be compared manually |
| 04:38 |
erle |
}ah, but why even compare manually? if you do mesa software rendering and output to an uncompressed bitmap, i see no reason why a render for the same circumstances should not be bitwise identical |
| 05:09 |
|
Yad_ joined #minetest-dev |
| 05:21 |
|
olliy joined #minetest-dev |
| 05:31 |
|
Baytuch_2 joined #minetest-dev |
| 05:34 |
|
Baytuch_2 joined #minetest-dev |
| 05:51 |
|
Baytuch joined #minetest-dev |
| 05:52 |
|
calcul0n_ joined #minetest-dev |
| 06:58 |
sfan5 |
you see no reason why something as complex as OpenGL rendering would not be deterministic even if done in software, really? |
| 08:05 |
|
cranezhou joined #minetest-dev |
| 08:35 |
erle |
oh, i bet there exist tons of reasons why stuff could not be deterministic – especially in minetest. but i believe that outside very carefully considered situations, rendering a static scene in a non-deteministic way is most likely a programming error. |
| 08:36 |
erle |
in fact, while openGL rendering is not pixel exact between different GPUs, i would be surprised if mesa would accept if their software renderer behaved in random ways. |
| 08:37 |
erle |
and if i am not mistaken, software rendering is taken as a baseline to verify hardware implementations |
| 08:38 |
erle |
anyways, on the same hardware with the same drivers and inputs i fully expect openGL rendering to give me the same result for the same inputs, every time |
| 08:42 |
|
x2048 joined #minetest-dev |
| 08:42 |
erle |
and by “same inputs” i mean stuff like “mesa uses a 16-bit depth buffer by default, but the dev expected a 32-bit one” |
| 08:42 |
x2048 |
Merging #12558 in 2 min |
| 08:42 |
ShadowBot |
https://github.com/minetest/minetest/issues/12558 -- Offset cuboid origin after scaling the cuboid. by x2048 |
| 08:43 |
erle |
(a wrongly-sized depth buffer will lead to issues, but it will be the same issues every time) |
| 08:48 |
x2048 |
Merged now |
| 09:59 |
|
HuguesRoss6 joined #minetest-dev |
| 10:10 |
|
lakeotp joined #minetest-dev |
| 10:47 |
|
kilbith joined #minetest-dev |
| 11:28 |
|
Baytuch joined #minetest-dev |
| 11:40 |
|
cranezhou joined #minetest-dev |
| 11:41 |
|
x2048 joined #minetest-dev |
| 12:03 |
|
appguru joined #minetest-dev |
| 12:32 |
|
Taoki joined #minetest-dev |
| 13:21 |
ROllerozxa |
is there anywhere in the main menu where the settings with the key type show up other than the hardcoded change keys dialog? |
| 13:22 |
erle |
ROllerozxa what is your reason for the query? |
| 13:32 |
|
Fixer joined #minetest-dev |
| 13:35 |
ROllerozxa |
lol yeah I probably should start from that angle. the generate_from_settingtypes.lua script includes titles and descriptions for settings with the 'key' type in settings_translation_file.cpp. however the advanced settings menu excludes 'key' type settings, and the change keys dialog use their own strings. so from what I can see these strings go completely unused outside of minetest.conf.example, but still get translated which is a bit of a |
| 13:35 |
ROllerozxa |
waste (~100 unused translation strings) |
| 13:36 |
ROllerozxa |
so basically, 'else' => 'elseif entry.type ~= "key" then' @ builtin/mainmenu/generate_from_settingtypes:112 |
| 13:43 |
|
appguru joined #minetest-dev |
| 13:50 |
|
appguru1 joined #minetest-dev |
| 14:49 |
|
Baytuch joined #minetest-dev |
| 15:03 |
|
Baytuch joined #minetest-dev |
| 15:22 |
|
proller joined #minetest-dev |
| 15:40 |
|
proller joined #minetest-dev |
| 15:49 |
|
Baytuch joined #minetest-dev |
| 16:41 |
|
x2048 joined #minetest-dev |
| 16:53 |
|
jwmhjwmh joined #minetest-dev |
| 16:55 |
|
Fixer joined #minetest-dev |
| 17:26 |
|
x2048 joined #minetest-dev |
| 18:14 |
kilbith |
I've got around a much simpler implementation of `core.wrap_text`: http://codepad.org/8jcrG48f |
| 18:14 |
kilbith |
bonus: it's UTF-8 aware |
| 18:14 |
kilbith |
Luatic ^ |
| 18:19 |
MTDiscord |
<luatic> kilbith: you don't need the brackets around the pattern |
| 18:21 |
x2048 |
Merging #12560 in a few minutes |
| 18:21 |
ShadowBot |
https://github.com/minetest/minetest/issues/12560 -- Restore flags texture to fix interlaced stereo mode by x2048 |
| 18:23 |
MTDiscord |
<luatic> kilbith: I highly doubt that your implementation could be used as a drop-in replacement for core.wrap_text |
| 18:23 |
kilbith |
core.wrap_text has more parameters, so indeed no |
| 18:24 |
kilbith |
hmm no |
| 18:24 |
kilbith |
it doesn't have |
| 18:24 |
MTDiscord |
<luatic> it doesn't have what? |
| 18:24 |
kilbith |
mind performing some tests? |
| 18:24 |
kilbith |
more parameters |
| 18:25 |
MTDiscord |
<luatic> table.insert(buf, j + 1, "\n") definitely seems fishy to me |
| 18:26 |
kilbith |
it's religion, not science until you perform some actual testing |
| 18:27 |
x2048 |
...done |
| 18:27 |
MTDiscord |
<luatic> first you have to define what you want your line wrapping to do :P |
| 18:28 |
MTDiscord |
<luatic> also why are you only checking against " " (ASCII space) rather than all forms of spacing (%s pattern item) |
| 18:28 |
kilbith |
... wrapping |
| 18:28 |
kilbith |
yeah, right |
| 18:29 |
kilbith |
in the real world you meet 99% of the time a ASCII space tho |
| 18:29 |
MTDiscord |
<luatic> anyways gtg |
| 18:29 |
kilbith |
but you're right that it doesn't cost much more to check against %s |
| 18:34 |
kilbith |
btw current wrap_text checks against " " as well |
| 19:44 |
|
olliy joined #minetest-dev |
| 20:16 |
|
Baytuch joined #minetest-dev |
| 20:55 |
|
YuGiOhJCJ joined #minetest-dev |
| 21:04 |
|
Baytuch joined #minetest-dev |
| 21:31 |
rubenwardy |
argh, I want 5.6.0 to be over already |
| 21:45 |
|
Baytuch joined #minetest-dev |
| 21:52 |
|
Baytuch joined #minetest-dev |
| 22:02 |
|
YuGiOhJCJ joined #minetest-dev |
| 22:34 |
|
panwolfram joined #minetest-dev |
| 22:59 |
|
Baytuch joined #minetest-dev |
| 23:09 |
|
Baytuch joined #minetest-dev |
| 23:59 |
|
YuGiOhJCJ joined #minetest-dev |
