Works like a charm, more or less :D

Alrighty, this post is just like the previous one, not so much for average Joey, and a bit more for people interesting in programming and the problems we are faced with :)

well, the idea i had about a VBManager seems to work just like i was hoping it would (atleast in small scale tests), i am rather impressed with how clever it is(if i may say so my self) ;-)

I did notice a rather interesting phenomena however.

When i search for new blocks, I always need to find the smallest possible block, or it will split big blocks and create smaller ones witch is harder to recycle.
consider the following example:

|XXXX|FFFFF|XXXX|X|FF|

If the game engine needed to change the 4th chunk, and convert it from a single X block to a XX (size 2), then it would find the first empty one (chunk number 2, with a size 5) and split it into 2 smaller objects, like the following:

|XXXX|XX|FFF|XXXX|F|FF|

This is not good!, because small objects are less useful than big objects most of the time.
we want our engine to cycle the VB data as effective as possible, and the next time need a 5 sized block, it would not find one, instead it would add a new block at the end of the line, and our use of resources has increased:

|XXXX|XX|FFF|XXXX|F|FF|XXXXX

Of course, one other thing changes now, the engine notice there is two small empty block(F and FF) next to each other, and convert them into one FFF block.

|XXXX|XX|FFF|XXXX|FFF|XXXXX

and that is what we end up with when everything is done.

Now lets compare the previus end result with how things could look if the engine prioritized small objekts in searches:
|XXXX|XXXXX|XXXX|F|XX|


This is not a very serious problem, it should be fine to try and find the smallest object possible with correct size and use that one, still... this is one of those things you don't consider when you start planning something :)

However, this is all a rather extreme scenario, but it shows how the technique currently would make bad choices and make it harder for it self to be effective later, but this i will fix soon.

still, i really like this way of handling my VB, and i think it will work out just fine in the end :)

A few problems, and solutions :)

Okay, so like every other project, there are always a few problems along the way one have to solve, some bigger than others.

One of those is probably the issues surrounding the VertexBuffer(From now on called only VB) and the nature of games like Minecraft(games with destructible world).
The problem is that every chunk in the world can have(and are likley to) have different amount of vertices's in them, and whenever a chunk is changed, the amount of vertices's will increase.
This means that it can be complicated to dedicate areas of the VB for something that can change in size.

So, i had to figure out a way to dynamically request storage in the VB for the size i needed.

And i did had an idea that i think should do it, at a slight performance hit however.

The solution:
I create an VBManager, and it internally stores both the VB, and a list of objects that keep track of every chunk, how much it stores, from where to where.

When my engine decides it don't need a block anymore(moves out of view-range for example) it marks the block as FREE, and can then be used to save other smaller chunks to the VB.

When i need a new chunk of data in my VB, i check every item in my list for an FREE object that is equal or bigger than the size i need to store.
If the block i find is bigger then the one i need to store, I simply subtract the difference into a new block and mark it as FREE, while using the other section to store my data in the VB.
if i didn't find a single object marked as FREE, i simply create a new object in the end of the list in the correct size and store my data.

to Finnish things off, every now and then, i check blocks who are FREE, to find other FREE block's that are next to it, if there are any, i make one big block of all those.
This removes small left-overs and creates more usable blocks.

The problems of this solution:

Well, its not entirely flaw-less i guess, especially in the beginning, it would probably generate allot of blocks before it starts to cycle old blocks as much as i want it to, but i think it should not be a problem after a while.

There is also a performance hit, if we have 200 chunks, we search more than 200 block for every change made in the world.

This however could possibly be solved with some form of Binary search tree, but that is a later problem, for now.. i believe this solution should work(still in the process of writing it).

Not sure how interesting this information is for the average joey, but there you have it :P


[edit] made some changes in the text.