Jump to content

darthlukan

Members
  • Content Count

    33
  • Joined

  • Last visited

Everything posted by darthlukan

  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 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
  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 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.
  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 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
  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 however many copies of that entity?
  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. Just a thought.
  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 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.
  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 ability to handle multi-line strings in LUA or have it renamed to DrawSingleLineText, since that's what it does.
  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
  16. I've started a second project that the wife says I'd better finish because she wants to play it:

    1. Show previous comments  1 more
    2. darthlukan

      darthlukan

      In which way? The fact that it's stuck in flappy bird mode or the fact that I am using textures from the tutorials?

       

      The former is a necessary mechanic for future levels, the latter will be rectified as I get further along :)

    3. Einlander

      Einlander

      Kinda looked like no grab at the end

    4. darthlukan

      darthlukan

      Yeah, that's because of the flappy bird flying thing and my screencap was stuttering for some reason.

       

      I've fixed the jump since then, I'll make a new video showing the third level and the fixed behavior soon.

  17. 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.
  18. For my current project I wanted to simulate a light that's shorting out in order to add a bit of a creepy ambience to my scene. After a while of messing with the different things that could be done with an emitter (and failing at getting the effect I wanted), I realized that really, a light that's shorting out is really a light that's turning off and on again. Well, that's something that can be scripted pretty easily thanks to Leadwerk's API. There are a couple of obvious ways to get the desired effect: Create the light in a given position, then remove it again. This can be a pain and can also be resource intensive Toggle the light's color between the "on" and "off" colors, where "off" is transparent and "on" is any color with a visible alpha. Needless to say, I chose the latter. First I needed to define some colors. For my purposes, I wanted to be able to set colors between Red, Green, Blue, and White, so in my Scripts/Objects/Lights/ShortedBlink.lua file I added the following: function Script:Start() self.colors = {} self.colors["red"] = Vec4(1, 0, 0, 0) self.colors["green"] = Vec4(0, 1, 0, 0) self.colors["blue"] = Vec4(0, 0, 1, 0) self.colors["white"] = Vec4(1, 1, 1, 0) if self.color_on == nil then self.color_on = self.colors[string.lower(self.OnColor)] end self:On() end Then it came time to fill in the "on()" and "off()" functions: function Script:On() self.entity:SetColor(self.color_on) self.component:CallOutputs("On") self.isOn = true end function Script:Off() self.entity:SetColor(self.color_off) self.component:CallOutputs("Off") self.isOn = false end I then defined a few top-level variables that I knew I would need, one of which needed to be available to the Leadwerks Editor, namely "OnColor" (the desired activated color). Here's what the top of the file looks like: Script.enabled = true Script.isOn = true Script.OnColor = "red" -- string "Active Color" Script.color_on = nil -- transparent Script.color_off = Vec4(0, 0, 0, 0) Now that I had my top-level variables defined coupled with on and off functions, it was time to add a ToggleLight() function that would do the work: function Script:ToggleLight() if self.isOn then self:Off() else self:On() end end Pretty self-explanatory. If isOn is true then the light is on, so turn it off, else turn it on. This script is missing one thing: UpdateWorld() function Script:UpdateWorld() self:ToggleLight() end I was pretty happy with myself up until I attached this script to a spotlight and almost suffered an epileptic seizure... Thankfully, the answer was pretty clear: I needed to add some sort of a delay. After some experimentation, the desired effect was achieved by performing some modulo division: function Script:UpdateWorld() if Time:Millisecs() % 11 == 0 then self:ToggleLight() end end Basically, we're taking the current time in milliseconds and seeing if it's evenly divisible by 11. If it is, then toggle the light, else leave the light's state alone. I probably could have gone with a better way of randomizing the delay, but this one works just fine and isn't resource intensive at all (if a computer struggles to perform a simple math operation, put it out of its misery). The completed script looks like this: Script.enabled = true Script.isOn = true Script.OnColor = "red" -- string "Active Color" Script.color_on = nil -- transparent Script.color_off = Vec4(0, 0, 0, 0) function Script:Start() self.colors = {} self.colors["red"] = Vec4(1, 0, 0, 0) self.colors["green"] = Vec4(0, 1, 0, 0) self.colors["blue"] = Vec4(0, 0, 1, 0) self.colors["white"] = Vec4(1, 1, 1, 0) if self.color_on == nil then self.color_on = self.colors[string.lower(self.OnColor)] end self:On() end function Script:On() self.entity:SetColor(self.color_on) self.component:CallOutputs("On") self.isOn = true end function Script:Off() self.entity:SetColor(self.color_off) self.component:CallOutputs("Off") self.isOn = false end function Script:ToggleLight() if self.isOn then self:Off() else self:On() end end function Script:UpdateWorld() if Time:Millisecs() % 11 == 0 then self:ToggleLight() end end Just add the script to a light source, type in the color you want (from the choices available within the script) and watch what happens the next time you debug or play your game. Hopefully this saves someone some time in the future.
  19. I might find something more useful to say, but for now, "Hello World!" will suffice.
  20. Today I will work on UI scripting, first step complete: https://twitter.com/DarthLukan/status/672113003974811648

    1. shadmar
    2. darthlukan

      darthlukan

      Thanks! Today I made a few changes after reading the API docs and now that's in a box. I'll post another screenshot once I have actual icons in place of the "Health" and "Ammo" labels :)

    3. ChrisV

      ChrisV

      Good work! One step at a time. ;-)

       

  21. Everything is dark because of my GTK theme settings, I didn't have to do anything since I have my GTK theme defined system-wide. So far as the LUA and C++ editors, a forum member showed me where the color options are in the Options menu for Leadwerks.
  22. Almost done with my first "real" map :)

  23. I'm using Leadwerks Standard Edition on an unsupported Linux distribution (CRUX) and aside from known quirks with tiling window managers (i3), other niche window managers (swm + wmutils), and the fact that my distro didn't come with a 32bit openAL package (about 5 minutes of my time to write a port for), I haven't had functionality problems. Any "crash" that I've experienced has been due to my window manager not liking pop-up dialogues (such as warnings about real-time rendering or errors that I cause). None of those are the fault of Leadwerks as a product, I expect things like that to happen because I'm using an unsupported distro and DE/WM configuration. If those things did become a "show stopper" for me, I'd just install the recommended setup and drive-on. So far, Leadwerks works as intended, is performant, and "breaks" where expected, which is no bother to me as those aren't actual "breaks" but minor quirks that quite honestly are not even worth complaining about.
  24. First level is coming along nicely :)

×
×
  • Create New...