darthlukan

No worries, it's not some super-high priority bug. If nothing else, it's just more of a confusion point at first and can honestly be counted as one of those "fixes of convenience"

Regarding the game launcher and Linux users: I tried using it in five different graphical environments on three different distros there was one consistent factor between all of them: The window behaves horribly. On tiling Window Managers I was able to force the size down, but then the content was hidden (I was staring at a white background with no game content). On non-tiling / floating WMs, I couldn't resize the damn thing down and it REALLY liked to use all monitors on my multi-monitor setups. I'm not sure how the game launcher window/browser is built, but it looks like a mini-browser that doesn't have responsive CSS enabled and doesn't honor window hinting (freedesktop standards have all of the information on that if you're interested). If that were fixed, I'm not saying Linux usage would significantly jump, but existing Leadwerks users on Linux (like me) would probably use it more often. Other than that, I'm really excited to be using Leadwerks and can't wait to see what else you have in store

I'm in the process of debugging a loop which is supposed to vertically scroll some text contained in a table. My loop is verified as looping over the keys in order (ipairs(array) vs pairs(array)) but in the debugger (pictured) the keys appear out of order once we get to "k=10", where it appears after the first index. It's a small thing, but it confused me for a minute before I double-checked the loop again and verified that it is in fact iterating in the correct order. This is literally just a display issue in the debugger. Here's the screenshot of what I'm talking about (nevermind my improperly incremented values): Expected behavior: Keys in "txt_y" table are displayed in order Current behavior: Keys in "txt_y" table are displayed out of order once there are more than 9 keys.

Given that find, I don't think there's anything for Josh to look at implementing (unless he wants to wrap that in a method exposed to LUA and C++ as API calls rather than directly via the Newton libs). I mean, that's the functionality we're looking for and the system provides for it, just not in a documented way, but that can be remedied by a link to the relevant Newton docs. Now if you'll all excuse me, the wife and I have a bottle of Cognac to enjoy

@Ma-Shell - You just made some people very happy with that find. Being able to call it via LUA would be a "nice to have", but really, for an operation like this, you're probably needing to perform your lookups in C++ anyways.

It's not a matter of reinventing the engine in this case. In this case, the dev expects to not incur a performance penalty when pre-loading and not rendering entities. Currently, there is a performance penalty, because, as you rightly pointed out, visibility has nothing to do with physics. Just because something isn't rendered doesn't mean it isn't having its physics calculated. That's fine for small games with not very many entities (as you also rightly pointed out) and the engine isn't designed for large scenes with lots of entities (several thousand). Is it complicated to expose a method of control that allows a developer to control that behavior? Yup, if it were easy, everybody would be doing it at home already. Is it something useful and therefore worth considering? Probably. Nobody is knocking your work or purposely trying to get you to fundamentally overhaul the engine here (in this thread). We are interested in having more control over which entities are having their physics calculated as we see it as useful performance-related feature. Obviously you're the gatekeeper of features since you're the one that would have to implement them, we totally appreciate that and understand that you're not some mythical magic wand wielder that can just say a few words and "poof" features into existence. Especially around the holidays IMO, it would be useful, but it's not some super-emergency that has to be decided over the holidays. Get some egg-nog in you and enjoy the family. This thread will wait

Because the whole point is to cache the item (since you will use it, just not "right now", maybe on a trigger) at load time and then incur a lesser performance penalty by simply "showing" it when you do need it. It's faster to have an entity present (but not having its physics calculated) and then show it when ready than it is to have a trigger that then creates the entity, which incurs the heftier penalty. Sure, you can remove a shape file so that the item doesn't get loaded, but then what are you supposed to do once you need physics applied? Create the file and then force a reload on however many copies of that entity?

I don't think it's a question of usefulness at all, it is. The performance gains alone would be enough. The only issue I see is that, depending on how entities are "sent" to the physics system, it could be really complicated to get right for 100% of cases. As Leadwerks gains more popularity and people want to build more complex games, the physics system's efficiency and level of control becomes even more important. It's the kind of feature that brings parity to Leadwerks as compared to other engines that have a way of doing the same thing.

Is there a way to force removal of the hidden entities from the physics system? For example, let's say I hide an entity, can I then do something like: "model:RemovePhysics()" so that item is cleared from the calculations? I'm assuming you have a way to remove items from the physics calculations as a private method, would exposing it as an API method cause unsafe execution? For large maps with large amounts of entities, it might be worthwhile to expose something like that so that developers can manage resources with a bit more control instead of relying on the Engine to automatically handle it. Just a thought.

That's a good suggestion, but ultimately, you'd still have to iterate over each entity to determine which list it belongs in. The difference now you've turned an O(n) problem into an O(n^2) problem since you're now iterating over two lists at some point.

It would make sense that an entity is iterated over even if it's hidden if the "hidden" attribute is set per-entity. The check would still have to be run and the only way to do that would be to iterate over all entities and see if "hidden" is "true", at which point it wouldn't run the render.

I took a look at that. I ran across this situation due to a use-case involving scrolling multi-line text (or at least, that's what I wanted to do). The scrolling isn't the issue, I have that well in hand, I was just trying to avoid using a loop to accomplish the task as, considering the amount of text, the performance penalty would become more noticeable (O(n) vs O(1)). For now, I can use a texture, though that's a bit unwieldy and requires yet more code to implement. Thanks for that bit on GLSL, I didn't realize that DrawText was using that and that it doesn't understand escapes because of it. Now that I think of it, that does make quite a bit of sense. I stand by that it would still be worthwhile having inherent to DrawText (or DrawMultiText) as it minimizes complexity in project implementation (even if it requires more code in the engine) and offers a bit more flexibility with regard to UIs in Leadwerks. That said, I can totally understand if Josh chooses to sit this one out, as it could cause backwards compatibility issues, especially if DrawText is modified for an extra param.

It looks like DrawText doesn't like multi-line string literals, it's reading them in as one long line that ends up mostly off of the screen and doesn't respond to escape characters (such as "\n") embedded in the multi-line string in order to try and simulate "wrapping". Either I'm missing some undocumented param or DrawText was only meant to draw a single line of text at a time. Of course, I can write a loop for this, but that incurs a performance penalty, especially with longer bits of text and seems to be a needlessly complex solution. My suggestion is to allow DrawText the ability to handle multi-line strings in LUA or have it renamed to DrawSingleLineText, since that's what it does.

Forked. I'll test it out on Linux (since that's my primary dev platform) and let you know what I find. If there's a problem and I can fix it, I'll shoot you a PR

You mean like self:Show() or self:Hide() ? That's another way to do it. I'm using the same script elsewhere in the game to simulate a discoball and just overriding the color_on, color_off and UpdateWorld settings. If I relied on Show and Hide then that discoball script would have required more code. I'm also not sure of the performance difference between using Show/Hide versus SetColor.