L B
-
Posts
967 -
Joined
-
Last visited
Content Type
Blogs
Forums
Store
Gallery
Videos
Posts posted by L B
-
-
Bubbly is the style nowadays? No, bubbly is "Web 2.0" and all the buzz words you may associate with it.
The web isn't glossy bubbles anymore, it evolved to be cleaner, flatter, and more content oriented.
Look at the redesigns over at Google - Gmail, YouTube, G+, even Google itself. Look at Vimeo, Twitter. Show me the bubbles.
I don't dislike the presented design, it's good, but if it's not modernized it won't last for as many years as you'd wish.
-
I will gladly accept any name you choose to give it Josh. I will use it wheter you call the engine The Cookie or Klingon's Nest
However a simple LE3 would be fine with me
Cookie Engine.
CookE.
-
The more I read, the less I like any of them.
-
Erhm, remember this is the Leadwerks3D forum, not LE2!
-
That would mean Leadwerks3D to support WebGL, that is, web browsers, am I right?
I'd tend to say it's impossible at first, judging by the risky nature of executing a DLL, but I'm mighty curious how Unity does it. They do have a web player install though, right? In that case, you'd have to make plugins for these browsers, I think that'd be the simplest way.
-
-
Oh lory, I thought I was in the C# forum, and now I'm assaulted with pointers. I must have gotten lost!
-
I don't really agree here. What you're saying is to push limitations from one language into another... Where I see such design it goes wrong. People won't use the API where they aren't supposed to, duplication of code, bad designs, ...
It might be an option that the API is LeadWerks specific, and that a bridge is specified for each language. To take the FileReader example, custom for C++, C# uses the .NET library, Lua uses the lua capabilities, ...
Don't force your way of working in a language, push the language standards in your way of working.
Yes, this is a valid point for a generalization. But not in our case. Static methods exist in C++, and Lua, so they are as valid as a global method.
Regarding the static classes build-in into the API, this means you need to expose a C interface and call all those functions with p/invoke. Isn't this a waste of time and a performance drainer?
In any case, the only way to expose a DllExport is through procedural calls. This will then be reconverted to OO calls by whichever language wrapper (note that Lua is an exception, with Lua++ and whatnot developed for it, I think).
From LE2, I can tell you this hasn't drained even 1 FPS from me, ever.
Not being documented makes no sense. If the methods are static and have the same name, you only need to document them once. The only difference is where they are and the implementation details.Then you agree, with the static method, they'll be documented. Yay. Everyone happy.
-
I fully trust in what Lazlo has to say about a good C# approach, so be it. Thumbs up
Off topic: Is it a coincidence that "Rimfrost Software" has the same initials as "Roland Stralberg"?
-
Go for a static class called something short, like LE or L3D, and put all LE functions in that class as static methods with DllImport. We can/will put wrapper classes over those anyways.
I think that anything else will lead to inconsistencies and unnecessary problems.
C#/.NET with Leadwerks3D will be supported in an OOP way occifially. There will not be just the DllImport header, but an officially supported class OOP wrapper, like LEO or Leadwerks .NET for LE 2. This is because Leadwerks3D is made to be OOP by design, and not procedural, and the default commandset will be documented in an OOP way.
So this discussion is about how to officially support, in the OOP wrapper, the global methods.
Did I say I liked the static class approach?
-
Don't reinvent the wheel. The .NET libraries offer a lot of functionality out of the box. FileSystem.ReadFile() is just plain evil. Every C#.NET developer knows that he needs to use the .NET streams and readers. Before you implement, I suggest you google what you need to do and there's a fair chance that the .NET library already offers that functionality. That's how .NET developers (we have 300 of them here at work) develop, they just know the most common things and google specific functionality they don't know.
On the other hand, specific LWE functions should just be documented. This documentation can easily be generated from your code.
Yes and no. Remember the Leadwerks API has to work with C++, C, Lua and who knows what other language, which don't all have an easy FileReader available.
And the rest of your post, e.g. classifying "LogToConsole" in a "Logger" class boils down to what I asked Josh, but his concern was that there would be too many undocumented top classes (remember, Logger wouldn't be documented). So instead, I suggested that these static classes were built right into the C++/Lua version, so they'd be consistent with C#, Java and whatever other language. It seems like the best solution so far.
See this wiki page: http://www.leadwerks.com/newwiki/index.php?title=Static_Functions
-
Vector based GUI, yummy.
Meanwhile, let's just get huge images and downscale.
-
Static functions are the way to go. I throw away all the other arguments from our 1 hour long debate, just use static functions.
-
This is marked as [sOLVED];
how did you solve it?
-
A computer simulation is not real life. If you were using PhysX, there would be even more arbitrary problems like this that don't match reality.
Will you fix the bug or not?
-
In a real-life scenario, you can attach an elephant to a rope with a strong metal joint. it won't "vibrate" and go "unstable" if the joint is strong enough.
-
Erhm, ok, 2.51?
-
That's weird, never occured to me. I run W7 Aero DWM.
-
If you use terrain, then you have to restart the application, because changing window size makes the terrain flat. However, since you can use Sculptris 3D terrain, you can resize on the fly also.
Mmm, built-in Sculptris terrain... That would be killer.
-
Make sure you know the difference between LE2 (the current version) and L3D (the new version, coming eventually, in the following year).
This is the forum for L3D. L3D is planned to work on Windows, Mac, Linux, iOS and Android.
-
Or maybe a pre-alpha version of LE3 would be even better
Shh that's in too long, I need joints now. Don't let Josh postpone it so much!
-
Hallelujah, very cool
Next build? -
While building my rope bridge, I set a ball joint to every connecting cylinder of the ropes.
But now I've decided to be a little more realistic, and adjust the masses properly. The rope cylinders have a low mass (rope is not heavy), calculated by density and their volume. The planks have a mass of about 2 kilos, or about 5 pounds.
The problem is, the ropes do not seem to be able to handle that much tension. The bridge just falls into the abyss and the cylinders go crazy trying to hold it back.
In the real world, the masses are OK, so it's the joints that are having a problem.
The way I see it, a joint should be able to handle so much force, in that case the weight of the planks. And it shouldn't "expand", unless I want it to. It should stay solidly in place.
Now the joint stiffness has no effect on that. Lumooja told me the joint strength doesn't work, and to use forces to simulate it. So, what am I doing wrong here? There seems to be a physics parameter I don't have control on, that is, the strength of the joints.
-
tree[d] is great, but generates so much polys.
Werkspace 2.0
in General Discussion
Posted
Web 2.0 is a marketing term. HTML5 is a technical term.
@Josh: I guess it all falls within the radius of your rounded corner, heh?