reepblue

Your physics mesh will be very high poly as it does 2 triangles per rectangle face. I would guess this would be expensive, but I'm interested in how it works out. The correct way to do this would be to make the gameplay walls/floors out of brushes and do the roof, railings and such as models. But with vsync enabled/low frame rate, brushes will pop in upon spinning the camera. If your plan doesn't work out, I suggest you make your building layout with brushes, and force disable vsync. Forcing a frame rate via the graphics driver (like what you have to do with Nivdia Linux drivers) produces better results anyway.

The small footprint is one of the many reasons why I really like Leadwerks. Really happy to see you still going forward with this approach, while making it more flexible.

I'll look more into that, thanks. I used 7zip for years, but never touched the command line.

I know, I plan on doing this for my project when the time comes. However, I'd need to create a way to do this automatically. Closest I got was I compiled an app that makes zip files, but I couldn't get password encryption to work. If you know of a good command line app for zip files, let me know.

VPKs allow for splicing packages. Your 8GB game can be cut into chunks. This allows for smaller updates down the road. This can be done using the -M parameter. https://developer.valvesoftware.com/wiki/VPK This isn't perfect, but much better than the current Leadwerks packaging system.

Source Engine models have a lot of information in them so I don't know how easy/hard it would be. But also, this means we can use vpks to store our game data?

This is because EOF is conflicting with stream->EOF. What are you trying to do that the engine's stream class can't?

One thing that caught my eye is you are loading a texture in Post Render, which is called every frame. Load the texture in the start function. Otherwise, that's ok. It seems ShowImage is never being set to "No". I also recommend making that value a Boolean member of the script. (Ie: self.showimage)

Yeah. We can always write the particle script once and attach the script to a particle entity. I could do a wrapper function like LoadParticle(<scriptpath>) and have it return an emitter. Still suggesting a visual editor in the future. Doesn't have to be in the 1.0 release, but it would be a lot more efficient in work flow. ?

Would it be possible for emitters to be created via an editor and then have it's values saved to a json/binary file? The particle editor in Leadwerks was really weak and pretty much had you had to code each effect to get most out of the system.

It seems that the input code isn't working how I want it right now. I'll fix it later.

