It does follow different shader rules that are inherent on different platforms.
You should begin to release versioned releases on Github for Rendercam as it becomes widely adopted.
2 Likes
@Pkeod Good to know. I don’t suppose there’s convenient documentation on the differences? Yeah, I’ve planned to switch to versioned releases but haven’t gotten to it yet. It turns out, releasing a library for public use comes with some maintenance headaches! (Of course, this little demo doesn’t actually have much to do with Rendercam.)
@britzl OK, thanks for helping debug this. I did try a web build, and that turned up some slightly more informative errors, though I haven’t been able to track down the causes yet:
Regarding the second and third errors, my render targets are set to render.WRAP_CLAMP_TO_EDGE.
I will keep looking into it in a little while.
1 Like
Well I’m stupid. My render targets were set up with the Clamp to Edge mode in the render script, but the samplers on the material were still set to Repeat. Fixing that solved the “active texture is ‘incomplete’” errors on web. Interestingly, if I only used one render target it was fine, but with two I got that error about each texture.
@britzl Can you try this version to see if it works on OSX? Thanks!
-link removed- (It didn’t. See below for a working version)
I’m still not sure what’s causing the “Error: WebGL warning: uniform4fv: Function used differs from uniform size: 16” on web, but I know it’s coming from one of my materials, and I can’t see that it breaks anything. I will look more tomorrow.
2 Likes
Crashed on macOS.
ERROR:GRAPHICS: gl error 1282: invalid operation
Assertion failed: (0), function SetConstantV4, file …/src/opengl/graphics_opengl.cpp, line 1346.
2 Likes
Thanks Dmitriy!
OK, hopefully the 3rd time’s the charm. I cleared up the other error I got on web, and it sounds like the same error as on MacOS (stupid again, I had extra stuff in my vertex shader).
rendercam_targets_lighting_3.zip (432.1 KB)
1 Like
Works on macOS & iOS. Nice example, btw.
1 Like
Yess! Thanks again! Now I know to be much more careful with my shader code in the future (and test web builds for errors). If you didn’t figure it out already, you can move the “character” around with the arrow keys.
4 Likes
It worked 
This is so educational, thank you.
2 Likes
Hi Everyone,
@ross.grams, thanks for Rendercam, it works great!
Is anyone seeing the following issue when using the rendercam.pan() function with something like:
rendercam.pan(20, 0)
ERROR:SCRIPT: /rendercam/rendercam.lua:186: bad argument #1 to '__add' (vector3 expected, got nil)
stack traceback:
[C]: in function '__add'
/rendercam/rendercam.lua:186: in function 'pan'
All the other functions seem to work ok, eg:
rendercam.zoom(-20)
rendercam.shake(2, 10)
all do what they’re supposed to when used at exactly the same code point. Apologies if I’m missing something.
1 Like
Hmm, that’s strange. Argument #1 is the stored local position of the camera, I’m not sure how that would be nil. But obviously there’s something I didn’t anticipate going on. Can you share your project?
Thanks for the reply.
Sure, do you need to PM me you email address for me to share?
I can replicate this in the Rendercam example you provided with the addon also. Adding this to the end of the init() function in main_example.script creates the same error. The zoom, shake and recoil all work:
rendercam.pan(10, 0) -- Doesn't work
-- rendercam.zoom(-40) --Works
-- rendercam.shake(10, 10) --Works
-- rendercam.recoil(vmath.vector3(40, 0, 0), 2) --Works
Defold prints a load more errors in the example after the same error I get though so scroll up! 
Best regards
1 Like
Aha, OK, thanks. I just forgot to initialize a variable, so it wasn’t set until the first update. I just pushed a fix. Thanks for reporting!
4 Likes
Awesome 
Can confirm this fixes the problem in my project. This library really is something special. I’ve used it in various collections and game objects during testing and it works a treat.
Thanks for the library AND the fix!
2 Likes
Designing a game for mobile devices is tricky when it comes to screen sizes. Iphone X has an aspect ratio of 16:7, compared to more square-ish ipads etc with 4:3. Translated to 16 in width, an ipad is 16:12, almost double the width of an iphone X with its 16:7.
So! How do you handle that in your game? Personally I’m designing for 16:9 at the moment. To handle different aspect ratios there’s a few options design-wise:
- Keep your aspect ratio and add black borders either top/bottom depending on screen aspect. Not ideal.
- Fill the screen, so not keeping the aspect ratio. Not ideal.
- Keep your aspect ratio and instead of black borders show something graphically suitable, expanded elements of the gui for example. Highly game dependent. Can be an ok solution depending on game/design.
Let’s examine the last option in my game scenario, a top down 2d space shooter running in portrait mode.
I would opt for having an aspect range, say from 16:8 to 16:10. I’d like to allow my game to use any aspect within this range, closest to the device aspect its running on.
So on an ipad, it’d run on 16:10 and show something on left/right edges of the screen (since it’s wider with its 16:12).
And iphone X it’d do 16:8, showing something on top/bottom edges.
This “something” I don’t know yet what I’d put there. I’m thinking that going past this aspect could result in scaling of the display, so you keep the aspect within the game itself but it’s scaled/warped to fit the screen anyway.
Is there any way to have rendercam use an aspect range? Is this a common way to design stuff or am I lost in my own thoughts here?
With Rendercam, GUI nodes draw on top of the black bars you get with a fixed aspect ratio camera. So I think for your case you can just use a fixed aspect ratio camera and add GUI borders on top and bottom.
If you were concerned about drawing large extra borders when they are not needed, you can use a window update listener and enable/disable the sides/top-and-bottom depending on which of viewport.x or viewport.y is zero. (the non-zero axis being where the black bars are)
But I guess that’s your non-ideal scenario…I’ve thought about aspect ranges before, but never had an actual use-case like this.
My idea might be overkill though, I’m currently in a confused state regarding this.
I’m trying to design enemy movement patterns etc which forces me to really define my play area size etc. And I’m just not sure how to handle the different screen sizes yet.
Doing some research on other top down shooters I found on Google Play, it seems most of them either change the actual visible area in the game (essentially giving the player a different gameplay experience depending on screen size), or just stretch to fill.
They actually stretch the rendering?!
Yeah, the cheaper games do
Not the fleshed out ones.
Some do a combination, where the player is preserved aspect wise, but the moving background is stretched to fill.
Interesting to look at the game Gemini by Armorgames, they don’t stretch anything, but a 4:3 experience on ipad vs 16:7 on iphone x is quite different. There’s a lot of side movement in that game and on iphone x it’s more tunnel vision.
On 16:7 aspect the background cover the entire screen, however they use a darkening overlay (png?) on the background which doesn’t cover the whole height of the screen. They probably thought nobody will ever use such a screen…
Result is the background being a lot brighter on top/bottom edge.
2 Likes
