Crazycarpet

I get why you'd want to do this but would this not be the same thing in principal because your "GameEngine" object would nwo be the bound state? This would have the same implications n a multithreaded environment as GetCurrent() because like the latter, only one thread could write to this "GameEngine" state at a time. Reading is always thread safe. I guess it doesn't matter because users don't have to play with that stuff, I just figure why not make life easier for yourself?

Leadwerks doesn't come with an underwater shader, but Shadmar released one! I'm not sure what the terms of licensing would be but he posted this link on one of gamecreator's threads. https://www.leadwerks.com/community/applications/core/interface/file/attachment.php?id=9778

So what about bound-states like your GraphicsDriver and what not? Will you remove these? I feel like that'd be a slightly harder one to remove cause it's require lots of design changes, but on the flip side it may not be neccesary to remove it because you won't have the main thread writing to the GraphicsDriver at any point. (I don't think.) I'm more asking, do you plan to remove ALL bound states?

Send button looks nice though, plus sometimes you find yourself looking around for say in the future a server IP or something in another menu before finishing whatever you're typing. (Example: In source sometimes you'll type "connect " then go find the IP and paste it in.)

Looks like Luawerks is coming along nicely. Good work Reepblue. The above code is kind of ugly because it doesn't handle errors so if your code errors the application crashes. Would like to find a way around this in the near future. Also it has a trailing space, which shouldn't hurt anything.

Nice! never heard of GitLab til just now, looks great. I like that it has a major feature Bitbucket is missing, that is the ability to search through your source code using the search bar on the website... Will most likely switch over.

Well that's what I assumed but he said that the line it errors on is the one where he creates the window... that error isn't even possible on that specific line. Good to know though, going to wait to update to 4.4 beta.

I know it's a long shot, but is there even the slightest chance that the character is somehow moving in a negative direction along the Z axis (Moving away from the camera) effectively missing the platform? Doesn't look like this is the case or anything, figured I'd throw it out there.

"Window" or "window" it's certainly not "window" because you're assigning the global variable and never reading from it... big difference. Josh probably simply forgot to expose the Window class to Lua.

Doesn't this just give "Error failed to..." every time? you're printing the error when the Interpreter::ExecuteFile method returns true.. But yeah Josh is right, Entity::SetScript(const std::string& path); is what you're looking for.

Nice! any news on any of the physics bugs and if they're fixed?

