NightCreature83

The matter of the fact is that you need to learn a language and the best one to pick is the one you are most comfortable with, which in your case is C# as you know a little of it already. Learn the language well enough so that you can tackle any problem in it, this will give you the wanted skills (algorithm design, design principles, oop structure and data structures) to move on to any other language. Sadly enough programming is a skill you have to learn through doing it is not something you can pick up from reading books, books however can provide you with insights in how to solve problems.

I jumped languages quite a bit in the beginning, I started of in Pascal moved to Delphi Pascal, then to C# and Java and eventually to C++. Nowadays I am most comfortable in C++ and C#. I never got how stuff worked until I forced myself to learn C++ and all of a sudden I could program in all these other languages as well. My point is stick with a language until you can actually write a non trivial program then switch to another language if you want to.

Frameworks are handy but you don't need to learn them inside out as long as you get a good grasp of how they work you can get a long with any of them, just turns out to be a question of finding out what they are called in the other framework. This also brings me to the final point once you start working you have to most likely get used to another framework which is the codebase everyone in the job works in, and that is the most important thing in programming be willing to always keep learning and adapting to a new thing.

MSVS in 64 bit windows does not allow inline assambler.

To the OP:

The only reason you'd wan't to contol fp mode would be to sync the CPU and GPU. However. this isn't possilbe. The GPU relies on FMA instructions, which have no CPU counterparts (yet), so it's a pretty futile excersise. You cannot get the same results from a GPU and CPU. (at least since gtx400 GPUs).

While that is true the OP didnt state wheter he was using x64 or not, so I assumed not especially since he talked about inline assmbler anyway. However you can still use assmbler if you want to but you have to add an assembler source file and add a reference to the assembler function to the C++ code.

See: he has more videos on how to write x64 ASM and they are good imo.

I read about this all the time but never see it in action. Would someone be so kind to post some code snippets, or books on this topic

Thank you.

Here is a link for how to use Python in C++, Boost has a nice package for this and if I remeber correctly (used this more than 5 years ago) wasn't to bad to marshall between the two: http://www.boost.org/doc/libs/1_50_0/libs/python/doc/

And here is an example of embedding lua in to C: http://www.codeproject.com/Articles/11508/Integrating-Lua-into-C. I believe Lua has a whole documentation on how to interact with C/C++ code on their website.

Ok just to throw another one in there Perforce isn't awe full either and comes with a VS plugin and an IDE, but is sadly a paid for solution but one that is used in a lot of places in the industry.

I found setting up the initial repositories and server far easier than doing the same for a SVN, but that might also just be because I work daily with perforce and not any of the others.

A proper standalone IDE for SVN is rapidsvn btw and it is decent to work with.

All you really want is a static factory function in each object that can be created at runtime for that particular class. This is then stored in a map from string -> callback, and you can then find the creation function based on the name.

The following code implements this and some home brew RTTI implementation which I only added for completeness to the registrar class.
http://code.google.com/p/dxengine/source/browse/trunk/src/ClassRegistration.h
http://code.google.com/p/dxengine/source/browse/trunk/src/RTTI.h
http://code.google.com/p/dxengine/source/browse/trunk/src/RTTIMacros.inl
And this object code shows you how it is used:
http://code.google.com/p/dxengine/source/browse/trunk/src/Object.h
http://code.google.com/p/dxengine/source/browse/trunk/src/Object.cpp

If you forget to add the implement it will cause a compile error.

If you turn depth testing off rendering is done in the order you submit the draw calls in, so say you have two objects that overlap and one is at 0.1 and the other is at 0.2 depth. With depth testing on and rendering the 0.1 object first that would be the object you see, when it is off however the one with 0.2 is rendered last and will overlap the other one.

Are you sure you aren't changing the alpha blend equations as well? If you render something thats changing the Alpha blend state before or after this draw call when you next come to this drawcall the alpha state will not have reset itself.

Only the professional version of Unreal Engine (not the free UDK) allows you to use C++, AFAIK.

Most people don't know this but you can use C++ libraries with UDK by using the "DLLBind" feature:
http://udn.epicgames...ee/DLLBind.html