Premake is multiplication project maker.Unlike CMake, it simply generates a project file for the given IDE giving you a clean result. You only need the one light weight executable and a lua script for this to work. I've spent today setting it up with Leadwerks. I haven't tested Linux yet, but it should work. My premake5.lua file: g_LeadwerksHeaderPath = "./Engine/Include" g_LeadwerksLibPath = "./Engine/Libs" function GlobalSettings() -- Include Directories includedirs { "%{prj.name}", "%{g_LeadwerksHeaderPath}", "%{g_LeadwerksHeaderPath}/Libraries/SDL2-2.0.10/include", "%{g_LeadwerksHeaderPath}/Libraries/NewtonDynamics/sdk/dgCore", "%{g_LeadwerksHeaderPath}/Libraries/NewtonDynamics/sdk/dgNewton", "%{g_LeadwerksHeaderPath}/Libraries/libvorbis/include", "%{g_LeadwerksHeaderPath}/Libraries/libogg/include", "%{g_LeadwerksHeaderPath}/Libraries/openssl/include", "%{g_LeadwerksHeaderPath}/Libraries/VHACD/src/VHACD_Lib/inc", "%{g_LeadwerksHeaderPath}/Libraries/glslang", "%{g_LeadwerksHeaderPath}/Libraries/freetype-2.4.7/include", "%{g_LeadwerksHeaderPath}/Libraries/OpenAL/include", "%{g_LeadwerksHeaderPath}/Libraries/NewtonDynamics/sdk/dMath", "%{g_LeadwerksHeaderPath}/Libraries/NewtonDynamics/sdk/dgTimeTracker", "%{g_LeadwerksHeaderPath}/Libraries/NewtonDynamics/sdk/dContainers", "%{g_LeadwerksHeaderPath}/Libraries/NewtonDynamics/sdk/dCustomJoints", "%{g_LeadwerksHeaderPath}/Libraries/RecastNavigation/RecastDemo/Include", "%{g_LeadwerksHeaderPath}/Libraries/RecastNavigation/DetourCrowd/Include", "%{g_LeadwerksHeaderPath}/Libraries/RecastNavigation/DetourTileCache/Include", "%{g_LeadwerksHeaderPath}/Libraries/RecastNavigation/DebugUtils/Include", "%{g_LeadwerksHeaderPath}/Libraries/RecastNavigation/Recast/Include", "%{g_LeadwerksHeaderPath}/Libraries/RecastNavigation/Detour/Include", "%{g_LeadwerksHeaderPath}/Libraries/tolua++-1.0.93/include", "%{g_LeadwerksHeaderPath}/Libraries/lua-5.1.4", "%{g_LeadwerksHeaderPath}/Libraries/glew-1.6.0/include/GL", "%{g_LeadwerksHeaderPath}/Libraries/glew-1.6.0/include", "%{g_LeadwerksHeaderPath}/Libraries/enet-1.3.1/include", "%{g_LeadwerksHeaderPath}/Libraries/zlib-1.2.5", "%{g_LeadwerksHeaderPath}/Libraries/freetype-2.4.3/include" } -- Global Defines: defines { "__STEAM__", "_CUSTOM_JOINTS_STATIC_LIB", "FT2_BUILD_LIBRARY", "LEADWERKS_3_1", "DG_DISABLE_ASSERT", "OPENGL", "_NEWTON_STATIC_LIB", "_STATICLIB" } -- Windows Exclusive: filter "system:windows" systemversion "latest" pchsource "%{prj.name}/stdafx.cpp" links { "libcryptoMT.lib", "libsslMT.lib", "Rpcrt4.lib", "crypt32.lib", "libcurl.lib", "msimg32.lib", "lua51.lib", "steam_api.lib", "ws2_32.lib", "Glu32.lib", "libovrd.lib", "OpenGL32.lib", "winmm.lib", "Psapi.lib", "OpenAL32.lib", "SDL2.lib", "Leadwerks.lib" } libdirs { "%{g_LeadwerksLibPath}/Windows/x86", "%{g_LeadwerksLibPath}/Windows/x86/%{cfg.buildcfg}" } defines { "PSAPI_VERSION=1", "PTW32_STATIC_LIB", "PTW32_BUILD", "_NEWTON_USE_LIB", "_LIB", "DG_USE_NORMAL_PRIORITY_THREAD", "GLEW_STATIC", "WINDOWS", "WIN32", "OS_WINDOWS", "PLATFORM_WINDOWS", "_WIN_32_VER" } buildoptions { "/D \"SLB_LIBRARY\"", } flags { "NoMinimalRebuild" } linkoptions { "/NODEFAULTLIB:MSVCRT.lib", "/NODEFAULTLIB:MSVCRTD.lib" } -- Linux Exclusive: filter "system:linux" systemversion "latest" linkoptions { "-ldl", "-lopenal", "-lGL", "-lGLU", "-lX11", "-lXext", "-lXrender", "-lXft", "-lpthread", "-lcurl", --"-lSDL2", "%{g_LeadwerksLibPath}/Linux/libluajit.a", "%{gameDir}/libopenvr_api.so" } defines { "ZLIB", "PLATFORM_LINUX", "unix", "_POSIX_VER", "_POSIX_VER_64", "DG_THREAD_EMULATION", "DG_USE_THREAD_EMULATION", "GL_GLEXT_PROTOTYPES", "LUA_USE_LINUX", "_GLIBCXX_USE_CXX11_ABI", "_CUSTOM_JOINTS_STATIC_LIB" } linkoptions { "%{g_LeadwerksLibPath}/Linux/%{cfg.buildcfg}/Leadwerks.a" } -- Debug Build: filter "configurations:Debug" runtime "Debug" symbols "on" targetsuffix ".debug" defines { "DEBUG", "_DEBUG" } if os.target() == "windows" then links { "newton_d.lib", "dContainers_d.lib", "dCustomJoints_d.lib" } end -- Release Build: filter "configurations:Release" runtime "Release" optimize "on" if os.target() == "windows" then buildoptions { "/MP" } links { "newton.lib", "dContainers.lib", "dCustomJoints.lib" } end end function GenerateLuaApp() workspace "PremakeTest" architecture "x86" --architecture "x86_64" startproject "LuaApp" configurations { "Debug", "Release" } -- Test application project "LuaApp" kind "ConsoleApp" language "C++" location "%{prj.name}" staticruntime "on" -- Project Directory: projectDir = "%{prj.name}/" -- Game Directory: gameDir = _WORKING_DIR .. "/../Projects/%{prj.name}" -- OBJ Directory objdir (projectDir .. "%{cfg.buildcfg}_%{prj.name}") targetdir (gameDir) files { "%{prj.name}/**.h", "%{prj.name}/**.cpp" } pchheader "stdafx.h" -- Custom Defines defines { "__TEST_ME_", } GlobalSettings() end newaction { trigger = "luaapp", description = "Builds the stock lua app", execute = GenerateLuaApp() } if _ACTION == "luaapp" then GenerateLuaApp() end Then I just have batch file that builds the project file. "devtools/premake5.exe" vs2017 luaapp pause My impressions are more positive on this than CMake as CMake creates a lot of extra files to do real time updating if the CMakeList file is updated. Premake simply just builds the project file and that's it. It really reminds me of VPC stuff I had to deal with in my modding days. Really interested to how codelite projects generate on Linux.

