| Time |
Nick |
Message |
| 02:47 |
|
fluxionary joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 05:16 |
|
jonadab joined #minetest-dev |
| 05:17 |
|
calcul0n joined #minetest-dev |
| 05:48 |
|
sofar joined #minetest-dev |
| 05:48 |
|
sfan5 joined #minetest-dev |
| 05:49 |
|
Krock joined #minetest-dev |
| 05:51 |
|
programmerjake joined #minetest-dev |
| 05:54 |
|
cheapie joined #minetest-dev |
| 07:03 |
|
proller joined #minetest-dev |
| 07:08 |
|
proller joined #minetest-dev |
| 09:06 |
|
Alias joined #minetest-dev |
| 09:49 |
|
Fixer joined #minetest-dev |
| 12:42 |
|
erle joined #minetest-dev |
| 12:58 |
|
erle joined #minetest-dev |
| 13:16 |
|
proller joined #minetest-dev |
| 13:39 |
|
HuguesRoss joined #minetest-dev |
| 13:50 |
Zughy[m] |
wait, wasn't the next meeting planned for today? In the wiki says "2022-??-??" |
| 13:50 |
Zughy[m] |
https://dev.minetest.net/Meetings#2022-.3F.3F-.3F.3F |
| 13:51 |
Zughy[m] |
sorry I meant for the 24th, not for today |
| 13:52 |
Zughy[m] |
https://irc.minetest.net/minetest-dev/2022-04-10#i_5959082 |
| 13:52 |
erle |
today is the ??th day of the ??th month of 2022 you say? |
| 14:02 |
|
erle joined #minetest-dev |
| 14:13 |
|
erle joined #minetest-dev |
| 14:26 |
|
sometalgoo joined #minetest-dev |
| 14:33 |
|
erle joined #minetest-dev |
| 14:39 |
|
fluxionary joined #minetest-dev |
| 15:02 |
|
erle joined #minetest-dev |
| 15:11 |
|
kilbith joined #minetest-dev |
| 15:26 |
|
behalebabo joined #minetest-dev |
| 15:31 |
|
behalebabo joined #minetest-dev |
| 15:40 |
|
kilbith joined #minetest-dev |
| 15:55 |
Baytuch |
Good evening, MineTest devs |
| 17:03 |
|
Desour joined #minetest-dev |
| 18:40 |
|
fluxionary joined #minetest-dev |
| 18:57 |
|
proller joined #minetest-dev |
| 19:17 |
|
proller joined #minetest-dev |
| 19:30 |
|
erle joined #minetest-dev |
| 19:30 |
erle |
uh, so does anyone of you need the 2 unused bits in the plantlike drawtype meshoptions for anything? |
| 19:31 |
erle |
because i just did a lot of work just to get some crops a bit lower and it still does not fully work |
| 19:37 |
erle |
my proposal would be to use at least one bit for a fixed -y offset of 1/16 node and maybe the other one for a -y offset of 2/16. that way, 15/16 14/16 13/16 lowered farming soil could easily (i.e. without nodebox trickery) have plants on it. also the same node could be planted on normal dirt and lowered farmland. |
| 19:37 |
erle |
the current random -y offset is nice for plantlikes on full nodes, but kinda useless if you have a gap below it |
| 19:37 |
erle |
also, my melon and pumpkin stems are now + instead of x because i can't rotate nodeboxes |
| 19:47 |
MTDiscord |
<Jonathon> your not using the right drawtype |
| 19:49 |
|
erle joined #minetest-dev |
| 19:49 |
MTDiscord |
<Jonathon> try "degrotate" |
| 19:55 |
erle |
Jonathon thanks |
| 19:57 |
erle |
Jonathon could you point me to an example of degrotate for nodeboxes? |
| 20:01 |
erle |
Jonathon the documentation says that degrotate is only valid for plantlike and mesh drawtypes. is the documentation lying? |
| 20:05 |
sfan5 |
I just posted on the Irrlicht forum to make them aware of most of the fixes we applied to IrrlichtMt |
| 20:07 |
erle |
nice, show |
| 20:07 |
erle |
pls |
| 20:08 |
erle |
do all their contributors post on a sourceforge forum? i thought they were using mailing lists or something |
| 20:08 |
erle |
or where is it hosted |
| 20:12 |
sfan5 |
its on irrlicht.sourceforge.io |
| 20:14 |
MTDiscord |
<Warr1024> https://irrlicht.sourceforge.io/forum/viewtopic.php?f=2&t=52819 <- nice |
| 20:16 |
|
erle joined #minetest-dev |
| 20:37 |
|
erle joined #minetest-dev |
| 20:47 |
|
erle joined #minetest-dev |
| 21:45 |
erle |
> We forked because waiting for an upstream release to fix many issues that have been plaguing users for years was no longer feasible. |
| 21:45 |
erle |
does irrlicht even make releases? |
| 21:45 |
erle |
like, regularly |
| 21:46 |
MTDiscord |
<Jonathon> no |
| 21:46 |
MTDiscord |
<Jonathon> *releases yes, regularly no |
| 21:46 |
erle |
i mean maybe, just maybe, irrlicht is just a “trunk”-only project now https://irrlicht.sourceforge.io/?cat=9 |
| 21:47 |
sfan5 |
that's missing 1.8.5 |
| 21:47 |
erle |
yeah i noticed |
| 21:51 |
erle |
sfan5 for the core affinity thing, why did you not set the core affinity to the core the task is already running on instead of removing it? or is there more to it than “prevent a spurious thread core switch”? |
| 21:52 |
erle |
(as i said before, the comment in the irrlicht source code is most likely wrong – the thing is for processors that count time differently, not bios bugs) |
| 21:52 |
sfan5 |
you want to know why I removed an obsolete workaround instead of keeping it but mitigating its impact? |
| 21:52 |
erle |
well, it's not obsolete, given that both fleck and me seemed to have multiple machines that have that |
| 21:52 |
sfan5 |
you never mentioned this but I also I don't believe you |
| 22:05 |
|
erle joined #minetest-dev |
| 22:06 |
erle |
sfan5 sorry, my internet is shit. i am going to explain the reason for the workaround now. |
| 22:06 |
erle |
though i am *really* sure i did it before |
| 22:06 |
erle |
maybe not to you |
| 22:07 |
erle |
sfan5 did you read all the windows articles i posted back then when i claimed the thread affinity thing is wrong the first time? |
| 22:08 |
sfan5 |
just explain what you want to explain |
| 22:08 |
|
PrairieWind joined #minetest-dev |
| 22:08 |
|
olliy1or joined #minetest-dev |
| 22:09 |
|
PrairieWind left #minetest-dev |
| 22:10 |
erle |
okay, so as far as i know, this workaround is necessary because some stuff is implemented differently for the TSC register in different processors. the thing originally ticked with every clock cycle, allowing you to make accurate timing measurements. |
| 22:10 |
erle |
when multicore processors came, there was no guarantee that they would tick the same due to powersaving etc. – what if you shut a core down? |
| 22:16 |
|
erle joined #minetest-dev |
| 22:16 |
erle |
so you have basically three possible ways this can go |
| 22:16 |
erle |
1. timing ticks are coupled to clock frequency. this works for time measurements as long as no powersaving is going on. |
| 22:16 |
erle |
2. timing ticks are constant. you can check the processor flags on linux for constant_tsc. this means that *per processor* you can rely on the timing even if there is powersaving going on and the cpu freq is reduced. |
| 22:16 |
erle |
3. tsc is shared between processors in multicore systems. this is the newest, and of course, the thing that makes the workaround not necessary. |
| 22:16 |
erle |
sfan5 as mentioned before, i think you removed that affinity call because it pinned the thread to core 1, regardless if that core was ever the core on which it run before. is that correct? |
| 22:17 |
erle |
as literally *all* of the docs i read say, the correct solution is to pin it to the core it is on, otherwise on multicore systemss your timing is off if the thread switches cores at the right … well, time. |
| 22:17 |
sfan5 |
if you want to say that (recent) windows does anything other than 3 then microsoft's docs contradict you |
| 22:18 |
erle |
no, on linux you can easily figure it out if your system is affected |
| 22:18 |
erle |
look if you have the cpu flag tsc_reliable |
| 22:18 |
erle |
if you do not have it, there is no reliable TSC |
| 22:19 |
sfan5 |
I must have missed the part where we're talking about Linux |
| 22:19 |
MTDiscord |
<Jordach> not my fault you're using nigh on 20 year old hardware |
| 22:19 |
sfan5 |
https://docs.microsoft.com/en-us/windows/win32/sysinfo/acquiring-high-resolution-time-stamps |
| 22:19 |
sfan5 |
if you read this it tells you that windows synchronizes the stuff that QPC is based on |
| 22:19 |
sfan5 |
zero exceptions |
| 22:19 |
erle |
; </proc/cpuinfo grep -o '[^ ]*tsc[^ ]*' |sort |uniq |
| 22:19 |
erle |
constant_tsc |
| 22:19 |
erle |
tsc |
| 22:20 |
sfan5 |
that you found out something about the TSC register is cool and all but the API method does not directly read from there |
| 22:20 |
erle |
linux can tell you if the thing is reliable. i think fleckenstein tried to get minetest run on windows to debug it. if he shows up again, i can ask him. |
| 22:21 |
erle |
hey it says there right on the page |
| 22:21 |
erle |
> Systems with flawed firmware that run these versions of Windows might not provide the same QPC reading on different cores if they used the TSC as the basis for QPC. |
| 22:22 |
sfan5 |
"these versions of Windows" = pre-Vista |
| 22:22 |
sfan5 |
are you trolling? |
| 22:22 |
erle |
the only thing that is bios-relevant here is that windows is stupider than linux |
| 22:22 |
erle |
and asks the bios instead of measuring itself |
| 22:24 |
erle |
anyway, the newest documentation that i could find that said to pin it was from 2018 and the last processor where i was positive that TSC was not synchronized was made around 2016 or so? |
| 22:24 |
sfan5 |
I will trust Microsoft's documentation over you saying you found something somewhere |
| 22:24 |
erle |
regardless, i asked fleck to check that some time back because he had 2 identical systems that did not have reliable timing |
| 22:25 |
erle |
microsofts documentation says you do not *need* to, but everywhere where it talks about multicore, it says you can get wrong measurements |
| 22:25 |
sfan5 |
no it does not |
| 22:26 |
erle |
btw, the info that some processors implement it ”incorrectly” that comes up often is wrong. it is merely that the meaning of some timing stuff (not only TSC) changed over time, especially regarding powerssaving and multicore. |
| 22:27 |
sfan5 |
> Does QPC reliably work on multi-processor systems, multi-core system, and systems with hyper-threading? |
| 22:27 |
sfan5 |
> Yes |
| 22:27 |
sfan5 |
they even added a FAQ entry for people like you who think they are smarter |
| 22:29 |
erle |
obv the correct answer is measuring it |
| 22:29 |
sfan5 |
yes please waste your time with that |
| 22:30 |
erle |
i believe fleck has 2 identical systems that have no invariant TSC and i'll ask about it |
| 22:30 |
MTDiscord |
<Jordach> continue wasting time by chasing shadows |
| 22:31 |
sfan5 |
that's cool but please don't report the results here because an invariant TSC has nothing to do with whether QPC works correctly |
| 22:33 |
erle |
oh i remember again |
| 22:34 |
erle |
forget about it for now. the windows documentation for QPC is most likely wrong, but until you get a test program, you won't believe that. so if i ever bring it up again, it will be with a test program. |
| 22:34 |
|
panwolfram joined #minetest-dev |
| 22:34 |
MTDiscord |
<Jordach> sfan5, i've been working on a mapgen that does a heavy amount of pregeneration at startup |
| 22:35 |
sfan5 |
you can report documentation bugs to microsoft (on github even IIRC), do that first if you find anything |
| 22:37 |
sfan5 |
hmm are you sure a mapgen is supposed to do pregeneration? |
| 22:37 |
MTDiscord |
<Jordach> yes, i've got a river algorithm that behaves fairly realistically that requires a monster startup period |
| 22:37 |
MTDiscord |
<Jordach> https://cdn.discordapp.com/attachments/369137254641303560/965480872792973352/unknown.png |
| 22:39 |
MTDiscord |
<Jordach> runtime generation speed is faster than v7 |
| 22:43 |
erle |
well, microsoft has been claiming that QPC will never return false or 0 on windows XP or later in their FAQ, even though searching for “QueryPerformanceCounter fail” yields accounts of people who not only had that happen, but can exactly say why it happens (QPC needs an *undocumented* 8-byte packing alignment or it fails). |
| 22:44 |
erle |
but as i said, if i come back to this point, it will be with a test program. |
| 22:44 |
erle |
because apparently this is as obscure as the shitty GCC x87 float implementation |
| 22:55 |
erle |
Jordach how far out does the river algorithm precalc stuff? for the whole map? |
| 22:56 |
|
olliy joined #minetest-dev |
| 22:56 |
MTDiscord |
<Jordach> the entire 62km^2 area |
| 22:56 |
MTDiscord |
<Jordach> takes less than a few tens of kb totasl |
| 22:59 |
|
olliy1or joined #minetest-dev |
| 22:59 |
erle |
Jordach is this a heightmap thing? i.e. you need to know where the valleys and hills are? |
| 23:00 |
MTDiscord |
<Jordach> entirely heightmap |
| 23:00 |
MTDiscord |
<Jordach> i also solved the problem that is 20m oceans |
| 23:00 |
MTDiscord |
<Jordach> on average oceans can go for at least 1km to ~24km+ |
| 23:01 |
erle |
well, i bet everyone will just LOVE that |
| 23:01 |
erle |
in fact, i am looking forward to it |
| 23:01 |
MTDiscord |
<Jordach> yeah and the default spawn algo is broken |
| 23:01 |
MTDiscord |
<Jordach> i went back and fixed it |
| 23:01 |
erle |
broken in what way? |
| 23:01 |
MTDiscord |
<Jordach> it only seaches a few km at the world center |
| 23:02 |
erle |
are you saying that there is a huge mountain or ocean there |
| 23:03 |
MTDiscord |
<Jordach> all ocean |
| 23:03 |
erle |
neato |
| 23:03 |
erle |
Jordach so this map generator … is it in the room with us right now? |
| 23:03 |
erle |
where can i get it |
| 23:04 |
MTDiscord |
<Jordach> there's a branch on GH |
| 23:04 |
erle |
link? |
| 23:04 |
MTDiscord |
<Jordach> but beware of the fact that rivergen can get stuck in an infinite loop requiring SIGKILL at the minimum |
| 23:04 |
erle |
uh what |
| 23:04 |
erle |
why |
| 23:05 |
erle |
there ought to be only a finite amount of state |
| 23:05 |
MTDiscord |
<Jordach> sometimes there's a rare occasion where it decides to choose two points that are equi distant with identical height |
| 23:05 |
MTDiscord |
<Jordach> the algo is even simpler than djkistra |
| 23:05 |
erle |
so why is this not detected after a simple back-and-forth? |
| 23:05 |
MTDiscord |
<Jordach> it does detect it and voids the entire river gen |
| 23:05 |
MTDiscord |
<Jordach> i might just break it after x failed iterations |
| 23:07 |
erle |
why void the entire etc. pp. |
| 23:08 |
MTDiscord |
<Jordach> voids that river, not of the 64 |
| 23:08 |
erle |
ok ok |
| 23:08 |
erle |
well that sounds manageable |
| 23:08 |
erle |
like why would anyone care about that one river |
| 23:08 |
erle |
oh yeah, is it deterministic? |
| 23:09 |
MTDiscord |
<Jordach> yes |
| 23:09 |
erle |
nice |
| 23:09 |
MTDiscord |
<Jordach> any more than 64 and the pain of n_rivers^(2^15) happens |
| 23:09 |
erle |
lol |
| 23:09 |
erle |
do you have some writeup on the thing so i don't have to get lost not understanding the code? |
| 23:09 |
erle |
like how you arrived at it |
| 23:11 |
erle |
jordach which branch of https://github.com/jordach/minetest is it? |
| 23:11 |
MTDiscord |
<Jordach> yes |
| 23:11 |
MTDiscord |
<Jordach> have a quick search |
| 23:11 |
erle |
mg_reverb? |
| 23:11 |
MTDiscord |
<Jordach> yes |
| 23:12 |
MTDiscord |
<Jordach> just pay attention to the world co-ords |
| 23:12 |
|
AliasAlreadyTake joined #minetest-dev |
| 23:24 |
erle |
once again i lament that minetest incremental builds are not a thing. :/ |
| 23:25 |
erle |
(branch switch = full rebuild) |
| 23:34 |
erle |
Jordach a full rebuild stopped at shader.cpp.o: mt_opengl.h: No such file or directory |
| 23:35 |
MTDiscord |
<Jordach> builds on my machine |
| 23:36 |
erle |
nvm it was AGAIN the “we don't use submodules here, instead your build randomly breaks” story |
