Mumbles

At the time of the old forum, there were a few problems with piracy. Kids who'd just downloaded to latest freebie to make its way to the torrent sites, without having the faintest clue of engine's capabilities or requirements (in terms of both hardware, effort). When you ask more sensible questions like yours, most members are more than prepared to help if they are able to, without you needing to get your wallet out, Since moving to this new forum about 1 and a half years ago the piracy pretty much died outright Well yes, donations are a great way of showing gratitude, but personally I wouldn't offer them upfront (maybe that's just me). To be offered a donation afterwards without any indication in advance really makes you feel like you've gone the extra mile to help someone. But to have been offered it upfront: let's just assume it's me your offering to pay for a tutorial. I go away and write one that actually doesn't really help you at all. Now what do you do? Do you pay me anyway to avoid upsetting me over the hard work I've put in and think to yourself "I'm not asking her again", or do you honestly admit that it didn't help, and thus not pay? So I'm not saying don't reward people who have helped you, but just be aware of some possible implications of it. And since we're like a big family here, help is normally offered for free, but no one's actually going to say "you must not pay me"... It's like paying your sister to iron your suit for you - you can, but she's probably willing to do it for free.

I've never heard of anyone demanding money for tutorials - it's just not something most communities do...

The leadwerks developer wiki (link) has some tutorial that cover both points 3 and 4 But as for 1 and 2. I've never heard of anything related to python in Leadwerks. The closest match you will find to python is lua. And my personal opinion is that the engine is best used with either C/C++ or BlitzMax. Other people will prefer other languages, but support for other languages is limited. The tutorial I linked to show you how to use the engine in both of those languages. I wouldn't really think python was suitable for making games with, but maybe I just love C too much...

I wonder if I'll be the only one to vote for Newton. I much preferred it when it was closed source though

NewtonBody shell casings sound like overkill 9000. You're in the cockpit, how long are you going to see the casing for? Also is it imperative that people on the floor can see the casing fall and bounce accurately? Just an image may be a better idea, and for raycasts: 1 raycast per 96 ms is by no means fast all... Even 1 per 20 should have a negligible effect on the performance. I know because I was once creating an auto-waypoint generator because I didn't fancy placing them myself over large areas. First stage was to distribute the map into "cells" (each 1x1x1 in size). Then was to analyse each cell, by firing a number of rays straight down inside the 1x1 cell. The number of rays was user definable, anywhere between 2x2 to 100x100, 10x10 being the default as it was good enough for high precision. To do an area of 200x50x200 cells at 10x10 scan resolution took no more than about a minute. This was a DBP project though, and it used Newton 1.53 I can't see Newton 2 in Leadwerks giving wildly different sort of times. But I've yet to port it over to Loadwerks because I've not yet needed it.

Might be a bit late by now, but I always found inno3d cards to draw a load of coloured (opaque) triangles and lots of small dots all over 3D geometry. I'll admit that happened in DirectX 7 thru 9, never tried it with anything OpenGL and they may have got their act together by now, so that may not apply, but just a warning... This was with a Geforce 4 (don't remember which), 6200 and 7600

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...