Jump to content

Crazycarpet

Members
  • Content Count

    283
  • Joined

  • Last visited

Community Reputation

85 Excellent

About Crazycarpet

  • Rank
    Advanced Member

Profile Information

  • Gender
    Male
  • Location
    Canada
  • Interests
    Vulkan graphics API, C++, Multithreading, Lua, C#.

Recent Profile Visitors

6,817 profile views
  1. Visual studio 2019 rocks. Unbelievably fast; I got a significant (consistently between 12 and 16) FPS boost in one of my game engine projects simply by recompiling! I guess new C++ optimizations in the compiler really lived up to the hype. Has anyone else found this to be the case?

    Hope to see Turbo using it. ( I'm glad to see it's using Vulkan. :) )

    1. Show previous comments  5 more
    2. aiaf

      aiaf

      Josh builds Leadwerks with vs2017 at the moment , but you can use vs 2019 for your project, i don't remember toolset nr

    3. reepblue

      reepblue

      Then yeah, ofc you can use the new ide, but it sounds like you still need the 2017 build tools. Luckly now you can pick and choose what compilers during installation.

    4. aiaf

      aiaf

      You dont need 2017 installed, i just have 2019 for my game.

  2. I get what you're saying, but the two physics libraries are very similar in how you implement them, switching the system out would be a rather simple process. Plus I would assume Josh uses some kind of higher level wrapper for the physics APIs that is used in both Turbo and Leadwerks. Changing one would like be nearly as simple as a copy and paste to the other with some minor changes. (That is a guess, I don't know how Turbo's physics were done.) If Newton does the job I'd say leave it... but it seems like it's causing headaches which with all the robust, free physics APIs out there
  3. I've been using Bullet in a lot of projects lately, it's really come a long way in the last couple of years. Very fast, more than accurate enough, fully-featured (unlike Newton), and open source... The documentation is also decent, especially stacked up beside Newtons. If you are planning to switch I'd imagine Bullet would be a pretty quick and painless switch. PhysX is good too but honestly, I prefer Bullet it has more options. Performance wise it leaves Newton in the dust, the only downside is the rigid body simulations may not be quite as stable but I'm sure they're more th
  4. They're just not updating OpenGL drivers to support new revisions of OpenGL past a certain one... I don't remember if that is 4.2, 4.3, 4.5 or what. Still, I doubt many people will follow this trend and if they do at least you will still have Vulkan. Shame Apple is only planning to support Metal, MoltenVK looks cool though. (I hear they're planning to make design and build their own processors too... 🙄)
  5. Pretty sure Josh said he's not working on LE4's editor because it's not carrying over to LE5.
  6. The executable in your game, the exe file, is built from the C++ source code found in "My Documents/Leadwerks/Projects/<My Project>/Source/". As you know in C++ you have both header files, ".h", and cpp files, ".cpp". Header files are generally for declarations. (They are where you tell the compiler what functions, classes, methods you are defining, but generally do not assign them a body.) C++ files are where you either write "static", or local code to the cpp file.... and/or more commonly. To use these functions, classes, and methods that you declared in your header file in s
  7. I'm too lazy to write the code, but you could do a pick downwards to see if there's 30ft of no collisions (or at least to confirm the actor isn't touching the ground), then set a variable in your character, 'falling', to true and store their current y position... In your UpdateWorld loop for this actor check if the player is 'falling', subtract the actors starting 'y' position from when they were marked as 'falling' from the current 'y' position and if that difference is 30 ft or over kill em. Edit: - You should code an IsOnGround() method for your actor, and use that to set 'falling' t
  8. This is really impressive Josh, can't wait for the release. However still I feel like the instanced rendering is carrying here I'd love to see how much faster LE5 handles animated meshes than LE4. Perhaps a demo of this in the future? Also, I thought you said LE4 has frustum culling when I was complaining about GPU occlusion culling?
  9. The reason you'd want to multithread the command process is for situations where big, new, powerful GPUs are bored because the CPU's one thread can't send it commands fast enough to utilize it to the fullest extent. That's not a fair analogy so long as your GPU can handle it, why would you not want to throw more work at it? Modern GPUs (10 series, etc) can certainly handle it. A great GPU can handle anything a single core on your CPU can throw at it with ease, so you want to throw more at it. This is the most common bottleneck in games these days with how powerful GPUs are getting. The b
  10. Again, Doom doesn't do multi-threading... Why would it be faster than it's OpenGL renderer? They've had years to optimize OpenGL drivers, of course it'll be at least as fast in a single-threaded environment. It's not magic, it's physics at that point.... Vulkan can use multiple threads to generate command buffers, more at a time; OpenGL can only do 1 at a time. It would indisputably be faster that's just the reality of it. As time goes on and GPUs get more powerful a renderer in Vulkan that generates cmd buffers on multiple threads would be even faster because not only are you sendin
  11. Doom doesn't use a multi-threaded renderer. Of course Vulkan isn't going to magically make things faster on it's own, it gives you the ability to do it... On OpenGL you don't directly write to command buffers so you can't split the work up between threads. Vulkan in itself does not do anything multi-threading, this is something you have to implement. Vulkan just gives you the tools to design fast multi-threaded designs that were not possible prior to. I'm not saying this is necessary, your design will be great because the game loop does not have to wait for the renderer. I'm just saying w
  12. The benefit to the multi-threaded APIs is that every thread has it's own command pool, and each thread can write to a command buffer so you can use any available threads to write to the command buffers. They are in the end submitted together, yes, but getting to the point where all command buffers are good-to-go is way faster. That's why they designed them this way. In the end, less time is spent waiting for 1 CPU thread to write all the command buffers. Nvidia has a great document about this: https://developer.nvidia.com/sites/default/files/akamai/gameworks/blog/munich/mschott_vulkan_mul
  13. Very cool, but this is still more rendering separately on a thread than multi-threaded rendering. No matter how you cut it in GL the heavy work can't be spread across multiple threads so your GPU is always bored waiting for the under-used CPU to send it work, although in GL this is as good as it's going to get which is good enough. Still like your MoltenVK idea the best. Either way it is neat to be able to control the frame rate of physics and game logic separately of rendering.
  14. Can't wait to see what the future holds for Leadwerks. You will be able to make way better use of the CPU's threads with Vulkan so that'll be fun (if it happens). Don't forget to always use RenderDoc when you're changing up the renderer. Best tool ever made, I swear... although I'm sure you've used it already
  15. Nice, I guess it makes sense they both return a function, I did not ever think that they would work together. Good to know. If std::bind is returning a std::function<void()>, it is likely you don't need to wrap the lambda in a call to std::bind() either. Keep in mind std::bind is for class members, not lambdas.
×
×
  • Create New...