Woah, nice set of tutorials! Thank you for sharing!
thanks
I switched from Godot to Defold too, a while ago. Rendercam was kind of designed to make doing this stuff with Defold about as easy as it is with Godot—just a few checkboxes and things. Britzl’s Orthographic is also a great solution. Defold is a bit “lower-level” than Godot, and assumes you know a bit about how 3D graphics work.
3 Likes
Sorry for off-topic, but may I ask you - why did you switched? What was “bad” in Godot and “good” in Defold?
2 Likes
Ín my case its for using lua, and the easy of creating an exe file. in godot custom icons and some properties doesnt work.
and looking for a tool to stick with it. Looking for the right balance between full control of the libraries and the easy use of an engine. I try a lot of tools in many years, and now wants to try this, for lua, performance and learn different designs of making games, then I will choose the best engine or go down and check more frameworks or libraries (I only try love2d and like it, but one day I wish to go down and try a library (raylib for example))
3 Likes
The short version is: Godot is a slow, buggy, undocumented, untested mess, and the attitude of the people working on it ensures that it will stay that way. Defold is small, fast, excellently-documented, about as bug-free as you can hope for, and has a very helpful, professional community.
The long version is here: Anyone here who has worked with Godot?
I haven’t used Godot seriously for ages, but I did make a small test project with a recent version a couple months ago and it didn’t seem like much had changed. And I still get github notifications for issues that I reported or commented on that are still open (or got closed simply because they were old? What?!).
9 Likes
well, I think they are going to be the new Unity, with all that bad
I feel the pain of the original poster, for a 2D engine this is unnecessarily complicated. Once you arrive to the manual the first thing presented is a 3D camera with view frustum and all, when Defold is a 2D enigne first.
Even it says on somewhere in web and manual that Defold is a “full 3D” engine that’s very misleading , the engine is on top of a 3D api, but the 3D features are very limited and hidden.
Back to the camera, in other 2D engines is just a Translation(x,y) and Scale(x,y), or a world root node to translate and scale.
I have spend the whole day trying understanding how camera projection works and the render script. No doubt that the Orthographic camera extension form @britzl is great, but at the end I coudn’t make it work on my game today, day is over, have to work on this simple thing again on Thursday. When I only needed to translate the world in x, y, anything else… maybe zoom.
I have work with actual 3D engines, and you don’t have never to deal with camera projections, cameras are just there.
Defold should comes by default with a basic camera that we can make scroll and zoom, with a Fixed_Fit_Projection. I can’t imagine an example of a game or app that would need stretched screen, if they exists should be less than 1%.
I’ll keep going ahead and next time I’ll finally make it work, but for today this was very frustrating.
2 Likes
This morning I made several clarifications to the Camera and Render manuals.
The Camera manual now clearly state which camera properties that are used for Perspective cameras only. The Camera manual also clarifies the default render script and how to change from Orthographic to Perspective projection.
The Render manual clarifies the available projections supported by the default render script and how to use them.
Please let me know if there is still something that isn’t clear and I’ll try to improve further.
7 Likes
Thanks for the quick action, I’ll give a second second try.
1 Like
Everything is clear at the end, the problem I think is the amount of information at the entry point, when less is better.
Resulted that was in fact as easy as one line, the one that shared in the first post:
And what happens to him maybe was the same to me, that I got a black screen, freaked out and jumped to the documentation to make it worst. Because view of the camera do not center the screen on the position of the camera, but in the left bottom of it.
Where is the source of the confusion that may happen to any new user. I reach the docs and instead of just trying blindly the code I read everything to try to understand how it works, but making it worst, it scare me since I’m no longer familiar with View and Projection transformation matrices.
After this good read: http://www.codinglabs.net/article_world_view_projection_matrix.aspx, I realised that in fact I did something with it back in the university ( 15 years ago), with DirectX; but still dont’ need it today anyway. After that even working as 3D modeler and playing with UE4 never had to deal with view and projection matrices again. And most 2D game engines hide that low level setup leaving to us just to play with X,Y coordinates.
My recommendation:
Leave the current documentation as it is, is perfect in fact, for those wanting the low level.
Create an additional page, call it: 2D Camera.
And trying to keep it simple do something like this draft:
- Introduction + mention the camera could have many advanced options linking to current camera manual.
- Creating the camera as component of game object, ignore the FOV stuff. (Don’t even mention perspective and frustum culling
) - Using the camera. Drop the little line of code. (Skip the render script info for now, it scare people).
- Quickly explain the offset thing, the camera origin is not in the center of the screen.
- Tell to make the camera follow the player GO put it as child of your player.
- To control it independently update the GO position containing the camera with go.set_position.
- Tell everything is ready! it works! everything will be fine!.. unless you want more then invite to follow up the reading to the full Camera manual.
I believe many people will fall in this category of need only 2D scrolling, not even zoom, for many kind of games. Would be a good place to add a second part for the Movement Tutorial where you simple add a “2D camera” as child of the spaceship.
I’m liking Defold, that’s why I put time to be critic and want that It could be accessible for many more users.
5 Likes
Thank you for the feedback. The point about separating into a 2D camera manual or more clearly specifying what is 2D and what is 3D makes some sense. I’ll look into it.
2 Likes
Yeah, camera its the biggest issue in Defold. In my project I am using gui nodes instead of gameobjects to avoid the problems of the camera.
I think the biggest improvement for defold will be a native 2d camera (not a library), with X and Y parameters for the viewport, and other X and Y parameters with the objective Resolution, with this, people with low pixel assets can work with , for example, 300x200 window size, and if he put a sprite in the lower right corner, then He knows in all the computers the users will see this in the same position, but in his Objective resolution.
a function for moving the camera, zooming, and a getter for the x,y of the object, and the click in the screen.
In those months using the engine, this is the only problem that I found.
Thank you for the feedback. We are aware that the built in camera is super basic. We actually didn’t have it in our documentation in the beginning since we didn’t feel that it was 100% ready. It is actually useful, but it’s slightly quirky.
The position of the game object holding the camera component is what you move if you wish to move the camera around the game world.
Changing the the zoom level is currently done via the render script using a Fixed projection (where zoom level can be specified).
This is the trickiest part and something that the current camera doesn’t support. You need to keep track of the projection and translate mouse positions on your own. We will never automatically translate coordinates for you in say on_input() but maybe we could potentially provide something like:
camera.screen_to_world(camera_id, screen_x, screen_y)
2 Likes
Its hard to work with the camera, like I said , this will be fixed with a system like other engines use, or like the gui system.
set the X, Y parameters, and distribution X, Y parameters and no more, no projection, no complex things.
the problem is that, you need very complex operations and time, for trying to know where are the objects being displayed in the user computers, and we cant lose time. (nowadays I cant succed at that, this is why Im using gui system)
the idea:
sorry Im working , Did it in 3 minutes, I like to give feedback in 1 month, when I finish my project.
1 Like
Thank you for the feedback!
The assumption you are making about “Developer don’t want you to see this” is not always correct is it? In some games I believe it is perfectly acceptable and maybe even desired that more of the game world is shown if the window is larger than what is specified in game.project.
This is what happens if you do this:
msg.post("@render:", "use_fixed_projection", { near = -1, far = 1, zoom = 1 })
If you want the behaviour of a non-stretched view where the same amount of content is always shown (as in your second picture) if the window is larger or smaller you do this:
msg.post("@render:", "use_fixed_fit_projection", { near = -1, far = 1 })
PC3 from the first picture will only ever happen if you keep the default stretch projection. If you use any of the two projection types suggested above the aspect ratio will always be correct.
PS I made some additional updates to the Camera manual and added sections on panning/moving and zooming the camera, as well as a note about converting screen to world coordinates.
7 Likes
Yeah I was talking about me, in that case.
You are doing great improving the documentation, maybe next time I can use and understand the camera.
2 Likes
Nice additions to the documentation @britzl, you can see here how @Vik was confused like me, even forcing him to use the engine how is not intended, using UI widgets as game objects.
About the orthographic projection, I remember the first time I was learning Corona and how they did a solution for all needs of different resolution on devices with the content scaling settings, providing 4 modes: “letterbox”, “zoomEven”, “adaptvie” and “zoomStretch” that could be combined with “xAlign” and “yAlingn”, was simple … of course we (someone) can make an extension for this, but looks better to have a similar basic early development setting already present on the engine.
1 Like
I just want to point out that I use UI Widgets as “game objects” all the time. It can make sense to create your whole game in GUI, especially for “classic” mobile game. Then you don’t have to fight with “move game object to gui position”, you can use layouts, anchoring and adjustment modes and a lot of other stuff.
I often think “can I create this in GUI” before doing anything else (and if I don’t need physics the answer is most often yes).
5 Likes
From the content scaling settings manual you linked:
zoomStretch
“Scales the content area to fill the entire screen on any device, ignoring the content aspect ratio. This mode should be used with caution since it will stretch/warp images and text if the device’s aspect ratio doesn’t exactly match the content area’s aspect ratio.”
This is the default stretch projection in the default render script. Use it by posting this message:
msg.post("@render:", "use_stretch_projection", { near = -1, far = 1 })
letterbox
“scales the content area to fill the screen while preserving the same aspect ratio. The entire content area will reside on the screen, but this might result in “black bars” on devices with aspect ratios that differ from your content aspect ratio.”
This is the fixed fit projection in the default render script. Use it by posting this message:
msg.post("@render:", "use_fixed_fit_projection", { near = -1, far = 1 })
zoomEven
“Scales the content area to fill the screen while preserving the same aspect ratio. Some content may “bleed” off the screen edges on devices with aspect ratios that differ from your content aspect ratio.”
This is not supported by the default render script but could quite easily be added. The projection wold be set like this:
local width = render.get_width()
local height = render.get_height()
local window_width = render.get_window_width()
local window_height = render.get_window_height()
local zoom = math.max(window_width / width, window_height / height)
return fixed_projection(near, far, zoom)
adaptive
“Instead of a static content area, a dynamic content width and height is chosen based on the device”
This is not really supported in Defold at all. Although it should be possible to add a similar kind of logic to pick an appropriate zoom level like Corona does and then apply that to both the game world and the ui.
I wonder under which circumstance you don’t want the content to be centered? If there’s a need for it it would be very easy to add support for.
7 Likes