"When you seek revenge, dig two graves."
More pages: 1 ... 11 12 13 14 15 16 17 18 19 20 21 ... 31 ... 41 ... 47
1.06 GigaEuros
Wednesday, May 13, 2009 | Permalink

EU fines Intel 1.06 billion in the EU antitrust case. Justice at last I guess you could say. Not a day too soon and hardly surprising given the shenanigans that's been going on for so long. Intel will of course appeal, but I think their chances at getting a particularly much more favorable verdict are slim given the facts on the table. A more interesting question is if it will actually change Intel's behavior. I'm doubtful. Although the fine is the largest ever it's probably only a fraction of the profits Intel made over their years from their illegal activities.

Also worth reading:
Will fine force Intel to change its ways?

[ 1 comments | Last comment by mark (2009-05-31 21:46:56) ]

Duke Nukem Forever
Thursday, May 7, 2009 | Permalink

Duke Nukem Whenever
Duke Nukem Taking Forever
Duke Nukem If Ever
Duke Nukem Never, and that's official.

[ 3 comments | Last comment by Micke (2009-05-20 01:07:34) ]

The most horrible interface ever
Wednesday, May 6, 2009 | Permalink

Here's one vote for Win32 API handling of cursors. Trying to squeeze a custom cursor through Windows' tight intestines and not getting screwed in the process in one way or another is easier said than done.

So you have a custom cursor and you called SetCursor() to use it. What if you want to hide it?

ShowCursor(FALSE)?

*BZZZZTT* Wrong answer!

SetCursor(NULL)?

*BZZZZTT* Wrong answer!

Correct answer:

PostMessage(hwnd, WM_SETCURSOR, (WPARAM) hwnd, HTCLIENT);

and then

case WM_SETCURSOR:
SetCursor(NULL);
return TRUE;

No, just calling SetCursor(NULL) directly doesn't work. You really need to do it in response to WM_SETCURSOR, or it won't work. Or at least doesn't take effect until you move the mouse or click. Or just wait a few seconds until Windows randomly postes a WM_SETCURSOR message to your window for absolutely no reason. What the heck, does that happen to cover up that things aren't really working under the hood?

[ 7 comments | Last comment by Humus (2009-05-11 22:21:33) ]

Shader programming tips #5
Friday, May 1, 2009 | Permalink

In the comments to Shader programming tips #4 Java Cool Dude mentioned that for fullscreen passes you can pass an interpolated direction vector and use the linearized depth to compute the world position. Basically with view_z computed using the math in #4 you compute:

float3 world_pos = cam_pos + In.dir * view_z;

This amounts to only two scalar operations and one float3 to carry out.

What about regular non-fullscreen passes? Turns out you can do that as well using a nice DX10 feature. The problem is that we need to interpolate the direction vector in screen space, rather than doing perspective correction. For screen aligned primitives it's the same thing, so it works out in this case, but for "normal" mesh data it's a completely different story. In DX10, and also in GLSL, there's now a noperspective keyword you can add to your interpolator, which changes the interpolation mode to eliminate the perspective correction, thus giving you an interpolation that's linear in screen space instead.

How do we compute the direction vector? Just take the position you're writing out from the vertex shader and push it to the far plane. Depending on if you're using a reversed projection matrix or not you either want Z=0 or Z=1, which can be done with using float4(Out.Position.xy, 0, Out.Position.w) or Out.Position.xyww respectively in homogenous coordinates. Transform this vector with the inverse view_proj matrix to get the world position of the far plane equivalent of the point in world space. Now subtract cam_pos from this and that's the direction vector. Instead of subtracting the cam_pos in the vertex shader you can just bake that into the same matrix and get it for free. The resulting vertex shader snippet for this is something like this:

float4 dir = mul(view_proj_inv, Out.position.xyww);
Out.dir = dir.xyz / dir.w;

Finally, note that view_z as computed in #4 goes from 0 at the camera to far_plane at the far clipping plane. For this computation we need it to be 1.0 at the far clipping plane, which can be done by simply multiplying ZParams with far_plane. Alternatively you can divide Out.dir with far_plane in the vertex shader.

[ 0 comments ]

Happy Anniversary AMD!
Friday, May 1, 2009 | Permalink

Today AMD turns 40. And what's a 40 year old without a bit of a crisis? Congratulations and good luck in the future!

I worked for AMD for about a year. I came originally from ATI but became part of AMD due to the merger in 2006. Continued with the same kind of job under AMD until the fall of 2007, after which I moved home to Sweden again and joined Avalanche Studios. Greetings to all my old friends that are still at AMD! Keep up the good work!

[ 0 comments ]

Today's whine
Wednesday, April 29, 2009 | Permalink

As I touched on briefly in my piracy post on piracy, we live in a globalized world and regionalizing digital products makes absolutely no sense in this time and age. This is not something that the average broadcast corporation understands, but some do. Or did. It's with great disappointment I see that Comedy Central has now implemented geofiltering, the perhaps most ironic and moronic kind of technology ever invented, so now my favorite show The Daily Show with John Stewart is no longer "available" in my "area". What they are hoping to achieve with this is beyond my comprehension. What the result is going to be is obvious though, their shows will get a smaller audience, and those who care enough will pirate it. And the pirated versions are of course stripped from all the commercials, the bread and butter of broadcasting corporations.

Oh well, in another 10-15 years the average CEO will be of my generation. By then I hope this kind of nonsense finally comes to an end.

[ 8 comments | Last comment by sqrt[-1] (2009-05-08 12:34:37) ]

Hmmm ...
Tuesday, April 28, 2009 | Permalink



Some left over debug code in Nvidia's webshop?
Or perhaps a warning regarding how truthful the information on the site is?

Screenshot is from yesterday night. Did not happen when I tried today.

[ 1 comments | Last comment by drp (2009-04-30 02:39:41) ]

Shader programming tips #4
Monday, April 27, 2009 | Permalink

The depth buffer is increasingly being used for more than just hidden surface removal. One of the more interesting uses is to find the position of already rendered geometry, for instance in deferred rendering, but also in plain old forward rendering. The easiest way to accomplish this is something like this:

float4 pos = float4(In.Position.xy, sampled_depth, 1.0);
float4 cpos = mul(pos, inverse_view_proj_scale_bias);
float3 world_pos = cpos.xyz / cpos.w;

The inverse_view_proj_scale matrix is the inverse of the view_proj matrix multiplied with a scale_bias matrix that brings the In.Position.xy from [0..w, 0..h] into [-1..1, -1..1] range.

The same technique can of course also be used to compute the view position instead of the world position. In many cases you're only interested in the view Z coordinate though, for instance for fading soft particles, fog distance computations, depth of field etc. While you could execute the above code and just use the Z coordinate this is more work than necessary in most cases. Unless you have a non-standard projection matrix you can do this in just two scalar instructions:

float view_z = 1.0 / (sampled_depth * ZParams.x + ZParams.y);

ZParams is a float2 constant you pass from the application containing the following values:

ZParams.x = 1.0 / far - 1.0 / near;
ZParams.y = 1.0 / near;

If you're using a reversed projection matrix with Z=0 at far plane and Z=1 at near plane you can just swap near and far in the above computation.

[ 9 comments | Last comment by Greg (2009-05-01 19:33:02) ]

More pages: 1 ... 11 12 13 14 15 16 17 18 19 20 21 ... 31 ... 41 ... 47