reepblue

Those screens man, I feel like if that was LE3, it would run at 35-40fps, and the frustum culling problem (that I at least seem to have) would ruin immersion. I debate with myself if the issue is us not knowing how to optimize the engine on our side, or the internal workings of the engine. Over the last page, Josh gave us hints on how to improve our games, but I feel that wouldn't be enough. I'll have to see when I start the project again. (Been busy). @YouGroove: Yes, Leadwerks right now seems to be more aimed at the game designer/programmer, than artists. I still think a simple shader editor would help a lot though.

Quite a portfolio you have there, I recommend posting that link on the Promotion board. If you mean generously give me something for free, I suggest you PM me about that unless you wish to give everyone here a free model.

It should be noted that some performance issues such as this one are driver side, and the Leadwerks Dev Team can't really fix alone. I've played around with the AI and Events showcase map, and it ran fine as expected after I turned all lights that were buffered into Static+Dynamic. There is a framerate drop going around the first corner (dips down to 27fps) and while a crawler is moving, (I made them chase me all over the map, and I got my frames back when they died) but the shadow mode is correctly set to Dynamic. So that must be ether navigation side, or something in the script/animations; haven't not really looked. So right now, just follow this guideline on shadow modes, don't use buffered lights, and while shelling out your map, just set the ambient light to a bright color (almost fullbright) with no lights so you can see what actually impacts performance as you develop your map and scripts. Having deferred lights are great, but you still need to be careful. I've still yet to figure out why the Vectronic Demo runs so poorly still, but that might be because of my garbage ways of doing things, I dunno. Again this was with one map, so I gonna do a bit more testing with lights models and such. When I go back to Vectronic, I'll make sure to note what things make the game stutter. Sorry that this topic derailed to the max.

Check to see if your pointlights have any shadows enabled. Disabling them should give you some frames back. Yeah, even I am not satisfied with how the Vectronic Demo came out in performance. Of course, looking back, there was somethings I've should have done better, but overall I kind of struggled keeping my framerate at 60fps. I've went back in my demo map, and made sure all my lights followed this guideline, and still my 3 room demo hits the high 40's, and I noticed the framerate was higher in a packaged build with 3.5. (I still got that build if you want it Josh!) I'm not saying they should roll back, and have you bake the lighting again like in 3.0; but I feel like if developers could bake the lighting, and use deferred lighting if needed, games would overall run better, and the shadows wouldn't fade out at a distance, or do stuff like this. But I assume that you can't/would be a chore to have the best of both worlds. From how Josh put's it, Leadwerks and games developed on Leadwerks are targeted at people who are interested in indie experiment games, but to me, it feels like you need a PC that a "Yo Bro Shooter" would have to have the best experience with the engine. I think a higher priority than PBR or substance support is better optimization. I'm gonna run a few tests to see what causes the slowdown mostly. (Whether be shadows, amount of objects, amount of lights, polys, etc). There is no doubt that Leadwerks needs more games for it. If there was a at least few top notch quality games that looked and ran awesome, Leadwerks would gain popularity and more people would be using it (or know more about it to spell it correctly!) If developers are having issues actually creating their game with performance/workflow issues, ether no games will be developed for it, or the engine will be known for low quality "games". If you know how to code shaders, your games today can look really nice, but that's overall the hardest, and most complicated part of the entire engine. I really hate to open this can of worms, but I think it's important for the product as a whole for people to speak up and openly talk about the difficulties of using Leadwerks beyond "Oh, I can't do X, Does not have Y, bad engine". If you can't get your shelled out map (a map in nothing but dev textures and little models) to play well at a good framerate, and you went through your code through a fine comb, you can forget about how cool you wanna make it look; it'll still run like trash! Leadwerks has so much future potential, I feel like a full update on improvements and optimization would be richer than an update with a new feature or two.

If Google translate is right about your question, you can copy the template into your project, then rename everything $PROJECT_NAME with the title of your game. This would be the exe's and the title value in main.lua.

That's really strange, I'd thought it would be the opposite.

