06/10/05

Hey, I know what you’re thinking, “What’s up with all these C# samples? Are we ever going to see any new OpenGL samples?”

If that’s what you're thinking, then the answer is, Yes!

On the other hand, if I’m wrong and you’re actually thinking, “How can I get Leonard Nimoy to eat more salsa?”, I can’t help you, but I know of a place where others, like yourself, can congregate and ponder this age old question.

For the rest of you, C# samples for some; new Cg displacement shader samples for others.
 

06/06/05

The managed madness of Microsoft's DirectX 9.0 and C# combo continues as I add two more C# samples to the site. The first one introduces the 6 primitive types supported by Direct3D and the second one deals specifically with loading vertex buffers from a data array using a GraphicsStream. I think you'll find both very useful:

06/02/05

For those who are interested in the weekly Direct3D/C# port, the port for this week is the "multiple view ports" sample, which may sound boring to you aspiring .NET game programmers who feel I'm moving too slow in my porting efforts, but don't lose hope. The sample also demonstrates how to load a simple Mesh object from a .x file and light it, which is definitely a step in the right direction.

So, with out further adieu, let me introduce you to the quintessential model of 3D graphics and game programming... the teapot!

Teapot, meet newbie. Newbie, this is teapot. Now, you guys go play, and remember - no rough-housing!

05/27/05

Due to popular demand, the DirectX 9.0 samples offered here will be ported from C++ to C#. I've already finished the first two, but the rest will most likely come at an interval of around one a week.

Now, with that said, I must warn you that I'm pretty new to C# and the whole managed code thing of .NET, so if I'm doing something blatantly wrong, or misusing the terminology, please let me know. Then again, I am a programmer of vast intellect... so how could I error... it's "inconceivable"!

05/25/05

As many of you know, earlier this year I released an OpenGL sample dealing with multi-texture blending, which demonstrated a popular technique used by terrain rendering engines to blend terrain textures together.

The technique basically uses two OpenGL extensions, and a specially encoded vertex color to blend three textures together at each vertex point in a mesh. This, of course, led many people to ask, "Why not just use a shader?"

Why not indeed!

Therefore, I wrote a new sample that blends the same three textures together on the hardware with a shader. It's definitely more intuitive than using the OpenGL extensions, but depending on your card, it may not run as fast as the older version that use the OpenGL extensions. Of course, maybe my Cg code is sub-optimal, but I don't see anything obviously wrong with it. If you do, bring up in the forums and we'll work it out.

05/22/05

For advanced users, I’ve added two new Direct3D samples dealing specifically with the proper usage of the D3DXMesh object.

Typically, instances of D3DXMesh are generated automatically by Direct3D when we load a ".x" file, but occasionally it’s necessary to create and manipulate these objects manually.

With that said, the first sample deals with how to manually create and load a D3DXMesh object. This is useful if you would like to substitute one mesh object for another, or modify an existing one.

The second sample deals with how to use the attributes table of a single D3DXMesh instance to load and render multiple pieces of geometry. If you’re already familiar with the DrawSubset method of the D3DXMesh interface, then you have already used this feature when rendering regular ".x" file meshes.

05/11/05

After some discussion on the forums and some personal research into the matter, I’ve decided to offer both Python and Lua samples, which deal with adding a scripting system to C/C++ applications.

While I still prefer Python for everyday use, Lua does have some advantages when it comes to the specific task of adding a scripting system to a game engine.

My basic feeling on the matter can be summed up like so:

Python is powerful and has a great collection of utility libraries, so it’s excellent for extending and embedding content creation tools like level editors, but its powerful nature makes it more complicated to implement and harder to squeeze good run-time performance from it, so it may not be a great choice for performance critical apps like a game engine.

For a game engine, where run-time performance is paramount, Lua seems to be a better choice since it’s much leaner and easier to integrate. It’s definitely lacking a good collection of utility libraries, but this hardly matters since the scripting systems typically added to game engines are much more geared toward setting up and initializing game objects than performing lengthy logical calculations.

Of course, this is just my opinion, but this does appear to be the general consensus amongst professional game developers who have researched and/or actuality used both Python and Lua in their projects. And when you think about it, this analysis makes sense when you consider the primary goals of Python and Lua: Python’s primary goal is to be a powerful, "general-purpose" scripting language while Lua’s primary goal is to be a lean, "bolt-on" scripting language for C/C++ applications.

Can you use Python as a "bolt-on" scripting language for C/C++ applications? Yes, but this was not a primary concern when designing Python. It was designed to be "general-purpose".

Likewise - can you use Lua as a "general-purpose" scripting language? Yes, but again, this was not a primary concern when designing Lua. It was designed to be integrated or "bolted" onto other applications.

More Site News...