TheUnbeliever

Yes, that's

Would it really mess up my timer variable, or my hOut, etc.? I'll post the fixes to the stuff like that in a little bit, but I need help on the base problem here.

Yes, it would - that's why two separate people have told you so :-) You may have similar problems in other source files, but that is the cause of all the errors you've posted here. Roughly what's happening here is:

1. Compiler looks at function definition.
2. Compiler sees that it claims to be a member function, but there is no matching declaration.
3. Compiler tells you so.
4. Compiler assumes that it is not a member function, and proceeds to see what sense it can make of the rest.
5. Because this assumption is wrong, Compiler thinks things which you expect to be in scope (e.g. timer) are not in scope.
6. Compiler tells you so, repeatedly.

You have to take errors after the first with a pinch of salt. With practice, you'll learn to tell when an earlier error has caused the others. Until then, as I say, a reasonable rule of thumb is that if you get squillions of errors, then one of the first few is the real problem. I've had GCC spit 40 pages of errors at me, all to be fixed by changing just a couple characters in some header somewhere.

Well, for example, the 'Act_Shoot' declaration in FINALBOSS.h is commented out. The compiler complains about that, and will then spew out a whole collection of errors for the body of the function because e.g. as it's not a member function, it doesn't have (unqualified) access to other members of an instance like 'timer'. More generally, a small number of errors is often unrelated, but a huge number suggests that there's a few root causes cascading, and that you're better taking the first, recompiling and repeating the process until they're hacked down to a more sensible number.

You can index a linear array as if it were multidimensional by using a formula like x + y * width. i.e. Skip y rows of width elements, then x elements preceding the one you want on the row you want. Your code just reverses this. Where width is the number of tiles in the texture, and x < width: integer division truncates so (x + y * width) / width = y; % is the modulo operation, which effectively gives you the remainer: (x + y * width) % width = x.

Can you clarify your system some more? RANSAC is a general robust estimator. It's entirely possible to use it to extract multiple models from a dataset by e.g. running it repeatedly on the 'leftovers'.

EDIT: Didn't realize this thread was from March.

Then you could just use the left-eye image for player 1 and the right-eye image for player two, and use standard 3D displays.

I ruled this out because of the limited viewing angles if the glasses were polarized, but obviously this wouldn't be a problem with active shutter, which I didn't think of for some reason...