Which project was that?
This is interesting. So is this meaning that you can load am image directly from the image path and push it as a sprite texture straight off? And what args are going to be available? And how is path exactly used?
No, the path is not a file path on disc, it’s a resource name.
It’s what the resource will be known as.
It must not exist before (I’m not sure if it will throw an error).
It must also end with .texturec
The documentation unfortunately misses to make it any clearer.
The new dynamic texture features seem pretty cool and useful, I am giving them a try now. 
I’m curious how these decisions get made though. These features are cool and open up new possibilities, but they are fairly esoteric—the vast majority of projects won’t use them. They were added to the core engine, not as an extension, and from the commit log it seems they involved a fair amount of new code. Compare this to, say, a function to toggle fullscreen on desktop, which almost every desktop project needs, and which, from my understanding would hardly need new code, only a lua binding to call a GLFW function or two that’s already there.
Was this feature requested by a large sponsor or something? From what I’ve seen, the usual arguments against adding new features are: a) Not enough people have asked for it, and b) The engine’s core philosophy is to remain lightweight and the feature is not necessary for everyone.
6 Likes
Yes, it was requested by a sponsor.
This is absolutely true and it drives our decision making at all times! When it comes to the ability to manipulate existing textures and create new atlases (will be included in 1.4.2) it is something that has been requested many many times over the years. Examples:
- Modifying sprite atlas at runtime
- Atlas generation
- How would you go about adding Google Maps? - #8 by britzl
- Is it possible to build an atlas at runtime? (edit: or Tiling map)
The feature also goes hand in hand with other work such as the ability to trim transparent pixels and loading packed textures from for instance Texture Packer or using our own tools. We’re also working on multi paged atlases which is tangentially related to this work. Finally we also have multi texture atlases which is going to be helped by the work we’ve done now.
7 Likes
Just like with other built in code, it might eventually happen that we’ll move it into an extension.
Creating a new extension api for this could have been done from the start, but it was a border case I’d say. I still think more people will use these things than has actually voted for the issue.
1 Like
Yes it could be moved into an extension, but I think there’s several benefits to having low level functionality closer to the core than as an extension.
We are introducing new use cases in the engine that we haven’t really had before, i.e creating resources in runtime. These functions interact tightly with the resource system and collection/gameobject code for managing the created resources which means we would need to add a bunch of new APIs to the dmsdk to interact with these systems. This in turn requires us to commit to those apis a lot more in order to avoid breaking changes, as well as having unit tests running on every commit.
It’s our philosophy to have as much as possible as extensions where it makes sense, and of course we can always make this change later. But for now I don’t see any benefits of doing that at this stage of development since we will invest more in runtime resource management (creating buffers in runtime for example, which is highly requested afaik). And as Mathias points out, I think this will be useful for a lot more people than you’d think 
4 Likes
Hi @jhonny.goransson, I understand @ross.grams post slightly differently. He doesn’t call for the new dynamic texture features to be moved into an extension. He wonders why other features, that are probably useful for more people and would require less code, are not part of the core. Like fullscreen toggle for desktop development. I agree with him, this is a rather vital feature. Personally, I would love to see RenderCam being part of the core, too, if that were at all possible.
5 Likes
Yeah true, I think I answered something else or just justified our decision to not have it as an extension maybe 
But in any case regarding the fullscreen feature specifically, it’s unfortunately a bit more work than exposing glfw functions - the (heavily modified) version we are using doesn’t support toggling video mode without deleting the GL context it seems, so we’d have to do something similar to what defos does. Which of course is doable, but we don’t know exactly how right now and probably don’t have time to solve it right now I’m afraid… But I agree, it’s something we should have.
3 Likes
Hmm, so what does DefOS do?
Actually there’s quite a bit more code than you’d think. Here’s the PR for mouse lock which we added recently (a little over 300 lines of code in total):
2 Likes
It would be nice to have this function in the engine, but there is a huge difference between these two things:
For now you can make your game full screen just by installing an extension.
But you can’t manipulate resources in runtime even if you really need it.
6 Likes
Thank you three devs very much for the explanation concerning the fullscreen toggle feature.
2 Likes
Answering this myself:
It does not call a function in glfw, instead it calls native functions per platform.
Thanks, this answers 80% of my question right here. 
Sorry, I wasn’t really trying to get into the weeds comparing these specific features, I more meant: Given that there are 1000 open issues, what made you decide to dedicate a week/fortnight/however-long of your very limited time to this specific issue, above the 999 others? Especially considering that it appears to fall in the same categories as things you have refused to work on in the past.
But again, if it was requested by a sponsor, then that pretty much answers the question. 
I have only one response: 
.
On the topic of Defold’s desktop support, well 
…I’ve been complaining about that for around 5 years and it has only improved by a few tiny steps (some only prompted by mobile development needs). Defold is mobile and web focused and that’s that.
How do you mean “refused to work on in the past.” ?
By “refused to work on”, I just mean:
- Github issues (often feature requests) that are closed without resolution.
- Forum bug reports or feature requests that have not been fixed or added to the core engine or an officially-supported extension.
- Any feature request where the user is directed to use an existing, less-than-desirable workaround instead.
- Any request or issue that has never been prioritized (never had plans made or code written for it).
- Arguably, any unresolved issue that is more than two or three years old.
In general, I mean anytime someone reports a problem or requests a feature, and it does not get fixed or added to the core engine or an officially-supported extension, and won’t be in the forseeable future. The kind of thing that happens multiple times every week.
Obviously this is often a good thing. Not everything can or should be added.
2 Likes
Also a note, that a lot of issues might be already outdated or actually even fixed/delivered - there is so much of them, that refining all of them is probably not possible in a reasonable time, but I believe it is something that step by step could be done (probably is sometimes, but still, the scale is overwhelming and growing).
1 Like
We’ve released several desktop games with Defold and have no issues, have not had any issues for years. I want everything in DefOS to be in core Defold too (it’s cool that it can be a community extension but it shouldn’t be)(I also strongly believe something like RenderCam+Orthographic should also be core, should be part of the standard), but they have still had limited resources. It absolutely makes sense they give priority to the companies keeping their lights on. But that doesn’t mean they are ignoring user requests, that seems like the majority of what they fix/add is not what the big funders ask for. The new texture features are very very very useful! They can enable complicated systems that advanced users can make and share with less advanced users so that they can use interesting things.
Can you give examples of this? I watch the Defold issues every day and I don’t see that but maybe I’m missing something.
closed issues list Issues · defold/defold · GitHub I do not see anything alarming in recent history
This kind of thing would be useful to do roundups listing outstanding things that are wanted added/fixed.
As an example, again I still want DefOS to be part of core too, but there is also nothing wrong with it. It enables everything I as a primarily desktop dev wants as far as those kinds of OS features go.
Squeaky wheel gets the oil. They don’t have unlimited time/money so have to prioritize, major issues do get solved in reasonable time.
Let’s make a thread for everything we would hope to see in 2023? New features / bugfix wise.
9 Likes
Eh, I lost count of how long I’ve been waiting to be able to define polygonal collision objects in the editor, but I can’t complain about everything else really.
Hopefully opening up the editor more to extensions scripting will give it the boost needed from the community and free up more time for the devs for really core features.
4 Likes