darthlukan
-
Posts
33 -
Joined
-
Last visited
Content Type
Blogs
Forums
Store
Gallery
Videos
Posts posted by darthlukan
-
-
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.
-
This doesn't make sense. You want to make the engine more complicated and introduce new bugs because of an extreme outlier situation? This would normally give you perhaps a 0-2% improvement in speed and make everything much more complex to use.
Leadwerks will never handle more than a few thousand individual entities in a scene very well. It's not designed to.
Beyond that, visibility has nothing to do with physics. If the developer has to worry about which offscreen physics occur and which don't, they are going to be very confused when a door doesn't open when it's supposed to, or some other reaction occurs. When objects are at rest, the physics system is very efficient. It will never accomodate tends of thousands of objects. That's what the vegetation system does.
I notice that any time we come out with new models or gameplay additions, people always start wanting to reinvent the engine. It's a pattern that happens every time.
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
-
2
-
-
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.
-
1
-
-
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.
-
1
-
-
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 would say you are not missing any undocumented parameter. The problem is that glsl has no idea what an escape character is. So for multi-line text, you would have to parse the string looking for these escape characters, determine the number of lines, and send the appropriate vertex positions to a shader (text is drawn across 4 vertices). I recommend taking a look at be06's 'Notes like in Amnesia' to see how complicated it can get to parse text (granted this does come with a lot of useful features) just to send it to a shader to be drawn.
If you are asking that LE just have the ability to draw multi-line text inherently so you don't have to do all the background work, then that is a reasonable request. Just do not be surprised to find out that the performance penalty is no different or worse than just using multiple DrawText()'s. And if Josh does make this request a reality, I'd prefer him just adding it as a parameter to the current command DrawText() or create a new command DrawMultilineText() since fellow LE users have been using the command DrawText() for several years.
If by chance you are showing a wall of text that does not change, then the best performance would be from just putting that text onto a texture and using DrawImage() to show it.
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.
-
2
-
-
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
-
1
-
-
Hi! Do you use a diffrend editor theme?
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.
-
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.
-
It's no bug it's just there is no original source file like .png/.jpg/.bmp for this tex file (it's a default LE asset), hence you can't do changes to it.
If you contact Josh maybe he will supply the source image file for you.
DOH! That makes perfect sense. Marking this "Solved".
-
[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"
-
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!
-
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.
-
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.
-
1
-
-
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.
- 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"
-
You should take a look at the time api included in Leadwerks. Using lua's time functions would work if implemented correctly however Leadwerks Engine manages how and when the game time is updated, this ensures that your logic is tied to game time rather than system time. You would be mostly interested in Time:GetCurrent().
http://www.leadwerks.com/werkspace/page/api-reference/_/time/
I totally forgot to check and see Leadwerks' API Reference. That's definitely the best route to take.
-
Hello again!
And again I'm here asking stupid questions... I still have some problems with the door jamming, but moved on for now. So I'm modifying default enemy AI for my needs and making slow, but steady progress. Now enemy has basic patrol mode and it attacks player. And gives up hunting if player gets too far away. Thanks for Nick Ace for navpoint tutorial!
But I would like enemy to stop for a few seconds when reaching navpoint, so is there pause function in lua? I tried to search but could not find anything useful...
Check out the time documentation for lua. What you can do is set an idle delay variable, grab the time the mob gets to the navpoint, start a loop, then set it's mode to "idle", and check the "end time" variable (start + delay) against the "current time". If current time (set in the loop) is greater than or equal to "end time" (set before the loop), set your mob's mode appropriately to "roam", else continue the loop.
-
Ha ha! I went into the DLC directory and unzipped the archives to my project root thinking "There must be a way to do this in the interface." Sure enough, after that, I see this topic. Thanks for the instructions!
-
This is an ID that steam assigns to each product. Here :
http://store.steampowered.com/app/251810/
Number is the steam ID. But this is no hack to make it run outside the Steam. This only allows to run Steam integrated software outside Steam while Steam is running. Best eg. is you can test your new version of software how it works in Steam without uploading it to Steam.
Thanks for the response
]). So yeah, that would be a great addition IMO.
Script Debugger: Table keys displayed out of order
in Leadwerks Engine Bug Reports
Posted
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"