What do you need help with? Version 5

[Armandur]

I know this is not a strictly programming question but if I have this scenario

[IMG]https://dl.dropbox.com/u/5342745/problem.png[/IMG]

Can I based on this calculate the length from A to C?

[Overv]

You guys aren't even trying now.

[img]http://i.imgur.com/ufGsO.png[/img]

[QUOTE=polkm;37335292]I am a bit confused about how to use the function "glVertexAttribPointer". The "pointer" object is a const void* and yet everyone uses it as an offset. I also saw an example were someone passed vertex data through the "pointer" argument. I just want to know if you are supposed to pass an array of vertex data or cast an int into a void* and use it as an offset, or can you do both? Can you pass an array of vertex data even if there is already a buffer bound?[/QUOTE]

It's a void* pointer type for both for legacy and practical reasons. Legacy because it, as you say, used to be possible to pass a clientside array directly to this function and for practical reasons because a pointer is the correct size type on all platforms.

[Armandur]

[QUOTE=Overv;37339297]You guys aren't even trying now.

[img]http://i.imgur.com/ufGsO.png[/img]

It's a void* pointer type for both for legacy and practical reasons. Legacy because it, as you say, used to be possible to pass a clientside array directly to this function and for practical reasons because a pointer is the correct size type on all platforms.[/QUOTE]

I'm sorry Overv but I've never studied trigonometry (at all).

[MakeR]

You should, It is a big part of game programming.

[Armandur]

[QUOTE=MakeR;37339551]You should, It is a big part of game programming.[/QUOTE]

I know. Just up till now it hasn't been part of the curriculum, but it will be now when I begin at the University in a few weeks.

[esalaka]

[QUOTE=ThePuska;37337600]1. project the velocity vector onto the surface normal
2. subtract this projection from the velocity twice

[img]http://latex.codecogs.com/gif.latex?V%20=v%20-%202%20\frac%20{n%20\cdot%20v}{||n||^2}n[/img]
(V is final velocity, v is initial velocity, n is surface normal)

In C code:

[cpp]/* Input:
* surface0, surface1 surface start and end points
* velocity initial velocity
* Output:
* out_velocity mirrored velocity */

/* Surface normal: flip the axes and change one coordinate's sign. */
float nx = surface1.y - surface0.y;
float ny = -surface1.x + surface0.x;

float m = 2 * ((nx * velocity.x) + (ny * velocity.y)) / (nx * nx + ny * ny);

out_velocity.x = velocity.x - m * n.x;
out_velocity.y = velocity.y - m * n.y;[/cpp][/QUOTE]

I swear you're like the official Programming section mathemagician

[Tracker]

Hey.
I just updated GWEN from revision 151 (the download zip) to 307 soon after realising just how old the download is.
After some quick fixes with linking and such, I've come across a few problems I can't quite explain.
For one, whenever I delete Gwen::Skin::TexturedBase, I get a corrupt heap and my program crashes.

Also, whenever I disable resizing on a WindowControl, the title text moves onto to the surface of the window. Not to mention the fact, that the close button does not even show up, yet when I click where it's supposed to be, the window closes.
[IMG]http://u.filepak.com/UTmp_gwen.jpg[/IMG]

Am I doing something rather silly, or just using an unstable build?

There's a few other problems aswell, but I think it might be linked somehow.

Edit:
I got the close button to show up, seems I was using an old version of the png for it. All the other problems I've list still occur, also the close button is much below the title bar aswell.

[Staneh]

Okay, let's say I have a number with decimals from 0 to 1, that changes all the time, how can I make that turn into a number which is in the range of 1 to 255?

[Overv]

[QUOTE=Staneh;37341006]Okay, let's say I have a number with decimals from 0 to 1, that changes all the time, how can I make that turn into a number which is in the range of 1 to 255?[/QUOTE]

[img]http://sae.tweek.us/static/images/emoticons/emot-colbert.gif[/img]

