User Tools

Topics I've Started

Something I've been stuck on for a while is the part of the low-level video subsystem that relates to creating/deleting resources and handling memory transfers between the CPU and GPU. There are lots of resources for the submission, batching and drawing itself but never anything about how those buffers, textures, etc. got there in the first place or how the API for resource management is designed. Note that I'm not talking about loading and caching resource files from disk. This is concerned with the low-level aspects of memory and resource management across processors.

One idea I had was a layered API loosely based off of D3D11, where you separate the memory itself (buffer, texture) from how it's going to be used (view). This way, for example, you can allocate a texture and use it as both a render target and a sampler target. Of course, this also brings up the issue of making sure access is "exclusive", i.e. you can't sample from it and render to it at the same time. Another issue I'm interested in is making the API thread-safe. While this is relatively trivial to do with D3D11 thanks to the Device/Context separation, with OpenGL it's more complicated since you have to deal with context sharing and currency.

Basically I'm just looking for some advice, ideas, open-source code to look at, or anything else that can help me see how this stuff has been taken care of before.

I've been thinking about ways to integrate features that traditionally require a flat list into a hierarchical scene graph structure, and improving upon the tree structure a scene graph uses. My solution was to replace the simple tree with a directed acyclic graph, which allows nodes to have more than one entry point. I also realized that generalizing the scene graph and allowing for more than one entry point per node would allow constructs for spatial partitioning and integration with a physics engine, among others.

The main inspiration for this came when I was trying to find a way for an object to be part of more than one partition, for example, when a character is standing in the doorway of a building. It's simple when you can add another entry into the node, so both the "outside" and "building" partitions point to the character, and it can be rendered if either partition is visible.

Generalizing the graph would allow for more flexibility. Typically, every node in a scene graph is associated with a transformation, but this is clunky when physics is put into the mix. Say a character is holding a ball. The "ball" node would be a child of the "hand bone" node. When the character throws the ball, the "ball" node must be moved and its transform changed to keep the same world position. It gets even worse when the character has to pick the ball up again. My solution is to implement transformation nodes as physics constraints. A typical transformation would be a weld joint. Bones in skeletons could be implemented as ball and socket joints. This works well with my engine where animations are all procedural and depend on the physics engine.

Why stop there? The whole high-level rendering process could be implemented in the graph. You could have a shader node, a texture node, and then a mesh node. Because each node can have more than one entry point, you could create multiple passes by forking into two material groups and then joining at a mesh. Instancing could be done automatically for rendering paths identical except for transformation. Nodes could also be general-purpose programming constructs, like a condition (if condition, choose this path, else, choose another path), a random selector, and so on, like nodes in a behaviour tree.

What are your thoughts on this? I want to get some feedback before I hunker down and code this.

I've been using Visual Studio for a little while but I want to go cross-platform. I've just done a fresh install of Code::Blocks 10.05 (with MinGW) from the binary. I open it up and whenever I go to start a new project (whether from the file menu or the start page) it crashes. I saw on the CB forums that it would output the error log to the codeblocks.RPT file, so here's that:

I've been working on a game engine using C# and SlimDX for about a week now. I only really worked with one entity in the world for a while, until today. I then realized that my engine is incredibly inefficient and really needs a rewrite. I am fine with this.

The most likely reason for my poor performance is my heavy reliance on lots and lots of .Net classes, especially dictionaries and lists, to manage everything. I usually end up creating a ton every step, and that's a no-go. So when I'm writing my new engine, how can I stop myself from making too many unnecessary objects? If it really comes down to trying to thwart the garbage collector, I'm up for switching over to C++ and doing manual memory management.