[Job at Microsoft - All Thanks to Leadwerks and its Community]

Fascinating story.

[Textures in Leadwerks Engine 3]

Will every license holder have access to the beta?

I have not decided how this will be handled yet.

[Textures in Leadwerks Engine 3]

I would like to know if we can expect the beta i november or december to organize my project correctly :s

So would I, but at this point your guess is as good as mine. I am terrible at predicting development times, and I don't want to compromise anything by trying to hurry it up to meet a schedule. Obviously, I would like to have a beta available in November, but I don't know whether that will happen.

[Textures in Leadwerks Engine 3]

I don't know how much the read/write pixel stuff can be made because a single pixel can use 1, 2, 3, 4, 8, or 16 bytes, depending on the format. I thought about a WritePixel() command where one of the parameters was a pointer to the pixel data, that had to be in the required format and length, but that was even more confusing. Additionally, DDS data stores pixel data in blocks, and you can't really write a single pixel, although you can still manipulate the data. Therefore it seemed best to just let the programmer use a memory pointer and read/write the data how they like, because it will be different for each format. I could do a WritePixel() command that accepted four floats and converted that to the proper format, but that's imprecise and probably not as good as writing the exact values in the correct format.

 

It's also possible to add your own texture loaders with this:

tex = new Texture(512,512,TEXTURE_MIPMAPS);
tex->SetPixels( mipmap0, 0 );
tex->SetPixels( mipmap1, 1 );
tex->SetPixels( mipmap2, 2 );
tex->SetPixels( mipmap3, 3 );
tex->SetPixels( mipmap4, 4 );
tex->SetPixels( mipmap5, 5 );
tex->SetPixels( mipmap6, 6 );
tex->SetPixels( mipmap7, 7 );
tex->SetPixels( mipmap8, 8 );

Or maybe:

tex = new Texture(512,512,TEXTURE_MIPMAPS);
tex->SetPixels( mipmap0, 0 );
tex->GenMipmaps();

[Further down the rabbit::hole]

I am inclined to agree with the suggestion about not using the copy flag, since I can't even remember which is which. Therefore each media class will have the following functions:

Media::Copy();//Makes a unique copy
Media::Instance();//like LE2's CopyEntity(), etc.

[My GUI]

The 3x3 system is probably the most versatile, and you just have to code that once, then the user can change the images. I prefer a system where none of the sizes are hard-coded, but rather the dimensions of the images dictate the layout.

[Further down the rabbit::hole]

I thought about this, but I actually don't want there to be a new interface to learn. I want people to know how to use the interface immediately. The features are the point, not the interface.

 

If you just think the Windows interface is ugly, perhaps you should consider Leadwerks for Mac.

[Further down the rabbit::hole]

It will probably be possible to add your own converters, as well, and have them integrate into the editor like that.

[Further down the rabbit::hole]

Entity matrices and colors are always unique for each copy or instance. The engine also doesn't attempt to instance entities the way you might in 3ds max or something, where changing the color of one might affect other instances. The copying/instancing just affects the loaded mesh data, so you can create a unique copy and apply different materials or alter the mesh without affecting others.

[Some sample LE3 code]

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.

[Some sample LE3 code]

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.

[Some sample LE3 code]

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?

[Some sample LE3 code]

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.

[Just to say Hi !]

I love your site. Be sure to make your feature requests for LE3 for anything that will help you.

[Some sample LE3 code]

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().

[Some sample LE3 code]

Another problem with constructors:

 

This returns an OpenGLShader object when the OpenGLDriver is in use:

Shader* shader = graphicsdriver->CreateShader();

 

This would just create the base Shader class, which has no actual code in it that makes a shader work:

Shader* shader = new Shader();

 

You would have to do this:

Shader* shader = new OpenGLShader();

 

And now your code becomes specific to one graphics driver.

[Some sample LE3 code]

So, if we have 10 models to load we will need write try/catch 10 times for each model, right?

Wouldn't you need to check to see if LoadMesh() returns NULL anyways?

 

Of course, we have the problem of worrying about how this is going to work with Lua and other languages.

[Some sample LE3 code]

Yes, most commands will have overloads like this:

SetPosition(x,y,z)

SetPosition(Vec3)

 

For inputting floats, the default function will be to send the float values, and then internally the overloaded functions will just call that, i.e.:

void Entity::SetPosition(const Vec3& position, const bool& global)
{
SetPosition(position.x,position.y,position.z,global);
}

LuaBind works nicely with C++ and allows function overloading, something that was not possible with Lua in LE2, so in Lua you can do this:

entity:SetPosition(1,2,3)
entity:SetPosition(entity2.position)
x = entity.position.x

After reviewing the alternatives, I am 100% happy with Lua. It works really well together with C++, and it runs on everything.

 

I agree, the -> separator is ugly and inconvenient, but that's really a complaint of the C++ language itself. When Codewerks arrives, you'll be able to produce the same executables with the same C++ compilers, using a saner syntax.

[Some sample LE3 code]

That's an idea. It's a pretty fundamental change in design. Typically, you would code in such a way that your program can handle missing files, etc.

[Some sample LE3 code]

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.

[Some sample LE3 code]

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.

[Some sample LE3 code]

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?

[Some sample LE3 code]

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

[Some sample LE3 code]

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.

[Some sample LE3 code]

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