I've decided to upload a demo of what I've been working on for the past 6 months (more if you count the old code I scavenged). The scene and app code is very basic but there is a lot going on here. A folder will be created in your Documents folder that'll save the settings, key/joy bindings and the logfile. The app uses SDL2 for controller detection and handling. If you run the batch, Fullscreen mode will enable. Sounds are preloaded from json scripts. Although not shown/used, An entities physics properties can be changed via a script definition. Game takes input on actions which are defined by json scripts saved to your documents file. FPS player can walk, crouch, jump, and zoom. There is a weapon system in the works. If you touch the sphere prop, you'll get 6 hemispheres in front of you. This is a developer 'weapon'; kind of like my own version of weapon_cubemap. Plenty of actors are in this build, just not showcased. Core code is compatible with Leadwerks 5. As for the game stuff - sorta. Everything is written in C++! Actors attach with the help of Lua, and scripts are json files. Notes: SDL2 has failed on some computers during previous implementations. This time I only use SDL2 for controller input and it works so far. If it doesn't work I'll just disable the define. No Linux build yet. It should compile, just need to set the projects up. If you have dual monitors, don't use fullscreen as the entire window might stretch across all displays. I'll have to look into border less windows. There was GUI working, but I thought of a better way of implementing it. I had it set to the window class when I should be setting it to the world class or the camera class.Issue with doing the GUI in the camera is that the camera gets deleted per world-Clear(). could do some nasty stuff to prevent it, but I think I'll just leave it be and do the GUI in the world class. If you run in fullscreen, you can press the END key to end the program. Hopefully it works! GameTemplateDemo.zip

I should really write something on how I handle Actors. Not to brag but my system is just really nice. ?

"Unofficial" meaning that it's a function that was put there as an experiment or he thought it would be replaced/removed one day. Personally, I just read the headers as my API, but examples really help.

