reepblue

This is a good step into turning the mouse look into an axis which can be set via an action binding system. You can also make a multiplier value for sensitivity. Thanks. Also, hopefully you got hold of an XInput device since the initial implementation of controller support.

What is it exactly you're trying to do? You want to expose functions with glue code? Sorry for being so late, this just recently grabbed my attention.

Gonna be honest, I was doing something the past week and it was really nice to youtube all my questions.

All jokes aside, looks like a modern light theme.

It'll probably be nice to have for the level editor too at some point.

It all looks super!

UAK is made with a mouse and keyboard in-mind. It's really made to be used for applications that use a mouse and keyboard.

Really good. It seems you're almost at the finish line. Speaking of what's left to do, have you decided on vs project generation? Or are you going to do what you did in Leadwerks? (Copy solutions, rename a string macro.)

The arrows and check boxes use vector graphics. This is why you need to load the svg plugin. Hopefully this was fixed/will be before release.

It's been a year and a half, how did I miss this?

The beta is broken and Josh has been using his time with the new engine. You can always zip package the game yourself of you need the latest beta for VR.

There is a balance. Much like Slippery Brick said, reviews are the key. I think allowing for honest takes is better than paying people to talk about how wonderful something is. The Cherno is good cause he does C++ tutorials and GamesFromScratch is also good because he covers game development tools. (He did mention Leadwerks in the past.) I also wish to push videos with UAK and the new engine although I'm not really booming with charisma. I have a lot of Source Engine users following me that I'm sure would be very interested.

You should make it very specific what is and isn't ok. I'm sure people will want to create their own tools to fit their needs, but I understand you not having competition/confliction with the upcoming editor. I think you can ask Games from scratch and others to get the word out and do quick run downs. I wouldn't really force this as people tend to hate the shilling on that platform. Overall the choice is there's and I think the tutorials and showcases will come naturally if the product is good.

The issue is that instead of a few major forums and news sites, communities are now thousands of various discord servers. I posted it in the few I was in but that's only 0.0001%. I think once you give us the ok to start sharing public videos of the new engine/app kit on Youtube and such, more people will stumble across it. I'm sure people making UAK tutorials will help with sales.

Or you can use Premake/CMake and have all projects point to where the SDK is installed.

You can manipulate the character controllers values if you're using C++. Check Entity.h or Character Controller.h as I'm not near my PC atm.

Yeah, this has been broke for over a year. It would be nice to have 4.6 wrapped up before the release of the new engine.

And the marketplace as an alternative download. You do good work and we don't want your stuff to get lost. ?

It's part of the new engine but it's going to also be its own thing.

Been sharing it around and the only criticism I'm seeing is that the cross platform stretch goal is too high.

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