Gonna go through some of YouGroove's points. 1 - Josh said that they are putting research into how to make this better. 2 - Maybe this will come with the Vegetation system in 3.7, but I doubt it. I'd put it in the suggestion box if you really want it. 3 - In the LE library, there are headers for UI elements such as buttons, sliders, and such. Josh said that these will be added slowly. 3b- OH MY GOD THIS! I understand that OpenGL is a different animal than DirectX, but it's just silly that a mid-range PC like mine can run UE4 at 60fps while it looks like a Hollywood blockbuster film, while the LE showcase map or the Vectronic Demo dips to 45fps at times, and it looks like the Source Engine! (Not that's a bad thing) This really needs to be fixed/optimized better, no one should have a GTX 980 just to play any LE game at 60fps. 4- I think this is because Josh want's a streamlined editor so it's easier to nail down issues. +1 for dreaming though. 5 - There is no doubt that the flowgraph editor needs to be more of a feature than a "Oh, here's a thing, feel free to use it if you want" element. I sometimes forget it's there and mostly use the entity field in my scripts. 6- Yeah, when I show someone else the engine, it's mostly the physics that throws them off. Of course, other people and myself are use to Havok Physics, but that has a $25,000 royalty fee. 7- Yeah, the prefab system can get a bit screwy if you're doing something more than a simple model with a script. Issues I have most with it is when you instance CSG. 7b- I don't really understand this. And about your whole PBR argument, there should be an easier/better way to make shaders, Your visuals are all about the shaders and how you use them! Shader design should be made for artists in-mind. Of course, this is easier said than done, but it's something to think about. We can't have Shadmar make all of our cool shaders for us forever. If you feel like your project would do a lot better on a different engine, then why aren't you doing just that? I'm developing my game on LE from Source because with Unity, and UE4, I got so overwhelmed as a solo developer. They were powerful, but too powerful for how simple I wanted Vectronic to be. Plus, them publishing royalties, while Leadwerks has none. You simply buy the software, and you're good to publish - you own your game.

I recently updated the Leadwerks Extended Executable with more shaders, and hot fixes. Fetch and pull this update in git. I wanted to post this yesterday, but I was having issues. Fix 1: No more crashing upon Alt+Tabbing This fix is eventually gonna be made engine side, but I was not sure if Josh plans on that being pushed to the default branch, or the beta branch. While the beta and default branch are synced, I jumped the gun and fixed it. //---------------------------------------------------------\\ // This will be fixed engine side in a future version of LE. // For now, we are gonna apply this patch. if (window->Active()) { // Update the world. world->Update(); } if (window->Minimized() == false) { world->Render(); } //---------------------------------------------------------\\ 2: Fixed saving conflict between the options and advanced options panel. Before I went to bed last night, I noticed that if you edited a property on the advanced panel, then edited a property on the options menu, the old value you just changed on the advanced panel would reset. This has been fixed by reloading the xml file before it saves values. 3: Fullscreen mode will now always get the current display resolution. In the initial release, the application would get the size of the display and store it in the settings.xml file. Although this was a good idea, I realized that this could be bad as a display can change if the user want's to play your game on his 1080p TV while they have a 900p monitor. If fullscreen is enabled, it will now ignore the resolution stored in the settings file, and just fetch the current display size from the System. The screenwidth and screenheight properties are now only used for windowed mode. 4: More Shaders! I've added animated versions for the color-emission, cubemap, and detail model shaders. I'm currently working on some documentation for this, and will update the opening post of the tread with Google Doc links to them. I've also set a Trello board for this so you can see what's next on the list for this project. Hopefully it will not become a wasteland like my Vectronic Trello. Although I feel that this is solid how it is, continue to add your input and suggestions.

Doing so will prevent additional code in scripts such as a check for preventing the mouse locking to the center when minimized Also, I'd make sure it flushes any keys and mouse clicks before the world gets unpaused.

