The fantastic Fatcow icon set was recommended to me in the comments in a previous blog post. These are very similar to the Silk icon set, but come in 32x32 and 16x16 versions, have more icons, and better coloration. The Silk icon set is sort of a desaturated pastel tone I don't like, and Fat Cow's icons are more saturated and bright. I had actually considered running the Silk icons through a color-correction algorithm, but Fat Cow has already done the work for me.
I knew from the start I
I hired a local Android developer to get Leadwerks 3.0 running on Android devices. We don't know a lot yet, other than that we have an OpenGLES renderer, and everything should be cross-platform compilable. The Android version of LE3 is using a minimum requirement of Android 2.2, which is the lowest version that supports OpenGL ES 2.0. This will run on about 75% of Android devices:
As you can see here, the proportion of 2.1 devices is steadily dropping. If a linear rate of decrease i
I am usually very excited to read about new graphical techniques, and even new hardware approaches, even if they are presently impractical for real use. I was very interested in Intel's Larabee project, even though I didn't expect to see usable results for years.
However, sometimes articles get published which are nothing but snake oil to raise stock prices. The uninformed reader doesn't know the difference, and these articles are usually written in such a way that they sound authoritative
It took a while to figure out, but I was able to get drag and drop interaction working on OSX. (Thanks to Seb Hollington for helping with the coordinate transformation stuff.) Now the editor lets you assign textures by dragging them onto texture slots, just the same as on Windows. There's one last step before the editor code becomes totally platform-agnostic. A file system watcher needs to be implemented on Mac. On Windows, this was fairly straightforward, because there is a built-in API fo
So here's what it took to get Leadwerks running on the iPhone:
Let's start at the point we had the C++ code building and running with an OpenGL 1 renderer on OSX. I was worried OpenGLES might be a dramatically different API that required a whole new learning curve, but I was pleasantly surprised. It's just a stripped-down version of OpenGL, more like OpenGL 3.3 than anything else. Making the OpenGL2ES renderer was mostly just a copy and paste operation, and then I had to comment out a few
There's a new set of pages for Leadwerks Engine 2 up. I think these do a better job communicating all the features of LE2, and explain why it's unique and awesome. Existing users might even learn something from the material:
http://www.leadwerks.com/werkspace/page/Products/le2
This also integrates into the forum skin. The only page left on the site that isn't using the global forum template is the 3D World Studio page, and that will be changed shortly.
The 2.43 evaluation kit will be
A few weeks ago, I was getting pretty nervous about all the known unknowns in going cross-platform with the Leadwerks Engine 3 code. All my libraries and languages are platform-agnostic, but there's always going to be small issues, and I wanted to get those worked out while the code was still malleable. Here's a few things I found.
-OSX file paths don't have a drive letter, so the only way to specify a relative path is to add ".\" to the beginning. This had some significant implications f
So after a lot of learning and mistakes, I finally have Leadwerks Engine 3 running on OSX Snow Leapord, Lion, and iOS. Rather than write out a detailed blog, I'll just throw a lot of random thoughts your way:
-OpenGLES2 is a nice blend of OpenGL 2 and OpenGL 3.3. I'm really surprised my OpenGL 3 shaders translate easily into OpenGLES2 shader code, with only a few changes. In fact, the iOS renderer looks exactly like the deferred OpenGL 3 renderer, except for shadows and some post-effects.
Leadwerks Engine 2.43
...will be released tomorrow, along with a new source distro. I've fixed a number of bugs, but I don't like compiling releases when I am tired because there's a lot of little steps to mess up, so I will do it in the morning.
Leadwerks Engine 3
Optics was always my favorite subject in physics, and I've been getting some amazing results lately by modeling computer graphics after real lighting phenomena.
Once I decided to make the materials system like 3ds max, ever
The C++ object debugger for Lua is working now. It was a little tricky, but I implemented a method to view all members of C++ objects. The debugger does handle dynamic object fetching, so if you expand a node in the debug tree representing a C++ object, the contents of that object will be loaded and displayed. Let's say you have an entity parented to another entity. This allows you to expand the parent member of the child, then find the child in the parent's child list, and so on, ad infinit
The script editor and Lua implementation is very close to being a usable programming environment. You can actually see the pointers to the C++ objects you create, and step through code. It's still missing features, but the parts I was worried about are working.
I am adding Lua commands like crazy, and it's easy to keep track of them because they all reside in one header file. The function overloading is great, as you can see in my example here, where I use a single float value to set the
While working with zlib, I implemented the package system, and it turned out really cool. Here's some stuff you can do
First, let's load the package and register it in the file system:
Package* pak = ReadPackage("mystuff.pak"); //Read the package
RegisterPackage(pak); //Register package into file system
Read a file from a package, just as if it were on the hard drive:
Stream* stream = ReadFile("mystuff/new document.txt"); //Read a file straight out of the package!
Write a file t
Two issues in the art pipeline were giving me some doubt. I stopped working on them a couple weeks ago, and I'm glad I did because the solutions became clear to me.
Shader Files First, there is the matter of shaders. A shader can actually consist of half a dozen files:bumpmapped.opengl3.vert
bumpmapped.opengl3.frag
bumpmapped.opengl4.vert
bumpmapped.opengl4.vert
bumpmapped.opengles.vert
bumpmapped.opengles.vert
I originally thought the .shd extension would be good for shaders, i
This blog is going to actually be about business rather than technology. Here's what's going to happen this summer:
First, we need to get this ATI driver bug fixed ASAP. Nothing else can happen until that gets fixed:
http://www.leadwerks.com/werkspace/tracker/issue-165-terrain-textures-bug-radeon-hd-5850
The official documentation is coming along well, and I am really pleased with how this has turned out. (Thanks, Aggror!)
An updated evaluation kit with some limited programming w
With Luabind, it turns out we don't even need a table associated with an entity. We can just add values and functions straight to Lua's representation of that entity in the virtual machine! So instead of this:
object.health=100
object.entity:SetPosition(1,2,3)
You can just do this, which is much nicer!:
entity.health=100
entity:SetPosition(1,2,3)
So there's no object/actor nonsense, you just work directly with the entity itself.
Entity Keys The Get/SetKey convention from Lea
In Leadwerks Engine 3, you can load a script and attach it to any entity. You can attach multiple scripts to any entity, and they will be called in the order they were attached. Right now, I am calling the script-side table "actor" because it is a little more descriptive than "object" but I'm not sure about all the syntax yet. Below is a sample script for a sliding door. When you attach this to a model, the script will control its behavior:
-----------------------------
-- Sliding door sc
We've transferred the site data to a dedicated server hosted with wiredtree. I've filed a ticket with invision power services to configure the new server. When that is confirmed to be working I'll retransfer the database to make sure all posts are saved and change the domain nameservers and A record.
I also have an update for the site skin that is supposed to fix most of the issues reported, but I want to make sure things are working right before installing it.
Then we'll get back to w
Below is raw output from the Lua debugger. It displays all variables, tables, and functions in the Lua script call stack. This will be displayed in a nice treeview interface that looks much better, but I found this terribly exciting.
You'll notice that tables don't get expanded, even though I have the ability to display all the values in a table. The reason they don't get expanded is because tables can contain tables, including tables that might be found elsewhere in the program. This ca
Last week I compiled the engine into a DLL and a static lib. That was pretty painless, and I have the project set up so it's easy to switch back and forth. I still haven't got Code::Blocks compiling right, which I will need for the Linux build. It can't seem to find any libs, but it's not too important yet.
After altering the behavior of the MaxGUI canvas slightly, I was able to load the engine DLL in BlitzMax and display 3D rendering on a windowed application. It's very easy to do this
When I saw specs for the graphics card they are using in the new iMacs, I knew it was time for Leadwerks to come to Mac. Steam for Mac also recently came out, so the time seems right for Mac gaming. Of course, some guy blew up the Roseville Galleria, so the Apple store was closed. I ordered the 27" iMac with a 3.2 ghz dual core processor and upgraded the graphics card to an ATI 5750. Here's what they sent me:
The computer case/monitor (it's all one piece) is a solid piece of aluminum that
I spent a lot of time last weekend making sure resources are correctly shared between rendering contexts. It's surprising how many commercial games make you restart the game to switch graphics resolutions, and I find it annoying. Leadwerks Engine 3 uses a small hidden window with an OpenGL context to create the OpenGL 3.3 contexts, and it just stays open so there is always a persistent context with which resources are shared. Textures, shaders, and vertex buffers can all be shared between Ope
I can now load models in Leadwerks Engine 3 (as of this morning):
Edit - Here's a demonstration of buffers working (as of this afternoon):
Edit - And here's a comparison of a multisampled buffer next to a regular one (as of this evening):
It's nice to see a feature in Leadwerks 3.0 that 2.0 doesn't have.
I'm getting my iMac this week. I'm going for the dual core 3.2 ghz with an upgrade to an ATI Radeon 5750. Mac is still using OpenGL 2.1, and I have no idea how good the drivers ar
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:
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
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() );
Cre