Josh

Fascinating story.

Fonts are not loaded from just a dds file. They are loaded from a DDS and an INI file of the same name.

I disagree with 1.1, 2.1, 3.1, and 4.1.

Set the material like this: castshadows=1 nodraw=1

I have not decided how this will be handled yet.

And then we go back to everyone asking for bitmap fonts for their game text.

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.

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

Since C libraries are cross-compiler compatible, yes, I believe you can use the engine DLL with code::blocks, without doing anything fancy.

Textures in LE3 give you more control. You can retrieve all or part of any mipmap of a texture to system memory, edit the texture, then send it back to the GPU. Fortunately, the engine checks the bounds of the texture so you don't have to worry about producing any blue screens of death, as can happen when you're having too much fun with GPU memory. Here's some simple code to retrieve the texture from video memory into a system memory bank, modify it, and send it back to the graphics card: Bank* pixels = new Bank( texture->GetMipmapSize(0) ); texture->GetPixels( pixels ); pixels->PokeByte( (x*height + y)*4, 255 ); texture->SetPixels( pixmap ); There are overloaded functions for raw memory pointers, but the bank syntax has a little extra error checking, since this kind of thing can easily produce BSODs. If you want to get really fancy, there are additional parameters that will let your retrieve or send part of a texture to and from the GPU. This is something I use extensively in the terrain editing routines, which take place on the GPU (that's why terrain editing is so fast). I use a shader to modify part of the terrain heightmap, and then I have to retrieve the modified heightmap back to system memory. Because the textures can be pretty big, it's more efficient to retrieve a sub-rectangle of pixels instead of the whole texture. I ran into some trouble with DDS compression, as the image below demonstrates. This is what happens when you accidentally offset DDS mipmap data by four bytes. (This has been fixed): The texture loader can handle background texture loading, so if you want you can have those cool blurry textures when a level starts, and they get sharper after a few seconds. This cuts the texture load time down to practically zero. If you have a large scene with lots of large textures, this will be nice to cut level load times down. All media files in LE3 can be reloaded with a Reload() class function. This is necessary for some of the art pipeline features in the editor, so it's being built in from the very beginning. It is pretty cool to tap a key and watch your textures reload one mipmap at a time. This also means you can change the texture quality setting on the fly and not worry about reloading textures manually...when you change the texture quality setting the engine will automatically reload all textures that came from a file. As we saw last week, here is the proper way to load a texture and apply it to a material in LE3: Texture* tex = LoadTexture("brickwall01.dds"); mat->SetTexture(tex); delete tex; It occurred to me this can be simplified with an alternate overloaded function: mat->SetTexture("brickwall01.dds"); The same can be done with shaders. If it succeeds, true is returned, otherwise false is returned: mat->SetShader("Shaders/simple.shader"); So that's a nice convenient feature. It was pointed out that my Copy(int unique) syntax was confusing, and I agree, because I couldn't even remember which was which. Therefore you will have an Instance() and Copy() function for textures, shaders, entities, materials, etc. The Instance() function will act like LE2's CopyEntity(), and the Copy() function will make a unique copy that can be modified without altering the original. Texture animation is supported, out of the box. I'm using the old Quake naming convention where you add +framenumber to the end of the texture to specify an animation. For example, if you load "fire+01.dds", the engine will look for "fire+02.dds", "fire+03.dds", etc., until all frames are loaded. The texture will automatically switch frames with an animation speed you specify. It should be possible to convert AVI files into a sequence of separate frames, but I haven't looked into it yet. That's all I have for now. It feels like I am really in the thick of LE3 development now. I've already done most of the graphics stuff with LE2, so I know how to do that. What I am really looking forward to is the high-level features, particularly the script and flowgraph implementation. I like to attack unknowns first, because the more I know, the better I can design the engine. We already know we can do fantastic graphics, and I understand how that all works. It would make sense to focus on areas that I haven't developed as extensively in the past...networking, gameplay, and the art pipeline. Therefore, we may see a Leadwerks 3 beta with just basic graphics and a focus on gameplay features first. Please "like" this blog!

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.

Rename the .pak file to .zip, then extract it anywhere in the SDK directory.