I think I've finally finished my approach in input for my project. This is the final result. //========= Copyright Reep Softworks, All rights reserved. ============// // // Purpose: // //=====================================================================// #include "stdafx.h" #include "gamewindow.h" #include "gameworld.h" int main(int argc, const char* argv[]) { App::ParseCommandLine(argc, argv); auto window = CreateGameWindow("GameTemplate"); auto world = CreateGameWorld(window); if (App::GetArgument("vr") != "") App::EnableVR(); auto camera = Camera::Create(); camera->SetPosition(0, 0, -1); ActionConfig::SetActiveSet("Walking"); while (App::Running()) { if (GetActionHit("jump")) { DMsg("jump!"); } if (GetActionHit("interact")) { DMsg("interact!"); } world->Render(); } return 0; } We no longer care what key or button is pressed, we are now concerned what action is being sent to us.Two json files are auto generated in "CreateGameWindow()". One for the mouse and keyboard, and the other for a gamepad with SDL2. These files can be modified by the user (hard) or an app when I actually write it (easier). { "keyBindings": { "actionStates": { "Menu": { "pause": 27, "selectActive": 13, "selectDown": 40, "selectLeft": 37, "selectRight": 39, "selectUp": 38 }, "Walking": { "crouch": 17, "firePrimary": 1, "fireSecondary": 2, "flashLight": 70, "interact": 69, "jump": 32, "moveBackward": 83, "moveForward": 87, "moveLeft": 65, "moveRight": 68, "pause": 27, "reloadWeapon": 82 } } } } { "joyBindings": { "actionStates": { "Menu": { "joySelect": 0, "pause": 6, "selectActive": 0, "selectDown": 12, "selectLeft": 13, "selectRight": 14, "selectUp": 11 }, "Walking": { "crouch": 7, "firePrimary": 16, "fireSecondary": 15, "flashLight": 3, "interact": 2, "joyLook": 1, "joyMovement": 0, "jump": 0, "pause": 6, "reloadWeapon": 1 } } } } You may notice that "jump" and "joyMovement" are both 0, but they get treated differently. I've added a GetActionValue() function which returns a Vec2 for analog sticks and triggers. Triggers are both read as buttons and analog values. You still have to write code in how you want to treat the sticks, but the question of the left stick or right stick is bindable now. There are also Action Sets a collection of buttons can be set based on what state the game is at. Driving is not the same as walking, nor it's the same as flying a plane. VR can also have it's own entry, but I feel you should use SteamInput for that since the Engine is dependent on SteamVR for it's VR implementation. I've could have just used SteamInput at the start, but then my binding code would only work if the game is on Steam. My code was compiled on Leadwerks 4.6 beta, but thanks to my wrapper functions and back and forth compiling, it should just work in the new engine.

It's ok if it doesn't work for VR. It may only be an AMD issue as the animated shaders don't render correctly ether in VR. I would not worry about it. As for the footsteps, I got the filepath of the material and used it's subfolder to determine what material type it is. I know the new engine has a Material praram that makes life easier. I should look into how to load custom material properties as I mentioned earlier.

Ok, only issue I came across is that it doesn't work with VR.

Finally tried your shader. Works on AMD hardware running the 19.9.2 driver. This looks like something that can be used in a real game; terrific work!

Ok, Looks like I've updated my driver since then. 19.9.2 works fine. This was an AMD issue.

I don't think there is anything you can do as a shader artist. The implementation of how to alter the shader to get different results is a job for the actual game programmer.

I tried this again and it seems to be working now which is weird. I check again to see if full screen causes this or not. I recall just making a box and plopping a decal to produce this.

Brushes get collapsed into the scene tree to improve performance. Once a brush has a script attached to it, it's left as a model. Josh can go into detail about what actually happens, but it's not wise to attach a script to a brush to change it's apperence. I would look into how I could read the material file and adjust the material accordingly. It would probably have to be in the MapHook function I have been meaning to try your shader for the longest time but now I want to see if I can read custom values from a mat file.

Only downside attaching a script to a brush is that now the brush will not collapse with the scene.

I still want to try this with my hardware. I'll let you know when I do.