Mumbles

I gave you a response before the rollback, but since I wasn't sure if you were going to recreate the thread and if you'd even seen the response, I sent an email to your publicly listed address...

I'm on 2.24 but haven't tested that in a while. But as I understood it. ContinuousCollision off: Fast moving bodies may pass through each other if one body can move inside another with just one update call (if the body is half in, half out then the collision is detected and the bodies react accordingly). ContinuousCollision on: Fast moving bodies may no longer "sit inside" another body. If one body is sitting inside another body then it will be interpolated back to the point at which it first collided (with the velocity interpolated as well to allow the correct reaction to take place) But if one body has passed through another AND exited on the other side (because both bodies were so small), then it is back in a valid position. Yes, for realism it should be sent back to the point it collided and reacted there. But what if it's two bullets colliding with each other (no one said one of the bodies have to be static) mid way through an update call but have fully cleared each other's overlap zones by the end of the update call. That would be so expensive to detect and to calculate the resulting reactions. My point was based on that point that Julio though it was a waste of resources and allowed to happen regardless - I might be wrong on that one though. I also thought Julio recommended using raycasts for bullets because they were always guaranteed to detect the hit. and if it does hit a player then you could try and calculate the impulse to add to the body (Because you know the "velocity" of the ray)

I still don't understand the whole fad with reliable, ordered UDP. If you're prepared to sacrifice speed for packet sequencing and guaranteed delivery, then why not just go the whole hog and go for TCP? I mean, TCP also tells you when the remote peer sods off. Also, does this UDP solution tell you if one of the bytes in the message has been stuffed up? For example, the sends a message mean\sing "apply a force to the third entity. the force is {0,0,10}" and the packets goes through an old copper wire and gets affected by some interference, so the client reads it as "apply a force to the third entity. the force is {0,0,14}" All these UDP libraries seem to mention reliability and ordering, but they don't seem to make such a big fuss about error detection.

How thick is the floor? If the bullet is really small, AND the floor is really thin they may pass through each other, even if ContinuousCollision is enabled.

Does the in-built networking have a client limit of 64? I can't think where I've got that idea from, but in any case, using a third-party network library with leadwerks should be pretty easy to do.

Newton multithreading enabled? Also, with 2000 boxes, newton dips to about 1 fps for 10 seconds, which yes, would be unplayable in a game, but once most of the boxes separate the frame rate increases to about 20. Once they're all sleeping due to not moving. the frame rate is as high as 95. Bullet on the other hand, only goes down to about 10 fps for 2-3 seconds. Much better better for a gamer. Once most of the boxes have separated the frame rate increases to 25. But even when the boxes have fully stopped, the frame rate is still at 25. And really, how likely are we to have 2000 active physics bodies all colliding with each other in such a small area? That's one of the biggest speed killers for newton I'm also guessing that the newton built into LE uses just one thread? I wonder how much faster it would be if more than one thread was enabled. Tomorrow, I might have a go at rewriting your code to work with a standalone newton to test that idea (If its OK that is).

The Sandbox is only available to people who have paid for an LE license...

