reepblue

Over 2 weeks ago, I released a small demo showcasing my project's core gameplay on the Leadwerks Engine. Although I'm happy with the demo; it's a good landmark for the project, but it can be better visually and functionality. I learned a lot of new information about the engine on how to better optimize it, multiplatform diffrences, and I grew a slight hatred to a certain brand of GPUs. But the demo on the Game Launcher to me was a success. The stand-alone version in my opinion was a bit shakey as with stand-alone releases you lose the end user's ease of use when it comes to settings and the requirement of OpenAL. The Vectronic Demo was indeed targeted to work with the Game Launcher from the begining as I wanted to be more focused on the actual game scripting than the dirty stuff such as how settings are loaded, menus, etc. But I also wanted a stand-alone version out due to the launcher being in beta, and I wanted to let people on linux play it. I took Vectronic to the Portal community to see how they liked it. I mostly got back issues in actually launching the application. Besides the lack of OpenAL, most people did not seem to understand how they can run the Portal 2 (Which runs on a branch of the Source Engine that can run on DX9 cards.), and other games but not Leadwerks; especally on a certain brand of a GPU. One person actually got angry at me because he could not run the game. Overall, it was mostly things that Josh nor I can fix. (i.e it was ether outdated hardware or poor drivers.) However, the OpenAL requirement is something I can look into. Right now, I'm stepping away from the demo, and focusing on improving the stand-alone experience now since the soultions for the standard edition has been recently optimized. With the Summer Games Tournament coming up, it's a good deadline to stay focused, and to experment with non-Vectronic stuff. After this project is done, Vectronic will be back on track as I kind of need this done before I continue to work on my main project. I still got Part 2 of My Introduction Entry to write which I share why and how I moved the Project to Leadwerks, but I think I'll write that when I want to look back as right now I want to looking forward. I might also share various techniques I used in the Vectronic Demo as I think it will help with any user of Leadwerks; especially durning the summer tournament. I'll continue to write about whatever I'm working on here.

It happens with any map with Post Effects shaders. I took the start map, added shaders. and re-saved it in Windows. https://dl.dropboxusercontent.com/u/16218991/Requests/transfertest.map I test it myself. The Post Effects list clears when loading it on Linux. However, if you where to add Post Effects in a map on Linux, then open the map in Windows, the list does not clear as expected.

Hmm, I guess I was not paying attention. Yeah everything seems to be the same on both platforms. However, the post processing effects don't transfer over, the "Post Effects" under the map tab becomes blank after they have been set in windows. I did not try the other way yet.

Ahh, ok. I tried the Tutorial project's fan model and it was turned off. I'll "open" this again if I notice anything weird.

This model I noticed it. All my models with bones and animations seem to do it such as most props in Vectronic.

Not sure it's a bug or not, but I noticed that when dropping a model in from the asset browser, Occlusion Culling is enabled by default, when on Window's it's disabled. Opening maps on Linux that were saved on Windows will switch all the models OC setting to enabled, and when read back on Windows, it will remain enabled. CSG on the other hand it's disabled by default. I understand the linux version has a lot of gotcha's, so not sure if this is intended or not.

I really hope I can come up with something small and fun within the time period. I also want to take a break from the first person perspective/genre.

Reporting that performance of newly built executables now has identical performance to the stock build. Thanks, now I can really get back to work.

You get similar warnings when compiling on Windows with Visual Studio. But yeah, I agree, it should be cleaned up more if possible.

NOOOOOOOOOOOOOOOO!

I hope to see the updated projects soon as I tried playing with the optimization settings with no luck.

People like me. Back in the day, I used a resource hacker to customize the Hammer UI a bit, even recompiling code. I actually made the editor Windows 7 schemed from it's Win95 scheme, added features, and a lot of other dumb stuff. It was a shame it could only read unpackaged content, and was not ideal to work with in the end. I also changed the icons for the entities in LE, but looks like Josh want's LE's new color to be more of a blue tone than it's former/current dark gray. Is this icon update only being applied to the Window's version of the editor, or will Linux see this UI scheme/a newer one as well? I recall you wanting to make the editor blend in with the rest of the Unity desktop. Still, would be nice to see less of a gap between the two versions, although that's easier said than done.

Just tried a rebuild from a blank project and same problem. the only thing it did was reduced the size down by 20kb. My executable just tells main.lua to execute and the lua file once and the main.lua script handles it from there. Although my program is lighter, it's still righting slower. And unless Josh joined the VS2015 beta, I'm sure he's still using VS2013 like the rest of us. Keep in mind he has more access to the engine than we do so it's possible that he is compiling the stock executables differently than us.

