Blog Move

I've moved all future posts about my games to kalasengames.blogspot.com. I will soon be going around and updating my other stuff to reflect this.

Free Camera and Lifted Vertex Limit

I redid the camera to be a free roaming camera. Later I'll stick some limitations and physics to be associated with it so that the camera is more like the eyes of the player. But this is excellent for my purposes right now. Instead of being stuck focused on one spot, I can fly anywhere to observe how the world is coming along.

While redoing the camera, I was going to have to redo a bunch of the draw code. So, while I was at it, I lifted off the vertex limit. Instead of being limited to 65000, it can go as high as it needs to. Only limit will be processing speed. Doing that was quite a bit of work, in that it broke quite a bit and I only just now got everything drawing again. But it does. The only thing is some minor glitches about which faces should be drawing. Shouldn't be much to fix.

After this, instead of height maps, I'm going to focus on what's known as "picking". Basically, it's how you decide what object the center of the screen is pointing at. With that, I'll finally be able to get back to the world where data is virtual instead of necessarily being rendered right on the screen. So I'll be able to do stuff like letting you be able to open doors. Or yes, digging out and placing blocks. The engine behind what I'm doing being similar to Minecraft and Infiniminer, that shouldn't surprise you. It's only once I have this up that I'll be able to do stuff like NPCs and procedurally generated quests.

Textured and Optimizations

I got the blocks to texture, which is a huge step. I also did some optimizations, including one huge one that basically means I shouldn't have to worry about draw speed for quite some time.

There's only two problems I've run into at the moment. The first is in increasing the number of blocks - the "draw all the vertices in this list" command can only take 65000 vertices before it complains. You can get that many when you up the number of blocks. I'll have to split up the vertices to draw into multiple lists.

The second is in baking the "will this face every be seen" info in, when there's a ton of blocks. It only has to be calculated once, right at the beginning. But there's a lot of blocks to go through, and it can take a little while. I'll have to look at what's slowing that down.

Good news is that I can put that off for a bit until I start working with a huge world. I'll work on the free roaming camera next, and make it more so that the player is the camera.

I'm Making a Note Here

Huge success. I finally got blocks procedurally drawing in 3D. With a camera that can navigate around them. I'm still not done with that though. I've got a lot of optimizations to do. To understand them, let me try to explain the process as simply as I can.

The most efficient way to draw something in 3D is to put each vertex into what's known as a VertexBuffer. Then, all at once, you draw them. Something about the order you fed them in determines where the faces are drawn on them. Also, you end up feeding in more vertices than you finally use, because some of the ones you fed in are shared. For each triangle, you need 3 vertices. For each square, you therefore need 6. And for each cube, you need 36. On a cube, a total of 8 vertices are eventually actually used. If you don't fill the buffer and render them all at once, you end up with wasted things that could have been shared.

Right now, I draw each block individually. I tried combining them all into one buffer the first time, but that didn't work out. From the point I'm at, I can now move towards doing that optimization.

Second, the algorithm I mentioned previously about which faces need to be drawn. Right now I'm not using that - I draw every face of every block. I need to do that optimization. Once all that is done, I should be able to render a ton of blocks very efficiently. Right now, before the optimizations, it's lagging a little with only 20x20x2 blocks. But there's a lot of optimization that can be done.

3D Faces and Camera

I'm still working on getting faces to draw properly. The problem is that they don't want to pay attention to the camera - they're pasted directly on the screen, with no basis on where they actually are in the world and where the camera is. Attached is a screenshot of that, with a square and cone imported model to demonstrate that.

Yet it does seem to be the way to do it. My guess is that I've left those in some sort of render mode that I don't need; I'll see about rendering them the same way as the models. On the plus side, I know how to navigate a 3D camera now. I just have to get the faces drawing right in 3D space. If I can get that going, I can start assembling the world out of blocks.

Block Engine

Okay, so forget Infiniminer. I just came up with a good algorithm for deciding which faces of a block need to be drawn. It's working perfectly. Quite simply, it checks whether the block adjacent to the face is transparent. If so, the face needs to be drawn. BAM. I bake it into the blocks at first world gen, and will update it whenever transparency of an adjacent block changes.

Also, at most three faces will need to be drawn on any block at any time, depending on the position of the player relative to the block. If the camera is higher that the block, the bottom obviously doesn't need to be drawn. Same for all sides. It's a simple "is a greater than b" check, and saves a face needing to be drawn.

The tricky part now is drawing individual faces in 3D space. Not to mention it will need proper texture sometime. So, I'm looking through XNA guides for drawing things in 3D space. A lot of the tutorials are for 3.1, and don't work with 4.0 which I'm using. Others are 4.0, but use stuff that only the HiDef profile can use, which my computer isn't wanting to play nice with. I got one tutorial working that drew a textured square perfectly... directly onto the 2D plane of the screen. I need it in 3D space, where the camera can move around it. I'm looking at a MSDN guide at the moment.

I'll keep you posted on progress. As soon as this is worked out, I should be able to post screenshots.

Infiniminer Source

I spent the day working with XNA, trying to draw cubes. I got one drawn, but it was white, rather than covered in grass like the model should have done. I tried messing with the material to be not an image file, and that only partially worked - it was greenish, but not like it appeared in Blender. Anyway, that's good enough for me to start working on multiple blocks. So I did.

When I filled a 3D array with them, it worked... but it rendered very slowly. Whatever I'm doing is apparently an inefficient way of doing it. It was about this point that I discovered something: Infiniminer was written in XNA and C#. Exactly what I'm using. Infiniminer uses the world-out-of-blocks system. And it apparently works well. It's also open source. So I'm going to crawl through the source code and see if I can't learn some ways that they were using to get all those blocks to be handled efficiently enough to run real-time. From a preliminary skim-through, what I need will be buried pretty deep into the specific implementation Infiniminer did. Apparently it's client/server based, and it didn't have an XNA Draw() method. So I'll have to more carefully look into how the world is kept and rendered.

I am also realizing that I need a blog not just for Adventurer, but for all the games I work on as a whole. I'll see if I can't rename this blog, or else make a new blog and link you all to it. Also if you'd really rather me return to Adventurer rather than work on this, go ahead and vote over on the right side of the page. Likewise, if you're excited about this, go ahead and vote. I'd like this to be fairly community driven.