[MakeR]

Multiply by 254 and add 1?

[esalaka]

Is it [0, 1] or [0, 1[ ?

For the former, 1 + n * 255

For the latter, I can't remember how you could make it include 255.

[editline]21st August 2012[/editline]

Seriously this is the most basic scaling thing you're scaling from 0-1 to something else

[editline]21st August 2012[/editline]

I actually had the general formula for scaling a function from [a, b] to [c, d] written on a paper towel because I keep forgetting it but it seems I've destroyed the paper towel

[polkm]

[QUOTE=Overv;37339297]
It's a void* pointer type for both for legacy and practical reasons. Legacy because it, as you say, used to be possible to pass a clientside array directly to this function and for practical reasons because a pointer is the correct size type on all platforms.[/QUOTE]

Is it still possible, or recommended to pass the clientside array directly?

[1cebabe]

[QUOTE=Armandur;37339400]I'm sorry Overv but I've never studied trigonometry (at all).[/QUOTE]

[url=http://www.khanacademy.org/]khanacademy. Bookmark it[/url]

[MakeR]

[QUOTE=esalaka;37341079]Is it [0, 1] or [0, 1[ ?

For the former, 1 + n * 255

For the latter, I can't remember how you could make it include 255.

[editline]21st August 2012[/editline]

Seriously this is the most basic scaling thing you're scaling from 0-1 to something else

[editline]21st August 2012[/editline]

I actually had the general formula for scaling a function from [a, b] to [c, d] written on a paper towel because I keep forgetting it but it seems I've destroyed the paper towel[/QUOTE]

Scaling from [a, b] to [c, d]:

f = c + (d-c)*(f-a)/(b-a)

[ECrownofFire]

Because lots of people have been posting trig questions, here's a super fast trig thing:

No images because I'm lazy, but imagine a right triangle with vertices (and therefore angles) A, B, and C. Its sides we'll call a, b, and c (lowercase). A the angle corresponds to "a" the side, etc. It's important that this is a RIGHT triangle (one angle of 90 degrees). It does not matter which one it is.

Now, the side directly across from the right angle is called the "hypotenuse" of a right triangle. This is important.

You've probably heard of sin (or sine), cos (cosine), and tan (tangent) before. They have to do with circles, but that's not relevant at the moment. All you need to remember is this mnemonic: [B]SOH CAH TOA[/B]. If you're wondering what the fuck that is, S is Sine, C is Cosine, T is Tangent. O is Opposite, H is hypotenuse, and A is Adjacent.

Adjacent and opposite to WHAT though? That would be the angle you're calculating sine/cosine/tangent for. Adjacent refers to the side that's next to the angle that is not the hypotenuse (undefined for a right angle). Opposite refers to the side opposite the angle (A to a, B to b, C to c, and the same side as the hypotenuse for a right angle, which is useless). [b](TL;DR people read this)[/b]

Now back to SOH CAH TOA. [B]Sine is the ratio of the Opposite side to the Hypotenuse[/B] (that is, the length of O over the length of H is the sine of the angle). [B]Cosine is the ratio of the Adjacent side to the Hypotenuse[/B].[B] Tangent is the ratio of the Opposite side to the Adjacent side[/B] (ALSO calculated by sine/cosine).

I googled this image just for you [url]http://upload.wikimedia.org/wikipedia/commons/4/4f/TrigonometryTriangle.svg[/url]. (Note, the sides labeled adjacent and opposite are relative to the angle A)

So, C is the right angle there (remember this only works for right triangles). sin(A) is the opposite side (a) over the hypotenuse, or c. So sin(A)=a/c. Cosine is the adjacent (b) over the hypotenuse (c), so cos(A)=b/c. Tangent is the opposite (a) over the adjacent (b), so tan(A)=a/b. Moving to B, we get sin(C)=b/c, cos(C)=a/c, and tan(C)=b/a.

Note: the sine, cosine, and tangent for 90 degree angles are 1, 0, and undefined (1/0), respectively. These are useless in nearly all cases, but you should watch out if you're ever dividing by a cosine that you do not use any multiple of 90 degrees. Also note that the sine, cosine, and tangent of 180 degrees are 0, 1, and 0 respectively, so watch out for using sines and tangents.

Also note that sine and cosine are repeating functions (over a period of 360 degrees, or 2pi radians). The negative sine of 35 degrees is equal to the sine of 125 degrees (or 35 degrees plus 90). The sine of 35 is equal to the sine of 215 degrees (or 35 plus 180).

Sine, cosine, and tangent are always the same for any one angle you give it, by the way. Sin(X)=sin(X) no matter where it is and what shape it's in as long as it's an actual angle.

Also, might as well do a quick thing on radians. Taking 360 degrees as the angle of a full circle, and the way to calculate the circumference (or distance around a circle) is 2*pi*r (where r is the radius), we get that 2pi is the distance around a unit circle (a circle with radius 1). [B]2pi radians is equal to 360 degrees for any circle[/B]. So to get radians from degrees, you divide by 180 and multiply by pi. 90 degrees is pi/2 (or 1/2 pi). 180 degrees is pi. To go the other way, multiply by 180 and divide by pi. Pi radians is 180 degrees, etc.

Might as well mention arcsin, arccos, and arctan down here too. Each of these is the INVERSE of each of the trigonometric functions. So arcsin of the sin of an angle is that angle (if that angle is between 0 and 360 degrees). Note that the inverse trig functions always give you an answer between 0 and 360 degrees (or 0 and 2pi radians). Passing a number larger than 1 or smaller than -1 to arcsin or arccos is undefined (but not for arctan). To summarize, the arcsin of a number X is the angle A whose sine is X. In shorter terms, [B]arcsin(X)=A when sin(A)=X[/B]. You may also see these functions with a superscipt -1 to the right of a sin. arcsin(X) = sin[SUP]-1[/SUP](X) (this gets kind of confusing later with things like sin[SUP]2[/SUP](X), which is actually (sin(X))[SUP]2[/SUP]), but it's used often, including on many calculators.

Edit: bolding important shit, for a TL;DR, read everything in bold. Also, inverse trig functions.

[ArgvCompany]

[QUOTE=ECrownofFire;37341941][B]2pi radians is equal to 360 degrees for a circle with radius 1[/B][/QUOTE]

They're always equal for any circle.

[ECrownofFire]

[QUOTE=ArgvCompany;37341990]They're always equal for any circle.[/QUOTE]

Oh dammit, I got myself confused for a second.

[editline]21st August 2012[/editline]

Fixed the post.

[OnDemand]

[QUOTE=ThePuska;37337600]1. project the velocity vector onto the surface normal
2. subtract this projection from the velocity twice

[img]http://latex.codecogs.com/gif.latex?V%20=v%20-%202%20\frac%20{n%20\cdot%20v}{||n||^2}n[/img]
(V is final velocity, v is initial velocity, n is surface normal)

In C code:

[cpp]/* Input:
* surface0, surface1 surface start and end points
* velocity initial velocity
* Output:
* out_velocity mirrored velocity */

/* Surface normal: flip the axes and change one coordinate's sign. */
float nx = surface1.y - surface0.y;
float ny = -surface1.x + surface0.x;

float m = 2 * ((nx * velocity.x) + (ny * velocity.y)) / (nx * nx + ny * ny);

out_velocity.x = velocity.x - m * n.x;
out_velocity.y = velocity.y - m * n.y;[/cpp][/QUOTE]

Can anyone explain why this works after subtracting the projection twice? Wouldn't that displace it too far at least in the y component of the velocity vector?
(I'm not good at linear algebra so have mercy!)

[MakeR]

I will try to explain.

V0 is the intital velocity vector.
V1 is the mirrored velocity vector.
n is the surface normal.
P is the V0 projected onto n.

[img_thumb]http://i.imgur.com/t6VuB.png[/img_thumb]

The velocity vectors have their origin at 0 by definition, therefore subtracting the the projection twice doesn't translate the vector but changes it's direction by 2P.
(Sorry for the bad drawing).

[OnDemand]

[QUOTE=MakeR;37342432]I will try to explain.

V0 is the intital velocity vector.
V1 is the mirrored velocity vector.
n is the surface normal.
P is the V0 projected onto n.

[img_thumb]http://i.imgur.com/t6VuB.png[/img_thumb]

The velocity vectors have their origin at 0 by definition, therefore subtracting the the projection twice doesn't translate the vector but changes it's direction by 2P.
(Sorry for the bad drawing).[/QUOTE]

I see, so to achieve the final displacement after the 2P change in direction he flips the axes and changes a coordinate sign and that finally creates the mirror effect, is that correct?

[ThePuska]

No. The X/Y and sign flip are a quick method of calculating a normal to a vector. I calculate a normal to the surface, project the velocity onto the normal and subtract the projection.

[sim642]

This thread has really turned into math discussion now.

[OnDemand]

[QUOTE=ThePuska;37343280]No. The X/Y and sign flip are a quick method of calculating a normal to a vector. I calculate a normal to the surface, project the velocity onto the normal and subtract the projection.[/QUOTE]

It makes more sense now, I somehow forgot to subtract the initial velocity vector. But there's one last thing that isn't clear about that formula. If we look at MakeR's drawing we can see that the double projection is made first and from that vector we subtract the initial velocity vector and not the other way around. So it's the same as your formula but with the signs flipped.

However, if we look at the drawing made by Overv we can see that the graph is flipped when compared to MakeR's. So I guess one has to be careful about the signs used in the formula for each specific scenario or is this sign flipping related to the way you calculated the normal vector and I'm getting the wrong idea?

[esalaka]

In overv's graph the initial vector is on the left. That's why it's flipped. No other reason.

[editline]21st August 2012[/editline]

And since subtraction is addition of negative values and vector addition has the same commutativity property as scalar addition, the order of the operations does not actually matter.

[editline]21st August 2012[/editline]

The important thing is that all the vectors are added in [B]some[/B] order.

[nos217]

void nchar(int n, char c, char** result) {
    result = malloc(sizeof(char) * n);

    int i;
    for (i = 0; i < n; i++)
        *result[i] = c;
}

char* frame(char* string) {
    int size = strlen(string);

    // create the top line
    char* top = malloc(size + 2);
    strcpy(top, "+");
    char* dashes;
    nchar(size, '-', &dashes);
    strcat(top, dashes);
    strcat(top, "+\n");

    // create the message line
    char* message = malloc(size + 2);
    strcpy(message, "|");
    strcat(message, string);
    strcat(message, "|\n");

    // bottom and top line are equal
    char* bottom = top;

    // put it all together
    char* result = malloc(strlen(top) * 2 + strlen(message) + 2);
    strcpy(result, top);
    strcat(result, message);
    strcat(result, bottom);

    return result;
}

Just getting into C, why is this code segfaulting? I've looked through it and don't see a problem.

[ThePuska]

[QUOTE=nos217;37345599]

void nchar(int n, char c, char** result) {
    result = malloc(sizeof(char) * n);

    int i;
    for (i = 0; i < n; i++)
        *result[i] = c;
}

char* frame(char* string) {
    int size = strlen(string);

    // create the top line
    char* top = malloc(size + 2);
    strcpy(top, "+");
    char* dashes;
    nchar(size, '-', &dashes);
    strcat(top, dashes);
    strcat(top, "+\n");

    // create the message line
    char* message = malloc(size + 2);
    strcpy(message, "|");
    strcat(message, string);
    strcat(message, "|\n");

    // bottom and top line are equal
    char* bottom = top;

    // put it all together
    char* result = malloc(strlen(top) * 2 + strlen(message) + 2);
    strcpy(result, top);
    strcat(result, message);
    strcat(result, bottom);

    return result;
}

Just getting into C, why is this code segfaulting? I've looked through it and don't see a problem.[/QUOTE]

[cpp]void nchar(int n, char c, char** result) {
*result = malloc(sizeof(char) * n); /* this */

int i;
for (i = 0; i < n; i++)
*result[i] = c;
}[/cpp]

[editline]21st August 2012[/editline]

In your version, you pass a pointer to a variable in the [i]result[/i] argument. But inside [i]nchar[/i], you use the [i]result[/i] as a local variable - you overwrite its previous value by mallocing, when you intend to pass the malloc'd pointer to wherever [i]result[/i] was pointing.

[nos217]

Ah of course. These pointers will be the death of me. Thanks a lot.

Also:

[cpp]void nchar(int n, char c, char** result) {
*result = malloc(sizeof(char) * n);

int i;
for (i = 0; i < n; i++)
(*result)[i] = c; /* This needed changing */
}[/cpp]

[Staneh]

-snip-

Fixed.

[Lord Ned]

When reverse engineering a file format, how do you determine the exact composition of members, and what their purposes are?

I've figured out the header format of this file (LoZ: Wind Waker map collisions) and that gives me several offsets, enough to dump the collision to *.obj. However I want to be able to actually create collisions instead of just dumping existing ones, so i need to flesh out the rest of the format.

What are some techniques as to discovering what fields are? I figured out a flags field earlier simply because it's value was either 0, or 256 and it was 256 on something named water, so 256 (1 << 8) was probably the flag for water, and there's probably one for ice too, 0 for default, something for lava, etc.

The other fields I'm not having much luck with. I inspected a lot of different collision files and compare their values and can't find an actual pattern in them. When I say (most common) I mean 90-95 of the time they are that value.
[cpp]
struct Type_t
{
//Offset from start of file. This contains Romanji names for objects, things like
//"floor" "wall" "water" "surfacePoly" etc. My guess is these were the original
//names in Nintendo's editor and can be reused to re-create them in the OBJ.
U32 nameOffset;

//This value is 1,1,1 for every Type_t on some maps, or ~94% of them on others
//When the map does have some non-1,1,1 the values normally range between 0.5 and 2
Vector3 Unknown1;

U32 Unknown2; //Value such as 0 (common), 16384 55550 4282438625 2145253536 5102 3269
U32 Unknown3; //65535 (most common), 1073807359

//This value is 0,0,0 for every Type_t on some maps, or ~98% of them on others
//When the map does have some non-0,0,0 the values range between -5000 and 5000
Vector3 Unknown4;

U32 Unknown5; //Can be something small like 2-5 or 6551-6557, or 131082-131085
U32 Unknown6; //Either 429467295 458751 524287 589853 655359 983039
U32 Unknown7; //Values like: 65535 0 655361 1048578 46661950 etc.

//Possibly flags field? Water = 256, 'Default' is 0
U32 surfaceType;

//Unknown1/Unknown2 are curious. They don't seem to correspond to anything. If they're positions
//in the world, they aren't near where their associated triangles are. If they're some sort of
//physics property override, they don't make much sense. It's my belief that it'd be best to just
//write them in as 1,1,1 and 0,0,0 since some maps have these values so the engine can obviously
//load them like that. In theory at least.
};
[/cpp]

[robmaister12]

Sometimes values are bitfields/flags. Look at which bits are set and see if there's anything common. Also if there's anything that's completely random, it's probably a checksum of some kind. At least that's what I've seen through the formats I've reversed.

If it's always a high value or low value, it might be two shorts put together, see if that yields any values that make sense.

Worst case scenario, you could try disassembling the game and seeing what it does with those values...

[editline]21st August 2012[/editline]

and the unknown vector might be a scale vector...