Josh

I'm having some problems with constructors. Some objects can fail to load, so obviously we can't do this: Mesh* mesh = new Mesh("car.gmf"); Instead we do this: Mesh* mesh = LoadMesh("car.gmf"); And it may return NULL. So you may say, okay, we'll use LoadMesh and then if we create something we'll use the constructor. But sometimes creation can fail: Graphics* graphics = new Graphics(5000,7842215); Texture* tex = new Texture(16384000,1024); So it means either having an Initialize() class function, a "failedtocreate" attribute, or using constructors for some classes and Create functions for others, unless someone else has a good idea to solve this. If a constructor could return NULL, that would be idea, but that is not possible.

Since LE3 renders things in separate layers, worlds are not really needed for anything anymore. The only reason you would want one is if you had two different "simulations" running that you don't want mixed up. So let's say you had an editor, and in one of the windows you had a model preview, and you just wanted that model and camera by themselves in one world. Well, that's a good case for still using a world class.

Graphics* gfx = new OpenGLDrivers(); // polymorphism tells gfx to use the OpenGLDrivers::CreateCamera() method Camera* camera = gfx->CreateCamera(); Yep, that's exactly how it works. OpenGLGraphicsDriver->CreateCamera returns an OpenGLCamera, which is an extension of the Camera class. Here's what I have implemented, as an alternative approach: GraphicsDriver* graphicsdriver = new OpenGLGraphicsDriver; SetGraphicsDriver(graphicsdriver); camera = CreateCamera(); //alternatively, you could use graphicsdriver->CreateCamera() For a true OO approach we should be doing something like this: GraphicsDriver* graphicsdriver = new OpenGLGraphicsDriver; World* world = graphicsdriver->CreateWorld(); world->CreatePivot(); world->LoadMesh(); But do you really want that? Sometimes it makes sense to call SetWorld() or SetGraphics() and then have it assumed that object is the one that gets used. At what point do we go from good design to just being pedantic? What do you guys and girls think?

Roland and I talked and agreed the approach I am using is best, although he suggested more use of constructors instead of Create() functions.

There's also problems like this: Camera* camera = CreateCamera()// returns an OpenGLCamera object if the OpenGL driver is used //If the DirectX 11 driver is used, it returns a DirectX11Camera object Camera camera; // just a base class camera; the user would have to explicitly declare an OpenGLCamera object, so their code will be different depending on what graphics driver they are using.

Roland, we'll talk. You're like my Jedi master of C++.

Ah, that's what causes that. I have seen that happen on a few profiles. There's a section in the bug tracker for website bugs now, FYI.

Right now, it's doing something like this: window = windowdriver->Create(); I haven't finalized how this will be set up, so I didn't include it. I don't like the -> separator, but using object variables seems like an awful way to design things: Mesh mesh; if (!mesh.Load("mymesh.gmf")) Print("Failed to load mesh"); //The mesh failed to load, but it still exists...ummmm... Versus this: Mesh* mesh = LoadMesh("mymesh.gmf"); if (!mesh) Print("Failed to load mesh"); You'd also have a lot of problems interfacing with external languages if you don't use pointers.

I mean that C++ programmers tend to be attracted to LE, and there aren't as many choices for direct C++ programming.

I thought about doing something like this. I think the best results will be if you use voxel-based modeling that merges with the terrain, the way Crysis did. This is the kind of thing I would hire a third party programmer for to write the algorithm.

Yeah, that's basically what I meant. The result of this would probably be a nice demo that no one could do anything with. I mean, it would be cool, but there are so many other areas to focus on that will go further. Leadwerks is the C++ programmer's engine, and we can take that further with LE3, so I think we will see more middleware and external libs integrated with LE3, officially or otherwise.

Both the Newton vehicle implementations are not working. I implemented my own raycast technique. Newton is fantastic for rigid bodies and joints, but it doesn't seem to be developing any further. I will be investigating alternatives. Bullet is probably the best choice, although I am not completely informed enough to make that decision yet. I hope we can find something that has the precision and stability we have had with Newton joints.

The purpose of the features request forum is so I have a record of requests I can look at any time, and to allow the community to discuss ideas. I do not provide a response most of the time, but I am reading.

It's a little ugly right now. I have a "WindowDriver" and it creates a window. The user may want a standalone window, either fullscreen or not, and that is pretty easy to handle. Where it gets messy is when they have a window of their own, like a panel in a GUI program. That part I have not worked out yet.

Here's some LE3 code for a simple program. The Graphics / Window stuff is not worked out 100%, and it's a little tricky because of the different operating systems and different kinds of windows. I think we'll see a little more consistency across various languages with the LE3 syntax. It was suggested that the C syntax use the following scheme: verb-class-noun SetEntityPosition() GetMaterialTexture() I agree with this suggestion. SetGraphicsDriver( OpenGLGraphicsDriver() ); CreateGraphics(1024,768,4); World* world = CreateWorld(); //Load a shader Shader* shader = LoadShader("Shaders/minimal.shader"); //Create a material; Material* mat = CreateMaterial(); mat->SetShader(shader); mat->SetColor(1,0,0,1); //Create a box; Mesh* box = CreateMeshBox(1,1,1); box->SetMaterial(mat); Camera* camera = CreateCamera(); camera->SetClearColor( Vec4(0,1,0,1) ); box->SetPosition(0,0,-2,false); float yaw = 0.0; while (!window->Closed()) { yaw++; box->SetRotation(yaw,0,0,false); camera->Render(); window->Flip(); }

