reepblue

I've been thinking about this for a while and not being connected to the internet 24/7 made me realize how messed up people are. I live off of mobile data for internet, and a useable connection is not always certain. When I do use the internet at home, most of the time I'm here talking about Leadwerks with you guys here, sharing what I'm working on with peers, or looking up examples on how to do things. I have a Twitter as another way of sharing stuff, but I'm using it less and less. Think this year I'm just going to delete the app altogether.

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.

AMD as in the vendor of the card. With my RX480, not everything works like it should.

Really awesome. My only concern is the shader with AMD because that's always a concern. But good work from what I'm looking at.