Erik Rufelt

I assume you combine your stencil shadows with drawing lighting with vertex-normals.

The problem occurs when normals are interpolated for smooth shading. If you draw your sphere with flat shading, as in that every triangle has only one normal, and not interpolated vertex normals, then it would look as expected. The reason for this is that stencil-volume edges are extruded between two triangles where one faces the light and one faces away from the light. With interpolated vertex-normals the normals used in the lighting calculation don't match the normals used to calculate the stencil shadow.

If every vertex that touches a triangle that is back-facing with respect to the light receives zero lighting, then the problem goes away.

You can fix it by, when you extrude the edges between back and front-facing polygons, instead of using the triangle plane normal to determine facing, looping over the three vertex normals in the triangle and checking if any of the vertex normals face the light. If at least one normal faces the light, then consider the triangle front-facing.

This will however cause your shadow volumes to shrink a bit, which may or may not be acceptable.

Another variation is to change the vertex-normals so that any vertex that touches a back-facing triangle receives zero lighting, which would keep your shadow volumes the same, but cause the shadow edge to grow a bit instead, as the shadow would be blurred into the lighted part instead of the light being blurred into the shadowed part.

One reason for multiple windows is if you want to use wglChoosePixelFormatARB to select your pixel format, and the final pixel-format might differ from the one selected with wglChoosePixelFormat for the dummy context. A window can't change its pixel-format once set.

As for the original question, do you mean that an active context claims to be 3.1 through GL_MAJOR_VERSION/GL_MINOR_VERSION, but functions that are guaranteed to be in core 3.1 are not available?

If they are extension functions, check if they are available in the extensions string.

EDIT: If I understand correctly the problem is that, when calling glGetIntegerv(GL_MAJOR_VERSION) and glGetVersion() after each other, on the same context, they return conflicting information. Which seems strange to say the least.. can you make a minimal example and post the code?

As well as update your drivers, might be a bug.

My guess is that glGetIntegerv(GL_MAJOR_VERSION, ..) returns an error (check with glGetError()), and does not overwrite the integers in int version[2]. Therefore some old values that happen to be 3 and 1 are still there and the real version is 1.2, for which GL_MAJOR_VERSION is not supported.

If you like the technical side, and want to learn how the internals of computers work.. and math and similar.. then definitely start coding, but prepare to start with text-based programs and then some simple 2D games for quite a while before you can do anything bigger. Your first games will be something like "guess the number" or "rock paper scissors" in text.

After you're comfortable with the language in general you can learn graphics and create something like Pong.

I started with C when I was 12 and then C++ and then other languages, and it's a lot of fun if you like coding, but if you want your drawings on screen in nice graphics in the near future, then low-level coding isn't what you want to be doing. For that, learn a 3D modeling or other art program, and combine with Unity.

Games like Halo usually don't use much C++ to implement the game logic. The engine driving the game is in C++ and takes years to create, and the actual game logic is implemented in scripting (as you also do in Unity).

You still need to learn some coding to be able to script your models, and you still start by doing text-based programs in the scripting-language of your choice, but it will be a lot easier and faster.

I don't mean to put you off C++, it's fun to learn, but only do it if you like the technical side.

I plan to use hardware skinning, and thus I need to use loop inside the vertex shader

Hardware skinning is usually done without loops by always skinning for a static number of bones per vertex, and using weights of 0.0 when less than that are needed for a particular vertex.

In general branching and looping on variables are bad, while looping over constants will be unrolled automatically by the shader compiler.

If you haven't written a skinning shader before, then start by writing one that works on your development system, and worry about support on other platforms later. If you know how to do it with loops then do it with loops, and then post the code here and people can comment on it.

Finding the information you need and iteratively changing your method will be easy once you've written one that works.

If you need information on how to start, then post information on your GLSL version and hardware so we can recommend a tutorial.

Just guessing unless you post the whole code in its entirety, but when you call ShowWindow it will call your WindowProc with a couple of messages, and perhaps the D3D device was used there, before it was initialized, or similar.

Post your WndProc.

Actually make a new project and paste your code there and then post the entire code if it still crashes, don't include stuff that isn't used. Perhaps you use something from WndProc that isn't created yet. Try putting ShowWindow right before the main-loop after D3D is set up etc.

Do you want to do it with C functions or as a class?

I made an example with another DLL that exports C functions that uses the wrapper, and a C# class that can use it: http://www.rufelt.com/fw1fontwrapper/csharp/

Download FW1CWrapper.zip and extract the appropriate DLL together with the usual FW1FontWrapper.dll and use the source in FW1Wrapper.cs to use the DLLs from C#.

I haven't tested this extensively and I don't have very much experience in C# or interop, but it seems to work fine, as long as you compile with x86 or x64 and use the appropriate DLL.

Then in SlimDX you can do this:

using FW1;
 
...
 
IntPtr devicePtr = device.ComPointer;

IntPtr contextPtr = device.ImmediateContext.ComPointer;


FW1Wrapper fontWrapper = new FW1Wrapper(devicePtr, "Arial");
 
...
 
