Mumbles

For bodies to collide they need to be inside the world (link) This is normally the cause. Also bodies outside the world will not react to forces either.

For a simple box shape, I just export a box as an obj from my modeller. That way I never make any collision shapes in code.

I see no reason for not using convexs everywhere. If need be, make your .obj a plain box the size you want it. Using raw newton, it's much easier to write a helper function to create: Convex hulls, compound collision, and tree collision and then never bother with the primitives. The primitives are more trouble than they are worth, since you can create them out of convex hulls anyway.

Lumooja already started one, and of all people, I was having a go at the AI. My 2.0 didn't mix well with the 2.3 everyone else was using (different GameLib versions). Really, it's not a task I should have taken up in the first place. I'm more likely to get it working for myself, and then teach everyone based on my own system that works. Building it with the idea of integrating it to other people's programs wasn't the way to do it. Really I needed to get something working at all before adding in the flexibility of making it work. I haven't given up on this at all, and I still do fully intend sharing the theories and algorithms once I believe it to be in a finished state. But it's by no means a quick thing especially nNot with my recent attempts at learning how to integrate newton separately (which I believe is now more or less done). But I did state on my only blog entry so far, that I would be going for network support before going for pathfinding and intelligent behaviour of computer controlled players. Because I believe networking (as difficult as it is) is quicker to get up and running than any type of computer intelligence.

For the concept of learning how to do it, then yes, by all means try it. But Java is going to be inherently slow for any serious games due to the nature of the virtual machine

Oh, I know that, I just don't think it would be as much of a waste of time as people may be inclined to think. Obviously, I've never actually written a program for a mac, but I'd be very surprised if it involved a large scale re-write between Linux and Mac... First year at uni my lecturer made a mass announcement that (regarding linux and mac) "cosmetic differences aside, the platforms are the same". This came about because we were using macs - that went down just before a programming (Java) assignment was due in, and most people in the group had hinted that they were going to submit a "mitigating circumstances" form on the ground that the computers they thought they needed were unavailable. Now in the case of Java there is no concern, the Java Virtual Machine interprets the code at run time, but I can't see C being massively different either.

This was originally an edit, but took so long, may as well be a message in its own right: Not everyone wants to install wine, and just because LE 2 works fine, that's no guarantee that LE 3 will. There's a large number of existing games out there that wine cannot load because they are built by crappy programmers that utilise things that need admin rights. Unlike windows where you were expected to leave your system vulnerable until the creation of (the annoying) UAC, that's not the philosophy for Linux. You run as a lowly user, so that rogue programs can't start deleting your data. Unfortunately, SafeDisc (and similar) requires admin rights because it installs a device driver. wine won't agree to raise its privileges so it can't install, net effect: games protected by SafeDisc don't work. I don't think anyone here is going to integrating SafeDisc with their games, but the same goes for anything which requires admin rights. Whereas of course, a native linux executable will ask for the root password if it needs it, at which point the user can decide if they trust the program's author, and provide the password, or not as the case may be. Of course, this just my reasoning as to why I'm surprised Josh went for macs first. At the end of the day, nothing I've said there is going to change his mind about the development path. And if Linux is supported natively in the future, wouldn't mind ..that.. much if it played second fiddle to the mac.

Debian, which I use, is very much ruled by free, and open source software, but that didn't stop Epic Games charging for UT2003, and id charging for Doom 3. Both games got their source released eventually, but not before the companies had capitalised on the investment, but that doesn't mean people are going to hunt you down and give you a good beating until you hand over your source code. That, and you can still install non-free apps anyway, but the userbase would rather you didn't, and to download any non-free software from the "repositories" first requires you to edit your config files, so it's by no means impossible. Obviously, you would get a larger return on your investment once macs are supported, those machines are for people with more money than sense, so they'll pay loads for it (Yes, it's not just Lumooja that makes statements like that). The difference is, you can get can basically get your engine working on a unix derivative without having to pay such ridiculous amounts of money for a machine that is most likely inferior to your current Windows based machine in every way. Sadly, I had to use macs at uni, and if you open up the terminal, they accept almost every single one of the standard commands that Linux does (being the standard unix commands that they are built on top of). It's only a successful platform due to its long running Photoshop dominance, and visual quality of the screens. Much as I don't like majority of the system, you can't fault the quality of the screens. Every single image always looks nicer on those screens.

Don't know how you're doing it, but that should be 1280x960. If you're doing all values between say 480 and 1050, it will be fine. If you're just trying specific numbers, say: 480, 800, 768, 864, 980, 1024 etc. Then that res will usually fail in fullscreen mode. Also would people not think that 1920x1080 was common? And the 16:10 equivalent of 1920x1200? (I prefer 16:10 over 16:9 any day...)

