Jump to content

Website refresh and Leadwerks 5

Josh

4,989 views

vr_main.jpg.35954ceccc3a0ff84cb31c21c99541bf.jpg

Back around February I started working on a website update that included the following:

  • Responsive design everywhere.
  • SSL everywhere.
  • Visual improvement of website.
  • Updated documentation system.
  • Tutorials for C++ programming basics.
  • Update forum software to new major version.
  • Forum moved to new URL.

All of that is now pretty much done.  These changes improve the online Leadwerks experience and are independent from the software itself, so it was a good idea to get them done now.

Since September I've had more time to think about Leadwerks Game Engine 5, and although I am not completely sold on Vulkan, I think it's a good plan.

Leadwerks 5 is all about performance and user experience with VR as a prime target.

Multithreaded Architecture

Separate threads for navmesh updating, physics, game logic, culling, and rendering.  The rendering thread loops at a constant 60 or 90 (for VR) frames per second regardless of what your game is doing.  This gives your game logic four times more time to run, while independently maintaining a constant framerate.  The design I have in mind will make Leadwerks 5 the fastest game engine, ever, and choosing Leadwerks for VR will be a no-brainer.

Leadwerks Editor 5

A new editor will be written in C++ using Leadwerks GUI, which will give us the same appearance on Windows, Linux, and Mac.  Functionality will be pretty close to the existing editor, but with more room to grow and a few improvements.  Because it's written in C++ parts of the editor can be exposed to Lua, and an editor API will be provided for making Lua mods and plugins.  By default, it will use a dark theme to be easy on the eyes.  A standalone script editor may be provided as well.

PBR Material System with Substance Support

The lighting model will use a more advanced lighting equation and substance PBR materials (metalness and roughness) will be loaded natively.

Shared Pointers

The reference counting system in the Object class will be replaced with C++11 shared pointers.  This gives you the performance of C++ with ease of use like a garbage-collected language.

64-bit

The engine and editor will be released as a 64-bit build only.

Game Templates

More game templates will be provided.  Fortunately we can add these now and updates for Leadwerks 5 will be minimal.

Open-Source Components

Source code to some parts of the engine and editor may be provided on the Leadwerks GitHub account.  For example, I may make a standalone open-source script editor or publish some of the engine classes for the community to play with.

Platforms

Leadwerks 5 will launch on Windows, Linux, and Mac.  The improved compatibility of Leadwerks 5 means we could do crazy things like run the editor on an iPad, but I'm going to stick with what I know sells.

Enterprise Edition

A standalone version that does not use Steam will be sold in bundles to companies that require this.

Pricing

A monthly plan may be introduced at around $5-20 per month.  Pricing for a perpetual license for the standard and pro editions would most likely be the same as now ($99-199), with a discount for early adopters / upgrades.  The enterprise version would probably be about $1000 per seat with a discount for schools.

If you found this blog interesting, please consider using the social media share buttons below to share it.



52 Comments


Recommended Comments



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!

Share this comment


Link to comment
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? :huh:
  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?

Share this comment


Link to comment

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.

Share this comment


Link to comment

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.

Share this comment


Link to comment

"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?

Share this comment


Link to comment
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.

Share this comment


Link to comment

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! :)

Share this comment


Link to comment
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.

Share this comment


Link to comment
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. ;)

Share this comment


Link to comment

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.

Share this comment


Link to comment
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. :lol:

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

 

Share this comment


Link to comment
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. :lol:

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

Share this comment


Link to comment

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.

Share this comment


Link to comment
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.

Share this comment


Link to comment

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.

Share this comment


Link to comment
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.

Share this comment


Link to comment

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.

Share this comment


Link to comment

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

Share this comment


Link to comment
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.)

Share this comment


Link to comment

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

Share this comment


Link to comment

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.

Share this comment


Link to comment

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.

Share this comment


Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...