i updated the engine to 1.9.7. The rendering in my game uses a camera game object with a camera in it. It seems that a lot of the defaults were changed in-between engine versions, since i had to change stuff just to get the game to look right in windowed mode.
the game is intended to have a fixed viewport size (this was the default rendering mode before), and somewhere along the line, this was changed, and now fullscreening the game has the effect of looking all zoomed out.
i tried adding a msg.post("@render:", "use_stretch_projection",{near=-1,far=1}) to the bottom of the init function of my camera GO’s script, but that didn’t do anything.
2 Likes
Hm what version did you update from? We haven’t changed any defaults for camera that I’m aware of
i don’t remember. it was 1.9.something, i’m pretty sure.
steam auto-updated it in the background, if that helps establish a timeline.
Would you be able to share a repro? We have done some camera work, but the intention was not to break anything. I think we fixed one issue with DPI not being used for some camera related thing, but afaik it was a bugfix 
i made a minimum reproducible example here:
example of issue.zip (4.0 KB)
1 Like
Thanks!
Using the camera, there was a Defold update that made things look bigger on the screen. Then another update made them smaller again. This without me changing anything in the project.
My notebook has a 13.3 inch screen, so Windows uses a 150% aspect ratio. I don’t know if this is related. When my project is set to 836x470 the game screen is 1254x705 in window.get_size().
There were issues previously with the DPI values returned on non-macOS platform being incorrect. This could potentially have cause projection changes
i don’t see why DPI would matter on a projection whose intent is to disregard DPI in the first place.
that and the view does scale as you would expect when not using the seperate entity+camera (as well as the documentation for projections) leads me to believe that that is an oversight
Ah sorry, I meant display scale factor (retina screens, ui scaling on windows etc) is part of the orthographic projection: defold/engine/render/src/render/camera.cpp at c32d364b9bce98d50b54278992516f69a3a74d44 · defold/defold · GitHub
For whatever reason, the display scale was always one on windows and web before I fixed it a few releases back, which could potentially explain changes in projection sizes. But I’m not sure
well something there definitely isn’t working right, since i can’t even change the aspect ratio to emulate the old camera behavior of a stretch fit - it has no effect.
Ok that sounds like a regression, I’ll take a look
Will this scale also on mobile? For me, it’s pretty unwanted behavior, can it be turned off? Or at least, how to read the display scale factor so I could manually adjust the camera zoom to even it out…
I mean… pixel games will look crap after that! Also, software UI is a different thing than games in my opinion.
I have an active PR regarding this: Added new window API functions by britzl · Pull Request #10252 · defold/defold · GitHub
I hope to merge it in a few days.
That’s something, good 
Hello again in here,
I was trying to prepare for undoing the display scale change, I wanted to multiply the camera projection matrix by vmath.matrix4_scale() that scales 1/display_factor times but I arrived to a problem: with the new version of the render script (since 1.9.6 I think) it looks like there is no direct access to the camera projection as it is passed through render.set_camera() to the renderer, I think.
So the only way I could think of doing this was to revert to the old render script (where the projection matrix was being passed through the render script so I could edit it…).
So now, I really don’t like this solution because I’m staying on the old render script and being denied of what comes in the new releases to come.
Is there an other way I could do this? And if no, maybe that’s really a good idea to add a checkbox in the settings to opt-out of the display scale influence on how the game looks?
Also, I don’t know why nobody else seems concerned about this, am I missing something out? Maybe it’s a needless worry? 
Nope, you are absolutely right. I don’t like the idea of not being able to access the actual camera view and projection from the new render script. I complained about it before, but they said this is the way they chose to go. So, I’m now simply getting the projection/view by using camera.get_projection() and camera.get_view() (You may also want to use camera.get_cameras() )
very lazy way of doing this: defold-daabbcc3d-example-charming-kitchen/render/game.render_script at 52bc66a2ec82e6b847d03adb911973231c20e938 · selimanac/defold-daabbcc3d-example-charming-kitchen · GitHub
Not sure what you mean and how it’s different from e.g. the camera.get_projection()/camera.get_view()?
1 Like
Sorry but I don’t see the point of doing what you are doing here, you are calculating a frustum matrix from the camera, and then setting the same matrices on the render context which is the exact same thing as render.set_camera does internally.
1 Like
And for some extra context regarding to what’s going on here with both content scaling and camera changes (since I’m the one who made both, sort of):
The orthographic projection when using the camera has always factored in the “display scale factor”, or at least as long as I’ve been working on Defold:
I don’t know the exact reason for this, but I am guessing that it’s because the orthographic projection should be the same regardless of what the OS content scaling is set to. For example, if you use the “high dpi” setting in the project setting, you should not be getting a different projection size just because the content scale factor has changed. Now, as to why this has changed is because the content scale factor functions that we returned for certain platforms simply didn’t work, for web and windows we simply just returned a constant 1. But with glfw3 windows now returns the correct factor as set in the OS, and we patched the old glfw to return the “device pixel ratio” instead of 1. So in theory we should now be doing the correct thing according to how the code was originally written. On OSX we have always returned the actual scale factor, so there was already a discrepancy.
Either way, something might have been broken along the way which means we will have to look at it to make sure. I want to take another look at it, but I’m a bit overburdened right now so it will have to wait for a day or two, unless someone else does.
And as for the render script changes in regards to cameras:
Previously to use a camera component you needed to send messages to “acquire camera focus” as well as tell the render script that it should be using the matrices that is being sent from the camera component via message passing. To me (and to most people I think), this setup makes cameras harder to use and frankly makes no sense from a user expectation standpoint - if you have created camera components I would expect that you want them to work without all of this extra setup. The old behaviour of passing messages and whatnot is still there, but you will have to modify the render script if you are not happy with the current approach (which is just a few lines probably).
Hope this makes sense!
2 Likes