Time |
Nick |
Message |
00:36 |
|
SitDog joined #minetest-dev |
05:52 |
|
celeron55 joined #minetest-dev |
06:04 |
|
Calinou joined #minetest-dev |
10:07 |
|
rsiska joined #minetest-dev |
10:39 |
|
OldCoder joined #minetest-dev |
10:39 |
|
OldCoder joined #minetest-dev |
10:40 |
|
sstrandberg joined #minetest-dev |
11:31 |
|
rsiska joined #minetest-dev |
11:50 |
|
celeron55 joined #minetest-dev |
12:10 |
|
rsiska joined #minetest-dev |
12:50 |
|
zee joined #minetest-dev |
13:00 |
|
celeron55_ joined #minetest-dev |
13:12 |
|
SpeedProg joined #minetest-dev |
13:23 |
|
sstrandberg joined #minetest-dev |
14:17 |
|
rsiska joined #minetest-dev |
14:24 |
|
hmmmm joined #minetest-dev |
14:25 |
Taoki |
celeron55_: http://minetest.net/forum/viewtopic.php?pid=55888 More people are starting to ask about using shaders to add post-processing like in those images. Any chance you might look into adding a second render pass during the next days? If that's added I can try to find some freebie GLSL filters and add them to the shader file, once there is one for that |
14:26 |
Taoki |
days / weeks / etc. It's ok if you can't but that would be a really nice thing |
15:15 |
celeron55_ |
Taoki: no |
15:17 |
Taoki |
ok |
15:18 |
celeron55_ |
the main thing in those images is lighting and shadows |
15:19 |
celeron55_ |
you're not going to get anything like that with post-processing |
15:22 |
Taoki |
Well bloom is a post-process, since it's not applied to speficic textures |
15:22 |
Taoki |
As well as light rays |
15:23 |
|
rsiska joined #minetest-dev |
15:23 |
celeron55 |
you can't have meaningful bloom or light rays without first having some kind of a thing that emits "brighter than the screen can show" light in such a way that it's detectable in a post processing step |
15:24 |
Taoki |
ah, right |
15:25 |
Taoki |
For bloom you can, since you can just over-brighten and blur bright areas of the image at each step |
15:25 |
celeron55 |
that would be horrible |
15:25 |
Taoki |
With that render pass |
15:25 |
Taoki |
Why? I use it in photoshop on images and it looks nice |
15:25 |
celeron55 |
it needs more than that to not be only a huge headache |
15:27 |
celeron55 |
well i guess you can do something |
15:27 |
celeron55 |
at least i wouldn't use it... |
15:40 |
|
PilzAdam joined #minetest-dev |
16:06 |
thexyz |
celeron55: https://github.com/celeron55/minetest/pull/344 |
16:07 |
celeron55 |
lol, just as if i didn't have anything to do tonight already 8) |
16:07 |
thexyz |
k |
16:07 |
celeron55 |
i'll look at it |
16:08 |
celeron55 |
where is the font from? |
16:08 |
celeron55 |
i don't see any license additions for it |
16:09 |
thexyz |
it's dejavu sans mono |
16:09 |
thexyz |
same as the one used in console |
16:12 |
VanessaE |
http://dejavu-fonts.org/wiki/License |
16:13 |
VanessaE |
if that's of any use. |
16:13 |
celeron55 |
currently reading that |
16:13 |
celeron55 |
seems quite useless; this is mostly just ambiguous to someone who hasn't dealt with legal texts for 10 years |
16:14 |
|
Calinou joined #minetest-dev |
16:14 |
VanessaE |
well, debian distributes deja-vu sans, so the license is probably compatible with minetest. |
16:15 |
VanessaE |
(considering how license-obsessive they are :-) ) |
16:16 |
celeron55 |
i think a mention of the font being dejavu sans and a link to http://dejavu-fonts.org/wiki/License should be added to README.txt |
16:17 |
celeron55 |
(or, well, whatever the proper name for it is) |
16:17 |
VanessaE |
meh. that License file ^^^ is the same one they include with the debian package |
16:17 |
VanessaE |
that's about useless. |
16:17 |
VanessaE |
(well in part it's the same) |
16:18 |
thexyz |
celeron55: the last readme.txt section is about DejaVu Sans Mono |
16:18 |
thexyz |
though it's missing this link |
16:18 |
VanessaE |
celeron55: it looks like your idea should work. link to the license from README. |
16:18 |
celeron55 |
hmm, i see |
16:19 |
celeron55 |
i guess the existing text can suffice |
16:19 |
VanessaE |
as I read it: make any change you want and distribute it as you see fit, as long as you include the copyright notice and don't use the words "bitstream" or "vera" in the names. |
16:23 |
Calinou |
"don't use the words "bitstream" or "vera" in the names" < huh, why |
16:24 |
Calinou |
i know a lot of games where fonts are called bitstream/vera |
16:24 |
VanessaE |
because bitstream vera is a font of its own |
16:24 |
VanessaE |
deja-vu sans is a modified version of it, and the Bitstream team claims trademark on the name. |
16:24 |
VanessaE |
"All Rights Reserved. Bitstream Vera is a trademark of Bitstream, Inc." |
16:25 |
VanessaE |
so telling downstream packagers to just use a different name was probably the easiest way to avoid a conflict or confusion without restricting derivative works. |
16:26 |
celeron55 |
oh dog |
16:26 |
celeron55 |
more utf-16 |
16:26 |
celeron55 |
i don't understand why somebody even invented utf-16 |
16:26 |
celeron55 |
it should burn deep in hell |
16:26 |
VanessaE |
the rest of this reads almost like a modified version of the warranty disclaimer included with most GNU software. |
16:27 |
celeron55 |
it has all the cons of utf-32, AND it has all the cons of utf-8 |
16:27 |
VanessaE |
heh |
16:27 |
celeron55 |
and no pros whatsoever 8D |
16:28 |
celeron55 |
i guess it's fine as long as we have all protocols and files in utf-8 |
16:29 |
VanessaE |
well, aside from being just plain overkill for this project, is there any functional negative for using a UTF-16-based resource? |
16:29 |
VanessaE |
(and aside from it obviously being a pain in the ass in general ;-) ) |
16:29 |
celeron55 |
utf-16 is bad because it's not compatible with ascii and is not 8-bit, yet still it has the extended characters (which are familiar from utf-8) because 16 bits will not fit all of unicode (not even close) |
16:30 |
celeron55 |
noobs like it because it will usually work for many languages even if you use it like a fixed 2-byte character set |
16:30 |
celeron55 |
but it's not |
16:30 |
VanessaE |
"not compatible with ASCII" and they thought it was a good idea? |
16:31 |
celeron55 |
if you want to use a character set like that, utf-32 is the only one that will do the job |
16:31 |
VanessaE |
wtf did they want to work with, EBCDIC? |
16:31 |
celeron55 |
it is not compatible with ascii, but it is fixed width |
16:32 |
celeron55 |
i guess utf-16 was made because windows uses 16-bit characters |
16:32 |
celeron55 |
or something like that... |
16:32 |
VanessaE |
meh. |
16:33 |
celeron55 |
and irrlicht uses wchar_t, which can be 16 or 32 bit depending on the system 8D |
16:33 |
celeron55 |
more namely, on windows it's 16, on *nix it's 32 |
16:33 |
celeron55 |
completely useless nonsense |
16:34 |
VanessaE |
"So jurisdictionally it's..." "--a g*ddamn nightmare." |
16:34 |
celeron55 |
with some luck, the things available in non-extended utf-16 characters will work for us |
16:35 |
celeron55 |
the rest, whatever |
16:35 |
celeron55 |
i won't even try |
16:35 |
VanessaE |
yeah.. There's really no need for anything outside of the basic Latin character set anyway in this game. |
16:36 |
VanessaE |
it's not like you're writing a word processor something. |
16:36 |
celeron55 |
nope |
16:36 |
celeron55 |
the chat and some mod need to support many languages |
16:36 |
celeron55 |
mods* |
16:37 |
VanessaE |
hrm. |
16:37 |
celeron55 |
the currently used latin-1 (or something like that) doesn't even support all european languages |
16:37 |
celeron55 |
then there is russian and all that |
16:37 |
celeron55 |
greece, whatever |
16:37 |
celeron55 |
supporting chinese and japanese is a good idea too |
16:38 |
VanessaE |
*looks at basic multilingual plane* |
16:38 |
celeron55 |
but those do probably require some rarer characters from the higher parts of unicode, not sure |
16:38 |
VanessaE |
all of this shit looks like the same stuff UTF-8 already has.. |
16:39 |
VanessaE |
(ignoring the multi-byte char encodings for a sec) |
16:39 |
celeron55 |
utf-8 has all of unicode |
16:39 |
celeron55 |
it just works for ascii too, and has no endianess problems and... ehm... is just the sane thing to use |
16:40 |
celeron55 |
anyway, whatever; i hope this thexyz's thing works 8) |
16:40 |
VanessaE |
heh |
16:41 |
VanessaE |
famous last words? :D |
16:41 |
thexyz |
i've disabled it by default though |
16:42 |
celeron55 |
it probably should automatically enable itself if freetype is available |
16:42 |
celeron55 |
hmm... that would mean that the option is enabled by default but it just falls back to not using it if it's not available |
16:42 |
celeron55 |
it's how gettext is used |
16:43 |
celeron55 |
it always kicks in on linux but on windows it's not on anyone's way |
16:43 |
celeron55 |
i guess nobody has heard any problems caused by that behavior of gettext in minetest? |
16:44 |
celeron55 |
i haven't, at least... |
16:44 |
VanessaE |
the only text entry issue I've ever seen, you already know about (copy&paste). |
16:44 |
VanessaE |
everything else seems to work pretty much as one would expect. |
16:45 |
VanessaE |
of course that's just the user-facing stuff, I've no idea what goes on under the hood. |
16:45 |
celeron55 |
by the way, the minetest network protocol does use 16-bit strings in chat messages... |
16:45 |
celeron55 |
should make that utf-8 |
16:45 |
celeron55 |
VanessaE: that is up to irrlicht |
16:46 |
VanessaE |
right. minor confusion there, don't mind me. |
16:47 |
celeron55 |
// As linux is successfully switched to UTF-8 completely at about year 2005 |
16:47 |
celeron55 |
// Windows still uses obsolete codepage based locales because you |
16:47 |
celeron55 |
// cannot recompile closed-source applications |
16:47 |
* celeron55 |
smiles |
16:47 |
VanessaE |
heh |
16:48 |
thexyz |
celeron55: does minetest use utf-8 for formspec text? |
16:49 |
celeron55 |
it should, but i wouldn't be surprised if it doesn't work |
16:49 |
celeron55 |
the protocol uses 8-bit strings for them |
16:50 |
|
SpeedProg joined #minetest-dev |
16:51 |
|
doserj joined #minetest-dev |
16:53 |
VanessaE |
bbl, time to head out. |
16:55 |
celeron55 |
thexyz: src/guiChatConsole.cpp |
16:55 |
celeron55 |
why does that need only the font filename while src/main.cpp uses a full path? |
16:56 |
thexyz |
oops |
16:57 |
thexyz |
oh, and by the way, where should the font.ttf be stored? |
16:59 |
celeron55 |
probably client/fonts/font.ttf (client/ was added to contain shaders in client/shaders/) |
16:59 |
celeron55 |
or, well |
17:00 |
PilzAdam |
to follow this textures/ should be moved to client/ |
17:00 |
celeron55 |
they kind of could be all flat in /shaders and /fonts (like /textures is), but i think that will create too many flat directories in the long run |
17:01 |
celeron55 |
on the other hand they were intentionally made all flat (by me and kahrl) in the directory rearrangement that was done in the early days of 0.4... |
17:01 |
doserj |
don't you want mods to be able to supply fonts? |
17:02 |
celeron55 |
that doesn't matter |
17:02 |
celeron55 |
there always has to be a client-side default font |
17:02 |
doserj |
oh, sure |
17:05 |
celeron55 |
i think we'll keep it all flat |
17:06 |
celeron55 |
there won't be that many different things and it is fun to make people immediately see what the thing consists of 8) |
17:07 |
celeron55 |
so this being the way, font.ttf should be /fonts/font.ttf, and /client/shaders/ should be moved to /shaders/ |
17:13 |
|
sstrandberg joined #minetest-dev |
17:15 |
|
rubenwardy joined #minetest-dev |
17:16 |
PilzAdam |
whats about this: https://github.com/celeron55/minetest/pull/345 |
17:30 |
|
rubenwardy joined #minetest-dev |
17:34 |
|
rsiska joined #minetest-dev |
17:39 |
thexyz |
celeron55: https://github.com/minetest/minetest/commit/efc3bb513c8c0411b2251ae652ffe7cf624db30f |
18:52 |
|
doserj joined #minetest-dev |
19:03 |
|
SitDog joined #minetest-dev |
20:45 |
|
sitdog joined #minetest-dev |
21:27 |
celeron55 |
thexyz: i don't think that works |
21:28 |
celeron55 |
oh... |
21:28 |
celeron55 |
no, yes it should 8) |
22:30 |
|
rsiska joined #minetest-dev |
22:52 |
|
doserj joined #minetest-dev |
23:32 |
|
Pixxy joined #minetest-dev |