Basically, the screen and world coordinates are so different (particularly when Zoom enter the fray) is a pain in the most intelligent part of me.
The fact trying to make an object stuck on the same Screen coordinate when the camera pan and zoom (and sometimes simply zoom) is so hard, with elements following the camera THEN jumping back (moving an object is VISIBLY slower than moving the camera), and sometimes even disapearing at some zoom level for reason of their own is horrible.
And you can’t replace it with Gui because Gui and Go communicate very badly (why ? Is there any reason for Gui and Go to not be able to Set and Get each other ?), and you can’t make Collision shapes in Gui (why ? It’s litteraly the simplest mean to make cascading UI).
There has to be a reason why dev refuse to make Screen and World have simple “World_to_Screen“ and “Screen_to_World” function. If that’s a coding problem, why not simply say it and let the community try to help you to resolve it ?
A mean to have an Object at fixed coordinate and zoom (as if it was simply attached to the Camera Object…) would help much : We could then make complex UI made of sprites with all the possibilities of the Game Objects (like Collisions). I’m trying that actually, but Defold is SO SLOW at moving my “UI object” when I move/zoom the camera…
And it’s so complicated it’s always buggy…
For example : I’m building an UI with Objects. That part is no problem. Objects works like a dream if you read the trigger in the good order in the script).
But The UI only appears if you click on some other object (As intended) with enable/disable.
With the camera in ortho mode, I have to take into account not only the world position, but the zoom for the UI appears and keep its “apparent” screen position with the good zoom level.
It’s laggy, but it’s work.
BUT : If I zoom past some point BEFORE (and only before) I enable the UI, some elements of the UI simply don’t show anymore. Ever. whatever I do after that.
I mean, come on ! It’s so complicated !
Please, of please, make at least ONE the those works :
GUI and GO can fully communicate by GET/SET (and functions like that).
Let us attach objects to the camera so some objects are ALWAYS at the same position and zoom level
Let us put some “fixed screen position/zoom” as stats for objects.
Let us simply just attach a second camera to an object, and the two images are just in front of each other
If GUI could use collision objects, it could be cool.
i missed the forum because i don’t regularly check the site for posts.
by far, the biggest pain point is how much the engine relies on extensions for common enough things.
audio effects. setting fullscreen. setting window title. locking and hiding the cursor. markup on text. lighting.
i’m sure there’s many other things that i’ve forgotten that others would like, too.
it’s just kind of annoying to either have to manually implement features, or go through the hassle of getting an extension for something that feels like it should just ship with the engine as-is, and i imagine it’s a big turn-off for people wanting to try out the engine. it makes it feel very incomplete.
and the biggest insult to injury is that a lot of those extensions are made by people on the defold team, so it’s really confusing to me. if the extension is so good, why not just… make it part of the engine?
but also not being able to use go functions in gui scripts. it can be frustrating when you want to attach a UI to an entity and can’t just use go.get_position on it, and instead have to store the position separately. quite inefficient. it feels like a very arbitrary limitation.
but for the record, i think that having a distinct GUI and GO system is beneficial, since it marks the boundary between working with screen space and world space.
Test made using an empty project. Exported to target platform using default settings. Release builds. The iOS, Android and Windows numbers represent the size on disk while the HTML5 number is uncached download size when gzipped. No optimizations. Release mode.
Can you be more specific?
I believe these will be added on desktop platforms as part of the window.* functions. We “recently” added window.set_size() for instance. And setting the title is already possible:
One VERY strong argument for having them as extensions, besides a small engine core, is the fact that the extension system encourages user contributions. It is orders of magnitude easier for anyone in the community to contribute an improvement to an extension compared to the engine. Contributions to extensions do not require you to install any additional SDKs or tools, while a contribution to the engine requires you to install SDKs and tools.
using an empty project as a comparison point isn’t that good considering that graphics, sound, code, and other assets are going to take that up a significant amount of space in comparison to that.
not to mention that 84MB is peanuts on desktop. and even considering mobile and web constraints, every executable has a smaller footprint for those platforms and again, game assets take up space too
by audio effects i mean things like doppler, reverb, that kind of stuff. i’m not saying we need full on Nyquist plugins a la audacity, but having some sort of audio extension system, be it lua or C++, could be very nice
will be added on desktop platforms as part of the window.* functions.
that’s good to know.
the extension system encourages user contributions
i suppose it lowers the technical barriers to entry which is good.
but i think that it has a knock on effect is that less people contribute to the engine than who would have.
but also extensions have their own issue of requiring a build server, of which setting it up locally is not the best defined.
while a contribution to the engine requires you to install SDKs and tools.
there’s a statement to be said here about simplified workflows and technical debt. regardless, i think that it’d be good for the project maintainers to perhaps reach out to the developers of widely-used extensions to see about getting them added officially.
but i suppose the bigger question would be given the above quote, what’s the point of developers ever making contributions if it’s so difficult compared to extensions. and the word extensions is underplaying the power since it is after all C++.
lightweight game engine is a natural oxymoron. Defold sits in this really strange spot between being a fully featured engine such as Godot or Unity, or a handy graphics sound and physics API wrapper like Love2D.
Well, those assets are likely roughly the same size across game engines.
The initial cost is still important, even for desktop (smaller download sizes, faster startup times)
not to mention that 84MB is peanuts on desktop
The point is that we target all platforms. Steam games account for only a small portion of the user base for games using Defold.
i think that it’d be good for the project maintainers to perhaps reach out to the developers of widely-used extensions to see about getting them added officially.
We occasionally add things to the core engine that users initially created as an extension.
but i suppose the bigger question would be given the above quote, what’s the point of developers ever making contributions if it’s so difficult compared to extensions
If it’s a feature that should go into the core engine, then it should go into the core engine.
But as mentioned, most of the use cases are best suited as extensions.