Jump to content

  • Log In with Google      Sign In   
  • Create Account

Brother Bob

Member Since 26 Nov 2001
Offline Last Active Yesterday, 07:34 PM

#5012757 recursion with reference parameter

Posted by Brother Bob on 20 December 2012 - 04:58 AM

Actually, scratch that, I was so focused on the return value from the score function that I didn't see that you actually print the value of total after that.

The reason is the order of evaluation of parameters within an expression. The language does not specify the order in which sub-expressions within an expression are evaluated. In this case, you have two sub-expressions that causes the problem:
  • The value of the function call to score.
  • The value of total.
The language does not specify the order in which these two sub-expressions are evaluated. If the value of total is evaluated before the function call, then the value of total results in zero, and then the function is called, setting it to its new value. In essence, you have two expressions where one (the value of total) depends on the other (the function call), and where the one expression has a side effect on the other expression. Your program is not well formed.

You need to call the function and grab its return value before printing it to ensure that the function is actually called before printing the value of total.
int total = 0;
int myscore = score(sol, total);
cout << myscore << "/" << total;

#5012755 recursion with reference parameter

Posted by Brother Bob on 20 December 2012 - 04:48 AM

You keep adding up the values depending on locationToScore->explored, but you never change the explored-member anywhere so my guess is that all of them are false and thus you keep adding up zeros all the time.

#5012394 multiply defined symbols found

Posted by Brother Bob on 19 December 2012 - 04:55 AM

Don't do the assignment of the extern variables in the header file, that turns the extern declaration into a definition and your linker is complaining about multiple definitions. Only declare them with extern in the header, and define them without the extern in one source file.

extern SDL_Surface* sScreen;
SDL_Surface* sScreen = NULL;

You don't have to do the extern declaration for primitive const variables such as your integer, though. They have static linkage by default, so you can leave them in the header file but remove the extern from them.

#5012259 Bottom Row of 4x4 Matrix

Posted by Brother Bob on 18 December 2012 - 06:19 PM

Your element 15 of the inverse is incorrect. The denominator is missing a parenthesis to ensure that the multiplication by f doesn't end up in the numerator.

#5012195 Help: Telling one mesh from another in the vertex shader

Posted by Brother Bob on 18 December 2012 - 02:35 PM

Yes, that works just fine.

In case it was the command buffering that threw you off and things were only drawn once the command buffer was flushed, then that is a different story and I can understand your concern. Commands may be buffered as much as the driver likes, but the observed behavior must be as if everything was drawn immediately though.

#5011993 Finding float elements have the same value in an array

Posted by Brother Bob on 18 December 2012 - 05:23 AM

The naive way, without modifying the array itself in any way, is to nest two loops and compare all pairs of elements of the array. Say you have an array of N elements. The outer loops with index i loops from 0 to N-2, and the inner loop with index j loops from i to N-1. The index pair i and j will cover all pairs for you to compare.

An algorithmically quicker method is to sort the array first (and preserve the original index information if you need that) and then only look for adjacent element with equal values.

Note that once you introduce an epsilon in your comparison, you may get some non-intuitive results. Your code may say that elements x and y are equal and that y and z are equal, but that x and z are not equal. The epsilon-comparison is not transitive.

#5011627 Using multiple header and .cpp files

Posted by Brother Bob on 17 December 2012 - 04:14 AM

Header guards, or any other mechanism to prevent a header from being included more than once, does not prevent multiple definition errors. Clicky; on page two, your error is the fourth pitfall listed.

#5011415 Bottom Row of 4x4 Matrix

Posted by Brother Bob on 16 December 2012 - 05:42 PM

I addressed that in my last paragraph; you have to perform a full 4-dimensional multiplication because you cannot multiply a 3-dimensional by a 4x4 matrix. You have to expand the multiplication using a full 4-dimensional vector.

Here's your matrix and vector and the product of the two.
>> M
M =
    0.7500    0         0         0
    0         1.0000    0         0
    0         0        -1.0001   -0.2000
    0         0        -1.0000    0
>> v
v =
>> p = M*v
p =
See how the fourth element of the vector p is -3.0? That's because your 3-dimensional vector is actually a 4-dimensional vector with an implicit element at the end with a value of 1.0.

