Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by JMK

  1. A new update is available for beta testers. The dCustomJoints and dContainers DLLs are now optional if your game is not using any joints (even if you are using physics). The following methods have been added to the collider class. These let you perform low-level collision tests yourself: Collider::ClosestPoint Collider::Collide Collider::GetBounds Collider::IntersectsPoint Collider::Pick The PluginSDK now supports model saving and an OBJ save plugin is provided. It's very easy to convert models this way using the new Model::Save() method: auto plugin = LoadPlugin("Plugins/OBJ.dll"); auto model = LoadModel(world,"Models/Vehicles/car.mdl"); model->Save("car.obj"); Or create models from scratch and save them: auto box = CreateBox(world,10,2,10); box->Save("box.obj"); I have used this to recover some of my old models from Leadwerks 2 and convert them into GLTF format: There is additional documentation now on the details of the plugin system and all the features and options. Thread handling is improved so you can run a simple application that handles 3D objects and exits out without ever initializing graphics. Increased strictness of headers for private and public members and methods. Fixed a bug where directional lights couldn't be hidden. (Check out the example for the CreateLight command in the new docs.) All the Lua scripts in the "Scripts\Start" folder are now executed when the engine initializes, instead of when the first script is run. These will be executed for all programs automatically, so it is useful for automatically loading plugins or workflows. If you don't want to use Lua at all, you can delete the "Scripts" folder and the Lua DLL, but you will need to load any required plugins yourself with the LoadPlugin command. Shadow settings are simplified. In Leadwerks 4, entities could be set to static or dynamic shadows, and lights could use a combination of static, dynamic, and buffered modes. You can read the full explanation of this feature in the documentation here. In Leadwerks 5, I have distilled that down to two commands. Entity::SetShadows accepts a boolean, true to cast shadows and false not to. Additionally, there is a new Entity::MakeStatic method. Once this is called on an entity it cannot be moved or changed in any way until it is deleted. If MakeStatic() is called on a light, the light will store an intermediate cached shadowmap of all static objects. When a dynamic object moves and triggers a shadow redraw, the light will copy the static shadow buffer to the shadow map and then draw any dynamic objects in its range. For example, if a character walks across a room with a single point light, the character model has to be drawn six times but the static scene geometry doesn't have to be redrawn at all. This can result in an enormous reduction of rendered polygons. (This is something id Software's Doom engine does, although I implemented it first.) In the documentation example the shadow polygon count is 27000 until I hit the space key to make the light static. The light then renders the static scene (everything except the fan blade) into an image, there thereafter that cached image is coped to the shadow map before the dynamic scene objects are drawn. This results in the shadow polygons rendered to drop by a lot, since the whole scene does not have to be redrawn each frame. I've started using animated GIFs in some of the documentation pages and I really like it. For some reason GIFs feel so much more "solid" and stable. I always think of web videos as some iframe thing that loads separately, lags and doesn't work half the time, and is embedded "behind" the page, but a GIF feels like it is a natural part of the page. My plan is to put 100% of my effort into the documentation and make that as good as possible. Well, if there is an increased emphasis on one thing, that necessarily means a decreased emphasis on something else. What am I reducing? I am not going to create a bunch of web pages explaining what great features we have, because the documentation already does that. I also am not going to attempt to make "how to make a game" tutorials. I will leave that to third parties, or defer it into the future. My job is to make attractive and informative primary reference material for people who need real usable information, not to teach non-developers to be developers. That is my goal with the new docs.
  2. If you're a beta tester, the new features are now entered into the new docs system. See Physics > Collider.
  3. The answer is yes, but you have to do a lot of casting to get the Newton classes and it is not something I can explain easily, since it is not a supported feature. I would probably use ray casting (the Pick functions) to do this. You gave me the idea to include some functions for user collision testing in the new engine: http://www.newtondynamics.com/wiki/index.php5?title=NewtonCollisionCollide http://www.newtondynamics.com/wiki/index.php/NewtonCollisionCollideContinue http://www.newtondynamics.com/wiki/index.php/NewtonCollisionPointDistance http://www.newtondynamics.com/wiki/index.php/NewtonCollisionClosestPoint It's a little tricky for me because this will run in the main thread, instead of in the physics thread, but I think it might be useful for many people to have these commands available.
  4. If you don't set mass in the first place, there will be no physics.
  5. I was curious and took a look at the flowgraph. That is some pretty complex logic at first glance. If I was designing this I would probably just do something like this in the windzone script: function Script:Collision(entity, position, normal, speed) entity:AddForce(self.force) end
  6. A new update is available to beta testers. I updated the project to the latest Visual Studio 16.6.2 and adjusted some settings. Build speeds are massively improved. A full rebuild of your game in release mode will now take less than ten seconds. A normal debug build, where just your game code changes, will take about two seconds. (I found that "Whole program optimization" completely does not work in the latest VS and when I disabled it everything was much faster. Plus there's the precompiled header I added a while back.) Delayed DLL loading is enabled. This makes it so the engine only loads DLLs when they are needed. If they aren't used by your application, they don't have to be included. If you are not making a VR game, you do not need to include the OpenVR DLL. You can create a small utility application that requires no DLLs in as little as 500 kilobytes. It was also found that the dContainers lib from Newton Dynamics is not actually needed, although the corresponding DLLs are (if your application uses physics). A bug in Visual Studio was found that requires all release builds add the setting "/OPT:NOREF,NOICF,NOLBR" in the linker options: https://github.com/ThePhD/sol2/issues/900 A new StringObject class derived from both the WString and Object classes is added. This allows the FileSystemWatcher to store the file path in the event source member when an event occurs. A file rename event will store the old file name in the event.extra member. The Entity::Pick syntax is changes slightly, removing the X and Y components for the vector projected in front of the entity. See the new documentation for details. The API is being finalized and the new docs system has a lot of finished C++ pages. There's a lot of new stuff documented in there like message dialogs, file and folder request dialogs, world statistics, etc. The Buffer class (which replaces the LE4 "Bank" class) is official and documented. The GUI class has been renamed to "Interface". Documentation has been organized by area of functionality instead of class hierarchy. It feels more intuitive to me this way. I've also made progress using SWIG to make a wrapper for the C# programming language, with the help of @klepto2 and @carlb. It's not ready to use yet, but the feature has gone from "unknown" to "okay, this can be done". (Although SWIG also supports Lua, I think Sol2 is better suited for this purpose.)
  7. No, but the new engine's editor could with the export plugin system. B3D is a very simple format I know well.
  8. Very first pass at SWIG C# binding code for new engine is uploading in beta forum.

    1. JKnife


      What version of .NET is it targeting?

      Be interesting to see if with this if LW5 will get Haxe "support" for free https://haxe.org/manual/target-cs-external-libraries.html

  9. My paper for the conference is finished and I am back to work. New update tomorrow probably, it just needs some more testing. C++ build times are down to like 10 seconds for a full rebuild. ❤️ 

    1. JMK


      About 2 seconds for debug builds (after the initial build).

  10. I've got a good start with SWIG. It is similar to tolua++ in that it uses a "cleaned header file" to generate the binding code.

  11. The multiplayer template uses Lua. You need a second computer and a second Steam account (or a friend) to test it.
  12. Prediction: LE5 coder split will be C#/Lua/C++ 90/9/1%.

    1. JMK


      It's currently 90/10% Lua/C++. I don't think programmers will switch languages, I just think that new users will be added that skew the percentage that way. So what is now 90% will become 9% of the new total.

    2. Thirsty Panther

      Thirsty Panther

      Wow. I thought Lua would be more popular but not by that much. I'll go with 40/50/10%

    3. JMK


      We will find out soon! (There's no danger of C++ being de-emphasized or minimized. It's the foundation of everything I'm doing.)

    4. Show next comments  3 more
  13. If you burrow into the shape class you will find the raw Newton objects in there, which do have a lot of collision test features.
  14. All Discord channels are now private, i.e. it's disabled for now.

    1. Show previous comments  1 more
    2. gamecreator


      There is a chat in the bottom right.

    3. JMK


      @carlb That's pretty much proof it was a mistake to give them anything. I should not be in a power struggle with a third party for control of my own community.

    4. wadaltmon


      I think Discord and the forums are entirely different use cases. Discord is pretty much an IRC, apt for asking quick questions and making quick remarks. More in-depth questions are always better suited to the forums.

    5. Show next comments  3 more
  15. I don't recommend using this. The launcher doesn't have much purpose now that everyone can publish anything on Steam.
  16. Maybe change the directory before you start the game, to a second folder with dummy content?
  17. Pretty darn happy about how the new engine is turning out. It's more Leadwerks than Leadwerks!

  18. Yeah, when you have different floor textures you can place next to each other to make a bigger design, it really makes the level flow. Having a corner trim piece, for example, looks a lot better than just slicing it at a 45 degree angle and having a visible seam. Alpha discard is also a great feature for floor panels and fencing, you can do a lot of interesting things with that when you are building a scene.
  19. One thing worth considering is designing textures to support interesting geometry. Instead of just thinking of a texture as something that covers a flat square, a good texture set can influence the level geometry. This makes it much easier for the level designer to create a good scene. To make doorways and trim details that can be cut to the geometry, you want to make sure those features line up to a power-of-two size or combination of power-of-twos, i.e. 32, 48, 64, 192 etc. If you have a set of textures created this way, your levels pretty much design themselves.
  20. The Leadwerks 5 beta has been updated. A new FileSystemWatcher class has been added. This can be used to monitor a directory and emit events when a file is created, deleted, renamed, or overwritten. See the documentation for details and an example. Texture reloading now works correctly. I have only tested reloading textures, but other assets might work as well. CopyFile() will now work with URLs as the source file path, turning it into a download command. Undocumented class methods and members not meant for end users are now made private. The goal is for 100% of public methods and members to be documented so there is nothing that appears in intellisense that you aren't allowed to use. Tags, key bindings, and some other experimental features are removed. I want to develop a more cohesive design for this type of stuff, not just add random ways to do things differently. Other miscellaneous small fixes.
  21. You likely have the wrong password stored in the browser.
  22. It's almost as if this new engine was built with feedback from tens of thousands of users in mind!
  23. I think we will need an example we can run to test this.
  • Create New...