| Time |
Nick |
Message |
| 04:54 |
|
SpeedProg joined #minetest-dev |
| 07:04 |
|
EdB joined #minetest-dev |
| 08:02 |
|
PilzAdam joined #minetest-dev |
| 10:10 |
|
saschaheylik joined #minetest-dev |
| 10:26 |
|
VanessaE joined #minetest-dev |
| 10:27 |
|
PilzAdam joined #minetest-dev |
| 14:18 |
|
Calinou joined #minetest-dev |
| 15:13 |
|
Mikeonline joined #minetest-dev |
| 15:24 |
|
rubenwardy joined #minetest-dev |
| 15:31 |
|
hmmmm joined #minetest-dev |
| 16:15 |
|
EdB joined #minetest-dev |
| 16:40 |
|
rubenwardy1 joined #minetest-dev |
| 16:48 |
|
rubenwardy joined #minetest-dev |
| 17:43 |
hmmmm |
alright |
| 17:43 |
hmmmm |
i'll try highlighting him |
| 17:44 |
hmmmm |
celeron55_: what is the rationale behind making datatypes in noise double instead of float? why do you add 0.5 to the X,Y position in noise2d_perlin calls? |
| 17:45 |
celeron55_ |
the addition is because otherwise the nouse would be always zero at zero |
| 17:45 |
celeron55_ |
noise* |
| 17:45 |
celeron55_ |
or something like that |
| 17:46 |
celeron55_ |
dunno about the doubles |
| 17:46 |
celeron55_ |
it probably doesn't make much of a difference |
| 18:04 |
|
rubenwardy left #minetest-dev |
| 18:05 |
hmmmm |
it does make a difference, if they're floats i can get twice as much throughput |
| 18:06 |
hmmmm |
also, the noise at 0 won't be 0 unless the seed were 0 |
| 18:06 |
hmmmm |
according to noise2d() |
| 18:09 |
celeron55_ |
haven't touched it in a good while; i guess you might know better |
| 18:10 |
hmmmm |
yes i've decided that no matter how the mapgen is redone it's going to take a lot of perlin calls |
| 18:10 |
hmmmm |
so the focus right now is on SSE-ifying the perlin noise |
| 18:13 |
hmmmm |
it might be cleaner to divide this up into perlin_asm_msvc.c and perlin_asm_gcc.c, and which file is added is chosen in the makefile |
| 18:40 |
hmmmm |
this is just a misc. problem that should not exist |
| 18:41 |
hmmmm |
1 * 4096 + 2048 = 2 * 4096 - 2048 |
| 18:41 |
hmmmm |
you know, if y = 1, or y = 2, and x = 2048, or x = -2048 |
| 18:41 |
hmmmm |
blocks can be replaced |
| 18:42 |
VanessaE |
especially if the server's HDD runs out of space. |
| 18:42 |
hmmmm |
this doesn't have to do with that |
| 18:42 |
hmmmm |
anyway this could be fixed by treating the LBA as a 48-bit field of 16 bit unsigned integers |
| 18:42 |
VanessaE |
oh, sounded like our previous convo. |
| 18:44 |
celeron55_ |
hmmmm: i'd imagine making a perlin noise implementation that is built from the ground up to make arbitrary chunks of noise would work well |
| 18:44 |
celeron55_ |
hmmmm: the current one calculates the same things again and again |
| 18:45 |
hmmmm |
i reckon you can fix this without any negative side effects by changing getBlockAsInteger to (sqlite3_uint64)((sqlite3_uint64)p.Z << 32) | ((sqlite3_uint64)p.Y << 16) | ((sqlite3_uint64)p.X << 0)); |
| 18:45 |
hmmmm |
(and getIntegerAsBlock too for that matter) |
| 18:47 |
celeron55_ |
also, no assembly; C is close enough to that |
| 18:47 |
hmmmm |
assembly is necessary here |
| 18:47 |
celeron55_ |
(C is a cross-platform macro assembler) |
| 18:47 |
hmmmm |
it's easy enough to fall back on C if the assembly isn't supported |
| 18:47 |
hmmmm |
so i don't see why not |
| 18:48 |
celeron55_ |
yeah and work unpleasantly slow? |
| 18:48 |
celeron55_ |
you'd need to make an ARM one at least too |
| 18:48 |
celeron55_ |
and then what about clang? |
| 18:48 |
hmmmm |
clang supports GCC-style inline assembly |
| 18:48 |
hmmmm |
as does ICC |
| 18:49 |
hmmmm |
this would be nothing but a strict speed _increase_ |
| 18:49 |
hmmmm |
ARM wouldn't be unpleasantly slow, it'll just be normal, and the x86 version would be really fast |
| 18:49 |
celeron55_ |
anyway, the current implementation "polls" each noise position from the noise functions for a big chunk; it could just calculate each noise level one time, buffer them and then add the buffers |
| 18:49 |
hmmmm |
I can do NEON too, I won't really be able to test it well though. |
| 18:49 |
celeron55_ |
it'd take out SO many calculations |
| 18:53 |
hmmmm |
definitely, the entire thing is getting a redesign to be the most optimal |
| 18:55 |
celeron55_ |
if it ends up good, then maybe 3d noise could be used for generation again without some silly tricks |
| 18:55 |
hmmmm |
i am already using 3d noise for Nether and Aether biomes |
| 18:56 |
hmmmm |
so it's an absolute must to get 3d perlin noise in a good state |
| 18:57 |
celeron55_ |
you'd get more bang for the effort by adding Lua APIs for bulkier generation of things |
| 18:58 |
hmmmm |
what, the biomes? |
| 18:58 |
hmmmm |
i guess, i'd rather just have it in C for now so there's no performance problem from the start |
| 19:00 |
celeron55_ |
but that is basically uneditable for most people, which is kind of not how things are supposed to be |
| 19:00 |
hmmmm |
Lua api for biomes might be like this: if a custom node-placement function is not required, then noise type and noise parameters are specified along with the temperature and height ranges for when it occurs |
| 19:00 |
hmmmm |
at the same time i also aim to make it friendly for people who'd like to add it right in the engine as well |
| 19:16 |
|
SpeedProg joined #minetest-dev |
| 19:32 |
hmmmm |
in map.cpp, ServerMap::saveBlock: block->resetModified(); should not be called on error like it is. |
| 20:52 |
VanessaE |
celeron55_: what's your opinion on having the client cache the received map data on disk (instead of just memory) for future use? |
