Roland

Absolutely awesome. This looks like a game that i definitely would not miss. I hope the game will be as good as this start scene, keeping the strange feeling of coming disaster of some kind, keeping it clean from silly looking monster running around or meaningless shooting on everyone that moves in front. This start is so fascinating. And I would not add one extra bit to that piano during this intro. That single piano makes this scene just what it is... strange and a bit worrying of what to come. Adding more to that tune can't make it better. Great job and thanks sharing ... I got really inspired. Roland

Been thinking about this a bit. If try/catch want work - its not the whole world, there is a possibility to solve this by giving us some error-callback that will be called in case of errors, in constructors or elsewhere. Callbacks are no problem from C++ to C#

Procedural... Buy the GG mess then Just joking ;)

Well. Constructors are in fact used in the method CreateShader... right!

This is an outline on what I mean. class Shader { public: virtual void SomeMethod() = 0; protected: Shader() {} }; class OpenGLShader: public Shader { GLenum glprogram; // this one is used by OpenGLShader only public: OpenGLShader() {} void SomeMethod() { // use glprogram ... } } class DirectXShader: public Shader { IDirectXDevice9* pdev ; // just as examle. this one is used by DirectXShader only public: DirectXShader() {} void SomeMethod() { // use pdev .... } } // fictional class to produce graphic objects class GraphicsFactory { Shader* CreateShader() { if( weAreDirectX ) return new DirectXShader() ; else return new OpenGLShader() ; } } // usage void AFuncSomewhereInApp( GraphicsFactory* pFactory ) { Shader* myShader = pFactory->CreateShader() ; myShader->SomeMethod() ; // will call OpenGLShader::SomeMethod if we are in OpenGL mode // and DirectXShader::SomeMethod if we are in Direct mode } A little note: Making GraphicsFactory (or what you call it) a singleton would eliminate the need for sending a GraphicsFactory* around. In this case the usage would be // usage void AFuncSomewhereInApp() { Shader* myShader = GraphicsFactory::Instance()->CreateShader() ; myShader->SomeMethod() ; // will call OpenGLShader::SomeMethod if we are in OpenGL mode // and DirectXShader::SomeMethod if we are in Direct mode } Remember that this is no absolute truth. Its more suggestions on different approaches. All this can be done in so many different ways. The most important part is to hide the DirectX/OpenGL nitty-gritty details from the user. The user should not have to deal with that, nor have to handle any such graphics-system specific variables.

There is only one way to learn and that is by doing, so you are just right on track. Learning on how to avoid mistakes is by doing them. Happy coding

Welcome from Sweden

The returned shader is either a OpenGLShader or DirectXShander. You as user doesn't need to know. Just use the methods in Shader.

Shader* shader = new Shader(graphicsdriver); is of course the correct approach. There is a possibility to simplify all this. Implementing GraphicsDriver as a singleton would eliminate the need for passing the driver as an argument to all objects as shown above. I normally avoid globals or singletons, but in this case it could a possibility, as there will never been more that one (and one only) GraphicsDriver in an application. Just an idea....

I don't quite understand what the problem is here. The implementations of the abstract base (Shader) can have as many extra attributes and methods they need as long as they implements the abstract methods in Shader. The user only handles the Shader class without knowing if its a OpenGL or a DirectX implementation. The Shader base class should be designed as a device independent class. The implementations can do what ever they need to do, and have any kinds of variables and methods to fulfill their mission. The user of Shader should not need to know anything about that. There should not be a static Mesh::Load in my world. The file argument should be in the constructor Mesh myMesh( "abstract::theThing.gmf" ) ; or Mesh* pMyMesh = new Mesh( "abstract::theThing.gmf" ) ; fails to load a mesh will be taken care of in a try/catch statement somewhere.

Well. I have used try/catch for many many projects in commercial products, and they are real I can assure you

It depends on how Box (or its parent object) is designed. Its possible to design in such a way that you can use both methods box->SetPosition( Vec3(0,0,-2), false ) ; or box->SetPosition( 0,0,-2, false ) ; Thats is if the Entity object (the parent of Box) is designed with both type of SetPosition methods like this class Entity { public: void SetPosition( float x, float y, float z, bool b ) ; // New pos using floats void SetPosition( const Vec3& pos, bool b ) ; // New pos using Vec3 }; But how the design will be in the end is up to Josh

try { Graphic* pGraphics=new Graphics(OpenGLGraphicsDriver(),1024,768,4); // assuming that Grahics will throw a GraphicsException on failure // code // code // code // code delete pGraphics ; } catch ( GraphicsException e ) { // Failed to initialze graphics }

-> is used when you are dealing with a variable that is a pointer to an object. . is used when you are dealing an object The * stands for 'pointer' Box box ; // box is an object ; Box* box ; // box is a pointer to a box object Of course you still have to know what you are dealing with, a Vec3 or a Vec4 ...

By the way... Have you guys seen this tool PInvoke Toolkit I use it frequently at work to create cs-code from C++-DLL's and it works like charm.

Just want to straighten this up. I have absolutely nothing against pointers (its not possible to make a program without them) and of course its the best thing to have the needed arguments in a constructor. This makes it impossible to create an object without supplying the needs for it. I do think this misunderstanding comes from the design of LEO, which I originally did as a thin wrapper of the C-API. My own originally design had no Create-methods. All was in the constructors, this was changed on request, I cant quite remember the actual arguments for this, but I have a feeling it was something like fear of pointers and having to delete the objects. But thats history. Just wanted to tell the story behind the Create's in LEO as an explanation of why it was done that way. I do think the understanding of C++ now has increased at Leadwerks and cant see why constructor arguments should be used. The great thing about the constructor arguments is that, if an object needs another object exist, the user is forced to give it in the constructor and does not even has the possibility of forget to give access to the other object. So ... pointers and constructor arguments is the way to go, and I have never stated anything else. Cheers Roland

Yes. Listen to Rick.. try and catch will handle those situation greatly

Haha Rick. Yes. That is exactly what I said. Nothing wrong with pointers. You cant live without them sometimes. So everything is Go.. This is a good sample of that.

That was exactly what I was thinking of.

Yes, agreed. Thats better. I would go even further but thats another story. A simple way to implement the C++ version would be to move the BMX-code into the LEO classes and we would have a new C++ version, compatible with the old LEO and also a bit more OOP oriented than the half-c++ that is suggested. But thats up to Josh and what he thinks is best for all. I just give my personal view of this, and now I'm not even into the programming stuff since I started learning 3D modeling

First impression .... Nice photos.. Your work is so good that it looks like street photos. Really impressing.

Beware of the memory consumption though. 3-4 millions of polys with Voxel is OK, but going over that limit things start to go veryyyyyy slow.

Well. Its easy enough to model in Voxels. The thing is to make the retopology to create a mesh. This has been made more and more easy, still it can be quite hard for complex models. Making such things as buildings or complex technical things with many hard surfaces is still better done using a traditional modeler. Normally you work with both your traditional modeler and 3DCoat together to get all stuff done. Making a complete building in 3DCoat may be possible but not wise, thats done far better with a normal modeler.

Exactly. This is how we do it at my work.

I guess you are talking about Auto-Retopo. The lines are suggestions or hints to the Auto-Retop logic, how you want your edgeloops. This may be critical for animation.