Ogre 64 bits
- tenaciusgordon
- Gnoblar
- Posts: 3
- Joined: Tue Sep 26, 2006 10:43 am
- Location: Madrid (Spain)
Ogre 64 bits
Hello, we are a group of people that we are trying to use Ogre for 64 bits with windows x64, Somebody has been able to use it??
As Ogre depends on third part (like envidiacg.dll, devin.dll..... till 12) we are not able to do it.
Thanks in advance
As Ogre depends on third part (like envidiacg.dll, devin.dll..... till 12) we are not able to do it.
Thanks in advance
- tuan kuranes
- OGRE Retired Moderator
- Posts: 2653
- Joined: Wed Sep 24, 2003 8:07 am
- Location: Haute Garonne, France
- x 4
- Contact:
I've successfully compiled once all in win x64.
Devil, cegui and zzip are really easy to build in x64 way, no need of special patches, just change target cpu build target in vc2005. zlib already has a x64 target. CG from nvidia can be downloaded specifically for x64 too.
Same for ogre, it's just a target change.
I didn't continue on that, as I didn't get any speed improvements at all, even if it was supposed to use "sse3 and new registers automatically" if we believe marketing from ms and amd.
Devil, cegui and zzip are really easy to build in x64 way, no need of special patches, just change target cpu build target in vc2005. zlib already has a x64 target. CG from nvidia can be downloaded specifically for x64 too.
Same for ogre, it's just a target change.
I didn't continue on that, as I didn't get any speed improvements at all, even if it was supposed to use "sse3 and new registers automatically" if we believe marketing from ms and amd.
-
- OGRE Retired Team Member
- Posts: 1603
- Joined: Wed Oct 20, 2004 7:54 am
- Location: Beijing, China
- x 1
The SSE optimisation in Eihort was truned off for x64 targets, as I haven't have compiler to build it up, as well as I never intsalled Win64/Linux64 at all, even though my hardware is ready for x64 (AMD Athlon x64 here). The gcc compiler I used is come from cygwin, version 3.4.4, it doesn't build with cross compile x64 target too. So, I have no ways to test with x64 for now.
- tuan kuranes
- OGRE Retired Moderator
- Posts: 2653
- Joined: Wed Sep 24, 2003 8:07 am
- Location: Haute Garonne, France
- x 4
- Contact:
My x64 test was with dagon anyway, with genva eihort sse optimisations, it surely will be faster to use 32bits version, even on x64 cpu.
@genva: just to be sure, I was speaking of compiler automatic sse3 code generation and amd64 register use. That said I never took the time to read x64 code generated by vc2005 to check reality of those marketing announces. In term of Ogre FPS, it was null anyway.
@genva: just to be sure, I was speaking of compiler automatic sse3 code generation and amd64 register use. That said I never took the time to read x64 code generated by vc2005 to check reality of those marketing announces. In term of Ogre FPS, it was null anyway.
- tenaciusgordon
- Gnoblar
- Posts: 3
- Joined: Tue Sep 26, 2006 10:43 am
- Location: Madrid (Spain)
We are not really focused on the performance of the 3D engine. We have studied different engines Illricht, Blender... and finally have decided to use OGRE, not only because of its nice visual features but because of its good and understandable code.
Our main target is to have a 3D engine for X64 (and x86), not because of its "improved?" speed, but because our application must work on x64.
Our team has 4 * 64 bit machines with win x64. We are going to try hard to make it work on x64 and hopefully have some examples for next week. If you are interested in our help for an x64 version of Ogre, just tell me.
Regards.
Our main target is to have a 3D engine for X64 (and x86), not because of its "improved?" speed, but because our application must work on x64.
Our team has 4 * 64 bit machines with win x64. We are going to try hard to make it work on x64 and hopefully have some examples for next week. If you are interested in our help for an x64 version of Ogre, just tell me.
Regards.
- sinbad
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
- Contact:
- tenaciusgordon
- Gnoblar
- Posts: 3
- Joined: Tue Sep 26, 2006 10:43 am
- Location: Madrid (Spain)
We have no experience compiling third party DLLs,
We have found some problems compiling the Ogre external dependencies, but we are still making ourselves an overall idea on how to compile everything, the way of working you have and so on.....
We are now having trouble compiling DevIL.DLL, ILU.DLL and ZLIB1.DLL, which we have searched through Internet. We assume that it is because we are using different versions, in fact, the projects create DLLs with different names which we have renamed in a hopeless try to make it work (we don't manage to either compile the win32 dynamic version). Where can we find the "good" or official projects of these DLLs that link with Ogre?
Any help will be really welcome and will accelerate the results
Regards
We have found some problems compiling the Ogre external dependencies, but we are still making ourselves an overall idea on how to compile everything, the way of working you have and so on.....
We are now having trouble compiling DevIL.DLL, ILU.DLL and ZLIB1.DLL, which we have searched through Internet. We assume that it is because we are using different versions, in fact, the projects create DLLs with different names which we have renamed in a hopeless try to make it work (we don't manage to either compile the win32 dynamic version). Where can we find the "good" or official projects of these DLLs that link with Ogre?
Any help will be really welcome and will accelerate the results
Regards
- tuan kuranes
- OGRE Retired Moderator
- Posts: 2653
- Joined: Wed Sep 24, 2003 8:07 am
- Location: Haute Garonne, France
- x 4
- Contact:
http://www.zlib.net/
http://sourceforge.net/projects/openil
Resulting dll names may not be the same, but that's not a problem if you link against them, but do not rename them.
Thing to make sure is that they compile using "multithreaded dll" in each project settings.
http://sourceforge.net/projects/openil
Resulting dll names may not be the same, but that's not a problem if you link against them, but do not rename them.
Thing to make sure is that they compile using "multithreaded dll" in each project settings.
-
- Gnoblar
- Posts: 1
- Joined: Sat Mar 28, 2009 12:26 am
Re: Ogre 64 bits
x64 could be cool as part of SDK
-
- Gnoblar
- Posts: 2
- Joined: Wed Dec 09, 2009 4:34 am
Re: Ogre 64 bits
i d like to make sure if OGRE perform normal with Windows X64? anyone
程序员是高尚的,博士是伟大的,程序员博士就是苦逼的了。
- Azgur
- Goblin
- Posts: 264
- Joined: Thu Aug 21, 2008 4:48 pm
Re: Ogre 64 bits
I haven't run into any issues running 32bit software on 64bit Windows.plwuxin wrote:i d like to make sure if OGRE perform normal with Windows X64? anyone
This includes Ogre.
Running your Ogre application as a 64bit application has some advantages, but most of the time they are neglectable for most common uses.
-
- Halfling
- Posts: 78
- Joined: Fri Feb 06, 2009 7:04 pm
Re: Ogre 64 bits
I have recompiled all dependencies in x64 (the most difficult) ... and Ogre compile without trouble in X64... seems to works fine
- guyver6
- Greenskin
- Posts: 106
- Joined: Mon Dec 23, 2002 10:16 pm
- Location: Warsaw, Poland
Re: Ogre 64 bits
Hi,
I was trying to get Ogre3D working on Snow Leopard in 64 bits. I got compiled needed dependencies (except OIS of course ), patched Ogre a little (patch against v1_7 branch attached), and... I hit a compiler error. I'm using GCC 4.2, as it is supported for 10.5+ SDKs (and I've tried building against 10.5 and 10.6 and the result is the same - linking error due to bad code generation from GCC 4.2). Anyway, I even filed a bug with Apple's radar about the issue. The exact error is like this:
It happens during linking only, and the problem is std::endl symbol referenced in OgreConvexBody (and in some more files actually; if you generate asm using -S GCC option instead of -c, you're able to fix the mis-compilation of OgreConvexBody and the rest of std::endl users and it links without problems). The workaround is to use GCC 4.0 (and get suboptimal performance on x86_64, since in GCC 4.2 there were a lot of optimizations dedicated to that architecute).
So, this is just an informational post if someone tries and dies trying to do the same. Oh, and the patch might be useful (it turns off Carbon for __LP64__ compilations).
PS. Maybe someone is interested in the bug report, so it's radar number is 7511396, and here it is quoted:
I was trying to get Ogre3D working on Snow Leopard in 64 bits. I got compiled needed dependencies (except OIS of course ), patched Ogre a little (patch against v1_7 branch attached), and... I hit a compiler error. I'm using GCC 4.2, as it is supported for 10.5+ SDKs (and I've tried building against 10.5 and 10.6 and the result is the same - linking error due to bad code generation from GCC 4.2). Anyway, I even filed a bug with Apple's radar about the issue. The exact error is like this:
Code: Select all
ld: codegen problem, can't use rel32 to external symbol std::basic_ostream<char, std::char_traits<char> >&
std::endl<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&)in Ogre::operator<<(std::basic_ostream<char, std::char_traits<char> >&, Ogre::ConvexBody const&)from /Users/endru/work/ogre3d/builds/cthugha/lib/OGRE.build/Debug/OgreMain.build/Objects-normal/x86_64/OgreConvexBody.o
So, this is just an informational post if someone tries and dies trying to do the same. Oh, and the patch might be useful (it turns off Carbon for __LP64__ compilations).
PS. Maybe someone is interested in the bug report, so it's radar number is 7511396, and here it is quoted:
SUMMARY:
Unable to link Ogre3D using GCC 4.2 targetting x86_64 due to badly generated asm code.
STEPS TO REPRODUCE:
Excuse the long list of steps needed to reproduce, but I couldn't get smaller samples to reproduce the same error. Here it goes:
1. Install Ogre3D dependencies (you need to provide 64-bit versions of those, I'll attach these if radar allows me to): Freetype, FreeImage, Cg-2.2 (from NVidia, you'll need to untar to root directory the NVIDIA_Cg.tgz file included in the DMG you download from NVidia, because it fails to install on Snow Leopard) and zziplib. These are enough to reproduce bug.
2. Install CMake
3. Fetch Ogre3D from SVN (Cthugha, revision 9548 - the one tested by me few moments ago, and the one that I patched to remove Carbon related code):
svn co https://svn.ogre3d.org/svnroot/ogre/branches/v1-7@9548 cthugha
4. Apply x86_64 patch (attached to this report):
cd cthugha
patch -p0 <../x86_64.patch
5. Make build directory:
mkdir ../build-cthugha
cd ../build-cthugha
6. Run CMake here:
cmake-gui ../cthugha
7. Click Configure
8. Change following settings from their default:
CMAKE_BUILD_TYPE = Debug
CMAKE_OSX_ARCHITECTURES = x86_64
OGRE_CONFIG_THREADS = 0
OGRE_USE_BOOST = false (uncheck)
9. Click Configure and then click Generate, select Xcode as generator, then next next next etc.
10. Close CMake and run from within build-cthugha:
open OGRE.xcodeproj
11. Build OgreMain target
EXPECTED RESUlTS:
Properly linked Ogre.framework
ACTUAL RESULTS
After compiling all files, linking results in following error:
ld: codegen problem, can't use rel32 to external symbol std::basic_ostream<char, std::char_traits<char> >&
std::endl<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&)in Ogre::operator<<(std::basic_ostream<char, std::char_traits<char> >&, Ogre::ConvexBody const&)from /Users/endru/work/ogre3d/builds/cthugha/lib/OGRE.build/Debug/OgreMain.build/Objects-normal/x86_64/OgreConvexBody.o
REGRESSIONS:
GCC 4.0 properly generates code that is linked without any problems for x86_64 target
NOTES:
I was able to investigate the problem to degree that I know why there is linking error there.
Comparing ASM output from GCC 4.0 and GCC 4.2, both targetting x86_64 arch, there is a difference in a symbol reference to std::endl, namely GCC 4.0 produces:
movq __ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_@GOTPCREL(%rip), %rsi
while GCC 4.2 produces:
leaq __ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_(%rip), %rsi
The code samples I was throwing at GCC 4.2 using the same setup (CMake generating Xcode project), but for one C++ file generated code similar to GCC 4.0 with @GOTPCREL at the end of a symbol. My best guess is that this is GCC 4.2 codegen bug triggered by huge precompiled header and basicly huge piece of code to compile, unable to reproduce with small samples. Also, the __ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_ symbol (std::endl) is the only one there is problem with.
- Attachments
-
- osx-x86_64.zip
- Mac OS X 64-bit patch
- (1.28 KiB) Downloaded 134 times
-
- Gnoblar
- Posts: 10
- Joined: Wed Dec 09, 2009 1:05 pm
Re: Ogre 64 bits
Thanks, guyver6, that's exactly what I'm currently tearing my hair out over.
Compiled 64-bit OSX10.5/6 dependencies would be really useful to have, if you can put them up - apparently 'configure' under Snow Leopard gets confused by something and by default sets itself to i386, not x86_64. I still haven't quite worked these out, and messing around with the time-consuming make process in Ogre is tiring.
Compiled 64-bit OSX10.5/6 dependencies would be really useful to have, if you can put them up - apparently 'configure' under Snow Leopard gets confused by something and by default sets itself to i386, not x86_64. I still haven't quite worked these out, and messing around with the time-consuming make process in Ogre is tiring.
- sinbad
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
- Contact:
Re: Ogre 64 bits
This is because of this section in CMakeList.txt in the root folder:gapgen wrote:apparently 'configure' under Snow Leopard gets confused by something and by default sets itself to i386, not x86_64.
Code: Select all
# 10.6 sets x86_64 as the default architecture.
# Because Carbon isn't supported on 64-bit and we still need it, force the architectures to ppc and i386
if(CMAKE_OSX_DEPLOYMENT_TARGET STREQUAL "10.6")
set(CMAKE_OSX_ARCHITECTURES "ppc i386")
endif()
[edit]nm, I see you just commented out the Carbon bits so presumably this was just a build test and not a runtime test. So we'd still need to become pure Cocoa-based to support x86_64 on OS X.
-
- Gnoblar
- Posts: 10
- Joined: Wed Dec 09, 2009 1:05 pm
Re: Ogre 64 bits
Yes, commented out the ppc i386 line and made sure there were no references to i386 in the CMake products before running "make". I dodged the infinite cmake loop by following the instructions in the relevant thread on this forum and then altering the CMake products again, although this is probably error-prone in itself.
I'd prefer to use x86_64 as my intended application is memory-intensive and I don't particularly need to use Carbon unless it's integral to the way Ogre works on Mac OS. The same problem with "configure" exists for building the dependencies, as I understand it. Ogre is reporting architecture differences with zzlib, freetype and boost even after recompiling under Snow Leopard. Fiddling with the compile settings hasn't (yet) made the problem go away, although I'm kinda fumbling in the dark as I'm not particularly an expert on Unix or the intricacies of Mac OS.
I'd prefer to use x86_64 as my intended application is memory-intensive and I don't particularly need to use Carbon unless it's integral to the way Ogre works on Mac OS. The same problem with "configure" exists for building the dependencies, as I understand it. Ogre is reporting architecture differences with zzlib, freetype and boost even after recompiling under Snow Leopard. Fiddling with the compile settings hasn't (yet) made the problem go away, although I'm kinda fumbling in the dark as I'm not particularly an expert on Unix or the intricacies of Mac OS.
- guyver6
- Greenskin
- Posts: 106
- Joined: Mon Dec 23, 2002 10:16 pm
- Location: Warsaw, Poland
Re: Ogre 64 bits
@gapgen: Here are the dependencies (freetype, freeimage and zziplib) compiled for Snow Leopard-like architectures (i386, x86_64 and ppc). Boost is building just fine for universal binary (I build it with "bjam --layout=system architecture=combined address-model=32_64 stage"), NVIDIA Cg 2.2 requires some manual installation but includes these architectures already (you have to dig into the mounted DMG like this: "cd /Volumes/Cg-2.2.0010/Cg-2.2.0010.app/Contents/Resources/Installer\ Items/", then there is NVIDIA_Cg.tgz file that you have to untar in root to install Cg on Snow Leopard). OIS is still using legacy event management from Carbon and I hadn't time to dig into that hole yet.
Ogre 3D OSX Dependnecies for 3 architectures (i386 ppc and x86_64) (I had to use rapidshare, since it's too large for forum)
For now the workaround for compiler bug is to use GCC 4.0 while targetting 10.5 or 10.6 SDK.
Oh, and forcing the compiler version in CMakeLists puts CMake into infinite loop when using Makefile generator, but you know that already (took me a day to figure out )... oh, I just realized that I haven't tested the GCC 4.2 using Makefiles... hmm, lets see...
Ogre 3D OSX Dependnecies for 3 architectures (i386 ppc and x86_64) (I had to use rapidshare, since it's too large for forum)
For now the workaround for compiler bug is to use GCC 4.0 while targetting 10.5 or 10.6 SDK.
Oh, and forcing the compiler version in CMakeLists puts CMake into infinite loop when using Makefile generator, but you know that already (took me a day to figure out )... oh, I just realized that I haven't tested the GCC 4.2 using Makefiles... hmm, lets see...
- guyver6
- Greenskin
- Posts: 106
- Joined: Mon Dec 23, 2002 10:16 pm
- Location: Warsaw, Poland
Re: Ogre 64 bits
I'm noob in that land too, so don't mind my quick hack I'm trying to understand the whole idea behind the run loops in OSX and how Carbon requires totally different approach when handling events than Cocoa, maybe if my mind wraps that I'll submit a better patch. That compiler bug put me off for a while, because I've wasted lots of time on it (I thought Apple did better with their GCC version, but it seems that Apple's investing more compiler developers time in Clang / LLVM than good old GCC).sinbad wrote:I'm still a total noob on Carbon / Cocoa but does this mean that we're Carbon-free now, if you managed to build x86_64? masterfalcon?
[edit]nm, I see you just commented out the Carbon bits so presumably this was just a build test and not a runtime test. So we'd still need to become pure Cocoa-based to support x86_64 on OS X.
-
- Gnoblar
- Posts: 10
- Joined: Wed Dec 09, 2009 1:05 pm
Re: Ogre 64 bits
Thanks! I'll give those dependencies a go.
-
- Gnoblar
- Posts: 11
- Joined: Tue Jan 19, 2010 2:09 am
Re: Ogre 64 bits
Hey guys !
This is the first time I try recompiling librairies for 64 bits OS, anyone would be kind enough to give me an how-to guide ?
(Using Windows 7 x64 with Visual Studios 2008)
Thanks !
-Shredder
This is the first time I try recompiling librairies for 64 bits OS, anyone would be kind enough to give me an how-to guide ?
(Using Windows 7 x64 with Visual Studios 2008)
Thanks !
-Shredder
-
- Gnoblar
- Posts: 19
- Joined: Tue Mar 16, 2004 8:43 am
- Contact:
Re: Ogre 64 bits
guyver, where did you submit that bug report, and do you know if there's been any action taken on it?guyver6 wrote:Hi,
I was trying to get Ogre3D working on Snow Leopard in 64 bits. I got compiled needed dependencies (except OIS of course ), patched Ogre a little (patch against v1_7 branch attached), and... I hit a compiler error. I'm using GCC 4.2, as it is supported for 10.5+ SDKs (and I've tried building against 10.5 and 10.6 and the result is the same - linking error due to bad code generation from GCC 4.2). Anyway, I even filed a bug with Apple's radar about the issue. The exact error is like this:It happens during linking only, and the problem is std::endl symbol referenced in OgreConvexBody (and in some more files actually; if you generate asm using -S GCC option instead of -c, you're able to fix the mis-compilation of OgreConvexBody and the rest of std::endl users and it links without problems). The workaround is to use GCC 4.0 (and get suboptimal performance on x86_64, since in GCC 4.2 there were a lot of optimizations dedicated to that architecute).Code: Select all
ld: codegen problem, can't use rel32 to external symbol std::basic_ostream<char, std::char_traits<char> >& std::endl<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&)in Ogre::operator<<(std::basic_ostream<char, std::char_traits<char> >&, Ogre::ConvexBody const&)from /Users/endru/work/ogre3d/builds/cthugha/lib/OGRE.build/Debug/OgreMain.build/Objects-normal/x86_64/OgreConvexBody.o
So, this is just an informational post if someone tries and dies trying to do the same. Oh, and the patch might be useful (it turns off Carbon for __LP64__ compilations).
PS. Maybe someone is interested in the bug report, so it's radar number is 7511396, and here it is quoted:SUMMARY:
Unable to link Ogre3D using GCC 4.2 targetting x86_64 due to badly generated asm code.
STEPS TO REPRODUCE:
Excuse the long list of steps needed to reproduce, but I couldn't get smaller samples to reproduce the same error. Here it goes:
1. Install Ogre3D dependencies (you need to provide 64-bit versions of those, I'll attach these if radar allows me to): Freetype, FreeImage, Cg-2.2 (from NVidia, you'll need to untar to root directory the NVIDIA_Cg.tgz file included in the DMG you download from NVidia, because it fails to install on Snow Leopard) and zziplib. These are enough to reproduce bug.
2. Install CMake
3. Fetch Ogre3D from SVN (Cthugha, revision 9548 - the one tested by me few moments ago, and the one that I patched to remove Carbon related code):
svn co https://svn.ogre3d.org/svnroot/ogre/branches/v1-7@9548 cthugha
4. Apply x86_64 patch (attached to this report):
cd cthugha
patch -p0 <../x86_64.patch
5. Make build directory:
mkdir ../build-cthugha
cd ../build-cthugha
6. Run CMake here:
cmake-gui ../cthugha
7. Click Configure
8. Change following settings from their default:
CMAKE_BUILD_TYPE = Debug
CMAKE_OSX_ARCHITECTURES = x86_64
OGRE_CONFIG_THREADS = 0
OGRE_USE_BOOST = false (uncheck)
9. Click Configure and then click Generate, select Xcode as generator, then next next next etc.
10. Close CMake and run from within build-cthugha:
open OGRE.xcodeproj
11. Build OgreMain target
EXPECTED RESUlTS:
Properly linked Ogre.framework
ACTUAL RESULTS
After compiling all files, linking results in following error:
ld: codegen problem, can't use rel32 to external symbol std::basic_ostream<char, std::char_traits<char> >&
std::endl<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&)in Ogre::operator<<(std::basic_ostream<char, std::char_traits<char> >&, Ogre::ConvexBody const&)from /Users/endru/work/ogre3d/builds/cthugha/lib/OGRE.build/Debug/OgreMain.build/Objects-normal/x86_64/OgreConvexBody.o
REGRESSIONS:
GCC 4.0 properly generates code that is linked without any problems for x86_64 target
NOTES:
I was able to investigate the problem to degree that I know why there is linking error there.
Comparing ASM output from GCC 4.0 and GCC 4.2, both targetting x86_64 arch, there is a difference in a symbol reference to std::endl, namely GCC 4.0 produces:
movq __ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_@GOTPCREL(%rip), %rsi
while GCC 4.2 produces:
leaq __ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_(%rip), %rsi
The code samples I was throwing at GCC 4.2 using the same setup (CMake generating Xcode project), but for one C++ file generated code similar to GCC 4.0 with @GOTPCREL at the end of a symbol. My best guess is that this is GCC 4.2 codegen bug triggered by huge precompiled header and basicly huge piece of code to compile, unable to reproduce with small samples. Also, the __ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_ symbol (std::endl) is the only one there is problem with.
- danfma
- Gnoblar
- Posts: 2
- Joined: Thu Apr 08, 2010 10:45 pm
- Location: Goiania - GO / Brazil
- Contact:
Re: Ogre 64 bits
Guyver6, you are the man!! hehe...
I will try the code as soon as I can...
I will try the code as soon as I can...
- guyver6
- Greenskin
- Posts: 106
- Joined: Mon Dec 23, 2002 10:16 pm
- Location: Warsaw, Poland
Re: Ogre 64 bits
Sorry I answer with such a delay, haven't notice the question. I reported it to Apple's radar (http://bugreport.apple.com/), but they haven't tacked it yet (if they ever will). The Radar #7511396.TV4Fun wrote:guyver, where did you submit that bug report, and do you know if there's been any action taken on it?