Well you are definitely right, I mean they are certainly easier to write because Vulkan puts most of the responsibility of memory management on the developer I didn't mean to overlook that. What I more meant in regards to shaders is that if you look at the way AMD/Intel/Nvidia drives handle glsl shaders it's hugely different... with Nvidia's implementation clearly handling shader optimization and what not the best... With Vulkan their drivers will handle the spir-v bytecode more or less in the same way. Long story short Vulkan gives the developer a lot more opportunity to capitalize on lowering the amount of allocations/deallocations, and concurrent command buffer writing... that handy little pNext variable in the structs also makes implementing things like Nvidia's bindless textures or AMD's rasterization order easily implemented with ~6 lines of code a piece. (I know it's easy in OpenGL as well, but not that easy!) Can you link me to a driver implementation that multithreads anything in OpenGL? I don't see how they would accomplish this "behind the scenes" as the global states in OpenGL would prevent this... that's why you need a command pool per thread in Vulkan... OpenGL is an API that really doesn't look like it'd be able to accomplish multi-threading and especially not lock-less multi-threading. (When I say lock-less of course I'm excluding the single lock that ways for all the threads to report-back.) I'm not argueing that you need to "synchronise" you have to wait for all threads to complete their jobs yes, but that doesn't by ANY means suggest that this won't give a performance gain... you get immense performance gains from this method, in fact Unity reported in their multithreaded Vulkan renderer release (that pretty much only optimizing through this method) 60 percent FPS gains out-of-box.

On the contrary, this gives more performance benefits than anything else you can do in Vulkan. Yes, they have to be submitted all at once through a primary command buffer... but it's not about that, it's about how long it takes to generate the sub-command buffers before being able to submit them, instead of writing the drawing for 1 entity at a time, you can write up to as many free threads as you have at once. Threads operate for approx. the same length as eachother per frame.... Instead of having 1 primary command buffer and writing the commands 1 at a time, you're writing commands <free thread #> at a time, then you get to submit the end result much, much sooner... Instead of your GPU being bored and 1 CPU core working hard, all your free CPU cores work hard and your GPU has a lot of work to do, which is great! You MUST have a command pool per thread, and when you generate cmd buffers you assign them to the pool of the thread you're working in, that's just the way the Vulkan API is designed. We have no say over that, this design is what allows us to do this without locks. Don't take my word for it, Valve wrote one of their write-ups on how they came up with design, Nvidia and many others follow it as well. As for the drivers for Vulkan, they're only easier to write because spir-v is a binary language, where as GLSL and some other shading languages may interpret the standards differently. Khronos provided a new verison of glslang that ensures your GLSL is conformant and compiles it to binary. I'd like to stress that Doom is a horrible example of a Vulkan implementation... they don't take advantage of any of the custom-allocator options that Vulkan provides, nor the easy multithreading options it provides. It was a poor implementation that expected to drop in a young API and see improved performance. As for Nvidia's performance on Vulkan, this will come... AMD had horrible shader optimization which was a big pitfall in their GL drivers, this is not going to be a problem in Vulkan that's why AMD cards perform well... Nvidia always makes great drivers just give them time.

Well, if it occurs on the AI and events map you most likely do have a camera in your scene. What kind of video card do you have have? Are you graphics drivers up to date? If you have AVG anti virus this can result in a black screen til it completes a quick scan. These are all the places I'd start looking, but if your problems persist post some information about your hardware, and what operating system you're using; maybe we can come up with some better ideas as to what might be going on.

C# is lame as a scripting language anyways, who wants a strongly typed language for your scripting language? (And I'm saying that as a C# lover, I use it for all my external tools!) Give Lua a go! it's fast (as LE implements LuaJIT), flexible, and extremely dynamic I'm sure you'll love it! It also is very easy to communicate between Lua and C++ so you can make blazing fast C++ code and expose it for easy use in Lua in the future. If you're new to Lua check out the Leadwerks tutorials by hitting the "Learn" button at the top, I hear the tutorials are quite well done. Plus, learning new languages is always fun!

This would certainly be nice, however it'd make the need for the project manger to add PATH variables for windows users to the project's bin folder. Simply putting it beside the exe makes it much easier for Windows to find. With Lua you can add search directories to require, etc by modifying package.cpath. When mollifying this ! represents the working directory of the project and ? represents what you type into require. I.E in: !\\Bin\\? when require("test") is ran ! would be the working directory. (Generally the exe's directory.) ? would be "test"

Just to add, this is called VSync, what it does is prevents your FPS from exceeding your monitors refresh rate to stop tearing.

Couldn't you set the entities alpha to 0? It' be nice if the renderer didn't even try to draw entities with an alpha color of 0.

Yeah, but Khronos scrapped OpenGL NG for Vulkan lol... and even if Vulkans not the future somethings going to have to replace OpenGL soon. Most engines are adding/have added support for when it's ready, it's simply not ready. Apples lack of support is kind of disappointing, but only weeks after they announced they aren't supporting it MoltenGL came out to allow Vulkan to work on Apple products. The community support is huge. ANYWAYS enough thread-highjacking (P.S: Roblox, Dota2, Doom, and vkQuake use Vulkan already!) Does LE use direct state access right now? If not do you plan on changing to use it so you don't have to constantly bind different states?

It is cross-platform totally... Khronos group doesn't make claims just to make them. They did an amazing job with OpenGL and an even better one with Vulkan. It's advantage over DX12 is the cross-platform nature. However, DX12 is probably faster because it's single platform support allows them to take advantage of windows only features to give games that little boost. Vulkan's still young and not ready to replace anything yet. I certainly would not make an engine with it right now.as the drivers are very young. That being said support for Vulkans growing faster than anyone thought, noone thought Intel would release drivers til 2018, they came out in 2016. That being said it is certainly a better idea to make the engine on OpenGL because Vulkan isn't "mature' yet. The day it is ready you can always make a renderer then. All I'm saying is you can't dismiss the purpose of Vulkan, it solves every problem that limits OpenGL on modern hardware and was improved/added to by many of the biggest name game companies in the world including Valve, Blizzard, Microsoft, Unity, Oculus, HTC, and hundreds of others. These people know what problems we face today, and how to solve them! Out of curiosity do you plan on using OpenGL's newly supported direct state access? Seems like you could make things a lot faster not having to bind/change global states all the time.

All cards get a big boost in Vulkan when you implement a multi-threaded renderer... Vulkan lacks any global states and allows for a command pool to contain command buffers on separate threads. Because of this the threads never have to wait behind a lock to wait for access to some data to become available. That being said, OpenGL is much much easier to implement and it is certainly fast enough. Your idea is definitely a good one too for the culling & rendering to be in separate threads. Still though it is no match for Vulkan and what you can do with it. Keep in mind Khronos designed Vulkan with multithreading and VR as the primary goal. A programmer can make a renderer with Vulkan that never locks a mutex by simply having 1 (or 2) command pools per thread. Sounds like some good ideas though, excited to see what you come up with. Edit: I don't think it's fair to say Vulkan is a niche... Khronos made Vulkan as a successor to OpenGL solely for the purposes of multi-threading and VR because OpenGL just simply isn't capable of allowing so much of the work to be handled by separate threads. However, the drivers are certainly still young... but I mean OpenGL has been around for so long of course the drivers will be better and more stable, this will come. Vulkan is here and here to stay. Still though, OpenGL is evolving every day and more than capable of creating high performance games.

Be careful with that many threads! but is there any specific reason you decided against Vulkan? What parts of the rendering do you plan on letting threads handle with OpenGL? i never knew there was effective ways of threading in GL. For example in a Vulkan implementation, you'd do something like allow all available threads to generate secondary command buffers for the meshes in the scene, then execute a primary command buffer when all the secondary cmd buffers have been generated. You really should profile a lot before starting to multithread that heavily, if you look at the update, and render time in Leadwerks... the update time is generally nothing. The render time is what's killing us.

Not a dumb question, because LE projects still get created with optimizations disabled in release mode!! Fix coming soon?

#include "App.h" #include <list> using namespace Leadwerks; template <typename T> class TestTemplate { public: int myInt; std::list<T> myList; /*Another comment*/ }; // A comment /* static void Stuff() { }*/ int main(int argc, const char *argv[]) { #ifdef USESTUF auto obj = new TestTemplate; #endif return 0; } Really nice formatting.

I don't think this is necessary, and the only way I know how to do that has been deprecated in C++ 17... so I'd advise against it. (Inheriting from std::template). Your LinkedList class is more than fast enough, and I'm sure can be made faster over time as you think of newer, more clever ways to optimize. (Maybe allocate more memory in chunks, then only expand the container when you reach this limit.) Either way, this is fast enough for what you want to use it for... keep in mind stl container is ~twice as fast with 1 million elements. If you're storing a few thousands pointers the speed difference really is negligible. Pointers are smaller yet than the integers you tested with.