text:
How can I automate high-level user interactions to test correctness of my game?
I am trying to automatically simulate the game experience in my programming game. I think Expect is the way to do it because it creates its own tty for the process, becoming independent process of the main process but I want that some key sequence is pressed down in some pattern, such as press the key Z down every minute or press this that with this that pauses, without really expecting any specific file descriptors. Is there some ready programs to automate this kind of high-level debugging?
I have access to obsd and ubuntu.

Related: http://gaming.stackexchange.com/questions/21167/how-to-press-a-key-repeatedly-without-really-typing-it-in-lord-of-ultima-javascr

It's basically the same question, just worded differently, so as to circumvent the rules that prevented gaming.SE from answering the question. Personally, I have no problem with the question here, it does not break any rules, it's just that it's similar (in, how can I put this... meaning? I think, but that might not be the correct term) to the previous one. They are related insofar that they refer to the same basic functionality of the program you want to build and use (pressing the same key or sequence of keys every minute or so). They are similar questions, no matter how you put it.

That's a related question, but useless answer in this context. The answer given there was that it violates the rules of the game, which is a helpful answer for a player but useless for a developer. Now, since he asked both questions it seems likely this is a veiled attempt to con us into helping him cheat, but that's a separate issue.

@jhocking - I linked to the question, not an answer...

There are ways to do the high level testing, but I'll throw in my 2 cents about this approach first! I think if you instead implement unit testing on each aspect of your game, it would be a better test. If you make some test that runs whatever function is called when you input that key sequence, just provide the unit test with all key sequences that you think might break the function. If it works for all key sequences, then you know the internals for that function are good and you can go on to test the link between the input box and that function. That test is easier and you only need to make sure the data gets passed to the function. After all of that works, then the testing above that is usually done by play testers, or in your case you. The top level test would need to be done either way.
Now, to answer your question, before I knew what unit testing was, I used something called workspace macro recorder to do exactly what you're asking. Given, your program may need some sort of testing that I'm not thinking of, but if your program fits in the general scope that I'm thinking, my previous approach should be more helpful.

blah, just read the other post, you're hacking a game, oh well. just use workspace macro

In short game event logging and replay is how you automate this. I don't know of any 3rd party software that does this (qualifier: SDK to integrate into app), but doing it yourself is both really easy and perhaps really hard.
You use game events to mean stuff like "pressed the X key" or "moved the mouse by (10,2)"
You play the game once recording each keystroke/mouse movement and the precise time it occured relative to the start of the recording. Once you are finished recording, you run the program again, but instead of generating the events from the mouse/keyboard, you simply play back the events you recorded, in order, at the right time. So, say if you found a reproducible bug that takes a few minutes of running around waving a sword or jumping into a wall, then you can record all of your actions and replay them again and see if you get the same results (if you have a deterministic engine, you should). Then you can make fixes, play it back again, etc. until the bug is fixed.
Though it isn't the same purpose, you've probably seen this method in old arcade games ('demo mode' before you insert a coin). It would have been too expensive to simply record a fullscreen demo to playback when the machines have < 1024KB of RAM, so the they record the actions and play them back as a sort of "real-time video" or "compression".
Getting the game/engine to be deterministic is a lot harder though.


text:
shuffle a sprite group
Is there a way to shufle a group of sprites created with:
pygame.sprite.Group()

I have tried using random.shuffle but it apparently doesn't work on sprite groups.

Since groups are an iterator, you can use:
sprs = list(spr_group)
random.shuffle(sprs)

You should not rely on Python's hashing order to randomize sprites for you. It is not a good RNG.

According to pygame documentation:

The Sprites in the Group are not ordered, so drawing and iterating the Sprites is in no particular order.
  http://www.pygame.org/docs/ref/sprite.html#pygame.sprite.Group

I think the best you can do is not to use the Group, and make your own group mechanism.
If you need only ordered update then use http://www.pygame.org/docs/ref/sprite.html#pygame.sprite.OrderedUpdates

Thanks, I will keep the sprite group though. Your first sentence is correct, each time I create/empty/create the group it comes back in a different order, which is just what I need.

-1. If you desperately need the group to shuffle you can simply subclass Group, you don't need to avoid it. But you probably don't want the group per se to be shuffled; you just want a shuffled copy of the sprites in the group.

As other already said, the sprite.Group iterator yield its members in an unordered way (like a dict, not like a a list).
So if you're after a simple unordered list (not properly shuffled with a random method - if you want that follow user744's answer), just get what it gives by default.
The "problem" here is quite the contrary: how to get an ordered list of sprites from it (or a sprite by its index in the group)

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

sort: votes


text:
sprite group doesn't support indexing
I have a sprite group created with pygame.sprite.Group() (and add sprites to it with the add method)
How would I retrieve the nth sprite in this group?
Code like this does not work:
mygroup = pygame.sprite.Group(mysprite01)
print mygroup[n].rect

It returns the error: group object does not support indexing.
For the moment I'm using the following function:
def getSpriteByPosition(position,group):
    for index,spr in enumerate(group):
        if (index == position):
            return spr
    return False

Although working, it just doesn't seem right...
Is there a cleaner way to do this?
EDIT:
I mention a "position" and index but it's not important actually, returning any single sprite from the group is enough

The answer to your other question seems like it answers this one as well.

Actually not anymore. I'm keeping the sprite group as I don't need to shuffle it anymore.

If you continue down this path of madness, at least update getSpriteByPosition to return None instead of False - False is equal to integer 0, which is a valid index.

What do you need the index for? Since sprites are hashed, the index is not stable; since you can't use it to easily find the sprite again, I don't know why you'd want to store it; and since you can't easily get from a sprite to an index I don't know how you got it in the first place.
If you need a reference to a sprite, reference the sprite itself, not its index.

I'm not trying to index sprites inside a group. I just want to get the first or second sprite in the group, whatever it is and whenever it has been added to the group. (thanks for return None)

Groups are not ordered so "the first sprite in the group" is a useless designator. What you probably actually want is "the player sprite" or "the enemy ship" or something. Store those when you make them, don't rely on being able to pull them back out of a group by the weakest handle imaginable.

hmm, it looks very well ordered to me. As a test I tried removing a sprite from its group (and printing the sprites names in the group before and after removing it) the sprites order is kept and I can get any sprite inside the group by "position" with the code above... but I understand a sprite group is here to keep all the "similar" sprites together for easier update and not to index them.

Removing a sprite is guaranteed, at the very least, to shift all the objects past it down by one. Removing many elements may make the dictionary shrink, rehashing. Adding elements is guaranteed to make the dictionary grow, rehashing. Indices into the key view/list - which are what you get when you make indices into the sprite group - are not reliable.

Understood and agreed. Note that what I want to do is take any single sprite from the group. The code above does that and is not an aberration. If there's a better solution to achieve this, I will accept it. (in the question I mention a "position" or index but it's not important actually, getting any single sprite from the group is enough) I'm wondering if your answer to the linked question (shuffle group) would not work for this purpose as well...

if all you need is a single arbitrary sprite from the group, you can use iter(grp).next() and be ready to catch StopIteration if it's empty. But I honestly can't think of a use case for grabbing an arbitrary sprite from a group.

You can save a reference to the sprite elsewhere. Game class might have a variable pointing to the player instance, as well as sprite list.
You can have a reference to one sprite, in multiple sprite groups. Ex: Starcraft unit selections, could use a unit_list of all unit sprites. And a sprite group for selected_units.
player = Unit()
units = pygame.sprite.Group()
units.add( Unit(), Unit() , player, Unit() )

# use player, by ref.
print player.rect
for unit in unit_group:
    print unit.rect

If you really, truly, absolutely want access a sprite by index, you can do this:
third_sprite = mygroup.sprites()[2]

So your function would be:
def getSpriteByPosition(position,group):
    return group.sprites()[position]

Which throws IndexError if the index is not found. If you want to return None in that case, simply enclose the line with a try block:
def getSpriteByPosition(position,group):
   try:
       return group.sprites()[position]
   except IndexError:
       pass

But... quoting user744, "What do you need the index for?". Afterall, the index of a sprite changes when you add or remove sprites to that group. And even if you don't, Pygame does not guarantee the list order will be the same in each call. So what do you mean by the "3rd sprite in the group"? It may be the 3rd now, but the 5th or 2nd later. How useful is that for you?
Simply put:
Being the nth sprite in a group means absolutely nothing !
(as a side note, position is a poor name for an index, as it might get confused as the sprite (x,y) position on screen)
Another sidenote: try to think OO. Instead of a function that receives a group as argument, subclass Group and create a custom method, so you can use it like mygroup.getSpriteByPosition(3)

As others have already said, you should probably refer to a sprite by something else then its order of addition to the group.
I'll try to give some examples of uses both using a group and a regular list.
sprite.Group
You can iterate over sprite.Group (or sprite.Group.sprites() - both give you the same) and check each sprite against some criteria.
Should you need to remove "dead" sprites, for example, you could use:
wanted_sprites = [sprite for sprite in mygroup if not sprite.alive]
# replace .alive with whatever condition you need
for sprite in wanted_sprites:
    sprite.do_something()

or simply:
   [mygroup.remove(sprite) for sprite in mygroup if not sprite.alive]

list
However, if you really need to keep a sprite's position in a list, why not just use a regular list?
Instead of using mygroup.update() (one of the sprite.Group functions) you would have to use:
[sprite.update() for sprite in my_sprite_list]

or
[sprite.update() for sprite in my_sprite_list if sprite.visible]  # or whatever condition

For collisions, what really matters is the sprite.rect anyway, so you could check if a sprite collides with the last sprite of your list with:
some_sprite.rect.colliderect(my_sprite_list[-1].rect)

I've tried to say something about different possible needs to deal sprite.Group/list, but, in the end, you should consider your specific needs (and possible future needs) to decide what to do:

change your logic to use a sprite.Group (changing the way you search for sprites);
or change your logic to use a list of sprites (replacing the few
functions that the Group has with your own).

