reepblue

If your ok with us Sharing the video now I can start posting links on some discord channels. Idk if you wanted to wait for the campaign or not.

Looking good. I'll tell all my friends.

I'm thinking about reviving my project for Leadwerks. It's probably gonna be another year before the new engine is done, plus I have to relearn a lot of things. Maybe make it as long as Portal: The First Slice and not go back over board with visual effects.

In late 2014, I made the bold decision to focus less with Source Engine mods and pick up an actual engine I could use without legal conflicts or worrying about knowing the right people. At the time, it was like all other options were telling me to forget everything I've picked up through the years of making popular maps and mods and learn something that's completely unique to their software. CSG tools were declared too uncool, and any engine that was nice enough to support it enforced that any and all CSG objects should be removed. And there I found Leadwerks. The editor looked and acted like Valve's Hammer Editor and I could code my game in C++. While the Source Engine didn't really use modern C++ (It was more C with classes and a bunch of macros if anything anything) I felt more open to learn this than anything else at the time. Also, my internet wasn't great at the time so the small install size was a plus. Only thing that threw me off from the start was that a lot wasn't done for you. With Leadwerks, YOU are in charge of window creation and YOU are in charge of how maps are loaded and cleared. Any engine I've tried, this is done for you and they give you documentation on how their system works for you to read which I'm not a big fan of. After I shipped the Vectronic Demo in 2015, I wanted to have a nice C++ foundation framework to work on. Back then, there wasn't an Actor class to attach C++ functionality to entitles, the animation functionality was in a Lua script, and back then there was no editor materials so you had to make trigger boxes invisible. I wanted something that didn't need Lua to function and make life easier to make maps. I also wanted code for window and world handling to be automatic- to "just work", This started as the LEX template. Looking back, the LEX template is a huge mess of code that did all of that. A demo game was made for a game tournament in 2015 or 2016 (I forgot tbh) called Crawler's Den. The entire game was written in C++. During the development time, my animation code I translated from the Lua variant got adapted into the base engine which made life much easier. This also made animations faster and easier for everybody. I also took time to look into cubemap reflections which I think really pushed for the probes in 4.1. In the end, the template was unstable and hard to work with. I was often afraid to clear and load a new map due to raw pointer issues. I instead dropped the idea in favor of a similar system using Lua. Luawerks was everything I wanted LEX to be but much safer. It was more adoptable as most people only have the Standard Edition of Leadwerks. I finished the code and pushed it to the market place. However, I really wanted to make a game with C++ and at this point VR was coming online which C++ is better suited for. For the past 3 or so years, I was writing testing, scrapping and recycling code figuring out the "best" way of a system. I tried to do a translation of Luawerks to C++ but decided against it early on. I figured out why my code was crashing before, what objects I can Release when the entity deletes and overall became better at programming. However, a new engine was on the way and I didn't want to write code if I just had to redo it again. I threw the 5 bucks a month for the early subscription at the time for access of the SDK of the new engine. Back then, I thought the new engine was just going to be "Leadwerks but faster" but that wasn't the case. I made a few macro's and #ifdef's to accommodate for this. Over time however, function names were changed, renamed, or removed completely. and the new engine slowly began to do things differently than Leadwerks. It came to a point in which how my systems would work needed to be completely different for both engines. In late 2019, I decided to cut the code in half making one folder called "Core" for core app functionality. That part of the code would be translated for the new engine and tested occasionally. This is also the time when I decided to really look into input functions. The "Game" code was code I would just create as normal and worry about it converting it later a file at a time. You can play the results here. In early 2020, I started a game project using this base but shelved the project due to the fact I was not happy with getting 150fps on a simple scene. This was also pushed when I threw in a fast VR implantation and thought it was really cool (But really slow!). I also was getting random crashes with an actor over something so something was still up with my design. The new engine was coming a long so I re-structured my base yet again. As of today, after many years of work and research I now have a very clean framework that works on both Leadwerks AND the new engine. I see this as more important than ever now as I expect a lot of people are gonna come in for the new engine and be in the same position I was in 2014. At minimum, this is how your main function should look like and will compile with both engines! #include "pch.h" #include "gamewindow.h" #include "stage.h" int main(int argc, const char* argv[]) { // Create Window App auto window = CreateGameWindow("FPSGame"); // Create a stage. auto stage = CreateStage(window); stage->LoadSceneFile("Maps/start.map"); // App Loop. while (window->Closed() == false) { stage->Update(); } } This code will create a window, load a map/scene file and update accordingly. Not only for my games, but this also works really well with my current "non-game" project! I wish to go into how into this deeper at a later date, but I thought I should bring context to the last 5 years. Although I didn't get to build a game within that time, I had a blast figuring all this out. I'll leave off with screen shots. Remember. it's same code base doing the same thing for each engine! Leadwerks 4: New Engine:

Cool. If you don't have it already, I can re-save the image as an eps and SVG so you don't need subscriptionware to open it. Actually, I hope I can open this in CS6

I can't access my notifications or inbox from mobile.

Ah, maybe do window::Close(bool) and have the default be true.

That's weird and not clear. There should be window::Open() then. I'll try that, however.

Due to library conflicts, the editor is only supported with 16.04. Games however can be ran on 18.04 but it takes work. Others have ran into the issue you are having and I suggest you have a look at the Linux board. IMO, there is no need to run or test games on Linux if you are using Lua. With C++ it's different as you need to write code that GCC will accept as it can be more stubborn and lacks some features compared to MSVC. Although very cool, I don't see developing games with Leadwerks for Linux is worth it at this time. Your game night be totally unbootable when you're game actually ships. The editor is also gimped compared to it's Windows version. I suggest just using Leadwerks on Windows. The new engine has less dependencies so it should be better.

Yeah but at-least for Leadwerks 4, there isn't a event polling for the Window class. If you take the line forcing the member to be true, the window would show for a split second before closing again. What I have now works really well, it's just that I'm worried I'll not have a way to implement this in the new engine as the members of most classes are private.

Fix this so I don't have to hack it. If you're not going to fix this in Leadwerks, definitely apply this in the new engine if you didn't already! //----------------------------------------------------------------------------- // Purpose: //----------------------------------------------------------------------------- void ConsoleWindow::Update() { //if (m_pWindow->KeyHit(KEY_END) || m_pWindow->Closed()) App::Shutdown(); if (m_pWindow->Closed()) { m_pWindow->Hide(); } if (m_pWindow->GetHidden()) return; .... } //----------------------------------------------------------------------------- // Purpose: //----------------------------------------------------------------------------- void WinApp::UpdateConsoleWindow() { #if defined (USE_INPUTCOMMANDS) && (LEADWERKS_3_1) // TEMP if (m_pConsoleWindow != NULL) { m_pConsoleWindow->Update(); if (m_pWindow->KeyHit(Key::Tilde) && m_pConsoleWindow->GetEngineWindow()->GetHidden()) { // HACK: set the window's closestate to false so it stays open. m_pConsoleWindow->GetEngineWindow()->closestate = false; m_pConsoleWindow->GetEngineWindow()->Show(); } } #endif }

You also need Material/Icons if you want to use the editor. Materials/Effects/Water so water mode doesn't crash the editor and I think Scripts/Error.lua to prevent a warning message. I also include Scripts/GUI. Finally, need to tell the editor to ignore out of date projects. I created a batch file that generates this one me. If you are interested, I can share.

Try launching your game executable directly. Something might be skipped being packaged.

Keep us posted on how it works out. I got impact sounds for models, but it'll be nice to have material types for each material like the Source Engine provides by default.

You can access all downloaded DLC by just extracting the ZIP file provided under the following directory. steamapps\common\Leadwerks\DLC\Asset_430061_76561197972437720_The Zone.zip

I'd prefer you just export models as an fbx these days.

Grab the camera with a for loop, then use it's fog functions to change it dynamically.

Fog information is stored with the world/map. When a camera is created, the camera pulls the information about the fog and enables a post effect using that data. Make sure post processing is enabled and no settings are set to low.

The eye lashes needs to be its own material with the correct blend mode.

That tells me the Armature isn't assigned to the mesh properly. Check your modifiers and bones to make sure that's set up properly. Without the blend file, we can't really help you much further.

Take a look at this post for basic importing. With animation, select both the Armature and the mesh and export it as fbx 7.4. Make sure animation is selected in the export settings as well.

I personally just disable VSync setting context->Sync(false). My apps always felt a lot better overall.

Very cool. I'll be sure to give this a go. I assume the limitations of the last build still apply but it's just much faster.

AABB and these commands are what I had in-mind. virtual bool IntersectsPoint(const Vec3& p, const float radius=0);//lua virtual bool IntersectsAABB(const AABB& aabb, const float overlap=0);//lua virtual int IntersectsPlane(Plane plane);//lua virtual bool IntersectsLine(const Vec3& p0, const Vec3& p1, const float radius=0.0);//lua virtual float DistanceToPoint(const Vec3& point, const float radius=0);//lua

You should but I'm not sure if it's exposed to Lua. I can take a look at the headers tonight for you.