reepblue

Anyway to draw the bounds of these in-game for debugging purposes?

He wanted to update them for them to support MSAA 0 before Josh dropped the entire idea all together. I really hope he re-releases them. What shader are you looking for?

Hey all, I just tried to compile my project for Linux. After discovering that I also needed to also include Xext, I get an error that references Josh's build path. Anyone else getting this? Edit: Turns out I didn't update the libsteam_api.so file. Still odd that it returns Josh's filepath tho..

I'll use these instead of the default ones from now on and get back to you on this. I think they look better than the Source-like dev textures, and more useful overall. When I first started using hammer, I actually used Portal's tile textures as a visual indicator of how big to make the rooms and such, and these textures kind of were made because of those times. Yeah, the normal map made it look bad, it looks way better flat anyway.

Cool, I'll give them a go. you want the dev textures to have a normal and spec map, or you want it just to use the diffuse shader for simplicity reasons? I already have the normal/spec maps when I made the original texture. Actually, nevermind, they look gross with the extra maps. Just using the diffuse is overall a better option.

I like the idea, worried on how you'll use colors tho. Also kind of reminds me of the texture I made a while back. It was mostly gray scale, and I had it's layers exported to test many shader effects.

Fixed, thanks.

Ahh I think see the issue. Correct me if I'm wrong, but since you're releasing static libs, the preprocessor can't be changed outside of your end. So in which you'd have to build two sets of libraries and I understand completely that you most likely don't want to do that for legacy. I mean, asking user's to upgrade their IDE isn't an issue, what can be an issue is if the developer is using another library that doesn't yet support 2017. Then again, 2017 RC released yesterday and Leadwerks is the only thing I know of that supports it at the moment. Real question is what other libraries will support 2017 when it comes to 4.2's release!

You can use the _msc_ver preprocessor. MSVC++ 14.0 _MSC_VER == 1900 (Visual Studio 2015) MSVC++ 12.0 _MSC_VER == 1800 (Visual Studio 2013) MSVC++ 11.0 _MSC_VER == 1700 (Visual Studio 2012) MSVC++ 10.0 _MSC_VER == 1600 (Visual Studio 2010) MSVC++ 9.0 _MSC_VER == 1500 (Visual Studio 2008) MSVC++ 8.0 _MSC_VER == 1400 (Visual Studio 2005) MSVC++ 7.1 _MSC_VER == 1310 (Visual Studio 2003) MSVC++ 7.0 _MSC_VER == 1300 MSVC++ 6.0 _MSC_VER == 1200 MSVC++ 5.0 _MSC_VER == 1100

Here is a modified Script that includes the needed dev packages to build Leadwerks. Just tried it on a fresh install of Ubuntu 16.04 and worked flawlessly. #!/bin/bash packages=(libc6:i386 libgcc1:i386 libgl1-mesa-glx:i386 libglib2.0-0:i386 libopenal1:i386 libopenal1 libstdc++6:i386 libx11-6:i386 libxxf86vm1:i386 gtk2-engines:i386 gtk2-engines-murrine:i386 unity-gtk2-module:i386 libdbusmenu-glib4:i386 mesa-common-dev libglu1-mesa-dev libopenal-dev libxft-dev libxrender-dev libtolua++5.1-dev libcurl4-openssl-dev) pkgcnt=$(dpkg -l "${packages[@]}" | grep ^ii | wc -l) if [ "$pkgcnt" -ge ${packages[#]} ]; then # Everything's installed, so exit quietly exit 0 fi cat <<EOF Leadwerks requires the following extra packages to function correctly: ${packages[*]} Do you wish to install them? [Yn] EOF while read response; do case $response in y|Y|"") sudo apt-get install ${packages[@]} ret=$? if [ $ret -eq 0 ]; then echo "Successfully installed packages." exit 0 else echo "Failed to install packages. Try again? [Yn]" fi ;; n|N) echo "Aborting as per user request." exit 1 ;; *) echo "Please enter y or n." esac done ibtolua++5.1-dev isn't necessary, but it'll allow you to generate tolua pkg files.

Nice, I'm taking that the libraries don't support 2013 anymore, right? Also great to see how fast you've managed to get it working. (Like the RC was released yesterday. lol)