Use Sprites method on the group, it returns a list of all the sprites on older pygame versions. And an "ordered" list if your using pygame 1.8, which is a new feature.
Like this:-
Bullet = Group()
Out_list = Bullet.sprites()
Or
Our_list = Bullet.sprites().copy()
"We use copy method if we are going to do modifications on the list,it might get mess if we dont"
Our_list[index]
"by putting your index in the square bracket you get  access to a sprite in your list"

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Initializing Direct X
I've recently starting with Direct X;
I've been using Rasertek's tutorials, and Frank Luna's book. One thing thats just out of this world to me is how much effort it is to initialize DX11: the swap chain and everything.
So...maybe to give myself a little bit of peace, is it mostly always going to be the same? I mean in Rasertek's tutorials it's like 8 different files, while nicely laid out seems to be a bit much; but I guess is it just required? It just seems a little long and hard to understand (the swap chain and everything).....but I guess my questions are:

Why is it so long, unlike OpenGL's initialization to start drawing which is 1/100th the size (it seems like)?
Is it basically going to be the same (Swap Chain, Message Handlers, etc) for all DX APIs (I'm working with DX11)?

D3D10+ expose a much lower-level view of the driver/card than D3D9 did -- there are a number of nice advantages to this (control, consistency) but they come with costs, and one of those costs is that the API is much more verbose. Fortunately it's not hard to encapsulate all that verbosity away so you only need to deal with it once or twice.
For D3D10 and up, the general process will be quite similar. 9 is, as I noted, much different and a lot simpler. If you're using D3D11, you should be good to go for quite some time now.

Gotcha. It's just crazy having like 4 different Classes JUST to initialize something, Im going through the classes and MSDN docs to understand everything. but man... lol

It's overwhelming at first, but you can just wrap it all up behind a nice interface relatively easily.

I feel kinda bad copy and pasting some of the stuff (like swap chain).....but it seems like alot of it is that way. Like there are LOTS of repeatable stuff.

DX10/11 requires more than DX9, because they have DXGI. However, there is a shortcut function. More importantly, the initialization to start drawing is pretty trivial, compared to what you're going to have to go through to load assets, etc.
http://msdn.microsoft.com/en-us/library/ff476083(v=VS.85).aspx

I wish there was an easier way, but I think Rasertek's tutorials he/she is setting up everything for future tutorials......which makes sense at why it's so long.

Also what is this shortcut function you speak of?

The function he linked is a shortcut, of sorts. You still need to fill out the description structures, but D3D11CreateDeviceAndSwapChain is much easier to use than manually creating the device and swap chain.


text:
Conversion from matrix defining rotation and position to camera matrix
I have a matrix that defines the rotation and translation of an object, relative to (0, 0, 0). Assuming that the identity matrix defines the camera to be at (0, 0, 0) pointing at (0, 0, 1), how would I go about constructing the view matrix from the world + rotation matrix?

Assuming I've understood the question correctly, you need to inverse the matrix. The inverse of the matrix is a matrix such that a multiplication between it and the matrix it is an inverse of will result in the identity matrix (i.e. 1,0,0,0 ,0,1,0,0, 0,0,1,0, 0,0,0,1). I'm not sure if you're using Opengl, D3d or whatever but your library should include functions to calculate the inverse. Bear in mind that calculating the inverse is not trivial and shouldn't be done say, once per vertex - you should calculate the inverse of the view matrix only as often as you change the view position.
HTH.

Will this actually give me the view matrix? As in, the matrix required to project world space into camera space?


text:
Simple Terrain Rendering
For some reason I can not find a good example of terrain rendering, as in like "bare bones". Im reading Introduction to game Programming with DX10, and i've seen some other tutorials....but they all are complicated classes with ALOT of stuff thats unnecessary, and tbh just confuses a beginner like me. Like Raserteks tutorials are awesome, but it's SOO much code and classes, it's very difficult to understand the "3d" part when you have so many other classes.
Im just looking for the most BASIC terrain rendering (using a heightmap....or what have you).
It doesn't even have to have a camera or movement control, hell it can just be of one color. Im just trying to understand everything first. Does anyone know where I could find a sample of this? or heck if anyone would be willing to provide a simple sample of their own i'd be mega appreciative.
Dont get me wrong, the Book is great.....and I understand the functions, but the way the classes are put together...it makes it confusing of "what goes where".
edit: I've seen some Direct X 9 terrain demo's/samples....but isn't DX9 like WAYYY different from DX10 (if so thats why I wouldn't want to waste time on it). I could be wrong though.

D3D9 is quite different from an API perspective than D3D10, but the underlying concepts are very similar. Any terrain rendering example in D3D9 (such as this one) will work fine in D3D10, you'll just have to translate the API calls which shouldn't be that difficult. Similarly, since the techniques for rendering terrain are in no way API-specific, you could even take a look at a tutorial geared for an OpenGL user, like this one.
Both of those articles illustrate very basic hieghtmap-based terrain using simple grids.

I would agree with this answer even if it was implemented in OpenGL. The concept is what you need to worry about here. I would definitely avoid finding code that you can directly copy over. If you don't understand what the code is saying, that's a good hint you shouldn't copy it! :) Having this in DX9 is going to get you much closer though. Once you understand what the algorithms are doing in DX9, translating it into DX10 will be a good exercise as this will force you to know what's going on!

Ya thats why im trying to understand everything before I move on, but man...DX10 has so much initialization stuff it can get very confusing.

+1 for Chad Vernon's article as it really helped me understand and implement my own heightmap based terrain a while back. A word of warning though, the formatting of the code on the site is sometimes dodgy (for me it was anyway) as some --x are seen as -x which gives you a very different outcome.


text:
How does an HLSL shader actually end up affecting the render output?
I understand the syntax of HLSL, for example let's pretend I have this as my HLSL:
struct VOut
{
    float4 position : SV_POSITION;
    float4 color : COLOR;
};

VOut VShader(float4 position : POSITION, float4 color : COLOR)
{
    VOut output;

    output.position = position;
    output.position.xy *= 0.7f;    // "shrink" the vertex on the x and y axes
    output.color = color;

    return output;
}

float4 PShader(float4 position : SV_POSITION, float4 color : COLOR) : SV_TARGET
{
    return color;
}

and I compile it like this:
D3DX11CompileFromFile(L"shaders.hlsl", 0, 0, "VShader", "vs_5_0", 0, 0, 0, &VS, 0, 0);
D3DX11CompileFromFile(L"shaders.hlsl", 0, 0, "PShader", "ps_5_0", 0, 0, 0, &PS, 0, 0);

How does it like... know to change... I'm confused about exactly what the pipeline between HLSL and the actual pixels/vertices on the screen is.
Is this what actually "applies" them?
dev->CreateVertexShader(VS->GetBufferPointer(), VS->GetBufferSize(), NULL, &pVS);
dev->CreatePixelShader(PS->GetBufferPointer(), PS->GetBufferSize(), NULL, &pPS);

// set the shader objects
devcon->VSSetShader(pVS, 0, 0);
devcon->PSSetShader(pPS, 0, 0);

Keep in mind I'm like a literal beginner at this stuff. Can someone maybe explain what it's doing? I'm assuming the vertex HLSL function goes through every vertex and then changes them to whatever I have in the function, and the output is what was changed... and similarly for the pixel shader?
Another confusion, I know what a pixel is, and I understand what a vertex is... but what exactly does the pixel shader do?

That's ok, no one does

How does it like......know to
  change....Im confused exactly at the
  pipeline between HLSL and the actual
  Pixels/Vertex on the screen.

It works roughly like this: when you issue a draw call (DrawPrimitives, DrawIndexedPrimitives in D3D, Draw in 10+, et cetera), the geometry data you've bound to the pipeline (your vertex buffers) are processed. For every vertex, the vertex shader is executed to produce an output vertex in clip space.
The GPU then performs some fixed functions on that clip space vertex such as clipping/culling and bringing the vertex into screen space, where it begins to rasterize the triangles. During rasterization of each triangle, the GPU interpolates vertex attributes across the surface of that triangle, feeding each interpolated attribute to the pixel shader to produce a semi-final color for that pixel (blending is applied after the pixel shader executes, thus "semi-final").

is this what actually "applies" them:

The code you posted first compiles the shaders, then binds them to the pipeline where they remain active for any subsequent draw calls until changed. It doesn't actually cause them to be executed.

Can someone maybe explain WHAT it's
  doing, im assuming the Vertex HLSL
  function goes through every vertex (as
  the input Position:POSITION and color:
  COLOR) and then changes them to
  whatever I have in the function, and
  the output is what was
  changed....(same goes for Pixel
  Shader).
Another confusion, I know what a pixel
  is, and I understand what a vertex
  is.....but what exactly does the Pixel
  shader do......

The vertex shader is responsible for transforming vertices from model space to clip space.
The pixel shader is responsible for computing the penultimate color/depth for a pixel based on interpolated vertex attributes.

I'll try to explain how things work without using much jargon.
If simplicity rather than interactive speed is your concern, a 3D surface in the computer would be just a huge cloud of points in space, dense enough so we can just render each point individually, without gaps between them.
You want to store a model only once in memory, but you need to display it at various sizes and from various angles, so when you render a 3D model, you need to "transform" all the points as you read them from memory. For example, to render the model 50% as big, you need to scale the positions of the points by half:
out.position = in.position * 0.5;
out.color = in.color;

This is almost the simplest "vertex shader" one can conceive: in goes a vertex position from memory, and out comes a new vertex position, half-as-big. The half-as-big vertex is not stored back to memory - it's used immediately for rendering and then thrown away.
Though a gross oversimplification that lacks key concepts, this in spirit describes aspects of how movies do graphics.
Interactive graphics (games) can't afford to be this simple, because they need to render graphics several orders of magnitude more quickly than a movie.
In games, we can't afford to render one point for each pixel on screen, plus extras to cover the gaps. So as a compromise, the gap between each three nearby points is rendered as a triangle, which for various technical reasons prefers to be at least 10 pixels big on the screen.
A 3D triangle can be projected onto a 2D screen, then divided into a stack of 1D lines, which can each be divided into a stack of 0D pixels. We can thus divide-and-conquer the problem of rendering a 3D triangle into the simpler problem of rendering a lot of 0D pixels in isolation. A computer can solve simpler problems in less time.
A pixel shader is a little program that we run on each pixel so generated from disassembling a triangle.
out.color = in.color;