Leadwerks Engine 2 requires a shader model 3 graphics card. There may be some 3D commands you can call without creating a graphics window, but it's not supported. The renderer in version 3.0 is being abstracted out, and a no-graphics renderer for dedicated servers will be provided. Your code will do something like this: SetRenderer( DedicatedServerRenderer() ); And then you can run your normal program calling all 3D commands, with the same results, and no graphics card is required. Of course you won't be able to see anything on the screen, but since it's so easy to switch renderers you can develop your server with graphics on to debug it, then switch to no-graphics mode.

You could by scaling the projection matrix.

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.

Typically, this error means the matrix stack is messed up. Be sure your push/pop matrix commands are identical in number. A lot of people use their own OpenGL commands with LE.

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.

You can't use Max2D with Leadwerks Engine. There's too much that interferes with it.

Are you doing your own OpenGL programming to cause this? It's strange you would be able to produce an error like this otherwise.

It's uploaded here: http://leadwerks.com/werkspace/index.php?/files/file/172-font-studio/ True-type fonts (TTF) are nice, but have problems: -They only work on Windows. -They will disappear if the upper left corner of the text is out of the viewport. -You can't do fancier bitmap font effects with them.

I just uploaded it here as well: http://leadwerks.com/werkspace/index.php?/files/file/172-font-studio/

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

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.

Let's start with some code for making instances and unique copies of a material: Material* mat1 = new Material; mat1->SetColor(0,0,1,1); Material* mat2 = mat1->Copy(true); Material* mat3 = mat1->Copy(false); mat1->SetColor(1,0,0,1); mat1 and 2 will be red. mat3 will be blue. Shaders, textures, and entities work the same way. Drawing commands are in. I like how OpenGL3 gets rid of all the built-in matrix stuff and just lets you deal with pure matrix multiplication. It would probably be pretty difficult for a beginner to get into, but it's much cleaner, and it forced me to learn a little more about matrices. I added a mat4 orthogonal projection class function, if you're interested in that sort of thing. I don't have DrawImage(), SetBlend(), SetColor(), etc. commands in, because the material system can handle all of that, and it's much more powerful. Here's some sample code: Material* mat = LoadMaterial("myimage.mat"); mat->SetColor(1,0,1,0.5); mat->SetBlend(BLEND_ALPHA); mat->Enable() DrawRect(2,2,10,20); mat->Disable() You can also draw polygons onscreen if you want. Vertex positions will correspond to screen coordinates: Material* mat = LoadMaterial("myimage.mat"); Surface* surf = CreateSurface(); surf->AddVertex(0,0,0); surf->AddVertex(0,1,0); surf->AddVertex(0,1,1); surf->AddTriangle(0,1,2); mat->Enable() surf->Draw() mat->Disable() There are two types of multisampling in OpenGL. The older technique uses the graphics window pixel format. The newer technique involves an FBO with a multisample format. I am going to disable the first technique, because normally rendering is performed on an FBO (a Leadwerks "buffer") and you don't want multisampling to mess up your 2D drawing that is typically done after 3D rendering. It also prevents the user from having to recreate a graphics window to toggle antialiasing on and off. So to sum that all up, antialiasing should be as simple as just defining a multisample format when you create a buffer, which can be 1,2,4,8, or 16. I also hired an outside developer to research fluid simulations for ocean water. Here is an early prototype. There's still some improvement to make, but the technique is promising: On to the editor. Here's the prototype. You can see the asset tree on the right, which functions pretty much like Windows Explorer: You can enter a word in the search box, press enter, and the results are instantly filtered. I was surprised at the speed, even with thousands of files: You can right-click on a source art asset and convert it to a final game-ready file format. Here we have a png file you can convert to DDS: And the familiar DDS convert dialog will appear: If you choose the "Reconvert" option, the converter will be run with the last options used to convert that file, without pulling up the options dialog. These settings are stored in a file with the image file, and will be remembered across editor sessions. One of the coolest features is that the editor automatically detects file changes and will ask you to reconvert a file. Or if you prefer, you can set the editor to always perform conversions automatically. Overall, I myself am surprised at the speed with which Leadwerks Engine 3 is taking shape. It's still hard to say exactly when it will be ready, because little details can pop up and take more time, but it's going well.

I like how the figure isn't noticeable immediately, then it kind of scares you. It's like the original Alan Wake game that never got released. Is the soundtrack available anywhere?