Rendertexture & ipad mini not showing the texture when image dimensions are small

[Exca]

Hi,

 

I have a shader which calculates distance from point A to nearest collision point. Colliders are drawn to bitmap and the shader basically checks how long it needs to move from point A towards angle until it hits color larger than threshold and then returns that length as color (0-255).

 

I render the collision map to renderTexture (128x1) using a scene with one sprite in it (of same size) and the sprite has the shader mentioned above.

 

On desktop I get wanted results, the bitmap generated has correct values. On ipad mini the bitmap renders empty. If I change the resolution of rendertarget to 128x16 ipad renders it correctly.

 

Anyone know if ipad has some kind of minimum required size for framebuffers?

If the text above isn't clear enough, I can create an example of the situation.

 

[Edit] Using a non power of two texture (I tried with 120x1) it gets rendered correctly.

[chg]

Really dumb guess: Any chance it might be due to lowered shader precision?

Also, the way you describe what you are doing, I do really wonder is this a good algorithm to try and defer to the GPU? There's potentially costs to pushing the data back and forth and context switches, and if it could benefit from branching (eg. the pixels aren't completely independent of each other) then why not try the CPU... there's always workers for threading and asm.js which are getting more and more practical / widely supported if a stock Javascript solution is running slow (though context switching overhead may kill those too esp. asm.js I hear )

[Exca]

Tried it with lowp, mediump and highp. All had the same problem.
 

Basically what I'm doing is something similar to this https://github.com/mattdesl/lwjgl-basics/wiki/2D-Pixel-Perfect-Shadows

 

For static lights I precalculate the collision maps in gpu, upload the results to another shader, render all static lights into lightmap and use that in postprocessing (similar to what happens in deferred shading). After that the static lights only change if scene changes (basically on reload / new game).

 

I have one dynamic light and I rerender that collision map each time player moves. The map is rendered from collider texture (which is basically the items creating shadows rendered to one texture) which does not change at all during the game. After the rendering of collision map is done, I render the light into separate rendertexture and use it in postprocessing filter with lightmap to combine the lights.

Running the collision map generation in cpu would be possible, but I doubt it would be faster.

 

Currently I get 55fps with static lights, 48 fps when updating player light collisions and 20fps when rerendering the player light. (ipad mini numbers)

 

Before I changed the texture to NPOT the collision calculation dropped fps to around 5-10 because the area was 16 times larger than what was needed.

[edit] Managed to get the numbers up to 35 by moving the updating of collision map & player light to RAF. I had them in touchmove handler which could occur faster than rendering.

[chg]

Before I changed the texture to NPOT the collision calculation dropped fps to around 5-10 because the area was 16 times larger than what was needed.

You don't have to use a full screen quad - you can use a quad 1/16 the width to shade less pixels (you'll wind up shading some extra fragments though, but I think that'll happen in the 1 pixel wide render texture case as well)

As for how you might do a CPU version... well you are more or less doing Doom style ray casting- if your level is static (your light doesn't have to be) or at least most of it is, and your occuluders can be modelled as line spans, and your moving light doesn't randomly teleport every frame you can do a lot... hell, if some of that stuff holds perhaps at least move some of the work to the vertex shader

[Exca]

Hmm, moving stuff to vertex would be a good idea, have to investigate if there's something I could move there.