Mumbles

Thanks! Will try this. And thanks, YouGroove, for originally suggesting it. Oh, I see what YouGroove was saying now. I thought he was saying to use Franck's code, but with three component vectors as the parameters. I feel a bit silly now...

There's no point using a 3 component vector for 2D calculations because the Z will never be used. It's the same reason we don't usually use 4 component vectors for points in 3D space.

Shame, I'd have loved to have played this by the looks of it... Especially if it had multiplayer in it... The lack of shadows -- trust me, it's not important, you don't really notice it

So uh, doesn't actually provide any protection at all?

Thinking about it, it's probably a better idea to have the "big" function using a Vec16 instead. I assume Vec9 and Vec16 still exist? The only difference would be that if there are more than 4 elements you may wish to print an index number rather than a letter. Also, in case of a Vec9, you may want a new line every 3 elements, and for a Vec16, every 4 elements, just to make it more readable.

Copying and pasting similar functions like this can lead to problems, particularly later when they are more complex. You'd do better to roll them all into a single function, particularly if you want to do more complicated things with your vectors later. This is a general programming thing //Header (Kept the same) std::string String(Leadwerks::Vec2 vector); std::string String(Leadwerks::Vec3 vector); std::string String(Leadwerks::Vec4 vector); //CPP (New function added at top. It's not declared in the header, so it's invisible outside this source file) std::string VectorToString(vec4 v, int elementCount) { std::string outputString = ""; char letters[] = {'X','Y','Z','W'}; for(unsigned int element = 0; element < elementCount; element += 1) { outputString += letters[element]; outputString += ": "; outputString += Leadwerks::String(v.a[element]); //I'm hoping the member 'a' was carried over from LE2's vectors, because in for-loops (like this) is where it really shines if(element != (elementCount - 1)) outputString += ", "; //If it's not the last element, put a comma after it. //Single line if statement, code below (if any) executes as part of the for-loop as normal } return outputString; } //Now, this is the only function that manipulates vectors into strings. If you notice a mistake, or want to change the formatting for example, you only rewrite this function, rather than 3 separate functions, Where you might forget one. Or you might typo in one, but not the other two... std::string String(Vec2 v) { vec4 tempVec; tempVec.x = v.x; tempVec.y = v.y; //We don't care about z or w... The VectorToString function will ignore them because we have passed the elementCount parameter as 2. return VectorToString(tempVec,2); } std::string String(Vec3 v) { vec4 tempVec; tempVec.x = v.x; tempVec.y = v.y; tempVec.z = v.z; return VectorToString(tempVec,3); } std::string String(Vec4 v) { return VectorToString(v,4); //We already have a Vec4, no need to create a new one just for purpose } As you see: Don't like the comma between the vector components? Take it out. Want to put brackets around the whole vector? Do that on either side of the for loop. Whatever change you want to make, you just make the change to that one function. You don't have to copy the change to the others as well. Copy and paste errors are one of the most frequent you'll come across. Try not to get into the habit of copy and pasting for small (but slightly different) functions, as projects get bigger, they begin to cause you no end of hell...

Why has he got a deformed uh... sausage, sticking out of his head?

It's sounding quite impressive as it is. I can't wait to see this develop into something big. Glad to see that LE 2 isn't dead...

Your intel HD 4000 is probably the problem. It should work on that (you may need to upgrade your drivers), but there may be a load of rendering bugs. Intel isn't that great when it comes to Open GL, which is what Leadwerks uses. The best intel can offer for graphics is almost as good as a load of doggy doo doo...

Yeah, because C++ doesn't have like 100 million+ free libraries available to reuse... So is C++... Both languages are just methods of writing a very long sequence of events that you want the computer to perform. One uses lots of meaningful symbols to reduce how much you have to write, and the other prefers a more "verbal" style of writing that long list... The symbols are quick to learn, like when you learn numeracy at school, it's very quick to learn what the + sign means. Before long you know that 123+456 means 579. The symbols in C++ are the same, once you've seen them a few times, you know what they mean and how they work...

I use winsock2. I'm happy with the performance but the lack of OO may turn some people away from using it. One thing I'm confident about is that it's built in to the Windows OS, so it's nothing third party and should work flawlessly. Wine handles it perfectly too, but if I wanted to port to native Linux, I'd have to adapt it to Berkeley Sockets and whilst Winsock is designed to mimic Berkeley's commands, some of winsock's commands work differently to Berkeley's and some are totally new. That would take a bit of learning to work out which functions work the same (like accept) and which work differently (like select)

This should have no impact. In my setup I have 1000 physics updates per second, with 25, 40 or 50 "major updates" spaced evenly... It was just as smooth as when I was using 25, 40 or 50 steps per second, but it now produces the same results whatever the update rate is. My advice to anyone having trouble using the integrated physics engine is, provided you're using the C++ interface, ignore it and use any physics library of your choice. Seriously, the fact I could do it speaks volumes of how easy it is...

You shouldn't need swept collision on the walls because they don't move, thus they can't move too fast fast for accurate collision. You should only enable swept collision on bodies that can reach high velocities (If it can move further than its own length in a single step). Swept collision should be enabled on as few bodies as possible because it really slows things down. Same goes for "autosleep" but I don't believe that functionality has been exposed to us... Edit: Actually no, that's badly written. Enabling swept collision on too many bodies severely degrades performance. Disabling autosleep (if it's available) on too many bodies also severely degrades performance.

Rick, are you using swept collision for your character controller? When the frame rate is smooth everything is fine but when it drops below 20 you tend to zoom around so fast you can pass right through the doors and walls etc. At about 30 FPS, I can slide half into the doors but then it slides backwards again. Also I'm curious as to your timer based movement handling. At about 30 FPS you seem to move at twice the speed you do at 60...

No, this makes a body totally immovable. You can't move it and no matter how small it is, if you place it on a train track -- worry about the train... It could be less than 1 mm wide, but if it's got no mass, nothing will move it... Turn off gravity and apply the "adjusted" (negligible) gravity yourself every frame. It's what you'd have to do if you were using raw, unwrapped Newton.