This is almost the simplest "pixel shader" one can conceive: in goes a blend of the colors of three triangle vertices, and out goes the same color. The inputs come from the outputs of the "vertex shader" and the outputs are written to the screen in memory.
So - the "vertex shader" is a program that runs inside the GPU chip. Its input is a "vertex buffer" in GPU memory, and its output is fed directly into a "pixel shader." A "pixel shader" is also a program that runs inside the GPU chip. Its inputs are a blend of three vertices from the vertex shader, and its output is a pixel on the screen.

Besides the other answers, here's a little picture of what goes on

From pipeline stages, d3d10 (same as d3d11).
See also

D3D10 unleashed
AMD d3d10 intro

Don't worry about a pixel shader right now.  If you're complete beginner, you should being hello world of GLSL / HLSL with vertex and fragment shaders only.  Once you're familiar and you start to understand variable movement and such, then expand your horizons.
I highly recommend a text book to get the nitty gritty as to how the API works.  OpenGL books also do a good job illustrating how things have changed over the years from the fixed pipeline to the dynamic programmable pipeline.
Go champion!

A fragment shader fulfills the same function as a pixel shader.

I don't think we can tell from the question whether the OP is a beginner at all game programming -- he only stated that he's a beginner at writing shader code. Learning to write shaders is a very important tool to have in a game developer's shed, I wouldn't merely gloss over them unless you're only at the very beginning stages of learning game development.


text:
How Often do you change Vertex/Index/etc Buffers?
So im still learning but I think i've got a grasp of most things DX11 (Well....beginner things) And I REALLY do apologize for all the questions.....but I'd rather understand EVERYTHING before I move on.
I have 2 main functions (well 3 technically) that set up everything. I have Initgraphics(), InitD3D(), and Initpipeline()
D3D sets up the swap chain, viewport, depth buffer and back buffer.
Initgraphics() Creates the Verticies (for the cube/whatever im drawing) and then creates the vertex buffer and copies it in.
// create the vertex buffer
D3D11_BUFFER_DESC bd;
ZeroMemory(&bd, sizeof(bd));

bd.Usage = D3D11_USAGE_DYNAMIC;
bd.ByteWidth = sizeof(VERTEX) * 24;
bd.BindFlags = D3D11_BIND_VERTEX_BUFFER;
bd.CPUAccessFlags = D3D11_CPU_ACCESS_WRITE;

dev->CreateBuffer(&bd, NULL, &pVBuffer);

// copy the vertices into the buffer
D3D11_MAPPED_SUBRESOURCE ms;
devcon->Map(pVBuffer, NULL, D3D11_MAP_WRITE_DISCARD, NULL, &ms);    // map the buffer
memcpy(ms.pData, OurVertices, sizeof(OurVertices));                 // copy the data
devcon->Unmap(pVBuffer, NULL);

it also does the same thing for the Index buffer.
I also have initpipeline() (see code below)
// compile the shaders
ID3D10Blob *VS, *PS;
D3DX11CompileFromFile(L"shaders.hlsl", 0, 0, "VShader", "vs_5_0", 0, 0, 0, &VS, 0, 0);
D3DX11CompileFromFile(L"shaders.hlsl", 0, 0, "PShader", "ps_5_0", 0, 0, 0, &PS, 0, 0);

// create the shader objects
dev->CreateVertexShader(VS->GetBufferPointer(), VS->GetBufferSize(), NULL, &pVS);
dev->CreatePixelShader(PS->GetBufferPointer(), PS->GetBufferSize(), NULL, &pPS);

// set the shader objects
devcon->VSSetShader(pVS, 0, 0);
devcon->PSSetShader(pPS, 0, 0);

// create the input element object
  D3D11_INPUT_ELEMENT_DESC ied[] =
{
    {"POSITION", 0, DXGI_FORMAT_R32G32B32_FLOAT, 0, 0, D3D11_INPUT_PER_VERTEX_DATA, 0},
    {"NORMAL", 0, DXGI_FORMAT_R32G32B32_FLOAT, 0, 12, D3D11_INPUT_PER_VERTEX_DATA, 0},
    {"TEXCOORD", 0, DXGI_FORMAT_R32G32_FLOAT, 0, 24, D3D11_INPUT_PER_VERTEX_DATA, 0},
};

// use the input element descriptions to create the input layout
dev->CreateInputLayout(ied, 3, VS->GetBufferPointer(), VS->GetBufferSize(), &pLayout);
devcon->IASetInputLayout(pLayout);

// create the constant buffer
D3D11_BUFFER_DESC bd;
ZeroMemory(&bd, sizeof(bd));

bd.Usage = D3D11_USAGE_DEFAULT;
bd.ByteWidth = 176;
bd.BindFlags = D3D11_BIND_CONSTANT_BUFFER;

dev->CreateBuffer(&bd, NULL, &pCBuffer);

devcon->VSSetConstantBuffers(0, 1, &pCBuffer);

Which from my understanding, compiles the shaders, makes the shader objects, creates the elements object and descriptions (Can someone explain what exactly this is?) and the Constant Buffer (which I only somewhat understand).
I guess my question(s) is.....when do these things need to change. I have a grip on the vertex and index buffers.....like I understand WHAT they are, but when would you change them? Same goes for Depth buffer, when would I ever want to change that (I understand back buffer). I know in my RenderFrame() function I select which ones to use using: right?
   devcon->IASetVertexBuffers(0, 1, &pVBuffer, &stride, &offset);
   devcon->IASetIndexBuffer(pIBuffer, DXGI_FORMAT_R32_UINT, 0);

Secondly, Do I only need to compile the shaders once and make the objects once? (unless I use different shader files presumably...maybe one for lights for one object and one for textures for a different object)....and what the heck does this:
// create the input element object
  D3D11_INPUT_ELEMENT_DESC ied[] =
{
    {"POSITION", 0, DXGI_FORMAT_R32G32B32_FLOAT, 0, 0, D3D11_INPUT_PER_VERTEX_DATA, 0},
    {"NORMAL", 0, DXGI_FORMAT_R32G32B32_FLOAT, 0, 12, D3D11_INPUT_PER_VERTEX_DATA, 0},
    {"TEXCOORD", 0, DXGI_FORMAT_R32G32_FLOAT, 0, 24, D3D11_INPUT_PER_VERTEX_DATA, 0},
};

// use the input element descriptions to create the input layout
dev->CreateInputLayout(ied, 3, VS->GetBufferPointer(), VS->GetBufferSize(), &pLayout);
devcon->IASetInputLayout(pLayout);

Stuff mean?. Also what is a Stencil Buffer.....im not really sure I understand why you create it (Does it ever need to change for that matter?)

Instead of L"text string" use the TEXT macro (so TEXT("text string")). TEXT prepends an L if need be (ie if _UNICODE is defined)

