reepblue

I've read that any program that is designed to run on Windows 7 or 8/8.1 (Which Leadwerks does.) will run without a problem on 10. And If not, I'm sure Josh will rebuild the solutions/fix the issues when the update comes out later this month. But honestly, I don't see why LE wouldn't work.

I hope the workshop is filled with things that are worth money rather than cheap/broken/stolen content with a high price tag. I guess we have to trust the "good floats, bad sinks" logic here. If I ever post something for sale on the workshop, I'll be sure it's worth the money. Hopefully everyone has the same idea as I do.

I had this issue! It would work fine if the game was windowed, but would flicker on fullscreen. This is why the spotlights in Vectronic use sprites instead of lens flares. Also on a Nvidia card.

I swore that this was addressed myself, but I still divide all my color values by 255 as I'm sure it will always work.

So far, C++ application that has a settings system, and a MenuUI that can easily work on any LE game. Menu, loading screen and other things can be edited outside of Visual Studio. It also has a background map system too.

Make a new collision response rule in Main.lua. -- Props can activate triggers. Collision:SetResponse(Collision.Prop, Collision.Trigger, Collision.Trigger) You might also want a new collision for objects that are picked up. Vectronic is a working example of this. Collision.PickedUpProp = 12 -- Picked up objects can still collide with triggers, but never characters. Collision:SetResponse(Collision.PickedUpProp, Collision.Character, Collision.None) Collision:SetResponse(Collision.PickedUpProp, Collision.Scene, Collision.Collide) Collision:SetResponse(Collision.PickedUpProp, Collision.Prop, Collision.Collide) Collision:SetResponse(Collision.PickedUpProp, Collision.Trigger, Collision.Trigger) Collision:SetResponse(Collision.PickedUpProp, Collision.PickedUpProp, Collision.None)

In a perfect world, everyone could just go with their preferences and enjoy games the same way. My linux machine is an AMD processor, with an AMD GPU running Ubuntu 14.04LTS, and it plays Portal 1 at 30fps. And I know if I were to slap a drive running Windows/DirectX, that game will run with no issues. Maybe the 15 driver will fix everything, who knows. At the end of the day, I don't have control over what players want/have in their PCs.

I'm not really mad, it just makes things harder than they have too...

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.