Jump to content

darthlukan

Members
  • Content Count

    33
  • Joined

  • Last visited

Community Reputation

8 Neutral

About darthlukan

  • Rank
    Advanced Member
  • Birthday 03/06/1984

Profile Information

  • Gender
    Male
  • Location
    Anaheim, CA

Recent Profile Visitors

3,012 profile views
  1. 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"
  2. 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 th
  3. Looks like I've got a mini-framework for multi-line UI text in the works :)

    1. Show previous comments  2 more
    2. darthlukan
    3. Einlander
    4. darthlukan

      darthlukan

      @Einlander - Those look radically more complex than what I've implemented. Mine sets the box scaling automatically based on the text content, no manual setting of box sizing or positioning required. It also accounts for directional scrolling, because I needed it for my game.

  4. 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
  5. 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
  6. @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.
  7. 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 metho
  8. 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 how
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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 beca
  14. 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 abili
  15. 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
×
×
  • Create New...