I'd recommend reading the Direct3D documentation as it will do a fantastic job at explaining most of your questions. For example, the page on Constant Buffers.
Stencil Buffers are described very elequantly on Wikipedia. You only need to create one if you plan on doing operations that involve creating and using masks to control the pixels to apply an operation to (much like a stencil in painting).
As with most API calls, the less you can call them the better. Most static resources (i.e. those that don't change during the course of the application running) are created once (for vertex buffers this can also involve populating with the vertices) and then set whenever they're needed. There are dynamic resources (again such as vertex buffers) that you might want to create the resource, but then you may change the contents of on a regular basis (such as for rendering UI or dynamic particles among other things).
You might want to change to a different depth buffer if you want to render to a different render target such as a dynamic cubemap, reflection, etc.
That last part where you create the InputLayout, you're basically telling D3D where to find the vertex data inside the vertex buffer. You can put whatever you want in the buffer, all D3D asks is you tell it how many bytes it needs to skip to the next vertex and what offset important bits are from the start of the vertex (such as position, normal and texture coordinates).

I am a newbie to directx, but as I have been learning it I find it helpful that I do already know a little bit about video cards and that might be relevant.
Directx makes you feel like you are creating typical programming resources, but I expect under the hood the important copies of those resources reside on the video card, i.e. your vertex buffer is probably created in memory, then copied to the video cards memory when you set it as the current vertex buffer. Your effect is probably loaded onto the video card.
Moving stuff to and from the video card causes a certain performance hit. That's probably why directx is set up as a state machine, because by and large it represents states of your video card.


text:
Does changing a Rasterizer State affect every object (model) on the screen?
Quick easy question. When setting a Rasterizer State (like for example wireframe).....does that affect every object (model) on the screen?
For example, let's pretend I have 2 cubes. I use:
devcon->RSSetState(pRSWireframe);

Will that affect all the objects on the screen?

It will only affect objects rendered after the state is changed.


text:
How does a single non-artistic programmer make a game?
I'd like to try my hand at making games. In making some simple ones, I realised I can't do art!
I've tried to find others to help: Most existing teams wouldn't want me because of my limited experience (I'm in high school) and I've been unable to find an available local artist with an appropriate skillset.
How do you guys do it? Do I have to wait until college to see if I like working in games? Is there a way to get free art so I can start messing around on my own? Or am I just having bad luck or looking in the wrong places for others interested?

I work full-time doing security software, and in my "free" time I work on my game. I'm not spending any money on making my game, I'm only using free software and making my own art. Don't get me wrong, I'm NOT an artist, just a programmer. It's not stopping me though. I just keep chugging away on my game, and I'll worry about making it look really pretty later. Or just make it good enough that the art doesn't matter. For now it's ordained with what I call "Programmer Art". Depending on the type of game you want to make, the art can be really important. But for a lot of games, it's all about the gameplay. Look at Dwarf Fortress. Not really a lot of "art" involved, but the gameplay is great!
If anything, you can get your game built with Microsoft Paint textures and sprites, then you'd have something to show off to get an artist interested.
You should definitely try your hand at making a game. I love making my game. It's the most fun I've ever had programming. Every aspect is a new interesting thing to learn.
Not everyone can do it all, so we just have to make do with the skills we have. Our skill is programming, so that's what we do. I think it's been proven more often than not, that it's the gameplay (programming) that makes or breaks games, not the art.

+1 If you don't have artistic skills, then getting the gameplay on its way is really important! Leave the real art to the real artists, and focus on having something to show them so they can go "Wow! This project is actually going somewhere! How great would it be to put my art in there?"

Very encouraging answer. Yet the textures that you are using are already very nice and way beyond the capabilities of somebody as artistically challenged as me. ;-)

Well, it's just a trick of the eye really, but thank you. Once all the textures are out on a some geometry the brain makes it work. You haven't seen the UI, it's ugly as sin. But indeed as Jonathan suggests, texture sites would work great.

@Jonathan Of course; that’s what I would do. But @Byte56 specifically mentioned that he’s doing all the textures himself, and then talked about MS Paint so I was expecting really crappy graphics and was very positively surprised when looking on his website.

I saw your blog a while ago! Nice progress! Anyway, here's what I'm working on: http://yannbane.blogspot.com/.

I am a designer, and even so my hobby game uses the most basic graphics for now, specifically so I get the gameplay done first.

The hallmark of a good game is if it is fun even if it looks like crap

It's gameplay + art. That's the formula.

@Byte56 You mean (0.6 * gameplay) + (0.4 * art), right?

If you make a game full of programmer art that looks a bit rubbish, but the gameplay is fun enough then you can always claim it's "retro" or something. Not all games need 4xAA rendered high poly 3D graphics with bloom shaders.

Small disclaimer - the game play is game design, not "programming". Designing a great gameplay does not necessairly have anything to do with implementing it (coding). A lot of the design can be done with some dice, paper, glue, pens and scissors.

This is fantastic advice. I work as a full-time game developer, but I want to start making games from scratch in my own accord.
Lots of things jumped up. Platform. Assets. Sounds. Scene structure. Prefab structure. 2D or 3D. Literally everything.
I am no artsy person, but, my advice would be to not go in with an idea - you will fall short. Rather, follow tutorials, play around, see what you can do, then build from that!

An option is to take photos of things and use those. It's fairly simple to create a texture or cubemap from a photo for example.

I want to add a slightly different point of view from what has been previously answered.
First, I disagree that gameplay is the only important thing in a game. Visuals sell, and you will most likely have your game played by other people if you show a pretty screenshot that catches their eye. Because of this, I do not recommend you disregard art, or use stock or placeholder art for your game. This also goes for sound and story (if your game has one).
Second, I wouldn't recommend you work on a project alone. Having more people in your project is a great way to stay motivated, and also by sharing ideas with other members you are more likely to get a better game.
So what you have to do is gather people who are interested in making a game, and making a project with them. It sounds hard, but it is actually very easy, if you approach the problem from the right angle. I've done several indie games with other people, and I've had really good experiences doing so.
Let me tell you that you are in a very privileged position, being a programmer. There are lots of people in the world who love games and would want to make one for themselves, but only very few know how to code. Even though it is technically possible to one-man-army a game project being a programmer, it is simply impossible being an artist. You would be surprised to know that for every "how do I make a game if I'm a programmer and not an artist?" question, there are a dozen "how do I make a game if I'm an artist and not a programmer?" questions.
So, people are there. There's a lot of artists and musicians and game designers who want to make games, and would do them for free. Unfortunately, pretty much everyone who is able to competently participate in the development of a game will most likely not be interested in joining your game, so that's the problem you want to attack if you want to successfully make indie games.
In few words, it's (good) programmers that are scarce, not artists.
In my opinion, there are two ways to solve this problem. I've done both, and I can assure you both work.

If you're interested in making games, but don't have the specific requirement that they have to be your games, you can offer people to make their games! If you can prove you're a competent programmer, there are lots of artist forums you can lurk, and if there's an interesting idea, you can contact the artist by telling them you're interested in making their game. If you say it right, it is almost guaranteed they will say "yes".

If you can prove you can make and complete games (for every finished indie game, there are thousands of projects that will never end), and if you have a good idea, you can hit the forums and propose that idea. Maybe the first time only one person will join you, but if you can deliver a finished product, and make sure you publicize your progress and success in said forum, you will gain credibility and more people will be interested in joining you for your next project.
For my latest game, I was able to convince two graphic artists, one musician, one writer and nine voice actresses (two of them who are actually professional) to help me for free. Of course it is crucial to actually deliver. I did, and because of that I'm confident that I will be able to get their help, and other people's help for the next project.

Keep in mind both of these options are viable only if you're serious about making games. If you stop halfway, or if they sense you're not being serious, you will lose reputation, and people won't join you in subsequent projects, so proceed only if you're actually capable, and willing to walk the walk.

This is a good answer in general, but does kind of make some assumptions about the OP's ultimate goal. Given that the question asked "Do I really just have to wait until I can go to college to see if I like working with games" I would recommend first make a few small games on your own with programmer art before you waste anyone else's time, in order to see if you'll stick with it. And then when you start contacting people, make it clear you are still early in your learning process and this is a learning project.

@jhocking: op said he had always been a software developer. I've known several good people still in their teens, so age is kinda irrelevant.

Who said anything about age? My point was, he should first figure out own if developing games is right for him, before he wastes the time of any future teammates. And anyway I wasn't contradicting anything about your answer, but rather adding on/clarifying that he may need to do some work on his own with programmer art before your other advice will apply.

I'd love to see the game if you wouldn't mind

@stumped: There's a link to the Steam page in my profile page

I would have thought this was the other way around.  I guess because I'm always on game dev. and programming sites.

Here's a thread that contains a ton of links that you'll find useful; everything from legal, to art to music, etc.
http://www.mangatutorials.com/forum/showthread.php?742-The-Ultimate-Indie-Game-Developer-Resource-List
It's mentioned in other answers, but while you're looking for an artist etc, you should be developing your game at the same time. Use programmer art, stand-ins, free sprites anything. Most of the time, before even thinking about final assets, I just want something up and running quickly to see if it's fun. Prototype the crap out of it and find the game. Then, when the gameplay's locked down, you can start putting in the proper art. Doing it the other way around leads to lost money, and work that needs to be redone multiple times, which aside from harming your project, sucks your motivation to finish it (and if you're making a game to get a job, showing that you can finish a project is a good thing).
If you still can't find an artist, then make the graphics yourself. Dwarf Fortress was mentioned, but there's also games like Geometry Wars, where the graphics are created through math. Anything is possible to get around if you put your mind to it.

We're in a similar situation when it comes to art, me and a friend build games in our spare time. We're both developers who love games, we must've started a dozen game projects.
The projects that have stuck, we've approached a number of people on artist community sites whose art styles have matched our ideas.
Having a project up and running, ready to show you're serious and to demonstrate your passion for the project has been enough for us to generate some interest.
Give it a go :)

I don't think the fact you are not an artist is that much of a downer, programmer are essential to make a game, and if you don't have content, it's not really a problem:
 - Do the game without content, and try to find artists after the game has more features: you will have more leverage, and you will have much less pressure to add those features.
 - Use an user-friendly 3D modeling tool, like sketchup.

You could always go for the "less is more" approach and use as little and as simple artwork  as possible.
Retro-style vector graphics are pretty popular these days, so there's plenty of inspiration to get there. Just draw some lines and make 'em glow a bit.

First, you're doing really good by doing all this stuff before you get to college.
Now, have you tried exploring art yourself?

I'm a programmer, not an artist

Is a common cop-out people use to avoid judgement on their artwork.
But if you just put the time into it, you can learn to draw, too. (and a couple of bucks for a Wacom tablet!)

But how does a single programmer make a game?
You just keep working on it until it's done.
It is true that the barrier to entry to create a game that captures attention and has a market has been raised quite a great deal just by the quality and amount of money and time invested into games that are actually selling.
So, because companies like Blizzard or Edge Of Reality are investing so much time+money just to get the next card game/First person shooter out, the game marketplace today is a very competitive place.  Compare this with the time when Mario Bros. was bleeding edge technology, and John Romero was able to sell games like Crazy Climber that looked like this:

Totally true. Nobody is born a programmer or an artist. You become one by programming or making art respectively. Sure, it won't rival the pros, but even the pros didn't rival the pros from day one.

I wanted to do graphics intensive games (RPGs) so I dropped programming for a while to do drawing, painting and 3d modelling. It's seriously NOT easy, after 4+ years self-practice, my programming has languished and my art link is still not there yet. On the upside, I discovered I love art as much as programming. :) I encourage everyone to just try it for the sake of discovering something new about yourself. You just might find a new passion.

@bobobobo thank you :D I would like to add that if art seems too intimidating, one can also try 3D modelling first. It's methodical nature might appeal more to programmers. :P

@Cardin Hey Cardin, how good were you when you started?  Were you already trained or had previous experience?  Oh, Do you se a graphics tablet or paper?  How do you get the images on the computer? Nice work.  Thanks for sharing.

How good... hmm I couldn't draw humans when I started. No prior training. I did get somewhat decent grades in high sch for drawing still objects (chair, table etc.) in the obligatory art&craft classes. In college I got myself a tablet and starting drawing as a hobby. Tablet's one way to get graphics in, or you can get a scanner, a 4B pencil lead and a inking pen (Sakura pigment pen is gd). But really, I realized no matter what tools I get, it doesn't improve your skills overnight. (I'm still not at a level to start drawing my own assets yet though)

