Ultra Software Company Blog

That is a lot of good news! Got a few questions/remarks:

1. Why 64 bit only and no more 32 bit? I know most players have a 64 bit machine, but is it hard to maintain a 32 bit version as well?
2. Will we be able to make our own threads? Currently the Leadwerks::Thread function doesn't allow me to bind class functions. I'd like to make one for things like networking and AI.
3. I really like the smart pointer integration. Was one of the few things that I felt missing.
4. Plans for Leadwerks after the 5.0 release? VR optimization or also some other topics you want to tackle?
5. Plans for the Leadwerks Game Launcher? C++ games support?
6. Is the App.h/cpp going to be removed, where main.cpp will now be the base of your project?
7. Leadwerks 5.0 when?

I really like all of these changes. Going into the right direction. I'll be one of the early adopters!

1 minute ago, Evayr said:

That is a lot of good news! Got a few questions/remarks:

1. Why 64 bit only and no more 32 bit? I know most players have a 64 bit machine, but is it hard to maintain a 32 bit version as well?
2. Will we be able to make our own threads? Currently the Leadwerks::Thread function doesn't allow me to bind class functions. I'd like to make one for things like networking and AI.
3. I really like the smart pointer integration. Was one of the few things that I felt missing.
4. Plans for Leadwerks after the 5.0 release? VR optimization or also some other topics you want to tackle?
5. Plans for the Leadwerks Game Launcher? C++ games support?
6. Is the App.h/cpp going to be removed, where main.cpp will now be the base of your project?
7. Leadwerks 5.0 when?

I really like all of these changes. Going into the right direction. I'll be one of the early adopters!

1. 32-bit operating systems are pretty rare nowadays (about 6% of Windows users): http://store.steampowered.com/hwsurvey/
2. You can make your own threads right now.  You can pass an object to the thread and call its functions.  Do you have any suggestions on how to improve this?  I don't expect the user to do a lot of multithread programming because it's really hard and if I set mutexes for every command it would end up being just as slow as a single thread.  But yeah, networking is one example where it is appropriate.
3. Leadwerks 3 began development before C++11 was available, so it was never designed for shared pointers.
4. After?
5. Game Launcher has been stalled because I need to improve the way game thumbnails are loaded.  Right now it pauses while the entire collection of games has their thumbnails downloaded, resized, and cached.  Leadwerks GUI needs to be completed for this as well.
6. App class and script are being removed in 4.4.  Docs are already updated.
7. When it's done.  Maybe another Kickstarter should be done for this?

Oh yeah, I don't see Game Launcher supporting C++ games in the future.  With Steam Direct you may not even need this, unless it is just a way to get your game in front of more people.  I'm not sure how Steam Direct will affect things, if it ever happens.

Unlike updates to version 3 and 4 Leadwerks 5 will introduce changes to the API.  However, it's not going to be a whole new engine written from scratch, more a reconfiguration of what we have.

Thanks for the update and I just say GO GO GO

 

"32-bit operating systems are pretty rare nowadays (about 6% of Windows users)"  haha so are Linux users: 0.76%.  But I'm just giving you a hard time.  I know it's different for you.

Very interesting developments.  So to be clear, Leadwerks 5 will be a separate product we need to purchase?  Will there be an upgrade option from 4 at a discount?

11 minutes ago, gamecreator said:

"32-bit operating systems are pretty rare nowadays (about 6% of Windows users)"  haha so are Linux users: 0.76%.  But I'm just giving you a hard time.  I know it's different for you.

Very interesting developments.  So to be clear, Leadwerks 5 will be a separate product we need to purchase?  Will there be an upgrade option from 4 at a discount?

There will be some kind of discount option for upgrades or possibly early adopters.

Really cool news! I've been dropping by for the past few months as the site has been slow. I like what I've read, happy that a "pay up front" option is still available, as it's one of the pluses of Leadwerks for me. Not a big fan of subscription-ware, but I understand why it's there.

A question though:

Since Leadwerks 5 is gonna be different when it comes to API, and it being a separate product than what we have now, what's gonna happen to 4.3/4.4 support? Because I suspect that the current Steam app is gonna be Leadwerks 4, and unless you request to take down the app, people might still buy and use the current version while 5 is well out. I know for 2.x, you moved all documentation to a legacy page, do you plan to do that? It's something that's not worth getting worried about; I know, just was curious on your thoughts. 