Good idea! Will there still 2013 backwards compatibility atleast for the first few months? I don't want to get the new VS until it's fully released. Not a huge deal for me, but still very cool.

Cool, so any assets that aren't in the new map will be released when GCResume() is called??

Really cool man. You should think about adding in controller support. If anything, pick up a Steam Controller and bind said keys to it before you go. I haven't played with the controller in Leadwerks, so it's something you gotta look into. I wouldn't bother with native XInput as I believe that Steamworks is eventually gonna take care of that. You might feel frustrated watching others play, but watch them play until they totally give up. You might have a person or two that might not notice something, and you might consider reworking a part to make it more clear. At Dev Days, some people just wanted to watch a Dev play and talk about it, which is fine too. That reminds me of a few stories. One, before we went to Dev Days in October, The PUNT team was almost panicking to finish the demo level. It was like 10 at night and something was like really broke and the main mapper wasn't on to fix it. It was pretty funny, I was on the Discord laughing I on the other hand finished the Blue Portals Demo a week in advance. Also, while we were showing Jeep Alive and Kicking, Chamber 07 didn't work. A real disappointment, but it was just one chamber which I'm sure he played 100 times before.

That seems to work. I put it on the top. Thanks. While It'll work for 16.04, I can say I had issues with 16.10. But that isn't an LTS release so it is what it is I suppose.

Make sure app is defined in Main.lua. app:Disconnect() All honesty, I really should set you up with the newer system as the git has been deleted cause I broke it, and the entire design was bad.

This is a well known problem. It existed since the release of Leadwerks on Linux.

It's actually very cumbersome to find VS2013. You have to go through some hoops to get the web installer from Microsoft.

No, I made the icons before the 4,1 release. And my design would have been flat to match the others. I got an idea for a design that'll fit. It'll pretty much be the same thing, just match the rest of the icons.

If the workshop button is actually gonna stay this time, I'll be happy to make an icon for that before 4.2 ships. Also, great to hear. I hope this will later mean more things can be on the workshop in the future.

Technically, people do with the branch system already in play. Issue is that in-order to switch branches, you'd need to redownload the differences. What I did was every time a build gets officially released, I backup all the contents of the Steam depot and place it under Leadwerks/Archive, then go to the beta branch to play with new features. (I'm not working on an actual game at the moment, or else I'd stick with the most stable.) When I notice that something is broken and it's a real bother like the libs not working anymore or something; depending on the update, I can ether redirect the LeadwerksLib path and keep the beta tools to wait for an official fix or backup the contents of the beta and restore the dlls and exe. Not really concern about scripts/shaders, but that depends on the update. Yeah, what I do is prob not ideal, and something a typical user would not need or do. However the idea of having the stable and beta branches locally would be nice, especially with the ones with slow or limited Internet.

Wait for the new GUI.

You could also make it a "Tool App" in Steamworks and it'll get treated as a separate app. Only thing is that it'll be under "Tools." Just a thought when I left as going back and forth between builds is a bit of a hassle. Not everyone is going to have an archive of previous builds like I do.

I'm also making something that others can use, so It should not conflict too much with the standard API and how Leadwerks is setup out of the box!