When the Linux build of the Game Launcher is available, I recommend only having your game on there. This way, it will easier to manage updates. I'm gonna be honest and say I'm not your target audience so I feel like I can't really give you valid input. But I still wish you the best of luck!

You can also just prevent the world from updating when the window is not active or minimized to fix the mouse bug, but I'm glad to see that this sort of thing is getting built in.

The way it works now is great, but I'm thinking having it disable creating bak files on first time generation would be the biggest improvement, This way, the project always starts out clean. It would also be neat to having the power to exclude certain files from the common folder, and the option to inherit other templates.

I'm happy to hear that you like it Josh. Just a reminder that anyone can edit the ClientScheme.xml script to customize colors and fonts to make the UI fit their game. For instance, "A Demon's Game" might want to have black panels, a spooky font, and a red highlight color while Vectronic would be totally different. If workshop support for templates comes, I'll be more than happy to put it up there for more exposure, while keeping the git for active builds. I hope the behavior of the Project Manager improves with it so it can handle various conditions and options for template authors. Right now, it seems to copy the common folder, then the selected template. (Which you can see here what happens when the template and common folder have a file with the same directory and name.)

It's not because I could not get it to include the .cpp/h files although I added them in text. I'm using VS2015 because of SQL server issues with 2013, so I did not want to replace the solution. I'll look more into this. For now, just add everything under Source/. The stock .sln files should be generated upon creating a project with the template.

Hmm, You should be able just to open the copied Code::Blocks and add all the files in. the solution should automatically be set up to work with the LE libraries. From what I can recall, getting all the dev packages for OpenAL and such was a pain, and it took a bit of Googling. Keep me posted on how you make out.

In the default script, you can use -fullscreen launch option to enable fullscreen. But yeah, I feel that the issue is when the window is minimized as alt-tabbing in windowed mode does not crash, but alt-tabbing from fullscreen does, which Windows auto minimize the window.

You use import if you have collision defines or functions you wish to use throughout your code.