Would you believe, an idea as simple as that never even occured to me... (Actually, I'm sure you would)

I'm not so sure about interchangeable physics engines. Because whilst the graphics rendering all appears the same (in a black box view), physics engines deep down can be very different. Not all support buoyancy, not all support cloth effects, etc. Most physics engines are designed to be hooked up to a graphics rendering system. The example from newton that I know is that for every rigid body that was moved, a user defined callback is called. Newton gives you the body that was moved and the 4x4 matrix to represent its position, rotation and scale. Newton bodies also store a single pointer for your own use. Usually that's the graphical object which visually represents that body. So for the Leadwerks, when the callback is called: Read the pointer stored with the rigid body. (When you created rigid body, you should have saved the pointer to the TModel which represents the body): Transpose the matrix (Because newton gives the matrix in "row-major" by default, probably because there are more DirectX games out there) Call SetEntityMatrix on the model pointed to by the pointer, with the transposed matrix. Voila! Newton and Bullet probably have very different structs and classes deep down and trying to incorporate them both into the engine would be wasteful. All physics engines are designed to easily interface with any graphics renderer, because without the graphics, you simply have no idea if the physics calculations are working accurately or not. Bullet probably relies on a very similar way of getting it's positional information to a graphics renderer. If it is that simple to interface with, I would say that physics should not be integrated into LE 3 at all. Imagine the prospective companies interested in LE 3. They might have decided on a physics engine already (Or even written their own). To suddenly be told, "you've got to use one of these physics libraries - In the way that I've wrapped them up", might just turn them away.

Microsoft keyboard (and mouse) on the last picture (native mac keyboard in the background). You should upload the picture to mac websites... They'd like it... Does the keyboard say "Keyboard" on the under side? We had Mac Pros at uni those ones did. They also had the word "Mouse" on the under side of the mouse. Did they really think no one would recognise what they were?

My way around that was to implement a third party winsock library. I'm using it in a multi-threaded fashion, but when you call it to check for messages on a socket, if there's no data waiting, it returns immediately with a value of 0, and if there is data waiting, it returns a value 1, in which case then instruct the library to get the packet that's waiting. Whilst that would work fine single-threaded, if you have lots of sockets then then you have to wait longer whilst you check them all for newly arrived packets. I don't know, but being entity related, I can guess that you may get setMemBit errors occuring if you use a second thread dedicated for networking. If the first thread is trying to access an entity at the exact same time.

I find garbage collectors to be a bit overrated anyway. It's like saying: Don't clean your house, anything you've forgotten about will instantly disappear so that the space it occupied is now free for you to fill with something else. Proper use of destructors, as in freeing (or deleting) any allocated memory renders the whole garbage collectors useless. The only time they are acceptable is when memory allocation is hidden from you to try and not complicate the language. If you can allocate "new" objects then really it should be up to you to clean them up. Sadly in this case, the garbage collector is built into the DLL during compilation so you can't remove/disable it.

Just thinking, do you know which compiler Xcode uses? I remember my first attempts at building C programs in linux with gcc. It didn't have a clue where to find <iostream> but the newer g++ knew straight away where to find it without me having to alter the include path. I later found out that you're not supposed to use iostream because the standard version is stdio.h. Perhaps some of your "missing" inclues are suffering a similar problem.

The last two might be due to the slashes being the wrong way round. (Windows used to use the backslash, but now accepts either. Unix systems only ever accept the forward slash for directories.) As for the first two, what's "io.h"? is that not "stdio.h"? "direct.h" I've never heard of before

Basically, you add the lib to your library dependancies, and then at build time, all the functions and variables in the lib are built into your exe. But like a standard cpp source file, if those functions have not been declared, then nothing can use them. Whilst users could declare the functions for themselves, it's not ideal. Including a header file with the lib is the best way because otherwise anyone who uses the lib has to declare the functions themselves, which first means that they must know the name of each function, its parameter list and return type. Without access to the source code, most people are not going to know this information.

It might be, but when you have a large number of physics bodies surely having multiple threads will speed up the calculations (But no more threads than you have physical processors). Even when there are only a few physics bodies, using two threads still gets to a nice 60 fps, with enough time to sleep as well. I don't know how Newton handles its threads. All I know is, I type: NewtonSetThreadsCount(NewtonWorld,2); And Newton will use 2 threads each time I update that world. It might create the threads each time I update that world, and destroy them when finished updating. Or it might create the threads up front, and just leave them sleeping when I'm not updating that world. But that's beside the point, most entity commands for Leadwerks do not work in a multithreaded way. You can't even load a sound at the same time you are loading a model. All loading has to be done single threaded.

No, not Newton, it's a multithreading issue. It's just when I used a standalone newton, the NewtonUpdate() function spawns x threads to do the updating (I had it set to use two threads). Each of the threads calls the same callbacks, at the same time, I had one of the callbacks calling SetEntityMatrix. When I took SetEntityMatrix out of the callback the problem went away because it was no longer being called by two threads at the same time. I could have just told newton to use one thread, but I wanted the physics calculation to be as fast as possible. All my Model loading was done single-threaded. So far, the only multi-threaded part of my project is when NewtonUpdate() is called. and the multi-threading ends when that call ends.

I ran into that one whilst using a stand alone version of newton set to use two threads. Except that for me, the error was when Newton's callback to set an object's position and rotation, tried to call SetEntityMatrix. My solution was to allow newton to run in two threads to speed up the physics calculation time. But the callback was not allowed to call SetEntityMatrix. Instead I gave each entity a private member for the new matrix and flag to say whether newton had to reposition the entity. Once newton has finished updating, the program is back in a single threaded state, so I can then call SetEntityMatrix one-by-one for each entity that had its move flag set to true. I don't think there is a way to get round loading objects in a second thread though

Really? If you call a Sleep(2) then the counter increments by 3. Basically, how ever long you sleep for, the counter increment is going to be 1 + the sleep duration. It looks like if you're going to be processor-friendly then you'll have to stick with 2ms accuracy, but really, 2 isn't bad...

Keeping it on his own hard drive is what I meant when I said: As for who said that to you, I would guess that it was probably id. It would go hand in hand with their stance on open source software.

I tried your C++ code with a Sleep(1) just after the printing. The result is increments of two milliseconds. still not the 16 everything else gets. So, when I thought: Sure enough, it really was only sleeping for 1 ms. Just a shame you have to jump through so many hoops to count 1 ms yourself. Still, I guess we should all be thanking Josh. If he hadn't asked this question, would this discovery have been posted? And of course obviously to Lumooja as well, for actually finding this out...

Models on FPS Banana each have their own license determining how you may use them. Most models are free to use in CSS (because most of the "skins" are built for CSS), but require permission to use in any other game or engine. This is so larger companies can't simply use models in their own blockbuster games without paying for them. As an indie developer you should find that most people on FPSB will let you use their models for free, but it's still better to make sure first. If you email them, they may even send you the models in an easier format to convert like .max As for creating GMF models, the best option is to buy something called "Unwrap 3D Pro". At $60 it sounds expensive but it imports (and exports) so many different formats, it's basically the only application you need to convert models from one format to another. It also exports Leadwerks GMF models with their animation intact.

MilkShape has an SMD importer, and someone has written a GMF exporter for milkshape (but with no animations). But I'll give you the same warning. Using commercial assets in your game is illegal unless you have permission to do so from the company who owns the assets. There is a commonly held belief that if your game is "free" or "not for profit" that this does not apply. This is not true. It's illegal to use copyrighted media whatever the circumstances. That said, if you use these assets for personal testing only (ie, no one else has access), Valve are not likely to pursue legal action against you. But if you ever release your game with these assets (free or not) you could find yourself in a lot of trouble.

timeGetTime() ... which is exactly what Josh was trying to use in the first place.

There must be a way, surely. If I put a Sleep(1) in my code, surely windows is not using a hi-res timer for that?