Development Blog

Isn't Shader an abstract class? And OpenGLShader is it's extension? How can constructor return different types?

ArBuz is correct. The extended classes also contain different attributes. For example, the OpenGLShader class has an attribute "int glprogram" which a DirectX shader class would not have.

 

Maybe it would be nice to use different name spaces for each class like this:

Mesh* mesh = Mesh::Load();

Material* material = Material::Create();

 

Although it's not really clear to me why Mesh::Load() would be any better than LoadMesh().

Mesh::Load() is for the OOP interface, LoadMesh() is for the procedural interface. You make the procedural interface by using the OOP interface internally, just like you did in LE2 with BlitzMax.

I think static methods is a good way to go. I think constructor doesn't control memory allocation of the object itself. The compiler with the "new" command does it.

All, that work with pointers must work with objects. I mean both:

Mesh* meshObj=new Mesh("mesh.gmf");
Mesh meshObj("mesh.gmf");

must work. But with the exceptions you can not use second line, right?

 

It will be similar with what Roland suggested

KittenFactory fact;
Kitten* k = fact.CreateFluffy()

But factory will be encapsulated in the class.

Kitten* k=Kitten::CreateFluffy();

 

That is only my thoughts. I'm not as good in programing as you guys.

 

[Edit] Damn I type too slow. Two more posts are made

ArBuz is correct. The extended classes also contain different attributes. For example, the OpenGLShader class has an attribute "int glprogram" which a DirectX shader class would not have.

 

Maybe it would be nice to use different name spaces for each class like this:

Mesh* mesh = Mesh::Load();

Material* material = Material::Create();

 

Although it's not really clear to me why Mesh::Load() would be any better than LoadMesh().

 

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.

You would pass the graphicsdriver to the constructor of Shader(). You would need the graphicsdriver object above anyway in both situations, so instead of saying graphicsdriver->CreateShader() you would do Shader* shader = new Shader(graphicsdriver);

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 can not even try to argue with you because you are by a lot of heads taller than me in programming

I just thought that Shader is a base class. And OpenGLShader and maybe DirectXShader are derived classes.

But as I understand

Shader* shader=new Shader();

allays returns Shader object and it can not return any other derived type. That what I meant.

Does BMax have a try/catch? I mean out of all the languages LE wants to support is it just Lua that doesn't have a try/catch? There is probably a Lua extension that someone wrote to give try/catch functionality.

I can not even try to argue with you because you are by a lot of heads taller than me in programming

I just thought that Shader is a base class. And OpenGLShader and maybe DirectXShader are derived classes.

But as I understand

Shader* shader=new Shader();

allays returns Shader object and it can not return any other derived type. That what I meant.

 

The returned shader is either a OpenGLShader or DirectXShander.

You as user doesn't need to know. Just use the methods in Shader.

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.

This is how things currently work:

class Shader {};

class OpenGLShader : public Shader
{
GLenum glprogram;
};

class DirectXShader : public Shader //purely theoretical for now
{
DXShader dxshader; // I made this up
};

Are you suggesting I do this?:

class Shader {
GLenum glprogram;
DXShader dxshader;
};

class OpenGLShader : public Shader {};

class DirectXShader : public Shader {};

 

Does BMax have a try/catch? I mean out of all the languages LE wants to support is it just Lua that doesn't have a try/catch? There is probably a Lua extension that someone wrote to give try/catch functionality.

I don't think try/catch will work across languages, i.e. C# try/catch is not going to catch C++ exceptions.

Honestly, if the try/catch is out then the ctor usage talk doesn't really need to be had.

@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.

This is how things currently work:

class Shader {};

class OpenGLShader : public Shader
{
GLenum glprogram;
};

class DirectXShader : public Shader //purely theoretical for now
{
DXShader dxshader; // I made this up
};

Are you suggesting I do this?:

class Shader {
GLenum glprogram;
DXShader dxshader;
};

class OpenGLShader : public Shader {};

class DirectXShader : public Shader {};

 

 

I don't think try/catch will work across languages, i.e. C# try/catch is not going to catch C++ exceptions.

 

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.

I hope someone will write a procedural C++ interface for LE3, since that starts to look just like Ogre3D to me

Roland, that is pretty much how it works now, although I am calling it a GraphicsDriver.

 

So I guess we have thoroughly thrashed out the reasoning why constructors really are not very useful?

Roland, that is pretty much how it works now, although I am calling it a GraphicsDriver.

 

So I guess we have thoroughly thrashed out the reasoning why constructors really are not very useful?

 

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

I hope someone will write a procedural C++ interface for LE3, since that starts to look just like Ogre3D to me

Procedural... Buy the GG mess then

Just joking ;)

ctors are very useful. It just so happens you want to target languages that don't handle try/catch and possibly other advanced OO concepts. If the scripting was C# it would be all good. You want to create a library in an OO fashion but still be able to use it with non OO languages. If that's what you are after then there is almost no point in using C++ in an OO fashion because you have to do everything in the lowest common denominator. In that respect you should just keep the C syntax that exists as there is little point in making it OO.

I have an idea. It's funny when your design just perfectly fits something you did not originally intend, but it's as if it was meant to be.

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#

I think callbacks would get messy. The implementation of them would probably be use and most likely a big switch statement to figure out what made the calling error.

 

The only other thing I've seen libraries do is have a GetLastError() function, but I'm not thrilled about that approach either.

Try/catch isn't a problem, but there's simply no way to use the Buffer() constructor to create an OpenGLBuffer. I could do something like this:

Buffer::Buffer()

{

this->internalbufferclasstheuserneversees = GetGraphicsDriver()->CreateRealBuffer(); //Creates some OpenGL-specific class

}

 

But that is an incredible workaround just so constructors can be used to do something they weren't designed for.

You were saying it was a problem because not every language supports it.

 

You are right, you would have to do something like

Buffer* b = new OpenGLBuffer();

 

But you don't want to do that because changing to use DX would require changing all those statements to some DX class.

 

It does seem that if you want to support multiple libraries you would have to create different graphics devices and then have each of those have CreateX() methods to them. Then at that point there is no point to use try/catch because you can check for null.

 

I can't really think of a way to do it otherwise. The factory design might help but it's pretty much the same idea as just using a normal function (for the most part)

I have an idea for exposed constructors function.

Have the default function be LoadMesh and return a Mesh (null on failure), this being exposed.

Now, in the C++ API, make a Mesh constructor:

Mesh::Mesh()
{
   if (!this = LoadMesh()) throw new LoadingException();
}

 

Oh wait, can you assign this in a C++ constructor?

@Lazlo: If Josh wants to use LWE on a wide variety of platform he won't use try-catch error handling (Nintendo ao.).

@Rick: Buffer* b = new OpenGLBuffer; (without brackets, brackets mean a function. It is valid C++, but not so clean code.)

 

And I see a lot of assignment overhead...

Shader* myShader = pFactory->CreateShader();

(sorry Roland, I just copied it from you because it's on this page ).

= a constructor + assignment.

Shader* myShader(pFactory->CreateShader());

= only constructor.

 

I know in most cases you really won't see the difference. But all bits help in game performance...