Posts: 1 to 25 of 29

I should point out that the orientation vectors used here are ... lazy, and so might result in problems (especially with form::rotate).3dio: Contains 2d/3d geometry, now with groups, holes, and a file format that I think is compatible with the JQ3D editor. The biggest change to the engine itself is that the form interface now has a method for intersection with boxes, instead of just spheres, and attempts at making it play nicer with orientation vectors.Download

Includes2018: Updates to my other includes. The biggest additions here are keyconfig and BGT2py. The former is supposed to make it easier to do Swamp-style keyconfig, including the user-editable file and the ability to identify keys by name (for instance, for a controls menu or in-game instructions). BGT2py is a quick-and-dirty script for converting bgt files to python. It makes no attempt at perfection, just takes care of the most common differences in syntax. You will still have to edit the resulting python file for things that BGT2py missed. It's more a time-saver than a proper converter.Download

Oh, I completely forgot to mention the fpsound_pool, which wound up with 3dio because it was supposed to allow bounding shapes (that part doesn't work). It basically tries to do Swamp-style first person sound in the sound_pool, instead of the top-down perspective of the normal sound_pool. I think it still has some bugs,—some of my tests had forward and backward reversed when facing along the z axis, but I'm not sure if that's the sound or if it's the movement code I was using.The confusing part will be the orientation vectors. In 2d, it's just the unit vector corresponding to the angle, effectively (cos, sin). In 3d, it's messier, because I was too confused by rotation and addition of 3d vectors and instead went with (cos(theta), sin(phi), sin(theta)). Which is to say, x and z are for theta, and y is for elevation (phi). Since audio games almost never use elevation, an orientation vector might just be (cosine(theta), 0, sine(theta)). Since this was such a headache with the sum_angle and dif_angle functions, I included variations on those that take the numbers directly, instead of the vectors, but it still returns a 2d vector you'd need to convertMath contains several new functions for all these angle and rotation shenanigans. See sum_angle, dif_angle, and rotate3d. I found that using sum_angle on very small angles didn't seem to have any effect, so it's certainly still somewhat buggy.

And there are some additions to stdlib, an nv(x, y, z) function for quicker vector creation, whatever.

Hi.Wow, BGT into python? I never thought I'd see the day. Now if we just had a tool to write code for us, so we don't have to do the work!Really neat includes!

Guitarman.What has been created in the laws of nature holds true in the laws of magic as well. Where there is light, there is darkness, and where there is life, there is also death.Aerodyne: first of the wizard order

are you still shipping soundtrack2 with it? I made a modification of that and added an additive framework but I was working on a slightly out of date version and edited syntax so... If you could help me add bending to it and maybe get this framework into your include as soundtrack3 or soundtrackX or something like that that'd be nice. Use forum email to contact me privately. Currently my note to frequency function is nuts and my generate harmonics doesn't support bending so, and of course I'd want the bend to go all at once and not fuck up the disposition during the slide so yeah, not quite that easy, least for me. I've changed the syntax to mml type, with lowewrcase notes and p to r and the ability to use the default length with rests and things like that.

----------An anomaly in the matrix. An error in existence. A being who cannot get inside the goddamn box! A.K.A. Me.

Hi there. I think you would better provide a read me for some of those new added codes, Including that key config include. For example i don't know what I should write in the parsed file that loads as key config's data. LikeKEY_W:dor move_forward:wHow does this one work please?

Since my explanation regarding keyconfig didn't survive the forum rollback:- If you use a global keyconfig, it needs to be a handle. Apparently, the need for initializing the key dictionary doesn't work in global scope before main, making this the first time I've encountered a problem with global variables. Make it a handle, or a member of a class, and there shouldn't be any problems.- The format of config files is the same as Swamp's. IDR if this version handles shift/alt/ctrl correctly, but there is a version that does, if I can find / upload it.

I'm going to go ahead and paste the most recent version of keyconfig from my Dropbox. I forget what all changed, but I think this version handles modifiers better, and might have fixed some bugs that would cause it to crash.

That worked. Thanks. Includes 2018.zip is what it shows. Although I do not see any file call 3dio after extraction of the zip file, so not sure whether there's a second set of files, and the link above for dropbox says "error 429," too many requests. Fucking Dropbox and their stupid fucking limits. It shouldn't matter to them how many times a file is downloaded, especially when it's being downloaded by someone with a paid account.

I forgot there were two O_O Here's 3dio:https://www.sendspace.com/file/4fki6nWhich I believe has some bugs that made it through testing without manifesting, even though that doesn't make sense. If anything weird happens related to cylinders, it's most likely a bug.Actually, if you open group3d.bgt, and ctrl+f "c=cast<cylinder>(c);", that's probably a bugged line that somehow hid until the past week. It should be casting f to c, not c to c, so if you ever use that function on a cylinder, it will crash.Not sure how old this copy is. There was a bug in the cylinder class, I think with the get_bounds method, but I'd have to look it up to be sure. I made a bunch of forgetful mistakes with cylinders, for some reason.

@Cae,I've got a couple of questions about your math code. First, are you using theta as the angle of elevation in the code, or are you using theta to represent degrees as degrees? ? From what I understand, unless I am reading incorrectly, if R is the distance from origin to point, theta is the measure of the angle of elevation, and phi is the azimuth angle, such that theta is equal to arcos(z/R). Why do you have the circular degrees in arrays? Does it need to be like that for BGT to calculate correctly, or does it give an advantage that I'm just not seeing? Why wouldn't something like this work as well?

double deg;double rads;double theta;

//convert degrees to radians, adjusting to use the 12-o'clock system due to the way sounds are handled in the programming language.double DTR(double deg){return rads = (90-deg)*pi/180;}To get the value of r:

double theta(pos.z, r){return theta = DTR(arc_cosine(pos.z/r));}Wouldn't that work as well, without putting the degrees into arrays? Or is there something in BGT that makes the arrays necessary? Just curious.

If you're referring to the sin / cos arrays in math.bgt, those were an attempt at optimizing for speed. It turned out, after testing, that this was somehow slower than the built-in functions, I think because CPUs started doing this optimization in hardware. So you can ignore those and use the normal sine / cosine functions.I'm using the coordinate system found in most 3d engines, where +x is right, +y is up, and +z is out from the screen toward the viewer. At least, that's how it's supposed to work. So x=cos (theta) * cos (phi), y=sin (phi), z = sin (theta) * cos (phi). I'm pretty sure something in fpsound_pool gets that wrong, somewhere, though.Theta and phi are radians. I didn't include any handling for degrees.

Also, BGT's vectors allow you to put the example for getting r into a single statement:double r = (v2-v1).length();BGT's vector operations are so convenient and simple to implement that I was surprised when I realized how few times I've seen anything similar elsewhere. Still needs negation and normalization, though. -v won't compile, and without a function for normalizing, you'd have to have divide by 0 checks everywhere.

Now I'm confused. I want to think I've seen that arrangement of phi somewhere, but the sin theta for x has me baffled.For triangles, sin = opposite / hypotenuse, and cos = adjacent / hypotenuse. If you're in the x/y plane, positive angles rotate from the positive x axis toward the positive y axis. In the x/z plane, same thing, but swap y and z.So if theta is azimuth in the x/y plane, and phi is elevation in the z direction, thenx = r * cos(theta) * cos(phi) <— because the x axis is adjacent to r, and when phi = 0, cos(phi) = 1, so even ignoring that the adjacent for phi is the vector projected into x/y, it can't be anything else.y = r * sin(theta) * cos(phi) <— y is opposite theta, so we use sin, but still use cos(phi) because the x/y projection is still the adjacent.z = r * sin(phi) <— elevation doesn't care about theta. It's sin and not cos, because z is the distance from the x/y plane to the point of our vector, and that is opposite phi.If we're using theta for the angle in the x/z plane, and phi for elevation into y, then we swap y and z in the above, but the calculations otherwise stay the same.x = r * cos(theta) * cos(phi)y = r * sin(phi) <— remember that when phi = 0, sin(phi) = 0, which is what we expect for y if there is no elevation.z = r * sin(theta) * cos(phi)

The equations you've given confuse me and remind me of what happened the first time I tried messing with 3d. x kinda makes sense, if we're rotating from y or z toward +x - and I can imagine reasons you might want to do that in game development (see the stereo wonkiness in fpsound_pool). However, y and z seem like they'd give gibberish, aiui. Since there's only phi for z, I'll assume that z is vertical. So, if we're facing forward, at theta=0 and phi=0, then the resulting vector would be(0, 0, r)Because sin(0) is 0, and cos(0) is 1. So you're pointing straight up, or straight z-ward, whichever makes more sense.And if theta is 45degrees == pi/2, and phi is still 0, we get:(r * 0.707..., 0, r)So x, and only x, changes. Also, that breaks the Pythagorean theor'em, since we need sqrt (x^2+y^2+z^2) to equal r, and that 0.707... is sqrt(2)/2, meaning we get sqrt(r^2 + r^2/2) = sqrt (3/2 * r^2) = r * sqrt(3/2), which is greater than r.Trying it for theta = 90degrees == pi/2, we get (r, 0, r), which makes the total length 1.414... * r.Maybe I did all of that wrong. It's been over 12 years since I was in a math class, and that wasn't even trig. And I got all my 3d from the internet.I suppose the thing to do is to test it.

In spherical coordinates, we can describe a vector by specifying the following components:• r which is the distance from the origin to the point• θ which is the angle the radial vector makes with respect to the z-axis (i.e. up / down)• φ which is the azimuthal angle that the radial vector makes with respect to the y-axis (i.e. rotation about the z-axis)We can get spherical coordinates from cartesian coordinates (and vice-versa) using the transformation:x = r * sin θ * cos φy = r * sin θ * sin φz = r * cos φwhere:r = sqrt(x^2 + y^2 + z^2)φ = arctan(y / x)θ = arccos(z / r)So, it looks like he is saying that θ is used for elevation instead of φ. If that's the case, then x being sin(theta)*cos(phi) makes sense.On a related mathematical but different note, One thing I have noticed about BGT is that if I declare a vector like so:vector VF((IV.x+acc.x)*DT*sine(theta)*cosine(phi), (IV.y+acc.y)*DT*sine(theta)*sine(phi), (pos.z+IV*DT)+(0.5*9.81)*power(DT, 2)*cosine(phi));it will declare the vector, but the values within the vector do not assign correctly. in other words, values do not change correctly as they should, as if the math isn't actually completed. In order to get them to assign correctly, I had to do this:

vector UpdateVel(){VF.x = (IV.x+acc.x)*DT*sine(theta)*cosine(phi);VF.y = (IV.y+acc.y)*DT*sine(theta)*sine(phi);VF.z = (pos.z+IV*DT)+(0.5*9.81)*power(DT, 2)*cosine(phi);return VF;}Once I did that, the vector values assigned correctly. So if the only way to get the values to assign correctly is to return the vector in a function, is there a way to have one function retirn all the vectors so that I don't have to make one for each one of them? That would suck, and, quite frankly, seems counterintuitive.

The vectors are assigned only once, with the values that exist at the time. They have to be updated whenever something changes. So long as the function is in the same scope as the vectors you want to change, you can put all the assignments in one function. I normally wouldn't even bother initializing a vector that's going to change in every frame, just letting it default to (0,0,0), and set the values in the function that updates everything else. The exception being if you have an orientation vector, which would need to default to something with length 1, but iirc, you aren't using those.

Re: Spherical coordinates, the explanation they gave just confused me even more, so I wrote a program to test it both ways, with theta and phi swapping roles, for a total of four tests. V1 and V2 are done my way, and V3 and V4 are done their way, with one angle being pi/4, and the other being 0:

Maybe I'm going crazy, but v1 and v2 are the only ones that make sense to me. A length other than ~1 should be invalid, based on the fact that length == r, and we're talking about a unit sphere.Here's the code I used to test it:

The problem that I can't figure out how to get around is that if I am not mistaken, a function to return vectors can only return one value. So in other words, I can't return 5 or 6 vectors, I don't think. So, using the above function to update velocity, once that vector is returned, it would exit the function, I believe, without updating the rest. I've got multiple vectors: displacement, force, acceleration, initial velocity, final velocity, etc. Maybe I'm wrong and I sound like a moron, and maybe that's due to the less than 3 hours of sleep I got last night. But if I'm right, if a function to return the vector can only return the one value, then how do I implement an update function that can update all of them at once? Ideally, this would be done before the ball moves. So, something like:

vector update(){v.x = blah;v.y = blah;v.z = blah;return v;}returns one vector. If I were to put another vector under the initial return, I don't think it would execute. And If I did something like:vector update(){v1.x = blah;v1.y = blah;v1.z = blah;v2.x = blah;v2.y = blah;…return v1;return v2;…}I think it would just exit the function after the initial return value and not execute the second return line of code, if I remember correctly. So not sure how to get around that. Or hell, maybe I'm totally off base at the moment and I'm a fucking idiot. If that's the case, then I apologize.

If the function is a method of the ball class, for example, it can change the variables associated with that ball, without having to return everything. If it's a global function changing global variables, the same applies. This is where the concepts of scope and namespaces become relevant. This can get confusing if you aren't use to it, especially since different languages can handle it differently (see: the chaos of addressing this in Javascript). If you want to be sure about what a variable is associated with, you can try prepending "this." If this.vel doesn't compile, either the function is outside of the class, or vel is. If it does work, you know you're affecting the variables associated with the class.

Yeah, I know that part. But math isn't a class in this case. I didn't think making it a class was necessary, but I always could in the future. I've got a math.bgt file, and all of the vectors and mathematical calculations are stored there, so that I don't have math in 50 different places in my code. Makes bugs related to the math portion easier to track down. What that means is that any vector and variable stored in math are treated as global, I believe.