It depends on what kind of game developer career you are seeking. Most titles created in the modern game industry are made by huge teams where a programmer doesn't ever have to draw a single pixel.
Though if you're more into developing your own indie game, you could assume the "one man army" role, in which you'll have to deal with graphics and sound creation.
Programming was the easy part, while generating synthesized sound effects and drawing pixel art consumed most of my time. Thanks God for public domain music which in this case perfectly suited the whole groove of the thing.
If you grew up in the 80's when you could actually see pixels on the screen (and then never being able to ever ignore them later) it could just grow naturally on you, but if that's not the case, I'd recommend reading a bit on pixel art creation. Of course you can always digitalize some paper drawing and just do the finishing later.
Anyway, creating games has always been a multidisciplinary craft. You'll need a good depth of programming skills (but not 'too much', or you'll end being unable to create the simplest game, because you'll be over-worried about abstractions, just like a good grammatician can't write a single book), good understanding of math, geometry, physics and also a good deal of artistic skills, like drawing, sound creation, level design, story telling, etc.
Ultimately, you must fall in love with your creation. You need a good deal of motivation and a genuine desire to make your game see the light. You must become the #1 fan of your own game, because if you don't like playing it at all, who else will?
With all that in mind, I really hope you overcome your obstacles and have a great time creating your own game. It's an incredibly fun and rewarding experience once it's up and running. :)

You can always replace your sounds and art later on. In my opinion the important thing is the game itself.
It can be an excellent 3D shooting game even if the walls are all brown and the characters are cubic block people.
It can be a wonderful sandbox world and look like Minecraft.
The sound effects are easy to make. Just record yourself making the sounds with your mouth. I've played some really fun tower defense games where it's quite obvious the shooting sound is a guy going, "Pew! Pew!" into a microphone. :-)
The really important thing is to finish the game. It doesn't have to be perfect. It doesn't have to have every feature you planned out. But once you finish a limited version of the game, no matter how many features it's missing and no matter how crap the art and sound is, then you have a basis for making changes and improvements, and you have something to show clients or potential employers as a code demonstration.

I wouldn't worry about art so much at your current state. The first game I ever managed to get to a satisfactory level of completion, I did completely without an artist and it was before I started college.
In my view, you have four good options depending on your level of game programming:

You can find a good game programming book that has a project which includes all of the art and you can get a feel of if you like the work involved in game programming
You can find a game engine that lets you write mods on using their artwork
Use Unity3d or Torque Game Engine, look those up, both have asset stores with some free art
You can take my route which I think is the best :) You can start programming a game and write the main functionality of the engine. Use extremely ugly art for it, like blocks or stick figure sprites. Then once you have a working engine, post it up on GameDev.net's help wanted forums. I got my first two artists this way. They liked the gameplay of my flight sim even though the plane was made up of 4 blocks and the terrain was painted in a terrain editor.

I'm a solo, hobbyist game developer, and although it tools many weeks, I did manage to publicly release a handful of 2D mobile games. Like you, I am a programmer and not an artist.
First off, I agree with the comments by others that Unity3D is a great way to go. The only thing I have against this is you're stuck with the splash-screen unless you go for the Pro version, and the Android/iPhone plug-ins aren't (normally) free (I'm unclear from your question whether you want to target mobile or desktop?).
If it's important to you to actually complete a project, as a solo non-artist, and you decide against Unity3D (or some other similar game engine), I suspect you'll find it more manageable if you go - at least initially - for 2D. The volume of assets and the complexity/size/effort of the programming will be much less.
Finally a quick tip - I found it much easier to model objects in 3D and then render them - with appropriate shading - into 2D sprites, rather than try and hand-draw 2D artwork. Blender is a fantastic, free 3D modelling tool. I can't recommend it enough.
Even when I kept things really simple (and 2D), I found it took far longer to complete my first game than I imagined. This was down to the sheer number of aspects that had to be tackled - game design, playability (e.g. input controls), programming, artwork, marketing material, animation, sales pitches, level design, level editors, you name it.
Good luck - you can do it. I think game development is one of the most multi-disciplined projects. I love it!

I think it's a great to see actual pretty things happen on the screen in the development process. Small projects often follow graphical artistic / lore concepts from the beginning as a guideline and a it's very strong motivator.
I might be wrong about this but from the perception i get, most indie projects that actually ever see the light of day are either made by single devs who do the whole thing both art and programming (i hate them) or small teams who have someone on the art, but rarely a programmer who hired someone in the end of development to replace the placeholders - even though this method should work in theory.
Try to find a friend, co worker, a girlfriend, wife, whatever, someone who can DRAW. They don't have to know how to work with any software or use a mouse.  Tell them you want to make a game and need someone to do the drawing while you do the programming. If not someone you know from your life find some artist online or in forums. Work on an idea together.
I actually had the same dilemma as you until i saw some drawings a friend made on his Facebook page, anyway, I posted this question that may seem relevant.
An alternative could be doing a game with some abstract graphics concept thingy that anyone could draw. Like stickman games, but can easily be more than that. Or some abstract 3D in a level that could be created after 2 days of learning from Lynda. It worked for MineCraft :)

I've had some experience writing my own games, both open source and commercial indie-style. Like you, I encountered problems with assets (images, animations, audio, ...). You have a few options:

Do it yourself
Find someone to volunteer their time
for you
Find something that you can legally
use for free/for a fee
Pay someone [probably good money] to
give you a decent product

Without much money, all these options can be frustrating. You can find artists to volunteer their time, but in my experience they don't like to sit around and wait for you to develop and fix a new game/rendering engine, so here is my advice (I'm assuming you aren't willing to spend any money):
Create some very simple graphics to test with. In one game I created, I made some very simple stick figure graphics that were merely sufficient to indicate what action / state my character was currently in. Later, when the game/rendering engine is compelling, it will hopefully be inspiring and you will have less trouble finding artists willing to help out.

It wasn't specified if you want to do a game professionally or as a hobby. For a professional game, you need professional graphics. Minecraft is a great counter example, but an exception to the rule. As a programmer making games for a living, I get the graphics from a paid artist and from online websites that sells 3d models, images and sound.
For a hobby, there are free online resources as well as doing your own art. However, if you are anything like me, my art sucks, takes too long to do and I don't like the end result of the game. That means I lose my mojo doing stuff I don't like vs stuff I do like and I am not motivated by my results... which means: I get it from good sources.
Get at least decent looking placeholder for your graphics. Then figure out how to get a better version, if you reach the point when you are ready to release, etc..
Don't force yourself to do stuff that will demotivate you - whatever it is. Motivation is the only thing that will make you finish your game and finishing the game will be the most important thing for you to accomplish. Do not squander motivation on graphics if it is not your thing, but realize that a nice looking UI will motivate you.

A lot depends on the type of game and corresponding expectations of the players.  I minimize the requirement for graphics in my games by basing the artwork on actual photos of game bits.

All that is required is motivation and time.
Unless you're limited on time so severely that your life will end before completing the project, you will be able to do anything alone, over time.
Motivation is something that each individual has to figure out themselves. Personalities differ, and so does what works. For me, what works best is to force myself to work a set of hours each day, and if I miss to make up for it on the weekend.
Setting tiny, tiny goals works. Then when you have the game built enough, you get better motivation to finish it because you are so close. The hardest part is beginning.

authors: คือว่า จั่งสั้นล่ะ


text:
In a 2d tile based game, what is a good method for scrolling?
I am using Direct3D with the D3DXSPRITE wrapper to draw the tiles to the screen. I have a tile class which contains members such as collision and tile type, then i have an array of tiles e.g.
Tile grid[256][256];
Which would be a better method?
-Draw the player in the center of the screen and offset where the map draws.
-Move the player with the camera following.
I was using the first method, but its getting really complicated when you get to the top left edge of the map, and when other players/enemies are on the map and moving at the same time
if i make the camera follow the player, would i have to call spriteBatch->Draw(...) for every single grid tile even though only a few can fit on the screen?

It's probably best to do all updates and calculations in "real", world units and move the camera.
Your spriteBatch may perform culling itself but if it's too slow you can try to determine what tiles need to be displayed on screen and only draw those.

You probably are going to want to write code to only draw those sprites which are visible, especially if you find that you need to increase the size of your grid.

Moving the camera in world coordinates and have your character move around the world is the easiest way to approach this problem, working in world coordinates means you dont need to do any extra calculations when it boils down to all the other systems which must work on a relative coordinates system and also understand where they are in world coordinates.
Since you are working in 2D another good tip is to do some spatial partitioning the easiest way would be to create a virtual world grid system, this will allow you to manage each tile individually by associating sprites and other resources on a per tile basis, so in essence the process would be:

create some tile class which can hold the boundary coordinates for the tile and whatever resources that specific tile may need ( sprites, enemies, etc.. ).
decide on the size of your world and create a 2D array ( you could use one dimension and access it as 2D ) of tiles each one representing a bit of your world with all of its associated resources.
only draw resources from the tile the player is in and its neighbours.

With a grid you can easily find out which tile the player is in based on it's position relative to the start of the grid.
To work around the problem you mentioned about the camera you need to make the player and the camera two independent systems where the camera wont travel any further than the centre of the edge tiles so when the player travels to that tile he can still travel throughout the entire tile as he is bound by world coordinates ( i.e. no longer centered on the screen ) but the camera is locked.

I use a surface. I create the entire world on an off screen surface and keep an x and y  coordinate. I alter these as the player moves and each frame draw a 1028 x 768 rectangle from the surface to the backbuffer using x and y.
as for other people I give them an x and y and let them move around the world as they please, when drawing I check if there x and y is in the 1028 x 768 rectangle and if so draw them (I use textures for people).
I have the player in the centre of the screen and check if the edge of the world has reached the edge of the screen. In this circumstance the player moves about the screen to the edge of the world and back to the centre then the world starts moving again. it seems hard and took me a while but is not to bad to do.
I use 64 x 64 tiles and the biggest world I have used so far is 50 x 60 tiles.
This is all done in direct x with c++

