1 Reply Latest reply on Sep 20, 2010 7:56 AM by Octahedra

    Shockwave player updates: graphics card compatibility problems?

    Octahedra Level 1

      I've recently had a new problem reported to me in the Driveway Visualiser, a piece of Shockwave 3D content that I've been maintaining since we built it in 2008.  I'm wondering if  recent updates to the Shockwave Plugin (e.g. may be contributing to this...



      So I'd be interested to know if anyone else has had any new problems affecting old content. I tried reverting the dcr file to last year's version but the same problem still occurs, so it doesn't seem to be a recently-added bug in my code.  I think it could be either a compatibility problem between the graphics card and the plugin, or between the Director 11.0 dcr and the Shockwave 11.5 web player.


      Because we need the DirectImage Xtra, it's Windows only.  For  each different computer that we've tested, the Driveway Visualiser (DV) will either always  work or always fail on that machine - regardless of whether IE or  Firefox is used.  All the test machines have DirectX 9.0c; all are  running Win XP SP3 apart from one laptop with SP2 and Intel 965 chipset  on which the DV fails.  Only one has Director (11.0) installed, and on  that the DV always works.  The problem is much more common on laptops,  so we reckon that Shockwave's ability to interface with the various  graphics cards might be the reason why it's not getting the image  property of a 3D cast member.

      So here's what's actually happening:

      When you get to step 4 of the DV, after you've drawn round the shape of your driveway, it tries
      to grab the image of a 3D cast member referred to by the  variable gWorldMember, and fails with the "four parameters expected" error message, on  this line of code...

            zoomAfterImage.copyPixels(gWorldMember.image, zoomAfterImage.rect, gWorldMember.image.rect)

      gWorldMember.image is being returned as <image:0> (not a usuable  image) and so its rect property does not exist, hence the crash.  This  line of code crashes whether or not there's a sprite of the relevant 3D  member on the stage at the time.  The member's defaultRect has been  temporarily changed so we can grab a 1024x1024 image off it.  Using  copyPixels, this image is resized down to the size of the zoomAfterImage  image variable (again 450x450).  This gives us an image at the original  size of 450x450, but with a softer image quality than if we'd grabbed  it from the 3D member at that size.


      Is anyone suffering similar problems or aware of what Adobe has been changing in the player?  At the moment I just don't see how I can fix this by changing my code...