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!


l0calh05t

Member Since 16 Dec 2000
Offline Last Active Apr 30 2015 08:01 AM

Posts I've Made

In Topic: Direction Booleans into single Integer

29 April 2015 - 12:50 AM

The more I think about it, there's entirely too much danger that someone might actually understand the full factorial interaction matrix approach I used in my first try. So I give you the polynomial evaluation version:

  int64_t x = 3 * (up - down) + left - right;
  return x * (x * (x * (x * (x * (x * (x * (x * (-31) - 28) + 938) + 840) - 8519) - 6972) + 24412) + 12880) / 3360;
More seriously, the full factorial interaction matrix has 16 different possible coefficients, but the solution had 14 non-zero coefficients. For the polynomial evaluation, there are nine coefficients, and eight of them were non-zero. This basically says that the mapping structure is slightly more regular than just random assignment, but not by much. I'm not going to say there isn't some clever way to do this computation more efficiently, but the horrible brute force techniques aren't simplifying into anything nice.

 

No, it isn't random at all, but rather based on angles!

 

auto x = (float)right-left;
auto y = (float)up-down;
if(!(x || y)) return 0;
return 1+(int(round((4.f/3.14159265f)*atan2(x, y)))+8)%8;

In Topic: Spot the bug quiz.

28 April 2015 - 11:00 AM

12/15, thought it only gave me 11/15 because in the misplaced bracket question I identified the problem correctly but clicked on the == instead of the misplaced bracket (it seemed reasonable, honestly, that was unfair) so I just gave myself the point. I didn't spot the misplaced semicolon either somehow, goes to show how these things are easy to miss!

Yeah, same thing happened to me. And in one case i misclicked by one character.


In Topic: Gamedevs presenting language problems to C++ standards working group

17 April 2015 - 11:31 PM


Not everything uses the zero-cost exception model. Namely, emscripten. ()

 

True. x86 (32 bit) compilers on Windows don't do so either AFAIK.

 

 

 


Furthermore, exceptions (zero-cost or not) depend on RTTI, which is non-ideal.

 

They are both core parts of the language, so switching them off is compiler-dependent anyways, but it used to be possible to switch of RTTI but keep (and use) exceptions on GCC.

 

EDIT: After having a look at the video, maybe you meant in emscripten?


In Topic: Gamedevs presenting language problems to C++ standards working group

17 April 2015 - 04:55 AM

 

Exceptions should only be used in exceptional situations.

 

Except nobody really uses them like that. Boost is a "great" example here. File exists? Throw! File doesn't exist? Throw! But it's not just Boost, many projects use them like that. Every action can lead to an unexpected exception, followed by a crash/slowdown.

 

If you can't "defuse" an exception quickly, what's the point? Errors can be thrown with plain functions too. Would be much cheaper/safer as well, plus you'd have access to the call stack.

 

On a side note, I wish there was some standardized way to access the call stack. It's a solved issue in any half-decent, modern language.

 

If you are talking about Boost.Filesystem, most functions in Filesystem support either using an error code or throwing an exception, see the third bullet point on http://www.boost.org/doc/libs/1_57_0/libs/filesystem/doc/index.htm


In Topic: Gamedevs presenting language problems to C++ standards working group

17 April 2015 - 03:00 AM

Regarding exceptions... This is anecdotal evidence, but I've made some toy graphics applications that use exceptions, and noticed that weaker PCs would grind down to a halt if a bug caused an exception to be thrown at every frame of gameplay. I didn't figure out why, but I assume something is being totally thrown off. Makes me think games are better off just ignoring errors and just logging/asserting in debug builds instead.

I asked some emscripten people about best practices for exceptions, and the answer was something like "no dude... just... just don't." so it seems like you can't safely assume exceptions are okay universally.

Exceptions should only be used in exceptional situations. Modern (x64) zero-cost exceptions are truly free (so much cheaper than return value checking) as long as no exception is thrown. As soon as an exception is thrown, it becomes a thousandfold more expensive than return checking due to massive icache misses, multiple indirections etc.


PARTNERS