"People are more violently opposed to fur than leather; because it's easier to harass rich ladies than motorcycle gangs."
More pages: 1 ... 4 5 6 7 8 9 10 11 12 13 14 ... 21 ... 31 ... 41 ... 48
Latest Steam survey
Sunday, August 1, 2010 | Permalink

Highlights this month:
- Windows 7 64bit is now the most popular OS. Windows XP's decline is accelerating. All 32bit versions dropped and all 64bit versions increased their share, even WinXP 64.
- DX11 GPU adoption is accelerating, although still only 9.26% vs. 74.16% for DX10. AMD continue to dominate the DX11 market.


Yet another gallery
Sunday, August 1, 2010 | Permalink

More pictures! I present you with the Just Cause 2 release party, pics from Riga, and more.


OpenGL 4.1
Friday, July 30, 2010 | Permalink

I'm a few days late on this news, but earlier this week OpenGL 4.1 was released. There was a time when I had doubts in the future of OpenGL, but in the last couple of years the API has really made a lot of progress, so much so that I sometimes feel I can't keep up with it. I would say that by now it's back to where it used to be, namely a competent alternative to DirectX that's also cross-platform. Some feature missing perhaps, but at least as often there are bonus features not available in DirectX.

[ 6 comments | Last comment by Micke (2010-11-17 17:14:42) ]

Another gallery
Wednesday, July 28, 2010 | Permalink

Trying to catch up with time here, so I've uploaded another gallery of old pictures. With this I'm only about 5 months behind the times.
The time covered by this gallery includes when I met my fiance, so I think she's in like half the pictures , but what the heck, she's pretty so why not?
I'll probably add another couple of galleries soon to get in sync with the times.

[ 2 comments | Last comment by Josef (2010-07-28 21:40:24) ]

New gallery
Sunday, July 25, 2010 | Permalink

I've uploaded a "new" photo gallery. I've been lagging with my photo updates, so the pictures are only about a year old, from last summer. But better late than never.


Monday, July 5, 2010 | Permalink

Tonight me and my fiance will get on the plane for China. So for the next two weeks this blog is likely to be silent. In the meantime, check out my article "Making it large, beautiful, fast and consistent Lessons learned developing Just Cause 2" in GPU pro. I just got my copy today, so I guess I'll have some reading on the flight.

[ 5 comments | Last comment by Humus (2010-07-23 17:57:09) ]

Wednesday, June 23, 2010 | Permalink

Via Rage3D I found this Nvidia blog post, which I found somewhat amusing. Although after a brief look at the actual paper I give Intel a bit more credit than the Nvidia spin of it. Still, even then, the Intel paper concludes that the previous generation GPU is 2.5x faster on average.

Anyway, I find the GPU vs. CPU war not so interesting, because my prediction is that we still need to have both paradigms around. No model is going to "win", so I don't think Intel needs to be so defensive, nor do I believe in Nvidia's prediction that "the piece of hardware that runs sequential code will shrink to a tiny dot swimming in an ocean of ALUs" (I forgot the exact wording, but something like that). I don't believe in Nvidia's prediction because of Amdahl's law. At least when speaking of games, there will always be some sort of critical path through the game update code where each step needs input from previous steps. So just slapping on more cores will not make things much faster and switching to the Larrabee model for CPUs is likely to make things slower even if you get an order of magnitude more raw throughput power. I believe the model for future CPUs is something like what the PS3 has, with one main CPU and 6 smaller throughput oriented SPUs. Even in the future we will need at least one, but preferably two or three cores optimized for quickly crunching through sequential code. Then a larger number of tiny throughput oriented cores next to it for parallel but fairly independent tasks. Then the GPU for graphics and a number of other embarrasingly parallel tasks. I don't think the GPU and CPU will meet anytime soon, although with more and more programmable GPUs and then stuff like Fusion I could imagine that the GPU and the SPUs might merge at some point, but I'm not convinced of that yet.

[ 11 comments | Last comment by Nuninho1980 (2010-08-04 13:39:03) ]

Dealing with uninitalized memory
Friday, June 18, 2010 | Permalink

A common source of undeterministic bugs that are hard to find is uninitialized variables. In a local scope this is typically detected by the compiler, but for member variables in a class you're typically on your own. You forget to initialize a bool and in 255 cases of 256 you get 'true', so the code might appear to work if that's a reasonable initial value. Until your bool ends up on a memory address with a zero in that byte.

One way to deal with this problem is to simply initialize all memory to zero first thing in the constructor. Unfortunately, that adds a runtime cost and code size cost. I figured someone must have attacked this problem before, and I'm sure someone did, but googling on it I haven't found much about it. So I came up with my own approach, which I'll be adding to Framework4. Basically it's a small class and a set of macros to simplify stuff. In my class definition I just tag the range of variables I want to check, typically all of them.

class MyClass
    // Variables go here

This inserts a start and end tag into the class, which are basically two uint32.
In the constructor I do this:

MyClass::MyClass() : CLASS_INIT()

CLASS_INIT() will initialize all memory between the tags to 0xBAADCODE, before any other initialization happens.

At some point where I expect everything to be set up, for instance the end of the constructor or maybe after some call to Init() or whatever, I simply add CLASS_VERIFY() which will check that no memory is left as 0xBAADCODE. Also, it will check start and end tags to make sure they have not been touched, which will also detect common out of range writes.

Adding this to my simple test app I found a whole bunch of variables I didn't initialize. Most of them were simply unused though. I can't imagine what kind of bug could be avoided if something like this is added to the main system classes in a big scale project. And the best of all, this come at no extra cost at runtime because in final builds those macros are defined to nothing.

[ 21 comments | Last comment by niko (2010-11-12 03:00:35) ]

More pages: 1 ... 4 5 6 7 8 9 10 11 12 13 14 ... 21 ... 31 ... 41 ... 48