Crazycarpet

If he truely wanted to show that his engine was more "correct" he could release his tests so people could point out the flaws. "When did programmers become so small-minded that they assume any decision a big corporation makes is the best?" - Well, I counter this with: When did programmers become so small-minded that they assume their decision is correct over that of the masses? When did we start taking an falsifiable test as fact, when did we throw out all the other tests that suggest the opposite of what these tests suggest? Does Julio give us any other information? he's profiling performance but he's not telling us whether the simulation is CPU bound or not, it's common knowledge that PhysX is slow when CPU bound the beautiful thing about it is generally it's not it allows for simulation on the GPU as well. I could find you 100 other tests that show Bullet to be the best, and 100 other tests to show that Havok is the best, and another 100 to show that PhysX is the best. But are they? no they're the best in each test because of the implementation. You need to remember big game studios don't just "make a decision" for example Unity started with Havok, then Bullet, then decided PhysX worked the best for their needs. To say "Newton is the best and most accurate" is not only naive, it's wrong. The proof isn't right infront of my eyes, his test (which is bias just like every other test that claims one physics engine trumps the rest) shows that for his implementation of each physics engine to do the same thing, he produced the best results with Newton. Who's to say I wouldn't be capable of doing that with any other physics engine? I know for a fact that soft body physics aren't "so soft that the joints fall apart". That's simply untrue, that happens because his implementation.

This test seems extremely bias to me... a lot of these problems would be fixed by making some minor adjustments, it looks more like the tester just fed the same parameters to each physics engine and expected the same results, and decided Newtons were the most "correct". You look at almost every AAA game and it's going to use PhysX or Havok.. because they're extremely performant and extremely accurate in almost all situations. With basic rigidbody Newton is great, but past that it struggles in a lot of scenarios... not bashing Newton but to say it's better than PhysX and Bullet is just bias. They're all strong in some areas and weak with others. I also don't think there's anything official about a test where you don't get the code to falsify his results. I can say with absolute certainty that all the issues this guy shows in the video are his own doing (or whoever made the test). How your physics behave is really implementation dependent to a huge degree.

Those were all the things that drove me nuts... hope Gamecreator's stuff stops falling through the world.

In regards to the lighting issue, make sure you're using the appropriate shader in the material like: diffuse + normal = specular (normal being key.) and try recalculating the normals.

This is long overdue, it would be nice to be-able to make it so my cursor isn't pinned to the center of the screen while my game is tabbed. Plus all it takes is a little //lua comment.

I think Aggror thought you were using C++, however in Lua it's not much different... store all your UI elements in a table and sort that table. I don't know what your code looks like so here's a generic Lua sorting example: local myTable = { { name = "key1", priority = 0 }, { name = "key2", priority = 1 } } table.sort(myTable, function(a, b) return a.priority < b.priority end) Then, use this table to render your UI elements one by one after world:Render() is called. Wherever you create your widgets you'd use table.insert to assign a priority and push the UI elements to the table. It's hard to give a more detailed answer because i have no idea what UI system you're using (The LE one is in beta, undocumented.) and I don't know what your code looks like at all. If you're using the LE one, keep in mind Widget::Draw() is not exposed to Lua...

Actually, for me from Entity::Camera::SetFov down it shows wrong topics: Should show | Shows SetMultisample GetZoom SetProjectMode Pick so on and so forth..

Yeah, well wish I could help more because that code isn't necessary. Just tested and I was right, LE hides/shows the children implicitly. If you're referring to the "hidden" checkbox in the scene panel when you say "start as hidden" I don't think Show() will work to show it again. I'm not sure if it's a bug but it hasn't worked for quite a while.

Sorry, I'm not quite sure I follow but are you trying to make Show/Hide execute on all children? It would look something like this: function Script:Show() if self.entity:Hidden() then self.entity:Show() end -- Show all children. for i = 0, self.entity:CountChildren() - 1 do local child = self.entity:GetChild(i) if child:Hidden() then child:Show() end end end function Script:Hide() if not self.entity:Hidden() then self.entity:Hide() end -- Hide all children. for i = 0, self.entity:CountChildren() - 1 do local child = self.entity:GetChild(i) if not child:Hidden() then child:Hide() end end end I feel like LE does this implicitly though... shouldn't be necessary.

