Josh

At the moment I am trying to figure out how to push a C++ object onto the Lua stack. When I use pushlightuserdata it does not match the value of the object that LuaBind commands return, so I am not sure what's going on.

It has to be built into the system, from the start. That's why I ask for specifics about what people intend to do.

This is one reason I decided to use Create() functions in LE3.

If the primary reason for this is to make very, very large streaming worlds, that's okay, but I need to know that because there's a lot more that goes into that than just loading models on a separate thread. For example, I am using 64-bit floats on anything to do with matrices and positions, because the physics need it.

How does this help you make games?

No such feature has been promised. I'll see how it works out, but I honestly think this kind of thing is overblown and would only benefit a very small number of people.

Multithreaded compiling is not supported. I have built the engine in MT mode, and it ran so slow it's not worth bothering with, like 15% the speed the ST mode runs at. BMX's multithread implementation is mostly useless, because it relies on a different garbage collector that is much slower. Making BMX garbage-collected was a huge design mistake, in my opinion, and this is just one more reason why. The engine also relies on the reference-counted (ST) GC at some points, and will crash without it.

Not for models, because visual geometry != physics geometry. Stuff like this is possible with CSG geometry because visual geometry == physics geometry.

In legal docs, typically you define terms at the start and then just use the generic term throughout the document. The EULA is written specifically to avoid someone building a 3D engine or game development product on top of Leadwerks Engine. This happened to Blitz3D; someone wrote a script interpreter and sold it as "CoolBasic".

I can produce this error. Those files are 16 mb each, which makes them the largest files in the SDK. We switched to a dedicated server earlier this week. I bet there is a php setting on the server that is limiting the download size.

Those values should always be set automatically. I will resolve bug reports next week. I've read it but haven't looked closely yet.

My guess is the trees have black pixels where the leaves aren't, and they are getting blended into the billboard image. That's what the settings I described corrects, or you can just paint the background green in a paint program. Is that the sample Pure3D tree that comes with the editor?

I believe the tree you have circled in the distance is still showing the model, not the billboard, and the leaves appear sparse because of the technique used to save mipmaps. I think Photoshop weights downsampled colors by the pixel alpha when saving mipmaps, or at least has an option to. In my own MakeDDS tool, there is an option for "mask correction" which does the same thing.

Splendid, it sounds like a lot of people will have use for that.

The whole Framework thing has been the weakest point of LE2 because it was originally intended for everyone to write their own renderers with, and when no one knew how to use it, something had to be done quickly.

The old C++ Framework code is no longer distributed. It was built into the engine some time around version 2.3.

It would be even cooler if the official docs for one language were finished.

The code is in the BMX folder?

There are roughly 10,000 customers who have bought any Leadwerks product including Cartography Shop, Character Shop, asset packs I no longer offer, on any site, including leadwerks.com, thegamecreators.com, and also including my software sold in bundles with other products, and bulk purchases for massively discounted foreign markets, over a time period of maybe 6-7 years. That sounds good to me, except I would not want separate documentation via doxygen. If C# requires separate documentation beyond the C++ command syntax, then it should be entered into the same database and appear on the same pages. I suppose .NET would be fine for LE2, since it's Windows-only, but LE3 will require Mono or whatever it is that runs on OSX. I'm not trying to drag my feet and get the community to add value to my product, but I have tons of other stuff to do that are a higher priority than official support for another language, so I haven't paid much attention to C#.

If anyone posts source code I can run that demonstrates an error I will try it out. Nothing has changed in the way the API works in any recent version.

What graphics card do you have? It should work with everything, but I am curious.

I don't actually have any problem with the addition of getters and setters, but the great thing about the API is you can generally guess what the command names are without knowing them. Sometimes in LE2, but much more often in LE3. I found myself even having to look up command names for particle emitters and some other things, so the consistent naming scheme in LE3 really helps. I don't see how getters and setters can provide a consistent API in LE3. There's exceptions I pointed out. If it were just a matter of always switching the syntax in one way or another, I would be 100% in support of them, but they are limited. It would also mean a vastly different API to document, and we're having enough trouble finishing the docs for LE2. That's why I'm suggesting the consistent documented class structure, and then implementing getters and setters in addition to that, and they can branch as far as you want from the C++ API without fear. C# users will get a documented API and will be able to follow C++ tutorials easily, and can still use the nice OO syntax, sort of like how I sometimes use operation overloading in my math code, i.e: a = b + c.Normalize(); If anyone doesn't understand the API, they can just look at the C++ docs and it will match. If they are a good C# coder, then checking out the source or additional docs won't be a problem, and they'll probably end up use getters and setters for their most commonly modified code. By providing a base API that matches C++, we can be more inclusive of the C# programmers. It's not a matter of C++ being better. I think every language except that one I made up is horrible. It's a matter of getting all the languages on roughly the same page so the community isn't branched in two development directions. C#, C++, and Lua all have a common OO structure they can share, so if it's consistent I only have to document things once. I don't just mean documentation, I mean all the tutorials and examples I put out and modify over the years. There's no way that can be duplicated and maintained because I can't even record all the changes I make and tell another person what they need to update.

Very nice.

Yeah, but then it gets into stuff like "model.surface[1].vertex[4].position.x = 3" which looks nice, but completely branches from the original API. When I see commands, and I'm not sure what they do, that means it's getting beyond my control. There's also a problem that many of the C++ get/set functions use multiple or optional arguments, like Entity::SetPosition(x,y,z,true). So we either have a break in the design, where some things use getters/setters and some things use methods, or you have to make up your own terminology. In this case we could say: entity.position = 4 -or- entity.globalposition = 4 But it's not always that clear. Or should it be entity.localposition? That would be more consistent, but look less nice. I'm not even sure. They really should have designed getters and setters to take multiple arguments: entity.position = 4, true Without that, they're only good for some things, and it creates an awful lot of inconsistency because you still have to use a method for anything more complex. So I am still interested in C#, but I am not going to put my name behind something unless I have thoroughly examined it and decided what the API should look like, and I just don't have time right now to devote to the syntax of one language. I think the uncertainty people express over C# has less to do with me not making it official, and more to do with the issues I described here, the implication being that I would devise some kind of consistent rule to clear all that up if I were to make it official.

I have provided the existing LE3 header, and am somewhat interested in C# support. I can't same more than that yet, because I don't know enough about C# to make a judgement. One problem is the getters and setters in C#, which are a nice language feature, but also lead to everyone making their own versions of commands they think is best, and it can deviate quite a lot from the original API. I would be much more comfortable with a class wrapper that duplicates the C++ classes exactly, and then let the C# people add whatever enhancement they like in a community add-on.