After I've returned from Steam Dev Days, I caught a terrible cold, so my first week home was unproductive when it came to LEX or Blue Portals. But besides that, I had a great time! I mentioned briefly in my last blog post before I went that I was giving LEX some reorganizing and defragmenting. This blog post, I'm going to go more into detail. LEX2 has a lot of things going for it. The developer console is really handy, the AssetManager prevents crashes and has the ability to pre-loads things for you and the PostStart() command for entities allows you to make entities do things RIGHT AFTER the map loads instead of during the loading process. All very helpful! Crawler's Den taught me a lot about what I was doing with LEX2, and where I should go. I designed it to be more Lua friendly than the initial release. but also allowed easy C++ classes to be made. Crawler's Den had the challenge of "Make a whole game in Leadwerks using nothing but C++". I know it was do-able, but how hard could it be? Leadwerks today isn't really as optimized to be developed using C++ as it is to Lua. I had to do go through a lot of hoops with somethings that could have been done easily if I just wrote the game in Lua. For instance, making C++ classes required more thought, and to attach my C++ puppeteers (actors) to entities in the editor, I had to make a Lua script that acted like a Hammer fgd file to sync it's keyvalues, inputs and outputs. Oh and on top of that, I had to make sure that each puppeteer got deleted properly. All and all, it was do-able, just not ideal at all! I'm switching back to be more focused to making games with Lua for now. I started by making a new project and re-writing the console system to be more flexible. Instead of defining all ConCommands in one cpp file, ConCommands can be defined anywhere now like: static void ConCommand_SayHi(vector parameters) { System::Print("Hi") } static ConCommand sayhi("sayhi", ConCommand_SayHi); With this system, it may be possible to make your own console commands via lua, but I'd have to look into it. My ExSystem Class is derived from Leadwerks System Class, and it's how to talk to the application directly. It handles the dev console, pausing, resuming, and other states that the application might be in. 90% of ExSystem can be called from Lua. The Developer console is much more powerful than it ever was. You can now make entities fire script functions or outputs by the entity name, or using !picker when looking at it. fire <entityname> <functionname> There are also a lot of Utility functions from the previous codebase. One of my favorites is this function. inline Leadwerks::Entity* UTIL_PickFromCamera(int pDistance, int pCollisionType=0, float pRadius=0) { Leadwerks::PickInfo pickinfo = Leadwerks::PickInfo(); Leadwerks::Vec3 p0 = UTIL_GetActiveCamera()->GetPosition(true); Leadwerks::Vec3 p1 = Leadwerks::Transform::Point(0, 0, pDistance, UTIL_GetActiveCamera(), NULL); if (UTIL_GetActiveCamera()->world->Pick(p0, p1, pickinfo, pRadius, false, pCollisionType)) { return pickinfo.entity; } return nullptr; } I also made the settings.config file store in the AppData folder instead of the game's root. While I never had any permission issues with the old way, still best to have the user's settings there. I merged both the WindowManager and ContextManager to be one class; There is just a WindowManager now. There was no point to have the context be managed in it's own class; definitely now since I took out my UI code I had in there for the console drawing. I also fixed Screenshots being properly placed in it's own Directory in the game's folder! The World Manager is what got the most fat reduced. Before I had a great chunk of code that was ether commented or ifdef'd out. For example, I had old code for my cubemap factory before the Probes where a thing, and other checks that in the long run might cause more problems later. The World Manager is responsible that when a user want's to load a map, a world get's created or cleared, and PostStart is fired on all entities if they have a script. If the user want's to go back to the menu, the world manager clears, and then releases the world. Something that was 913 lines got reduced to 260, and it does pretty much the exact same thing. I removed the InputManager as at Dev Days I learned that that Steam will later be able to handle that for you, not exclusive to the Steam Controller. Also, the implementation was really confusing and tricky. Finally, I removed a bunch of classes that are no longer needed including the Puppeteer class as the focus is now Lua. I want to keep the scope of things small right now. All you need to convert a game using the standard executables to the LEX is to replace the 2 executables and add this self explanatory Lua script that'll override main.lua. --This function will be called once when the program starts function App:Start() return true end --This function will be called right after when the program starts. function App:PostStart() end --This is our main program loop and will be called continuously until the program ends function App:Loop() return true end --This function is called once when the program pauses time. function App:onpause() end --This function is called once when the program resumes time. function App:onresume() end --This function is called while the program is loading a map. (This is where you draw your loading screen!) function App:OnMapLoad() end --This function is called when the program finished loading a map. function App:OnPostMapLoad() end --This function is called when the program disconnected from a map. function App:OnDisconnect() end --This function is called when the program closes. function App:OnShutdown() end Since it's really those three files that need to be shipped for the product to work, I can use the the standard Leadwerks Project Manager again. I don't plan on releasing the source code at this time. Maybe when making C++ games becomes more streamlined I'll re-integrate my C++ systems. There are still somethings to do though: Integrate the dev console to the Leadwerks GUI when that's fully done. The CMD using Cin approach that I'm using now is kind of bad. Play with the app a few hours a day, fix bugs, build on it a little each week. Find a good method in distribution, and keeping people up to date. In the future, I also hope to add more classes you can use while making gameplay objects. Somethings like a Beam class, and such to make things much more simpler. I also hacked together this shader that takes in roughness and ao sheets along with the diffuse, normal and spec. My artist gave me some textures right from Mamoset and my goal was to import them to Leadwerks as close as I could. I think they came out really well.