Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 02 Nov 2012
Offline Last Active Yesterday, 11:32 PM

#5256486 Do you use friend to avoid security problems ?

Posted by on 10 October 2015 - 12:13 AM

If you're truly concerned with security, that is, you want to prevent malicious users of your API from doing things that could be harmful to other users or to you, then making functions private will do very little to help you achieve your goals of protection. If a malicious person wants to call a private function, they only need to discover its existence, find its location in the executable, determine the proper calling convention and parameters, and then they can freely call it with whatever parameter values they want. While the above steps aren't trivial, especially for your average script kiddie, for a well practiced malicious agent it's not that hard.


If you're using protected/private to try to 'secure' an API, it'd be even more trivial for a user just to add the following lines before including your headers:


#define protected public

#define private public


And they will have access to all the innards of your classes as if they had the friend designation.


It's probably best to think of protected and private as mechanisms to encourage and simplify correct use of your API rather than to prevent misuse.

#5256437 Do you use friend to avoid security problems ?

Posted by on 09 October 2015 - 03:53 PM


Do you use friend to avoid security problems of public functions ?


Yes, I always get a friend to keep a lookout when I urinate in public.

#5255204 How exactly does localizations of apps translate to more downloads?

Posted by on 02 October 2015 - 12:42 PM

As well as the other points made, on mobile, Apple and Android are important gatekeepers with their featuring systems, and the features are different per territory.


You are unlikely to be featured in France without French localization for example.

#5254549 How do I know what Android version to target?

Posted by on 29 September 2015 - 01:04 AM

This contains a lot of useful information about Android fragmentation: http://opensignal.com/reports/2015/08/android-fragmentation/


We're about to release on Android and are support 4.0+. Version 3.* was never widely distributed, so you can pretty much pretend it doesn't exist. Version 2.* is still used by about 5% of devices but we decided to ditch it because it doesn't support setPreserveEGLContextOnPause which we're using to keep our OpenGL context alive after multitasking.


Picking an API level has little to do with dealing with low-end performance devices. That's a whole other kettle of fish. I'd use the above link and try to identify a few popular low end devices, and try to hit a variety of GPU manufacturers. Also, borrow as many devices off friends as possible. It took testing on about 20 devices before the flow of weird device specific issues dried up for me, but then I'm writing an engine from scratch. If you're using Unity or something, then you won't have to worry about all the quirky workarounds for various device specific issues.

#5254255 binary alpha

Posted by on 27 September 2015 - 12:13 PM

For bonus points, use this technique to avoid jaggies on your foliage (not invented by Wolfire, but they have a relatively short clear explanation): http://blog.wolfire.com/2009/02/rendering-plants-with-smooth-edges/


TLDR version: Render all foliage twice. First pass use clip/discard/alpha test on your foliage (as Hodgman describes). Second pass, render with alpha blending.


A more correct solution might be to look into alpha-to-coverage with multi-sample antialiasing.

#5249285 Alpha blend mystery

Posted by on 28 August 2015 - 12:03 AM

I think Jihodg is on the right track. Your code that's hardcoding a test value for texture two's alpha is only modifying the top mip.


If the lower mips are already generated, then they will still be opaque. Try regenerating the lower mips after hardcoding that transparency, or modify your code so that you iterate through all the mips and hardcode an alpha value.

#5248363 OpenGL-ES Light-Shader: distance-issue

Posted by on 23 August 2015 - 09:34 AM

Sounds like a precision issue to me. Your math is being done at mediump which could have a maximum range of -16384 to 16384, which is quite a lot more than your 250-300 but do bear in mind that the distance function is almost certainly having to square. In fact, maybe the compiler is smart enough to remove the square root from the 'distance' function and compare with your radius squared (which can be calculated per draw call) instead of using radius.


First up, if you have a device that supports highp in the pixel shader try just changing 'precision mediump float;' to 'precision highp float;'. If that fixes it then we're on the right track.


But I wouldn't stop there because lots of Android devices don't support that. Try doing your lighting math in normalized screen coordinates instead of pixel coordinates maybe? (i.e. divide both the pixel pos and the light pos by the screen height or the screen width)

#5247748 Controls for Mobile Platformer

Posted by on 19 August 2015 - 03:12 PM

I would check out the Mikey games (Mikey Shorts, Mikey Boots) for example of how to do it right. Basically, you want a left and right button for your left thumb, and a jump plus a maximum of one other button for your right thumb. I wouldn't recommend any more than that.


Extra points if you make the button size/positioning customizable.

#5246654 DirectX Camera Jitter

Posted by on 15 August 2015 - 03:02 AM


