Josh

You would use "x1=cube1:GetPosition().x" in that situation. Of course, even better would be this: position = cube1:GetPosition() By the way, there is no point in the engine where we ever iterate through the list of all entities. It's always broken down into the scene octree.

I have some members exposed in Lua, but I would not ever use them in example programs in the documentation. I could see an argument for not having them exposed at all in Lua, since they are a low-level hardcore C++ feature for writing intensive routines.

I don't recommend setting members directly. For example, changing the position member of an entity would not have the intended result, because the 4x4 matrix and other things have to be updated. Members generally should be treated as read-only attributes. For that reason, you will never be expected to rely on members. If you want simpler code and faster performance in intensive routines, you can read them. Any members we document will be considered "fixed" and won't change. Don't mess around with anything that's not documented, because that could be subject to change. Members also gives you a little more power. For example, Material::GetTexture(const int& index=0) increments the refcount of the texture and allocates a new handle that has to be deleted (so you can safely use a texture without worrying about it being automatically deleted when the material is deleted), but you can avoid this by just reading the member with material->texture[0].

It doesn't matter, the vector won't scale well when the numbers get big. If you have 10,000 entities, this can result in 40,000 bytes being allocated or copied every single time you create or delete a single entity. The list will always add and remove elements at the same speed. The iteration speed of both will increase linearly with the number of elements. When designing systems you want predictable performance and scalability. Sacrificing scalability to gain a minute performance increase (in the lightweight scenarios where it isn't even needed) is a bad idea. What? Who said anything about maps? I like being able to access members. It's simple and convenient. It would be silly to call Entity::GetPosition() and allocate a new Vec3 object every time I need to perform some math on an entity, when I can just access the member directly. If you don't like it, don't use them, because there is a getter and setter for anything you need to access.

Yes, you can debug the Lua state of any application that is built with the debug Leadwerks3D library.

A vector is a contiguous block of memory. If you remove an element in the middle of it, everything after that element has to be copied to where the element's position was. If you add an element at the end of the vector and it exceeds the size of the memory allocated for that vector, a new block of memory has to be requested, and the entire contents of the container copied to it. Linked lists have a next and previous pointer for each element. When an element is removed, the program just has to update the memory pointers of the previous and next elements to point to each other, so insertion and removal is fast. I almost never use vectors.

Lists should be used if objects will be randomly removed from the container.

It should, but I am not going to mess up my Mac machines quite yet. It's not due out until summer.

If it requires the end user to have a Leadwerks Engine license, I don't see any problem.

Thanks, I have absolutely no objection to a game product as described in that specification.

Got it working now. The problem was that most of the hooks never get called if the DEBUG macro is not defined. I object to having this embedded in the Lua source code, since a competent programmer can use a macro to only set a hook in debug mode, if desired.

You would need to be a lot more specific and precise for there to be anything for me to agree to. It's not enough to just say "it's for the game". You need to define your terms, or there is nothing concrete for me to agree to. Your definitions of gameplay control might be wildly different from mine. But I think you understand my concerns and position.

It errs on the side f protecting the company, like most of these things do. If you have a precise description of what you intend to do, feel free to run it by me.

I don't know, the guys on the mailing list are saying it should be able to step through each line, but that doesn't seem to be happening. I'll spend some more time on it and see...

Lua's debug hooks are a little funny, because they don't appear to allow line-by-line calling of your own function. The description here is pretty vague: http://pgl.yoyo.org/luai/i/lua_sethook The line and count hooks look like they might be what I wanted, but the docs have one big caveat: This makes me wonder what the point of these hooks even is. The way I have it set up now, "Step" continues to either the next Debug:Stop() call, or to the next point where a Lua function is called. Not C++ functions, Lua functions only, as shown in the code below. Additionally, I found that each time the hook was actually being called twice. No idea why, but I added a flag to discard every other call. I'm not too happy with the documentation of this or it's design, but the important thing is that the Debug:Stop() function be usable to set a program breakpoint, which it can. I sent a query to the Lua mailing list, and I'll work on it some more if anyone indicates that it's supposed to be able to do line-by-line stepping. I did some additional work on the shader editor, adding a few ideas I got from the script editor. The tabs for errors and warnings will show a number indicating how many items each tab has. I also made it so the compiler output gets printed even when the shader is successfully compiled, which wasn't the case before. As you can see in the screenshot below, the shader editor can be very useful for catching problems that might occur on other cards. I have an NVidia GEForce 480 in right now, but I can see from the warnings list this shader probably would not work on other hardware! This is becoming very useful as a diagnostic tool. Well, that was my day today. What did you accomplish today?

We use the standard interface for Windows and Mac, and these don't support line numbering. You can double-click on a function in the debug tree to go to the appropriate line, and the current line number is displayed in the status bar. It's a compromise, but the native text rendering looks sooooo much better than Scintilla or something like that. That's a good point. I'll see what happens when I start actually using it.

http://www.leadwerks.com/werkspace/page/Documentation/le2/_/tutorials/

YES.

In my last development blog, I wrote about some design problems I faced, and why I wasn't sure how to proceed. I've resolved these issues by building the debugger and game output display close to where they will be most likely to be used, the Script Editor. I was pleased to find that my Lua debugger code I wrote about a year ago works perfectly. This allows breakpoints, code stepping, and the display of variable values in your game. It works with any Leadwerks3D executable, so you can even examine and debug the Lua state in your C++ executables. (This does not debug C++ code or other languages, as there are already appropriate tools for that.) I like to combine the callstack and variable display into one tree view, so you can quickly navigate the program. I decided it made sense to build the game output and debugger into the script editor, because that is where you are most likely to use it. Even if you are debugging Lua in a C++ application, you still want to be able to double-click on the call stack and display a script in the editor. The only situation where this design doesn't really make sense is if you launch a C++ application and just want to look at the program's output. In that situation, it is a little strange to need to open the script editor to do that. The actual executable to be launched will be controlled in the project settings. The default for a Lua program will be a copy of the interpreter executable that gets added the project folder. You can specify the script in a command line field, like this: +script $scriptfile Where "$scriptfile" gets replaced with the file name of the currently selected script file in the script editor. For a C++ application, the project will simply be set to call the executable the C++ template sets up a project for. If any of that sounded confusing, take a look at how maps are launched in 3D World Studio (or even Valve's Hammer Editor, for that matter). The bottom line is it's set up automatically when a project is created, and you probably will never need to change it, but the capability is there if you need to. Previously I wrote that it's better to name a thing with a specific name that describes most of what it does, rather than to broaden the description to become fully encompassing but vague. The same holds true for program and workflow design. The debugger and game output display are built into the script editor, where they will be the most useful overall. It's not "correct" in a hyper-analytical way, but it makes sense and is convenient.

For leadwerks engine, c++ is probably best. For leadwerks3d, Lua will have better debugging support, and be easier to use than installing all the different SDKs for mobile platforms.

If it's not a right angle, it's a wrong angle.

I'll get right on that...

Aria is kind of off and on when needed, but the Android stuff is done. I'd like to get a couple of students to help write the command declarations in the docs, and whatever else they can do. We'll see.

Ah, that is a little more complicated then. I just thought they were supposed to be completely stiff.

As you can see, the bloom effects are fantastic, but the chair looks a little fake.