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?

I think it's important to keep trudging forward with newer hardware. AMD's affordable core act (RYZEN) means 6 and 8 core CPUs (with 12 and 16 threads) are going to be the norm in the coming years, because intel has had to adapt to their pricing and offering, so are likewise offering more cores for cheaper. We already saw them move coffee lake to 6 cores after a decade of quad cores. So to me, offering to leverage this in your core engine is going to be a strong selling point and get developer attention. AMD has a 15w, mobile 4 core 8 thread CPU. It's getting heated out there on the CPU front. As soon as miners stop buying all the GPUs, I think we're going to see some trading blows over the next year starting from this summer. Offering Vulkan support out of the box is going to turn a lot of heads as well, especially if it's well done. Good work Josh. Looking forward to playing with Leadwerks on my 8 core AMD and RX Vega =)

Doom Vulkan results are probably better on AMD. It seems that nvidia hardware is better on DX11 and OpenGL, more traditional rendering methods. You'll find AMD performing a bit better on Vulkan and DX12, in most cases though.

I'd be highly interested in a mac version as well. I'd probably do a lot more development if there was a Mac Version. Right now, I hate going back and forth between windows. I could VM it I guess, but I suppose I'm being lazy Since there's a Linux version I was under the impression a Mac version would be along shortly, but it's been 2 years almost....

You can also utilize the invisible material (under effects) to make it just not visible to the player. Adding mass can make it act strange with the physics when all you want is a placeholder or bounding box, for example.

Entity::Point() will work between any two entities, Entity::GetDistance() should help with the other issue.

It's possibly a different blend mode used for terrain since it has layered(/mega) texturing. Josh would be able to answer this if it's possible to customize that. I don't have the editor in front of me at the moment...

Check this thread out and see if it helps. http://www.leadwerks.com/werkspace/topic/8802-tolua-exposure-problems/

@nick.ace- One of the things I noticed, is most assets that are animated have their own FBX for the motions. Which seems strange to me. I tried a free one to see if it could work. Granted I only spent about 10 minutes, but I couldn't seem to import the animations from each FBX file? Was there a technique you recommend for this? Edit: within LE itself, I mean. I can import the models, but going to import animation from the model viewer didn't seem to work when picking the motion fbx files.

Great, that's good to hear! So please, stop running to every thread and calling it a bad joke, then. Use it. If you have problems, ask about the specific problems and go from there. LE3 is what Josh makes now, not LE2. Logic alone would dictate it's the latest iteration of his work and all his time and energy will be focused there. It's true it's not fully complete and needs a few more things, but it's also true he's actively updating it and adding to it all the time. You'd have to weigh your project release schedule against the time it would take for some of the features you need to be implemented. Chances are very likely the first would far exceed the second. Right now, new users see people like you harping on the product and making up stuff that is untrue. Drawing incorrect conclusions like, the engine can't handle this, it can't handle that, it's not optimized. The old one is better. It's bad, don't buy it. That's far more detrimental than me calling you out on trollish behavior. If someone has money in hand thinking about buying a game engine, dealing with trolls is internet 101 -- we all expect it and who cares. Seeing posts like the engine is bad and flawed will result in impact on sales conversion. Again, logic. For my part, I will apologize to you, from one person to another. I will not take back what I said though: if you don't know what you are speaking about, it's better to remain silent and be a fool than to speak and remove all doubt. Asking questions is one thing, but you hardly just asked an innocent question. As for everyone else who considers themselves part of this growing community: Get thicker skin, some of the reactions to what I said border on comical. You're in the wrong industry if you really have such a taken aback stance on rebuking trolls. Where I come from, if you don't deal with trolls, the community becomes toxic. If you didn't know he was a troll, then my advice to him applies to you as well. Secondly, the gaming industry is one of the darkest, rudest, harshest, and meanest places you can go. It's not pretty, it's unthankful, and you'll most likely end up out of work and hated for it. For indie developers, you need one another. People who don't contribute, who are negative, who try to tear down a place where you have solidarity, you must toss them to the wayside. Get rid of them, they do you no good. Build a community. Make bridges, form relationships, create, lift up. Do not tear down, destroy, and divide. And do not allow it happen in your midst. I'll be the bad guy on this one, but I want you people who take this seriously to consider this stuff. Ya'll want trolls in your forums, cool beans. Don't chase em off, see what fruit that produces. It's hard to come back from a place of negativity in this world. Good day.

Cool. I've been hesitant to buy from there because it says "open" in unity and I don't use unity. So if you buy you can get the items in FBX format?