You shouldn't be scaling mouse movement by the time delta. Mouse movement should have a direct mapping to rotation. These lines:


XMMATRIX xRotation = XMMatrixRotationY(((float)-deltaX  * (float)timer.Delta()));
XMMATRIX yRotation = XMMatrixRotationX(((float)-deltaY * (float)timer.Delta()));

This is wrong. You're camera movement should be tied to the frame-time just like all movement. Otherwize, a 30 fps game would result in a more sluggish camera rotation compared to when it was running at 60 fps. 

In any case, it doesn't explain the issue.


Edit : Unless of course, you're not taking input snapshots per frame, but rather updating input at a frame-independent rate, such as by directly pushing windows msgs into your engine.



We're talking about mouse cursor movement.


If we were talking about control pad analog sticks rotating the camera, then there should be a time delta applied, but we're talking about mouse movement, which should definitely not have a time delta applied (as proved by the fact that it fixed the bug!)

#5246404 DirectX Camera Jitter

Posted by on 14 August 2015 - 01:00 AM

You shouldn't be scaling mouse movement by the time delta. Mouse movement should have a direct mapping to rotation. These lines:


XMMATRIX xRotation = XMMatrixRotationY(((float)-deltaX  * (float)timer.Delta()));
XMMATRIX yRotation = XMMatrixRotationX(((float)-deltaY * (float)timer.Delta()));

#5243226 Why is this 1?

Posted by on 28 July 2015 - 12:38 PM

I think it's kind of confusing showing the normalised device coordinates on the same diagram as the view frustum.


It seems like a somewhat separate concept to me, and there's no reason that projection window line couldn't sit to the right of the near plane, or even to the right of the far plane!

#5242567 OpenGL ES God Ray Precision error

Posted by on 25 July 2015 - 01:06 AM

The best way to start would be to force everything to use highp and see if the problem goes away. If it does, then you can start the process of figuring out what needs to be highp and what can be mediump or lowp.


IMO, using a precision declaration at the top (the line: "precision mediump float;") is bad practice, on mobile fragment shaders you ought to think about the required precision of every operation. But in this case it makes life easier because all you need to do to confirm whether it's a precision problem is change that line to be "precision highp float;". You should also go into your vertex shader and make sure the texture_coord varying is being output as a highp too.


If that fixes it, then that's great, but you do need to bear in mind that not all Android GPUs support high precision floats in their fragment shader. However, you might be able to get it all working at mediump. Most likely the place where precision is being lost is the iterative adjustment of textCoo, you might see an improvement by calculating textCoo on each iteration rather than applying a delta. (change the line "textCoo -= deltaTextCoord;" to something like "textCoo = texture_coord.st - (deltaTextCoord * (i + 1));" or if tweak stuff correctly before you enter your loop you could use the far more optimal "textCoo = texture_coord.st + (deltaTextCoord * i);")


As an aside, attempting 128 samples might be too many unless you're targeting only the extreme high end devices.

#5240989 DXT3 nowadays

Posted by on 16 July 2015 - 10:55 PM

Can't see why anyone would need to use DXT3/BC2 in normal circumstances.


Only exception I can think of is some scenario where the value is used as some sort of index into a lookup table, and that having 16 values is a positive.


This is an excellent article on compression formats: http://www.reedbeta.com/blog/2012/02/12/understanding-bcn-texture-compression-formats/



BC2 is a bit of an odd duck, and frankly is never used nowadays. It stores RGBA data, using BC1 for the RGB part, and a straight 4 bits per pixel for the alpha channel. The alpha part doesn’t use any endpoints-and-indices scheme, just stores explicit pixel values. But since each alpha value is just 4 bits, there are only 16 distinct levels of alpha, which causes extreme banding and makes it impossible to represent a smooth gradient or edge even approximately. Like BC3, it totals 16 bytes per block. As far as I can think of, there’s no reason ever to use this format, since BC3 can do a better job in the same amount of memory. I include it here just for historical reasons.

#5240191 Compute cube edges in screenspace

Posted by on 13 July 2015 - 11:06 PM

What I'd do is transform all the 8 corner points of the cube to 2D screen space, and then use a 2D convex hull algorithm to recompute which edges are the outside edges of the projected silhouette. That solution has the appeal of using only generic "stock" algorithms (3D->2D projection, and 2D convex hull), so it will be very easy to reason about and maintain in the long run.


Good call!


Way easier than calculating silhouette edges, I think.

#5239691 Google play services?

Posted by on 11 July 2015 - 02:00 AM

I've been implementing google play sign-in recently, and my understanding got a lot clearer after watching this video:


TLDW? GameHelper is deprecated.


Probably doesn't explain the problem, but might help you simplify your code.