As you can see in the images I have attached your picking is not quite accurate. I haven't dug into the code yet so I can't suggest a fix at the moment.

http://www.minddesk.com/qubicle_constructor.php

http://create.msdn.com/en-US/education/catalog/sample/lens_flare

Go over block getter & setter blocks, they may need tiny fixes & has space for improvements.

Blocks in chunk range doesn't get re-built when a block is digged

As suggested by Delwin9999#7, the engine needs mod support.

• All the interfaces and subsystems provided by the engine should be overridable which will probably require huge refactoring.

http://gamedev.stackexchange.com/questions/31241/random-map-generation

After render AimedBlock, BlendState has changed to BlendState.NonPremultiplied
that made incorrect to other Draw method
way to solved this issue is keep old state and restore before end this method.

Can we use Flyweight pattern for blocks?

I think engine itself should be free of any UI stuff (maybe except the new debug-console). And for the basis Nuclear Winter is a good candicate.

• Delwin9999#6 UI - Add one

Engine has the private static _instance attribute and assignment to this of a singleton but the constructor is public. This means someone could instantiate it twice thinking they'd get the same instance (as you would with a real singleton) but in fact they'd overwrite the first one's _instance with the second one and the game state would be unrecoverable.

This should be a real singleton pattern. The only reason it isn't right now is that the unit tests fail when I tried to do the conversion on my branch. When I become more familiar with the unit test harness I will be able to untangle that and I can throw a pull request for the fix at you.

Assets should be managed by the game itself and engine needs to be only aware of what it needs with our configuration interface (like block textures or so).

• http://www.gamedev.net/topic/580927-aabb-terrain-occlusion-culling/
• http://techcraft.codeplex.com/workitem/13

Models in game-content are not compiled correctly somehow, which affects the sky renderer.

http://create.msdn.com/en-US/education/catalog/utility/graphics_profile_checker

The XNA Framework GraphicsAdapter.IsProfileSupported API enables you to check whether the current hardware supports the Reach or HiDef graphics profiles, but this only returns a simple boolean, with no details of why a failing profile isn't supported.

This utility provides more information about hardware capabilities, by performing the same checks that are used internally by the XNA Framework and by displaying their results as a detailed failure report. This can be useful for investigating driver compatibility problems, and also to see exactly what hardware capabilities are required for each profile.

Unlike most XNA samples, which are written in C#, this utility is written in C++/CLI (the .NET version of C++). This allows it to call directly into the native Direct3D API, thus obtaining more detailed caps information than is available through the XNA Framework graphics API. You'll need to install three things before you can build this utility:

We have major issues in engine architecture.

• Delwin9999#3 - Entire architecture is tightly coupled. Decouple it
• #46 - Engine itself should be free of Camera and Player.
• #43 - Engine is a singleton without the protections thereof.

http://www.minecraftwiki.net/images/7/78/TerrainGuide.png
http://www.minecraftwiki.net/wiki/Texture_Packs

Improve debug graph capabilities

• http://create.msdn.com/en-US/education/catalog/utility/performance_utility

http://create.msdn.com/en-US/education/catalog/sample/split_screen

Blocks top-face's texture drawn buggy.

Somehow only one side of the chunks doesn't get rendered even if that side is edge.

Clean:

• a8fb05b

Offending:

• 3d63a73

Add debug-commands for ingame debug visualizers.

Implement minecraft texture pack support

Should be some strange bug that I've introduced sometime ago.

As suggested by Delwin9999#11, we need it.

The current code documentation should be improved and generated (with doxygen or whatever) - and for sure we also need getting started tutorials.

• http://techcraft.codeplex.com/SourceControl/changeset/view/19900c922855#TechCraft/TechCraft4.0Engine/WorldEngine/Generators/LandscapeMapGenerator.cs
• http://www.float4x4.net/index.php/2010/06/generating-realistic-and-playable-terrain-height-maps/

