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!

Matias Goldberg

Member Since 02 Jul 2006
Offline Last Active Yesterday, 03:57 PM

Posts I've Made

In Topic: no Vsync? why should you

17 May 2015 - 07:16 PM

Believe me I've tried it with a fixed game/ physics update time of 1/60th of a second, but just didn't work out (after spending days).

Then you didn't try hard enough. Read the Fix your timestep article again, and try again.

Basically almost every game runs on a fixed time step.
Variable framerate can end up in bugs that only reproduce in very specific framerate scenarios, like people going through buildings / invisible walls, game suddenly freezing because an FPS spike (high or low) caused a NaN or similar impossible-causing scenario, bullets that never hit their target, scripted events that never trigger (imagine beating a level but the game never acknowledged the player won, so you're stuck!). The list of bugs that can happen due to variable framerate steps is never ending and insanely hard to debug and fix.

It's a really, really bad idea.

In Topic: no Vsync? why should you

16 May 2015 - 04:13 PM

In that case the game will not as expected (collision detection annoying issues).

You should not be simulating your game using variable framerate. Fix your timestep.

In Topic: Sorting draw calls by distance

15 May 2015 - 02:10 PM

Aras has already a blog post dedicated to the OP's question.

In Topic: Back Face Culling idea

10 May 2015 - 02:40 PM

I didn't make the link between that article which talks about points in the positive triangle area, and direction of front face and back face.

Ooops. Sorry. Right blog, wrong link. See Fill rules.


Edit: The baricentric conspiracy article is still important to understand what's going on. Through the math exposed there, the author arrives to the code:

if (w0 >= 0 && w1 >= 0 && w2 >= 0)
                renderPixel(p, w0, w1, w2); 

To determine whether a point is inside a triangle.

w0, w1 & w2 are calculated using:

int w0 = orient2d(v1, v2, p); //F12
int w1 = orient2d(v2, v0, p); //F20
int w2 = orient2d(v0, v1, p); //F01

He obtains the formula from his baricentric conspiracy math derivation, where he defines F12, F20 & F01 using a counter-clockwise scheme.

If a point is inside a triangle but the vertices are given in clockwise order, then w0, w1 & w2 will all be negative. This is a damn good mathematical property.

Counterclockwise triangles can be checked doing "if (w0 >= 0 && w1 >= 0 && w2 >= 0)"; while clockwise triangles can be checked doing "if (w0 <= 0 && w1 <= 0 && w2 <= 0)"

Another way to switch this, is to alter the definition of w0, w1, & w2 so that you use F21, F02 and F10 instead; then check for all positive for clockwise triangles, and all negative for counterclockwise ones.


In other words, checking whether a triangle is counterclock- or clock-wise is a matter of checking whether all three coefficients are positive or negative (or toggling the math formula to flip this identity). No cross product involved, no dot product involved. No need for a triangle normal at all. In fact, this can be solved using integer arithmetic and no need for floating point!


Since during rendering we only care that triangles are in one order, we don't need to do anything. We just leave "if (w0 >= 0 && w1 >= 0 && w2 >= 0)" and the vertices in the wrong winding order will automatically be left out.

In Topic: Back Face Culling idea

08 May 2015 - 02:58 PM

Whaa..? That's not how rasterizers detect triangle orientation. See 'Oriented edges section' from Fab. Giesen. It basically exploits a mathematical property and is nearly free.