| Time |
Nick |
Message |
| 00:50 |
|
YuGiOhJCJ joined #minetest-dev |
| 02:30 |
|
SFENCE joined #minetest-dev |
| 03:05 |
|
SFENCE joined #minetest-dev |
| 03:06 |
|
v-rob joined #minetest-dev |
| 03:24 |
|
SFENCE joined #minetest-dev |
| 03:48 |
|
SFENCE joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:31 |
|
SFENCE joined #minetest-dev |
| 04:49 |
|
v-rob joined #minetest-dev |
| 05:05 |
|
SFENCE joined #minetest-dev |
| 05:06 |
|
hlqkj joined #minetest-dev |
| 05:16 |
|
SFENCE joined #minetest-dev |
| 05:38 |
|
SFENCE joined #minetest-dev |
| 06:08 |
|
SFENCE joined #minetest-dev |
| 06:30 |
MTDiscord |
<cvcvcvcvcvcvcvcvcvcvcvcvcvcvcv> sfan5: Your code didnt compile btw, just pinging you incase ur on |
| 06:30 |
MTDiscord |
<cvcvcvcvcvcvcvcvcvcvcvcvcvcvcv> Im going to juse use a c++ template enable_if, which does the job similar to your weird [[maybe_unused]] hack |
| 06:31 |
MTDiscord |
<cvcvcvcvcvcvcvcvcvcvcvcvcvcvcv> also im pretty sure there are specified type intrinsics for char array types |
| 06:32 |
MTDiscord |
<cvcvcvcvcvcvcvcvcvcvcvcvcvcvcv> Oh, and if you're bored, take a look at the video in #15221. I copied it from Osu! but i wasn't sure if everyone was going to like it. |
| 06:32 |
ShadowBot |
https://github.com/minetest/minetest/issues/15221 -- [DRAFT] Smooth Scrollbar improvements and Elastic scrolling by swagtoy |
| 06:33 |
MTDiscord |
<cvcvcvcvcvcvcvcvcvcvcvcvcvcvcv> or https://files.catbox.moe/krmg8x.mp4 |
| 06:49 |
|
fluxionary joined #minetest-dev |
| 06:54 |
|
SFENCE joined #minetest-dev |
| 07:15 |
|
SFENCE joined #minetest-dev |
| 09:01 |
MTDiscord |
<nrz0> hello, merging #15207 |
| 09:01 |
ShadowBot |
https://github.com/minetest/minetest/issues/15207 -- Network: offload often changed constants to source file by SmallJoker |
| 09:03 |
|
YuGiOhJCJ joined #minetest-dev |
| 11:14 |
|
MTDiscord joined #minetest-dev |
| 12:36 |
pgimeno |
it strikes me as odd that *_PROTOCOL_VERSON_MAX was renamed to LATEST_PROTOCOL_VERSION yet *_PROTOCOL_VERSION_MIN was not renamed to something like e.g. EARLIEST_SUPPORTED_PROTOCOL_VERSION |
| 12:37 |
pgimeno |
it makes code that uses *_PROTOCOL_VERSION_MIN and LATEST_PROTOCOL_VERSION harder to understand |
| 12:37 |
pgimeno |
pinging Krock ^ |
| 13:09 |
|
MTDiscord joined #minetest-dev |
| 14:09 |
|
behalebabo joined #minetest-dev |
| 15:19 |
|
hwpplayer1 joined #minetest-dev |
| 15:24 |
|
v-rob joined #minetest-dev |
| 15:51 |
|
v-rob joined #minetest-dev |
| 16:05 |
Mantar |
min/latest? sounds normal for minetest, where we don't use over/under or above/below, but instead do above/under |
| 16:45 |
MTDiscord |
<warr1024> Also extra points for switching from THING_MIN/THING_MAX to MOST_THING/LEAST_THING to ensure that THING-related things don't lexically sort near one another. |
| 16:48 |
Krock |
pgimeno: I chose to pick what resulted in the least changed lines. Thing is that min and max are both subject to the handshake between server and client |
| 16:51 |
Krock |
I intentionally kept the PR open for a few days to collect feedback |
| 16:53 |
Krock |
yours is one way to look at it. I think that "latest" does express very well that it equals the current development progress, whereas "max" can be rather seen as a hard limit; and not a variable that is changed twice or three times a year |
| 16:57 |
|
hwpplayer1 joined #minetest-dev |
| 17:12 |
|
Noisytoot joined #minetest-dev |
| 17:15 |
MTDiscord |
<cvcvcvcvcvcvcvcvcvcvcvcvcvcvcv> sfan5: are you there? |
| 17:15 |
MTDiscord |
<cvcvcvcvcvcvcvcvcvcvcvcvcvcvcv> wondered if you could help me live with your suggestion |
| 17:30 |
Krock |
probably just afk. |
| 17:31 |
MTDiscord |
<cvcvcvcvcvcvcvcvcvcvcvcvcvcvcv> sfan5bros..... we lost .... |
| 17:31 |
MTDiscord |
<cvcvcvcvcvcvcvcvcvcvcvcvcvcvcv> drop your stocks... |
| 18:20 |
|
ivanbu joined #minetest-dev |
| 18:21 |
|
Desour joined #minetest-dev |
| 18:46 |
|
v-rob joined #minetest-dev |
| 18:59 |
|
SFENCE joined #minetest-dev |
| 19:16 |
|
SFENCE joined #minetest-dev |
| 19:35 |
|
v-rob joined #minetest-dev |
| 19:55 |
|
mertgor joined #minetest-dev |
| 20:03 |
|
hwpplayer1 joined #minetest-dev |
| 21:06 |
|
v-rob joined #minetest-dev |
| 21:41 |
|
YuGiOhJCJ joined #minetest-dev |
| 21:41 |
|
hwpplayer1 joined #minetest-dev |
| 22:12 |
|
hwpplayer1 joined #minetest-dev |
| 22:32 |
|
panwolfram joined #minetest-dev |
| 22:33 |
|
Noisytoot joined #minetest-dev |
| 22:42 |
|
hwpplayer1 joined #minetest-dev |
| 23:05 |
|
Eragon joined #minetest-dev |
| 23:15 |
MTDiscord |
<andrey2470t> Can still anybody review and test #15061 please? I've made a few changes in the PR and that gave a much higher gain in the performance than as it was before. Generally, the reason was in the bad batching by texture within mapblock and also I took away the grouping the buffers in the ClientMap::renderMap() by a mistake. So that created a big count of unnecessary textures switches and multiple of buffers. |
| 23:15 |
ShadowBot |
https://github.com/minetest/minetest/issues/15061 -- Texture atlas for mapblocks meshes by Andrey2470T |
| 23:18 |
MTDiscord |
<andrey2470t> Now with the view range = 190 and with all disabled visual effects, I get at middle 380-430 FPS and 1-2 drawtime against 120-170 with the drawtime in dozens of milliseconds |
| 23:19 |
MTDiscord |
<andrey2470t> If there are no transparent blocks around, I can get even until 480 in the best case |
| 23:28 |
|
Noisytoot joined #minetest-dev |