Also, is 4.4 still gonna be a thing?

I wish you the best and looking forward to the future, looking forward to your future development blogs too. I'll be happy to early-adopt when available!

15 minutes ago, reepblue said:

Really cool news! I've been dropping by for the past few months as the site has been slow. I like what I've read, happy that a "pay up front" option is still available, as it's one of the pluses of Leadwerks for me. Not a big fan of subscription-ware, but I understand why it's there.

A question though:

Since Leadwerks 5 is gonna be different when it comes to API, and it being a separate product than what we have now, what's gonna happen to 4.3/4.4 support? Because I suspect that the current Steam app is gonna be Leadwerks 4, and unless you request to take down the app, people might still buy and use the current version while 5 is well out. I know for 2.x, you moved all documentation to a legacy page, do you plan to do that? It's something that's not worth getting worried about; I know, just was curious on your thoughts. 

Also, is 4.4 still gonna be a thing?

I wish you the best and looking forward to the future, looking forward to your future development blogs too. I'll be happy to early-adopt when available!

Version 4 documentation will be moved to a folder like "learn/4" and left there, with a robots.txt file to tell Google not to cache the page.  The final version will point the user to that location.  Leadwerks Game Engine on Steam will be renamed to Leadwerks Game Engine 4 and will continue to be sold.

Version 4.4 is coming out this summer.  Mind you, we will all be using 4.x for a while.  The stuff I described here is a big task.

Version 5 will make some breaks with how 4 works, but it's not a whole new engine and the same code will work with small changes.  The two things I can think of right now are shared pointers and I want to add a "surface builder" class, and stop storing surface data in system memory.  Hooks will completely go away, as the Actor class works better for this and the editor will no longer need C-style function pointers.  Hopefully all or most Lua code will work without any changes, but I am not sure yet.  Version 4 to 5 will be much less of a jump than 2 to 3 was.

Eventually, Game Launcher will probably use both a 4.x and 5.x executable and it will just choose the right EXE to run.

11 minutes ago, Josh said:

Version 4.4 is coming out this summer.  Mind you, we will all be using 4.x for a while.  The stuff I described here is a big task.

Alright, sounds good! I was getting a feeling that the current version was gonna "rot" until you said that! Also nice to hear that 4 and 5+ are gonna co-exist in a way. 

Again, interested to see what will come, but take your time. We want the best.

Does the enterprise version include source code? Or is that no longer an option? Is this also a yearly license?

I like the idea of a subscription. Granted it will cost me more overall, but I think it will allow for more updates to the engine. Would allow you to grow leadwerks better.

I'm super excited about multi-threaded support. I know asset loading is a frustration section for me as it locks up the UI.

I'm also super excited about the idea of plugins and open source support. 

As far as SharedPointers, will there be a backwards compatibility API for legacy code? My source is getting pretty large TBH, it would be difficult to replace everything to shared pointers that interacted with Leadwerks specifically. Which is why I haven't really adopted the Actor class as well.

5 minutes ago, martyj said:

Does the enterprise version include source code? Or is that no longer an option? Is this also a yearly license?

I like the idea of a subscription. Granted it will cost me more overall, but I think it will allow for more updates to the engine. Would allow you to grow leadwerks better.

I'm super excited about multi-threaded support. I know asset loading is a frustration section for me as it locks up the UI.

I'm also super excited about the idea of plugins and open source support. 

As far as SharedPointers, will there be a backwards compatibility API for legacy code? My source is getting pretty large TBH, it would be difficult to replace everything to shared pointers that interacted with Leadwerks specifically. Which is why I haven't really adopted the Actor class as well.

A source code license will be and is available, but that is a very big cost.

On my end, the subscription model is also very appealing, even if it were to make less money overall it is still better to have reliable monthly income.  I'm sure you can think of a lot of products who had the genius idea to promise their users "free upgrades for life" and are no longer around.

Hmmmm, Model::LoadASync()?

You can probably use typedefs or auto to make your code forward-compatible, but again this is still in the research phase and I can't say for sure:

auto model = Model::Box();
model->SetPosition(1,2,3);// shared pointers still act like a pointer

 

11 minutes ago, Josh said:

On my end, the subscription model is also very appealing, even if it were to make less money overall it is still better to have reliable monthly income.  I'm sure you can think of a lot of products who had the genius idea to promise their users "free upgrades for life" and are no longer around.

As long as you keep the full price option, I'm all for the addition of a subscription option.

I am all ears about extending the editor with plugins/mods. Will this allow us to create our own windows/tabs, run scripts in the editor? 

The lack of ability to extend the editor is the most important reason for me to not use Leadwerks for any large project and just mainly to try stuff out. That could be a real game changer.

As for the standalone script editor, ever had a look at Visual studio code? Crossplatform, lightweight, easy creation of custom tools etv. With the current documentation system you could generate a plugin for visual studio that lets you create an entire intellisense for Leadwerks + Lua.

3 minutes ago, AggrorJorn said:

I am all ears about extending the editor with plugins/mods. Will this allow us to create our own windows/tabs, run scripts in the editor? 

The lack of ability to extend the editor is the most important reason for me to not use Leadwerks for any large project and just mainly to try stuff out. That could be a real game changer.

As for the standalone script editor, ever had a look at Visual studio code? Crossplatform, lightweight, easy creation of custom tools etv. With the current documentation system you could generate a plugin for visual studio that lets you create an entire intellisense for Leadwerks + Lua.

People love plugin systems when they first come out and hate them when an update makes all their plugins incompatible..  So keep in mind there are limitations to how useful they can be.  I am not 100% sure how it will work, but an editor API would allow Lua to add new windows and stuff, I think.

I would probably use the same code in the main editor and just separate it out for the standalone.  This is still going to use Scintilla, but Scintilla with C++ is much simpler than trying to make it run with BlitzMax.  It's really a miracle @klepto2 was even able to figure that out.

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.

6 minutes ago, Crazycarpet said:

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.

Culling and rendering will be separate threads.  One will gather up batches of surfaces to be rendered, and the other thread will continuously rendering them.  This is basically how command buffer APIs work, as I understand it.  I don't think Vulkan will offer a big performance increase over the architecture I have in mind.  It's only AMD cards that get a significant boost, and OpenGL is still the only cross-platform graphics API for Windows, Mac, and Linux.

The niche-ness of Vulkan does not make me feel good about the drivers.  The only game I have that supports it crashes a lot (Doom).  There's just not enough there to make me want to jump on that bandwagon yet.

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.

Is the gmf/mdl file format going to continue?

Looking forward to Leadwerks 5  ... some questions though:

1. Can you use Leadwerks GUI in your game or will it only be for the editor?

2. Will Windows, Linux, and Mac support be released at the same time? 

Thanks for the update

7 minutes ago, Einlander said:

Is the gmf/mdl file format going to continue?

No reason to change that.

1 minute ago, codeape said:

Looking forward to Leadwerks 5  ... some questions though:

1. Can you use Leadwerks GUI in your game or will it only be for the editor?

2. Will Windows, Linux, and Mac support be released at the same time? 

Thanks for the update

1. Leadwerks GUI is being developed for version 4.4.  It works in a 3D graphics context or directly on a window using OS drawing commands.  I had to dig deep into XRender to figure it out.
2. Yes.  (The editor will be a big improvement for Linux users especially.)

Also this lock free c++ queue could probably come in handy for Leadwerks (BSD license): http://moodycamel.com/blog/2014/a-fast-general-purpose-lock-free-queue-for-c++

Oh yeah, and all models, prefabs, maps, physics shapes, textures, materials, shaders, and post-processing effects will still work just fine with no changes.

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.

A lot of those guys jump on anything new just so their name can be associated with it in case it works out.  They also said OUYA was the future and we were all going to be playing game consoles that were made out of a thumb drive.

Notice there are no Vulkan-exclusive games in existence.  It's always just an experimental feature people add on to another renderer.

Microsoft has a solid working API that reliably does everything Vulkan does, except run on Linux, and Apple is not interested in Vulkan.  So really I would say DX12 is the future for a long time.  We will see.