More pages: 1
... 4 5 6 7 8
9 10 11 12 13 14
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.
[ 0 comments
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)
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)
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.
[ 0 comments
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)
GPU vs. CPU
Wednesday, June 23, 2010 | Permalink
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.
// 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)
New DirectX SDK
Wednesday, June 9, 2010 | Permalink
The June 2010 DirectX SDK
has just been released. I haven't given in a try yet, but there appears to be a few nice things in it, but not so much big news. This release also drops MSVC 2005 support while adding MSVC 2010 support.
[ 1 comments
| Last comment by fmoreira (2010-06-12 22:55:34)
More pages: 1
... 4 5 6 7 8
9 10 11 12 13 14