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 20 Nov 2005
Offline Last Active Dec 27 2014 07:21 AM

#5194599 real time reflections from arbitory surfaces.

Posted by tanzanite7 on 25 November 2014 - 08:21 AM

"this video is private" and the post has no content anyway as pointed out previously.

#5191210 Thread-post never made ... almost

Posted by tanzanite7 on 04 November 2014 - 04:22 PM

I have a rubber duck at my desk for this exact reason. If I'm stuck, I explain the problem to the duck and half the time figure out the solution in the process.

Hehe, sweet. biggrin.png ... also, pics or didn't happen tongue.png

Either do:

void skipX(char const* const& at)
void skipX(char*& at)
However, I advise you not to take a reference to a pointer because that's one extra memory read you'll be doing (i.e. it's slower). It's always faster to copy raw types than reference them.
void skipX(char* at)

Erm, ...
* the first one will cause a syntax error given the function body.
* the second: the first step in fixing const-correctness is not to just abandon it all.
* the example code was marked with: "silly-made-up-simplified-mini-example" ... it is obviously meant to expose a language quirk and not to micro optimize a nonsense algorithm.
* any compiler worth anything will inline that silly snippet -> hence there wont be any redirections and nothing to optimize.
* obviously, my real case uses pass by reference because it needs to affect the variable used in function parameter.
* no-one cares about micro optimizations without a bloody good reason.
* oh, and the third one changes what the function does - likely emitting an warning that something got fucked up.


#5191157 Thread-post never made ... almost

Posted by tanzanite7 on 04 November 2014 - 12:12 PM

An observation of the self-reflection kind: the vast majority of problem-threads i start to write - i never actually post. It goes like this:
* problem
* need to explain the problem
* need to understand the problem to explain it
* ...
* never mind

Oh, well. Since the problem i had was a simple one (the facepalm moment arrived in the middle of writing the very first sentence for me) - i post it anyway for readers benefit as i have encountered variations of this problem fairly often.

Why cannot "Foo *" be implicitly converted to "Foo const *&"?

void skipX(char const *&at) {
    if(*at == 'X') at++;
void snafu() {
    char *buf = ...
    skipX(buf); // not OK! -> 'Conversion loses qualifiers' !
Noticed the problem? Did you think about it? Did thinking about it help? tongue.png

Oh, well - my take on the pesky WHY:

Foo const constFoo;
Foo *ptrFoo;
Foo const **snafu = &ptrFoo; // *** ie. if it WOULD allow this then the following can legally happen ***
*snafu = &constFoo; // exact type match: both sides are "Foo const *"
*ptrFoo = @#$%! // completely valid to do whatever with the Foo ... ow, crap - it just happens to be constFoo.
Aliasing issue, lovely. Compiler errs on the side of caution (validity of the code is the goal, not some version of const correctness in and of itself ... but that is a rant for another time deep in the complicated waters of language design not relevant to C++ with its constraints of history).

... and this kind of mind-wrappers are why one generally tries to avoid low level C++.

C++, the sledgehammer of const correctness.

So, what C++ thread did you not make lately?

#5184546 Multithreading issues: Unit test fails sometimes

Posted by tanzanite7 on 02 October 2014 - 06:13 AM

It doesn't explain why the X component of Position is screwed while the Y component is always fine.

I have no experience with boost - so, not sure i understand what it is expected to do here.

Anyway, if at any time multiple threads can work at the same data then what you are experiencing is exactly what one would expect.

In other words: "It doesn't explain why the X component of Position is screwed while the Y component is always fine." - No, that (unguarded overlapping data usage) explains it perfectly.

PS. testing MT parts of code only counts for the "basic-sanity-check" case - they are fundamentally utterly useless to check the actual validity of it beyond that.

Take a paper and pencil and revalidate your MT logic (in the end, that is the only way to write MT code) - you have a race condition (assuming you are proficient in MT land - then read relevant boost documentation to find where your assumptions clash with what it says).

#5183727 Funniest line of code ever ?

Posted by tanzanite7 on 29 September 2014 - 07:32 AM

Personal favorite of mine (from the first version of my 2D engine back in 2009) 

	runRight  = new ANIM();
	runLeft   = new ANIM();
	runBack   = new ANIM();
	runFront  = new ANIM();
	idleRight = new ANIM();
	idleLeft  = new ANIM();
	idleBack  = new ANIM();//those of you with OCD will HATE me for these lines...
	idleFront = new ANIM();//if you don't have OCD, you have no idea what I'm talking about.

Fixed for you.

#5177207 decltype(vector<Type>) doesn't compile

Posted by tanzanite7 on 31 August 2014 - 08:22 AM


Completely OT, but what does that emote mean? Never seen it before and it is rather difficult to Google for it x_x.

copy/pasting it is not so easy because my VS is in german

Yeah noticed. My grasp of German is still fairly good, besides - the gibberish part between the fairly standard text is where the problem is actually shown.

Btw, OT again, why do you use German for VS? English is not my native language either, but i still strongly prefer all my tools to be in English - easier to Google stuff etc (ie. the knowledge pool in English is a far greater benefit than the un-noteworthy benefit of having some tools in ones native language).

edit: Oh, yeah "template<typename Type> typename Test<Type>::NewType get(void) { ... }" - forgot the second "typename" there. Oh C++, you so silly.

#5177182 decltype(vector<Type>) doesn't compile

Posted by tanzanite7 on 31 August 2014 - 05:44 AM

decltype is very fragile with VS ... not that your problem has anything to do with it, just mentioning to be cautious in relying on it.

Anyway, what you seem to want is:
std::conditional<std::is_pod<SomeType>::value, SomeType, SomeType*>::type
also, might want to typedef it if it is needed often for readability:
typedef typename std::conditional<std::is_pod<SomeType>::value, SomeType, SomeType*>::type NewType;
edit: "typename" is of course not needed if SomeType is not template parameter - kind of wrote it on autopilot.

#5170724 Quaternion-Rotation to Degree (Edge-jump)

Posted by tanzanite7 on 31 July 2014 - 04:33 PM

But if I'd convert it into a rotation-matrix, I'd still get the problem at the edges,  wouldn't I?

This was supposed to mean that the conversion problem that occurs when converting to degrees also would occur when converting to a matrix.


There are no conversion problems when converting quaternion to matrix (*) - did you mean from matrix to Euler angles? Then yes, whatever is the perceived problem with quaternion->euler (I am not sure what the problem is - are the values wrong? Why do you care that the values jump around a bit?) would probably crop up again.

Euler angles are usually terrible to work with (expensive, capricious and shall i say - bloody useless. IMMHO, aka YMMV), i would repeat the advice to use a quaternion and/or matrix where appropriate instead.

*) Quaternion transforms fairly easily into a neat equivalent rotation-only matrix (Orthonormal basis. So, just a bunch of unit length orthogonal axis vectors).

Perhaps useful for reference:

#5166135 c++ basics

Posted by tanzanite7 on 11 July 2014 - 12:59 AM

Just to clarify what previous post is telling:


"using namespace std;"


... don't do that. Especially as a beginner - one benefits from clean namespace (not polluted with bazillion things a beginner does not even know exists from std and will bite him in the back). Etc: http://stackoverflow.com/questions/1452721/why-is-using-namespace-std-considered-bad-practice


I, personally, have never seen a necessity for "using namespace whatever" and consequently have never used it.

#5165240 [GLSL] send array receive struct

Posted by tanzanite7 on 07 July 2014 - 06:46 AM

uniform float lights[MAX_LIGHTS * 15];
uniform Light lights[MAX_LIGHTS];

Did you account for the padding?

I do not see how is Light defined - but it likely has some padding (check the spec). Also, did you define a standard layout for the structure?

#5153167 Ignore "Reload from disk?" prompt || Python conversion?

Posted by tanzanite7 on 12 May 2014 - 05:11 PM

Need to meditate on your Google-fu a bit.


The, shall i say, obvious first search would be "ignoreChanged" (with the quote marks of couse) - which will give a bunch of apparently topical Sublime Text links at the top.

#5148335 BRDF gone wrong

Posted by tanzanite7 on 20 April 2014 - 05:01 AM

Unexpected black patches are indicative of NaN values - might want to check/pinpoint that (glsl has "isnan" function from 1.3 onwards ... iirc).


Possible sources of NaN: http://en.wikipedia.org/wiki/NaN

#5142261 Javascript Memory leak

Posted by tanzanite7 on 26 March 2014 - 04:05 AM

biggrin.png, true that.


(sorry for being a jackass - i am just easily amused)

#5142248 Javascript Memory leak

Posted by tanzanite7 on 26 March 2014 - 03:23 AM

anyway, it just looks stupid that the garbage collector have that zigzag pattern at all
what memory does it allocate ? it uses one global variable and that's all
I didn't even declare a new variable.
This is strange indeed

1. garbage source.

While your example program itself does not visibly generate garbage - there still are plenty of garbage sources, a'la: virtual machine interpreting the javascript, jit compilation, whatever other internal structs it needs to implement the used or assumed to be used functionality of javascript.

Case in point of a possible source: calling a function needs a local scope/closure to be created and destroyed (technically - a good jit optimizer under specific conditions can prevent it from using generic GC for cleanup).

2. zigzag pattern.

Garbage collection is an overhead (ie. in a sense no useful work is done - GC is hardly the goal of any program tongue.png ). Hence GC implementations avoid actually doing it if they do not need to do it (ie. there is plenty of free memory) - allowing memory usage to steadily grow till it finally decides to do the work causing a sudden drop in memory usage => zigzag.


it seems to leak according to chrome dev tools

I have not used chrome dev tools, but i guess you are misinterpreting what it tells you.

I don't think this is a case of circular dependencies or anything to do with DOM

Yep. However, memory is not free till GC tells so => every unused crumb of memory piles up over time till GC gets rid of them all, all at once.

is this normal in javascript ?

Yes. It is common in all languages that heavily use mark-and-sweep style GC, not just javascript.

One might have a leak problem if memory usage grows over GC cycles (ie zigzag bottom line keeps growing).

#5142072 Javascript Memory leak

Posted by tanzanite7 on 25 March 2014 - 01:16 PM

/.../ and please explain me where I am wrong.

He already did:

What is "written" to setInterval is a reference to the function.

You have already stated a whole pile of nonsense, /.../

Except that his "pile of nonsense" is actually correct and your statements are not.

My guess is that you did not notice that the lambda function given to setInterval is not given as an string. This guess is also supported by the error you made in your example:

setInterval(heavy(), 1 ); // this is equal to: "setInterval(undefined, 1 )", given that heavy() returns "undefined".
instead of what you probably meant:
setInterval("heavy()", 1 );