L B

Please refer to Klepto2 or Tyler for updates on C# now. The source has been released if you want to fix it yourself.

http://localhostr.com/files/d1f5ed/Leadwerks%20Source.zip Enjoy NOTE: This source might lack the picks, callbacks and delegates. In this case, I leave it up to Tyler and Klepto to fix it and add them in. Hopefully someone will take on the development.

Apparently this function has been renamed. I'll have to look into it. I'm really not into Leadwerks development at the moment, so I'll just post the source for you to adapt it.

Why don't you try (right click task bar, "Properties..." Check: Use small icons Combine: Never combine, show labels You should get the classic feel you're looking for.

Just thought I'd share the link: New Features in C# 4.0 Including optional parameters (will be useful for the C#LE wrapper): public void Initialize(int width = 800, int height = 600, int depth = 32, int hertz = 60, int flags = (int)BufferType.Color) { ... } Named parameters (useful for users) Graphics.Initialize(1024, 768, hertz : 75); Dynamic objects, with calls and methods calculated at runtime: dynamic test = GetDynamicObject(...); test.NotDefined(2); Will work even though the type of "test" is not determined. A Runtime Exception will be thrown if the method does not exist. Looking forward to this new version

I could as well. I simply lost some interest, but mostly a lot of time to give to Leadwerks development. Klepto has proposed to do it, I will send him the source tonight. Then hopefully, he will send me his modifications and I'll be able to publish V.1.21.

Sorry, not much time on my hands.

Your download seems to have corrupted. You are supposed to have a "Leadwerks.dll".

Lumooja, let's please not start a language war. There are many of these around the internet, if you feel like it.

Mmm... cheese road. *Drools* Sorry, can't help, so I say useless things.

I will implement the buffer features you requested by 1.3. However, I cannot do anything about the conflicting classes, unless you want it to be called "Leadwerks.LeadwerksBuffer". Just use the namespace prefix in the designated contexts.

...

There would be a /CSharp directory if the headers were officially supported. That might be coming soon.

Title says it all. Will look at it AOAP.

Thanks Tyler for that, I'm basically a wrapper. I'll open a thread for reports and suggestions.

I'm not interested by that extra-detailed load function yet as many of the users seem to be now. However, the other thread can make all the calculations, analysis and data exchange, and then simply tell the client what to do. That's my vision of multithreading advantages. You're asking for a progress report on the loading function and for locking the main thread. It's really simple to call engine commands from another thread - I did. There isn't any limitation. But you'll lose a frame in the process while you have to lock it.

I'd need to see some code and folder structure, it seems to act quite strangely on your side. Why can't Lua files be in the Abstract Path directory instead of adjacent to the EXE? I requested that feature. Can't remember why it got denied or delayed, but it did.

LE can only process actions once every loop - just as any engine would. The point of my use of multithreading is of allowing other threads to tell LE which actions to execute at the closest possible loop, a.k.a. almost instantly as we are talking about fractions of fractions of seconds.

Here's mine, tell me if you still get trouble after that: Graphics.Initialize(1024, 768); Framework.Initialize(true); FileSystem.AbstractPath = @"C:\Program Files\Leadwerks Engine 3.0"; Scene.Load(@"abstract::test.sbx"); EDIT: Make sure your script directory is in the executable library, as lights are scripts.

The engine has that function. Are you using Framewerk? If so, don't forget to set "true" to "enableLua". If not, make the "GlobalKey" for your world "world_main". Framewerk.Initialize(true); or new World().GlobalKey = "world_main";

Not possible. This requires making LE calls, so it would all end up as if it was the main LE thread doing it, or it would crash. Don't bother trying to make multiple threads for that, just use the main one. Still, accessing objects across worlds is not possible at the moment. I could explain, but in C#. Tell me if you want, I'll PM you.

For OpenGL coders, see the OpenGL detailed version changes. For Leadwerks coders, nothing. For Leadwerks, probably nothing either, we're not even at OGL3 yet.

I made a method queue for transmitting. My second thread transmits a method to the first one (LE), and the first one dequeues it at every loop^, executing the command.

Update: Version 1.2 out as beta, with fixed raycasts and picks. Please test it and report any bug.

Not using raycast at all, unfortunately.