Mumbles

What is your graphics card?

Well, that should evaluate to true (return 1)... 0 is after all, equal to 0. Secondly, is that code copied/pasted? Your second atoi statement has a lowercase 'e' on the entity, which could cause it to bring back a zero... In which case, only a negative number on the LHS can cause an evaluation of false

Actually, this is very inspring stuff. I don't want to hi-jack your thread so I'll keep it quick. But back in my DBP days I was building a dynamic waypoint generator. The whole pathfinding system was to be based on a system very similar to breadth-first search. But what I didn't want was to have to sit there placing large numbers of waypoints (especially if the levels became large), so I'd make a system to generate them for me. You would provide it 3 integers to form a cuboid and all geometry inside this cuboid would be analysed (Probably either the same way, or a very similar way that your system does this). The cuboid would be split into 'cells', each with a size of 1x1x1. Once all the cells had been formed, any that were directly on top of geometry would have a waypoint on them. Then they were linked up. The only rule for linking was that the distance between two points must be less than sqrt(2) if they were on the same height level, or less than or equal to sqrt(2) if the height level was different. This disallowed diagonal movements on the same height level (to save memory), but allowed such movements as climbing stairs. Unfortunately, this would generate sometimes as many as 8000 walkable tiles, and I decided that this was too many. Upon trying to build an algorithm to remove redundant (transitive relational) waypoints. But I couldn't figure out how to do this, so it eventually all fell to pieces - just over two years ago... However, looking at your system, it seems that perhaps I was just being too conservative with memory. Not only does yours allow diagonal movements on the same level, but yours also doesn't attempt to optimise the navArea grid. The navArea grids look almost identical to my old waypoint generation outputs, because it wouldn't ever place a waypoint in the air, it had to be right on top of something. So yeah, this looks great, and has actually inspired me to possibly think about pulling mine out of the bin and maybe even trying to bring it into Leadwerks. (I hope a kept a copy of it in a sensible place)

I had my own thoughts for a slightly sped up, multithreaded loading system (via hijacking ProcessScene, rather than LoadScene) but never even started to implement it, so this should be well worth a look