Time ruler is buggy (it doesn't obey screen limits) -- even better move it out of engine to sample game project.

Implement block cracks (dual texture support)

Implement EngineConfiguration support that will handled by the game at Engine startup, that will hold the common configuration parameters like view-range, cache-range and so.

Lighting right now uses chunk neighbor pointers. Fix it!
Also Slaihne's technique seems better - http://blokworld.forumotion.co.uk/t6p30-lighting-technique#614

Idea originally by Delwin9999#15;

• tools to create new inventory items
• tools to create new block types simply
• particle system generation tools (effects)

For sure we need to work out the block-system to allow game itself to define them. Inventory and particle system needs to worked from scratch.

• Delwin9999#14 Add asset based block type

http://create.msdn.com/en-US/education/catalog/sample/nonrealistic_rendering

• http://techcraft.codeplex.com/workitem/13
• http://www.gamedev.net/topic/580927-aabb-terrain-occlusion-culling/
• http://msinilo.pl/blog/?p=194

• Fix all negative values for chunk & block accessors.
• Check all accessors & remove unneeded ones.
• Write unit tests for accessors.

Implement water blocks (transparent chunks)

Implement multithreaded chunk processors.

As suggested by Delwin9999#12 we need an entity system so that we can implement player, npcs and other stuff.

• Delwin9999#12 - Add NPC capiability
• AI Task management & prioritization
• AI Friend/Foe management
• Inventory Managment
• Pathfinding
• Delwin9999#13 - Items

https://github.com/mono/MonoGame

As this isn't any kind of server-like software, I don't think we need configurable loggers. So I'll be refactoring out logger configuration functionality -- and will bind the console and file log will be just statically.

As of right now, these exist in the Engine code itself but it should be free of them and Camera related the values should be provided by the game itself as configuration to Engine. So that anyone could just use it for FPS, RTS or some other kind of game.

Camera issues;

• Delwin9999#16 - vertical looking is not clamped to prevent looking past vertical
• Delwin9999#1 - Detachable camera
• Delwin9999#2 - Move hard coded values out to asset files
• Delwin9999#8 - Collision detection is off

Player issues;

• Delwin9999#4 - Find aimed block is not finding the most intuitive choice for a block.
• #72 - Block picking is offset

Implement oldskool support?

• http://code.google.com/p/oldskool-voxel/
• http://www.kongregate.com/games/pintsized/oldskool-designer

• http://www.minddesk.com/qubicle_constructor.php
• http://code.google.com/p/sproxel/

Voxeliq currently uses an advanced optimization to improve rendering performance, in simple worlds while building the mesh for a chunk, instead of building the complete mesh for the chunk, it only builds it partially (basically it doesn't include blocks in the mesh where user can't seem them).

Check this graphic;

So lets say that a chunk may had landscape generated around y=50 ~ y=55.

• So with out the optimization, the mesh would contain all the blocks from y=0 to to y=55
• which means more blocks in the mesh = more polygons in the mesh = lower rendering performance.

So the ideas is that, user will not able to see blocks below the lowest-solid-block-index(y) in chunk.

As in the screenshot above, users will not be able to see blocks below the [chunk's lowest block index - 1](marked with purple).

And the optimization arrives here, where we only build the mesh between [chunks highest block index + 1] to [chunks lowest block index -1].

This optimization is all good and improves the rendering performance a lot but with a given drawback; with every set-block operation, chunk's highest block index and lowest block index values have to be updated.

In the current state of the engine, this is done in landscape-generation after every block-set operation;

air (empty) blocks
                    BlockStorage.Blocks[offset + y] = new Block(BlockType.None);
                    if (chunk.LowestEmptyBlockOffset > y) chunk.LowestEmptyBlockOffset = (byte)y;

---
(solid blocks)
                    BlockStorage.Blocks[offset + y] = new Block(BlockType.Dirt);
                    if (y > chunk.HighestSolidBlockOffset) chunk.HighestSolidBlockOffset = (byte)y;

The problem is that this is an engine and forcing game-developers for so, will increase the entry barrier of engine higher and will make things complex.

A solution is that using the available SetBlock methods which can find the chunk block belongs to and do the calculation on it's own.

        public static void SetBlockAt(int x, int y, int z, Block block)

The problem is that setting blocks in a block-engine is an operation used millions of times. The current method we use in first code snippet is automatic (or close enough being atomic at least in our context - as it just sets a byte value in our Flatten Block Storage array).

The latter solution in second snippet means calling that SetBlockAt() functions over and over millions of times, which for sure will decrease the performance a lot - here's a proof of concept test; http://www.dotnetperls.com/inline-optimization

So I've been looking for possible solutions and here's what I've came up with;

Statement Lamdas
As I've discussed it here and they maybe a solution but I'm not sure yet, will check it further & profile.

Conventional way:
-----------------
L_0000: nop 
L_0001: ldarg.0 
L_0002: ldarg.1 
L_0003: ldarg.2 
L_0004: ldarg.3 
L_0005: call int32 VolumetricStudios.VoxeliqGame.Chunks.BlockCache::BlockIndexByRelativePosition(class VolumetricStudios.VoxeliqGame.Chunks.Chunk,
 uint8, uint8, uint8)

Statement Lambdas:
------------------
L_0000: nop 
L_0001: ldsfld class [mscorlib]System.Func5<class VolumetricStudios.VoxeliqGame.Chunks.Chunk, uint8, uint8, uint8,
 int32> VolumetricStudios.VoxeliqGame.Chunks.BlockCache::BlockIndexByRelativePosition3
L_0006: ldarg.0 
L_0007: ldarg.1 
L_0008: ldarg.2 
L_0009: ldarg.3 
L_000a: callvirt instance !4 [mscorlib]System.Func`5<class VolumetricStudios.VoxeliqGame.Chunks.Chunk, uint8, uint8, uint8, int32>::Invoke(!0, !1, !2, !3)

The second solution is MethodImplOptions.AggressiveInlining that was introduced with .net framework 4.5. But I'm not sure if we'll be able to change our engine projects framework version to 4.5. Will also try that.

I'm looking for other possible solutions.

Interesting reads on the topic;

• http://blogs.msdn.com/b/ericgu/archive/2004/01/29/64644.aspx

We need networking support as suggested by Delwin9999#10 and a server project which I've some ideas;

• We could use a service based implementation just as in Diablo III with google protocol buffers and bit-buffer based packets for ingame-data.
• Run-lenght encoding and diffing chunk blocks is another good idea.