Jump to content
Ultra Engine Community

Josh

Staff
 View Profile  See their activity

  • Posts

    23,126

  • Joined

  • Last visited

 Content Type 

Blog Entries posted by Josh

  1. Josh
    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 in LE3:

    gadget:Byte Ptr = CreateWindowsCustomGadget( QueryGadget(canvas,QUERY_HWND) ) context:Byte Ptr = CreateContext( gadget )
    Or with C:

    Gadget* gadget = CreateWindowsCustomGadget( HWND hwnd ); Context* context = CreateContext( gadget );
    The editor is taking shape, though it is still very early. It feels like a cross between Visual Studio and Valve Hammer Editor (Worldcraft) which are both programs I like a lot.

    I knew from the beginning the only acceptable way to display assets would be a draggable, multi-select treeview with icons. For the scene hierarchy, I wanted checkboxes and icons. I looked at ways to hack the Windows treeviews and I looked at wxWidgets, and didn't find anything suitable that would work on all platforms. At last resort, I started writing my own custom control on a graphics window, and I'm getting surprisingly good results with that. The behavior is about 60% functional now, and it's faster than the Windows tree view because it's completely hardware accelerated. The only problem is that the FreeType text does not match the Windows GUI font 100% completely, even though it's using the same font and size. I'll see if there's anything I can do to make it match more closely.
     
    The reason I am spending so much time on this tree control is because drag and drop is used everywhere in the new editor. You can drag a texture onto a material, drag a material onto a model, rearrange nodes in the scene hierarchy, and even move files around on your hard drive. So it's not surprising if some customization is needed to support this functionality.
     
    Knowing the kinds of things people want to do like copy all used assets into a folder ("Publish") and import a bunch of models they downloaded off the internets, it's kind of fun to design interfaces to make development easier. My goal for the LE3 editor is to have more of an established official procedure for everything, along with extensive documentation. I've gotten lots of feedback from some fantastic artists, so I know what will help them get a large project done faster.
     
    That's all for now. I've got a lot to do!
  2. Josh

    iWerks

    By Josh,

    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 doesn't bend or crackle when you pick it up, like most PC equipment. It's very nice to have a solid geometric shape with such stability.
     
    The keyboard looks weird at first, but I got used to typing on the low flat keys very quickly. The mouse has a touch surface instead of a mouse wheel, which works well for scrolling pages, but doesn't work at all for switching weapons in a game. The shape of the mouse is not very ergonomic, and I don't think I will be able to use it for extended periods of time unless I figure out a better way to hold it. The mouse and keyboard are both wireless. In fact, I have a computer with speakers, mouse, keyboard, camera, and internet, and only one cord is coming out of it, for power. It definitely cuts down on space and mess.
     
    The monitor is the most beautiful I have ever seen. It's 27 inches with a native resolution of 2560x1440. At that resolution, you can't even see the individual pixels. The desktop background looks like a photograph because you can't see pixels. I have a black and white photo in the background and I can see individual grains of sand on a beach. It's really incredible. Unfortunately, the OS has not adjusted to this fine resolution. There is no way to adjust the font size for the whole interface, so if you have the monitor set at its native resolution you will be looking at text that would be about a size 6 or 7 on a 1920x1080 monitor of the same physical size. You can lower the resolution, but then text gets slightly blurred. A few programs like Xcode and Safari let you adjust some of the text sizes, so that is what I am getting by with for now. This giant image is squeezed onto a 27" monitor:

    The speakers embedded in the monitor (that I didn't even know existed) are surprisingly good. I sort of got used to my bass-heavy Altec Lansing speakers with bad shielding and a constant buzz. It's nice to have good clear speakers and no subwoofer to trip over.
     
    The ATI 5750 has 720 stream processors (equivalent to about 144 NVidia stream processors) but I was apprehensive about performance because it is a mobile card. Source engine games ran great with max settings at the monitor's native resolution of 2560x1440. Remember, this is running in native OSX, not Windows with boot camp:

    I wanted to see how a more demanding engine would do, so I installed Windows 7 on a separate partition and ran Crysis. I was surprised to see the game running with max settings at about 18 frames per second, at the monitor's massive resolution. Of course, lowering the screen resolution improved performance. So that was not bad at all.

    I spent some time with the Mac developer tool Xcode. It's about the same as Visual Studio. It uses GCC to compile, which cuts the ten minute build time in Visual Studio down to about a minute. I could get the same results on Windows using Code::Blocks so that's not really a Mac thing, but it's nice to work with. I am pleased to say that Leadwerks Engine 3 is now compiling for Windows and MacOS. The Mac version has no graphics or GUI yet, but it compiles without any errors, and that is a big achievement. Linux should be easy now, since it's a lot more like Mac than Mac is like Windows. I also tried out the iPhone SDK and was pleased to see the iPhone emulator starts up almost instantly. By contrast, the Android SDK took me about 45 minutes to install the first time, and it took ten minutes for the emulator to start.
     
    So my conclusion on Mac is that I am very pleased with just about every aspect of them. You could reasonably get away with only having an iMac for development, because it allows you to make games for Windows, Mac, Linux, Android, and iPhone. I may make MacOS my main operating system, although I have to keep some other machines around for compatibility testing. It's taking some extra time to get the cross-platform support for Leadwerks Engine 3 in from the beginning, but I think a couple extra weeks spent now will be well worth it in the long run. Soon enough the code will be platform-agnostic, meaning I can just work with my own code, instead of trying to figure out somebody's else's designs.
     
    I picked up Left 4 Dead 1 and 2 last week in a Steam Halloween sale. I'm starting with the first one, and I absolutely love it. I've always liked co-op play since Duke Nukem, and there hasn't been nearly enough of it available. I also love zombie movies, so Left 4 Dead is right up my alley.


  3. Josh
    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.
  4. Josh

    Out of OpenGL3Context

    By Josh,

    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 OpenGL contexts, but oddly, frame buffer objects cannot. This is probably because FBOs are small objects that don't consume large amounts of memory, but it still seems like a strange design choice. I got around this problem by using the persistent background context whenever any FBO commands are called, so buffers will continue to work after you delete a context. So I guess the way to describe that is I start with something that is sort of awkward to work with, and encapsulate it in something that makes more sense, to me at least.
     
    Because the background context is created in the OpenGL3GraphicsDriver constructor, you can start calling 3D commands as soon as you create the driver object, without creating a visible 3D window! Weird and cool. No idea yet if it will work like this on MacOS, but I'll find out soon enough, since I ordered my iMac last week. I got the 27-inch model with the 3.2 ghz dual core CPU, and upgraded the GPU to an ATI 5750. I chose the 3.2 ghz dual core over the 2.8 ghz quad core because I have found in general usage, my quad core rarely goes over 50% usage, and I would rather have a faster clock speed per core.
     
    I said earlier that the window/context design was a little tricky to figure out, especially when you take into consideration the external windows people will want to use. In Leadwerks Engine 2, this was accomplished via a custom buffer, where callbacks were used to retrieve the context dimensions, and the user was responsible for setting up an OpenGL window. Well, initializing pixel format and OpenGL version on a window is a somewhat tricky thing, and if it's possible I would like to avoid making you deal with that. I ended up with a window design that is quite a lot more advanced than the simple Graphics() command in LE2. The window is created from a GUIDriver, which implies other parts of a cross-platform GUI might one day be included. The design is modeled similarly to MaxGUI for BlitzMax. To create a window, we do this:

    Gadget* window = CreateWindow("My window",0,0,1024,768,NULL,WINDOW_FULLSCREEN)
    Then you can create a graphics context on the window (or any other gadget):

    Context* context = GraphicsDriver->CreateContext(window)
    We can check for events in our game loop like this:

    while (PeekEvent()) { Event ev = WaitEvent(); switch (ev.id) { case EVENT_WINDOWCLOSE: return 0; } }
    At this time, windows are the only supported gadget, but the framework is there for adding additional gadgets in the future. This system can also be used to implement the skinned game GUI as well as native interface elements. Before Rick says anything, yes, there will be a custom event handler function you can attach to a gadget instead of polling events.
     
    You can render to an external window just by supplying the HWND (on Windows) to the GUIDriver->CreateGadget(HWND hwnd) command. This will create a "Gadget" object from any valid hwnd, and it can then have a context created on it, like the above example.
     
    Simple deferred lighting is working, just using a directional light with no shadows. On both AMD and NVidia cards, the engine can render 16x MSAA deferred lighting. The gbuffer format in Leadwerks Engine 3 is only 12 bytes per pixel. Per-pixel motion blur will add a couple more bytes:
     
    color0 (RGBA8)
    diffuse.r
    diffuse.g
    diffuse.b
    specular intensity
     
    color1 (RG11B10)
    normal.x
    normal.y
    normal.z
     
    color2 (RGBA8)
    emission.r
    emission.g
    emission.b
    materialid
     
    Material properties are sent in an array to the GPU, and the material ID is used to look up properties like specular reflection color, gloss value, etc. So this is a very efficient usage of texture bandwidth. My GEForce 9800 GTX can handle 1920x1080 with 8x MSAA, but 16x seems to go over a threshold and the card crawls. I don't know if you'll be using 16x MSAA in a lot of games, but if nothing else it makes for fantastic screen shots, and the lower resolution antialias options are still there. I personally don't see a big improvement past 4x multisampling in most games.
     

     
    Here's my current test program. It's more low-level than you will have to work with. You won't have to create the gbuffer and draw lighting yourself like I am here, but you might like seeing how things work internally:

    #include "le3.h" using namespace le3; int main() { InitFileFactories(); //Create GUI driver GUIDriver* guidriver = new WindowsGUIDriver; //Create a window Gadget* window = guidriver->CreateWindow("Leadwerks",0,0,1024,768,NULL,WINDOW_TITLEBAR|WINDOW_RESIZABLE); if (!window) { Print("Failed to create window"); return 0; } //Create graphics driver GraphicsDriver* graphicsdriver = new OpenGL3GraphicsDriver; if (!graphicsdriver->IsSupported()) { Print("Graphics driver not supported."); return 0; } //Create a graphics context Context* context = CreateContext(window,0); if (!context) { Print("Failed to create context"); return 0; } //Create world World* world = new World; //Create a camera Camera* camera = CreateCamera(); camera->SetClearColor(0.5,0.5,0.5,1); //Load a model LoadModel("Models/train_sd40.mdl"); //Create gbuffer #define SAMPLES 16 Buffer* gbuffer = CreateBuffer(context->GetWidth(),context->GetHeight(),1,1,SAMPLES); Texture* normals = CreateTexture(context->GetWidth(),context->GetHeight(),TEXTURE_RGB_PACKED,0,1,SAMPLES); Texture* emission = CreateTexture(context->GetWidth(),context->GetHeight(),TEXTURE_RGBA,0,1,SAMPLES); gbuffer->SetColor(normals,1); gbuffer->SetColor(emission,2); delete normals; delete emission; //Set up light shader Shader* lightshader = LoadShader("shaders/light/directional.shd"); Mat4 lightmatrix = Mat4(1,0,0,0, 0,1,0,0, 1,0,0,0, 0,0,0,1); lightmatrix *= camera->mat; lightshader->SetUniformMat4("lightmatrix",lightmatrix); lightshader->SetUniformVec4("lightcolor",Vec4(1,0,0,1)); lightshader->SetUniformVec4("ambientlight",Vec4(0,0,0,1)); lightshader->SetUniformVec2("camerarange",camera->range); lightshader->SetUniformFloat("camerazoom",camera->zoom); //Delete and recreate the graphics context, just because we can //Resources are shared, so you can change screen resolution with no problems delete context; delete window; window = guidriver->CreateWindow("Leadwerks",200,200,1024,768,NULL,WINDOW_TITLEBAR|WINDOW_RESIZABLE); context = CreateContext(window,0); float yaw = 0; while (true) { //Print(graphicsdriver->VidMemUsage()); if (!window->Minimized()) { yaw +=0.25; //Adjust the camera camera->SetPosition(0,0,0,false); camera->SetRotation(0,yaw,0,false); camera->Move(0,2,-10,false); //Update the time step UpdateTime(); //Render to buffer gbuffer->Enable(); camera->Render(); //Switch back to the window background context->Enable(); //Enable shader and bind textures lightshader->Enable(); gbuffer->depthcomponent->Bind(0); gbuffer->colorcomponent[0]->Bind(1); gbuffer->colorcomponent[1]->Bind(2); gbuffer->colorcomponent[2]->Bind(3); //Draw image onto window graphicsdriver->DrawRect(0,0,context->GetWidth(),context->GetHeight()); //Turn the shader off lightshader->Disable(); //Swap the back buffer context->Swap(false); } //Handle events while (PeekEvent()) { Event ev = WaitEvent(); switch (ev.id) { case EVENT_WINDOWRESTORE: ResumeTime(); break; case EVENT_WINDOWMINIMIZE: PauseTime(); break; case EVENT_WINDOWSIZE: //Recreate the gbuffer delete gbuffer; gbuffer = CreateBuffer(context->GetWidth(),context->GetHeight(),1,1,SAMPLES); normals = CreateTexture(context->GetWidth(),context->GetHeight(),TEXTURE_RGB_PACKED,0,1,SAMPLES); emission = CreateTexture(context->GetWidth(),context->GetHeight(),TEXTURE_RGBA,0,1,SAMPLES); gbuffer->SetColor(normals,1); gbuffer->SetColor(emission,2); delete normals; delete emission; break; case EVENT_WINDOWCLOSE: //Print OpenGL error to make sure nothing went wrong Print(String(glGetError())); //Exit program return 0; } } } }
    There's been some debate about the use of constructors, and although it would be nice to be able to use a constructor for everything, but that does not seem possible. I use a lot of abstract classes, and there is no way to use an abstract class constructor to create an object. If there was a way to turn the object into a derived class in its own constructor, that would work, but it's not supported. You certainly wouldn't want to have to call new OpenGL3Buffer, new DirectX11Buffer, new OpenGL4Buffer depending on the graphics driver. The point of abstract classes is so you can just call their commands without knowing or caring what their derived class is. So if anyone has any other ideas, I'm all ears, but there doesn't seem to be any other way around this.
     
    What's next? I need to get some text up onscreen, and the FreeType library looks pretty good. I'll be getting the Mac version set up soon. And I am eager to get the engine working together with BlitzMax, so I can work on the editor. The graphics features of LE3 are great, but I think there are two even more important aspects. The first is the art pipeline. I've designed a system that is the absolute easiest way to get assets into the engine. More details will come later, but let's just say it's heavy on the drag and drop. The other important aspect of LE3 is the interactions system. I have concluded that programming, while necessary, is a lousy way of controlling interactions between complex objects. The Lua implementation in LE2 was good because it provided a way for people to easily share programmed objects, but its the interactions of objects that make a system interesting, and a lot of object-oriented spaghetti is not a way to handle this. Using the interactions system in LE3 with inputs and outputs for each object is something that I think people will really like working with.
  5. Josh

    Model citizen

    By Josh,

    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 are, but at least I know it will be stable. I am working with the OpenGL 3.3 renderer right now, which requires a Shader Model 4 card. OpenGL 4.0 is just like 3.3, with a few added features, and it will need a separate renderer. So right now we are looking at:
    -OpenGL 4.0
    -OpenGL 3.3
    -OpenGL 2.1 (for Mac)
     
    Those versions are just variations of one another, and I know OpenGL pretty well, so it's mostly just a matter of copying and pasting code. Since I have to deal with three versions of OpenGL anyways, it's not a big deal to add an OpenGL 1 renderer using the fixed function pipeline. Then of course we have OpenGL ES for the mobile platforms, but I won't be dealing with that myself. A DirectX renderer will only be needed for XBox 360, when the time comes.
     
    That's all for now. The material / shader / model systems are pretty crucial to LE3, especially how they are designed to be reloadable, so I have plenty of work to do! The most critical features in LE3 are the asset handling and the interaction system. In LE2 we created a system whereby programmers could share programmed game objects with Lua script, but we found that without an official visual interaction system, there were limits to how interesting your game components could get. With LE3, a totally new visual system will provide a framework with which your game components can interact, so everyone can create complex game interactions. In plain terms, that means I can easily drop a character into the scene, and set it up so when they die, a door opens, or something like that...with no programming.
     
    By the way, I recommend catching "The Social Network" in theaters. Some of the dialog is cheesy, but it's an interesting look into tech startups (and an unflattering portait of Mark Zuckerberg). The most interesting parts to me were the scenes in Palo Alto, which were a lot more familiar to me than the Boston setting. Plus, the soundtrack is by Trent Reznor:
     

    http://www.youtube.com/watch?v=qy8qDXQQZ3U
  6. Josh

    Some sample LE3 code

    By Josh,

    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() ); CreateGraphics(1024,768,4); World* world = CreateWorld(); //Load a shader Shader* shader = LoadShader("Shaders/minimal.shader"); //Create a material; Material* mat = CreateMaterial(); mat->SetShader(shader); mat->SetColor(1,0,0,1); //Create a box; Mesh* box = CreateMeshBox(1,1,1); box->SetMaterial(mat); Camera* camera = CreateCamera(); camera->SetClearColor( Vec4(0,1,0,1) ); box->SetPosition(0,0,-2,false); float yaw = 0.0; while (!window->Closed()) { yaw++; box->SetRotation(yaw,0,0,false); camera->Render(); window->Flip(); }
  7. Josh
    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!
  8. Josh

    Move over, StarFox

    By Josh,

    I was determined to get 3D graphics working this week, and I did it. Behold, a box, now with *3D PERSPECTIVE*.
     

    Making another variation of the infamous "my first box" demo with OpenGL is certainly nothing to brag about. However, there is quite a lot of code in use beyond just a simple hard-coded demo. The materials, shader, file system, camera, surface, graphics, math, and entity classes are all functioning at various levels of completion. I coded these systems and then used them to make a spinning box. If I had simply set out to make a spinning box and nothing else, it would have required a lot less code, that wouldn't be good for anything else.
     
    More importantly, I have got C++ doing everything I did with BlitzMax. I still would not recommend C++ unless you need it for some specific reason, but I am very comfortable with it. I've run into a number of bugs and problems I was able to fix without too much trouble, and the debugging tools that come with MS Visual Studio are adequate. Besides the funny syntax, C++ is not really any different than programming in any other object-oriented language, so don't let anyone make you feel bad if you prefer C#, BlitzMax, or something else.
     
    One interesting problem was dealing with the lack of garbage collection in C++. I am not a fan of garbage collection, but some kind of smart handling of resources is needed. When you have objects that can be assigned to other objects and passed around, managing them can be a nightmare. I could pass the responsibility onto the end user, but it would be very problematic to keep track of which material's textures need to be manually deleted. I used the following solution.
     
    When something like a shader is assigned to something like a material, a copy of the shader is actually made. The copy is just a pointer that has the same ShaderReference object in the "reference" member. The ShaderReference instance count gets incremented. When a shader is deleted, the ShaderReference instance count gets decremented, and when the count reaches 0 the ShaderReference is deleted. Wow, that sounded confusing.
     
    Let me illustrate with some code showing how resources are managed in LE3:

    Material* mat = CreateMaterial(); Texture* tex = LoadTexture("rock.dds"); mat->SetTexture(tex,0); delete tex; // Don't worry, you are fine! delete mat; // Internal copy of texture will be deleted, along with the //TextureReference object that contains the OpenGL texture data
    It's pretty hard to crash the engine by accidentally deleting a texture that is in use somewhere else. The reference / instance system is a lot more advanced in LE3, and also allows copies of most objects to be made, either as an instance or as a new unique copy. Cool, huh?
     
    I love OpenGL3. The way they cleaned up GLSL and just made everything user-defined abstract data is fantastic. Cannot wait to get into it further!
     
    In completely unrelated news, I have an idea for another website that is oriented towards video game consumers rather than developers. It's an interesting idea...we'll see if it materializes over the next six months or so. There's also a major site feature coming to leadwerks.com in October. I am very excited about it, but I'm not ready to say what it is yet, so all I can do right now is make ambiguously optimistic statements.
     
    Here is the game I referenced in the title. This was the first 3D graphics I think I ever saw, and I was blown away at the time. The soundtrack is pretty rockin', too.
     


     
    I am getting a lot of work done. Have a good week and have fun!
  9. Josh

    Pump up the volumes

    By Josh,

    Shader class...done.
    Surface class...done (pretty much).
     
    One change in LE3 is the addition of .shader files. This is just a text file with a list of shader components:

    vertsource="mesh.vert" fragsource="mesh.frag"
    Your material file then just has to reference a single file:

    shader="mesh.shader"
    Of course, you'll be able to just drag the shader file onto the material shader property in the editor to assign it. You will never have to use Notepad, for anything.
     
    Now working on "solids". This is based on my old CSG code from 3D World Studio. It's kind of nice that knowledge I developed a pretty long time ago is still so useful. Solids in the engine are a mathematical construct. They're basically a list of planes, with some extra fancy bits that do useful things like test if a point or ray intersects a solid convex volume. It can even detect the intersection of two convex volumes, which is some pretty advanced and fun geometry. Not 100% whether CSG modeling will be supported in the LE3 editor, but there is a pretty good case for it. I would probably program the more complicated CSG brush stuff in BlitzMax, and just convert it to a dumb mesh by the time it gets into the engine, for visible geometry.
     
    Solids are used for the visible camera volume (frustum), and can also be used for invisible trigger volumes, blocks of water, etc. I am leaning towards allowing attachment of any number of solids to an entity, and then when the solid is entered by another entity, a Lua script function (or C callback [or both]) would be triggered. This allows you to attach multiple convex solids to an entity to form a concave shape, and the action can then be handled through the regular entity script system.
     
    I haven't gotten into it yet, but the entity script system will allow any number of scripts to be attached to an entity, and they will be called in sequence. Special entities will have script functions available that have not existed before. For example, a particle emitter entity will have a script function EmitParticle() which allows you to control exactly where a newly emitted particle appears.
     
    Well, writing code for invisible mathematical intersection tests isn't too exciting, but it formed a lot of the basis of LE2, and will for LE3 as well. Then it's on to the OpenGL camera class, so I can actually get some 3D graphics on the screen.
     
    I'm mostly just retreading things I've already done right now, but having the code in C++ is good. It gives us cross-platform support for C++ programmers, the biggest segment of LE coders. It allows easier implementation of external libraries. Hiring outside help for some tasks is actually possible now. Finally, with a well-designed C++ core, it ensures we are forever moving forward, and not backing up and redoing things again. If I need to support the XBox or iPhone, that can be done without a massive rewrite or a new language. We learned a lot from LE2 about what works well and what can be improved. I am looking forward to a long and stable future using the LE3 engine design. I'd like to get into game production of our own titles as well, using LE3.
     
    I'm enjoying Amnesia: The Dark Descent this week. All I need is an hour or two each week, so when I start a new game it usually takes a couple of months before I finish it. I also discovered the web series The Guild, and found it hilarious, although I am an outsider to the whole MMORPG thing. Maybe Felicia Day will make an episode about my life.
     
    Well, I want to have something to show off for GDC 2011, so I'd better get back to work. Enjoy this episode of "Civil Protection". You can rarely go wrong with Half-Life 2 machinima:
     


  11. Josh
    Frictional Games is the developer of puzzle horror games like Penumbra and the new Amnesia: The Dark Descent. We sat down with Frictional Games co-founder Thomas Grip to learn more about their development process.
     
    Josh: I'm a big fan of the Penumbra series. What can we look forward to in Amnesia: The Dark Descent?
     
    Thomas Grip: There is a lot to of new stuff in the game. First of all the game is a more streamlined experience both in terms of general gameplay and interaction. For the gameplay we have made sure that the focus is always on atmosphere and story, and made sure that the player is never stuck at a puzzle for too long and stuff like that. One of the ways we do this is to allow multiple solutions so it always feels intuitive to the player.
     
    In terms of interaction, it is much easier to interact now. In Penumbra it could be a pain to open doors at times because you needed to click on the right spot and so on. In Amnesia all that is fixed and it is now possible to easily slam shut a door in the face of an enemy and things like that.
     
    There is also a new insanity system, a fresh environment, and new story.
     



    Josh: Can you talk about the process of developing an idea and turning it into a full-fledged game? Do you start with a design document or just start writing code? How closely does your final game resemble what you originally imagined?
     
    Thomas Grip: This time we had a very long iteration period where we tested out various ideas. We actually first had a bite-sized horror design inspired by Super Mario. It was intended to have small self-contained levels and to be played in shorter bursts. It did not fall out too well and we tried tons of stuff before settling where the final game is.
     
    In the early iterations we started out with a "fun" mechanic and tried to base a game on that, but as I said, it did not turn out good. Instead we started focusing on the themes and general feel of the game. Then we started building minimal mechanics to support that. To do this we took a lot from Penumbra, as we knew how it worked, and refined it.
     
    Once we had the general feel going 1/3 or so is drawn up on paper and we started making maps based on that, then as maps are made we continue to design the remaining 2/3 on paper taking cues from the maps being built. These written paper designs are often very close to the full game and that is a way for us to be able to plan ahead very accurately. Early on we knew around 90% of the assets that we needed, which is great when outsourcing. Then in the final steps the maps get polished and we play them over and over and try to build up the feel we are after. If something does not work out, we often scrap it instead of rebuilding it.
     



    Josh: Towards the end of the first Penumbra game, you communicated with a major character over an intercom system. The character never actually appeared on screen, but the emotional connection was established using voice acting. This struck me as a good design decision, because you were able to eliminate all the trouble of making an animated character speak in a convincing cut scene, without detracting from the player's experience. Are there any other examples like that where you made design decisions that helped streamline production, so you could focus on the core gameplay?
     
    Thomas Grip: There is a lot of that stuff in Amnesia. For example, there is one character without a lower jaw, which removed the need to do lip-sync. When it comes to visions we only use sound (without models, like in System Shock 2), which in turn also gives the game a more spooky feel. I think having these kinds of constraints also forces you to use your imagination more and not just follow the design of other games. Although it is a bit annoying not being able to do certain stuff, it often turns out positive for us.
     



    Josh: What's next for Frictional Games?
     
    Thomas Grip: Rest! And tech support... And then we have to see how sales and so go! We have an interesting idea we would like to pursue, but it depends a bit on how we do financially.
     
     
    Check out Amnesia: The Dark Descent for creepy thrills and inspiring game design.
  12. Josh

    Picking Up St(r)eam...

    By Josh,

    I'm making good progress on LE3 now. First I had to write basic functionality for things like strings and file access. It was tedious, but now that it's done I've got a nice library of functions that make programming all that much easier. The string commands include Trim(), Split(), ExtractExt(), StripDir(), etc. I know the Boost library has some functionality like this, but I'd like to avoid relying on third party libs whenever possible. I've also got the file system working, with a FileFactory class that can be extended to handle internet or other files. The commands are simple and easy to use:

    Stream* stream = ReadFile("myfile.txt"); int n = stream->ReadInt(); delete stream;
    The regular file commands work for .pak file reading as well.
     
    These features will also be useful for Codewerks, my meta language that uses C++ compilers. I have put development of this on hold for now, but I am still very interested in picking it back up again at a later date. It's nice to see that everything I originally envisioned for that will work just fine.
     
    The OpenGL 3/4 renderer is started. The changes from OpenGL 2.1 to the latest version are pretty minor. Since I already know OpenGL pretty well, I don't think the LE3 renderer will be too hard at all.
     
    The texture class is working. Each texture has one or more "frames" for animated textures.
     
    So far everything should be cross-platform compatible, but I'll be picking up an iMac pretty soon so I can try it out on MacOS. I'm going to use XCode on Mac and Visual Studio on Windows. I'll probably use Code::Blocks or CodeLite for Linux.
     
    I'm comfortable with C++, and have enough knowledge of it now to finish the project.
     
    So I guess to sum it up, this week marks the end of the learning and experimenting phase, and the start of actual coding. Coding LE3 in C++ is about the same as coding it in BlitzMax, although a bit slower. The point is I am just dealing with my own code and design instead of worrying about learning new conventions, so I think things will speed up now.
     
    Thanks for all your ideas and feedback in the feature requests forum. Some really good suggestions have come from the community that I will incorporate in LE3.
     
    On a final note, LOL Week was a tremendous success. Here are some of my favorite images that were posted.
     






  14. Josh
    Here is the amazing first shot of Leadwerks Engine 3. Behold not one, but TWO triangles! It's a dual display of isosceles inspiration.
     

     
    Believe it or not, this screenshot actually demonstrates a feature that's new for LE3...hardware multisampling. Look carefully at the edges of the triangle:
     

     
    This isn't the first time I've done multisampling, but until now it hasn't been possible to use with deferred rendering. It's now possible to combine these techniques with OpenGL4. You'll have our awesome lighting combined with high-quality 16x antialiasing for raytracer-like graphics. Oh yeah, multiple layers of transparency, each with proper light and shadows, will also be supported.
     
    I ran into problems getting Code::Blocks to import the glew library. Something struck me when I was Googling around for docs. I became aware that most Code::Blocks programmers are probably coding for Linux, and all the examples I read just assumed I was using MS Visual Studio. I didn't give in to the C++ monster just so I could go off on another "non-standard" (if there is such a thing) development route, so I am back on MSVC. I really don't like the poor (or complete lack of) error handling, but I am just going to have to adjust my coding style to this environment. If anyone knows if either the pro version of MSVC or the Intel compiler will stop on the first error and select the line it occurs on, I would gladly pay for that functionality.
     
    As annoying as C++ can be, there are some compelling reasons to write the next iteration of our technology in it. First, I need C++ source code to have something I can sell to professional studios. Second, it is extremely difficult to find programmers willing to work in either BlitzMax or C, and dealing with the interface between BlitzMax and C libraries can get ugly. It's not so technically difficult, but you are doing something in the world no one else is, so there's not any support for it. Having Leadwerks Engine 3 written in pure C++ code allows me to work with other programmers who can handle various tasks like networking, some special effects, and ports to other platforms. It also makes it easier to include external libraries for added features. Finally, only C++ can be used for all the platforms I want to support, including Android, iPhone, XBox, PS3, Wii, etc.
     
    C++ programmers will like this a lot because the LE3 command set allows them more power than they have had before. It's possible to write your own drivers for physics, graphics, device input, and have it all work with the core engine. You can also extends existing classes. This is particularly useful for entity programming.
     
    Should you switch to C++ for LE3? If you've already got another language you're comfortable with, I don't see any reason to. When you are programming a game, flexibility and production efficiency are more important than the raw speed of the final program. Let's say that C++ gave a 25% speed increase over another language. This is probably not realistic, but for the sake of argument let's use that number. That still doesn't mean much, if the user can get a 300% speed increase by switching the GPU or changing some quality settings. So unless you want to support a lot of extra platforms or you just like C++, I don't see any big advantage when it comes to actual game authoring. I need a C interface for use with BlitzMax, because I intend to continue making the editor with that language. Therefore, our policy of allowing you to "code the way you want", with any language you want, will continue.
     
    By the way, Khronos has done a really great job with the design of OpenGL 3.1 and onwards. A few points of interest are that immediate mode rendering is finally done away with:

    glBegin(GL_TRIANGLES); glVertex3f(1,2,3); glVertex3f(1,4,3); glVertex3f(1,2,4); glEnd();
    No more! It doesn't make sense to have three different ways of drawing primitives, and it just makes the drivers overly complicated. You should learn the one right way of doing things, from the start.
     
    Also, the shaders have all the remnants of the old fixed function pipeline cleaned out. The GPU doesn't have a "color array" or a "texcoord array". It just has vertex arrays and you decide what they are, and what format they should be in. So I can do things like compress surface normals into four bytes and not worry about needing the color array for something else.
     
    I didn't get much into it, but it looks like shaders have a nicer implementation of what used to be called "varyings". Variables are just "in" or "out" in the vertex and fragment shaders. Uniforms remain unchanged. I might have a play at geometry shaders, but two years later I am still not sure what they are for, other than something that would have been nice when stencil shadows were popular. Of course, what I am really looking forward to is the OpenGL4 hardware tessellation.
     
    Anyways, I am pretty comfortable with C++, and am happy to be back into graphics, my favorite area of technology. Thanks again to Roland Strålberg for his advice with some C++ details. Have a good week!
  15. Josh

    Week 3

    By Josh,

    The last two weeks were mostly me wrestling with C++. I had promising results with a meta language that translates to C++ and compiles, and also learned how to create makefiles as a result of that. I tried CodeLite and CodeBlocks, in addition to MS Visual Studio. I finally settled on CodeBlocks.
     
    Codeblocks can be configured pretty easily to use GCC, the MS C++ compiler that Visual Studio uses, as well as about a dozen others (very curious to see if LE3 compiled with the Intel compiler is faster!) I prefer GCC with no optimizations for development, because it builds about twice as fast as the MS C++ compiler. Although I find Scintilla to be slow and somewhat poorly written, it's nice to have a cross-platform code editor. I can also configure Codeblocks to stop on the first error (it's actually a GCC compiler setting) and it automatically opens the file and selects the line the first error occurs on (CodeLite does not). Because I realistically expect to make thousands of coding errors during the production of LE3, it makes sense to streamline this highly repetitive task any way possible, and for that reason Codeblocks wins.
     
    The meta language made a promising start, and I may offer it as a product in the future, but it will not be used to develop Leadwerks 3.
     
    I've started on the OpenGL4 renderer. First I create the base renderer class, and established what the commands would actually do. Next I am going to create a window in Windows, set the pixel format, and initialize an OpenGL context. I've done all of these tasks from scratch in BlitzMax, but it's been a long time since I dealt with any of that.
     
    One of the most confusing parts for me was pointers versus references. In C++, pointers act pretty much like an object in Blitz3D: When you declare the variable, it's null, you create a new object and assign the variable to it, you delete the object manually when you are done with it. Now if you declare a variable that is a class, it creates it instantly and it can never be Null; it just exists. When the variable goes out of scope, it gets deleted/destructed automatically. This was pretty confusing until I realized that these objects are just like when you declare a float or integer variable. You don't worry about cleaning it up, because it only exists within the scope of the function it's declared in. You can never set an integer to Null, because it just exists; it doesn't get deleted. In the same way, a Vec3 variable doesn't need to be cleaned up or deleted; it just exists within the scope it is declared in. Therefore, it makes perfect sense for math classes like Vec3, Vec4, Mat4, etc. to always be used as a regular variable, and for complex objects like entities, materials, etc., to always be declared as pointers.
     
    I had another look at the Android SDK, and decided an Android game development would come in the form of a static lib for use with Java (or pure C++ if you prefer and can set it up). I'm cautious about the iPhone, but because Leadwerks is a code-centric development approach, I don't think we will have much trouble staying in compliance with the Apple EULA. I sort of understand Apple's strictness. I love my HTC Evo, but there's so much on it that just doesn't work. The app store is full of horrible crappy games. The App Installer even crashes on startup. iPhone gets Doom 3 by id Software, and Android gets 10 versions of Doom classic compiled by some kid, and none of them work. If Apple can deliver a good and consistent user experience, then I don't really have any problem with the restrictions they give developers.
     
    You can now add your SteamID to your Werkspace profile and display your Steam status. It may help a few people to join up for some fun multiplayer challenges, but I am mostly interested in learning about the multiplayer features Valve has implemented in Steam. Join the Leadwerks Developer Steam Group and be sure to keep a couple games in your wishlist. Thanks to HurrBeDragns for reserving the URL for me!
     
    I want strong multiplayer support in LE3, and I like some of the things Valve has done. In LE3, all entities can be saved to a binary file format. We have learned how troublesome serialization can be, so we won't be using that, but this binary file format can be used for prefabs, and even for syncing entities over the network. I've already had success specifying an entity should be synced over a network. It's really nice to have everything just work automatically. I'm in favor of just letting the server handle all interaction, with no client-side prediction because: 1. client-side prediction is inaccurate and wrong, 2. It was originally designed for 56k modems, and 3. Onlive has proven that player response lag can be minimal even when streaming graphics in real-time. The design I used in the multiplayer tests I conducted a few month ago was certainly good, and the results were responsive enough as long as the players were on the same continent.
     
    The platforms I am most interested in are Windows and MacOS, now that the new iMacs are shipping with decent graphics cards. The GPUs the new iMacs come with range from an ATI Radeon 4670 up to a Radeon 5750. By following the ATI/NVidia rule and dividing the number of ATI stream processors by 5, we can deduce these cards to be the equivalent from about an NVidia GEForce 8600, to a bit better than a GEForce 9800 GTX. This is definitely within the range of Leadwerks hardware requirements, so I look forward to developing for MacOS in the near future. And it's a good excuse for me to get a 27" iMac. I did not like the direction Microsoft went with Windows 7, and the new OS has finally put me in a place where I am willing to try something new. That never would have been this case in the days of Windows XP. Just so you know I am not turning into a total Apple fanboy, it is funny they make a big deal out of having a separate graphics processor...I had a 3DFX card in 1997, and they are only now catching onto the idea of dedicated GPUs!
     
    That's pretty much it for now. Stop on by the Asset Store and grab the Industrial Cargo Model Pack for only $9.95 before the price goes up tomorrow.
  16. Josh

    Week 2

    By Josh,

    What an interesting first week. I compiled a C++ program for Android, made a programming language, learned about iPhone development, and figured out a lot of C++ stuff I did not know.
     
    It's nice to see that a port to Android will work pretty much like I was hoping. I just write an abstract driver for every system, and have specific drivers that extends that class:
    class GraphicsDriver {}
    class GL4GraphicsDriver : public GraphicsDriver {}
     
    Then when you have something like a surface that is dependent on the graphics driver, you do this:
    surface = GetGraphicsDriver().CreateSurface()
     
    And a GL4Surface object is returned. Of course, this is just the internal workings, and you will only have to call CreateSurface(). The GL4Surface is an extension of the Surface class, the same way the GL4 graphics driver extends the base graphics driver class.
     
    I would like to get something running on my HTC Evo, but the details of an Android, XBox, or PS3 version aren't too important right now. What is important is to get the C++ core done, in a way that makes it easy to add support for more platforms in the future. So as planned, you'll get a .lib file for C++, a .dll you can use with any language, and multiple Lua scripts can be attached to any entity.
     
    A roadmap of the development plan can be viewed here. I hope to accomplish most of stages 1 and 2 myself, and then recruit additional coders for the last leg. I don't intend to write the networking code myself, either. I figure it will be easier to develop streamed terrain from the beginning, instead of trying to tack it on two years from now, so I will see what I can do about that. I've never seen an infinite streamed world with the density and complexity I want, but Leadwerks seems to do best when we do really aggressive development:
    http://leadwerks.com/werkspace/index.php?/page/roadmap
     
    What I like best about this process is the code I write now is ForeverCode: It's good for any platform, and it will last for the life of the engine, which will be a very long time. I really can't imagine ever writing a version 4, because version 3 is being designed to be perfect.
     
    At this point I would like to thank Roland Stralberg, Mika Heinonen, and Ed Upton for their feedback and wisdom.
  17. Josh

    Friday

    By Josh,

    My little precompiler is going well. It creates makefiles and can split a build up across multiple files. I am working out the interface with external libraries. Here's an example program:

    Print "Hello World!"
    And here's the code it outputs and compiles:

    #include "Hello World.h" using namespace codewerks; //============================================= // Main Loop //============================================= int main(int argc, char* argv[]) { Print(std::string("Hello World!")); }
     
    I'm confident this will work on both MacOS and Linux. Where things get a little foggier is on the iPhone, and especially on the Android. I'm looking for an Android and an iPhone developer to work with. It would be easiest in the long run if I can account for those platforms from the beginning.
  18. Josh
    We're finally offering our first product in the new assets section of the site. I have wanted for a long time to have a means where assets can be produced and sold in a sustainable manner. I am very interested in working with third-party sites that produce game artwork. Orders are still processed by hand, but we're working on a system to automate things. You can be sure I won't let anything into the product listing unless it is 100% game-ready for Leadwerks Engine.
  19. Josh
    The Industrial Cargo Model Pack is now available for only $9.95. This package includes three cargo containers and two wooden spools. All assets are certified game-ready for Leadwerks Engine. This is just some of Dave Lee's work, and there's lots more coming!
     

  20. Josh
    I feel like you guys are owed an explanation of our long-term strategy, and now that I have definite plans I am happy to reveal them to you.
     
    I've been spending a lot of time in the Silicon Valley area, and have learned a lot about business. We've been investigating external investment. I believe we could raise pretty much any amount of money we want, based on the fact we already have an existing business that is self-sustaining, and we have a great strategy. However, money does not necessarily equal success, and funding brings more restrictions. If we raised $10 million, our investors would expect a $100 million return, and everything we did would have to be geared towards that. If you recall the Blade3D story, you know what can happen when these deals go bad. I believe the wisest strategy for the development of Leadwerks 3.0 is for me to buckle down and write the majority of the C++ code, then add additional programmers once the foundation is in place. This allows me to carefully design the core functionality without external pressures. It ensures I don’t trust the engine core to some programmer that may not understand our design objectives. Finally, it forces me to tame that beast that is C++. Even if my future is more of a management role than programming, I still need to be able to evaluate future employees’ work. Once I feel the project is ready for more programmers, we may seek funding, but we’ll be in a less risky position at that point.
     
    Another thing I have learned is how great networking is. It’s fun, and it can lead to valuable contacts. I live two hours from San Jose, so there is no excuse for me not to be more involved in the game industry. From now on, I am going to attend more IGDA and other events. I may find some good programmers to hire later on, or it may lead to new partnerships like the one I will be announcing with version 2.4. For many developers, Leadwerks is your portal into the game industry. If I am more in involved with what is going on, then by extension you will be, too.
     
    Leadwerks 3.0 will be written in C++, but will still support all the languages we do now. Every part of the code that interfaces with the hardware will be abstracted out as a “driver”. This includes graphics, sound, the file system, and networking. To add support for a new platform, we will just write a new set of drivers for that hardware. The editor will continue to be written in BlitzMax because development time will be shorter and the end result will be fast and cross-platform compatible. To begin with, I am most interested in Windows and Android, but eventually plan on supporting everything. The abstracted driver design we are using makes it possible for separate teams to work on porting the code independently.
     
    I’ve received a lot of great feedback from the community, especially on the tools and workflow. The design of version 3.0 makes it easier for users to just click and drag some items around to make a game, but you can still drill down to the script and programming level, when you need more control. The most intriguing aspect is how it lets advanced programmers work together with designers, and they all can make valuable contributions to a project.
     
    Leadwerks Engine 2.4 will be out soon, and will include a brand new lighting feature that has never been done before, by any engine. The bug tracker is presently clear of reports, but if anything comes up in the future, it will be fixed and patched. After 2.4 is released, I will be going on a short vacation, and when I return work on Leadwerks 3.0 will begin in earnest. We will begin offering the 3.0 beta for sale at a generous discount only to existing Leadwerks Engine 2 developers. When will it be done? I don't know, but I will have a better idea after working with the C++ code for a while.
  21. Josh
    I recorded some clips from Dave's latest version of his scene he is working on. Somehow he managed to get more detail and faster speed. The octree optimizations in version 2.32 help a lot here. The renderer is really good at dealing with lots of small objects strewn across a scene, even if it did take some trouble before we got it working completely right. So here's a short video we'll be using to showcase the capabilities of Leadwerks Engine:
     
    Please share this on Facebook, Twitter, YouTube, etc. We want to get lots of views on this one. Thanks!
     


     

     
    Suggestions are welcome, as I will be doing a second cut with some small improvements.
  22. Josh

    OnLive Lives

    By Josh,

    I signed up for a free year of OnLive. I received a response email within 24 hours, so I think they just are choosing applicants based on connection speed and location. I've been extremely skeptical of this service, but I can report that it works, and it doesn't suck. I can play UT3 on my netbook. There is some slight lag, but it's not bad. Fast mouse looking can amplify it, so I slowed down my mouse speed to compensate. I had no trouble getting headshots with the sniper rifle, and the gameplay experience was very good. As far as technical performance, OnLive has delivered.
     
    As for the product itself, I don't see any reason to jump onboard yet. Wi-fi connections aren't allowed, so the fun of using my netbook anywhere in the house is mitigated. Without that, there's no reason not to use my desktop PC. The lineup of games is very limited. No Crysis, and it looks like the servers have the games running on low to medium settings. This puzzles me, because the quality settings the servers run with should be trivial. That's the whole point of OnLive. With the games and settings they are offering right now, you could get the same results with a five year old PC.
     
    The pricing model is where OnLive fails. After the first year, you pay $4.95 a month for the service. On top of that, you have to "buy" each game you play, but you don't really own it, and the game may be taken down after 2013. With a revolutionary new delivery system like this, the choice to use an outdated purchasing model is baffling. What if you had to pay a monthly cable TV bill, and then "buy" each show you wanted to enable? It doesn't make sense. OnLive should charge a higher monthly fee, around $29.99-49.99 for access to all games on their servers. OnLive would take their cut of the sale, and the rest would be divided up among the game providers based on the percentage time players spent in their game. This would encourage developers to make games with long-term replay value. It would create a continuous revenue stream for developers, instead of just making money off one-time purchases. It would lessen the complaints people have when an old game if retired off OnLive's servers. And finally, it would deliver a lot of value to the customer. Which would you rather pay for, a $200 XBox plus $60 for a game, or pay $40 this month and play every game? The choice for a lot of people would be obvious. Hopefully OnLive will come to see this. I am surprised it isn't already obvious to them.
     
    As of right now, I don't know who would use this service. Who is the target market? People who can't afford a decent PC, but still have $50 to spend on a game they don't own? Maybe some Mac owners will pay for it. I think they should be targeting console players who want the ultimate graphics, but the OnLive console isn't available yet.
     
    Still, OnLive has delivered from a technical standpoint, and they may become something amazing and unique. I look forward to seeing what it might grow into.
  23. Josh

    Downtime

    By Josh,

    First, I want to apologize for the server issues we have experienced this week. With the amount of activity we have coming through the site, it is inexcusable to have any downtime.
     
    The server is reverted to the state it was about four days ago. If you have any important information from the last week you want to save, replace the domain name of the url you want to access with "69.163.255.164". For example, here is the link to the blogs on the other server:
    http://69.163.255.164/werkspace/index.php?/blogs
     
    If you click a link on the old server, you will need to change the URL again. This will be left up for a period of one week.
     
    One of the problems we have been trying to resolve has to do with large files being downloaded through the php download system. After looking into this for quite a while, the conclusion I have is it just won't work, and the php download system should not be used for this. We're going to use direct links to download those files until that changes.
     
    We also have some site improvements coming up very soon. It's not a total redesign, but it is a big improvement that maintains the overall look and feel of the site. We also have lots of dynamic content and a new spotlight section that features cool stuff the community is doing. The last step will be to have the forum reskinned to match the site completely, but I want to get the rest of the design solidified first.
     
    We'll soon be offering some additional products on the site, including tools and assets. We're also working on a community marketplace where you can buy and sell digital goods, sort of like the iPhone Appstore. We'll hold a beta of the system first so we can work it out with no real money involved.
     
    Again, I'm sorry for the recent website problems. Werkspace is your site, and we're glad the community values it, so we'll do our best to provide a good experience.
  24. Josh

    Bug-fix week begins!

    By Josh,

    There were numerous small issues related to the 2.32 release, but I am chipping away at them:
    http://leadwerks.com/werkspace/index.php?app=tracker&showproject=1&catfilter=2
     
    I'm not going to add any new features until every bug is fixed.
     
    Remember that the more complete and easy to reproduce a report is, the faster it will be to fix. Thanks for the feedback!
  25. Josh

    Some hints of 3.0

    By Josh,

    This is a quick blog to fill you in on some of the features planned for Leadwerks Engine 3.0.
     
    -Any entity can be a physics body. The body command set will become general entity commands, i.e. Entity.SetVelocity(). You can make an entity physically interactive with Entity.SetShape( shape ).
     
    -Any entity can have any number of scripts attached to it. The basic model script functions will be supported for all entities, plus specialized script functions for certain entities. For example, particle emitters will have an optional script function that is called when a particle is reset. This could be used to make a fire emitter "burn" a mesh. Script functions are called in sequence, so you can attach a chain of scripts to an entity to combine behaviors.
     
    -Prefabs will be supported, with the ability to drag entities together to make a hierarchy, add lights, emitters, and other entities, attach scripts, and then save a prefab.
     
    -Record screenshots and movies from the editor!
     
    -Tons of scripted behavior you can attach to your own models, and lots of scripted assets you can download. Basic AI features will be supplied.
     
    -The editor is being designed so you only need a mouse to make games. If you want to script or program or make artwork you can, but at the simplest level, the whole workflow can be controlled in the editor, with reloading assets, automated imports, and lots of drag-and-drop functionality.
     
     
    That's all for now. I can't tell you some of the coolest features, but this gives you an idea of where we are headed.
Copyright © 2024 Ultra Software.
All rights reserved.
×
×
  • Create New...