October 4th, 2010
- woah, is that a shark? It’s so small!
- yeah it is. A small shark… it’s a sharkozy !!!
(only funny for french readers I suppose)
October 4th, 2010
- woah, is that a shark? It’s so small!
- yeah it is. A small shark… it’s a sharkozy !!!
(only funny for french readers I suppose)
September 26th, 2010
Thanks for the link, Benoit
September 24th, 2010
http://www.codercorner.com/Pictures/OpenGLConsideredHarmful.PNG
I’m not the only one with that kind of troubles
September 23rd, 2010
The coolest demo to ever come out of the Zürich office is finally public:
http://physxinfo.com/news/4331/physics-demos-from-nvidia-gtc-keynote/
I mentioned that one to some people before, now you can have a look
September 20th, 2010
Here’s an interesting new paper:
http://graphics.ewha.ac.kr/gSaP/
http://graphics.ewha.ac.kr/gSaP/gSaP.pdf
I’m not sure where they got that though:
“Moreover, [Terdiman 2007] hypothesized that parallelizing the hybrid SaP and subdivision may perform poorly”.
Did I? I just briefly explained how to do it but I don’t think I ever wrote “it may perform poorly”. Or show me where, because I don’t remember. In fact, I didn’t investigate this path well enough to know. But this is interesting and motivating, maybe I will now
“This algorithm may be considered as a parallel version of that proposed by [Terdiman 2007]”.
Hmm, but I already explained the parallel version in that paper, didn’t I? So it’s basically a parallel implementation of an MSAP, which I already detailled in 2007 (and it wasn’t even new at the time). No? Well ok, for GPU.
I should note that I’ve made the “ArraySAP” in that benchmark a bit faster than it used to be (especially insertions can now be 2X faster), but overall it doesn’t change their good results.
Oh, and I’ve used PCA to compute the best axis years ago already, in Z-Collide
SAP in 1999, SAP in 2010… I just can’t escape
September 2nd, 2010
Little trivia about empty classes…. Here’s the setup:
Question: what’s the size of Test0? What’s the size of Test1?
It’s a relatively well known fact that embedded empty classes are not actually free, and add 1 byte to the class containing them. So, knowing this, it shouldn’t be a surprise that sizeof(Test0)==2.
A more surprising fact, maybe, is that sizeof(Test1)==1. Yep, not free either, and a different size from Test0. It has to do with an obscure rule saying that the addresses of base classes must be different, or something. Can’t remember. Still, you need to keep this in mind if you don’t want to discover weird “ghost bytes” in your binary-serialized data.
Oh well.
September 2nd, 2010
The size of enums is compiler-dependent, and usually you don’t have any control over it. For example let’s have this simple enum for some types:
Then let’s check the size of the enum type:
With MSVC 2008, s = 4. This is clearly a waste of space in this case, since the type could be safely encoded on a single byte. So how do you tell the compiler about this? Well it turns out MSVC allows this nice syntax to control the size of the enum:
And that’s it! Compile with this, and s = 1. This is very useful when trying to save some bytes in a class while retaining the type safety provided by the enum. I think this notation is part of C++0x and will be supported in all compilers at some point. Right now though, it doesn’t seem to work with GCC.
For a portable solution, one probably needs to use templates, maybe something like:
July 13th, 2010
A recent talk with a friend made me realize that the following declspec is not very well known. It’s used to avoid inlining a function (the opposite of what we’re usually looking for, which probably explains why it might have remained obscure for a lot of us).
With VC++:
__declspec(noinline)
With gcc:
__attribute__ ((noinline))
It’s very useful for example with templated arrays, to make sure things like the resize functions are never inlined.