http://forum.audiogames.net/viewtopic.php?id=22574
Fri, 22 Sep 2017 05:30:05 +0000PunBBhttp://forum.audiogames.net/viewtopic.php?pid=330400#p330400
So I will also need two separate velocity vectors, one for the player, one for the ball. I don't think I'm going to worry with drag, friction, and all that shit related to the player, so I won't need duplicates of those.]]>Fri, 22 Sep 2017 05:30:05 +0000http://forum.audiogames.net/viewtopic.php?pid=330400#p330400http://forum.audiogames.net/viewtopic.php?pid=330154#p330154
It seems like you wouldn't need a global theta, so much as the orientations of the players / the ball. In that case, you could have theta be a property of those objects, so the only time you'd need to pass theta around is if you're using global functions, or changing direction.]]>Tue, 19 Sep 2017 22:28:04 +0000http://forum.audiogames.net/viewtopic.php?pid=330154#p330154http://forum.audiogames.net/viewtopic.php?pid=330105#p330105
guess that I am going to have to get used to the adjustment of Y being travelled with 90 degrees, and the counter-clockwise system in and of itself because of the way sound pool updates. Shots that I would normally expect to go to the right go straight ahead, etc. So if I want to hit the ball directly in front of me to the other side of the court, I have to hit a 90-degree shot. I suspect that for a while that's going to feel totally weird. As for the other issue re theta declaration and passing, I still haven't figured out what to do with that one. It is going to annoy me if I have to make math a class. It's ridiculous and should be unnecessary, given that math is immutable...2+2 is always going to be 4. The thing is, I suspect that if I do that, it will probably work correctly, since I can specify to use that particular theta. I don't need 15 thetas. But surely there's got to be another way of doing it.]]>Tue, 19 Sep 2017 13:27:41 +0000http://forum.audiogames.net/viewtopic.php?pid=330105#p330105http://forum.audiogames.net/viewtopic.php?pid=330037#p330037
It sounds like you want -theta+90. You could either apply that to whatever takes theta, or you could just set 90 as the default and transform any messages.To get 0=+y, 90=+x, ... let's call it the 12o'clock system, and the 0=+x, 90=+y version the right-handed system...From right-handed to 12:00: theta12 = 90-theta_rh. From 12:00 to right-handed: theta_rh = 90-theta12. ... Use pi/2 if you want to do the same for radians.As for which to apply where, that really depends on what you're aiming for. If you want to work with 12o'clock values, then put the conversion at the top of any function that uses theta for major calculations. The only question that follows is how you'd reference theta later, which brings us back to the previous issue.]]>Mon, 18 Sep 2017 22:59:51 +0000http://forum.audiogames.net/viewtopic.php?pid=330037#p330037http://forum.audiogames.net/viewtopic.php?pid=329935#p329935
So how would I best handle this? How would I determine where the player starts out facing when the game starts? Is there a way to make it the way I originally thought it was, 90 degrees to the right, 180 behind, 270 left, and 0 straight ahead, or are the values of 0 being along y, etc. set in stone? I also need to know because it affects the sound pool and the way the ball sound travels as it's updated.]]>Mon, 18 Sep 2017 01:07:08 +0000http://forum.audiogames.net/viewtopic.php?pid=329935#p329935http://forum.audiogames.net/viewtopic.php?pid=329897#p329897
Yeah. I think this is why Swamp tends to start players off facing east. If you put compass directions on the x/y axes, 0dg is east, 90dg is north, 180dg is west, and 270dg is south. ... unless you're using screen coordinates, in which case north and south would be reversed, but once you go to 3 dimensions, there's usually not much point in bothering with screen coordinates, since those are based on pixel arrays.]]>Sun, 17 Sep 2017 16:33:17 +0000http://forum.audiogames.net/viewtopic.php?pid=329897#p329897http://forum.audiogames.net/viewtopic.php?pid=329875#p329875
So I'm just trying to figure this out from the player point of view. If X is side to side movement, and y is front to back, and if 90 degrees makes the ball move along y, front to vack, then that would mean that the player actually starts out facing 90 degrees. Is that correct? Meaning that 180 degrees would go to the player's left, and 270 degrees would be behind the player. Is that right? I never knew that. thought that facing straight ahead would be 0, 90 to the right, 180 behind me, and 270 directly left.]]>Sun, 17 Sep 2017 14:00:14 +0000http://forum.audiogames.net/viewtopic.php?pid=329875#p329875http://forum.audiogames.net/viewtopic.php?pid=329847#p329847
0 radians generally points along the positive x axis, so I would expect 90dg to move along the y axis.As for x, notice the number of 0s. This is the limitation of floating point arithmetic, aka rounding error. Pi/2 is an irrational number with infinitely many digits. You can't represent all of those in 64 bits. You can't represent all of those in 9000 bits, because 9000 is less than infinity. So you inevitably have some minor discrepencies due to rounding. As a general rule, physics in the real world struggles beyond the 8th decimal place, unless you're dealing with quantum mechanics, for which PCs are woefully inadequate. So, if the drift due to rounding errors is small enough that it wouldn't be measurable by a human in any cases that are going to show up, it's generally safe to treat 0.00000001 as 0.I mean, you have 10 zeros after the decimal point. If you're measuring in meters, that is enough accuracy that you'd need some very expensive equipment to detect the difference. It's still bigger than atoms, but I'm not sure that a paramecium would notice.]]>Sun, 17 Sep 2017 04:15:59 +0000http://forum.audiogames.net/viewtopic.php?pid=329847#p329847http://forum.audiogames.net/viewtopic.php?pid=329838#p329838
So until I figure out what the hell to do about getting theta to pass and change correctly, preferably without making math a class, I decided to test whether theta would control the direction correctly. Which brings me to the following question: What...the...fuck? Radian values should be immutable. In other words:if 90 degrees = 1.5707963268 radians, and knowing that position = velocity*DT:double theta = 1.5707963268;vector vel((acc.x/M2)*cosine(theta), (acc.y/M2)*sine(theta), grav.z);This should make the ball travel 90 degrees. That would mean that it would travel strictly on the x axis, and none on y, meaning that Y should remain 0. However, this is what the log shows the travel to be. I've only shown the first 5 entries, but you will see what I mean:position of ball.x is -0.000000000019894, position of ball.y is 3.8982412815094.position of ball.x is -0.000000000039591, position of ball.y is 7.75790357589722.position of ball.x is -0.000000000059289, position of ball.y is 11.6175222396851.position of ball.x is -0.000000000078986, position of ball.y is 15.4771375656128.position of ball.x is -0.000000000098684, position of ball.y is 19.3368358612061.I see two problems here. First of all, the ball is travelling along the Y axis instead of the X one, meaning that it's going straight ahead. Last time I checked, that's not 90 degrees. Second of all, the ball is moving very, very, very slowly along the X axis, but apparently in the wrong direction, as the numbers are negative, which would mean the ball is moving to the left. Again, not 90 degrees. And I know that my math is correct. I doubt very seriously that every website showing the value of 1.5707963268 radians is that mathematically fucked up. And I just verified it with a calculator. So, again, my question is, what...the...fuck?]]>Sun, 17 Sep 2017 01:04:00 +0000http://forum.audiogames.net/viewtopic.php?pid=329838#p329838http://forum.audiogames.net/viewtopic.php?pid=329745#p329745
Interesting...I tried ::theta = theta; and the compiler was fine with that. It did change theta in math.bgt, but the values for T1, which is cosine(theta), and T2, which is sine(theta), are still 1 and 0 respectively, which is incorrect. Please see my above post re class, but I would really prefer not to do that.]]>Sat, 16 Sep 2017 00:04:32 +0000http://forum.audiogames.net/viewtopic.php?pid=329745#p329745http://forum.audiogames.net/viewtopic.php?pid=329685#p329685
The only other possibility that I can think of is that the global theta declaration in math.bgt only applies to math.bgt. In other words, it's global to any function within math.bgt, but when it's passed to another script, like vectest.bgt, it doesn't update correctly because it's outside of math.bgt. I'm not positive; it's just a thought.I have a suspicion that if I made math a class and declared theta there it would work correctly. But I was hoping to avoid doing that. To me, it just makes sense for them to be global. Math is math, global across the board. Specific formulae related to physics are immutable. I shouldn't need a specialized class for this. The only two vectors that make any sense to me being in a class at all are the ones for position of the ball in the ball class, and the position of the player in the player class. Other than that, to me it makes the most logical sense for all other vectors related to physics to be global, and for all specific formulae to be global as well.]]>Fri, 15 Sep 2017 14:18:13 +0000http://forum.audiogames.net/viewtopic.php?pid=329685#p329685http://forum.audiogames.net/viewtopic.php?pid=329676#p329676
I think that you can use the &out; to make a C-style pointer out of a number, but that's almost certainly not what you want to do, here. You can't use handles on primatives, which numbers and bools are. I'm not sure about strings.I think the main confusion here is over how variables are managed internally. I can try to explain how that should work in this case, but it might take a while.]]>Fri, 15 Sep 2017 12:50:32 +0000http://forum.audiogames.net/viewtopic.php?pid=329676#p329676http://forum.audiogames.net/viewtopic.php?pid=329628#p329628
Any way to use a handle to reference the correct theta? I tried something like:void move(theta@ T)but the compiler wasn't pleased. The only global variables I have for the purposes of this test are in the main test script, vectest.bgt:#include "sound_pool.bgt"#include "voice.bgt"#include "math.bgt"#include "ball.bgt"#include "clock.bgt"#include "player.bgt"#include "logger.bgt"#include "snapshot.bgt"