In fact one clever guy figured out how to trick DLLBind into calling into C# libraries yet this is not officially supported.

Wait for UDK 4 for and we will only have kismet and C++ code they have gotten rid of UnrealScript , also dynamic C++ compiling on the fly. See last 2 minutes of video.

The struct bitfield marker is a leftover part of C.  There are almost no good reasons to use them any more.

Back in the old days, in the 70's and 80's when bitfields were good, memory was very expensive.  There was no on-die cache until the mid to late '80s so anything that touched memory was slow.  There was no CPU pipeline, so if you could use multiple instructions that avoided a trip to memory you could see great performance improvements.  Using a bitfield, or in other words, having the compiler perform bit shifts followed by the compares or other operations you need followed by another bitshift back, was much faster than using a single byte of memory.

Today this is the opposite case.  Memory is cheap and plentiful.  On-die cache can contain more than the largest HDDs of that earlier era; there is practically no benefit to the space usage, and the compressed space may even result in cache alignment penalties.  With deep pipelines, the shift operations are expensive and will stall your CPU.  Using a bitfield in modern code is a huge performance penalty, and should only be used when you have specific reasons to take that penalty.

There still are reasons to use this technique and they will never disappear as long as we have console games. Consoles have a far more restricted memory model then a general PC and they are using modern CPU's.

You also benefit from bit fields when they are embedded in an object where the game or application spawns more than a few thousand of these objects. Compare the size of an object that contains 8 bools with one that contains one unsigned int as a bit field, you have a memory saving of 7*4 bytes per object you create.

There are also ways to break alignment without using bit fields btw

struct
{	
	 short x;
	 int y; //Not on a 4 byte alignment here.
}

There are a lot of valid ways you can use bit fields you just have to be mindful of what you are doing when you do use them.

You've got a vector of Tile, but you're trying to push_back a Tile* (pointer to Tile).

Perhaps try changing your code to:

Tile tile;
tile.rowPos = row;
tile.colPos = column;
tile.rowSpr = rowSpr;
tile.colSpr = colSpr;
TileContainer.push_back(tile);

The whole point of vector is so that you don't have to use pointers and new/delete to store things in an array. All of the heap memory is automatically allocated/deallocated for you by the vector class. Perhaps I'm misreading what you're trying to do, but it doesn't seem like pointers are at all necessary here.

That is part of the problem yes and the cause of the compile error but as soon as the compile error is fixed another one should pop up informing you that you are using a class definition as a variable. To fix that one have a look at the Ripiz post above as that solution will fix your next problem.

For all STL containers, the object value you are trying to put into the container must match the type definition of the container, eg:

std::vector<int> m_intVector; //This can only hold variable of type int
std::vector<int*> m_intPointerVector; //This will only hold variables of type int*

Be carefull with deep and shallow copies of data you push into the vector as the vector will actual make a copy of the object you pass in to push_back and store that in the vector.

Basically what it boils down to is the following code:

if (<Boolean epression setup by D3DRS_STENCILFUNC>)
{
	 //Here you specify what operation to do when the stencil test passes
	 stencilValue = <Equation setup by D3DRS_STENCILPASS>;
}
else
{
	 //Stencil test fails
	 stencilValue = <Equation setup by D3DRS_STENCILFAIL>;
}

I explain this with a code example as this is what the hardware is actually executing and I find this easier to understand then just looking at the API calls.

The masks involved in these equations are only of interest if you want to only look at say the first few bits of the actual stencil value or write to those bits. So when these are set to 0xFFFFFFFF you will write and read from the whole stencil value, when set to 0xFF000000 you will only look at/write to the first 16 bits of the stencil value (this is a 32bit value, it gets converted to 8 bits later on I believe). Bear in mind that the read and write mask don't need to have the same value.

The actual stencil test equation is just a comparison and D3DRS_STENCILFUNC sets which type of boolean expression is used to do the stencil test: "<", ">", "=", etc.
Then stencil D3DRS_STENCILFAIL or D3DRS_STENCILPASS defines what operation is done to the stencilValue: "keep", "+1", "-1", etc when the test passes or fails.

Your problem lies in this

#define D3DFVF_CUSTOMVERTEX(D3DFVF_XYZ | D3DFVF_NORMAL | D3DFVF_TEX1 )