This seems like a HUGE memory hog. Keeping the entire world drawn in a surface off-screen is going to run you into memory issues once you start wanting to do things like having multiple (animated) layers for your world and expanding it further than what you have now. It would be much better to keep the information about the world and only draw the parts/objects that need to be drawn when they need to be drawn. Just my 2 cents. :)

@Drackir I think you misunderstand. only the world is drawn off screen, things like the other people are tracked and drawn on the backer buffer when they are needed. also I do not see myself doing more that 70 x 70 world. when I say world I mean area, this could be a town a dungeon or the inside of a house, when the player moves between them the off screen surface is reconstructed. yes it takes memory but 2d tiles on modern terrabite drives makes it negligible and a few seconds loading is a small price to pay for smooth scrolling and animation. but yes there are better and harder ways :)

The surface should be stored in the GFX card memory, not on the hard drive. However, I believe if the GFX card memory is too large, it will move the surfaces onto the HD which would considerably slow things down. Admittedly, it's been a while since I've dealt with that stuff so I don't remember exactly how it worked, but I guess as long as you're not drawing too big of a world it would be ok. :)

@Drackir That is interesting to know, I never thought of it like that. I found that this way gives me a smoother scroll that if I dynamically drew new tiles so I think it fits ok but I will have to look into that.

I was working on a game where I had maps 31x31 but they were attached together side-by-side. I was trying working from someone else's engine and they would draw all the maps surrounding the one the player was on; so nine maps in total. Each map had several (I think 6) layers. So like 31x31x9x6 = 51894 tiles being drawn (max of course; not all tiles were full) every time the user switches maps. That was a huge slow-down for me, so I rewrote the drawing routine to only draw the tiles surrounding the player as far as 1 tile past the edge of the screen (to handle partial tiles while moving).

You could kind-of mix your idea into that and re-use part of the surface when you move to a new tile/position so rather than redraw all the tiles on the screen, copy the part of the back-buffer that won't change and only redraw the new line of tiles you need (because you moved one tile away). Anyways, as long as it's fast enough for you that's all that matters. I'm just thinking out loud now. :P

It's quite normal for the code to get a bit of a pain in the corners of a tiled world, when working out which tiels to draw, and simultaneously ensuring the camera doesn't go 'off-world'.
Those edge cases are basically the most compelx thing about implementing a 2D tile-based world thats larger than the screen res. It gets much more complex if you support zooming in, and zoom-to-cursor :D


text:
Where can I download the Doom Classic source code, the iOS port?
Doom classic source code for iOS was released by id software, but there is no working link on their web site where I could get it from.
Do you know an alternative source to download the Doom Game for iOS?

You may have seen this analysis, but it bears linking: http://fabiensanglard.net/doomIphone/index.php

I saw it, and is quite good :D

You can get it from "http://www.doomworld.com"

http://www.doomworld.com/idgames/index.php?id=15906

But getting it from idsoftware directly would be better. I hope they will read your mail and fix the problem.


text:
in Unity3d, how to automatically create fixed joints in a wall of cubes?
I want to create a wall:
width  6 cubes
height 7 cubes

therefore I have 22 cubes on the margins and 20 cubes inside. For each of the margins cubes(except the corners) I have to set 3 fixed joints, and for the cubes inside the wall I have to set 4 fixed joints - all this to have good physics behavior.

Pretty much I have to create a fixed joint between a cube and all his neighbors => and that's a lot!
Is there a way to automatically create these fixed joints?

Is there another way to create a physics friendly wall? I want to simulate a wall of bricks hited by a projectile.

I usually don't write code for these questions, but I'm bored. I don't have unity on this computer so I'm just guessing, it should give you an idea even if it doesn't compile. I just added each blocks right and top joint as long as it's not on the top row or far right column. In a real situation you would add the parent transforms x and y position and do all positioning in local space so it can accept the parents transform, but you get the idea I hope.
int x = 6;
int y = 7;
float hSpacing = 0.5f;
float vSpacing = 0.5f;
GameObject[,] wall = new GameObject[x,y];

