L B

Undocumented/poorly documented and incomplete for a main-server architecture.

Agreed, but isn't this slower: (That's what I meant) cube = CreateCube(); cube2 = CreateCube(); repeat...

Are you coding in C#? If so, that's very easy.

@Josh's last post: Ew, no, keep your current implementation. @Roland: You beat me to everything I want to say. I can only +1 all of your posts.

I'm just wondering, would creating a cube model be faster than using CreateCube()? This way the model would get instanced and repeated, you could just change its material for texturing.

try { Model* a = new Model("a.gmf"); Model* b = new Model("b.gmf"); Model* c = new Model("c.gmf"); Model* d = new Model("d.gmf"); } catch (LoadingException) { // Do something. } But as Josh pointed out, constructors and exceptions can not be exposed to other languages, so that design can not be done.

Thanks for the link, but the P/Invoke / DllImport has already been completed by Tyler

I am 200% for try/catch and the pointer-oriented syntax. For those who are not used with the -> operator, you've been in garbage-collected environments for way too long Actually, if the syntax turns out like what I posted + try/catch/Exceptions, I might even switch to C++ for development. Introduction to pointers: Link Introduction to exceptions: Link

That would be great, perhaps LE4

I thought the demonstrated syntax was C, I wonder how you get classes in there Lumooja/Roland. Besides, the "object.Load" approach is really bad, as Josh demonstrated. Also, I also want to precise I would use pointers and not objects, but Josh beat me to that too. Lastly, I don't know why you fear constructors, Lumooja. Setting the graphics properties after its creation implies that it exists but is empty, which is strange in my opinion. Here's my ideal code syntax for C++, not C (I feel Josh's one is perfect for C). Graphics* graphics; World* world; Mesh* box; Camera* camera; graphics = new Graphics(OpenGLGraphicsDriver()); graphics->Create(1024, 768, 4); world = new World(); box = new Box(1, 1, 1); // Box : Mesh box->GetMaterial()->SetShader(new Shader("Shaders/minimal.shader")); box->GetMaterial()->SetColor(new Color(255, 0, 0, 255)); // Basically Color is a Vector4 represented as bytes camera = new Camera(); camera->SetClearColor(new Color(0, 255, 0, 255)); box->SetPosition(0, 0, -2, false); float yaw = 0.0f; while (!window->IsClosed()) { yaw++; box->SetRotation(yaw, 0, 0, false); camera->Render(); window->Flip(); }

However, you can still use load. Both syntax are accepted: Mesh loaded = new Mesh("abstract::tree.gmf"); Mesh loaded = Mesh.Load("abstract::tree.gmf");

I actually solved it with this material file: texture0="abstract::glass.dds" texture1="abstract::glassdot3.dds" texture2="tag::rendercolor" texture3="tag::renderdepth" depthmask=0 zsort=1 shader="abstract::mesh_diffuse_bumpmap.vert","abstract::mesh_diffuse_bumpmap_refraction.frag" Thanks to Lumooja for the firepit reference suggestion.

Requested Josh, he said it is not possible at the moment, but that he would try to implement GetFrameworkGraphicsBuffer and GetFrameworkLightingBuffer eventually, which could be in some time. What are your suggested alternatives? Building my own Framewerk, or what?

Trying to use refraction with framework, I found myself stuck having to get the rendering buffers, which I can't access. Example: (Reference tutorial: http://www.leadwerks.com/files/Tutorials/CPP/Transparency_And_Refraction.pdf) using System; using Leadwerks; using Math = Leadwerks.Math; namespace Evol { static class Refraction { static void Main() { try { Engine.Initialize(800, 600); Framework.Initialize(); FileSystem.Initialize(@"C:\Users\Lazlo\Desktop\Refraction"); Filtering.Optimize(); Explorer ex = new Explorer(Framework.Camera); ex.Camera.Position = new Vector3(0, 2, -2); Mesh scene = Mesh.Load("abstract::scene.gmf"); World.Current = Framework.Layers.Transparency.World; Mesh sphere = new Mesh.Sphere(); sphere.Material = Material.Load("abstract::glass_refraction.mat"); //sphere.Material.Textures[2] = Can't get the framework's light buffer? //sphere.Material.Textures[3] = Can't get the framework's graphic buffer? sphere.Position.Y = 2; World.Current = Framework.Layers.Main.World; float refractionStrength = 0.01f; while (!Window.HasRequestedClose) { ex.Update(); if (Keyboard.KeyDown(Key.Up)) { refractionStrength += 0.001f; } if (Keyboard.KeyDown(Key.Down)) { refractionStrength -= 0.001f; } refractionStrength = Math.Max(refractionStrength, 0); sphere.Material.Shader.Pass("refractionstrength", refractionStrength); Timing.Update(); Framework.Update(); Framework.Render(); Graphics.Flip(); } } catch (LeadwerksException e) { Debug.Alert(e); } try { Framework.Dispose(); Engine.Dispose(); } catch { } } } }

A header is the medium between your coding language and the Leadwerks Engine. A wrapper is an object oriented approach to a header - it's basically a OOP header. You can download them at www.middlewerks.com/headers or in the "Downloads" section of Werkspace, under "Tools and Utilities" (look for "32-bit .NET DLL") The documentation is available on the same site. In Visual-Studio documentation will be coming soon. Even though the site says the custom engine.dll is required, it is not. Some custom methods require it, but few of them.

That's because Josh doesn't want user moderators and doesn't have time to clean up. Sorry for the confusion, really can't do anything about it.

If players demand anything out of a game, it isn't indie anymore. Indie is the beauty of development freedom, where the maker should enjoy the game as much or more than the user.

I think lip synchronization is against Josh's mentality, and I agree with him on it: It takes an incredible amount of time to implement, various voice artists, and most of all, it's not needed! It can easily replaced by an off-screen voice-over or, honestly, with not-so-perfect animations. @Betke: I'd really like to see that list too

Love the Microsoft-office badge effect.

I can only assume it is because an exact copy doesn't make it work any more - it is probably a reference problem in that case.

Ok look, let's stop arguing for nothing, and answer the OP, before he gets desperate of our community and goes to Unreal. Trainguy, if you want to do a MMOFPS, go for it and try. Leadwerks will be easier to code in general, but has no network support (it will in LE3). UDK will be harder to code in general, but has networking support and a lot of FPS examples. Now if you want my opinion, I'd buy Leadwerks and get familiar with it, get some experience, then when LE3 comes out with the Networking you need, you should be more than ready to at least realistically attempt making your game.

The transparency world can handle alpha blending as long as the objects are not affected by any deferred rendering lights.

That would be the end of Betke.

If Tyler was there, I could fix some things and release v2.1. :/

And people who go big are those who don't.