I'm fairly certain no branch of Leadwerks is missing folders, and the old tutorials should still work! There is no need to remake them every year. Here are the steps to create your FPS player, it's really simple if you're using the pre-made game templates!: 1) Create a project using the "First Person Shooter" template. 2) On the "Assets" panel, double click "Prefabs" in the folder list. 3) Select "FPSPlayer.pfb" and drag him into your scene. 4) Goto the "Scene" panel, ensure in the "Entities" category that there is NO other camera as this will be used instead of the FPSPlayer's camera. That should be it. If you don't want to use the "FPS shooter template" you'll have to make your own player prefab.

WIP LuaBridge binding generator aswell. https://bitbucket.org/Codeblockz/luabridgegenerator Luabridge - https://github.com/vinniefalco/LuaBridge ToLua++ is better though imo, it handles overloaded methods and constructors, LuaBridge does not... LuaBridge is however better for sheer speed. Note that this won't currently work because it doesn't remove overloaded methods... but it will in a few days. Edit: STILL haven't got around to this, i plan on forking toLua++ to add function overloading support instead I just haven't had time!

Hey all! So recently I've been using Josh's BlitzMax ToLua++ package generator but it just didn't quite do everything I needed, so based off his design I wrote my own C# version that supports a little more variety of situations. The usage is the same! just tag classes (or structs), and public members with the '//lua' comment in your C++ header files and follow the instructions provided on the BitBucket page. After you implement this into your project you will be-able to generator all your ToLua++ bindings with 1-click. The one thing you have to do manually is open the generated C++ files and add any required includes as I haven't made a clean way for this to be done automatically (yet). You can get ToLuaPkgGenerator here. (Windows Only) Just a simple tool I wrote to make my life easier, hope others find it useful as well! Here's an example of the pkg file generated for the Leadwerks namespace: https://pastebin.com/NjpE8L8d Edit: - ToLuaPkgGenerator no longer removes default arguments but now rather replaces unsupported types with the nearest supported one. (In the pkg files, your code is never modified by these programs!) - Todays update will also encase namespaced classes in modules to further prevent ambiguity issues. (i.e: System:Print() will now be Leadwerks.System:Print()) ** This doesn't overload the default bindings Leadwerks provides so the provided Lua files will still work. ** Edit #2: - A naive solution to a namespace issue can be found in my BB repositories called FixToLuaNamespaces. Edit the batch file provided in ToLuaPkgGenerator, uncommenting out the line that executes this application on each generated cpp gluecode file. You simply drop the compiled FixToLuaNamespaces.exe file in the same directory and the ToLuaPkgGenerator.exe file. - In this solution when ToLuaPkgGenerator generates a return type preceded by a namespace like Leadwerks::Sound. FixToLuaNamespaces would replace the strings "Leadwerks::Sound" with "Sound" assuming that's the way ToLua++ named them when they were exposed.

if (Interpreter::ExecuteFile("Scripts/Main.lua")) { Throws an access read violation. I feel like it's related to my toLua++ bindings, but I don't see why one project works and the other does not then.. Edit: Figured it out! Sorry! It seems my toLua++ bindings were somehow removed from the project! I never even thought to check this.

Before I post any source code I wanted to ask the community if anyone's ever experienced this issue before.... in one of my projects (the other has identical code to this point!) when I go to execute Main.lua with the interpreter a read access violation is thrown, here's what I know about it so far: 1) It started happening after linking against a new lib. (However, I don't think it's this because the working version links against the same lib.) 2) No code changes were made from the time this app was working to now. 3) I'm not on the LE beta. 4) The Main.lua file exists!! 5) The file Main.lua contains no lua errors. 6) It does not seem to be a file permissions issue. NOTE: The same access read violation happens even when the App class is replaced w/ the default one from the LE template. And just to reiterate, my other project that does work uses the exact same code up to this point, and it's Main.lua file is character-for-character identical. Edit: Solved. I must've accidentally removed the ToLua bindings cpp file from one of my projects!

