Arcanaville! I need your help, please!

Because the rise of the variable was set for the window already in b=500.0. What the formula is trying to do is either turn b into 0 or get the difference if the window is panned up or down hence b-500. y=640 put into the code is fine though.

As far as the multiply is concerened, c++ needs the * symbol to designate mulitiplication, the compiler would read d2 as a variable in itself instead of d*2.

v = 500;
y = 640;
z = (v(y-b)/(a+(b-500)-b))-v;
x = (c-d2)*((z+v)/v)+d;

or in c++ code:
v=500.0f;
y=640.0f;
z=(v*(y-b)/(a+(b-500.0f)-b))-v;
x=(c-d*2)*((z+v)/v)+d;

Like Bob.



I had a boss many moons ago who always named one of his variables "Bob" and on a bad day "Bob2"

I always do when I code, I was just going along with Durakken in the post.

Actually, my variables go even further by designing its type. So for instance x, y, z would be fX, fY, fZ the "f" stating that the variables are floating point variables.

yeah... a, b, c, d is just easier to keep straight in your head than window.x window.y...

btw I was thinking about this more.

Let me see if I understand what you're doing...

you have surface with a puck on it in an absolute position.
You then can move the window with which you are looking at this surface and puck.
You can touch a point on the window which shoots a straight line from that point to the surface which is where the puck should then move to?

If this is accurate then what you are doing is what I said earlier..which is messing with equations for finding the length of a side of a triangle.

So to go through mentally what I'd do...

#1. Window or Portal is an object and contains the following variables
Angle, height, width, pos(x,y), touch(x,y)

Angle is the angle of the window from the ground...which is important.
Height and width are the size of the window which will be needed to figure out position of touch in the world
pos is the position of the window, based on the the upper left corner of the window.
Touch is the position of where you're touch the window and works off the window's position (ie upper left is 1,1 and as you go down and right it increases)

#2. Set up a convert sub-function of touch in the window to where that touch is in the world... the object's touch would be called window.touch.x while this one would be called touch.x or something like that...

this object would have angle, x, y, and possibly z parameters... z is stationary right? or is it not?

#3.

do the simple math for where the puck should be... this should be something like...

Assuming that the ground is 180 degrees and the window is stationary it should be 90 degrees which means all valid angles would be 45 degrees or less (unless you can move the window), but this should be a "if window angle > 45 break"

You know the height of the window to the ground which gives you the length of the side...so if your angle is say 45 degrees the puck should...if I remember right... move the same distance as the height of the of the window or double it or half it... something like that. So all you need is the touch(x,y,z) - puck(x,y,z) and then you need the angle(s) of the window.

And then you simply calculate for that

And that formula is at this website http://library.thinkquest.org/20991/alg2/eqtri.html
under Law of Sines

It's higher level math and outside my realm, but I'm sure you understand it and that should give you what you need and if you follow what I said it should give you a lot more freedom in the program to mess with in program.


And those calculations and such look nothing like what you have, but then I barely understand what you are doing with those calcs.

I agree that building a solid foundation for a complex program is a good idea. However, with all due respect, we don't know what exactly Innovator actually wants to do with his program. For example, if the "window" never moves, and if the floor position will always remain in the y=640 plane, and if all he wants to accomplish is just a nice graphical effect that was best described with the puck scenario, I'm perfectly fine with keeping the constants and the prepared equations.

In other words, if you want to build a Lego toy airplane, you don't need to worry about its aerodynamics.

10joy

The other thing is never over-optimize calculations. That's what the computers are for. Unless you have a specific performance issue, algorithmic simplicity is better than overoptimized calculations. Its easier to debug code that is algorithmically transparent.

In any event, nobody goes through the derivations from scratch anymore except as a learning process. We do this 3d stuff with matrix-based transformations now. That type of 3d code is more transferrable to accelerated graphics APIs.

But for something as straight-forward as this, I'd stick with the simple linear transform: touch.y = 640 * [500 / (z + 500)]


Incidentally, I just have to shoot out there that this is basically the math for Duration-based resistance:

NetDuration = BaseDuration * [1 / 1 + Resistance]

The 500 values are constants that scale the math, but its the same math. Lots of MMOs use similar math for various linear scaling or diminishing effects. Imagine replacing the 500s with 100s:

touch.y = 640 * [100 / (z + 100)]

That's actually the Duration-based resistance formula, scaled for 100 percent. When Z is 100 (resistance = 100%), the factor in the brackets becomes 1/2, and the touch point becomes half of the original y plane coordinate. In other words, the puck's distance from the center of the screen is cut in half. Like a Mez duration that starts at 640, and is then cut in half to 320.

Yeah... my mind just keeps trying to figure it out is all ^.^ The answer is already there for what he wants the program to do, but there is never anything wrong with discussing other ways to do the same thing or how to make it cleaner or what not as if it is a learning then that's sorta the point.

Also it's graphical programming which my mind just fizzles on which results in the above mentioned trying to figure it out. Brain goes into over drive... over heats...and then crashes ^.^ And thats also why you get all those crazy messed up edits that i noticed later on how stupid they were and that i was correct before i edited >.>

Yeah, I probably shouldn't have done this from scratch. But I had a problem with lack of resources and equipment for a full 3D project so I decided the best way to complete the project was 2D objects on a 3D plane. Doing it from scratch seemed best as I can control the graphics scaling better for best quality since the objects are basically 2D sprites. Also, for now, the window itself only needs to pan up, down, left, and right, therefore this seemed the way to go.

The next 3D project I do for sure I'll do with 3D graphics APIs.

True that. I try to keep things as simple as possible (and with lots of remarks) so I can at least figure out later what I did should I need to add features or have to debug something about it.

Honestly, if it was me, I would transform the target point to a normalized one as if there was no roll (basically, undo the roll), do your calculations as you currently do them, and then transform the results back to the rolled frame of reference.

In most coordinate and graphics systems I've seen, most of the nitty gritty stuff is done in a simple frame of reference, and transforms are applied to it. So lets say your screen is currently rolled 40 degrees counter-clockwise. That means the y-plane is now more at 4 o-clock rather than 6 o-clock (aligned with the bottom of the screen). Rather than make more complex formulas to calculate what's going on, I would take the target point, rotate that 40 degrees *clockwise* and compute where it *would have been* if the screen wasn't rolled. That would tell me what the x,y,z of the target would have been. Then I roll that x,y,z target 40 degrees back counterclockwise, and that's where the puck goes. Calculating rotation about the z axis shouldn't be difficult by itself.

Hmm...that should work, I'll see if that's possible to code (I'm using Cocoa Touch's CoreGraphics framework for this).