| Time |
Nick |
Message |
| 00:39 |
|
v-rob joined #minetest-dev |
| 00:40 |
|
Extex joined #minetest-dev |
| 01:10 |
Calinou |
<exe_virus> hence why the noise based system is novel and a decent idea |
| 01:10 |
Calinou |
just saying, but Minetest had noise-based farmap previews back in 0.2-0.3.1 in mid-2011 :) |
| 01:10 |
Calinou |
it worked decently, it displayed tree coverage but was fairly costly and didn't look voxel-like (it used flat-shaded polygons and billboard sprites for trees). celeron55 did another attempt in 2013-2014 where large voxels were rendered far away (say, 4×4×4) based on noise too. Original node textures were used, so it looked more accurate |
| 01:14 |
Calinou |
you can test it by running https://www.moddb.com/games/minetest/downloads/minetest-031 (in WINE if you're on Linux) |
| 01:14 |
Calinou |
had to dig a bit to find a Minetest 0.3.1 precompiled download, that seems to be legit |
| 01:15 |
Calinou |
run the game once, exit it, add `enable_farmesh = true` to minetest.conf, then run it again |
| 01:15 |
Calinou |
it looks like this: https://0x0.st/-Lw2.png |
| 01:15 |
v-rob |
http://packages.8dromeda.net/minetest/minetest_old_releases_2010_through_2012_mostly_win32/ is a more official place to get old releases |
| 01:15 |
Calinou |
ah, nice |
| 01:18 |
Calinou |
and yeah, enabling farmesh increases drawtime from 6 to 30, even at small window sizes, so it's likely draw call-constrained |
| 02:58 |
MTDiscord |
<exe_virus> Oh interesting, I figured we would render with the billboards and 2d sprites and just haze-blur it |
| 02:59 |
MTDiscord |
<exe_virus> That's much more detail and yeah only something like Vulcan would be able to handle that many draw calls I suspect |
| 03:03 |
|
v-rob joined #minetest-dev |
| 03:09 |
|
olliy joined #minetest-dev |
| 03:23 |
|
kilbith joined #minetest-dev |
| 04:17 |
|
v-rob joined #minetest-dev |
| 04:23 |
kilbith |
scrollbar customization: https://github.com/minetest/minetest/pull/11345 |
| 04:23 |
|
\c joined #minetest-dev |
| 05:03 |
kilbith |
v-rob: you there? |
| 05:03 |
v-rob |
Yeah, but only for a little longer |
| 05:04 |
kilbith |
okay, should scrollbaroptions[] be transfered to style[] and marked as deprecated? |
| 05:05 |
kilbith |
that'd make sense for me |
| 05:08 |
v-rob |
scrollbaroptions[] exists as a hack from before formspec versioning, since formspec elements could not have new arguments added to them. |
| 05:08 |
kilbith |
so what's your take about it now? |
| 05:09 |
kilbith |
well, these options aren't really about styling either... |
| 05:10 |
v-rob |
I know at least rubenwardy thought that it shouldn't be part of style (for instance, https://github.com/minetest/minetest/pull/8530#issuecomment-531495972), and I agree since it really doesn't have much to do with style. If anywhere, I think it would be better to integrate it into scrollbar[] where it would properly belong (with or without named arguments, IDK) |
| 05:10 |
kilbith |
except arrows=<show/hide/default> |
| 05:10 |
v-rob |
Arrows are styling, definitely |
| 05:10 |
kilbith |
so, transfer? |
| 05:11 |
v-rob |
Transfer arrows to style, but nothing else I think |
| 05:12 |
v-rob |
I guess thumbsize could theoretically be style |
| 05:12 |
kilbith |
yep |
| 05:12 |
v-rob |
And maybe the steps, but that's somewhat of a stretch |
| 05:13 |
v-rob |
Min and max, certainly not in style[] |
| 05:13 |
v-rob |
But yeah, for now deprecate the styling parts and move them to style. Other core devs can give their input when they're on |
| 05:14 |
kilbith |
also, basically, arrow up/down should support all the properties of button[] ? |
| 05:15 |
v-rob |
Yeah, that's where a pseudo-selector would come in handy. Such as `style_type[scrollbar::up_arrow:hover;fgimg=koolstof.png]` |
| 05:15 |
v-rob |
It would probably be implemented similarly to states if anything |
| 05:16 |
kilbith |
hmm, let's see |
| 05:16 |
kilbith |
the real deal would be a new syntax for formspecs |
| 05:17 |
v-rob |
Ugh, yeah. I'm really loathing Irrlicht's bug right now. I can't find where Minetest relies on the buggy behaviour. |
| 05:18 |
v-rob |
Anyhow, I've got to leave now, sorry. It's very late here. |
| 05:19 |
kilbith |
thanks for the feedbacks |
| 05:27 |
|
\c joined #minetest-dev |
| 06:02 |
|
BuckarooBanzai joined #minetest-dev |
| 06:10 |
|
kilbith joined #minetest-dev |
| 06:14 |
|
v-rob joined #minetest-dev |
| 06:24 |
|
kilbith joined #minetest-dev |
| 06:33 |
|
kilbith joined #minetest-dev |
| 08:00 |
|
specing_ joined #minetest-dev |
| 08:24 |
|
tech_exorcist joined #minetest-dev |
| 09:03 |
|
tech_exorcist joined #minetest-dev |
| 09:04 |
|
calcul0n_ joined #minetest-dev |
| 09:17 |
|
Fixer joined #minetest-dev |
| 10:05 |
|
entuland joined #minetest-dev |
| 10:06 |
|
book` joined #minetest-dev |
| 11:24 |
|
tech_exorcist joined #minetest-dev |
| 12:14 |
|
olliy joined #minetest-dev |
| 12:46 |
|
\c joined #minetest-dev |
| 13:39 |
|
Lone_Wolf joined #minetest-dev |
| 13:44 |
|
nrz joined #minetest-dev |
| 14:01 |
|
freshreplicant[m joined #minetest-dev |
| 14:07 |
|
wsor4035 joined #minetest-dev |
| 14:45 |
|
Fixer joined #minetest-dev |
| 15:04 |
|
appguru joined #minetest-dev |
| 15:20 |
|
nrz joined #minetest-dev |
| 15:41 |
|
Extex joined #minetest-dev |
| 16:37 |
MTDiscord |
<exe_virus> Is the PsuedoRandom class we use in the engine faster than the PcgRandom class? I.e. does it generate numbers faster? |
| 16:44 |
|
CeeGee joined #minetest-dev |
| 16:50 |
|
pmp-p joined #minetest-dev |
| 16:52 |
sfan5 |
it does less operations, so probably? |
| 17:11 |
|
Extex joined #minetest-dev |
| 18:21 |
|
AntumDeluge joined #minetest-dev |
| 18:24 |
|
Extex joined #minetest-dev |
| 18:27 |
|
Extex joined #minetest-dev |
| 19:55 |
|
queria joined #minetest-dev |
| 20:01 |
|
specing_ joined #minetest-dev |
| 21:03 |
|
v-rob joined #minetest-dev |
| 21:15 |
MTDiscord |
<exe_virus> I tested on windows, 64 bit, -O3 release, got slower times with PCG so yep, psuedo is faster, all good |
| 23:01 |
|
jonadab joined #minetest-dev |
| 23:19 |
|
three joined #minetest-dev |
