Sorry for being a broken record at this point, but personally I would like to see better PC support as a higher priority than consoles and other platforms. I’ve switched to using Love2D instead of Defold in large part because of this, and don’t feel like I can recommend Defold to people for desktop projects.
What’s your current list of desktop problems? Most of the issues I have had in the past have since been resolved for desktop platforms (except for pausing sim while minimized / resizing).
While I do recognize some shortcomings of the desktop builds I didn’t quite think them severe enough to warrant a move to another engine, especially not with the DefOS extension available from the Asset Portal. Please share your top three missing desktop features!
And we believe in you!
Dude, that’s awesome! Make sure to post the pics of the 3D print, would be awesome to see
Some feedback, though: the ratio on the plus symbol is a bit off—I reckon it’d look more correct if all the squares which constitute the plus symbol have equal width and height. This image should better convey what I mean.
Small size is one of benefit of defold. What about adding proguard, to android build pipeline.
It’s still on our radar, I added DEF-3495 to the growing list of NE features.
@britzl Yes, the move is not just about the desktop stuff, there’s physics, sound, and a bunch of smaller things. Defold is awesome(!), don’t get me wrong, but it doesn’t quite do all the things that I want but don’t have the skills or equipment to do myself (like cross-platform desktop features).
@Pkeod Does DefOS support linux? Not having linux is/was my biggest gripe. The readme doesn’t mention it, though I see some files for linux, so now I’m not so sure.
OK, top three features, besides the window and cursor stuff that DefOS already seems to handle nicely:
- Mouse capture & relative mode - Also unclear (from open issues, etc) with DefOS whether these work correctly and on all platforms.
- Multiple monitor support -
- Get number of displays. (and some name if possible).
- Get available resolutions for a display.
- Be able to set window position on any display.
- Keyboard scancode support - To gracefully handle non-QWERTY keyboard layouts. I don’t know how this would work with Defold’s existing input system.
- Get key name from scancode and vice versa.
~ bonus feature! ~
- Callbacks for when gamepads are plugged in and unplugged.
Honestly I don’t expect Defold to do any of this stuff anytime soon. It just seems weird to talk about consoles while desktop is still not nearly an equal citizen with mobile (but it’s 90% there). Even from a purely market-oriented view . . . the PC gaming market is huge! (though not King’s focus . . .) But it’s a self-fulfilling prophecy; No one wants to start a game based on the hope that the engine will have the features they need by the time they are done. The features need to exist first for them to choose the engine. I want to be able to tell any of my desktop-targeting friends using Unity, Godot, Gamemaker, Unreal, etc, that Defold is lighter, faster, and better—out-of-the-box and without qualifiers.
Thank you for the feedback!
DefOS is great, but I do acknowledge that it’s probably better if some of the features of DefOS would be integrated into the Defold core.
I belive DefOS handles all of this correctly, right @Pkeod?
These are good candidates for DefOS features.
Hmm, this shouldn’t be that hard to add support for I think.
Yep, this needs to be fixed. It’s on my list of things I want us to support within the next 6 months or so.
Mouse capture works, but relative mode, not so much. I remember having big issues with this because Defold doesn’t handle dx and dy properly. https://github.com/subsoap/defos/issues/64 I remember @Pkeod tried something hacky on Windows, but I’m not sure if he managed.
When it comes to screen resolutions, I’m a big proponent of not changing the desktop display resolution. At least on macOS, this requires capturing the display and that means the user can’t even Cmd-Tab out of it. Instead, you should change the scale of your render buffer. This can be done with Cocoa functions, but not without Defold’s cooperation. Instead, in our game we’re just rendering to a smaller render target from the render script when
scale != 1.
You can already move the window on any screen you want (client coordinates are across screens), but unfortunately you can’t query the bounds of each screen.
There is Linux support, albeit I’m not sure what’s the state of it. Coming back to DefOS to check things out on all platforms has been on my list, considering we want to release our game on all 3 desktop platforms, but the fact that my only computer is this Mac with no dual boot and VMs don’t play nice with OpenGL doesn’t make things easy.
We have a fix in the next release for 64 bit Ubuntu and the OpenGL initialization.
We use Parallels Desktop on our systems, and they work for us afaik.
Also, we can run the Windows builds via wine, and even DefOS behaves pretty good there.
What VM’s have you tried?
I agree with most of the features DefOS has should be core to Defold for desktop platforms. They are expected features for professional desktop releases for sure and if DefOS could be depreciated in the future in favor of using vanilla Defold that would be great! But still it’s nice to be able to implement the features as a community. If Defold team gradually implemented DefOS features that would be for the best long term.
@ChaosYu did the majority of Linux work I believe so would have to ask him about how it works. I have not tested Linux support in a while.
For the dx/dy windows locking you can look at this project for how I did it https://github.com/subsoap/fps
I was working on getting actual relative mouse cursor positions always without needing on_input for getting cursor position outside of window but that was never finished. I had it working but didn’t fully polish it and only did it for Windows.
I was also working on a gamepad extension for better support. My proof of concept worked (I think I was using DirectInput?) but again I didn’t polish and release. But the ability to finish and release is there for anyone else always. We can completely skip Defold’s gamepad support and use NEs to interface with gamepads directly. I know you are a skilled and resourceful programmer and it would be a big loss if you left this community for good!
@ross.grams could you make some issues on DefOS github for those feature requests?
As a pro dev who published to desktop and releases games on Steam, the current state of Defold and DefOS is good enough to ship PC games. Ideally I want DefOS features to be core Defold, but the opportunity still exists for community to make those features we want happen.
Console dev is another story. We have no power to add new targets. A Switch target would be a great commercial opportunity too, and console support may also be more of a chicken/egg situation where some pro devs are not choosing Defold because there is no console support yet.
@ross.grams since you’ve moved to love2d for now I’d like to ask what other features it has that you think is missing with Defold?
Cool! I only tried with VirtualBox, since that’s what’s free (and that was some time ago). Last time I tried it, it didn’t have OpenGL >1.1 drivers on Win10 with macOS hosts. I will give Wine a go if that doesn’t work again. I didn’t think to try it, thanks for the tip!
Wow… Wine works really good. I was using VirtualBox. But this is a much better option. Thanks for the tip
I’m glad to know I’m not insane in thinking the DefOS stuff should be in the Defold core.
@pkeod OK, made issues for the multiple monitor things.
Besides all these desktop features, I am missing Physics and Sound stuff with Defold. Not sure how people do sound with Defold, does everyone use the OpenAL extension, or do their games not have a pause feature?! And no pitch variation? I used Howler.js for my asteroids game, but that’s web-only of course.
As far as I can tell, Love exposes every feature of Box2D. It’s a long list of features. Multiple fixtures with different physical properties, polygons, edge shapes, chain shapes, all the different joints, ghost vertices, CCD, instantaneous point checks, raycasts (including multi-hit rays), and bounding box checks, get moment of inertia, get center of mass, custom collision response for dynamic bodies. And everything can be modified at any point in code. Categories and masks can be changed on the fly; density, friction, restitution etc., can all be modified; bodies of any shape, size, and properties can be constructed at runtime; and so on. I have used, would have used, or at least plan to use every one of these things.
Thank you for the feedback! It’s super valuable to get a “reality check” from our users! Sound improvements will be made and we need to think about how to proceed with physics. Either expose more of Box2D and/or extract into a native extension and allow the community to add missing features. Also there’s my Chipmunk 2D extension that could be worked on as an alternative to the built in physics.
Extracting Physics and making it an extension is probably the fastest route. Having said that physics could really use some tight editor integration. Being able to draw collisions or setup joints, etc visually in the editor is definitely a workflow and speed advantage.
We started using FMOD for our game. It’s only free for one game per year and the library does add a MB or so to the binary size, but FMOD Studio has been a really great tool to play with when iterating on SFX and filters. We’ve done things with it we wouldn’t have otherwise considered doing were they not so convenient.
I am currious. Is there something that is needed for DefOS that can’t be added by the community?
Saying that we want it to be a core feature in Defold feels like going against that we want things to be extensions. In this thread the Box2D Physics have been mentioned as a candidate to create into an extension instead of having it part of the Defold core.
Or is it manily thinking of having (something like) DefOS included by default and make it “opt out” to make it easier for new developers to find the functionality?
This gets me thinking that maybe the documention should point to some of the most recommended NE to make them easier to find for new users?
Well, I agree with you to some extent, but when core functionality simply is sub-par (like sound, physics and basic desktop features) we need to improve on them ourselves. We can then also decide to move the functionality to an extension, but that decision should be made separately from improving the provided functionality.
Yes, I’ve been thinking the same thing. We do this in some places (like the camera manual) but we should do it in other places as well.