void move(double theta){B.moving = true;test.write("test.log", true);B.pos += vel*DT;test.add_entry(C.frame);if(B.pos.z <= 0){env.destroy_all();B.moving = false;testing = false;exit();}if(C.frame == 5){B.slot = env.play_2d("sounds/ball.ogg", user.x, user.y, B.pos.x, B.pos.y, false);C.frame = 0;}C.tick();C.update();env.update_sound_2d(B.slot, B.pos.x, B.pos.y);}As you can see, no theta. in ball.bgt:class ball{float x, y, z;vector pos(0, 0, 0);int slot;//These booleans will be adjusted given the new vector implementation, but for now, they can remain.bool tossing = false;bool moving = false;bool rising = false;bool choosing = false;ball(){x = 0;y = 0;z = 0;}ball(float x, float y, float z, int slot){this.x = x;this.y = y;this.z = z;this.slot = slot;}Again, no declaration of theta.In math.bgt:double CT = 1.2;double DT;double theta;double deg;float M2 = 0.057;float x, y, z;float d;float roh = 1.151;float A = 0.0033;float CD = 0.507;float FL;float DX = (CD*roh*A)*power((vel.x/2),2);float DY = (CD*roh*A)*power((vel.y/2),2);float DZ = (CD*roh*A)*power((vel.z/2),2);const double pi = 3.14159265358979;As you can see, this is the only theta. And since math.bgt is not a class, these variables should be treated as global, just as they are in the main vectest.bgt script. If I change theta in math.bgt, it does change in main. However, if I pass theta to ball, it does not change in main, which means the theta in math.bgt is not being updated correctly. I'm not sure how there is a scope issue, since any variable in math.bgt is global.

]]>Thu, 14 Sep 2017 22:57:39 +0000http://forum.audiogames.net/viewtopic.php?pid=329628#p329628http://forum.audiogames.net/viewtopic.php?pid=329625#p329625
I think there's a chapter somewhere in the language tutorial on scope, but basically, function parameters are creating local variables (which is why we have to pass around handles when dealing with objects). The name conflicts happen only in the same scope, so you can technically have four separate thetas, in global (that'd be the one in math.bgt), local to main, local to ball::move, and as a property/instance variable/member variable (the terminology on this one is either woefully inconsistent, or more complex than I'm aware) for the ball class.So, in the move function, you could access the local theta (theta), the ball's theta (this.theta), or the global theta (::theta), but not a hypothetical theta declared in main, even though main is technically still on the stack.A quick fix might be to add the following to the move function, near the top. It's not going to resolve the scope issues, but that could take some major reorganizing of your variables, so this is something of a bandaid@:::theta = theta;I don't remember if I've ever tried anything like that, but either it will work, or the compiler will have a very self-explanetory complaint.]]>Thu, 14 Sep 2017 22:17:27 +0000http://forum.audiogames.net/viewtopic.php?pid=329625#p329625http://forum.audiogames.net/viewtopic.php?pid=329582#p329582
Ok, I think I discovered the issue.I wanted to track when theta was changing value, so I did the following:I added the following lines to main():test.write("test.log", true);test.add_entry("Theta in main is " + theta + ".");In ball:test.write("test.log", true);test.add_entry("Theta in move is " + theta + ", T1 is " + T1 + ", and T2 is " + T2 + ".");And in math, I had to create a function, since it seems that for some reason you can only write to a log file within a function:void debug(){test.write("test.log", true);test.add_entry("Theta in math is " + theta + ".");}This is what the log shows:Theta in main is 0.Theta in move is 4.5, T1 is 1, and T2 is 0.Absolutely nothing, not even 0, in math. Math is not listed at all in the log, and it should be. What this looks like to me is that the original theta, the one in math, which is the only one I declared, isn't changing at all. Evidence of this is in the values of 1 and 0 respectively for T1 and T2. Keep in mind that if theta were truly 4.5, then T1 and T2 would be much different, since T1 = cosine(theta), and T2 = sine(theta). If I were to go into math and change double theta; to double theta = 4.5, then theta is now changed in main, in move it remains 4.5, and now T1 and T2 are:Theta in main is 4.5.Theta in move is 4.5, T1 is -0.21079579943078, and T2 is -0.977530117665097.What that seems to mean is that somehow, a new theta is being declared in void move(double theta)or the value for theta isn't updating correctly. The thing is, I never declare another theta other than in math: double theta;In move, I do not declare theta:void move(double theta){B.moving = true;test.write("test.log", true);test.add_entry("Theta in move is " + theta + ", T1 is " + T1 + ", and T2 is " + T2 + ".");B.pos += vel*DT;test.add_entry("Ball is now at " + B.pos.x + ", " + B.pos.y + ", " + B.pos.z + ".");env.update_sound_2d(B.slot, B.pos.x, B.pos.y);... //more code related to frames and such.It almost looks like the line void move(double theta) is somehow creating a separate variable named theta. I've never had that happen before. I thought that it was legal to say: void function(data type variable), and it would simply pass the original declared variable value, not create a new one. Which means that when I say:move(2.6)the original theta that I declared in math should become 2.6. This is how it has always worked for me in the past. If I passed a variable, i.e., void move(int direction), or void shot(int ShotType), it always updated correctly. This should be no different. And besides, now that I think about it, theoretically, if it is creating another instance of theta, then wouldn't I get a compiler error based on name conflict? I think it's something like: "'theta' is already declared."This issue makes no damn sense to me.]]>Thu, 14 Sep 2017 16:06:14 +0000http://forum.audiogames.net/viewtopic.php?pid=329582#p329582