The perspective division is just dividing all elements of the vector by the fourth element:
>> p./p(4)
ans =
So your resulting projected 3-dimensional vector is (-0.2500, -0.6667, 1.0668).

#5011218 Bottom Row of 4x4 Matrix

Posted by Brother Bob on 16 December 2012 - 04:14 AM

I'm not really sure if A is used at all, I did this a long time ago, but B is supposed to be the perspective divide element.
Or at least B and the projection matrix modify the 4th element of the position, so that in clip space if you divide by it, you get the ndc coordinates.

The entire bottom row is used for the perspective division, not just the B-element.

For example, for an orthographic projection, the bottom row is [0, 0, 0, x] where x is some value depending on the parameters of the projection matrix. That means that the fourth component of the resulting vector after multiplication is the fourth component of the in multiplying vector, to some scale factor. For glOrtho, x=1 at all times though, which means that as long as the Z-coordinate of the input is 1.0, which is often the case, there fourth component of the resulting vector is also 1.0, and there is effectively no perspective division, hence no perspective since it is an orthographic projection.

On the other hand, for a perspective matrix, the bottom row is [0, 0, x, 0]. That means that the fourth component of the resulting vector is the third component of the multiplying vector, to some scale factor x. The third component is the depth, and hence the perspective division is now dependent on the depth; you now get a perspective effect.

Likewise, the first two elements of the bottom row can also be non-zero to get a perspective effect along the X and/or the Y-axis instead.

how would I apply A and B to a Vec3? ( I know how to translate and rotate )

It doesn't make much sense to talk about how to apply these elements to a 3-element vector. You simply cannot multiply a 3-element vector by a 4-by-4 matrix in the first place. What you do when adding multiplying the 3-element vector by the rotation part and then adding the translation part as a separate step is really just assuming that the missing fourth component of the 3-element vector is unity. In order to handle the fourth row of the matrix correctly, you have to do the same assumption again, carry out the multiplication, and see how the bottom row affects the other three elements, as well as performing the final perspective division to ensure that the assumption that the fourth component really is unity even after the multiplication.

In the end, you really have to carry out a full 4-vector times 4x4-matrix multiplication, although you can assume that one element is unity and eliminate its multiplication with the corresponding elements of the matrix, and just add them.

#5011094 Applying a perspective matrix

Posted by Brother Bob on 15 December 2012 - 05:34 PM

That's the result of making the fairly arbitrary decision of using a bottom-left origin and a right-handed-based coordinate system; the negative Z-axis points into the screen.

#5011082 Applying a perspective matrix

Posted by Brother Bob on 15 December 2012 - 05:09 PM

Perhaps the perspective matrix is similar to the one in gluPerspective where the Z-range is actually negative. A near and far clip plane parameter pair of 0.5 and 3.0 corresponds to a visible Z-range of -0.5 to -3.0.

#5011076 Using std::vector to load data to VBO

Posted by Brother Bob on 15 December 2012 - 05:05 PM

What do you mean it won't get passed; what isn't passed to that function? Does it not generate a unique buffer handle?

#5011061 Applying a perspective matrix

Posted by Brother Bob on 15 December 2012 - 04:39 PM

I don't know, why don't you try and see?

I'm not saying that is the only problem, just one I saw. I could see another potential problem in that only the far side of the cube remains, and with back face culling, you won't see the back of the cube (which would be viewed with the inside towards the viewpoint) assuming the winding order of all faces are consistent. A better idea than adjusting the near clip plane is to simply move the cube inside the view volume instead. Move it 1 or 2 units into the scene so that the Z-range becomes, say, 1 to 1.5 instead.

#5011048 Applying a perspective matrix

Posted by Brother Bob on 15 December 2012 - 04:10 PM

The cube extends from 0 to 0.5 along all axes, including the Z-axis, and the near clip plane of the projection matrix is 0.5. As expected, the cube is clipped entirely because it is outside the view volume.

#5011034 Using std::vector to load data to VBO

Posted by Brother Bob on 15 December 2012 - 02:57 PM

When drawing, you're binding the color buffer object but setting the vertex pointer. Sounds from your description though that you are much better of drawing pixel rectangle with glDrawPixels instead of drawing the individual pixels as points.