Time |
Nick |
Message |
00:00 |
|
Weedy joined #minetest-dev |
00:09 |
sapier |
https://github.com/minetest/minetest/pull/1078 TCP/UDP mixed mode support please review until I have enet variant ready for testing |
00:09 |
sapier |
btw I still don't really know how to compare those variants any ideas are welcome |
00:31 |
|
us_0gb joined #minetest-dev |
00:53 |
|
OldCoder joined #minetest-dev |
02:31 |
|
Miner_48er joined #minetest-dev |
02:49 |
|
sapier left #minetest-dev |
03:51 |
|
djdduty joined #minetest-dev |
04:04 |
|
bas080 joined #minetest-dev |
04:23 |
|
salamanderrake joined #minetest-dev |
05:13 |
|
OldCoder joined #minetest-dev |
05:13 |
|
OldCoder joined #minetest-dev |
06:43 |
|
us_0gb joined #minetest-dev |
06:51 |
xyz |
cool in the end hmmmm just fucking disappeared |
06:57 |
xyz |
well I guess no one else is interested |
07:01 |
kahrl |
guess that means more time to write the changelog |
07:02 |
kahrl |
ah, you already did that |
07:04 |
hmmmm |
??? |
07:04 |
hmmmm |
I am here |
07:04 |
hmmmm |
I thought the release was done |
07:07 |
RealBadAngel |
hi folks |
07:07 |
kahrl |
did the clientmedia fix for webservers that can't deal with POST go in? |
07:08 |
kahrl |
hrm, apparently not. oh well |
07:08 |
kahrl |
I kind of forgot about that one |
07:08 |
RealBadAngel |
i was readin lately the chan |
07:09 |
RealBadAngel |
do we have a deal who is responsible for specific parts of code? |
07:10 |
kahrl |
RealBadAngel: yeah, subsystem maintainers similar to how the linux kernel is maintained |
07:10 |
RealBadAngel |
because i would like to sign specific seat |
07:11 |
RealBadAngel |
thats in general good idea imho |
07:11 |
RealBadAngel |
since we accomodated a few coders, workin in specific areas |
07:12 |
kahrl |
right |
07:13 |
RealBadAngel |
i would like to be responsible for shaders |
07:13 |
kahrl |
here is the current list of subsystems: https://gist.github.com/celeron55/8189279 |
07:13 |
kahrl |
shaders would be subsumed under client/audiovisuals |
07:14 |
RealBadAngel |
i can see |
07:14 |
RealBadAngel |
so i should be with c55 in a team? |
07:14 |
us_0gb |
Testing ... |
07:14 |
RealBadAngel |
disease |
07:15 |
kahrl |
no, the idea was to have only one maintainer per subsystem |
07:15 |
RealBadAngel |
minimalistic theory vs eyecandies? |
07:15 |
RealBadAngel |
thats not gonna work ;) |
07:15 |
kahrl |
but c55 wanted to give the subsystem to someone else soonish, you should talk to him |
07:15 |
RealBadAngel |
not in audiovisuals |
07:16 |
RealBadAngel |
c55 way was pc at (<-ideal) |
07:17 |
RealBadAngel |
my way is as much eyecandies as it is possible |
07:17 |
RealBadAngel |
and targeting new GPU's |
07:19 |
RealBadAngel |
btw im suprised he had chosen that area |
07:19 |
kahrl |
http://irc.minetest.ru/minetest-dev/2013-12-30#i_3522914 |
07:23 |
RealBadAngel |
controversial |
07:24 |
RealBadAngel |
i was learning GLSL for months |
07:24 |
RealBadAngel |
i made working shaders |
07:24 |
kahrl |
he means from the artistic point of view |
07:24 |
kahrl |
the code is fine |
07:25 |
RealBadAngel |
because im the only one texture pack maker that made a pack? |
07:25 |
RealBadAngel |
fuck i even added auto generation |
07:25 |
RealBadAngel |
i hate c55 attidude |
07:25 |
|
nore joined #minetest-dev |
07:26 |
RealBadAngel |
it is not acceptable |
07:26 |
RealBadAngel |
i wont be crawling on the floor for ages |
07:26 |
kahrl |
as I have zero artistic clue, you'll have to work this out with c55 yourself :/ |
07:27 |
RealBadAngel |
i do have next part of code, tested for months |
07:27 |
RealBadAngel |
ready to merge |
07:27 |
RealBadAngel |
but i wont pull it |
07:28 |
RealBadAngel |
that what i have read was enough for me |
07:28 |
RealBadAngel |
please sign me outta this organisation |
07:28 |
RealBadAngel |
im going back to modding only |
07:28 |
kahrl |
... |
07:29 |
RealBadAngel |
im done with core development |
07:29 |
kahrl |
I see no problem with adding "controversial" shaders as long as they can be disabled |
07:29 |
RealBadAngel |
say it to c55 |
07:29 |
RealBadAngel |
im off that business |
07:30 |
|
RealBadAngel left #minetest-dev |
07:34 |
nore |
so, 0.4.9 was released? |
07:40 |
|
RealBadAngel joined #minetest-dev |
07:40 |
RealBadAngel |
back for just one thing |
07:41 |
RealBadAngel |
c55 taking care of audiovisuals. things that require new hardware and power. what a joke. |
07:41 |
RealBadAngel |
^for the record |
07:42 |
|
RealBadAngel left #minetest-dev |
07:47 |
xyz |
eh |
07:48 |
xyz |
overreacting over those simple things is no good |
07:48 |
|
blaaaaargh joined #minetest-dev |
07:49 |
hmmmm |
erm |
07:50 |
hmmmm |
I don't know if I like that division of subsystems and having "exactly" one person for each |
07:50 |
hmmmm |
for example you can't put sapier on the server and client, many people have and do modify it |
07:51 |
hmmmm |
I can't put sapier on any single one subsystem |
07:51 |
hmmmm |
and the scriptapi, everybody modifies that when they add new api of their own |
07:51 |
hmmmm |
nobody should be able to (or should I say can) own scriptapi |
07:51 |
xyz |
okay, I've published github release and posted forum entry |
07:52 |
hmmmm |
not to mention that this adds a dependency on talking to these specific people in order to modify something if this plan is to really come to fruition |
07:52 |
hmmmm |
the bus factor becomes an issue |
07:53 |
|
Naked joined #minetest-dev |
07:54 |
xyz |
and the website is updated too |
07:55 |
xyz |
Zeitgeist_: please update gentoo ebuild for Minetest, 0.4.9 is released now |
08:00 |
Zeitgeist_ |
xyz: kk gonna update the ebuild s fast as possible |
08:00 |
Zeitgeist_ |
as* |
08:13 |
|
darkrose joined #minetest-dev |
08:45 |
|
blaaaaargh joined #minetest-dev |
10:15 |
|
john_minetest joined #minetest-dev |
10:21 |
celeron55 |
eh what |
10:22 |
celeron55 |
it's not about who can modify something; it's about who is responsible for making sure pull requests get handled and fixing the sybsystem if it doesn't work |
10:24 |
celeron55 |
wtf is this thing with rba |
10:26 |
celeron55 |
he just suddenly pissed himself off |
10:28 |
celeron55 |
apparently he thinks i am going to suddenly stop anything made by him getting into upstream or something |
10:28 |
celeron55 |
while i wasn't even around to be commenting anything |
10:28 |
celeron55 |
that's fair |
10:33 |
celeron55 |
also i already previously said that the "allocated" persons can simply give the same permission to someone else too if they see fit; but it's up to the one persons to handle that, not me or someone else |
10:34 |
celeron55 |
apparently people are too used to the current organization to be able to think individually like that |
10:34 |
celeron55 |
john_minetest: no, but there should be |
10:35 |
celeron55 |
it should be a page which also overally describes the idea |
10:35 |
celeron55 |
"Organization" or something |
10:36 |
celeron55 |
i think dev wiki is best |
10:38 |
|
BlockMen joined #minetest-dev |
10:41 |
BlockMen |
is there a special reason that 0.4.9 is released already? |
10:42 |
nore |
BlockMen, yes: we got back to normal release time... not that very long time before 0.4.8 |
10:44 |
BlockMen |
ic |
10:48 |
celeron55 |
https://gist.github.com/celeron55/8189279 |
11:06 |
|
RealBadAngel joined #minetest-dev |
11:10 |
sfan5 |
what the heck? ndk debugging is broken on 4.3... now I need to buy another device to debug minetest or what? -.- |
11:11 |
sfan5 |
( https://code.google.com/p/android/issues/detail?id=58373 ) |
11:11 |
|
Calinou joined #minetest-dev |
11:19 |
RealBadAngel |
celeron55, sorry, i just got upset because you were always the one blocking most of eyecandies i was working on |
11:21 |
|
Robby joined #minetest-dev |
11:28 |
|
eeew joined #minetest-dev |
11:39 |
|
SmugLeaf joined #minetest-dev |
11:39 |
|
SmugLeaf joined #minetest-dev |
11:39 |
celeron55 |
i updated the text on http://dev.minetest.net/Organisation |
11:40 |
celeron55 |
if anything is unclear to anyone, ask me and i will answer on that page |
11:41 |
celeron55 |
i guess we should define how the maintainers are selected and when they change |
11:43 |
celeron55 |
or i should |
11:44 |
RealBadAngel |
celeron55, so... https://github.com/RealBadAngel/minetest/commit/a48d0e9bed5d478e1b9c468484eb81420ffed28b |
11:45 |
RealBadAngel |
this is waiting for review i think... |
11:51 |
celeron55 |
does someone use this? |
11:52 |
RealBadAngel |
i was asking many times for testing... |
11:52 |
RealBadAngel |
this change alone makes this: http://i.imgur.com/Jh13V2j.png |
11:53 |
RealBadAngel |
without any extra files needed |
11:54 |
RealBadAngel |
it was intended for 16x textues, but works suprisngly well for any |
11:56 |
RealBadAngel |
it uses Sobel's 3x3 operator for normals and for each texel 3x3 gausian blur |
11:58 |
RealBadAngel |
256x sphax: withou: http://i.imgur.com/LEzebiX.png and with: http://i.imgur.com/RX2BUjh.png |
11:58 |
pitriss |
RealBadAngel: maybe you should fix your shaders to not break look of framed glass.. With shaders are large glass places just ugly.. It is weird to see sides of nodes inside glass.. |
12:00 |
RealBadAngel |
i havent got such issue report |
12:02 |
|
kaeza joined #minetest-dev |
12:03 |
|
RealBadAngel joined #minetest-dev |
12:04 |
RealBadAngel |
sorry. power was down here for a short while |
12:05 |
RealBadAngel |
pitriss, please open an issue with screenshots how it looks like for you, your os, GPU used, drivers, and log for this session |
12:05 |
|
jin_xi joined #minetest-dev |
12:06 |
pitriss |
ok i will do that later.. |
12:07 |
RealBadAngel |
GLSL is very hard to maintain since same code works different for each version and if that was not enough for different GPUs (ie AMD or NVIDIA) |
12:10 |
RealBadAngel |
without feedback i cant do nothing, because i do own only AMD GPU |
12:10 |
|
Jordach joined #minetest-dev |
12:11 |
celeron55 |
http://dev.minetest.net/Organisation#proposed:_releases |
12:11 |
celeron55 |
i (and many others) would be glad if we could get someone on that |
12:11 |
|
ImQ009 joined #minetest-dev |
12:12 |
RealBadAngel |
celeron55, any comments on screenshots? |
12:28 |
celeron55 |
all i can see is that this patch doesn't do anything for me |
12:28 |
celeron55 |
ah, now it does |
12:29 |
celeron55 |
lol, this looks ridiculous |
12:30 |
celeron55 |
nowadays i can test on both, a haswell and an nvidia, on thee same computer 8) |
12:30 |
celeron55 |
it slows down the haswell so much that it's unplayable |
12:35 |
Jordach |
celeron55, i'll give it a test - see how bad it is |
12:35 |
|
iqualfragile joined #minetest-dev |
12:38 |
celeron55 |
anyway i can merge this |
12:38 |
celeron55 |
i guess if we don't have a good game, then we have to let people play with silly shaders 8-) |
12:39 |
Jordach |
celeron55, can i finish testing under 2.1.2 OGL? |
12:40 |
celeron55 |
yes |
12:41 |
|
Naked joined #minetest-dev |
12:55 |
nore |
there is a problem with node pointing: if I point a node, and there is an entity *behind* the node, which would be pointed if the node was not there, it is the entity which is pointed and not the node |
12:55 |
nore |
is that normal? |
12:55 |
sfan5 |
no |
12:56 |
nore |
then why does it happen? (btw, the entity is the same kind of entity as falling nodes, except that it doesn't fall) |
12:57 |
nore |
i.e.: visual = "wield_item" |
12:58 |
nore |
can you reproduce it? |
12:59 |
celeron55 |
that has always been the case |
13:00 |
celeron55 |
the pointing of things is calculated separately for nodes and objects, and objects take precedence |
13:00 |
nore |
why? |
13:00 |
celeron55 |
it just happens to be so |
13:03 |
nore |
and couldn't be it be changed? |
13:05 |
celeron55 |
probably can |
13:05 |
celeron55 |
you need to combine two messy loops |
13:06 |
nore |
nope: you get distance of nearest selected object |
13:06 |
celeron55 |
oh whatever just fix it 8) |
13:06 |
nore |
and if you find a node nearer than that distance, you have what you want |
13:07 |
Jordach |
celeron55, you shouldn't merge it |
13:07 |
Jordach |
it's decided to throw a shader compile error |
13:11 |
Jordach |
http://i.imgur.com/RU3YJMD.png |
13:11 |
Jordach |
with just the generate normalmaps enabled :P |
13:17 |
|
ImQ009 joined #minetest-dev |
13:18 |
celeron55 |
i guess it needs opengl 3 then |
13:18 |
celeron55 |
well that doesn't matter as long as it works when the option is disabled |
13:19 |
celeron55 |
but these should be documented and also possibly autodetected somehow |
13:19 |
celeron55 |
RealBadAngel: what do you think |
13:27 |
nore |
https://github.com/Novatux/minetest/commit/91923806a98fb5cc8e2bf6ed6a864b41337bb3e5 <-- any thoughts? |
13:28 |
nore |
celeron55, ^ |
13:33 |
RealBadAngel |
celeron55, i do have 1,8ghz amd 4600 series |
13:33 |
RealBadAngel |
with all those options enabled im getting 40-50fps |
13:33 |
RealBadAngel |
for 256x texture pack and generation enabled |
13:34 |
celeron55 |
nore: test it with very large and very small objects near nodes; if it works for both, it's good |
13:34 |
celeron55 |
RealBadAngel: i don't care about performance; i asked about compatibility problems |
13:35 |
nore |
celeron55: the node is selected if the distance from camera to intersection with node is less than distance from camera to center of object |
13:35 |
RealBadAngel |
celeron55, yes, there are problems, but in general not in shaders code |
13:35 |
RealBadAngel |
but the drivers folks are using |
13:36 |
nore |
and it is not possible to make better, since for objects, the one with the closest _center_ will be selected, not the closest intersection |
13:36 |
RealBadAngel |
propertiary drivers are way faster |
13:36 |
RealBadAngel |
thats why Thorvalds showed a finger to Nvidia |
13:37 |
RealBadAngel |
also i can notice on the very same box that minetest runs way faster on windows |
13:37 |
celeron55 |
nore: maybe that's good because otherwise you couldn't select small objects that are inside large ones... maybe |
13:38 |
RealBadAngel |
another note: it runs WAY faster in full screen mode |
13:38 |
celeron55 |
RealBadAngel: you are talking about completely random things |
13:38 |
nore |
but is what I said ok about the selection objects/nodes, or do I need to change it? |
13:39 |
celeron55 |
objects behind nodes are blocked while objects in front of nodes aren't; that was the idea, right? |
13:39 |
celeron55 |
this means that objects inside nodes are blocked too; is that bad? |
13:39 |
RealBadAngel |
celeron55, those are two issues on the very same code |
13:39 |
celeron55 |
does some mod insert objects in a node and expects the player to be able to take them from there |
13:40 |
RealBadAngel |
opengl is such a bitch that work different way depending on GPU |
13:40 |
RealBadAngel |
and the drivers |
13:40 |
nore |
yes |
13:40 |
nore |
celeron55, it depends on the position of the object |
13:41 |
BlockMen |
cauldrons are impossible then?! |
13:41 |
RealBadAngel |
even if you restrict shaders code to a specific version, it does matter what drivers you are using |
13:41 |
nore |
I don't think there are a lot of mods that do that... |
13:41 |
RealBadAngel |
and then what brackets are allowed |
13:41 |
nore |
BlockMen, what would you mean, cauldrons? |
13:42 |
BlockMen |
nvm, i forgot that there is sth like nodeboxes^^ |
13:42 |
BlockMen |
^nore |
13:42 |
celeron55 |
what happens with nodeboxes that have a hole into them and there is an object inside? |
13:43 |
nore |
celeron55: if the object is at the center of the node, and if you point the hole so that the intersection with the node is further than the center (that should be the case), then the object gets selected |
13:43 |
celeron55 |
RealBadAngel: that doesn't mean we should simply disregard the user's problems |
13:43 |
RealBadAngel |
no, ofc |
13:44 |
RealBadAngel |
but i need feedback |
13:44 |
RealBadAngel |
that means users tryin to run it |
13:44 |
RealBadAngel |
and their error reports |
13:44 |
celeron55 |
i would like it to be so that if shaders don't work, it asks the user whether he wants to disable shader features that don't work for him |
13:45 |
celeron55 |
opengl's versioning is based on features, and the supported ones can be queried from the driver |
13:45 |
celeron55 |
so minetest can disable what isn't supported |
13:45 |
RealBadAngel |
atm shaders are compiled depending on chosen options |
13:46 |
celeron55 |
nore: it's good then |
13:47 |
RealBadAngel |
i am targeting glsl 1.20 |
13:47 |
celeron55 |
nore: i guess i'm responsible for this "pull request" so i can say that you can push it4 |
13:47 |
celeron55 |
-44 |
13:47 |
nore |
ok... |
13:48 |
|
EvergreenTree joined #minetest-dev |
13:48 |
|
EvergreenTree joined #minetest-dev |
13:48 |
RealBadAngel |
celeron55, all the code named "shaders rework" was published way before i made a pull out of it |
13:49 |
RealBadAngel |
and thx to feedback i have fixed many compability issues |
13:49 |
RealBadAngel |
also old ones |
13:51 |
|
eeew joined #minetest-dev |
13:52 |
RealBadAngel |
and about the features, as i said, i decided to target 1.20 |
13:52 |
RealBadAngel |
that means even opensource drivers should work with it |
13:53 |
RealBadAngel |
but opensource Nvidia refuses lighting for some unknown reason ;) |
14:02 |
celeron55 |
RealBadAngel: should i push this? |
14:05 |
VanessaE |
I need some help: what would cause the server to create tons and tons and tons of players/xxxxxxxx.~mt ? |
14:05 |
VanessaE |
for each player on every world I run, all of a sudden, bam there they are |
14:06 |
celeron55 |
it creates those for saving player files in a crash-resistant way |
14:06 |
VanessaE |
doing so causes crashes. :P |
14:06 |
VanessaE |
the server apparently can't tolerate the existence of those files. |
14:07 |
celeron55 |
there shouldn't exist tons of them |
14:07 |
VanessaE |
the whole dir was filled - every player had one on every single world |
14:07 |
celeron55 |
only one for each crash where it has crashed in the middle of writing a player file |
14:08 |
celeron55 |
then it's broken |
14:08 |
celeron55 |
do you have a long path or some non-ascii characters in the path? |
14:08 |
xyz |
sfan5: I told you, remember? |
14:08 |
VanessaE |
http://pastebin.ubuntu.com/6678666/ |
14:08 |
VanessaE |
celeron55: nope, see above |
14:09 |
VanessaE |
I came home from shopping to find that ^^^^^^^ |
14:09 |
xyz |
sfan5: you just need to root your device and then there's a workaround |
14:09 |
xyz |
sfan5: and it's run-as that is broken afaik, not ndk-gdb |
14:09 |
VanessaE |
the server was complaining of the old PlayerArgsEnd not found error, I investigated, found that ^^^^ |
14:10 |
VanessaE |
in fact all five were complaining, hence the use of find. |
14:12 |
celeron55 |
how about if some logging of errors was added to filesys.cpp:707 so that we could have some idea why it fails in that case |
14:12 |
VanessaE |
oh wait, I think I know what happened. |
14:13 |
VanessaE |
looks like I may have ran out of space during the backup task |
14:14 |
VanessaE |
still, |
14:14 |
VanessaE |
looks like it revealed a corner case you might want to control for :) |
14:14 |
celeron55 |
wtf |
14:14 |
celeron55 |
oh |
14:14 |
VanessaE |
"the backup task" == a script I run, not to the engine. |
14:14 |
celeron55 |
so those .~mt files are empty? |
14:15 |
VanessaE |
I didn't look. deleted them and got the servers back up |
14:15 |
celeron55 |
they probably were empty |
14:16 |
celeron55 |
it tries to write one, and if it's empty, it just is like "oh that errored, i'll just do something else"; otherwise it moves it over the actual file (and thus never endds up with an actual file with half-written content) |
14:16 |
celeron55 |
it should remove the file in the case of failing to write into it 8) |
14:16 |
celeron55 |
(that it doesn't is a bug) |
14:17 |
celeron55 |
wait what |
14:17 |
celeron55 |
was the server trying to load a .~mt file? |
14:17 |
celeron55 |
that's an another bug |
14:18 |
sfan5 |
xyz: I found a workaround |
14:18 |
VanessaE |
yes, it was |
14:18 |
celeron55 |
i wonder if PilzAdam wants to fix these as he wrote the original 8) |
14:18 |
VanessaE |
as soon as I deleted all *.~mt the servers were happy. |
14:19 |
VanessaE |
the server loads *all* player files |
14:19 |
VanessaE |
even if a player isn't signed on |
14:19 |
celeron55 |
i know, i looked at the code |
14:24 |
RealBadAngel |
celeron55, no, its not in the state for push. i was askin for testing that by devs |
14:24 |
RealBadAngel |
the change only affects solids |
14:25 |
RealBadAngel |
problem was nobody (of devs) wanted to try it |
14:26 |
RealBadAngel |
if the generation code will work, i can make all the shaders use it |
14:26 |
VanessaE |
celeron55: well that code needs fixed. thanks to that, I can't even rely on timestamps on those files to be able to clear out old, dead accounts. |
14:27 |
RealBadAngel |
but for testing is better to keep the changes in one |
14:28 |
celeron55 |
RealBadAngel: you should make sure that the base-level shaders work with very low-end setups |
14:28 |
celeron55 |
only if special features like that are taken into use, then it can require stuff like opengl 3 |
14:28 |
RealBadAngel |
i can achieve that only with feedback |
14:29 |
celeron55 |
then ask Jordach always to test; he apparently has something non-fancy |
14:29 |
RealBadAngel |
also lotsa other folks |
14:29 |
RealBadAngel |
even VanessaE |
14:30 |
RealBadAngel |
she had too new hardware, and problem with lighting popped up for her |
14:30 |
VanessaE |
yup, because my driver doesn't clamp lighting values, it allows them to overexpose. |
14:30 |
nore |
I have only OpenGL 2.1, so I can test it |
14:30 |
RealBadAngel |
believe me, GLSL is a bitch to maintain |
14:31 |
* sfan5 |
has some old hardware to test on |
14:31 |
sfan5 |
but it will take 1 hour to compile |
14:31 |
RealBadAngel |
lol |
14:31 |
sfan5 |
literally 1 hour |
14:31 |
VanessaE |
what is it, a RPi? :) |
14:31 |
sfan5 |
no |
14:32 |
nore |
for me it only takes 5 minutes, so I can test now if you need |
14:32 |
RealBadAngel |
for me its enough to see logs to know whats wrong |
14:32 |
sfan5 |
VanessaE: some old computer with an AMD processor (1 core) and a pretty old nvidia card |
14:32 |
VanessaE |
RealBadAngel: and then...there's the glistening water shader ;) |
14:32 |
VanessaE |
sfan5: ouch, must be damned old then |
14:32 |
RealBadAngel |
the water will be reworked, you know |
14:32 |
VanessaE |
RealBadAngel: yep I know |
14:33 |
RealBadAngel |
water need to have surface, for christ sake |
14:33 |
sfan5 |
does the rpi even support glsl? |
14:33 |
VanessaE |
doubt it |
14:33 |
nore |
RBA: reflections too? |
14:33 |
RealBadAngel |
i do have reflections, refraction and surface code rdy |
14:34 |
nore |
you can see the other nodes reflected in the water??? |
14:34 |
RealBadAngel |
ofc |
14:34 |
* nore |
tests |
14:34 |
RealBadAngel |
and the sunlight and moonlight |
14:35 |
RealBadAngel |
i just need to split rendering into 2 passes |
14:35 |
RealBadAngel |
up and below |
14:35 |
RealBadAngel |
with result in texture shaders will do the rest |
14:37 |
RealBadAngel |
http://www.youtube.com/watch?v=ax48OnXjDTE |
14:37 |
RealBadAngel |
you can see water shaders here |
14:38 |
celeron55 |
raspberry pi uses opengl es2 |
14:38 |
celeron55 |
it doesn't even display anythign without giving it shaders that emulate the fixed pipeline |
14:38 |
celeron55 |
anything* |
14:39 |
RealBadAngel |
quake3 works somehow on rpi |
14:39 |
|
sapier joined #minetest-dev |
14:41 |
RealBadAngel |
http://www.youtube.com/watch?v=YDPnqkZF6hQ |
14:48 |
nore |
wow... I had to make a few tweaks, it killed my FPS, but the generate_normalmaps thing works!!! I couldn't see any reflections on the water however, and it stills use the normalmaps, so with bumpmapping, it is black... |
14:48 |
|
PilzAdam joined #minetest-dev |
14:52 |
xyz |
RealBadAngel: are water shaders in your repo already? |
14:57 |
Exio4 |
sfan5, old nvidia card? |
14:58 |
sfan5 |
yes |
14:58 |
Exio4 |
nvidia igp? |
14:58 |
Exio4 |
sempron? |
14:58 |
Exio4 |
model name: AMD Sempron(tm) Processor LE-1200 |
14:58 |
Exio4 |
my actual cpu ;P |
14:58 |
sfan5 |
not igp |
14:58 |
sfan5 |
the mainboard has no vga output |
14:58 |
Exio4 |
ah |
14:58 |
sfan5 |
s/vga/video/ |
15:07 |
|
bas080 joined #minetest-dev |
15:09 |
|
Megaf joined #minetest-dev |
15:09 |
|
ImQ009 joined #minetest-dev |
15:11 |
|
Yepoleb joined #minetest-dev |
15:13 |
RealBadAngel |
xyz, no, water shaders are wip |
15:15 |
RealBadAngel |
nore, the patch is about generate normal maps on the fly (or use overriding one) |
15:15 |
nore |
yes, it works... (but not for liquids) |
15:16 |
RealBadAngel |
yes, because only solids shader is modified to use it |
15:16 |
RealBadAngel |
but you can try out one trick |
15:16 |
RealBadAngel |
please create empy texture pack folder |
15:16 |
RealBadAngel |
and copy there this image: |
15:17 |
RealBadAngel |
http://i.imgur.com/epKsbgF.png |
15:18 |
RealBadAngel |
rename it to: override_normal.png |
15:18 |
RealBadAngel |
also i suggest turning off filtering |
15:19 |
RealBadAngel |
this thingy will work for all the shaders actually |
16:08 |
|
rubenwardy joined #minetest-dev |
16:16 |
|
hmmmm joined #minetest-dev |
16:19 |
|
bas080 joined #minetest-dev |
16:38 |
|
Calinou joined #minetest-dev |
16:38 |
|
Zeitgeist_ joined #minetest-dev |
16:41 |
|
jin_xi joined #minetest-dev |
16:55 |
|
rubenwardy joined #minetest-dev |
17:12 |
|
Anchakor_ joined #minetest-dev |
17:20 |
celeron55 |
xyz: are you interested in unifying this touch control stuff somehow sanely |
17:21 |
xyz |
what do you mean? |
17:22 |
celeron55 |
i'm not sure actually |
17:22 |
celeron55 |
i |
17:23 |
celeron55 |
i'm now using irrlicht's sdl2 backend quite succesfully in this |
17:23 |
celeron55 |
or, well, one that i made... |
17:25 |
celeron55 |
but basically i want to get as much of this upstream as possible |
17:25 |
celeron55 |
upstream minetest (obviously) |
17:25 |
xyz |
of what? |
17:26 |
celeron55 |
code that allows one to actually play using touchscreen input |
17:29 |
xyz |
well my code isn't android-dependent |
17:29 |
xyz |
though at some places it is, but this can easily be changed |
17:29 |
xyz |
you just need to send EET_MULTI_TOUCH_EVENT to it, and that's all |
17:30 |
celeron55 |
you've mixed android-specific and other stuff in commits |
17:30 |
celeron55 |
and the code is freeminer's so i can't copy files either |
17:31 |
celeron55 |
i guess i'll try the commits |
17:31 |
celeron55 |
i hate you for not committing to minetest though |
17:32 |
xyz |
<3 |
17:33 |
celeron55 |
it's a serious pain and nothing progresses because freeminer isn't any better suited for continued development |
17:33 |
xyz |
yeah sure |
17:34 |
celeron55 |
well what |
17:34 |
celeron55 |
do you suggest i close down minetest and start developing freeminer instead? |
17:34 |
celeron55 |
yeah sure |
17:35 |
xyz |
no, I didn't suggest that |
18:03 |
|
Anchakor_ joined #minetest-dev |
18:34 |
|
ImQ009 joined #minetest-dev |
18:41 |
RealBadAngel |
celeron55, a few days ago i have bought new tablet, so i can test stuff |
18:42 |
|
ImQ009 joined #minetest-dev |
18:46 |
|
rubenwardy joined #minetest-dev |
18:57 |
|
RealBadAngel2 joined #minetest-dev |
19:00 |
sapier |
anyone another protocol to evaluate except udp tcp enet? |
19:02 |
xyz |
don't think so |
19:02 |
xyz |
how will we "evaluate" those? |
19:04 |
sapier |
that's the open issue ;-) I have no real idea how to test, of course there are some numbers, e.g. cpu load, max download rate, rtt ... but none of them on its own is even close to a good indicator (at least if they're not extremely wrong) |
19:05 |
|
daswort joined #minetest-dev |
19:05 |
celeron55 |
well, there's only one real test: set up an identical server for both and play on them from everywhere in the world |
19:06 |
celeron55 |
or, really, many servers with different connections... |
19:06 |
sapier |
while this is best suggestion by now I don't really think this is a reliable test ;-) |
19:07 |
sapier |
my current expectation is old udp support will loose any test (except of compatibility ;-) ) |
19:08 |
sapier |
tcp will win max bandwidth tests |
19:08 |
sapier |
and enet hmm guess something in between |
19:08 |
celeron55 |
enet could work best for crappy connections |
19:09 |
celeron55 |
(overloaded crappy connections) |
19:10 |
sapier |
you could be right about that |
19:10 |
sapier |
oh I have to remove the useless connection lock prior starting tests |
19:11 |
sapier |
enet might suffer off lack of send/receive separation ... but there could be other limitations for this too |
19:12 |
sfan5 |
sapier: how about max. download speed when sending all media? |
19:12 |
sapier |
guess it's hard to compete with tcp in this discipline |
19:12 |
xyz |
honestly |
19:13 |
xyz |
oh wait a moment |
19:13 |
sapier |
and while that one is "first impression" it doesn't matter really much in game |
19:14 |
xyz |
sapier: so is it fair enough to already compare your tcp_implementation_2 branch to minetest master? |
19:15 |
sapier |
comparing to master isn't an option as master is utterly broken |
19:16 |
xyz |
well I only did a small simple test |
19:16 |
xyz |
just created a singleplayer game and placed some cobble blocks randomly |
19:16 |
xyz |
and master won and tcp_implementation_2 sucked |
19:16 |
xyz |
but if it's broken then I guess it's a bit unfair to compare, even if broken implementation wins |
19:16 |
sapier |
can you be a little bit more precise? |
19:17 |
xyz |
sapier: they disappear and reappear like on laggy servers |
19:17 |
xyz |
I can record a video |
19:19 |
sapier |
I believe you why would you lie about it ;-) question now is it is a silly bug in my implementation or a principle problem |
19:19 |
sapier |
guess if you try to connect to a server with 200mb textures result will be different ;-) |
19:20 |
sapier |
thats's why we need some more then a single test |
19:24 |
sapier |
I'm not even sure flickering is indicator for low performance it might be result of asynchornous sending too |
19:27 |
sapier |
old code handles sending and receiving in same thread so it's gonna process all currently received messages prior sending anything, this may result in queuing multiple map changes and processing them at once ... same way modifications to map are sent back to client in a single shot too |
19:28 |
sapier |
you could verify this by using my fixed udp version, if it isn't limited by beeing to slow you should recognize same effect |
19:28 |
xyz |
here's the video anyway http://a.pomf.se/cywoca.mkv |
19:29 |
sapier |
how long do you have to wait for map to appear? |
19:29 |
xyz |
the server_improvement one? |
19:29 |
xyz |
just check the video |
19:30 |
sapier |
ok I guess I need to download it instead of streaming |
19:31 |
xyz |
can't reproduce this behavior in server_improvement branch |
19:31 |
xyz |
works fine ther |
19:32 |
sapier |
interesting |
19:33 |
sapier |
is there a way to tell os to flush tcp buffers to network? |
19:33 |
sapier |
thinking about a buffering issue |
19:34 |
ShadowNinja |
TCP doesn't concentrate on latency, it concentrates on fast reliable delivery of bulk data. Is it sent through TCP? |
19:35 |
sapier |
that's why it's called tcp client ;) |
19:38 |
sapier |
ok :-) I made the tcp client do the full buffering thing |
19:40 |
sapier |
not even samba does it this way :-) |
19:41 |
xyz |
so is it fixed now? |
19:41 |
sapier |
not pushed yet |
19:41 |
sapier |
I'm fixing the last bugs in enet right now give me a minute ... or two ;-) |
19:43 |
xyz |
enet? you have this branch too? |
19:44 |
sapier |
not yet pushed |
19:52 |
|
kaeza joined #minetest-dev |
19:56 |
kaeza |
it seems that `on_chat_message' calls all the registered callbacks regardless of what previous ones return. Is there a problem if such callbacks stop processing as soon as one of them returns some value? |
19:57 |
sapier |
"some"? wasn't return value of various other callbacks bool? not quite sure about that either |
19:58 |
|
Jordach joined #minetest-dev |
19:59 |
kaeza |
as an example, I coded an "antiflood" mod, that disallows sending the same message twice in a row, by returning false from the callback, but the IRC mod is still getting passed the text, thus still flooding the channel |
20:02 |
kaeza |
any insight on how to avoid this, without resorting to a heap of hackwork? |
20:02 |
sapier |
flooding from minetest to irc? :-) quite ironic ;-) |
20:02 |
sapier |
but anyhow how do you ensure your protection mod is first one to get the data? |
20:03 |
sapier |
hmm "but anyhow" is german english ... just forget about that phrase |
20:03 |
kaeza |
because antiflood (opt)depends on irc |
20:03 |
kaeza |
I believe on_chat_message is FIFO, right? |
20:03 |
sapier |
might be ... but there's no guarantee for it |
20:17 |
|
ShadowBot joined #minetest-dev |
20:19 |
kaeza |
oh derp |
20:23 |
|
ShadowBot joined #minetest-dev |
20:31 |
|
ShadowBot joined #minetest-dev |
20:43 |
|
sapier1 joined #minetest-dev |
20:44 |
|
Miner_48er joined #minetest-dev |
20:47 |
|
Miner_48er joined #minetest-dev |
20:48 |
|
john_minetest joined #minetest-dev |
20:57 |
|
smoke_fumus joined #minetest-dev |
21:16 |
|
ShadowBot joined #minetest-dev |
21:19 |
|
eeew joined #minetest-dev |
21:21 |
|
ShadowBot joined #minetest-dev |
21:34 |
|
emptty joined #minetest-dev |
22:04 |
|
eeew joined #minetest-dev |
22:18 |
|
Naked joined #minetest-dev |
22:21 |
|
Fury joined #minetest-dev |
22:21 |
PilzAdam |
did someone fell asleep while releasing? half of http://dev.minetest.net/Releasing_Minetest isnt done |
22:22 |
PilzAdam |
nobody pushed to stable-0.4 branch, mt_game isnt taged |
22:22 |
PilzAdam |
the -dev suffix isnt enabled either |
22:23 |
PilzAdam |
this is the second release that is only done half |
22:28 |
|
naxthesurvivor_ joined #minetest-dev |
22:41 |
|
diemartin joined #minetest-dev |
22:50 |
|
diemartin joined #minetest-dev |
22:57 |
|
iqualfragile_ joined #minetest-dev |
22:58 |
celeron55 |
http://c55.me/random/2014-01/tscrot-2014-01-03_00-57-27.png |
22:58 |
celeron55 |
so yeah, apparently ogles2 is broken in either minetest or irrlicht |
22:59 |
celeron55 |
hard to tell |
22:59 |
celeron55 |
it looks the same on the actual device |
23:02 |
celeron55 |
it's like it drew only the first texture of a mesh or something |
23:02 |
sfan5 |
i guess that is a bug in irrlicht |
23:05 |
|
ShadowBot joined #minetest-dev |
23:08 |
ShadowNinja |
And the serverlist is broken!!! |
23:09 |
ShadowNinja |
The only usefull information that I got was that it got a error code of 0. |
23:11 |
|
diemartin joined #minetest-dev |
23:39 |
|
us_0gb joined #minetest-dev |