But we humans don't accelerate the same way vehicles do. Within about 1/2 a second, we're at our target speed (unless you're out of energy, or have a lard belly). So we just use 500 as a value to make it feel virtually instant. If the maximum speed is constrained to about 1 or 2 metres per second anyway, then we just reach that 1 or 2 m/s very, very quickly...

I guess it's because of distance between verts 1 unit = 1 cm, the verts are really far apart 1 unit = 1 metre. the verts are quite close together U and V are values between 0 and 1. So larger triangles (or quads), with the 1 unit = 1 cm scale, equals less accuracy with the floating point. I guess that has something to do with it.

I don't have a 'world size'. the world is as big as it needs to be. The objects placed in it are built to the 1 unit : 25 cm scale. And camera ranges are: near: 0.01 (2.5 mm) far: 3000 (750 metres). 10000 units long, is it an MMO type game? A world that large is better built like a jigsaw puzzle, and only show each pice of the world when you are within (for example) 300 units of the middle of that piece.

I think 1 unit = 1m is the scale it's designed for. I personally use 1 unit = 25cm (So 4x larger), and that seems fine. I suspect that the scale is not the issue, but rather, how far apart the vertices are. Doing a simple ScaleEntity(entity,Vec3(1000,1000,1000)) will make the vertices much further away. Larger faces probably result in crappy lighting - regardless of scale.

Yes you can, but it changed between version 2.2 and the newer version 2.3 I don't have the newer 2.3, but I know it is still easy to do.

The official line is that the engine works in any language that can call functions from a DLL. It's written in BlitzMax, and has been translated to other languages. The most commonly used languages are: BlitzMax C/C++ C# they all have their own dedicated board in the programming section, but they are locked to people who not paid for the engine. This is so members can post headers there, without being thieves being able to download them, thus giving them a full engine for free. Official support is limited, and generally provided only where the there's a fault in the DLL (which will affect all languages). Generally, the support is community based because Leadwerks is an extremely small team. If they spent all their time answering everyone's questions, they would never have time to improve their engine. And the community are generally quite helpful, and quick to respond anyway. All I would say is, don't be turned away by community based support, here it does seem to work quite well. But it's your choice in the end. Edit: If you go to that page, they're on the left hand side, under the link called "Bodies" To create a physics box, the command is CreateBodyBox() - the one I posted earlier up is for the visible mesh version, because physics bodies are invisible. usually you would 'tie' the visible mesh to the invisible body the make the visible mesh appear to be physics based.

Put simply, yes you can do it all in code. creating boxes is very simple. Just use the CreateCube() command. You can actually make any shape you want entirely in code, but it's not a good idea. cubes, sylinders, spheres etc can allbe created in one command. But for non-primitive shapes, you have to create all of the vertices, then connect them all up. So you can do it, but I would only create cubes, cylinders, spehere, etc, in code, anything else I would use a 3D-modeller for. Input, update, render. You would be expected to put those in your own loop anyway, so that's more than possible. The c# headers and managed by the community (they're not official), but they should still be fairly up-to-date. (I don't actually know, because I use the standard c headers)

That's exactly what I was thinking... Any chance of naming and shaming this manufacturer? Just because this was an i7 board doesn't mean it can't happen on any of their Phenom II boards... And - oooh, when they find which out little toe rag broke their hammer, his head will suffer the same treatment, you mark my words...

Really? I have to use a different password...

There's also the fact that they would look rather silly if they spent millions building their own engine for years. One that works on all three platforms, and then they decided "You know what, Leadwerks Engine 2 works better than ours, we'll use this one instead". So much money would go to waste, so they'll probably stick with what they've got, and try to mimic the good bits of Leadwerks.

Best best would be to go with something like RakNet (if you're brave enough, winsock - I personally think winsock is a nightmare to use!) Edit: Beaten again -- I always take so long to type MW2 only has one real server, the IW.net matchmaking server. I'll concede that it does store a large list of 'hosts' that you can join. the problem is, these hosts are hosted on home connections which start to lose synchronisation pretty badly with more than about 12 clients - and poor synchronisation means a poor game for all. Peer-to-peer file sharing networks (legal or not, that's not the point here) don't suffer with large numbers of clients because the data does not need to be synchronised. So I'm not saying the poor synchronisation is always bad, but for games, synchronisation should be high on your list. And 9v9 is certainly by no means large. Tribes 2 (Early 2001) Supported 64 players smoothly (even over dial-up). By FPS standards, those are what you would call large servers. Not 18 players, those are pretty standard, if not small... I'm not sure how realistic it would be to use built-in Leadwerks networking commands because I don't use them. But using RakNet, it should very easily do what you want.

[#10355] You must cast your vote in each question of the poll. Which Version of Leadwerks Are You Using: None of the above (2.27) So I put a 2.26 in since they're almost the same. Chances are your water shaders will work if you copy them over to 2.27. What Language Are You Using: Other C for engine commands, C++ for dealing with my own "stuff" (technical name) Would You Be Interested In GameObjects: No, I want the "satisfaction" of reinventing the wheel and doing it myself, even if the project takes 5x longer as a result (Edit) I know the last post time keeps blaming me because I'm the last poster, but I'm not continually bumping the thread. That's just happening because someone has casted a new vote...

Surprise, surprise. The "wrong" way describes me perfectly. Heh, I'm a programmer, not an artist. So thanks for the link... I assume it was meant for me... Sadly, this means I've got to learn to... umm, draw... Ugh, horrible thought.

Interestingly, I'm not experiencing leaking at all, and I'm using C... Loading a very primitive scene: A large blue box as the floor with zero mass 3 small light-weight red boxes, and 1 small green box (weighing the same as all 3 red boxes.) Sample 'cars' seeing how much force is needed to make them move at a decent speed. During loading, goes up to ~125 MB Once loading is finished, it drops to ~48 MB and stays there minimise the app, and the memory drops down to 8112 KB, and again, stays there (If the app is windowed it stays as ~48 MB) bring the app back to being the active window, and memory usage will rise to ~12 MB, once again, stays there (Again, this only happens if the app is full-screen) However, if my app does not sleep it's idle time, then when paused, the memory will climb to 13 MB, and then drop down to 2 MB. Climb to 13 again, drop back to 2 again, and so on... So not only does it use less memory after minimising->restoring, but it also doesn't look any different (Presumably, textured meshes would lose their textures in this case - I'm still using coloured cubes as placeholders). I'm not saying that this is a fault, just an observation.

At that price, perhaps I should buy it even if it doesn't see much use... I mean, CrazyBump is $300 for a commercial license, and when I was using it's free trial, it didn't seem to be creating the normal maps the way I was expecting. Example being, I wanted to inscribe some text into a relatively low quality G36 model "Made in Germany" stuff like that. It just seemed to flat when viewed on the weapon. I always put it down to me not being a modeller, but it should be interesting if this tool can achieve the effect, even if the process of going about it is different.

Well, despite the list of stuff it can't do, it still looks excellent - and as we know, it can only get better... It definitely sounds like a lot of effort has gone into this, and I'm sure it's all been worth it.

> Make me a game I understand you, and say do it yourself, you lazy sod!

Several years ago, I would have said that Nvidia absolutely crucifies ATI when it comes to OpenGL rendering. But my non-gaming laptop has a mobility Radeon 3100 in it (Or it might be a 3000, can't remember off the top of my head). As low grade as the graphics card is, it can run simple LE scenes quite nicely actually. So, with a much better card, that your linked laptop has, there probably won't be any serious problems with it, if there are any problems at all that is.

Never noticed that second quote before... Maybe he meant 2.3. Since 6 is right above 3 on the 10-keypad

Move the decimal one place to the left and then stick a 2 in front of it

2.0 - The elite choice B)