for(int i = 0;i<width;i++)
{
    for(int j = 0;j<height;j++)
    {
         //Add the Cube
         wall[i,j] = (GameObject)Instantiate(cube,
                     new Vector3(i*(cube.lossyScale.x+hSpacing),
                     j*(cube.lossyScale.y+vSpacing),0);

         //Add right joint
         if(i+1<width)
         {
              FixedJoint fjR = wall[i,j].AddComponent("FixedJoint") as FixedJoint;
              fjR.connectedBody = wall[i+1,j].rigidbody;
         }

         //Add top joint
         if(j+1<height)
         {
              FixedJoint fjT = wall[i,j].AddComponent("FixedJoint") as FixedJoint;
              fjT.connectedBody = wall[i,j+1].rigidbody;
         }
    }
}

Thanks, I used a similar approach, as it is described here: http://answers.unity3d.com/questions/58449/how-to-automatically-create-fixed-joints-in-a-wall-of-cubes


text:
Simple Terrain Grid (not working)
I know yall are probably going to hate me.....but I can't figure out what im doing wrong, im trying to make a SIMPLE Vertex Grid (for Terrain) but I get a black screen for some reason And I can't figure out why. It does run, but I just get a black screen afterwards....I hate posting such huge code on this site but I figure if anyone can explain what the heck I did wrong i'd be able to understand a little bit better.
I think the problem....may be in the matrix, but my code is simple and im 100% sure im doing the Grid right because I took it from a working tutorial that does grids (but it's large and VERY confusing for a beginner, so I just took the appropriate code).
I know it's alot to look at (vars.h is very small) and main.cpp is pretty small too but I know it's still alot.....but im just completely stuck.
vars.h
http://pastebin.com/SupcqB8N
main.cpp
http://pastebin.com/vAnSUTpp
shaders.hlsl
cbuffer ConstantBuffer
{
    float4x4 matFinal;
}

struct VOut
{
    float4 position : SV_POSITION;
    float4 color : COLOR;
};

VOut VShader(float4 position : POSITION, float4 color : COLOR)
{
    VOut output;

    output.position = mul(matFinal, position);
    output.color = color;

    return output;
}

float4 PShader(float4 position : SV_POSITION, float4 color : COLOR) : SV_TARGET
{
    return color;
}

Have you tried building up from example code you know works? Incrementally adding to it? I think that's your best solution. Start with drawing a triangle and make sure that shows up, then add textures, then make it two triangles drawn from a loop, then make it into your whole grid.
For your current code, I can only suggest the basic 3D troubleshooting stuff.

Make sure your camera is pointing the right direction

Disable lighting, depth buffer, clipping, textures and special effects

Check that your objects are properly formed

Make sure your camera has it's bounds set up correctly
Good luck!

+1 When implementing something grand, taking incremental steps from something tiny is always incredibly helpful. In every single step, you have only a tiny amount of code that might not be working, so identifying any problems that appear in each step is easy.


text:
How to run DirectX10 on non-compatible hardware?
I'm going to be away for a little bit, bringing my netbook with me to do some basic DirectX10 stuff.
How can I run DX10 on DX9.0c hardware?

Windows Advanced Rasterization Platform (WARP)

WARP is a high speed, fully conformant software rasterizer. It is a component of the DirectX graphics technology that was introduced by the DirectX 11 runtime. The DirectX 11 runtime is installed on Windows 7, Windows Server 2008 R2, and Windows Vista with the [KB971644] update.
To use WARP
Direct3D 10, 10.1, and 11 components can use an additional driver type that you can specify when you create the device (for example, when you call the D3D11CreateDevice function). This driver type is D3D10_DRIVER_TYPE_WARP or D3D_DRIVER_TYPE_WARP. When you specify this driver type, the runtime creates a WARP device and does not initialize a hardware device.
Because WARP uses the same software interface to Direct3D as the reference rasterizer does, any Direct3D 10 or 10.1 application that can support running with the reference rasterizer can be tested by using WARP. To use WARP, rename D3d10warp.dll to D3d10ref.dll and place it in the same folder as the sample or application. Next, when you switch to ref, you will see WARP rendering.

I copied all of that from the article, but looks like the most relevant and useful part. You probably should read the entire article though.
I was pretty sure that doing this was impossible when I read your question. A little digging and I was surprised.

what about DX9.0c tho.....

@Sauron: You said you're doing DirectX 10 anyway. Did you actually read the linked documentation? One of the paragraphs reads Enabling Rendering When Direct3D 10 Hardware is Not Available

Ohhh I thought it was talking about DX10->11 with it, nm. my bad.

Direct3D no longer ships with a software rasterizer. You could, however, check out WARP. http://msdn.microsoft.com/en-us/library/gg615082.aspx

WARP is good but you're going to find it quite slow on a netbook.  My experience is that even on a quite beefy i7 it struggles to hit 60 fps with relatively simple scenes, and also is incredibly CPU-intensive - more black marks against it for netbook use.
If you want to use the D3D10 API I'm going to make an alternative suggestion.  Don't.  Use D3D11 instead and use feature levels to gain support for downlevel hardware.  Just specify D3D_FEATURE_LEVEL_9_3 in your D3D11CreateDeviceAndSwapChain call, stick within the documented restrictions, and you'll run.


text:
RTS Game AI Thread
I have a project to make a real-time strategy game from scratch. I am still at the early planning stage, but I have been programming a little to see the mechanics.
I know how to program. I also have a good idea of how I will structure the game classes and the Rule-Based (state-machine) AI for the computer player.
I want to develop Doctrines, which will give a specific behavior to a specific unit (but can be used on many units at the same time), such as Scout, Follow Mission Route, hold Position (attack any approching enemy or retreat if overwhelmed), etc...
The doctrines will only apply to the units, so it will have a unit perspective, and not be aware on the whole map sitatuation.
The Computer AI will analyse the entire visible map and decide on which soctrine to assign each unit depending on another set of rules.
I am doing this in C# with OpenGL.
For now, I don't have much, only a few things in tests before I begin my main conception. I have a game loop where all the game processing (where I will call the update mouvement, combat, rendering, etc, one after the other) will happen, it is called very often if the Application.Idle event.
Now, I was wondering. Since there will be a lot of things to process in the gameloop, should the Computer AI and the Units select their actions in that loop or will it be too slow?
If I want all things to be simultaneous, Should I create a separate Thread for the computer AI? Or even a separate thread for every unit?
I don't have much experience with multi-threading. What would be the best approach for this?

Unrelated - considered Ogre3D instead OpenGL?

Actually, no, I never heard of it. I'm using OpenGL because that's what I was taught in my classes. Can Ogre3D do 2D too? I suppose it can, but we never know...

Yes it can, it even has its own GUI toolkit (cegui).  For example, TorchLight is built with it.  It can save you time because it wraps nicely AROUND OpenGL.  http://www.ogre3d.org/tikiwiki/MOGRE

"Or even a separate thread for every unit" Hell no. The overhead of a thread is much too big. For one there is the reserved memory for the stack of the thread(1MB by default). And thread switches are expensive too.

migrated per http://meta.gamedev.stackexchange.com/questions/434/are-beginner-design-review-questions-acceptable

There are many ways to get many things executing at once. One way is multithreading, but C# has other approaches such as tasks and futures that are more lightweight, and could be used per unit. See this altdevblogaday: http://altdevblogaday.org/2011/04/19/solving-problems-with-asynchrony-asset-loading/

What does "from scratch" mean? Can you use something like XNA instead with DirectX?
You should be rendering something between 30 and 60 frames per second to have fluid motion.
There is really no need to have more fps.
If rendering + logic takes less less than the 16ms that 60fps gives you, then there should be no need for an AI thread.
If you won't have enough time between rendering the frames then you are going to have to think really carefully on what must be updated every frame and what does not.
I'd guesstimate that the "doctrines" part should be as simple and efficient as possible so that it can be updated every frame, at least for visible units and other units nearby.
The units that do not influence the visible units directly can be updated less frequently (and, correspondingly, with a greater delta T).
The main AI has more work to perform, as it has to process all the units on the map and figure out a strategy, so it should require most of the computation time. It is the first candidate for a separate thread.
Note that you might want to add another layer between the two, something like an squad level AI.
Basically, each unit's AI should make sure the unit responds "intelligently" to the immediate situation, so it needs to be fast and responsive. The squad AI is responsible for the "intelligent" actions of several units, spread across several seconds, like finding a bridge if the squad needs to cross a river. And the main AI should direct the actions of lots of squads over a long period of time.
Especially if you don't have a lot of experience, don't do threading if you don't have to.
This will be complicated as it is without an extra burden.
You can learn multithreading as a separate project, or as an extension of this one once it is in a working state.
Good luck!

Have a separate thread for AI. But not for every unit since it would consume too much OS resources and synchronization would be a nightmare.
Make sure the AI thread would find an opportunity to execute. Don't take it lightly, if the main thread does too many things, it may never find that opportunity! If you simply give higher priority to AI thread, then the game becomes unresponsive, which is unacceptable.
So, carefully select sync points and/or events in main loop and allow the AI thread to complete its calculations while the main thread stops. For example, if the user unit sees another AI unit, sync it, so your unit sees an updated unit vice versa.

I am also working on a RTS game from scratch. I haven't tested it yet, but my idea was to run unit AI in the main game loop for all units that are currently visible to the player (in the part of the screen that the player actually see's or near the border of that screen), as it is more likely that the player will move the screen a bit.
The other units are checked in a separate thread, and I have two priorities:
1. Units that are in places which are visible to the user if he moves the screen there.
2. Units that are in hidden areas (not yet explored and "fog of war").
For units in the seconds priority, i run the loop less often, and compensate by moving them retrospectively when needed.

Sounds very complicated.

Your idea sounds fine except for the first part about moving units into and out of the main game loop. All AI should be done in it's own loop, where you can select to skip the loop every x iterations on low priority units.

Whether you need to multithread or not, it might be a good idea to prepare the AI to be multithreaded.
Your main thread would update the world, tick the physics, etc, and then would populate a data structure that represents the AI's view of the world: position of units, state of resources, etc. This data structure would cache the main systems, rather than just hold pointers to them. This is sometimes called a synchronisation point.
Pass this data structure to the AI, and only allow it to reason on the contents of this structure. If you find the AI needing more info, add it to the structure. In AI parlance this is often called a blackboard but could also be referred to as a cache. Never let the AI write to the cache, the output should come through a seperate data structure.
This setup will allow you to parallelise the game because the AI no longer has any direct dependency on the other game systems. Those systems don't need to be threadsafe and you should never get locks. You can safely run the renderer or something while the AI whirrs away.
As a secondary benefit, you can in future extend the cache by decaying the information you get from the other systems over time, simulating uncertainty rather than exact knowledge.


text:
What is your Unity 3D physics engine budget for iOS games?
I'm testing Unity for a game that I'm building, and I've touched its limit.
My test scenario: a wanna-be house with 200 elements (cubes rescaled) no textures, box colliders and rigid bodies for each "cube" and fixed joints to hold them together (400+ fixed joints). The house is on a plane, and above it I put 2 sphere at different altitudes, spheres which will crash in the poor house.
This moves very slow on an iPod Touch 3rd generation. Therefore I'm looking for some documentation to create a reasonable budget for the number of polygons, physics collisions and so on. What is your recommendation?

Do you have any code in the update functions for the cubes? Also the poly count should be fine since it's only about 2400. I know with physics I try to stay under 10k polys as per the documentations recommendations, but I'm too lazy to answer this completely since I'de have to test build on my ipod.

I have no code into my update function, not for the the above test.
10k polys is smth to remember, thanks :D

My suggestion as it's what anyone would have to do to answer this: get the pro trial. Open up the profiler and first do the wall without the joints. Look at the percentage of CPU that physics is using. Then enable the joins and look at the percentage again. Also watch the framerate. You can find your limits there.

I would have posted a comment but I don't have enough Rep. to :(.
Having working with Unity3D on PC we came into problems with the phsics engine when there were too many fixed joints; suprisingly there are very greedy, I'd guess even more-so on iOS as the Physics is CPU dependant.
The guidelines for Unity are generally quite good, you could check out this link for optimizing performance in iOS.
They obviously tell you to use the Profiler, which I also recommend, if you can't go Pro, you'll just have to keep on testing :/.
Oh and as you are using fixed joints to attach the walls, you could maybe use capsule colliders with high friction to simulate the bricks and change this at real time with a box collider once the brick is not longer attatched to any others. (Any two bricks attached should still have a decent simulation even with capsule colliders.)

agreed. u might also want to try to run perfmon.exe on windows providing you don't have dedicated physics processing.

My recommendation is to utilize a profiler or some other form of metrics gathering, that way the physics budget you arrive at will be tuned for your specific game -- the numbers others provide for their games may not apply so well for your game. This is especially true in general, but it tends to hold even if you're using common technology like Unity.
Xcode ships with Sampler and Shark, which can be used to profile applications (although maybe not Unity ones, at least not usefully). You may be able to inject home-grown profiling/timing gathering solutions into your code as well, provided you have any.
Failing that, I'd take a divide-and-conquer approach. You say your initially-described scenario runs poorly, so I'd start with that and halve one of the numbers (either the number of cubes, the number of joints, et cetera), and see how that performs. Try to change only one variable at a time. It's pretty ad hoc, but it might be what you need to do if you can't get the pro trial that comes with the Unity profiler.


text:
Warcraft 3 Editor - Not triggering the Wait action?
Ok so this is mind boggling to me. Every time I've used something similiar before it works.  I added messages to be displayed before everything happened to see where it would, and it never got past the wait.
Events
     Unit - A unit Begins casting an ability
Conditions
     (Ability being cast) Equal to Berserking Power [E]
Actions
     Unit Group - Add(Triggering unit) to heroSpellUG[(Player number of (Owner of (Triggering unit)))]
     -Unit Group - Pick every unit in heroSpellUG[(Player number of (Owner of (Triggering unit)))]
           Unit - Add Berserking Power Damage to (Picked Unit)
           Unit - Set level of Berserking Power Damage for (Picked Unit) to (Level of Berserking Power [E] for (Picked Unit))
           Wait (5.00 + (Real((Level of Berserking Power [E] for (Picked Unit))))) game-time seconds
           Unit - Remove Berserking Power Damage from (Picked Unit)
           Unit Group - Remove (Picked Unit) from heroSpellUG[(Player number of (Owner of (Picked Unit)))]

So I guess my question is, why is the Wait not completing.  I had it display what the time to wait was and it said 6 seconds at level one. Any help would be appreciated.

don't have any idea; you can ask icefrog guess he can help!

Umm, i have a few things to mention here ...
First you're using GUI which is in WC3 really weak and not useful, try to learn Jass and vJass they're more powerful
Second, there are plenty of forums made for Wc3 the best i know is a wc3c. They can help you better than we can do.
Third, it seems that you are trying to do something like a berserk skill, you should try to create a dummy unit add it an ability with the buff and the duration you want and let it cast the ability on all units u want to have the buff.
Forth, waits in picks are stupid, because they will go like this: First unit gets buffed - 6 seconds wait - debuff - Second unit gets buffed - 6 seconds wait - etc. I guess you don't want it to happen like this

Not sure what you're trying to accomplish, but that doesn't look right at all:

You are calling a wait inside the loop, meaning if there are two units in the heroSpellUG group, the second unit will not get the Berserking Power Damage attribute until after Berserking Power Damage has been added and removed from the first unit (~ 6 seconds later)
Because this is being called asynchronously (every time a unit casts Berserking Power), and you are adding and removing from a unit-group inside a loop, you are almost certainly opening yourself up to race conditions that occur when two units cast Berserking Power at the same time.

It's been a while since I've done any WC3 scripting, but what you probably want to do is add the ability to only that unit, then create a timer which takes away the ability when it expires.

Try it with just one unit triggering the effect.
When multiple units trigger the effect the they will only receive your buff sequentially.
Also unit groups and picks will create memory leaks, try to avoid them.
Also try it with a static time, and add a message at the very end of the script to debug it.

What do you mean by "not completing"?
Does it never end?
Does it never happen?
You might wanna ask on www.hiveworkshop.com where your chances to get an answer are 100000 times greater than on www.wc3c.net...
Edit: Seshiro said
Forth, waits in picks are stupid, because they will go like this: First unit gets buffed - 6 seconds wait - debuff - Second unit gets buffed - 6 seconds wait - etc. I guess you don't want it to happen like this

This is true, but also during the wait the trigger may run again, so the first unit in the group (UnitGroups are queues) will get the effect lots of times and the others will get it slowly...


text:
Should I use animated objects or use the physics engine on iOS scenes with lots of rigidbodies?
I have a scene with lots of houses and other objects. These objects will be bombarded from the sky. How to handle these kind of settings having in mind that you want the physics to be as realistic as possible.
In Unity3D, if I set all the objects with isKinematic=true and on collision I set it to false, then the physics isn't as realistic as I want it to be... Can you have these kind of scenes on iPhone? Should I have animated objects? I really don't know what is the best practice in this kind of scenes....

the problem with the kinematic object is that physics engine doesn't check if 2 kinematic object have collision and even if it collide with a dynamic object there won't be any change in kinematic object's speed, so basically you have to set all your game objects as dynamic, on the other hand you have to define all your objects as simple as possible for performance issue, you have to use only rects and ellipses, and at most triangles, and there are too many games with your base concept available in iphone now (remember angry birds?)


text:
Enabling multisampling in Irrlicht?
I'm working on a little game that uses Irrlicht. I'm pretty new to Irrlicht and I was wondering how I could enable multisampling. The device driver is EDT_OPENGL initiated as such:
IrrlichtDevice *device = createDevice(video::EDT_OPENGL,
                                        core::dimension2d<u32>(800, 700),
                                        16,
                                        NO);

How do I enable multisampling?

Here's a solution, but you'll need to call createDeviceEx instead of the current function.
You'll have to pass a SIrrlichtCreationParameters structure to the above function, with the AntiAlias member set to true (or another value ? It seems that the variable is an unsigned integer, and not a bool, never noticed that). Of course you'll have to define some other structure members in order to have the same IrrlichtDevice as the one in your question. ;)
Here's a piece of code if you prefer : (warning : I've not used Irrlicht since 1 year now)
SIrrlichtCreationParameters params = SIrrlichtCreationParameters();
params.AntiAlias = true;
params.DriverType = video::EDT_OPENGL;
params.WindowSize = core::dimension2d<u32>(800, 700);
IrrlichtDevice *device = createDeviceEx(params);

