Gotcha, interesting. It’s your game obviously, but if it were mine, I would just use a fixed aspect ratio, that way the gameplay would be the same for everyone. 16:9 seems like a good middle ratio between 4:3 and 16:7. You’re still using 90% of the area for gameplay, and you could use the black bars to put GUI stuff out of the way.
A fixed width and variable height probably wouldn’t make more work for you, but then it would be harder (less time to see what’s coming) on fatter screens and easier on taller ones. (You might scale down the vertical speed of everything to even it out somewhat.)
With a fixed height and variable width, you would probably want to scale your enemy movement patterns, otherwise the player could always hide out at the edges on wider screens. And the gameplay would still be a bit different, you might want to make the player faster, since they would have more horizontal space to cover.
You could try fixed area. It’s a middle-ground and might work out pretty nicely, or you might just have to deal with all of the above problems.
Those are the only four options that I can see. If you don’t use a fixed aspect ratio, then either the width or the height or both are going to change. Using an aspect ratio range is not a bad idea, but it’s really just lessening the effect, you will still have to deal with slightly different width/height.
Thanks for helping me put words to my thoughts!
For some reason I’m really struggling with this, but maybe I should consider allowing black bars on those outlier aspects (or things in between).
Maybe it’s not as frowned upon as I was thinking first…?
OK, well that was easy. Try the 2.0 Beta branch: https://github.com/rgrams/rendercam/archive/2.0Beta.zip Now there is a rendercam.viewport_align vector. You can set its x and y to 0-to-1 values. 0 for bottom/left, 1 for top/right. (default 0.5, 0.5 for centered)
Slightly regarding my previous questions above with GUI etc:
The vector_align works great! I now want to make sure there’s a “gap” from the camera view to the top of the screen.
For the 720x1280 example, let’s say the top 100 pixels are ‘reserved’ for GUI. I don’t want the gameplay camera to expand to this area.
Setting aspect ratio to 720x1180 and checking Use View Area, and Fixed Aspect Ratio solves this for me… as long as the window is 720x1280. If I make it wider, the camera will maintain aspect but eventually cover all the screen height.
I need to make sure the height never goes past 92% of available height.
I guess this should be fairly easy to set by copying the renderscript to a custom render script, and modifying parameters based on window size somehow?
I’m unsure on where to start though. I tried print out on every update: print(render.get_window_height() .. ' -- ' .. render.get_height())
But that prints DEBUG:SCRIPT: 1280 -- 1280 no matter what width I change my window to, but changing window size still updates rendercam behaviour so I know the system reflects width changes still.
Ansering myself here, seems this solution works great for my case, just altering this function in the update:
local function update_window(self)
rendercam.update_window(render.get_window_width(), render.get_window_height() * 0.921875)
self.gui_proj = vmath.matrix4_orthographic(0, rendercam.window.x, 0, rendercam.window.y, -1, 1)
end
(adding the * 0.921875 to height is the change)
Edit:
Hmm strike that… this messes up my game menu. Makes sense though.
I wonder if there’s a way to set this only in my gameplay scene/collection. Through the rendercam module maybe?
Edit 2:
I’m probably overthinking this.
I’m going back to keeping a straight 16:9 aspect ratio (or rather 9:16 since portrait).
I’ll let the camera be covering the whole area, and I’ll put GUI on top of this.
The main reason I had for this offset was to have dynamic positioning of enemies based on a dynamic width/height, but I can easily just create a subset area excluding the GUI portion and align everything as if that was the available area. Works great!
Small update: I made a bit of a mistake when I made a git release tag instead of just using branches, and I didn’t realize I had to update the tag. So, if you were using v1.0, you may not have gotten the last three bug fixes I did way back in January and February, but you should get them now. Sorry about that!
Fixes:
Fixed debug rendering.
Added error message for camera name conflicts.
Fix bug where calling pan() on init caused problems.
Never mind, the reason why it was not working was because I was calling it in the init function of my script. rendercam.camera_init has not been called yet when I was calling rendercam.activate_camera.
I’m new in Defold and this is a huge help. I was wondering if you could clarify for me something about the Fixed Area feature.
It doesn’t seem to work properly for me. What I understood is that the camera will always show the area I set in Use View Area if this this checked.
I set the size of my game project to 800 x 1200 and did the same with the Use View Area and checked it. I set a background of 900 x 1734 and centered the camera and the background. I would expect the camera zoom in or out to always show a part of the background equivalent to (800 x 1200) no matter the size of the window but sometimes it show less of the area I set.
Can you tell me if I misunderstood it or what I may be doing wrong. Fixed width and height seem to work tome as expected. but no Fixed Area.
Yes, those options don’t work quite the way you expected. Fixed Area does not keep either of the same dimensions, it keeps the same Area (width x height). So with 800x1200, you should always see 960,000 pixels of world area, with the proportion of your window. If you had a background image of 800x1200, it would always be cropped in one direction unless your window had the same 2:3 proportion.
With the Use View Area option checked, it uses those values instead of the game.project settings to figure out the initial zoom. It’s there so you can have a window resolution (in game.project) of, for example, 600x900, but still have the camera zoom to show 800x1200 of world space.
If you want the proportion to stay the same, so you always see your 800x1200 area (and only that area) use the Fixed Aspect Ratio option. This will add black bars (letterboxing) if the window proportion doesn’t match.
Currently there’s no option to do this without the black bars, perhaps there should be…
Yeah, I will look into it, I can’t promise anything soon though. I have been planning a rewrite for a while now, hopefully over the next month.
I haven’t tried, but I think this would be the same as switching between a fixed-height camera and a fixed-width camera depending on the aspect ratio of the window. You could see if that works for you, set up a window update listener and switch between the two cameras based on the aspect ratio being greater or less than your 2:3 ratio.
Updated Rendercam’s render script for Defold 1.2.146 and some other cleanup and tweaks. If you’re using the v1.0 release you can update your dependency URL to:
Well, I have a fairly long list of things I would like to add or improve. The code is quite old at this point, and with some updates to Defold there are better ways to do things now. I’ve started some of this on the dev branch, but there’s still a long way to go. To be honest I intended to do this stuff and release an official v2.0 at least a year ago. Unfortunately I’m no longer using Defold for my own projects, so it’s become a fairly low priority.
If anything breaks because of Defold updates I will try to fix it quickly. Other than that, don’t expect much from me, though I do plan to get things done eventually.
I appreciate your support! I don’t have any intention to start a Patreon though. I’ll let you know if I release any commercial games.
Rendercam is a very important Defold project. As Defold gets its 3D features more accessible and developed it will be more important as more devs come to Defold for 3D gamedev projects.
