| Time |
Nick |
Message |
| 01:27 |
|
shadowzone joined #minetest-dev |
| 01:32 |
|
GrimKriegor joined #minetest-dev |
| 02:03 |
|
Zeno` joined #minetest-dev |
| 02:58 |
hmmmm |
jjeez |
| 02:59 |
hmmmm |
I'm just making braindead simple style changes in nodedef.cpp and all of a sudden those 100+ column lines are fixing themselves |
| 03:00 |
hmmmm |
I mean stuff like TileSpec *stile = &f->special_tiles[tile_index]; and then s/f->special_tiles[j]./stile->/ |
| 03:02 |
|
rickmcfarley joined #minetest-dev |
| 03:06 |
hmmmm |
this is a lot more time intensive than i thought it was |
| 03:07 |
hmmmm |
and all this is just so i can start work on the resolveNodeNames() improvement in a state of sanity |
| 03:40 |
|
Miner_48er joined #minetest-dev |
| 03:45 |
|
Hunterz joined #minetest-dev |
| 03:46 |
|
chchjesus__ joined #minetest-dev |
| 03:47 |
|
Hunterz1 joined #minetest-dev |
| 05:27 |
|
mos_basik joined #minetest-dev |
| 05:46 |
|
proller joined #minetest-dev |
| 05:49 |
|
Hunterz joined #minetest-dev |
| 05:53 |
|
NakedFury joined #minetest-dev |
| 06:08 |
hmmmm |
guys |
| 06:08 |
hmmmm |
when you're doing switch fallthrough, could you ACTUALLY FUCKING COMMENT THE SWITCH FALLTHROUGH |
| 06:09 |
hmmmm |
look, i do it |
| 06:09 |
hmmmm |
/* FALLTHROUGH */ |
| 06:09 |
hmmmm |
https://github.com/minetest/minetest/blob/master/src/nodedef.cpp#L705 |
| 06:10 |
hmmmm |
oh, git blame says TriBlade did that... I guess it's understandable because he's new, but come on guys, isn't it common sense? |
| 06:12 |
Zeno` |
I would say it's common sense |
| 06:12 |
Zeno` |
unless it's like lines 706-710 of course |
| 06:14 |
Zeno` |
I may not have even used fallthrough there though |
| 06:14 |
Zeno` |
I don't think repeating f->solidness = 0; break; would have been that much of an issue heh |
| 06:15 |
hmmmm |
I am pretty sure that's intended but I wouldn't know for certain unless I actually loaded minetest up and verified that it doesn't work if I were to add a break |
| 06:15 |
hmmmm |
https://github.com/minetest/minetest/blob/master/src/util/serialize.cpp#L252 |
| 06:15 |
Zeno` |
Well that's why the comment is always necessary |
| 06:15 |
hmmmm |
I've seen some pretty dumb mistakes go into minetest |
| 06:15 |
Zeno` |
otherwise you don't know if the person simply forgot (happens) or they intended it |
| 06:15 |
hmmmm |
this is my favorite (thanks RBA): if (enable_shaders); { ... |
| 06:16 |
Zeno` |
:) |
| 06:20 |
Zeno` |
maybe he meant it |
| 06:34 |
RealBadAngel |
nobodys perfect hmm |
| 06:34 |
hmmmm |
speaking of which |
| 06:35 |
hmmmm |
are you actually nevermind |
| 06:35 |
RealBadAngel |
i did play it and i loved it |
| 06:35 |
hmmmm |
I just condensed a lot of bloaty, repetitive code in nodedef.cpp |
| 06:35 |
RealBadAngel |
do you remember? |
| 06:36 |
RealBadAngel |
most lovely rpg game out there imho |
| 06:37 |
|
chchjesus joined #minetest-dev |
| 06:38 |
RealBadAngel |
hmmm can i see the results? |
| 06:46 |
Zeno` |
well, when you look at the push I did yesterday just remember you said to do it the ugly way for now hehehe |
| 06:47 |
|
kaeza joined #minetest-dev |
| 06:52 |
hmmmm |
special tiles can't use their own special shaders? |
| 07:07 |
Zeno` |
https://github.com/minetest/minetest/pull/1711 <-- parse.h. What's the minetest "style" recommendation for including includes like that? |
| 07:08 |
Zeno` |
Seems overkill to me, but I am still not fully tuned with the minetest way |
| 07:08 |
|
Wayward_One joined #minetest-dev |
| 07:10 |
hmmmm |
maybe it should go into util/string.cpp |
| 07:11 |
hmmmm |
I have stuff like read_seed() and the flag string parsing in there |
| 07:11 |
hmmmm |
also I would revise the flow of parseColorString() |
| 07:12 |
hmmmm |
instead of if (thing) { /* ungodly huge if block with nothing underneath it */ |
| 07:12 |
Zeno` |
probably yes. He seems to have copy pasted it "as is" from it's original location |
| 07:12 |
hmmmm |
howabout |
| 07:12 |
hmmmm |
if (!thing) { |
| 07:12 |
hmmmm |
do stuff that was underneath that huge block |
| 07:12 |
hmmmm |
return; |
| 07:12 |
hmmmm |
} |
| 07:12 |
Zeno` |
Well, that's how I'd do it but it's not my PR :D |
| 07:12 |
hmmmm |
i'll comment on it |
| 07:12 |
Zeno` |
thank you |
| 07:12 |
Zeno` |
sounds better coming from you |
| 07:13 |
Zeno` |
also, I know it's pedantic, but: newlines at EOL |
| 07:13 |
Zeno` |
EOF* |
| 07:14 |
hmmmm |
yes |
| 07:15 |
hmmmm |
oh boy |
| 07:15 |
hmmmm |
there was a nodedef.cpp modification yesterday |
| 07:15 |
hmmmm |
I'm gonna have lots of fun merging these |
| 07:18 |
|
chchjesus joined #minetest-dev |
| 07:21 |
|
alexxs joined #minetest-dev |
| 07:23 |
hmmmm |
https://github.com/kwolekr/minetest/commit/01ce57ade534f83d80bbb1f0c48630891b338237 |
| 07:25 |
hmmmm |
RealBadAngel, https://github.com/kwolekr/minetest/blob/master/src/nodedef.cpp#L798 |
| 07:26 |
hmmmm |
there was literally nothing different between those two huge hunks of code aside from the tile and tiledef it's reading from. prime candidate for refactoring |
| 08:02 |
|
ImQ009 joined #minetest-dev |
| 08:08 |
|
BlockMen joined #minetest-dev |
| 08:19 |
|
jin_xi joined #minetest-dev |
| 08:21 |
|
alexxss joined #minetest-dev |
| 08:21 |
|
alexxss joined #minetest-dev |
| 08:30 |
|
PenguinDad joined #minetest-dev |
| 08:33 |
sfan5 |
ShadowNinja: ping |
| 08:33 |
Zeno` |
hmmm when you're finished styling can you check #1707? |
| 09:12 |
|
Amaz joined #minetest-dev |
| 09:29 |
Zeno` |
My PRs don't even get tags anymore ROFLOL |
| 09:30 |
BlockMen |
sfan5, fine with https://github.com/BlockMen/minetest_game/commit/56cc4191ca4ce238f724805a3b180d0f3586fdf0 ? |
| 09:30 |
sfan5 |
BlockMen: yep |
| 09:31 |
Zeno` |
I'm not. See last comment |
| 09:31 |
Zeno` |
it's not standard C++ |
| 09:31 |
Zeno` |
oh that one. sorry |
| 09:31 |
BlockMen |
lel |
| 09:32 |
Zeno` |
hey. it's 7:30PM (late!) |
| 09:33 |
|
alexxss joined #minetest-dev |
| 09:33 |
|
restcoser joined #minetest-dev |
| 09:35 |
BlockMen |
Zeno`, it seems you commented on outdated code. there are no newlines missing. |
| 09:38 |
Zeno` |
I did? I refreshed, but if that's the case then cool :) |
| 09:38 |
Zeno` |
I'll edit the comment |
| 09:41 |
Zeno` |
ok |
| 09:42 |
Zeno` |
BlockMen, I like it by the way |
| 09:42 |
Zeno` |
Seems like a good addition |
| 09:43 |
BlockMen |
Zeno`, if not it should go in ;) |
| 09:43 |
Zeno` |
So... if I don't like it it will go in? I don't like it then |
| 09:43 |
Zeno` |
lol |
| 09:45 |
BlockMen |
the other part |
| 09:45 |
BlockMen |
"good addition" |
| 09:45 |
BlockMen |
not "I like" ;P |
| 09:45 |
Zeno` |
oh. yes |
| 09:47 |
BlockMen |
and since you wanted labels, you pull has no two |
| 09:47 |
BlockMen |
+w |
| 09:48 |
Zeno` |
what's the reasoning behind video::SColor outcolor(255, 255, 255, 255); |
| 09:49 |
Zeno` |
I don't think it's low priority :p |
| 09:49 |
Hunterz |
is possible using mod change texture of digged node for player who only observe? |
| 09:49 |
Zeno` |
lol |
| 09:49 |
Zeno` |
I can't even play the game without the fix |
| 09:50 |
Hunterz |
now only player who dig node see changing texture |
| 09:50 |
BlockMen |
Zeno`, low priority since most did not agree here on IRC on you thoughts on it |
| 09:50 |
Zeno` |
Shadowzone, hmmmm and VanessaE did |
| 09:51 |
BlockMen |
Hunterz, i dont think that you can do that |
| 09:51 |
Hunterz |
when dig stone see changes on stone |
| 09:51 |
Hunterz |
breaking |
| 09:51 |
Zeno` |
see: https://github.com/minetest/minetest/pull/1704 |
| 09:51 |
Hunterz |
others players neear see nothing changed |
| 09:51 |
Zeno` |
which is broken and closed |
| 09:52 |
Zeno` |
ShadowNinja* |
| 09:52 |
Hunterz |
digging effect or something |
| 09:52 |
BlockMen |
Zeno`, ask someone else to make it high prio. for me its not |
| 09:54 |
BlockMen |
Hunterz, no, not supported currently. |
| 09:54 |
Hunterz |
ok, thanks |
| 09:54 |
Zeno` |
BlockMen, I didn't realise you were most players :) |
| 09:55 |
BlockMen |
Zeno`, never said or claimed to be ;) |
| 09:58 |
Zeno` |
BlockMen, https://github.com/minetest/minetest/pull/1661 |
| 09:59 |
Zeno` |
notice that the description is kind of wrong... |
| 10:00 |
Zeno` |
and it swaps items without warning |
| 10:00 |
Zeno` |
it's broken |
| 10:03 |
BlockMen |
Zeno`, i wont touch it now, sry |
| 10:13 |
|
proller joined #minetest-dev |
| 10:19 |
|
edlothiol joined #minetest-dev |
| 11:20 |
|
PilzAdam joined #minetest-dev |
| 11:21 |
|
ImQ009 joined #minetest-dev |
| 11:26 |
|
ImQ009 joined #minetest-dev |
| 11:54 |
|
kaeza joined #minetest-dev |
| 12:26 |
BlockMen |
can https://github.com/minetest/minetest/pull/1635 get closed? |
| 12:44 |
Hunterz |
im trying compile minetest with no bundled lua and get this error during linking: CMakeFiles/minetestserver.dir/script/cpp_api/s_base.cpp.o: In function `ScriptApiBase::ScriptApiBase()': |
| 12:44 |
Hunterz |
s_base.cpp:(.text+0x122): undefined reference to `luaJIT_setmode' |
| 12:44 |
Hunterz |
anyone can help? |
| 12:46 |
|
shadowzone joined #minetest-dev |
| 12:46 |
|
shadowzone joined #minetest-dev |
| 12:50 |
|
alexxsss joined #minetest-dev |
| 13:09 |
PilzAdam |
BlockMen, I guess yes |
| 13:36 |
|
AnotherBrick joined #minetest-dev |
| 13:39 |
|
ImQ009 joined #minetest-dev |
| 14:29 |
hmmmm |
ahh good catch RBA |
| 14:29 |
hmmmm |
thank you |
| 14:30 |
hmmmm |
except that doesn't actually fix it. special tiledefs are broken now |
| 14:32 |
hmmmm |
RealBadAngel: why is it that f->tiledef_special[j].backface_culling is used for special nodes, but f->tiledef[j].backface_culling isn't?? |
| 14:51 |
RealBadAngel |
back face culling is modified on the fly |
| 14:51 |
RealBadAngel |
it isnt hardcoded in def |
| 14:51 |
RealBadAngel |
gbrb |
| 14:52 |
RealBadAngel |
*brb |
| 14:54 |
|
RealBadAngel joined #minetest-dev |
| 14:55 |
RealBadAngel |
sorry had to reboot |
| 14:55 |
RealBadAngel |
open source video drivers suck big time |
| 14:55 |
RealBadAngel |
half frame rate and hangs all the time |
| 14:56 |
RealBadAngel |
hmmmm, i think we shall make this consistent |
| 14:57 |
RealBadAngel |
that can be really confusing |
| 14:57 |
hmmmm |
wait huh |
| 14:57 |
RealBadAngel |
content feature is modified on the fly |
| 14:57 |
hmmmm |
but why isn't that modification copied over to the tiledef |
| 14:58 |
RealBadAngel |
^^ |
| 14:58 |
RealBadAngel |
its based on def but not strict |
| 14:58 |
RealBadAngel |
thus cannot be used to define the material |
| 14:59 |
RealBadAngel |
too many things can modify it |
| 14:59 |
RealBadAngel |
like opaque water/waving leaves etc |
| 15:00 |
|
proller joined #minetest-dev |
| 15:03 |
|
Anchakor joined #minetest-dev |
| 15:05 |
RealBadAngel |
why you think that special tiles are broken? |
| 15:11 |
hmmmm |
i don't think they're broken, i just don't understand why the special tile filling is different from the regular tile filling |
| 15:12 |
RealBadAngel |
special tiles are kinda hacky |
| 15:12 |
RealBadAngel |
thats not my code neihter |
| 15:12 |
hmmmm |
whose is it?? |
| 15:13 |
RealBadAngel |
propably c55, but just guessing |
| 15:13 |
hmmmm |
hmm |
| 15:13 |
RealBadAngel |
i see different usage for special tiles |
| 15:13 |
hmmmm |
so do you know if it's necessary to have the different backspace culling attribute for special tiles? |
| 15:14 |
hmmmm |
see: https://github.com/minetest/minetest/blob/5baf379f40537060a1d5111905c7702d4563ee5c/src/nodedef.cpp#L795 |
| 15:14 |
RealBadAngel |
yes, special tiles imho should be an alternative |
| 15:14 |
RealBadAngel |
but they need also alternative light source value to be really useable |
| 15:15 |
RealBadAngel |
all the other code is already in |
| 15:15 |
hmmmm |
RealBadAngel, by the way, do you realize there is a 80 column line size limit? |
| 15:15 |
hmmmm |
it's preferred to stay under 80, but it's absolutely necessary to stay under 90 |
| 15:17 |
RealBadAngel |
sorry, where i exceeded that? |
| 15:18 |
RealBadAngel |
sometimes its hard for me to notice that, im on wide screen |
| 15:18 |
RealBadAngel |
80 lines here is merely half a scren width |
| 15:18 |
hmmmm |
yeah... |
| 15:19 |
hmmmm |
most IDEs have a vertical line at 80 characters |
| 15:19 |
hmmmm |
also perhaps you should start making better use of your horizontal space with a split screen view |
| 15:19 |
BlockMen |
even notepad has :D |
| 15:21 |
hmmmm |
https://github.com/minetest/minetest/commit/173beeee65289464d2541c44f753d21cd1fa3155 |
| 15:21 |
hmmmm |
I also switched the parameters around |
| 15:22 |
|
zat joined #minetest-dev |
| 15:24 |
|
selah joined #minetest-dev |
| 15:26 |
|
shadowzone joined #minetest-dev |
| 15:32 |
RealBadAngel |
hmmmm, i think that will be wrong |
| 15:32 |
RealBadAngel |
f->tiledef_special[j].backface_culling, |
| 15:32 |
hmmmm |
no, no, that's what the code originally was before my cleanup commit |
| 15:33 |
hmmmm |
it looks weird, doesn't it? |
| 15:33 |
hmmmm |
that's why I inquired about it |
| 15:33 |
RealBadAngel |
thats a mess indeed |
| 15:34 |
RealBadAngel |
atm i have no idea how to make it cleaner |
| 15:34 |
hmmmm |
well we don't know why f->tiledef_special[j].backspace_culling is needed |
| 15:34 |
RealBadAngel |
not to mention i do have large portion of code that modifies it already |
| 15:35 |
RealBadAngel |
i do have nearly completed drawtype mesh |
| 15:35 |
RealBadAngel |
which does a few things just by the way |
| 15:35 |
RealBadAngel |
one of them is massively speed up of nodeboxes code |
| 15:36 |
hmmmm |
cool |
| 15:37 |
RealBadAngel |
i just chosen to convert them into meshes |
| 15:37 |
|
proller joined #minetest-dev |
| 15:37 |
RealBadAngel |
and cache the possible rotations |
| 15:37 |
RealBadAngel |
so the only thing that can change the mesh is the daynight cycle |
| 15:42 |
|
iqualfragile joined #minetest-dev |
| 15:43 |
BlockMen |
RealBadAngel, what do you mean with change in this context? |
| 15:43 |
BlockMen |
the lighting? |
| 15:44 |
|
Hunterz joined #minetest-dev |
| 15:45 |
RealBadAngel |
BlockMen, not the lighting, turning nodeboxes into meshes at startup |
| 15:45 |
RealBadAngel |
so theyre preconverted to drawtype mesh |
| 15:49 |
BlockMen |
and how is that related to the daynight cycle? |
| 15:50 |
RealBadAngel |
lighting is applying the vertex color |
| 15:50 |
RealBadAngel |
to the mesh |
| 15:52 |
|
Taoki[mobile] joined #minetest-dev |
| 16:01 |
|
Megaf joined #minetest-dev |
| 16:25 |
|
kaeza joined #minetest-dev |
| 16:44 |
|
rubenwardy joined #minetest-dev |
| 16:55 |
|
NakedFury joined #minetest-dev |
| 17:00 |
|
BlockMen left #minetest-dev |
| 17:11 |
|
gravgun joined #minetest-dev |
| 17:12 |
gravgun |
Hi, has any work been already done to create a custom node rendering Lua API? |
| 17:12 |
sfan5 |
no |
| 17:13 |
gravgun |
I'm thinking of a node def format that could work |
| 17:13 |
gravgun |
However I know calling custom Lua render functions 60 times a second is heavy... |
| 17:14 |
sfan5 |
s/heavy/totally not a good idea/ |
| 17:14 |
gravgun |
sadly... |
| 17:14 |
sfan5 |
without LuaJIT you don't even need to consider that idea |
| 17:14 |
sfan5 |
even with it's still not a good idea |
| 17:14 |
kaeza |
how about specifying draw commands, kinda like shaders or SVG? >_> |
| 17:15 |
kaeza |
...or WMF <_< |
| 17:15 |
gravgun |
ewww WMF |
| 17:15 |
gravgun |
but that'd require one more "language"+parser |
| 17:16 |
sfan5 |
what you'd need if some kind of basic gfx language that can be compiled to machine code or something |
| 17:16 |
gravgun |
or using somehow complicated def structures if the "shader" gets complex |
| 17:16 |
gravgun |
Android RenderScript? |
| 17:16 |
sfan5 |
whats that? |
| 17:17 |
gravgun |
A rather high-level LLVM-compiled code that somehow gets translated to native CPU code + shader, used rarely in Android... |
| 17:17 |
sfan5 |
does it do 3D? |
| 17:18 |
gravgun |
Dunno, I've seen 2D particles examples in the Android SDK but that's all |
| 17:18 |
sfan5 |
what we'd need is more like a language that can call irrlicht and is near native speed |
| 17:19 |
sfan5 |
LLVM is not something we can use |
| 17:19 |
sfan5 |
I don't think anyone wants to go through the troubles of compiling LLVM for windows |
| 17:20 |
gravgun |
And isn't dynamically linking to CPP code way harder than C? Good luck with Irr then |
| 17:20 |
sfan5 |
you could do a C -> C++ interface for the funcs needed |
| 17:21 |
gravgun |
What comes to my mind then is tcc (Tiny C Compiler, by the same guy that wrote the Bochs emulator, very light and waaaaay faster than GCC) |
| 17:22 |
gravgun |
Plus it can be embedded with libtcc... |
| 17:22 |
gravgun |
But that may be a lil' out of scope of the Minetest project |
| 17:23 |
gravgun |
(and some CPU architecture may be left behind as tcc geneates native code) |
| 17:23 |
sfan5 |
e.g. ARM |
| 17:24 |
gravgun |
IIRC tcc does have an ARM compiler |
| 17:24 |
sfan5 |
what you need to support is i386, x86_64, ARMv6, ARMv7 and ARM64 |
| 17:24 |
sfan5 |
source: http://meow.minetest.net/tmp/serverlist_stats_2014-09-2014.txt |
| 17:25 |
gravgun |
tcc's arm-gen.c, 2nd line: "ARMv4 code generator for TCC" |
| 17:26 |
gravgun |
Well... |
| 17:26 |
sfan5 |
generating armv4 when armv{6,7} is supported probably doesn't help speed |
| 17:26 |
gravgun |
And ARM w/ VFP only, no fixed point |
| 17:28 |
gravgun |
"probably doesn't help speed", native code is always better than interpreted |
| 17:29 |
sfan5 |
yeah |
| 17:29 |
gravgun |
(except when interpreters JIT optimizes really hard, e.g. luaJIT) |
| 17:29 |
sfan5 |
but I mean potential is lost if you target v4 and run on v6 or v7 |
| 17:29 |
gravgun |
Yes |
| 17:30 |
gravgun |
Forcing LuaJIT may be an option then, using our own Irrlicht C++ -> C wrapper and LuaJIT's FFI |
| 17:31 |
sfan5 |
LuaJIT doesn't work on arm64, does it? |
| 17:33 |
gravgun |
Nope |
| 17:33 |
gravgun |
The Cocos2dx game framework, which uses LuaJIT, has problems with this on iPhones 5+ (arm64) |
| 17:34 |
gravgun |
And so we will if we head this way |
| 17:34 |
sfan5 |
then we can't force luajit |
| 17:34 |
|
Calinou joined #minetest-dev |
| 17:34 |
sfan5 |
2% of people playing the latest release use a device with arm64 |
| 17:35 |
gravgun |
Meh... |
| 17:35 |
gravgun |
And writing a whole VM is not an option either, is it? |
| 17:35 |
Calinou |
>VM >Minetest |
| 17:35 |
Calinou |
you know it already |
| 17:35 |
sfan5 |
a vm is not that hard? |
| 17:35 |
sfan5 |
s/?// |
| 17:35 |
gravgun |
Well it's supposed to be very light in this case |
| 17:36 |
gravgun |
I never wrote a VM but that'd be fun :) |
| 17:38 |
gravgun |
But darn, Minecraft is written in Java, and custom rendered blocks aren't *that* heavy |
| 17:38 |
sfan5 |
says the person with a good computer? |
| 17:39 |
gravgun |
:P |
| 17:39 |
Calinou |
Minecraft runs well, yet is heavy |
| 17:39 |
Calinou |
don't mix both |
| 17:40 |
gravgun |
"custom rendered blocks aren't *that* heavy" compared to the whole game then |
| 17:40 |
VanessaE |
custom-rendered blocks? sounds like mesh draw type. |
| 17:40 |
gravgun |
They already aid much in this regard |
| 17:40 |
gravgun |
especially "nodebox" |
| 17:40 |
sfan5 |
VanessaE: custom is supposed to mean 100% custom, e.g. depending on param1, depending on sourroundings |
| 17:41 |
sfan5 |
like re-implementing the new firelike drawtype |
| 17:41 |
gravgun |
<anachist>custom, so I can draw *rounded* shapes in the world</anarchist> |
| 17:41 |
Calinou |
nodebox rendering speed can be improved by not setting coordinates every frame |
| 17:41 |
Calinou |
like VanessaE says |
| 17:41 |
Calinou |
RealBadAngel said he has a solution to it |
| 17:42 |
Calinou |
gravgun, use the meshnodes for that! |
| 17:42 |
Calinou |
lets you replace node models by arbitrary model (can it be animated though? not sure) |
| 17:42 |
Calinou |
RealBadAngel made this a few days ago, but not merged yet |
| 17:43 |
sfan5 |
Calinou: can you re-implement something like "firelike" entirely without engine changes with that? |
| 17:43 |
Calinou |
if we can put animated textures on it, then yes |
| 17:44 |
Calinou |
ask RBA for whether you can animate model and/or texture |
| 17:44 |
sfan5 |
wut |
| 17:44 |
Calinou |
the other problem here, is, is wallmounted paramtype supported? |
| 17:44 |
Calinou |
to use one model per orientation |
| 17:44 |
sfan5 |
how can you do sourrounding-dependent stuff with models? |
| 17:44 |
sfan5 |
I'm not talking about wallmounted here |
| 17:45 |
sfan5 |
using wallmounted for a firelike drawtype would be a hack |
| 17:45 |
Calinou |
so fire is surrounding-dependant and not just wallmounted? |
| 17:45 |
|
ImQ009 joined #minetest-dev |
| 17:45 |
sfan5 |
fire is not wallmounted at all |
| 17:45 |
Calinou |
then we need surrounding-dependant nodeboxes and meshnodes in the engine |
| 17:45 |
Calinou |
then we can do everything |
| 17:45 |
sfan5 |
param1 is just ignored |
| 17:45 |
sfan5 |
>surrounding-dependant nodeboxes |
| 17:45 |
Calinou |
that'd replace fences too |
| 17:45 |
sfan5 |
that still doesn't allow me to implement firelike in lua |
| 17:45 |
Calinou |
meshnodes then |
| 17:46 |
sfan5 |
you don't get what I mean |
| 17:46 |
sfan5 |
I can come up with thousands of things you can't do even with surrounding-dependant nodeboxes or meshnodes |
| 17:46 |
sfan5 |
if you want to offer the full potential you need custom renderers |
| 17:50 |
gravgun |
On a related note: what if one wants directly create a texture (i.e a computer screen w/ custom graphics/text)? (I thought of a minetest.Bitmap class, convertible to a minetest.Texture which is just a reference to irr::video::ITexture) |
| 17:50 |
gravgun |
(Bitmap -> Texture conversions means GPU bitmap upload) |
| 17:50 |
sfan5 |
you can do that in a very hacky way using texture modifiers |
| 17:51 |
sfan5 |
you can't set the texture of a node too |
| 17:51 |
gravgun |
"very hacky way"s bother me |
| 17:51 |
|
exio4_ joined #minetest-dev |
| 17:51 |
sfan5 |
so you'd need to use entities anyway |
| 18:00 |
|
Taoki[mobile] joined #minetest-dev |
| 18:07 |
Megaf |
Folks, how to I enable the GLES support if Im compiling minetest client on an ARM device? |
| 18:07 |
Megaf |
Actually on ARM you dont even need X |
| 18:07 |
Megaf |
XBMC and Quake III for example, they dont use X on the Raspberry Pi |
| 18:08 |
Megaf |
and Quake III run very fast with all things on max |
| 18:08 |
Megaf |
Minetest mush run quite fast too |
| 18:08 |
Megaf |
must* |
| 18:14 |
|
Miner_48er joined #minetest-dev |
| 18:19 |
sfan5 |
Megaf: use irrlicht ogles |
| 18:23 |
|
gravgun joined #minetest-dev |
| 18:25 |
Megaf |
sfan5: oops, Im compiling the standard irrlicht already |
| 18:26 |
Megaf |
sfan5: this one? https://github.com/kexplo/irrlicht_ogl-es.git |
| 18:26 |
sfan5 |
Megaf: read http://irrlicht.sourceforge.net/contributing/ |
| 18:26 |
sfan5 |
And the experimental OpenGL ES driver is here: |
| 18:26 |
sfan5 |
svn://svn.code.sf.net/p/irrlicht/code/branches/ogl-es |
| 18:27 |
sfan5 |
</quote> |
| 18:28 |
Megaf |
sfan5: Ok, thanks |
| 18:31 |
gravgun |
Megaf: "Actually on ARM you dont even need X; XBMC and Quake III": those use DirectFB, Irrlicht has no support for this |
| 18:31 |
gravgun |
Well it has but is experimental |
| 18:31 |
sfan5 |
"Actually on ARM you dont even need X" |
| 18:31 |
sfan5 |
wat |
| 18:31 |
gravgun |
On any platform you can do w/o X |
| 18:31 |
sfan5 |
needing a program does not have anything to do with the cpu arch |
| 18:32 |
gravgun |
You can do w/o X with either DirectFB, /dev/[graphics]/fbX direct access, or /dev/[dri/]cardX with KMS+GBM+DRM |
| 18:33 |
Megaf |
Im afraid to ask, whats the equivalent in svn to git clone? |
| 18:33 |
gravgun |
>"Well it has but is experimental", woops, was wrong |
| 18:33 |
gravgun |
svn co / svn checkout |
| 18:34 |
Megaf |
hm |
| 18:41 |
Megaf |
Thanks sfan5 and gravgun |
| 18:43 |
gravgun |
Coming back to the custom renderer problem: a node def property "on_render", function(pos) could return some kind of mesh definition table |
| 18:43 |
sfan5 |
thats not exactly a custom renderer |
| 18:43 |
sfan5 |
like you said a VM would be good |
| 18:43 |
gravgun |
but who says VM says compiler |
| 18:44 |
gravgun |
and who says compiler says parser |
| 18:44 |
sfan5 |
not exactly |
| 18:44 |
sfan5 |
let the people do assembly< |
| 18:44 |
gravgun |
this |
| 18:44 |
gravgun |
what I thought |
| 18:44 |
gravgun |
but may be too hardcore |
| 18:44 |
sfan5 |
nah |
| 18:44 |
sfan5 |
people can write parsers/compilers for that if they want to |
| 18:45 |
gravgun |
make some simplified instruction set (like how easy ARM assembly is compared to x86) and yes, why not |
| 18:48 |
|
diemartin joined #minetest-dev |
| 18:51 |
|
selah joined #minetest-dev |
| 18:56 |
|
Amaz joined #minetest-dev |
| 18:57 |
gravgun |
The VM solution seems good actually (I recall Garry's Mod Wire's GPU code being written in an assembly format, whose VM is itself written in Lua, but was made to be as fast as possible) |
| 19:05 |
|
iqualfragile joined #minetest-dev |
| 19:06 |
gravgun |
sfan5: Something like this: http://socrates.io/#IjX71wj ? |
| 19:07 |
|
kilbith joined #minetest-dev |
| 19:08 |
sfan5 |
gravgun: basically yes |
| 19:08 |
sfan5 |
gravgun: one thing I'd like: call method, arg1, arg2, arg3 instead of push arg3; push arg2; push arg1; push arg0; call method |
| 19:09 |
|
zat joined #minetest-dev |
| 19:10 |
gravgun |
"push" (and "pop") suggests stack-based model |
| 19:10 |
sfan5 |
yes |
| 19:10 |
sfan5 |
stack based is better IMO |
| 19:11 |
gravgun |
given that minetests uses strings as node IDs, metadata names and so on |
| 19:11 |
gravgun |
registers would hold different types of data... |
| 19:11 |
gravgun |
cuz' dealing with strings w/ only integer registers would be a PITA |
| 19:12 |
sfan5 |
strings are not used for nodes |
| 19:12 |
sfan5 |
nodes actually have IDs |
| 19:13 |
gravgun |
IDstring:IDint translation table isn't it |
| 19:13 |
sfan5 |
basically |
| 19:14 |
gravgun |
as for metadata names... |
| 19:14 |
gravgun |
which is probably *the* reason, alongside neighbouring blocks, why we write this |
| 19:17 |
sfan5 |
metadata.. |
| 19:17 |
sfan5 |
is more complicated |
| 19:17 |
sfan5 |
the "metadata" you have before doing any advanced stuff is just param1 |
| 19:17 |
sfan5 |
which is a number |
| 19:19 |
gravgun |
number that we should bitshift (or ANDed) to get light level in sunlight/not-sunlight |
| 19:20 |
gravgun |
need to add binary operators... |
| 19:20 |
gravgun |
btw, how many registers should we add? |
| 19:21 |
sfan5 |
umm no |
| 19:21 |
|
paramat joined #minetest-dev |
| 19:21 |
sfan5 |
thats param2 |
| 19:21 |
sfan5 |
or maybe the other way around |
| 19:21 |
gravgun |
paramtype = "light". The value stores light with and without sun in its upper and lower 4 bits. |
| 19:21 |
gravgun |
http://dev.minetest.net/node |
| 19:22 |
sfan5 |
param2 is the basic "metadata" you have then |
| 19:23 |
gravgun |
param1 and param2 should have a specific register then |
| 19:24 |
gravgun |
readonly though |
| 19:24 |
gravgun |
we only do rendering |
| 19:25 |
sfan5 |
why a register? |
| 19:25 |
sfan5 |
an address where param1 and 2 are always found suffices too |
| 19:26 |
paramat |
the feature that runs an ABM many times to compensate for the area being unvisited for a while ... i actually find that a big problem and would like to be able to disable that with a boolean in the ABM registration. Unfortunately i doubt i can code this change myself |
| 19:29 |
gravgun |
"why a register?" well I might not use the good term maybe (only did a very tiny little bit of assembly myself) |
| 19:51 |
Megaf |
sfan5: weird thing is, while compiling irrlight ogles it asks for GL/gl.h, just like the regular irrlicht do. http://paste.debian.net/plain/124380 Anyway, I isntalled that file and let's see what happens |
| 19:53 |
|
exio4 joined #minetest-dev |
| 20:10 |
|
proller joined #minetest-dev |
| 20:28 |
Calinou |
https://github.com/TriBlade9/minetest/commit/c22146a2b5073a7661dba202ec44dde9c2c23bc4 |
| 20:28 |
Calinou |
I am testing this |
| 20:29 |
sfan5 |
Megaf: you need to disable the opengl driver in irrlicht ogles |
| 20:32 |
|
casimir joined #minetest-dev |
| 20:44 |
|
Anchakor_ joined #minetest-dev |
| 20:46 |
Megaf |
now, minetest's cmake can't find OpenGL |
| 20:46 |
Megaf |
CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:97 (MESSAGE): |
| 20:46 |
Megaf |
Could NOT find OpenGL (missing: OPENGL_gl_LIBRARY) |
| 20:46 |
Calinou |
it works |
| 20:47 |
Megaf |
I dont want it to use OpenGL, its GL ES! |
| 20:58 |
|
gravgun left #minetest-dev |
| 21:11 |
|
SudoAptGetPlay joined #minetest-dev |
| 21:14 |
SudoAptGetPlay |
Hi, I want to read some user defined values from a discrete conf file of a mod. Is that possible with io.open(), etc ? |
| 21:14 |
|
shadowzone joined #minetest-dev |
| 21:16 |
RealBadAngel |
SudoAptGetPlay, example: https://github.com/minetest-technic/technic/blob/master/technic/config.lua |
| 21:16 |
SudoAptGetPlay |
thanks |
| 21:52 |
|
proller joined #minetest-dev |
| 22:00 |
* Megaf |
still havent succeeded in compiling minetest with ogles |
| 22:20 |
Megaf |
it was just a lib missing |
| 22:30 |
|
Gethiox joined #minetest-dev |
| 22:34 |
|
shadowzone joined #minetest-dev |
| 22:34 |
|
shadowzone joined #minetest-dev |
| 22:41 |
|
Gethiox joined #minetest-dev |
| 23:02 |
blaise |
Megaf: which lib? |
| 23:21 |
|
edlothiol joined #minetest-dev |
