L B

I would say: Draw a loading image (texture w/e) all over the screen oldScene.Free() Scene.Load(...) Stop displaying picture Anyway, LoadScene should freeze the app.

@Mesh.Scale suggestion: both Tyler and I found that more confusing than our way. Just use the Mesh editing mode, it's quite easy.

With the new C# headers, I hope people will start using C#. Next time I get a hold of Josh I'll try to have them officially integrated.

I hate Java as well, I think the syntax is sketchy and inferior to that of C#. But I do need to get used to the "Java-mindset", i.e. the libraries and syntax changes, even if they're minor.

Try MeshBox from the previous forum. Not batch though.

I've started school in Java and it could be a fun project to do to learn. Does anybody need/want that? Yes, for development Yes, for the theoretical aspect Yes, in the ideology that LE has all common languages No, not at all

Object scaling (as seven mentioned, it didn't work on meshes as entities): Fixed. Give me some time to upload the next revision. Done. Mesh scaling: use the following snippet: using (Mesh.Editing) { example.Scale = new Vector3(5, 9, 1); } Use the same for "Translate" and "Rotate". GetPreferredMaterialName: Far from being a critical command, I asked Tyler to add it to our DLL for Middlewerks. It should be there when I get to talk to Tyler again. Why can't you access the surface object? This should do for most uses: example.Surfaces[0].Material.Path Retrieving global and local vectors? Specify please. Color cast: This is normal. Try the following code to test by yourself: Color test = new float[] { 0.5f, 1f, 0.5f, 1f }; Debug.Alert(test.ToString()); float[] casted = (float[])test; Debug.Alert(string.Format("{0}f, {1}f, {2}f, {3}f", casted[0], casted[1], casted[2], casted[3])); This is because the internal constructor uses floats. Please do not assume it's wrong then, you shouldn't be messing with a reflector and looking into our methods anyway

@Rick: Please don't be aggressive on language comparison, as it isn't our intention to compete: we're simply proud of the time we invested in the wrapper that, to us, paid off. Dynamic Vectors Indeed, all languages can provide the given functionality - however, as far as it goes now, only C# implements it. This means you *can* do it in C/C++, but you'll have to make the headers yourself. And believe me, it's a tedious task. Also, we do not use reflection (hard to maintain), but delegates. The line that was posted was this: cube.Position.X += sphere.Rotation.Y; The simplest and natural translation to C/C++ would therefore be: EntityPosition(cube).X += EntityRotation(sphere).Y; However, trying that, you will realize that it has no effect. This is because the Vector3 returned by EntityPosition isn't dynamic, and therefore, changes applied to it do not apply engine commands. You will merely store a variable and increment it, but not set its value back. Simplified Casts Of course, you'll still be able to increment the cube's X position in a longer manner. But version 2 was all about usability. For instance, you can declare a whole vector by a float or integer, due to an extensive set of operators and casts we created. Example: sun.Rotation = 45; This will set the sun's rotation to 45 degrees in all directions. Advanced Accessors What do we mean by "advanced accessors"? Have a look at this page: Unified Get/Set accessors. Our custom engine DLL and headers fully implement them, giving you much more flexibility and control. @klepto2: Sorry for the vertex stuff, many things are bugged in this sector. We'll look into it very soon.

cube.Position.X += sphere.Rotation.Y; Framework.Effects.Bloom.Enabled = !Framework.Effects.Bloom.Enabled; Many getters are only available in C#, such as Framework effects. Here's the equivalent of the first line in C. Notice how longer it is. PositionEntity(cube, EntityPosition(cube).X + EntityRotation(sphere).Y, EntityPosition(cube).Y, EntityPosition(cube).Z); You simply can't do the first line in another language.

Good, but feel free to use the latest version of the headers, with the following parameters: Emitter fire = new Emitter(velocity: new[3] { 0, 5, 0 }); It's less than a quarter of the previous code in terms of characters.

You are using outdated headers. "SetRadii" doesn't exist anymore in version 2, and is replaced by the "Radii" member with dynamic get and set accessors. Has anybody noticed this link? http://www.middlewerks.com/headers/ I posted it many times with barely no comment, which is surprising since people had been waiting on it for over 2 months. Now onto the fix: Vector comparison didn't support null checks, which is now fixed. I'm uploading the new revision. Should be on in 5 minutes at most.

Details at middlewerks.com/headers

2010 = .NET 4

The long awaited v2.0 is out! Visit www.middlewerks.com/headers to download them and get access to a growing list of in depth tutorial. Please report bugs here. Thanks! Note to header developers: SVN access will be granted after bug reports and initial fixes have been completed.

File Name: Custom Engine.dll for .NET File Submitter: Lazlo File Submitted: 23 Aug 2010 File Category: Tools and Utilities Required for advanced accessors. Click here to download this file

File Name: 32-bit .NET DLL File Submitter: Lazlo File Submitted: 23 Aug 2010 File Updated: 06 Sep 2010 File Category: Tools and Utilities 32-bit DLL for .NET. Tutorials and information Click here to download this file

I was going to quote all the sentences accompanied with a +1, but in the end, it's shorter to say: -Good inheritance design -Thanks for the roadmap -Great news for the DLL/C# -Yay for the streaming terrain. Therefore, +>9000 Percfect.

Part of why I hate C/C++. Getting your libraries and headers straight is a pain that should be done automatically by the computer.

I'm not completely satisfied. This sounds like C# users will be stuck at 2.3, which is a bad move, both in terms of selling points and usability.

+1. Although I expected that answer from Lumooja. Slightly deceived here

.lib And @Lumooja: Static linking the Leadwerks library would mean restricting access to pirates. I see no negative aspect into that, especially if you only statically link code and not media files.

I cannot statically lib anything in C#, it would have to be exposed through a DLL. Will that still be possible? Also, I assumed LE3 to be OO as you mentioned - therefore, the command set couldn't really stay the same.

I'm curious as to how or why you generate a header file, especially with a parsed string's name. Other than that, I hope it can save you time, but I also hope the source license will be available in C++.

Lots of talk and negative comments here. My only question: Will the API stay as usable? My second only question (whoops): Will I still be able to wrap a DLL to C#?

Hi Andrew, First, I hate you for making me lose the game. Second, your display picture is great. Third, there is no official support for networking, but all games are feasible with Leadwerks.