Josh

The wiki has all the up to date command reference.

I added a BMX section, although there were no BMX tutorials in the database. I thought about doing the tutorials the same way the command reference works, where you select a language and it displays the code in that language. It would be a nightmare.

I revised the main tutorials page the way I think everyone wants. I think I want the tutorials list view to be laid out like the main page, with two columns where your tutorials appear side by side.

I'm working on a template to display tutorials Here's what the listing looks like: http://leadwerks.com/werkspace/index.php?/page/resources/_/leadwerks/ Here's a lesson by Masterxilo I made a few formatting changes to: http://leadwerks.com/werkspace/index.php?/page/resources/_/community/using-opengl-for-drawing-r19 This lesson talks about writing and formatting tutorials: http://leadwerks.com/werkspace/index.php?/page/resources/_/community/tips-for-creating-tutorials-r13 There are still some limitations of the template and some things won't work right. Ratings and comments are missing. The lightbox display does not work. You also can't add attachments when editing. To get around the last problem, you can use this page as a temporary solution. This accesses the same data using a different wrapper, and the buttons to attach images and files will work: http://leadwerks.com/werkspace/index.php?/page/edit_tutorials

I would prefer not to have a secondary market of used software licenses.

Sent.

Sounds like your Apache material may have an invalid shader definition, like using the diffuse texture vertex shader with the diffuse+bumpmap fragment shader. I strongly recommend you have an ATI card for testing because they are more strict with the requirements. NVidia cards tend to silently fail if a problem exists, while ATI cards let you know immediately something is wrong.

The Lua script attachment eliminates the need to parse entity class IDs. If this is not used, I recommend using the model file. Originally, every piece of code was just a suggestion of how to set things up, and not a strict guideline. People wanted more and more an official way of doing things, and the result was version 2.3 and onwards.

It's relevant because the API design interacts with the design of the documentation system, and the documentation system is being designed with future scalability in mind. Exactly. The purpose of the C command set is not necessarily to program in C (although I know you like it). The C command set is the general command set that is not tied to any single language.

I think it's a good idea to have CreateMesh(), etc., only for the purpose of filling in the C command set. I don't actually expect anyone to code in pure C. The purpose of the C syntax is actually to provide a consistent command set that every programming language can access. For C++ I expect programmers to use new, and all tutorials and documentation will reflect this.

Your EXE fails to start without any error message on my ATI 4870.

ZioRed, your design is fine for version 2.x. For version 3.0 I think I want a 1:1 ratio with the commands, but that's not your responsibility. You are of course welcome to help plan the syntax in whatever capacity you feel like.

I recommend an NVidia GEForce 9800 GTX. It costs about $130 and it will destroy almost anything you throw at it.

http://cboard.cprogramming.com/cplusplus-programming/38020-vector-references.html

I'm just joshing you, Roland. References seem good for classes like Vec3's, where you have a lot of temporary objects you want collected when they are no longer in use. Pointers seem more suited to objects that get created and deleted infrequently, like entities. Since references can't be NULL, it makes commands like TFormPoint() very awkward, where one of the arguments can be NULL. There is a way around that, by declaring an overloaded version that accepts an integer. However, my experience is memory management is more trouble than it saves when used for objects that have lots of connections that have to be manually removed when they are deleted. Oh yeah, and you can't make a list of references. Math classes like Vec3's, AABB's, Mat4's, etc. will not be exported in the library for use with external languages. The external language will be responsible for creating these, and they can either be a block of memory the appropriate length, or an actual structure. All the library cares about is that you send it a pointer to a memory position with enough space to read or write the number of floats it needs. This is how the DLL works now.

Queering an object state? I will disagree in that public members are very useful, i.e.: x = entity.position.x; Some of Mika's suggestions are cool, but it's a lot of work to declare all those overloaded methods, especially since all functions have to be declared three times (the function, the header, and the luabind structure). I think the Get/Set method should be what we do everything in, and if we add other niceties for convenience, we will deal with it then.

Agreed. The C# header is okay the way it is, but in version 3.0 I think the syntax should match C++. I will question a lot of basic design elements in the next few months. Keep in mind it is because I want to make sure we are designing 3.0 the right way. The command reference database I created is for version 2.x. A lot of it can be copied to a new database for 3.0, and we will make whatever changes are needed.

We would not have an equivalent to this: entity.SetPosition(1,2,3) ...because we can only assign one value. We could do this: entity.position.x = 1; entity.position.y = 2; entity.position.z = 3; ...but this would involve a separate hierarchical matrix update for each line, so it would be very suboptimal. Yes, and unless I am convinced otherwise, this is the approach I intend to use in 3.0. I am not so concerned about the current C# header that anything has to be rewritten. I am more interested in determining a consistent design for the future.

That's what I figured. Is there any way to pass an extra variable along with the assignment, that the get/set method can process? We can do the same thing in C++ and even Lua: http://www.rasterbar.com/products/luabind/docs.html#properties I am not sure this is the best approach in v3.0. I believe it eliminates the ability to have an extra argument, and thus changes our command paradigm a bit. What do you guys think? This should be decided and made consistent for everything in 3.0. We're either looking at: entity.SetPosition( 1, 2, 3, True ); ...or this: entity.globalposition = Vec3( 1, 2, 3 );

So when you assign this value, there is a set method that gets called internally?: myEntity.Position = new Vector3(1.5f, 2f, 4.5f); Is it customary to call the base class "core"? If not, wouldn't "engine" be more appropriate? I don't like this approach because it splits the command into two commands that aren't really even commands: myEntity.Position = new Vector3(1.5f, 2f, 4.5f); myEntity.GlobalPosition = new Vector3(1.5f, 2f, 4.5f); I understand you know more about C# than I do, but I would like additional feedback from other C# programmers.

Why doesn't the C# header do it like this?: entity.SetPosition( Vec3 position, int global ) Why is the .core prefix necessary?: Core.PositionEntity(IntPtr entity, float[] position, int global); Doesn't C# support objects from pointers?

What is Leadwerks? It's an engine, but as we abstract out parts of the code in version 3 it's also a specification for how things should work, like OpenGL is.

Looks cool.

Can you type what C# syntax documentation would look like for PositionEntity(), in this thread? That's what I am getting at.

There are about three different ways of generating mipmaps on the GPU, and they all have their own individual driver issues. This is one the reasons I opted to support DDS textures exclusively, with their pre-calculated mipmaps. I recommend calculating your mipmaps on the CPU because I think the GPU-based methods are unreliable.