| Time |
Nick |
Message |
| 00:08 |
MTDiscord |
<mistere_123> at this point, adding the tech debt of another server-sent-client-side-setting is miniscule and is vastly outweighed by the benefit of fixing engine bugs now and for the next several years until 6.0 |
| 00:40 |
MTDiscord |
<luatic> SSCSM hopefully isn't gonna be a 6.0 thing; removing serverside APIs in favor of cleaner SSCSM APIs is what's gonna be a 6.0 thing |
| 01:28 |
MTDiscord |
<andrey2470t> If you add each such feature with the miniscule debt as you say, it will grow eventually from the miniscule one up to the vast one some day is what the engine actually has now. And btw bad implemented APIs are generally error-prone, because it becomes harder to modify the existent code and orient in that (like the Irrlicht's animated meshes, their bones, mapblocks meshgen, generic cao, sounds handlers and multiple other parts), so it |
| 01:28 |
MTDiscord |
could be explained by that why there's a such high bugs count |
| 01:29 |
MTDiscord |
<andrey2470t> If you add each such feature with the miniscule debt as you say, it will grow eventually from the miniscule one up to the vast one some day is what the engine actually has now. And btw bad implemented APIs are generally error-prone, because it becomes harder to modify the existent code and orient in that (like the Irrlicht's animated meshes, their bones, mapblocks meshgen, generic cao, sounds handlers and multiple other parts), so it |
| 01:29 |
MTDiscord |
could be explained by that why there's a such high bugs count |
| 01:36 |
MTDiscord |
<luatic> I think you're right in that this is definitely technical debt. But I would disagree about whether it is worth going into this particular technical debt. |
| 01:36 |
MTDiscord |
<luatic> Technical debt is incurred for much the same reasons as real debt: Because you need the money not sometime in the future, but now. |
| 01:37 |
MTDiscord |
<luatic> We want to deliver some important features to game developers that need them now. |
| 01:37 |
MTDiscord |
<luatic> And sometimes that means going into technical debt, despite knowing that a much better solution will eventually exist using SSCSM, the formspec replacement, or similar, because we don't want to wait on that. |
| 01:38 |
MTDiscord |
<luatic> I agree that at the same time, we must not lose sight of the bigger goals however. |
| 01:40 |
MTDiscord |
<luatic> But I think the technical debt incurred here is low interest. It isn't the spaghetti kind where everything is intertwined, a hydra where for each bug you fixed, two new bugs pop up. It's just one relatively nicely separated API feature that does a particular thing. It will require some work when a proper feature is implemented in the future, but it shouldn't be nearly as messy as e.g. skeletal animation. |
| 02:10 |
|
TheCoffeMaker joined #luanti-dev |
| 02:54 |
|
SpaceManiac joined #luanti-dev |
| 03:00 |
|
SFENCE_arch joined #luanti-dev |
| 03:53 |
|
SpaceManiac joined #luanti-dev |
| 04:09 |
|
SpaceManiac joined #luanti-dev |
| 05:00 |
|
MTDiscord joined #luanti-dev |
| 05:24 |
|
hwpplayer1 joined #luanti-dev |
| 06:44 |
|
SFENCE_arch joined #luanti-dev |
| 07:41 |
MTDiscord |
<andrey2470t> Do the important features, I just expressed my opinion here because I saw the potential hazard in making such decision which the community has already actually stumbled upon with. |
| 07:47 |
MTDiscord |
<andrey2470t> Under the technical debt I meant you refuse to do a proper long-term API now in swap to the simplicity and quickness of the implementaion and thus you auto get the debt in the form of the necessity of the refactoring such APIs afterwards waiting for them the dependencies like the SSCSM |
| 08:19 |
rubenwardy |
Waiting for the long term solution only works if the long term solution actually happens |
| 10:38 |
|
hwpplayer1 joined #luanti-dev |
| 11:21 |
|
SpaceManiac joined #luanti-dev |
| 11:57 |
|
hwpplayer1 joined #luanti-dev |
| 12:39 |
|
Desour joined #luanti-dev |
| 14:15 |
|
hwpplayer1 joined #luanti-dev |
| 14:34 |
|
SFENCE_arch joined #luanti-dev |
| 14:38 |
|
SFENCE joined #luanti-dev |
| 14:41 |
SFENCE |
According to ObjectLabel function problem. I get an answer, and looks like it is a problem on our side. |
| 14:42 |
SFENCE |
Interactions with OpenGL ES |
| 14:42 |
SFENCE |
This extension specification uses non-suffixed names for new entry points, types, and tokens. This is correct for implementations against OpenGL. However, when implemented in an OpenGL ES context, all new entry points, types, and tokens are given KHR suffixes. |
| 14:42 |
SFENCE |
Cite: https://registry.khronos.org/OpenGL/extensions/KHR/KHR_debug.txt |
| 14:43 |
SFENCE |
So, we are loading glObjectLabel for GLES also. But for GLES we should load glObjectLabelKHR. |
| 14:57 |
|
SFENCE joined #luanti-dev |
| 15:16 |
|
SFENCE joined #luanti-dev |
| 15:16 |
|
[MatrxMT] joined #luanti-dev |
| 15:22 |
sfan5 |
hmm |
| 15:35 |
|
SFENCE joined #luanti-dev |
| 15:46 |
SFENCE |
Verified that switching to glObjectLabelKHR fixes a problem. May I do separata PR for this, or keep it as part of #15451? |
| 15:46 |
ShadowBot |
https://github.com/luanti-org/luanti/issues/15451 -- Make Luanti buildable for iOS (iPhoneSimulator). by sfence |
| 15:58 |
|
SFENCE joined #luanti-dev |
| 16:35 |
sfan5 |
separate PR is good |
| 16:58 |
|
pmp-p joined #luanti-dev |
| 18:03 |
sfan5 |
@zughy can you test #15829? |
| 18:03 |
ShadowBot |
https://github.com/luanti-org/luanti/issues/15829 -- [no sq] Fix shadow performance regression due to force update by sfan5 |
| 18:03 |
sfan5 |
(i'm too lazy, sorry) |
| 18:39 |
|
fluxionary joined #luanti-dev |
| 18:47 |
[MatrxMT] |
<Zughy> on it |
| 18:57 |
[MatrxMT] |
<Zughy> sfan5: it works, thank you |
| 19:03 |
sfan5 |
great |
| 19:13 |
SFENCE |
ObjectLabel fix #15830 |
| 19:13 |
ShadowBot |
https://github.com/luanti-org/luanti/issues/15830 -- Fix ObjectLabel OpenGL ES issue. by sfence |
| 19:39 |
|
jonadab joined #luanti-dev |
| 20:57 |
|
SFENCE joined #luanti-dev |
| 21:09 |
|
hwpplayer1 joined #luanti-dev |
| 21:28 |
|
hwpplayer1 joined #luanti-dev |
| 22:33 |
MTDiscord |
<grorp> can I have a review on #15567, please? |
| 22:33 |
ShadowBot |
https://github.com/luanti-org/luanti/issues/15567 -- [no sq] Implement player:get_point_dir() and player:get_point_screen_pos() by grorp |
| 22:38 |
MTDiscord |
<grorp> I recently split the first commit (refactoring stuff) off into #15800 to make it easier to get reviewed, but tbh I think the original PR is not big enough to justify that (+201, -71 lines) |
| 22:38 |
ShadowBot |
https://github.com/luanti-org/luanti/issues/15800 -- TouchControls: touch_use_crosshair, dig/place simulation refactoring by grorp |
| 22:39 |
MTDiscord |
<grorp> so I would be more happy if someone could just review 15567 |
| 23:06 |
MTDiscord |
<grorp> actually, new idea: planning to merge #15800 with 1 approval rule thing later |
| 23:06 |
ShadowBot |
https://github.com/luanti-org/luanti/issues/15800 -- TouchControls: touch_use_crosshair, dig/place simulation refactoring by grorp |
| 23:33 |
|
panwolfram joined #luanti-dev |
