catch22

Scope and the mundane are probably the biggest killers. IE: don't set out to make an MMO for your first game. Do some jams first, or weekend warrior projects. An artist once told me to put down a project and move onto another one when you get too close to it. Worrying about the little details to the point you don't make progress for a few days. Just switch to another part of it, or something different. If you stop making headway and progress, motivation plummets. Always move forward, if something is blocking you, work on something else that gives progress to re-ignite your motivation. When you go back to the thing blocking you earlier, you will probably push right through it.

Seems Lua doesn't have a modulo operator prior to 5.1 (not sure what LE is at the moment). a % b == a - math.floor(a/b)*b You can also try math.mod or fmod. from: https://stackoverflow.com/questions/9695697/lua-replacement-for-the-operator

If you guys are doing networking, I highly recommend at least going through gaffer's write ups. He did the Titanfall series networking, and some other AAA titles, I think. https://gafferongames.com/

A function that expects a return value. so for example... main { var x = hello(); print(x); // outputs 1 } int hello() { return 1; }

Well, substance is PBR and current Leadwerks isn't, so yeah, you'd have to adapt the mapping. For LE's stock shaders, anyhow. You could implement or find your own shaders though. Export the diffusals and merge them in your photo editor, then import them and make your own materials and normals in leadwerks? I know this works in 3dcoat, and the last trial version of SP I used it had an export layers to pshop option as well. I think the key is going to be which shaders you assign them in Leadwerks, you're probably just going to have use a more manual workflow with the materials.

I'm not sure designing an API around how intellisense works makes any sense whatsoever. The engine is C++ and thus object oriented, there's no reason the scripting language for the engine shouldn't reflect that. I wouldn't go out of my way to obfuscate it. At the end of the day you can just provide both, if it really concerns you? Both of your examples are procedural anyway, one just uses methods/properties and the other has standalone functions, so you're basically talking a style thing -- which should strictly be up to programmer using it, I'd think. Ultimately you'd need to decide if you want to groom people into a C++ way of thinking, or add the confusion layer of making program flow work a bit differently between your C++ core and your LUA API (for the simplicity sake of super-newbs). I'd go with the former and tell people to git gud.

First, I'd like to say, I am not an artist. I'm a programmer who does art to get by ? One issue I struggle with is textures being seamless between separate "modular" dungeon pieces. This is like walls and such. The problem I'm having is with texture scaling when making my unwraps and using textures for the sub parts of the model. It's very hard to unwrap each modular set piece and then like, stencil in the textures, because they'll never line up; the scale in the uv could be off, etc. I ended up making basically making a small texture atlas because then my texel to unit ratio is consistent and the coordinates are always roughly the same... I tend to model geometry first then try to texture after, maybe I'm doing it the wrong way? At the moment I've kind of gone back to making modular geometry pieces that I will use to compose larger "set" pieces that are groupings of these... however, it's limiting. Not everything comes down to a square. I tend to do a lot of bevels and other geometry embellishments. I also wonder, then, about using different materials, but the same texture. So I have a "set" atlas so all these modular geometry unwraps and scales correctly, but some of it might be wood, or stone, or metal... and I'd want each part to have it's own material. But then, does this cause performance hits having a big-ish texture with multiple material properties? I thought I could get away just doing each piece with its own custom unwrap and stenciled texture; im not too worried about it from a performance perspective -- just a visual one. Because in this case as I said, making stuff "line up" is tricky. Of course, a trade off might be to do "seam hiders," ie, like pillars every segment to cover the few pixels off. ... anyone more experienced with art pipelines comment? Am I on the right track, totally off, etc? My environment art is intended to be pretty elaborate, but considering uv scale, texels per unit, and seams, I'm kind of scratching my head on the best approach here?

I was bored. I wrote something in a few minutes. It's a mockup, I dunno? It works anyhow. I'm using EventEmitter I posted the other night in that other thread. https://gist.github.com/rioki/1290004d7505380f2b1d Or just ignore my ->on and ->emit stuff in the player class. It's just a callback function anyway. main loop: long currentTime; long dt; long lt; while (true) { if (window->Closed() || window->KeyDown(Leadwerks::Key::Escape)) return false; Leadwerks::Time::Update(); currentTime = Leadwerks::Time::GetCurrent(); dt = currentTime - lt; lt = currentTime; controller->update(dt); world->Update(); world->Render(); //dt = Leadwerks::Time::GetCurrent() - dt; context->SetBlendMode(Leadwerks::Blend::Alpha); context->SetColor(1.0, 1.0, 1.0); context->DrawStats(2, 2); context->Sync(false); } return 0; player class update function: // constructor .. this->on(EVENT_ANIMATION_END, function<void (const char*)>([this](const char* sequence) { std::cout << "Animation sequence '" << sequence << "' ended!" << std::endl; })); void update(long dt) { animationFrame += dt / ANIMATION_WALK_SPEED; if (animationFrame > model->GetAnimationLength("walk")) { animationFrame = 0; // this doesnt have to reset to 0 but rather whatever your state system dictates? this->emit(EVENT_ANIMATION_END, "walk"); } if (animationFrame < 0) { animationFrame = 0; } model->SetAnimationFrame(animationFrame, 0.8, "walk"); std::cout << "animationFrame: " << animationFrame << endl; }; EDIT: I guess it should be noted (at least in my model) it's 0 based animation sequences, so GetAnimationLength would return, for example 100 and your frames are 0-99; so offset appropriately. Also, I'm not blending or anything here (it's a hack come on!), so you'd take the remainder from the DT calculation and probably want to mix that into your wrap around to avoid hitching or smooth the interpolation =D

You've said crazier things?!

Well, I cannot speak for him of course, but that was 2 years ago and still nothing. It seems people just measure it themselves. I'll be doing this soon myself since animation is my next milestone...... Not a big fan of lua for core stuff like player controlling, so yeah. If I write something of use before you have a solution, i will gladly share it.

Note the comments: Josh says that's only a lua function.

Wonder how long till someone YAMLs or BSONs it for file size? JSON is great, I work with it everyday, but it's it's a little heavy around the waist since it's notation/markup is a bit excessive. Being a Ctype struct expression, it moves between languages very easily as well. Now we should ditch lua and go javascript rite? hue

Eh, I tend to gravitate toward event driven models. Would definitely be a use-case, when the animation loops to the start again just emit oncomplete event, or whatever. C++ we used to call this slots/hooks (dating myself here); in Node it is just the EventEmitter and part of the base package. Someone wrote it for C++ though if you guys wanna add similar functionality to your own classes. https://gist.github.com/rioki/1290004d7505380f2b1d

I'm a nodejs software engineer. When dealing with this stuff you generally design the routines to be "chunkable"; like you can do pieces of the work every 10ms or whatever, so it's non-blocking to the rest of the thread. Alternatively, you can fork child processes to do that, and use IPC (interprocess communication) to poll results and what not. Since you're really being quite vague there's no easy answer. But if you're asking if you should be doing "big calculations" when the game happens to be running over 60fps, I think there's probably a better way to design your program flow; it's certainly not a 'standard' way of looking at things. It seems weird to me you'd have "big" stuff to do then, and only then, rather than tasks that just need to be done all the time, or potentially all the time, whenever, wherever, etc.. Anonymous function processing is a thing as well for small bursts of stuff you don't really have anyway of knowing if it's going to be happening in regular enough intervals to write classes/functions for it -- ie: like doing a lamba on a separate thread -- but these are specific kind of workloads, lest you need to think about mutex/resource contention. C++ on modern hardware is extremely fast. You'd be surprised how much it can do at interactive framerates; if you're experiencing slow downs you need to profile your app and see where your bottlenecks are and address them accordingly.

Josh are you attending Siggraph this year?