Jump to content

DaDonik

Members
  • Posts

    376
  • Joined

  • Last visited

Everything posted by DaDonik

  1. Those are just some predefined collision types. According to the docs (http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/entity/entitysetcollisiontype-r35) you can choose any value between 0 and 99. LEt me remid you that i don't own the engine and just took a quick look at the documentation, so no guarantee ^^
  2. Axis aligned means they won't rotate, which makes things faster to calculate. Normally they are aligned wo the world axis, but who knows what Josh implemented.
  3. Of course it will be as good as that one! The fact that newton runs on the CPU and the demo you show runs on the GPU doesn't affect speed at all! Get a brain...or stop trolling... @ Shadmar Can't try that demo, as i don't have LE3 installed, sorry.
  4. At least you now accept that you have serious problems
  5. It's a no for LE2 and LE3 doesn't even have dynamic shadows atm.
  6. Be patient guys, the more questions you ask, the longer it will take Josh to release LE3
  7. The easiest way is to have two TPivot's that you use to get the desired rotation. Position one pivot right where your model is and the other at the place you want to look at. Let the first pivot point at the second one and then get the rotation from your first pivot. Now use that rotation in CalcBodyOmega and you are done.
  8. All of these full screen post effects are working on a per pixel basis, which is why the number of pixels is the most important performance factor. In the case of DOF it is always working on all pixels, so it doesn't really matter what near and far distance you set. It might be that the per pixel calculation gets more or less complicated when you change near and far distance, but that would be not a huge factor.
  9. Thats indeed good news. Now we just need a LE3 beta to play around with and get used to how things are done.
  10. Error handling in the LE2 Editor is not really existing. I would highly suggest not to use LUA with LE2 if you are new to programming. Even though i'm quite proficient in C++, i still have problems using LUA scripting. A simple typo will cause that "EXCEPTION_ACCESS_VIOLATION", while any C++ compiler will complain about it. Normally after the main loop a program closes. At that point the engine is already unloaded. So why are you calling ShowMouse()? =)
  11. You have to live without Framework, because Frameworks intention is to keep exactly these things away from unexperienced users.
  12. The solution is pretty simple, but not obvious if your are not used to C++. You just can't compare a char* and a string. if(GetEntityKey(entity1,"name")=="test_box") Where GetEntityKey(...) is returning a char*. One way to do it would be to convert the char* to a string and then compare the two strings: std::string strEntityName = GetEntityKey(entity1,"name"); if (strEntityName =="test_box") { ..... } if the compiler complains about the std::string, just include the string header: #include <string>
  13. EntityDistance() works on the origin of the entity, so that wouldn't be accurate with such a huge plane. Since the world is just a huge box, all you need is to check if one of the coordinates is near the size of the world in that direction. You could also make a physics box and scale it so it is more or less a plane. Then use the collision callback to free any entity that collides with it. Do that for all 6 sides and you have it. Oh and make sure the physics boxes are inside the world, otherwise it won't work.
  14. Thats not quite true, the callbacks can also be static class member functions.
  15. The character contoller code was available at some point. Sadly i can't find a link to it anymore. Maybe someone else can help out...
  16. Just a small tip: Instead of multiple calls to KeyDown(KEY_A) you could save the result in a variable and use that. bool bKeyDownA = KeyDown(KEY_A); .... if (bKeyDownA) { .... } That saves some time, because it only has to Call KeyDown(KEY_A) once. Not that it gives you much performance, but things like that add up easily, as your program evolves. Oh and there is no judgement involved, just a simple tip
  17. You can do it that way: if (KeyDown(KEY_W)) { sequence = 2; } else if (KeyDown(KEY_A)) { sequence = 2; } else if (KeyDown(KEY_S)) { sequence = 2; } else if (KeyDown(KEY_D)) { sequence = 2; } else { sequence = 1; } Or even that way (if W, A, S, D all should do the same) if ((KeyDown(KEY_W) || KeyDown(KEY_A) || KeyDown(KEY_S) || KeyDown(KEY_D)) { Sequence = 2; } else { Sequence = 1; }
  18. It's up to you to combine LE2 and RakNet in a way that suits your needs. Both of them are accessible from C++. I don't mean to be rude, but not knowing that doesn't put you in a place where you are able to make a MMORPG.
  19. I feared only LUA will have such "project managment" support. Nice to have that in C++, too! I actually aggree with metatron (doesn't happen too often ). It would make it somewhat easier for us C++ people to share libraries between projects.
  20. Most ppl asking things like that will probably not manage to do it... You would have to throw away all LE2 physics commands and replace them with your own implementation. Since you have no LE2 source code (i think) you can't change the commands and rebuild the engine. That means for every LE2 mesh you load you would have to create and maintain a physics body with NGD all by yourself. Dunno about the NGD version that is used with LE2.5
  21. Since the Callback functions are only documented for C/C++ and Blitzmax, i don't think it's possible to do that from LUA. To be honest i also never tried...
  22. Looks like your "graphics" chip is not worth its name Check out that link and look at the bottom of the page: http://www.leadwerks.com/werkspace/page/Products/le2/_/system-requirements Intel graphics chipsets are not supported...
  23. Create a sound, create a source and then connect the sound to the source. AFAIK the source commands work with mono .wav or .ogg only, but i haven't tried it for like a year.
  24. You should take the direction of the body's current velocity into account. Just relying on collisions will cause "bugs". Imagine an already airborne body hitting the ceiling...
  25. If it's possible to determine that a body was thrown in the air (just like the user presses a certain key), you could set a flag that tells your code that the body was thrown. Now you can check if your velocity and rotation is near 0 and just ignore it, if the flag is set. You could apply the same for a bouncing object. Just use the collision callback and check if the force is sufficient to get the body airborne again. If so, set the flag again. I do not recommend to check any float value against 0.0f. Normally you would define a small value beyond which you assume it's zero. The way i would do it: // Global const float cfMinVelocity = 0.01f; // For each throwable body bool bAirborne = false; // Check if the velocity reaches zero LE::TVec3 Vel = LE::GetBodyVelocity(TheBody); float fVelocity = (float)sqrt(Vel.X*Vel.X + Vel.Y*Vel.Y + Vel.Z*Vel.Z); if (fVelocity <= cfMinVelocity) { if (!bAirborne) { // Object is not airborne/thrown and has stopped moving } else { // Object is airborn/thrown and has stopped moving } } You can even get rid of the square root and check against cfMinVelocity*cfMinVelocity to get maximum performance =) Edit: Assume a player that can shoot a ball that then bounces off other objects. The player shoots the ball and you set the flag bAirborne to true. Now the ball flies around and finally hits an object. The collision callback of the ball will be called and you can set bAirborne to false. If the collision speed was fast enough, you set bAirborne to true again, because the ball will become airborne again.
×
×
  • Create New...