C++ references won't work with external languages, and many functions want to have an optional NULL parameter. Pointers are used for things that you manually create and destroy, like entities. Objects are used for thing like Vec3s and other temporary structures that are really just glorified float variables. I prefer this: TFormPoint( 1, 2, 3, NULL, entity ); To this: TFormPoint( 1, 2, 3, NullEntity(), entity );

I was determined to get 3D graphics working this week, and I did it. Behold, a box, now with *3D PERSPECTIVE*. Making another variation of the infamous "my first box" demo with OpenGL is certainly nothing to brag about. However, there is quite a lot of code in use beyond just a simple hard-coded demo. The materials, shader, file system, camera, surface, graphics, math, and entity classes are all functioning at various levels of completion. I coded these systems and then used them to make a spinning box. If I had simply set out to make a spinning box and nothing else, it would have required a lot less code, that wouldn't be good for anything else. More importantly, I have got C++ doing everything I did with BlitzMax. I still would not recommend C++ unless you need it for some specific reason, but I am very comfortable with it. I've run into a number of bugs and problems I was able to fix without too much trouble, and the debugging tools that come with MS Visual Studio are adequate. Besides the funny syntax, C++ is not really any different than programming in any other object-oriented language, so don't let anyone make you feel bad if you prefer C#, BlitzMax, or something else. One interesting problem was dealing with the lack of garbage collection in C++. I am not a fan of garbage collection, but some kind of smart handling of resources is needed. When you have objects that can be assigned to other objects and passed around, managing them can be a nightmare. I could pass the responsibility onto the end user, but it would be very problematic to keep track of which material's textures need to be manually deleted. I used the following solution. When something like a shader is assigned to something like a material, a copy of the shader is actually made. The copy is just a pointer that has the same ShaderReference object in the "reference" member. The ShaderReference instance count gets incremented. When a shader is deleted, the ShaderReference instance count gets decremented, and when the count reaches 0 the ShaderReference is deleted. Wow, that sounded confusing. Let me illustrate with some code showing how resources are managed in LE3: Material* mat = CreateMaterial(); Texture* tex = LoadTexture("rock.dds"); mat->SetTexture(tex,0); delete tex; // Don't worry, you are fine! delete mat; // Internal copy of texture will be deleted, along with the //TextureReference object that contains the OpenGL texture data It's pretty hard to crash the engine by accidentally deleting a texture that is in use somewhere else. The reference / instance system is a lot more advanced in LE3, and also allows copies of most objects to be made, either as an instance or as a new unique copy. Cool, huh? I love OpenGL3. The way they cleaned up GLSL and just made everything user-defined abstract data is fantastic. Cannot wait to get into it further! In completely unrelated news, I have an idea for another website that is oriented towards video game consumers rather than developers. It's an interesting idea...we'll see if it materializes over the next six months or so. There's also a major site feature coming to leadwerks.com in October. I am very excited about it, but I'm not ready to say what it is yet, so all I can do right now is make ambiguously optimistic statements. Here is the game I referenced in the title. This was the first 3D graphics I think I ever saw, and I was blown away at the time. The soundtrack is pretty rockin', too. I am getting a lot of work done. Have a good week and have fun!

It's not a high priority because even if it were implemented and 100% working, it would still require a lot of effort to make a character with lip syncing, record speech, do whatever is required to set it up, etc. There are other things I can focus on that will be more useful for more people. Having support for this feature doesn't mean you could just drag a character into the scene and have it work. It would still take a tremendous amount of work to get your own models talking.

I'm only interested in this for the sake of professional studios. Independent developers are unlikely to make use of it.

Build a simpler collision shape for physics. You should not use complex meshes like that for the physics.

The current version of Leadwerks Engine does have network commands.

What programming language?

I don't know, my first programming project was to write a 3D engine, and I am still working on it. I only learned programming because that is what I had to do to make it happen. I certainly didn't learn C++ because I like programming. I can see the argument for making something small of limited scope, if you want to get a sellable game done in a reasonable amount of time. However, I can also understand someone who just learns what they need to and does whatever it takes to make their idea happen, even if they have to stretch themselves to achieve that.

Why would you want SpeedTree? Our vegetation system can render much larger amounts of foliage than that. I talked to SpeedTree employees about this, and it is definitely not the angle they want to take. They want to sell the vegetation rendering code, not a tree modeling program. Because the modeling program can export .fbx, you can just register for the evaluation version and use that to make trees. No idea what the licensing terms on that would be.

He's probably got more free time in the next few years than he ever will again in his life. I started programming when I was in college.