Tao.FreeType and amd64
Submitted by emacinnes on April 11, 2008 - 5:52am.
While we're waiting for a general 32bit vs 64bit resolve, I'm going to do some partial work on FreeType 2 here to convert the datatypes over to custom FreeType ones. I've just upgraded to 64bit Linux and am hit by the issue and need to get it functioning. Then later if we can find a generic solution to the cross-platform 64 bit issue of longs, then it'll be much easier to plug it in by changing the one datatype that's causing all of it, rather than the entire file.
Heh, I had this problem when
Heh, I had this problem when I was screwing around with FreeType myself (with the potential looking into asking it to get into Tao, but I never quite finished enough). However, I did find *one* way of handling the 32/64 bit problem with FreeType marshallings.
http://boogame.svn.sourceforge.net/viewvc/boogame/branches/dmoonfire_ref...
In specific, the FreeType.cs and FreeType64.cs. I know these work, I've been using them for a few (um, about five) months now with CuteGod.
Yeah, it isn't Tao (sorry about that), but I was aiming for it. I'll drop it as soon as I can compile to use the real Tao.FreeType and make sure it plays well on amd64 (for my game).
In short, basically what I did was create a static function to identify which version I should use. Mainly by looking at the sizeof int and make sure it isn't Windows 64 (because of pointer differences). Then, the various .Marshal(IntPtr) functions use that static property to handle the loading. In the 64-bit cases, it then uses a copy-constructor on the 32-bit to make everything use the same classes.
So, for a 32-bit, FT_Face.Marshal(IntPtr) returns a FT_Face object. For 64-bit, .Marshal(IntPtr) creates a FT_Face64, then creates a FT_Face which is then returned. The advantage is that the class always deals with a FT_Face object with a consistent sized variables and doesn't need a recompile, and it is determined at runtime which version to use.