Interesting, I would have moved to Linux before Mac to be perfectly honest. Both are unix derivatives, but Linux can use absolutely any hardware that Windows can. I guarantee you that some Linux users (maybe not on these forums) will have GTX 480's working with full hardware acceleration, which no mac user can claim. Also, some Linux people will also be maxing out their 8-core i7's (or 6-core Phenom II's), although that may not offer too much more power than the Intel Xeon chips now found in current high spec macs. Plus the new high power macs come with ATI graphics cards, and we know the numerous troubles your engine has had with ATI cards previously. They maybe fixed now, but can you guarantee that with a new platform architecture, that they won't mysteriously re-appear? People were swayed to Macs more than Linux because Apple actually advertised, and boasted such features as "No viruses", "Doesn't crash", "Has an office suite fully compatible with Microsoft Office". Linux offered all of those, but for free. Whilst we Linux users are the silent minority, I'm sure you know that Lumooja has C++ compiled exes using your engine, working in wine (BlitzMax exes always worked in wine), which tells you Linux hardware is already up to the job. Once it works there, Mac users aren't thick, they now that mac support is either imminent, or it will work at the same time... But hey - your engine, your choice. But unless you already have a mac (or have access to someone else's) you can support Linux first without having to pay a large amount of money upfront.

On the build output, I just double click on any entry that says error, and it jumps to the line in question. It doesn't highlight the part of the line that's causing the problem though. But usually, on reading the error message you'll spot the problem almost instantly

Funnily enough, only a few days ago I found myself writing a soft of beginners guide to using Leadwerks in a C/C++ environment and one of the topics was strings. Even I was saying to use the std::string and I'm by no means an expert compared to the rest of the posters in this thread.

My current project exe is only 102K and that's after it has 2 static linked libs built into it (One at 400K and one at 4.0 MB), while the Leadwerks Engine dll is 1.7 MB. Even if it was a static lib, the exe size would still not be huge (Not like the Splinter Cell Chaos Theory (offline) exe, which stands at 24.5 MB. What have they bloated that with?) I'm not too bothered about the compilation speed. For me, execution speed for the end user is the only important factor. The execution speed is (more-or-less) identical, isn't it?

Rather depends if you can make Visual Studio create executables for other platforms... I've not seen a way to do that yet (But watch it be just one small option in the project properties ) If that can't be done, I don't see they would include the ability to read any static lib file format other than their own. Really the question would be "Which compiler would you be most likely to use."

I think in one of the old tutorials, Josh said that engine revving can be done via the SetSourcePitch() command

Hopefully you don't have a driving license. You'll kill someone driving like that. I presume you mean how do you import your models into the engine? If so, .gmf is the model format for leadwerks, so you'll need an exporter to make your models leadwerks ready. The most popular one I believe is for Ultimate Unwrap 3D, but there is also one for 3DS Max and there are a few for other modelling apps too... Then it's just a case of using LoadModel() to make it appear. There's a special command set (link) for vehicles. I believe they are now working (at times in the past they didn't work properly, but like I say, I think that's fixed now). Vehicles though are physics bodies, which you can create in code, or export from a modelling app (as a wavefront obj), and then run that obj file through something called "phygen" (included for free) which will create a custom physics shape. If your vehicle model (.gmf extension) and the generated physics shape file (with a .phy extension) are in the same folder, then your model will be linked to a physics body. Turn that physics body into a vehicle then you can move it around with the vehicle commands, and the graphical model will stay perfectly synchronised with it. It may be a bit wordy, but really, take it step at a time, and you'll see that you can load your vehicle in just two lines of code. Which must be easier than it is in UDK...

To me, this sounds like a reason to not link dynamically

.lib for me Is there not a poll to go with this post?

Wow, thanks a lot. I never even saw that command before, and it's exactly the command I needed. I was trying to do some acos() calls on some of the matrix elements . It was sort of working until it got to 180 degrees rotation, then it would go the other way. But thanks to you it works perfectly, keeps rotating in the same direction forever...

Unfortunately, after reading that, I'm still confused. The section right at the end looks like the information I need, but it's suggesting that I should already know the angle. I get the idea that they are showing how to calculate the new position of a point after rotating it by a known angle. Sadly, I don't know the angle. That the thing I've got to try and work out by processing the matrix that newton gives me, but it does seem to be suggesting that I leave zeros on the right hand size. It's also suggesting that I need elements 12-to-15, but after replacing 12, 13 and 14 with zero values. It will be something very small that I'm not understanding (it always is), but until I know what I'm not understanding, I'll be completely clueless and stuck.

Edit: I'm hoping this is the correct board for this. Since it is programming related, and this is the only programming board that does not say "Programming Leadwerks Engine with (language)" As most people will know, Leadwerks is great, because positioning and rotating objects is nice and easy, no matrix multiplication to worry about... Unfortunately, not all engines share this level of ease-of-use. As part of integrating a stand alone version of newton in to my project, there is a newton callback ... The TransformCallback. Basically, whenever an object changes position or orientation in the newton world, this callback is called so your graphics can reflect this change. What Newton does however, is give you a matrix containing 16 floats. Now, if I have been reading correctly, elements 12, 13, and 14 are used for the position (and 16 can be ignored entirely). This leaves me with 12 floats (0-to-11) describing the rotation. I quickly read my uni notes on matrix multiplication (one of things I thought I would never use again). I'm now quite confident about multiplying matrices together, but my concern is. What should I be multiplying these floats by, in order to get 3 meaningful angles from that matrix? Also, from observing the raw matrix output that newton gives me, elements 3, 7 and 11 are all zero, does this mean I should instead be forming a 3x3 matrix before doing any multiplication? There's no shortage of articles on the Internet trying to teach people how to do it, but they don't really seem to be written in plain english, and the ones I keep stumbling across seem to assume that the reader already has an extensive knowledge of Open GL's inner working's. Sadly, because I'm a bit thick, I seem to be getting quite confused when trying to read just about any of them. The console output of newton's matrix is as follows: Transform callback matrix element 0: 1 matrix element 1: 0 matrix element 2: 0 matrix element 3: 0 matrix element 4: 0 matrix element 5: 0.655827 matrix element 6: 0.754912 matrix element 7: 0 matrix element 8: 0 matrix element 9: -0.754912 matrix element 10: 0.655827 matrix element 11: 0 matrix element 12: 0 matrix element 13: -0.0534112 matrix element 14: -0.159811 matrix element 15: 1 As I said earlier, I'm using elements 12, 13 and 14 for the position, and that seems to be correct, I'm just having trouble figuring out how I get three angles from the first 12 elements. I'm also not sure if I should be using this matrix (with the zeros removed): 1 0 0 0 0.655827 0.754912 0 -0.754912 0.655827 Instead of this one (with the zeros left in): 1 0 0 0 0 0.655827 0.754912 0 0 -0.754912 0.655827 0 After that, I should a very basic Newton integration. A version of newton that I can also run in a graphic-less dedicated server. So I'm hoping someone can explain this to me in a way that even I can understand...

When Josh has read your email (no robots involved) your group will change to an SDK Developer (2.0 or 2.3 depending which version you have). When this happens, all of the private boards will become visible*, and you will be able to download things from the forum. It is done this way so you can can post whatever code you like without worrying about pirate SDK owners getting working code *Leadwerks Source remains locked - you need a source license to view that board. And lua will remain locked if you are only a 2.0 owner.

I wanted to suggest this a while ago (Dec '09 sort of time) but I also spotted some complications. When a model is loaded, say "something.gmf" the engine searches for: something.gmf something.phy something.mat somethingLODx.gmf How would this be done with memory? You would have to provide a memory address for at least the first three of those. How would it handle LOD meshes? The only realistic way I could think of was the ability to add them with separate function calls later on Example: TModel Something = LoadModel("Something.gmf"); AddModelLOD(Something,2,"SomethingLOD2.gmf"); Without something like that, you would have to make the engine aware of how many pointers you want to pass. Then there's mat file issue. How would you specify the texture being in memory? You simply cannot know where your texture is going to be allocated. I mean I would be in favour of packing everything into a single (encrypted) binary file that you can decrypt once it's in memory. The file would say how many LOD meshes there were, how many textures there were, and would list the size of each mesh / physics file, so you could know how many bytes to skip when loading of portion of the overall model. But simply saying you want to load from memory, I don't think is a very good idea unless you could describe ..how.. you want to load from memory. I was thinking about this again recently, because I was thinking about writing a short tutorial about quick, simple encryption. But I soon realised that there is no practical use for it in Leadwerks, because you have to load the decrypted files from the hard disk. Anyone being concerned enough to want to encrypt their assets in the first place will know that the the second their decrypted files hit the hard disk, they're vulnerable. Edit: I should add the the issues I listed mostly only apply to LoadModel. Loading an individual texture / sound from memory should be relatively straight forward.

In that case, do what kids in school do: model something close to a stickman 2 cubes for feet, 6 cubes for legs (2 upper, 2 knee-caps, 2 lower) 1 hips/waist area 1 for torso and chest 8 for arms (2 upper, 2 elbows, 2 forearms, 2 hands) 1 neck 1 head So, now instead of one cube, you have fourteen. so 14x more performance power is needed for the rendering... ...And finally, the most important detail for the male audience 2 hi-poly spheres (with the back cut off) at the front of the back cut off chest area (eh? Comprehension monster must have interfered). Must be high poly because this is where the male audience are going to spend 95+% of their time looking... More polygons in this area equals more performance will be required . Also, Make them unnaturally big too, because you'll only get one chance to impress your audience. Edit: wow, looks like the spelling monster got hold of quite a few words

No, your computer is junk and can't handle it... Is it hamster powered by any chance? PSU's are a much better alternative...