Any plans for improve the camera?

[Vik]

Hi, I always have problems using the camera in this engine.

People play on a variety of devices with very different resolutions. But we have to show all the players the same. And I see that it is impossible how the camera is right now, or how it has always been. Tried solutions (which do not work https://github.com/britzl/publicexamples/blob/master/examples/crop_viewport/main/crop.render_script#L18-L60), apart from modules rendercam and ortographic camera.
There is no way that it only shows the area that the developer wants.

When we increase the size of the window. It should look black, limit what you see to only what the developer wants. My question is clear

Shouldn’t the team focus on providing a simple, useful camara2d component?

Like other (all) engines, viewing the area to be displayed in the editor, rendering only what is displayed in that area, regardless of the size / resolution of the final device

It seems to me something basic, that the camera, which is what shows everything we do, is not being given the work it requires, and it has been like that for years.

Are there plans to change / improve this? or do I forget about it?

[Pkeod]

The builtin render script has been improved over time, but the builtin camera component has not changed in a while. As another user, I agree that the builtin camera component / rendering script does need improvement. Features like Orthographic / RenderCam should be builtin. But these modules do exist so they are options to use instead of what’s vanilla, which makes changing what is builtin less urgent (I believe nearly all features of DefOS should be builtin but it’s not something super urgent to happen either). Part of the reason it seems like it has not been urgent in the past, before Orthographic / RenderCam existed, is because it seems like a lot of the people who worked on big projects using Defold were very experienced with the concepts and knew how to roll their own solutions within raw render scripts without much trouble. That and the fact GUI components can be used to make games fully and handle most of the render problems you could have with using pure GOs.

For really changing / improving it there should be discussion on how to do so, what features are needed, how the camera component should be changed, what should be changed in the editor (such as being able to see through cameras in the editor as they would see the game world), what features in the render script should be in vanilla. It’s something people with more experience and those who have contributed to the existing camera solutions like @britzl and @ross.grams would be useful to have weigh in on. There are extra considerations too such as making post processing more accessible.

[ross.grams]

I’m not an engine dev so I can’t answer the question, but I guess there are a few reasons why this hasn’t changed more:

(click to expand for more thoughts on each)

1. Not everyone wants the same thing...not at all.

When we increase the size of the window. It should look black, limit what you see to only what the developer wants.

You’re talking about letterboxing, right? Adding black bars? That’s not what everyone wants. Many people specifically do not want to add black bars.

Personally, I mostly use Rendercam’s “Fixed Area” mode, in which there are no black bars and no set dimensions, but the user always sees the same number of square pixels (w1h1 == w2h2). I don’t think any other game engine does this.

Some people want letterboxing, some people do not. Some want letterboxing controlled by a different formula than others. Some people want the height fixed, the width fixed, or something completely custom. Some people will only use one view, some switch between multiple, some want to render multiple views at the same time.

2. It's already pretty easy to do what you want.

It’s not hard to change the render script to do exactly what you want for your game. A dozen or so lines of code might do it.

I realize that I can only say this because I know how most of it works. Most(?) people don’t, the render script looks like some scary, black-magic thing.

Defold has the features already, they’re just not as easy to use as you want, and more importantly, they’re not in the place you expect them to be. You (and lots of other people) expect them to be on the camera, but they’re in the render script.

Since a primary goal of Defold is to stay small, adding a new feature to do something that you can already do yourself is not likely to happen.

3. There's assets available if you don't want to do it yourself.

Why don’t you use Rendercam or Orthographic? Defold is meant to be used with extensions (or a lot of personal framework code), it lacks many features that other engines have.

Neither of these extensions is perfect, but there’s no guarantee that a built-in solution will be perfect either. I bet the Defold team would do a pretty good job, but it might not do what you want it to.

4. It could be a lot of work to add.

It would take a lot of research and development to make something along the lines of Orthographic or Rendercam that would work well for everyone. Britzl added Orthographic to github 3 years ago, and has been regularly updating it since then…

Of course any time spent on “feature A” is not spent on “feature B”, so someone’s going to complain no matter what they do.

I do agree with your general idea, but if you want something to change, I think you should rephrase your post as a feature request, and be as specific and detailed as possible.

Asking for, “a simple, useful camera2d component” is too vague, try something like: “I want to add black bars so that my camera always shows exactly the same thing on any device, and that’s way too hard and confusing to do with built-in features.”

[ross.grams]

If we’re talking about engine features that would allow better cameras (user-made or assets), then yes, there are several.

Thoughts on that (I really like these collapsible things :) )

The big issue is this one—it’s impossible to have a custom camera that never lags behind by a frame without using a Native Extension. The built-in camera component doesn’t suffer from this, but has other limitations, like not letting you use multiple cameras at once.

Allowing multiple camera components to be active at once would solve my specific, recent use case and probably not be too hard, but I think giving the render script access to some .go functions would be more flexible. Or maybe adding a .camera_script type that gets a callback when the camera updates, just before rendering (that could be more intuitive for users too, hmm…).

This one: Should be able to add a collection as a game object's child, would make Defold roughly 3x better and more flexible in general, and make more involved Libraries possible. Currently I’m using a game object with a factory that spawns an object and adds it as its own child on init (making it lag a frame on init), but that stinks. (And it could potentially take several frames to build up a collection of objects? Not sure.)

This one: Enum Script Properties, would greatly increase the possible useability of Libraries and Script Properties in general.

This one: Generate custom game.project settings, would also greatly increase the useability of Libraries.

I’m sure there are others that I’m not remembering right now.

Improving the documentation about render scripts is always good. It’s pretty common that newcomers are afraid of it and don’t know what any of it does.

If someone wants me to help rework the built-in render script or something, I’m happy to do that, but I’ll procrastinate about it forever unless I’m specifically asked…

[Edit] To sum up: I think it’s not about missing features, it’s about how intuitive those features are. No one thinks, “I want to zoom my camera”, and naturally goes to edit their render script.