Oh, I don't know... I feel like if the output isn't already being redirected it should print to the console by default. I don't know how you'd do this if it's not already doing it, sorry. Edit: -Keep in mind if the application doesn't open it's own console it has no object to pass stdout to... it'd be NULL, so unless you could set from C++ the console to redirect stdout to (the one created by the batch file) this might not be do-able. If you wanted to build it right into the engine you could create a console and redirect stdout and what not, stderr, etc... but other then that idk.

You mean forward console output to a file? Run the program with the command line parameter: "> "output.txt"" or whatever file you want it to forward stdout to. Example bat file: start "Hale3DEditor" "Hale3DEditor-Debug.exe" "> console.txt"

Hope they fix it! I've had this happen twice, both times power related. One I just didn't have it sitting on the motherboard correctly, the other time I was missing a power cord... so basically what everyone else said.

Why not do something like making it so the default Leadwerks templates are open source so the community can contribute to them? Of course, changes would still require your approval.

Not trying to sound like a broken record, but this really does sound like you have a camera in your scene, in which case your camera would stay put because of course, the main camera that's being used isn't actually moving... and yes you would still hear the footsteps of the character controller. Keep in mind that a default scene you create by pressing "New" has a camera in it already, delete it if you haven't already. Look closely because this would perfectly re-create the situation you're describing. You should have no cameras in your scene tree, FPSPlayer.lua creates it's own.

I really like the ideas you suggested here... recently been doing a lot of work with Vulkan, and although it takes a lot of code to accomplish anything with Vulkan it's well worth it.... easy to optimize, and without doing a whole lot you'll see huge performance gains on AMD cards, and decent ones on Nvidia cards as well... also the framerate seems to be more steady in general when using Vulkan. Been doing some work with physics on a separate thread where the loop is executed at a fixed interval and it's been really nice so far... plan to do some work with threading the creation of sub-buffers on Vulkan as well so looking forward to seeing where LE goes with this, I think it'd be a huge step for the engine.

Really cool is right, looks like you're taking your time and doing an awesome job of the LeadwerksGUI system.. can't wait til it's done!

See that's what I'm doing, but I print out the input I'm passing to SetInput and it seems that he server for some reason simulates the movement for an extra frame or something before stopping it (I stop it when there's no input.) so they're getting slightly different results from identical inputs. I feel like it SHOULD be stopping the input on the server at the correct time... but it's not. I'm sure I'm doing something wrong and just missing it but this is far from my first time making predicted/reconciled movement. Edit: Okay so i found out no matter how I do this w/ LE CharacterPhysics it's not possible because the frame-delay before actual movement happens makes it so reconciliation is so far behind and of course choppy... so I need to write my own character controller... any suggestions? I don't even know where to start.

So I have a game where I have a dedicated server and clients with predicted movement and server reconciliation... the problem is I noticed when using SetInput it's really choppy , and when I dug into it deeper it seems that SetInput keeps moving the player with these inputs til you SetInput something else.... (Which is a problem since there's a network delay.) So my question is, is there ANY way I can predict fully the outcome of character controller movement in LE... (guarantee the server/client will produce the same result when given the same input.) The problem with SetInput continuing on simulating movement in one way til inputs changed is that the server of course has a delay when receiving the clients inputs. So I need either a move method in the character controller in LE that you can set how much movement to do per-frame, that DOESN'T carry on to next frame.... that or I have to make my own character controller :/ anyways any tips/tricks would be appreciated. Just sort of stumped and I'd rather not write my own character controller. If LE has something similar to Unity's CharacterController.Move please let me know. I need to be-able to fully predict the movement result on the client and ensure I can (almost) always produce the same movement result on the client/server to do this I'd need something where I can specify the movement myself rather then relying on the movement through 'SetInput' that continues movement for a moment longer than it should. (Again, because of network delays.)

Again, definitely not picky... necessary lol, glad you noticed thanks again. Edit: Although this one I did have fixed in my version. 0.o must've forgot to upload.

Woahh nice catch. Cant believe we missed this. Thanks. Will update pastebin when im by a computer. Edit: Updated.