fontWrapper.DrawString(contextPtr, "a string", "Courier New", 64.0f, x, y, 0xffffffff, FW1Wrapper.Center);

I've only done the most common functions.

Try setting the file-name to NULL when you specify the code in memory.

Or try using D3DCompile instead. There's probably no reason to go through the D3DX11 function in this case.

B is usually just a way to automatically generate the texture and the mapping for A in code, so they are equivalent.

Using B might be better if you use many different font-sizes and not the same letters all the time, to avoid saving massive textures and charactermaps, but otherwise using A directly is probably better so you don't have to have the GDI code in your game and can avoid generating the textures every time.

If you want a library that draws text for you, I made one a couple of years ago that uses B, but with DirectWrite instead of GDI: http://fw1.codeplex.com/

Wow, I accidentaly found a perfect article, describing the process I tried to explain in my previous post 

Hope it will help someone who stuck at this problem just like me.

 

It describes how you must subtract 0.5 to get corresponding pixel and texel match each other.

That is not correct in D3D11, only in D3D9. It has changed. If that fixes your problem then it is coincidental and not your actual issue, as you see from the letters that still look wrong.

You should divide by 1900 to get correct coordinates if that is the size of the texture, not 1899. The last pixel begins at 1899, but ends at 1900.

Imagine a texture that is just 1x1 or 2x2 in size. If you divide by width-1 you get completely wrong results.

If your Q begins at 795 and is 9 pixels wide then the correct coords are:

795.0 / 1900.0 = 0.4184210526

(795.0 + 9.0) / 1900.0 = 0.4231578947

If you have a 1x1 sized letter at the last pixel on the right side of the texture, then it starts at 1899 and has a width of 1.

1899.0 / 1900.0 = 0.9994736842

(1899.0 + 1) / 1900.0 = 1.0

Each single pixel is a quad with 4 edges, it is not a zero-width point. Each single pixel has a width of 1.0 / 1900.0

The problem is either the texture coordinates or the vertex coordinates for your quads. Are you sure you are using only integer coordinates?

If your quad vertices are like 10.1 instead of 10.0 this could happen. If your texture-coordinates are on exact pixel boundaries in the texture then you need to use vertex coordinates without fractional parts too.

Also, you should not use 1899, but 1900. Coordinate 1.0 would otherwise be on the left side of the last pixel, where it should be on the right side.

Floating point is not an issue, it is precise enough for this case.

So if Q starts at 177, 0 in the texture and is 9 pixels wide and 18 pixels high, use coords (177.0/1900.0, 0.0, (177.0+9.0)/1900.0, 1.0).

Use vertex-coordinates (x, y, (x + 9.0), (y + 18.0)) to draw it on the screen, where x and y is floor(...) to make sure they are integers.

If you later scale your text it's possible you want to include a half pixel border for linear filtering, and as such create texture coordinates at 10.5 / 1900 instead of 10.0 / 1900, at which point you also need to do that for vertex-coords on the screen. Start with integer coords.

On your new picture the letter widths are still different from the texture. If you are using point sampling, try switching to linear filtering and you will see it more clearly that the texture is blurred. Disable blending or add character boxes to your texture in different colors, so you can see each quad matches the corresponding quad in the texture pixel by pixel.

If you paste your two images on top of each other and align the letters it's clearly visible that the rendered characters are wider than those in the texture. Perhaps you scale horizontally somewhere. Also, if you manually specify the back-buffer size, double-check that it matches the window client area.

The reason you need shutdown is because recv() will not return 0 until the server decides to disconnect you. If the program doesn't exit immediately after receiving the image, the server is probably keeping the connection open until it decides to time out and disconnect you later. If you use shutdown with SD_SEND you tell the server that you will not be sending anything more, so it knows that it's OK to disconnect you when the image is sent.

You are using recv() correctly. It will not necessarily block until the buffer is full, only until at least one byte is received or an error occurs. You already handle that correctly by saving "result" number of bytes. An error is when result < 0 (disconnect from timeout or similar), graceful disconnect is when result == 0, and result > 0 is received data as you already know.

Assuming this is HTTP.. and you have some more recv() code earlier to handle the HTTP header?

You could ask the server to disconnect you faster by sending a "Connection: close" HTTP header in your request, and hopefully it will conform to protocol and do so.

You will obviously get a problem if the image is larger than 1 MB or whatever size you use for new[]. If you want to improve your program and this is HTTP, you can parse the Content-Length: header in the response before the image, to allocate exactly the number of bytes needed.

What are you going to use it for?

If you're actually placing it on a terrain then you probably want the triangles to match the terrain triangulation exactly, as a quad can be triangulated by splitting by either of its diagonals, and the two triangulations are not equivalent unless all the 4 vertices lie in a plane.

I would start with the triangulated grid and simply clip it to the polygons you place on top. Should be rather simple as only those triangles of a cell that are intersected by a boundary edge need to  be changed, and all the interior cells are already done. It should yield a nice triangulation, and reduces the problem to the clipping of a single triangle to inside the shape, for each edge-intersecting triangle.