Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 02 Nov 2012
Offline Last Active Today, 03:14 PM

#5243226 Why is this 1?

Posted by C0lumbo on Today, 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 C0lumbo 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 C0lumbo 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 C0lumbo 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 C0lumbo 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.

#5233407 Compute cube edges in screenspace

Posted by C0lumbo on 07 June 2015 - 01:06 PM

Sounds like silhouette calculation. For each face of the cube you can calculate whether it is facing toward the camera or away from the camera. Then for each edge of the cube you can calculate if it connects a face that's pointing away and a face that's pointing toward the camera. If so, then it forms part of the silhouette.


Tricky to implement though, because you need to deal with floating point precision issues, and once you've figured out the silhouette edges, working out the correct ordering you want might be fiddly.


"Also, if I subdivide the cube into 8, would the same relative points for the smaller cubes also form an outline for each smaller cubes?" - With an orthographic view, I think yes. With a projection view, I think no.

#5231805 Help with opengl diffuse shader

Posted by C0lumbo on 29 May 2015 - 10:38 PM

The reason it comes out transparent is because of the last line:


gl_FragColor = (diffuse * texture2D(u_Texture, v_TexCoordinate));


You're multiplying the RGBA you get from texture2D by the diffuse scalar you've calculated. You only want to multiply the RGB. Try:


gl_FragColor = (vec4(diffuse, diffuse, diffuse, 1.0) * texture2D(u_Texture, v_TexCoordinate));

#5230567 Imposter Transitioning to Mesh

Posted by C0lumbo on 23 May 2015 - 08:10 AM

Have you tried just manipulating the world matrix of the 3D mesh version of the tree?


You should be able to quantise down the rotation of the tree to match the same orientation that the imposter was using, and you manipulate the scale of the matrix to flatten it as well.


The other alternative might be to do some sort of fragment discard based transition effect which is often more subtle than simple 'popping'. It's mentioned (but not detailed) in this paper: http://www.cs.ucsb.edu/~holl/pubs/Candussi-2005-EG.pdf


"To avoid the popping effect while going from one LOD to the other, we implemented a smooth fade-in/fade-out transition for billboards. The fade effect is done with alpha test; when fading out, the number of rendered pixels is smoothly reduced, when fading in, it is smoothly increased. This is done by assigning random alpha values for the billboard texture pixels and then varying the alpha comparison value for the alpha test."

#5230447 degenerate triangles

Posted by C0lumbo on 22 May 2015 - 12:22 PM

Use indices. Obviously the proper answer is to profile, but the performance difference is probably marginal enough that it's hard to measure, so just use indices because it makes sense.


By using indices you are sending less data through (an index is smaller than a vertex), but more importantly by using an indexed draw you are allowing the GPU to use an optimisation called a post-transform cache. Basically, the quad (012, 213) involves 6 vertices, but the GPU can realise that it can reuse the previous vertex shader output for the second instance of vertices 1 and 2, skipping some work. GPUs don't use a post-transform cache for non-indexed rendering because it'd be too much work to check which vertices are duplicates of earlier ones.


There's a trickier question of whether or not you should use indices as a triangle strip with degenerates (0, 1, 2, 3, 3, 4, 4, 5, 6, 7, 7, etc) or a triangle list (0, 1, 2, 2, 1, 3, 4, 5, 6, 6, 5, 7). It probably makes little difference but I'd choose the latter because there is at least some archaic console hardware that performed particularly badly with degenerates.


Note that rendering a big load of quads is quite common, sometimes it's handy just to make one giant array of indices exactly for that purpose and share it across your 2D system, your particle system, etc.

#5229282 How does Clash of Clans (mobile) keep track of timing?

Posted by C0lumbo on 16 May 2015 - 02:26 AM

There are standard functions for getting the time from a device (e.g. http://www.cplusplus.com/reference/ctime/time/). iOS, WP8 and Android also have additional functions for getting the device time.


Most computers, (phones included) will have their own clock that continues to run independently of whether the device is switched on or off, in desktop computers the clocks use a separate battery. No idea what phones do, tbh, not sure if they'd use up precious space to add an extra battery just for a clock, perhaps they just use the main battery, and if you ever fully drained the battery (hard because phones turn off when there's still a few percent left) the local time would become wrong.


In games with timers, there's always the risk of exploits by users manipulating the device's clock and the solution is usually to use both local time (for better user experience) and server time (for cheat prevention). When online, CoC probably uses the server time, when offline it probably trusts the local time.


However, I imagine if someone tries to manipulate the local time to make building faster then the next time you go online and the CoC server time is available the game will have code to detect that and it will take corrective measures (e.g. maybe it'll take back the stuff you gained using the exploit).

#5228904 Architecture copyright

Posted by C0lumbo on 13 May 2015 - 11:53 PM

Here's a case from a few years back that made the news in the UK. The church that was allegedly copied seemed to not have a copyright infringement case in this particular instance:





Hope your game is not violent!

#5226001 So, what happened to god games ?

Posted by C0lumbo on 28 April 2015 - 12:18 AM

Yes, I think it's a real shame.


Personally, I got turned off by the fact that as god games became more complex, I seemed to spend more and more time doing really boring micromanagement tasks.


Black and White in particular had the odd situation where I was playing as a super powerful god, but I seemed to spend all my time being a child minder to stupid minions. Now Godus combines similar tedious micro management with farmville-esque clicking-on-stuff-to-collect-it.


So I ended up making a god game which focuses on global war and destructive acts-of-god because I think the key thing about god games is the wielding of power, not worrying about minutiae.

#5225703 Small indie question

Posted by C0lumbo on 26 April 2015 - 02:32 PM

Why worry about $200, the amount of time you've invested in getting your game this far is worth much more than $200.


Will you make the $200 back? Not sure, the game looks pretty enough to, but plenty of games don't make anything and there's a very good chance your game will be the same.

Will it be worth it from a learning point of view? Yes, go for it! Plus, it's a big personal achievement and it's quite a buzz releasing your own game on the app store, even if you do lose money on it.

#5224515 Did I Work On This Game?

Posted by C0lumbo on 20 April 2015 - 10:56 AM

Hopefully you'll have a couple of proper titles on your CV by the time you look for a new job, and this can sit as a single bullet point in an 'Other TItles' section.


Just don't exaggerate it on your CV, the chances are reasonable that the guy who will interview you will know someone who was on that game team for the entire project, and you really don't want to be caught out in a lie.

#5218539 Particle Z Fighting

Posted by C0lumbo on 23 March 2015 - 12:41 PM

Sounds like you have a situation where the render order is changing frequently.


Is there any way you can switch to a render mode where the order doesn't matter, e.g. additive blend. Or multisampling with alpha to coverage?


Otherwise, sounds like you need to sort them, or at least get to a point where the sorting isn't changing often enough to be noticable