Updates

Lights! Camera! Action!

Okay, the camera system is almost complete. I am working out some of the jerkyness in the movement of the camera. There are two types of cameras: Basic and Player. The basic camera provides the basic orientation operations on a camera, such as, pitch, yaw, roll, and move. The Player camera is broken up into three different cameras: First Person, Third Person, and Spacecraft. All Player cameras are attached to a player object. I will elaborate on each camera once the system is complete...so stay tuned!!

Do you see what I see???

I simplified the interface of the graphics system so it is much easier to get DirectX up and running. The graphics system manages the DirectX interface and device as well as the MBLib graphics renderer. Each of these components are accessible through this system.

That is all for now. Once the camera system is complete, I plan to update the terrain demo adding a dynamic camera that switches between the different camera modes. So, I'll see you then.

OOH OOH EEH EEH

Errors

Let me know if you come across any errors when running the demos. That way I can make sure the system is as stable as possible. It should be, I test the systems before uploading them, but you can never do enough tests... Thanks in advance.

OOH OOH EEH EEH

Dynamic Vertex Buffers

Here is a screenshot of a demo application I created to show the new dynamic features of the vertex/index buffer interface. It displays a patch field the uses a sine wave to calculate the new positions of each vertex on each interation of the application loop. The effect is a rippling effect from the center of the patch to the end. Also, the red diffuse color is adjusted to become more intense at the high wave peak and less intense at the wave down peak. All of these effects are scaled by time to create a smooth animation. You can enjoy the demo by clicking here

I have modified the vertex/index buffers to support both static and dynamic propertics. The demo above show the nature of using dynamic vertex buffers. This allows the client to modify the vertices in the vertex buffer at any time. There are two conditions to be aware of, an overwrite vertex buffer and a nooverwrite vertex buffer.

The overwrite vertex buffer will discard the vertices in the vertex buffer and write the new vertices starting at the beginning of the buffer. Since the Graphics Processing Unit (GPU) will be expecting this to occur, it will return a new pointer into the buffer for the client to add vertices to and then discard the previous vertices.

The nooverwrite vertex buffer will only return a pointer to the available space remaining in the vertex buffer to add the new vertices to. The catch is, if there isn't enough space to add the new vertices, then the vertex buffer will move into overwrite mode and will function like an overwrite vertex buffer. The vertex buffer will return an error when this occurs to let the client know it is no longer protecting the original vertices. This will give the client an opportunity to either continue rendering without crashing or to recreate the vertex buffer to add more space to it. The best approach when using a nooverwrite vertex buffer is to check for enough space before adding the vertices.

Also, to run the demo your video card must support the use of dynamic vertex buffering. The demo doesn't use extensive error handling. I will update the code to be a bit more user-friendly, but its main purpose is to demonstate the use of the Dynamic Vertex Buffer interface. Enjoy!

That's all for now...I am coming with more updates, so stay tuned!

OOH OOH EEH EEH

Terrain Demo is here!!

Okay, it is here as promised. The screenshot is of the initial version of my terrain class (MBGraphics_Terrain). It creates the terrain based on values in a height map. The height map is broken up into sectors to provide optimal performance pushing vertices down the graphics pipeline.

The lighting in the screenshot is simulated. That will change once I get the DirectXGraphics lighting system operational. Also, the camera is locked at that angle. That will also change. I am currently working on the camera system to provide a player control camera under different perspectives. My next post will provide more information into the design of that system.

Enjoy this screenie for now...it's time to feed the monkey's belly!!! OOH OOH EEEEH!!!

OOH OOH EEH EEH

Vertex/Index Buffer Demo

Okay, it is time for an update on the MBLib. I am currently working on the mesh interface of the MBGraphics component. I have created a simple mesh interface (MBGraphics_Mesh). Its purpose is to manage the locations in the vertex and index buffers of where an objects data is stored. This works well with batch loading and rendering of mesh objects. The idea is to be able to sort mesh objects by the vertex buffers they reference. This way when the renderer loads a vertex buffer all mesh objects that reference that vertex buffer and are visible by the camera will be rendered at that time. This will increase rendering performance because vertex buffers are not being switched out frequently causing the rendering pipeline to stall.



Above is a screenshot of a demo that shows the use of the mesh and the vertex/index buffer interfaces. It displays two mesh objects, a cube and a prism, and rotates them on unique axes. The vertices and indices of each mesh object share the same vertex/index buffers. Each mesh stores its location into these buffers so the render knows how to draw them to the display.

There is still some work that needs to be done with the mesh interface. There will be a high level manager that manages all mesh objects needed by an application. The idea behind this is to have one mesh be used by multiple objects. This is often referred to as "instancing". This cuts back on the memory usage because each object references a single mesh in memory.

Also to be added are some utility operations for loading mesh model formats such as 3DS, OBJ, and Milkshape3D models. I am still debating on coming up with a universal format that converts those formats into a proprietary one, or just relying on those. I am not totally sure of the pros/cons of either decision, but I will keep you posted after I do more research.

Also, the terrain interface is still being designed. I will post a description of the interface and a demo once that is completed.