This is not a properly defined FVF.

SetFVF takes a DWORD as it's parameter not a define.

//From the DX SDK documentation
HRESULT SetFVF(
  [in]  DWORD FVF
);

And if you would look at the examples they use in the documentation you see that they all use "const DWORD" variables to define the custom vertex format.
The better way of doing this is to use a vertexdeclaration, which will allow you to use shaders properly as well and will make the switch from DX9 to higher much easier to achieve as the fixed function pipeline is dead.

One option is to just create a bigger buffer - make it large enough to hold data for an entire frame worth of drawing, and don't bother worrying about this.

That may not always be possible.  Depending on how much you're drawing a full frame's worth of data may be too much.  In that case don't worry about it either - just fill and flush the buffer as you need.

The important thing to remember is that there is no guaranteed one-size-fits-all approach to this.  Depending on your application's needs you'll be making adjustments to the recommended basic approach.  Sometimes you'll keep a system memory copy, sometimes you won't, sometimes you don't bother refilling the buffer if data doesn't change, sometimes it's not that big a deal and is cheaper to just fill the buffer anyway, and sometimes using a group of smaller static vertex buffers is preferable to using one big dynamic buffer.

With VB's and IB's the trick is to find the best batch size that works across the set of cards you want to support. I am making a maze crawling game with a lot of 4 verts squares which make up the wall, when I submitted these as seperate drawcalls my performance tanked massively with less then 100.000 verts on screen. When I batched it up into a single vertex buffer performance jumped back to a solid 60 (vsync) on a HD4850.

A good rule of thumb is to try and get about 10.000 verts per vertex buffer if you have massive amounts of vertices to draw, this number can change according to situation and profiling ofcourse.

GPU's are bad at drawing buffers with a low amount of verts in them as most of the card is doing nothing then, but go over a threshold and performance dies as well as the card is too busy to deal with all the data you give it. It's a balance you have to find through some trial and error and profiling.

You got the idea yes, but you need to only fill the buffers when they change no change no update. Change happens either when a chunk comes into the view area or leaves it, or when a block in a visible chunk changes.

Also it isn't bad to have an in system memory buffer of the vertices in the list, it's just that you only send this list when the chunk is visible or a change has happened to it.

class Chunk
{
public:
 void update()
{
//if you add or remove blocks from this chunk mark m_dirty = true so that you reupload the vb and ib
}
private:
bool m_dirty; //Only update the render buffers when this flag is set.
std::vector<Vertex> m_localChunkVertexData; //Change this in the update function and you need to reupload them to the GPU, but only change it when it is actuall there.
std::vector<unsigned int> m_localIndexData;
}

This will allow you to change the vertex list without having to lock the vertex or index buffers untill you are ready to upload to the device. Those vectors can also be local update function members which you write to the VB and IB once you have filled them out with the update you wanted.

If the verts don't change you do not need to update the vertex buffer, and for what you are doing you really want to use a dynamic vertex buffer. Basically any mesh that updates fairly frequently should be stored in a dynamic vertex buffer, any mesh that doesn't should be in a static one.

One more thing that will help you is to not update the vertex buffers when they haven't changed from the last frame, the fastest data you send to the GPU is data you never send. Rendering with the same vertex buffer as the last frame when it hasn't changed will be the same as sending the same buffer again.

You need to send a Vector4 to the shader that contains the location in the texture and the size of the image located at that positoin, all these values are 0..1.

In the vertex shader you then access this to modify the texture coordinates as follows:

Vector4 textureUVInfo; //Passed from application
textureCoord.x = (in.texCoord.x * textureUVInfo.z) + textureUVInfo.x;
textureCoord.y = (in.texCoord.x * textureUVInfo.w) + textureUVInfo.y;

In the above code the actual lookup location in the texture is stored in textureUVInfo.xy and the size of that area of interest is stored in textureUVInfo.wz. All the art assets should just use 0..1 coordinates just as if they are actually textures with a single texture instead of with a spritesheet. In your application you have to store a link between a particular location and size in the texture and which object uses it.

Google Atlas texturing to find out more information as that's what a spritesheet is essentially.