Crazycarpet

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.

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.

I thought this were the case too as the 0 ms iteration time seemed odd, however I used n each time it was assigned. (via print, etc) and this is still the case.. Keep in mind generally the stl library will be fast as it takes advantage of tricks and ideas that have been thought of by many people before us over years. If we think of an optimization technique, odds are it's been though of by someone before and implemented into the C++ standard.

Bad news! I found out for some reason optimizations were disabled in release mode. When I went back and enabled compiler optimizations lists took lead once again. Had a feeling something was off... the standard library containers are very, very fast for what they are. All in all though, good linked list implementation! you can certainly continue to make it faster while maintaining the added safety too. With <int>: STL Insertion: 68 LW Insertion: 69 STL Iteration: 0 LW Iteration: 15 Press any key to continue . With <MyStruct>: STL Insertion: 84 LW Insertion: 100 STL Iteration: 0 LW Iteration: 16 Press any key to continue . . . The code: auto end = stllist.end(); in place of just using stllist.end() directly in the loop can be reverted because the compiler automatically does this when optimizations are enabled.

STL iteration is faster if you do: auto _end = stllist.end(); / Obviously BEFORE the Time::GetCurrent(); Than make your loop look like this: for (auto it = stllist.begin(); it != _end; it++) Otherwise you're creating a new iterator every iteration, which normally wouldn't matter but 1 million iterator creations adds up. This is where your version implicitly has the advantage, I bet if you made the test case use a smaller sample the stl container and the original way would be faster. STL container is faster because it doesn't do your error checking which is why it's almost immeasurably faster. So far I can't poke holes in the insertion performance improvements. There is a lot of memory leaks to be fixed though if I'm reading the code correctly. Edit: Note that when compiler optimizations are enabled for speed. (O2) the whole auto _end = myList.end() thing is done by the compiler automatically.

I'd assume because the list of this type doesn't exist at the time, the concept itself is flawed. You'd need a list member, then in the constructor create a iterator for the list member. Edit: This is because the template nature. Edit#2: Same issue with the constructor, I don't know what I was thinking... this will be hard to implement look how the standard does it using the auto keyword. I'd really re-think your design before trying to make a custom container type to fight against the standard. C++ containers are the way they are for a VERY good reason. How about using (the now deprecated) std::iterator? http://en.cppreference.com/w/cpp/iterator/iterator See the Range example and how they create a custom iterator type.