Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 07 May 2013
Offline Last Active Sep 26 2013 10:10 PM

Posts I've Made

In Topic: Newbie programming question (AS3 draws to "stage" as C++ draws to...

18 July 2013 - 01:13 AM

The two languages aren't really comparable in that  way. AS3 is a high-level language, with very abstracted graphics drawing. If you're after a gentle transition from AS3 to something else, I'd suggest Java over C++ as its more similar (though, probably not quite as useful in the long run) and OpenGL. If you have an Android device, Java and OpenGL ES is a lot of  fun to learn. I'd also suggest OpenGL ES2 over OpenGl 1.x as well, because its almost the same standard as WebGL and writing your own shaders is a useful life-skill. I'm sure what I just said is probably a  lot to  take in, but just do some research  into the things I just mentioned and it might help you decide where to go next. I've been a Flash programmer for a couple of years and have been transitioning to other languages to make games and this was a comfortable road for me. Of course, if you're just trying to make a game as quickly as you can, Unity is a pretty neat engine with a lot in common with Flash.

In Topic: OpenGL ES 2.0: Point light optimisation

08 June 2013 - 04:53 AM

Perfect! Thank you! Works a treat

In Topic: OpenGL ES 2.0: Point light optimisation

08 June 2013 - 12:13 AM


That limit will cause popping that does not look good. I would suggest to remove it.


Yeah, I worked that out with some experimentation sad.png.


Is there a more typical way to colour light?

In Topic: OpenGL ES 2.0: Point light optimisation

07 June 2013 - 07:05 AM

I implemented those suggestions and that helped heaps. I had my own brainwave (slapped myself for not thinking of it before), and added a limit to the distance from the light that attenuation and colour would be calculated at.


if(distance < limit) {	
	diffuseDiff = clamp(dot(v_Normal, lightVector), 0.0, 1.0);		
 	diffuseDiff = diffuseDiff * (1.0 / (1.0 + (u_LightPower[i]* distanceSquared)));	
	gl_FragColor.rgb *= vec3(1.0) / ((vec3(1.0) + ((vec3(1.0) - u_LightColours[i])*diffuseDiff)));

Hopefully that might help someone else

In Topic: OpenGL ES 2.0: Point light optimisation

06 June 2013 - 06:20 PM

This doesn't mean anything.
Say the app was running at 16fps and it dropped by 15 to 1fps, that means it increased from 62.5ms per frame to 1000ms per frame -- or an increase of 937.5ms.
Say the app was running at 100fps and it dropped by 15 to 85fps, that means it increased from 10ms per frame to 11.8ms per frame -- or an increase of 1.8ms.
Is a drop of 15fps equal to the workload increasing by 1ms or by 1000ms? It's both, so it's meaningless  


Oops, sorry about the confusion. I come from a Flash background, so I'm stuck in the habit of using FPS as a measurement of efficiency (I'll get better). My original and target speed was 16.6ms per frame, but it increase to 22.ms after three light, 33.3ms after four, etc etc.


gl_FragColor.rgb *= vec3(1.0) / ((vec3(1.0) + ((vec3(1.0) - vec3(u_LightColours[i]))*diffuseDiff))); //The expensive part

What's the theory behind this line? Is it necessary?


This line determines how much to tint the fragment's rgb by each light's rgb. If 'diffuseDiff' is 0, then gl_FragColor.rgb would just be multiplied by vec3(1.0). If 'diffuseDiff' is 1, gl_FragColor.rgb is multiplied by the full value of vec3(u_LightColours[i]).


Thanks heaps guys. I'll try implementing this when I get home from work and report back on the difference. I really appreciate the help.