Hmm. I looked over the the project and everything seems to be right to me. I also tried cleaning up the main.cpp file (removing the AppData writes and calling App), and removed the app.cpp/,h files from the project. This still made the exe bigger than the auto generated one, but the game still works. #ifndef OS_IOS #ifndef _DLL #ifndef BUILD_STATICLIB #include "Leadwerks.h" #endif #endif using namespace Leadwerks; void DebugErrorHook(char* c) { int n=0;//<--------------------------- Add a breakpoint here to catch errors } #ifdef __APPLE__ int main_(int argc,const char *argv[]) { #else int main(int argc,const char *argv[]) { #endif //Set program path System::AppPath = FileSystem::ExtractDir(argv[0]); //Load command-line parameters System::ParseCommandLine(argc, argv); //Enable Lua sandboxing if (String::Int(System::GetProperty("sandbox")) != 0) Interpreter::sandboxmode = true; //Switch directory std::string gamepack = System::GetProperty("game"); if (gamepack != "") { Package* package = Package::Load(gamepack); if (!package) return 1; } //Add debug hook for catching errors Leadwerks::System::AddHook(System::DebugErrorHook,(void*)DebugErrorHook); //Load any zip files in main directory Leadwerks::Directory* dir = Leadwerks::FileSystem::LoadDir("."); if (dir) { for (int i=0; i<dir->files.size(); i++) { std::string file = dir->files[i]; std::string ext = Leadwerks::String::Lower(Leadwerks::FileSystem::ExtractExt(file)); if (ext=="zip" || ext=="pak") { Leadwerks::Package::Load(file); } } delete dir; } #ifdef DEBUG std::string debuggerhostname = System::GetProperty("debuggerhostname"); if (debuggerhostname!="") { //Connect to the debugger int debuggerport = String::Int(System::GetProperty("debuggerport")); if (!Interpreter::Connect(debuggerhostname,debuggerport)) { Print("Error: Failed to connect to debugger with hostname \""+debuggerhostname+"\" and port "+String(debuggerport)+"."); return false; } Print("Successfully connected to debugger."); std::string breakpointsfile = System::GetProperty("breakpointsfile"); if (breakpointsfile!="") { if (!Interpreter::LoadBreakpoints(breakpointsfile)) { Print("Error: Failed to load breakpoints file \""+breakpointsfile+"\"."); } } } else { // Print("No debugger hostname supplied in command line."); } #endif if (FileSystem::GetFileType("Scripts/main.lua") == 1) { //Execute main script file if (Interpreter::ExecuteFile("Scripts/main.lua")) { #ifdef DEBUG Interpreter::Disconnect(); #endif //if (!System::SaveSettings(settingsfile)) System::Print("Error: Failed to save settings file \"" + settingsfile + "\"."); Steamworks::Shutdown(); return 0; } else { #ifdef DEBUG Interpreter::Disconnect(); #endif Steamworks::Shutdown(); return 1; } } } #endif I don't know how or why this is a problem. Maybe there is something with the settings. I'm gonna try building a project from scratch now.

The only difference here is the exe itself. I never noticed that the exe's are two totally different sizes. It seems to only be noticeable with busy scenes rather than simple games/prototypes. Hence why I waited till I released the demo to ask about this issue. So it must be within the project files. I might try rebuilding an exe from scratch and see if there is any hiccups.

Before I released Vectronic's Demo, I've noticed that when recompiling the project even with the stock code, the game runs at a much slower framerate than the exe generated by the project manager. But now since the demo is out, and there is something to test it with I'd thought I would share this issue with the community, and hopefully find a fix. Please download the Vectronic Demo if you don't have it already, then download this 7z file which contains two exe's. One recompiled titles "Vectronic_Recompiled" (Recompiled by me.) and the other "Vectronic_Stock" (Straight from the project manager). It also contains the Source and Project Folder. This should work regardless if you have the latest beta or not. I tried the exe's on the current standard release. You'll notice that the stock executable runs at a higher framerate than the recompiled executable. I've not changed a single thing within the projects nor source code. What makes this different than the ones generated by the stock builds of the executables? Thanks.

Strangely enough, with the Linux version of the editor this defaults to true, and in Windows, it defaults to false. I can't recall if I checked it or a 3.5 beta build automatically did this. Ether way, I force my elements to set it to be false in the start functions as it fixes the issues with AMD GPU's and the statement above. I wish to update the demo with this fix and the crouching fix for Linux players.

I think you should do something in the scene tree/name field when 2 entities are sharing a name. A little warning icon or how Hammer does this is by bolding the name if 2 entities share a name. (Although may be less obvious.) I welcome this approach. Yeah, I'm use to typing/copy and pasting names into fields, but I really dislike how the scene tree functions. But that's just me.

Again, I made a character that can go under stuff. If you play Vectronic use the 0g and ghost box combo to make a ghost box float around half the player's height, they player will go under it and there is a picker test to tell the player not to get up if they are under an object...

This seemed to fix it. Hopefully doing this on all props will not impact on performance too much. I might have the actual maps be small (A one puzzle per map rule, sorta like Portal 2.)

On my AMD Linux machine, (A 5770 HD), I tried the AI and events SDK map even though it's a smaller map, and the only animated models are the crawlers. Trying to figure out if this is my models and how they are rigged, or AMD with Leadwerks. So far the reports are coming from AMD users. Don't think it's the fact it's on linux as I tried it with my machine with Mint, and it ran like it should.

I'm aware of the flickering issue, so far my findings have been that it's something to do with animated models and AMD gpus. From your profile it seems you have an integrated chip. Do models flicker in other LE games? Gonna test the Advanced Shooter template now.

With the Unity desktop, it's fine. What desktop are you using? Also what distribution you are using because Ubuntu is the only distro officially supported.

Great information. I just thought adding a quick how to for Linux newbies like myself. Thanks for the tip, your knowledge is very helpful.

Note: This is pretty much a copy and paste from this post here with a few tweaks. After 3 years of planning, modeling, texturing, and a lot of engine hopping, I was able to create a playable demo in the Leadwerks Engine for Windows and Linux (Debian/Ubuntu/Mint). You can download the demo from this page. A small demo was created not only to test the basic elements of the game in the new engine, but to also give back to those who have been supporting this project since I started talking about it. I'm also announcing that from here on out that the development will be more open. How open? Well first you can always check the Trello page to see the progress at any time, If you wish to help, drop me an e-mail. Feed back is welcomed with opened arms. You can do this simply by e-mail or twitter @reepblue. I'll do my best to respond if necessary. About Vectronic Vectronic is a first-person environmental puzzle game inspired other games of the same genre such as Portal, Quadrum Conundrum, and Q.U.B.E. Players must solve puzzles using special power balls that effect boxes that changes their behavior in the world. For more information, please visit the Q&A. For additional help, click here. Please let me know what you think. Although a short primitive demo, this is a big milestone for the project in the indie path.