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 07 Apr 2012
Offline Last Active Jan 19 2015 06:50 AM

Posts I've Made

In Topic: Crazy GLSL bug

03 January 2015 - 08:15 PM

Thanks again!


Not sure how you are calculating specularFactor, but most of the time with diffuse/specular (well all the time really) you want to clamp your dot products between 0 and 1.

Well, with the fix it is effectively clamped now. It can't get greater than 1 because both vectors for the dot product are normalized and if it is smaller than 0 the if-block where the specularColor is calculated wont be entered and specularColor stays at (0, 0, 0).

In Topic: Crazy GLSL bug

03 January 2015 - 05:13 PM

Okay, I figured it out, thanks! Like you suggested I tried different values increasing by 0.1 and found out that both lines give identical results except if the value is exactly 1. My guess is that if you write pow(specularFactor, 1.0) openGL removes that line because it expects the result to be specularFactor. However in my case specularFactor was negative for some fragments and then pow yields undefined results (apparently even if the second parameter is 1.0). The solution was a simple if statement:

if (specularFactor > 0.0) {
	specularFactor = pow(specularFactor, matSpecularPower);

Now the artefacts are gone and everything works perfectly. smile.png

In Topic: C++ c

23 March 2014 - 09:49 AM

There is an assertion to warn you in debug mode if this is accidentally used. It is a design decision whether the class should actually support this use case where the client code attempts to call removeElement() on arbitrary indices/ID.

Ah, I just overlooked it. I expected it in the removeElement method, but it was in the clear method.


It would appear to me that the intention is that a client class would use addElement(), store an index/ID, and then use getElement() when necessary, finally using removeElement() when finished.

Your correct. A warning when I accidentally do something wrong is all I need, I just didn't see that it's already there.


I think Container is too generic. To me, it is some kind of handle system, so maybe a name like HandleRepository?

Yes, that's better, thanks!

In Topic: C++ c

23 March 2014 - 08:23 AM

Okay, now I know that you can write unsigned instead of unsigned int. Also thanks for showing how to implement the rule of three. I think there might be a little bug if removeElement is called for an element that isn't used. The value of nextFreeIndex of that element would get lost and be overridden by freeIndex. Maybe an assertion that isUsed() is -1 like you suggested earlier would help here?


I agree about the name, though it's hard to think of something new. Maybe just call it Container?

In Topic: C++ c

22 March 2014 - 09:18 PM

Wow, lots of interesting stuff. I didn't even know you could have internal structs. That alone will be very helpful in some other places. It was a bit overwhelming, but I think I understood most of it now (though I wouldn't be able to reproduce it) except the reinterpret cast. I will look that up.


I will also look at the code some more and try to adapt as much as possible to improve my coding skills. Thanks for taking the time! You guys are awesome!