Jump to content

darthlukan

Members
  • Posts

    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. 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.
  4. 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
  5. @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.
  6. 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
  7. 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?
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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
  15. 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.
  16. 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.
  17. I might find something more useful to say, but for now, "Hello World!" will suffice.
  18. 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.
  19. 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.
  20. DOH! That makes perfect sense. Marking this "Solved".
  21. [sOLVED] Saving textures requires the source image (jpg/png/etc) I've been wanting to mess around with the different options in the Texture editor but I keep getting this "No source file found" error. Please see the screenshots below. Here I chose to try and edit the glass01 texture and upon saving, received the error. Sure enough, in the Information panel, there's <unknown> in the Source file field. I'm not sure I understand what's going on here, there's definitely a glass01.tex file listed in my assets and that's what I thought I was editing, but I guess there's another file that's missing? This issue occurs with any texture provided as part of the template (I'm using the "Advanced First-Person Shooter" template). I can't adjust anything without getting the error. Steps to reproduce: (Using Leadwerks v3.6 Standard Edition on Linux) 1. In the Properties pane, open the Assets tab 2. Select the Materials folder 3. Double-click any <filename>.tex 4. Change any setting and click the "Save" button 5. A dialogue box appears stating "No source file found." Expected behavior: Performing step 4 results in the File being saved with changes. Actual behavior: Error message "No source file found"
  22. After spending a few days with the tutorials and getting myself accustomed to the editor I'm ready to begin an actual project. I don't have a name for it and I promise nothing grand, but I do have a short story written for the project as well as some story boards from start to finish, so that's something at least. It's a mild horror / psychological thriller story that I think will adapt nicely to a game, even if it's super short. Here's to just getting started!
  23. I don't seem to have the option to change fonts in Leadwerks 3.6 Standard Edition on Linux. But thanks for pointing me to the colors options! That will help a lot.
  24. I actually prefer the Steam option. I don't have to think about updating to the latest and greatest version and the community on Steam is great what with all of the people contributing to Workshop content for use in game projects.
  25. I'll keep the list short and devoid of mentioning bugs that are already being worked on Version Control Integration: Sure, it's trivial to use the project manager to start a project then crack open a terminal to run "git init" and setup my remote, but it would be nice to set a default preference in Leadwerks for a VCS installed on my system and when my project is created, have a local git repo ("git init" already run). Simple commit, push, pull behavior would be great as well, but would obviously require a lot more work (might be easy for git, but what if the user chooses subversion, mercurial, etc?). Still, a definite "nice to have" One thing that I'm still confused about (granted, I just got Leadwerks less than a week ago) is how I can go about adding a dialog system. Whether it be with dialog balloons, or dialog screens. If this is already possible, then a tutorial on getting started with it would be awesome. If not, then I think it would be a great addition and would allow for easier creation of story-based games (not like interactive books, but games of "substance" with characters that you can identify with [assuming the writer is doing their job ]). So yeah, that would be a great addition IMO. Preferences. What I mean by this is, for example: Font selection: I'm not sure how the font is being determined, but it's most definitely not configurable via a menu (or config file) that I've seen. Editor color schemes: White backgrounds are hard to look at when spending hours in the editor, especially in a dark room. Those changes alone would keep me focused in the editor and not having to feel like I "need" to drop to my terminal in order to maintain a sane workflow. As it stands, I rarely use the in-engine script/code editor in favor of vim and I keep a terminal open for local version control.
×
×
  • Create New...