How camera works?

[ross.grams]

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?!).

[Vik]

well, I think they are going to be the new Unity, with all that bad

[piXelicidio]

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.

[britzl]

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.

[piXelicidio]

Thanks for the quick action, I’ll give a second second try.

[piXelicidio]

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:

msg.post("#camera", “acquire_camera_focus”)

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.

[britzl]

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.

[Vik]

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.

[britzl]

camera its the biggest issue in Defold

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.

with X and Y parameters for the viewport

a function for moving the camera

and a getter for the x,y of the object

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.

other X and Y parameters with the objective Resolution, with this, people with low pixel assets can work with , for example, 300x200 window size

zooming

Changing the the zoom level is currently done via the render script using a Fixed projection (where zoom level can be specified).

click in the screen.

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)

[Vik]

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.

[britzl]

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.

[Vik]

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.

[piXelicidio]

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.

[Jerakin]

even forcing him to use the engine how is not intended, using UI widgets as game objects.

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).

[britzl]

providing 4 modes: “letterbox”, “zoomEven”, “adaptive” and “zoomStretch”

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.

combined with “xAlign” and “yAlingn”

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.

[Vik]

Im trying the camera… too much pain.

In the editor I cant see whats the actual camera viewport, changing numbers in position and launch build is not a solution.

The center of the camera viewport is not the origin of the GO

And using fixed_fit_projection doesnt egnerate black bars, its shows more game screen…

This is very important, Defold lacks a Camera that shows only the developer wants.

[britzl]

In the editor I cant see whats the actual camera viewport

This is true. We could probably improve how the camera component is visualised in the editor. Ping @mats.gisselson and @vlaaad.

changing numbers in position and launch build is not a solution

Well, it’s a workaround

And you can move the camera and hot-reload to immediately see the change.

Please also note that the camera properties are for a Perspective camera only. Changing them for a 2D game with fixed_fit_projection (or any other projection for that matter) will have no effect.

The center of the camera viewport is not the origin of the GO

This is true. It’s actually not mentioned in the camera or render script manual. I’ll make sure to add this information.

You need to offset the camera yourself. This is done in the Camera example.

And using fixed_fit_projection doesnt egnerate black bars, its shows more game screen…

Yes, this is true. The manual section describing the fixed_fit_projection doesn’t mention any black bars. If you want black bars you can achieve it by modifying the render script. Or use RenderCam. We could also add this as an option to the use_fixed_fit_projection message.

[Vik]

What changes need to do for add black bars?
thanks

[ross.grams]

To get black bars you need to change the viewport—the rectangle inside the window where stuff is rendered. In your render script update, you’ll see:

render.set_viewport(0, 0, render.get_window_width(), render.get_window_height())

That sets the viewport to fill the full window. Give it a rectangle that’s smaller than the window to get black bars. Well, actually, they may not be black, they will be whatever your clear color is set to.

This is the little bit of RenderCam’s code that figures the viewport rect for a fixed aspect ratio:

-- You only need to recalculate this when the window changes.
local scale = math.min(M.window.x / curCam.aspectRatio, M.window.y / 1)
M.viewport.width = curCam.aspectRatio * scale
M.viewport.height = scale

M.viewport.x = (M.window.x - M.viewport.width) * M.viewport_align.x
M.viewport.y = (M.window.y - M.viewport.height) * M.viewport_align.y
-- M.viewport_align.x and .y are generally 0.5, which will center the viewport in the window. 

[Vik]

thanks.

If I want a render window of 800 x 600 and only render that space of the game??

I did changes but doesnt work

The second sprite that is below, need to stay out of the render.