TheRhinoDude

API semantics and setters and getters vs. "traditional" properties are really all a moot point IMO. Seriously, there are bigger issues. And you are correct, it's not about official vs. community vs. whatever. The reason I started the thread was to learn the state of it, to determine if I would have to be taking on this work myself, because as I stated I never rely on the community (but I don't mind consuming what they've already built if it saves me time). But more importantly, the point is to determine the PERFORMANCE ISSUES others have run into, if any, when using the procedural wrappers. I get the feeling there has been a whole lotta wrapping, but not a whole lotta using. Which scares me. For example, a lot of people have apparantly abandoned their C# LE projects. Now, with hobbyists this happens a lot anyway, regardless of the language. But how often has this happened because they ran into a fundamental problem and the only "solution" was to abandon ship and start over w/o C#? This is the kind of info I'm trying to figure out. I'm sorry if a lot of this info already exists in the C# forum, but I can't read that. Plus, the other C# thread here I was particpating in just got moved (probably to the C# forum), so I can't see the replies there now either. ;-( - Rhino

Ahh...LE3 is targetting Mac and/or Linux? So it won't be Windows only? If so that would make Mono support far more desirable, which would invalidate C++ Interop anyway, as it's Windows only. Rhino

Yes, that would be ideal. There is a lot of synergy which comes out of that, not the least of which is applicability of examples, documentation, and so forth. However, that may be problematic unless Josh designs for it up front. Things like multiple inheritance and certain template features are hard to implement in C#. Besides, if a primary design goal was official C# support that matched the internal OO model, then I think there is a bettery way to go about it: C++ Interop (more on that below). OK so that's interesting (and is opposite of what was said earlier). So essentialy it had it's own PInvoke declarations (even if they were a direct source-copy) and didn't usethe other DLL. Good. I'm hot on the idea. ;-) I'm sure it would save me some time, especially if the wrapper is already very .Net-ish, as that's how I roll. The .Net runtime is wonderful in it's consistency of implementation, and if what you've come up with has a similar look and feel then I'm sure it would save me a lot of effort. Part of the issue I see with C# and LE3 going forward is it's going to become a layercake situation if you assume the solution should be architected the way it is today. If I'm understanding LE2 architecure correctly, today the procedural layer essentially is the engine. But with LE3+ it's going to be a layer built on top of the engine. Then PInvoke acts as an interop / marshalling layer on top fo that. Then there's an OO C# layer on top of that. Sure, the change in LE3 architecture will affect all languages that use the procedural layer, but PInvoke is like adding insult to injury. ;-) It's clearly more work for Josh (or the community), but perhaps a better way to support C# would be through Managed C++ (C++ Interop) classes that extend the new C++ engine classes for LE3. That not only provides a level of type-safety that doesn't otherwise exist, but it is also faster (in some cases a LOT faster) at marshalling data since it does a simple bit-copy with no data wrangling needed. It would be a lot faster. More info... http://msdn.microsoft.com/en-us/library/ky8kkddw(v=vs.80).aspx Of course, no Mono support...but since we're talking Windows only that's really not a huge deal, is it? And if you really wanted to use Mono, then just use the procedural layer and PInvoke. In summary, if the goal was to have a C# OO class hierarchy that matches the C++ hierarchy, then going through the future procedural layer via PInvoke really isn't the best way to do it. Furthermore, if tne new LE3 classes are designed with the knowledge that they will have a C++ Interop layer wrapped around them (pretty please Josh), then adding and mainting such a layer will essentially become a fairly trivial bookkeeping exercise (I've written code generators that do this for me). In theory wouldn't be too much extra effort to support, because the same set of documentation and examples apply to both. . - Rhino

Well that helps me decide betwen LE.Net and Leadwerks.Net. One less thing out of 938 I have to figure out. ;-) Seriously though, I had pretty much decided that I would be writing my own OO layer given the upcoming changes for LE3. Lazlo, in your experience implementing and working with Leadwerks.Net, what kind of PInvoke perf hit were you seeing when using LE.Net? Were there certain api's that became problematic? In my experience with C#, when PInvoking an API design that results in many frequent API calls to fast functions can result in huge perf problems due to the invocation overhead. For example, math library invocations, coordinate transforms, etc. Doing them in a deep, tight loop can really slow things down. Did you run into this kind of problem, which required you to reimplement some of LE on th managed side to avoid the bottlenecks? Or worse, run into any such scnearios that you weren't able to workaround? Any pointers or best practices or pitfalls worth mentioning? Other than GC woes? If there are already such posts, please just link them here, and once I purchase I'll be able to read them. Thanks, Rhino

Of course, surely when making other big changes you might as well get the conventions set. Consistency in naming trumps nice sounding names. If for the most part we are talking essentially the same parameter sets but different function names, then that's no biggie as search/replace can take care of that easily enough. What I'm more concerned about is if how things work fundamentally changes from LE2 to LE3 and thus require significant logic changes in order to port. Thanks for providing the latest LE3 listing. I'll compare it against the LE2 listing and get an idea for myself (assuming it's in the eval kit). Does anybody have any downloadable LE C# example games or walkthroughs or demo's? Just something to get an idea on performance. Would love to see if anybody has written something that loads the same datasets from both C# and C++ so you can get a idea of the perf hit taken. I have to think somebody has doen research into this... And finally, I know better than to ask for a release date for LE3, but is it expected that it will be a 2011 release? 2012? Thanks, Rhino

Thanks for the overview, that makes perfect sense, and I've seen (and built) similar constructs before. Now that you are deep in LE3 impl, how compatible is the LE3 DLL procededural interface going to be to the LE2 interface? Surely there will be additions, but do you foresee large changes in the API set given the new engine architecture? Or if it a design goal to ensure / maximize compatibility? I assume that today the LE2 procedure interface exposes close to if not 100% of the LE BlitzMax implementation. Will this be true as well with the DLL procedural interface for LE3? Thanks, Rhino

Thanks again for the prompt reply. That is very helpful. Now that is interesting. I wasn't aware that was the current LE architecture...if I am reading between the lines correctly. So LE internally is written in C (or C++), and the engine interface / API are simply DLL entrypoints? Such that LE.Net is essentially a PInvoke wrapper? If so, are there any plans (public or otherwise) to drop such an architecture for Leadwerks in the near or mid-term future and move to C++ classes at the core and essentially kill LE.Net / pinvoke solution? Such an architecture would essentially kill LE.Net going forward from that point, right? I can easily maintain my own very tight wrapper which are simply PInvoke declarations, which is what it sounds like LET.Net is. That's not a problem; I did that years ago with PowerRender back when it was implemented in 'C'. But when it was re-implemented in C++, I was hosed. I don't want to have the same thing happen twice if possible. ;-) Thanks, Rhino

Thanks for the reply folks. Rick, can you elaborate on what exactly you mean by this: Edit: just read that Leadwerks.Net is built on top of LE.Net bindings. so rest of post was irrelevant and has been deleted. Thanks, Rhino

Hey folks, New here and wondering if C# is "officially" supported and up to date feature-wise? In particular: - Is there any part of the engine that is not exposed via C# "headers" that are exposed to other languages such as C++? - When new versions are released, are up to date C# "headers" available immediately as part of the main download? What I'm trying to avoid is some form of "community supported" layer. Been there. Done that. Wasn't fun. ;-) Obviously there will be a perf hit with C#, but that's irrelevant for this project. Thanks in advance for any info / advice. - Rhino