Windows 10 right? Because with Win8.1, I did not have this issue. It also happens when you call window->minimize in C++, but it's more noticeable when you alt-tab from fullscreen mode even if you pause the world like this: // Check to see if the window is active. // Pause the game if it's not. if (window->Active()) { // Update the world. world->Update(); }

I have a trade certificate in graphic design, so I just make my logos.

I'm not sure if I fully understand your question, but I'll do the best I can to answer it. Basically, since there is no Linux build, the Linux Executable that gets copied to your project is the stock one and not LEX. You should not really worry about your Linux version until near release. I just released this, so things might change over time. If you're a Linux developer, I understand your frustration of Windows getting served first, but I currently don't have anyway of compiling the application for Linux at the moment. If you're a Linux user with the Standard Edition, and you wish to compile this, I'd be more than happy to see a pull request of the Linux executable and any code adjustments if needed.

about: The Leadwerks Extended Executable Template (LEX for short) is a third party, and unofficial template for the Leadwerks Game Engine. The template is aimed at developers who are most interested in creating stand-alone games. The template is centered around the executable which contains a functioning options panel, a menu that can be customized, and various useful scripts. Although it's more aimed at stand-alone releases, the template is set up so you can still publish demos to the Game Launcher. Although the executable will not upload to the workshop, you can still stay connected to your fan base without destroying your stable stand-alone project. After an entire summer of development, You can now clone/fork the project on GitHub! Read the Readme for information on setting it up. Documentation Setting Up Customizing the LEX UI Answers for Expected Questions: Q: Why is the appreciations LEX, and not LEE? A: Don't ask why, I just like LEX better. Q: I'm new to Leadwerks, should I use this? A: I'm going to say no, not now. Get to know the engine with the official templates more before looking at this. Q: Will this work if I don't own the Standard Edition? A: Yes! With the executables pre-built, you're off to start your game using Lua! With the default main script, your game will still work with the game launcher. Q: Is this free to use; even for my commercial game? A: Yes! This is why I created this; To get people a jump start on their commercial projects. Q: How often will this be updated? A: The master branch will be updated with every new release of Leadwerks. A beta branch is available and will be actively updated during the engine betas. If you are using a beta branch of the engine, it's recommended you use the beta branch of LEX also. Once a new version of the engine is released, it will be merged with the master branch. Q: Why no Linux build? A: Because my Linux machine took a dirt nap and I can no longer build code for Linux anymore. I recall coding most of the UI code in Code::blocks, so it should build ok if you are on Linux with the Standard Edition. Q: Why a Template? Why not just release the executable, source, and needed files? A: Templates are a one time install, and you can use the template for multiple projects. I also wanted some scripts to show off how to communication to the application, as well as common scripts I actively use. Q: I don't want/like this template, but I want the Executable. What would I need for it to work? A: The application still crashes if there is missing files, which I plan to fix eventually. You'll need the application (Duh), ClientScheme.xml, and the UI folder under materials. In main.lua, you need to call the App class. title="MyGame" local startmap = "" local backgroundmap = "" app = App:Create(title, backgroundmap) app:SetStartMap(startmap) --[[ We loop the app here like this, and not in the app class in code so we can still communicate with the App class in other scripts. --]] while app:Loop() do end If you are still having trouble getting this to work, take a look at the main.h file of source code as all the files needed are listed there. Q: When I make my project, there is already bak* files! Why? A: This is because the Project Manager first copies the Common folder, then the selected template resulting in creating bak files for the common files. There is a batch under tools that deletes all bak files. Be careful though! It's a simple batch file with no checks at the moment. If a batch file that deletes files sounds scary to you, then don't use it, delete it! Q: Do you plan on making tutorials/documentation on how to use this? This looks all confusing! A: Yes. I'll write blog posts and link to them in the this opening post. Q: How do I customize the menu and panels? A: Edit ClientScheme.xml. Special Thanks And Conclusion First off, I'd like to thank the entire community as a whole. Although you did not help directly, searching through the forums of how to do various things really helped. I personally like to thank tjheldna for his work of tjui which it's source helped me a lot. I'd also like to thank Joshua's Leadwerks Template for showing me how to be a better programmer overall. Finally, I'd like to give credit to nick.ace and shadmar for the cubemap shader which is included with fixes for it to work in 3.6. I hope you find this useful for current/useful projects. Please provide feedback and feel free to ask any questions at anytime. If you find any bugs or issues, feel free to post an issue report in the GitHub, or report it here and I'll post it there for you. GitHub: https://github.com/reepblue/LEX-Template

Huh, this maybe why I had trouble when I tried to run Linux on my main machine. I think the best way I've found to cross-develop is to have 2 machines with the project on a git. Of-course, not everyone has 2 PCs, and the only need to cross-develop is if you're building applications for each OS.

Leaks of games happen, and they still happen. You can spend months and months working on your game, only for a server attack or the wrong person to share it with their buddies; which then goes public accidentally, (or intentional). Having an unintended work in progress build out there can give people the wrong idea about your game because there are people out there who think the development process is pretty straight forward. Let's take a look at the Half-Life 2 leak. The game, and the entire engine code was leaked and the entire thing was very unstable, It was also found out that all those were scripted, and broke when you actually play them. A lot of doubts and concerns about the game were made as they felt like they were lied to after seeing videos and screenshots not representing the leak at all. Of course, this later on generated a community of it's own, but that's a rare scenario. Since Leadwerks is far more stable than a Source Engine build from 2003, you can have months of playable work leaked. If you indeed plan to sell your game on Steam or Desura, you most likely don't want you're game freely available. So how can we prevent this? If you already got a SteamAppID from Valve after a successful Greenlight campaign, there is nothing to worry as users need a key to access your game. But what about if all to your game is dev textures, rough code, and programmer art? If you only have the indie edition, or only use Lua scripts for your game, you can use the Game Launcher, and set your game to "Friends-Only". For games written in C++, or have a modified application, we can't do that as our program does not get uploaded to the workshop. With the Standard Edition of Leadwerks however, we can use more of the Steamworks API. A friend of mine was talking to me about how an old Source mod use to detect if an invalid Steam user tried to boot the mod, it would not boot. Once I heard this, I was eager to see if I could get a similar system to work. Every Steam user has a public unique ID that comes in many different forms. Steam and games use this to gather information about the user, among other things. In this case, we are going going to focus on the 64bit FriendID number. Thanks to the Leadwerks API, we can access Steamworks features without our game being on Steam! Let's us first start with creating a bool function under the main.cpp. bool CheckSteamID() { if (Steamworks::Initialize()) { } System::Print("Error: Failed to initialize Steam."); return false; } So far so good! We make it a bool function so if we are not a fail to load Steamworks, or have the wrong ID, it will return false and close the program. Now let's get the users ID number with: uint64_t user = Steamworks::GetUserID(); As I said before, SteamID's come in various forms. The easiest to get is the 64 bit FriendID which appears in profile urls such as http://steamcommunity.com/profiles/76561197996502882/ As you can see, my SteamID is 76561197996502882. For the rest of this article, I'm gonna use mine in place of where you should put yours. A way to get yours is to go on a site such as http://ihavenfi.net/steamid. Popping in the STEAM_0:0:******** format after putting your ID-less profile URL will give you your FriendID. Remember, these numbers are public, they aren't like credit card numbers, or anything. So let's continue! For this example, I'm going to use My SteamID. So let's make a simple if statement comparing the account trying to play this game with a hard coded value. bool CheckSteamID() { if (Steamworks::Initialize()) { uint64_t user = Steamworks::GetUserID(); if (user == 76561197996502882) // Me! { return true; } else { System::Print("Error: Invaild SteamID!"); return false; } System::Print("Error: Failed to initialize Steam."); return false; } With this code, (and I hope you replaced the SteamID), your game will only work for you if you're logged into your account. But you need beta testers, and what about the other developers? Let's Continue by adding more IDs! As another example, let's grab Josh's SteamID. After all, he's the CEO and should be able to play any LE game he wants. Although his profile is private, we can still grab the ID-less URL which is: http://steamcommunity.com/id/Josh Pop it in the converter and we get: STEAM 0:0:6085996. Let's pop that value in again and we finally have his FriendID which is: 76561197972437720 Now let's edit that if statement. if (user == 76561197996502882 // Me! || user == 76561197972437720) // Josh { return true; } Now, Josh can play our game if he's logged into his Steam account. The best way to get ID's is to make a Steam Group for your testers this way you have all the profiles listed that you need to code in. We're not done yet, we still need to call this function near the start of the main function. if (!CheckSteamID()) return 0; Just make sure you comment that out when your game does get to be on steam, or when it releases elsewhere with a different DRM measure if you desire. With this somewhat messy way, you can restrict your games to certain steam accounts without having your games on steam during development. As a bonus, let's welcome the user in the console to make the tester feel they're special. Put this before the function returns true. std::string username = Steamworks::GetUserName(user); System::Print("Hello there, " + username + "!"); And that's it! There is most likely other ways of doing this, but this way is the simplest and easiest. If you hard code FriendIDs, and use the stand-alone publishing for beta builds, your game is just a bunch of unplayable bites and bits if it falls into the wrong hands!

Not saying they should be prefabs, but mainly a working functional way with-in the editor. Maybe you can have a similar format as pfb, but they auto break their instance on creation. Store these in the steamapp folder and have the editor read the files from that directory instead of the users game.

I've been experimenting with dragging and dropping pivots with scripts already attached to them. It worked out really well minus the dialog box showing up when you edit the object. I then just created all the Leadwerks objects one by one and saved them to prefabs, and seems to be faster and easier than the traditional way. Decals and Point lights benefit the most from this method. I've attached my prefabs to give you an idea what I mean. Again, only downside to this is that dialog box. Maybe in the future have all the objects on the left sidebar and if the user holds down on the button/icon, then drags from the button to the scene, the object will be dropped in. If it's just clicked, then it would act like it does now. ObjectPrefabs.zip