See here for (unfortunately not much) information. (the Irrlicht doc is in fact not very helpful, unfortunately)
Hope this helps, good night ! :-)

I think a combination of your answer and user1201210's is correct.  It should be "params.AntiAlias = 8;" The higher, the better it seems.

The AntiAlias value is meant to be a u8 not a boolean. Valid values are powers of two, so 2, 4, 8, 16. The device usually falls back to the next highest number if you specify a factor that is too high. 1 is usually the same as 0, but it depends if the hardware has a special meaning for 1 as an AntiAlias value.

Quick addendum to Minishlink's answer: AntiAlias is the number of samples to use in anti-aliasing. The following snippet comes from Irrlicht's COpenGLDriver.cpp.
// This value determines the number of samples used for antialiasing
// My experience is that 8 does not show a big
// improvement over 4, but 4 shows a big improvement
// over 2.
if(AntiAlias > 32)
    AntiAlias = 32;


text:
Does XNA provide any special class to make a game server?
For my multiplayer game server, I made a class inheriting from "Microsoft.Xna.Framework.Game", just like I did for the client-side part.
The thing is, I don't need any graphical display for the server, so I end up with a useless blank game window floating around. Also, the LoadContent/UnloadContent and Draw overrides are left empty. On the other hand, I still need to use Microsoft.Xna.Framework.Game for the game loop and logic update parts.
So is there any special class in XNA made especially for the server-side part, or is everyone else doing it just like I do?

There is no class that is part of the XNA library that acts as a game server.
You probably should not use the framework to write the server code unless you are creating a peer to peer Xbox based game over Xbox Live. I assume that you are not doing so because you would then need to render things onto the screen.
All C# programs start in the public static void Main method, including a program begun with the XNA framework.
If you do not already know how to create a program and import the XNA libraries without using the framework, you may be in over your head when it comes to the creation of a multiplayer game.

An XNA application is a .NET application, just like any other. In your Program.cs on the server, don't call the constructor or Run() for the Game class; just run your server logic instead.

But if I do that, I won't have the game loop that the Game class provides. So I won't be able to update the game state at a fixed interval of time.

You could use the System.Thread.Sleep(time) to update something at a fixed interval of time, and create your own server-side game loop manually

On a server why would you want a 60-times-per-second loop anyway? Wouldn't you rather have the control to make the server run faster or slower?

Why is it a problem that your game doesn't draw anything?
It seems like you're tilting at windmills.
If you want you can make a console application and then just import the XNA networking classes that you actually need, or make any other type of application, and import the XNA networking stuff. If you need a fixed time update loop, that is pretty trivial to implement.
You can create a windows forms application, and use it with XNA, by following the information here:
http://forums.create.msdn.com/forums/t/6471.aspx
You probably want your server to draw something though, like the current status, or provide some sort of GUI controls.

What kind of multiplayer server you are going to write? Is this just a lobby server for setting up peer-to-peer games? Is this a full on multiplayer server that is dedicated to hosting the game and communicating with clients (like Counterstrike servers, for example)? Or are you wanting to add multiplayer capability to your game in which a player starts a game that others can join?
If the last variant is what you want, XNA/.NET do provide some networking classes.
If you want to create a dedicated multiplayer server, you should do as HydroxicAcid says and avoid using the entire XNA framework as you will not need much of what it provides. What you should do is isolate your logic from your rendering code (in separate assemblies!) so that you can reuse these classes in your server application. You'll want to look into serialization over a network of figure out some lightweight message format for transporting gameplay data. There may be some instances where a 1:1 match between how a game object is represented on the server must be very different from how that same object is represented on the client, so be prepared to deal with that.
If you want to create a lobby server, you probably don't need to even write it in C# or use the .NET framework or even run it on a Microsoft platform. Its sole purpose is to find other people that want to play the game and tell them about each other, so there will likely be no need to reuse any existing game code for that.
Whatever it is you're looking to do, you can find a lot of good resources on AppHub => http://create.msdn.com/en-us/education/catalog/?devarea=19

That's brilliant. The separating logic idea.


text:
Draw real time fog of war in 2d game
I have game situation as shown in picture:

Red dot: player
Brown dot: obstacle ( rock, tree, etc)
Grey: non visible area ( under fog of war)

My question is: how can I draw that kind of shape, changed dynamically, with XNA 4.0. I can calculate each point of this shadow polygon. I would avoid drawing it pixel by pixel due to performance reasons, maybe particles? But i won't have sharp edges with this technique. Any tips?

The technique is the same as rendering shadows (many resources online). The difference is that instead of rendering the gray area as a shadow, you're using it as a mask to hide parts of the green area.

I don't know if it also exists under XNA, but with DirectX (and OpenGL I guess) you can use the stencil buffer to achieve exactly that effect.

@Anko this duplicate close vote leads to a chain of duplicate links, and it ends up in a closed question with no answers.  That doesn't seem right.

@Seth You're right. I meant to close them all as a duplicate of this one, which I think has the clearest phrasing and a clear (if somewhat incomplete) answer. Byte seems to have closed it as a duplicate of a much vaguer question for some reason. (I've voted to reopen it and added my reasons in the comments there.)

See here for an in-depth tutorial/example of doing it in HLSL (shader) code.:
http://www.catalinzima.com/2010/07/my-technique-for-the-shader-based-dynamic-2d-shadows/
If you want sharp edges remove the final blur step.

+1 Thats right 2D shadow maps are the coolest solution :)


text:
2D game physics, doing it right
I have a ball that you can make jump,
I have a sneaking suspicion I'm doing this wrong. It works now, to the extend that gravity pulls the object down toward the ground, but I'm having trouble manipulating the speed of the object.
What this is, is a ball jumping and falling towards the ground.
I have another function called "jump" that just adds a value to it's yVel
I can increase gravity, and it falls faster.
I can increase the jSpeed speed, and it'll rise up longer, but not faster
But I can't get it to do everything faster. It just looks painfully slow, which may or may not be because of my emulator running at 11 fps, on average.
Is it just my emulator, or is it something on my end?
float time = elapsedTime/1000F;
 if (speed < maxSpeed){
            speed = speed + accel;
            }
            if(mY + mVelY < Panel.mHeight){ //0,0 is top-left
            mVelY += (speed);
            }

            if (!(mY + height >= Panel.mHeight)){
            mVelY = mVelY  + gravity ;}

            mX  =  (float) (mX +(mVelX * time));
            mY =  (float) (mY + (mVelY * time));

Why two equal if statements? !>= is the same as <?

I can't really remember why I did that. I think it had a purpose once...

If your goal is to 'do it right', I wouldn't treat gravity as a special case and instead as just a constant acceleration.

There are some errors:
speed = speed + accel;

acceleration must be multiplied by time to get the change of velocity/speed during this frame:
speed = speed + accel * time;

The same problem is how you handle gravity, you cant simply add it to velocity.
Then you add speed to velocity each frame. Speed is actually the length of the velocity vector. Adding speed to velocity doesn't make sense physically.
You can find a proper implementation of Euler Integration in my answer here, there is a simple example showing how to deal with Acceleration, Velocity and Position.

That you can't add gravity can be somewhat accurate but is misleading and wrong in most cases because most game engines do recalculate the velocity vector by adding gravity at each time-step, much differently than speed with is added only when acceleration occurs (e.g. user presses left, right, jump, whatever). In that way the velocity for any given time-step is calculated as the sum of all accelerations along time, i.e. it's integral.