Well, that's all I have for today...back to the lab

OOH OOH EEH EEH

I added the vertex/index buffer interface to the MBGraphics component of the MBLib library. It is divided into two sections: pools and buffers. I wanted this interface to be very simple at getting up and running while maintaining high standards in performance.

Pools

There are two pools: MBGraphics_VertexBufferPool and MBGraphics_IndexBufferPool. The purpose of the pools is to have a central location for managing the existence of and access to the buffers needed by an application. The client is able to interface with a particular buffer through the buffer's id. All buffer ids are supplied to the client when they are allocated in the pool. From there it becomes the responsibility of the client to organize and manage them.

Buffers

There are two buffers: MBGraphics_VertexBuffer and MBGraphics_IndexBuffer. The vertex buffer is used to store vertex information about a mesh object. The index buffer is used to reference vertices loaded in a vertex buffer describing how those vertices are supposed to be connected. A vertex buffer can be used without an index buffer, but it is highly advantageous to use an index buffer to cutback on the memory usage. Index buffers must reference a vertex buffer (at this point in time) in order to be used by the renderer.

Another important advantage is all buffers take advantage of the Direct3D Managed Pool system. This take the responsibility of having to recover lost vertex data during lost device situations. The disadvantage is because Direct3D maintains a system copy of the data, the memory use is doubled. I chose this route because I wanted the use of this system to be simple, and one less thing the client has to worry about is a big plus to me.

Conclusion

This system is still a work in progress, but I am very pleased at its current state. It is fast and very simple and flexible to use. Once the MBGraphics component of the MBLib has been completed, i will provide a series of brief tutorials on how to use it. I speculate this component being the largest out of all the other planned components. Stay tuned! There is plenty more to come...


OOH OOH EEH EEH

MBGraphics Library

Alrighty! My MBGraphics library is in development now. I have very big plans with this portion of the MBLib. Currently I have created a simple renderer and vertex buffer interface.

Currently the renderer clears the display to the desired clear color, activates a vertex buffer, and renders basic primitives (points, lines, and triangles).

The vertex buffer interface creates a static buffer of vertices. The interface is setup to be extended into a dynamic vertex buffer to allow the client manipulate the vertices. At present, you can add vertices to the vertex buffer just as long as the buffer hasn't reached its maximum capacity. The idea I have behind encapsulating the Direct3D vertex buffer interface is to aid in batch loading of vertices. I want it to be able to load all vertices that use the same Flexible Vertex Format (FVF). This will help performance when rendering mesh objects because we can sort the objects and render them all at once without having to reset the stream source for each object.

I am also desiging a VertexBufferPool interface to manage a number of vertex buffers. I want this to extend over to the mesh loading interface as well. The idea is that each mesh that shares the same FVF will manage an ID to the vertex buffer provided by the VertexBufferPool.

Also, the main graphics querying interface is being designed. That will allow a client to query the number of video cards attached to the system and theirhardware capabilities. It's priority will be to manage both the main Direct3D interface and Direct3D device.

Once those interfaces have been completed, I will post a sample application using the components of the MBLib (MBApp, MBWin, and MBGraphics). That's all for now, so stay tuned for more updates.

OOH OOH EEH EEH

Monkeyboy Library

What is MBLib?
MBLib is a Win32 library that helps simplify the process of making graphics and game demos. Currently there are two modules available: MBApp and MBWin.

MBApp provides a base application interface that organizes the process used for each demo applicaton. MBWin provides a basic window class to get a simple Win32 window up and running with minimal effort. Together, they make it a cinch to launch a basic Win32 application with a functional window. Below is an example of a simple application that uses the MBLib:

// BEGIN demo.cpp

#include "MBApp_application.h"
#include "MBWin_window.h"

class DemoApp : public MBApp_ApplicationInterface
{
public:
    DemoApp(HINSTANCE inst_) : MBApp_ApplicationInterface(inst_){}
    ~DemoApp(){}

    virtual bool DoInitialize()
    {
        if(m_win.Create(string("Demo App")))
            return false;
        m_win.Display();
        return true;
    }

private:
    MBWin_Window m_win;
};

// User-defined factory method definition needed by the MBApp library to create the
// appropriate application interface.
MBApp_ApplicationInterface* CreateApplication(HINSTANCE inst_)
{
    return new DemoApp(inst_);
}

// END demo.cpp

And that is all there is too it. That program there will create a basic Win32 window that has a caption bar, minimize, maximize, and close buttons and also the ability to use the ESC key to terminate the program.

The goal of MBLib is to make this process simple, with extra emphasis on "SIMPLE".

How can I get it?
MBLib can be downloaded from here. Once downloaded, unzip it to a desired location keeping the file structure intact. The include directory houses the necessary header files needed for compilation, and the lib directory houses the necessary library files needed for linking.

What's to come...
In the works is the graphics and input libraries. There progress will be updated here on the site when they become available. Presently, the idea, since the target platform is Microsoft Windows, is to wrap the DirectX API into a simple to use interface to launch application more effectively and easily. So stay tuned for more to come...

OOH OOH EEH EEH