Final checks (World's longest post!)
by darren john (dj2007)
on
Aug 20, 2008 at 5:57:35 pm
Howdy there guys,
Apologies in advance for the extra long post! But your advice would be greatly appreciated.
You might want to grab a coffee by the way! Here goes...
Been working on a massive project for the past year – an interactive DVD-Rom for PC’s only - and everything is almost ready for duplication. And since thousands of copies will be duplicated, there is simply no room for errors etc.
However, one thing that seems to be highlighted most often from the client’s feedback is that of the DVD-Rom crashing occasionally, either with and/or without errors messages.
The project itself is huge (it includes literally hundreds of videos, PDF/Word resources, high res images etc) and although a large effort has been made to reduce the file sizes (using separate linked movies, videos compressed as far as possible, images optimized etc) the final size of the entire DVD-Rom project is just under 2GB. Hence why it is a DVD-Rom as opposed to a CD-Rom. This in itself is enough to be fairly sure that the reason the project crashes occasionally is due to its sheer size and the end users PC spec not meeting the minimum system requirements.
On the other hand, the error messages are the most worrying. They seem to be system errors from the users PC – see below for more detail on the errors - but nonetheless still worrying. We have tested the DVD-Rom on numerous high and low spec PC systems, and all seems sufficient with no actual system errors as such. They seem to happen more at the clients end, as they also do some testing at their end on various PCs and laptops although I can’t be sure if the above errors are from the SAME testing PC but I will find out.
So basically I’m starting to wonder if it is even possible to have a project of this size to play seamlessly on all PC's and laptops? Nothing in life is guaranteed and I am aware that some things are simply beyond our control. However I would like to hear what you guys think, maybe provide some advice from your experiences on getting a project duplication-ready etc.
For your reference, the error messages in question are presented in more detail below:
Error example 1:
Macromedia Projector - Macromedia Projector has encountered a problem and needs to close. We are sorry for the inconvenience.
Please tell Microsoft about this problem…etc.
Error example 2:
PROXY: Tray Icon - PROXY: Tray Icon has encountered a problem and needs to close. We are sorry for the inconvenience.
Funnily enough, the above errors seem to have appeared recently, on the latest prototype sent over to the client, but there are too many factors that could be causing this such as that the client could be using a different PC to test this prototype than that used to test the previous prototypes etc but I’m also concerned that something else could be causing the issues - either some settings on my own PC where the DVD-Rom was built have been changed, my Director MX 2004 software has become corrupted or some other unknown cause although I cant think of anything and besides, the project seems to work perfectly on my own system as well as others that I have tested it on so the error doesn’t seem to be consistent.
As you can see from above, these errors are not your usual Director "Script errors" as these have and are still being ironed out. They seem to be system errors from the users end depending on their PC settings, or am I wrong?
Again, would really appreciate your advice and your experience’s on getting a project of this size duplication-ready etc.
And of course, any solutions, if any, to the above errors would also be very welcome! Although according to my trusty research, it seems a little tweak here and there is required on the users own PC in order required to resolve such errors like these. But please correct/advise me if I’m wrong.
Re: Final checks (World's longest post!) by Brodd Nesset on Aug 21, 2008 at 7:41:25 am
Well, one thing that will vary across user's machines is memory fragmentation. Also poor graphic card drivers is a known source for erratic behavior. Sorry I have no 'magic wand' trick to solve these issues.
Her lips said "no!" but her eyes said "read my lips".
Re: Final checks (World's longest post!) by darren john on Aug 21, 2008 at 4:53:24 pm
A magic wand would certainly come in useful!
Thanks for the response, it's appreciated.
Still looking into the possible causes and so far there is no light at the end of the tunnel. It does seem to be the PC that the project is running on that is causing the issues as opposed to the project itself but nonetheless still need to find out for sure and thought I'd post and see if its happened to any others and if so, learn from your experiences.
I have sent some instructions to the clients requesting them to carry out some checks in order to try isolate the problem so just awaiting some further feedback about this.
In the meantime, if anyone has further advice etc it would be welcome!
Re: Final checks (World's longest post!) by Brodd Nesset on Aug 26, 2008 at 7:18:11 am
Hello! Hope this isn't too late for your project. I consulted a Rosenzweig book, and in the paragraphs regarding memory management there might be some interesting options to try out. Just might, because in general the automatic memory management in Director is pretty good. Director will preload members that it 'sees' in the score, and unload when reaching a memory limit. Sometimes this preloading isn't fast enough (for instance when a member isn't physically tied to a sprite in the Score - it is loaded by Lingo), sometimes 'silent' unloading isn't enough doe to other apps competing for the memory perhaps. Both circumstances could lead to at least hickups in performance, and potentially to crashes too.
preLoadMember "mymember1", "mymember2" will preload those members.
preLoad will preload the entire current movie, or a given number of frames.
There is also preLoadMovie "myMovie" which indeed preload a new movie into memory, allowing for a smooth transition.
unLoadMember, unLoad, unLoadMovie does the opposite. An example of how Lingo simplicity and effectiveness shines :-D
How much available memory do you have? Use freeBytes() How much do you need for a given set of frames? Use ramNeeded(1,50) for the memory needed to play frames 1 - 50.
For the memory size of a specific member use member("myMember").size.
You can then of course compare this with 'freeBytes()'.
Note that if any of these exceeds 'freeBytes()', your app will not play as intended, or at all. Now, in today's modern computers there's usually ample memory, but: Director members actually needs contiguous memory to display. That is: a 100 mB video will not play on a computer with heavy fragmented memory, even if the total RAM is, say 2 gB! You can test for this with freeBlock() which will return the size of the largest chunk available.
If 'freebytes()' or 'freeBlock()' is exceeded, you should concider throwing a warning message, like
alert "The application have encountered a memory problem which will affect performance. This application will likely perform better if you close other programs running and even restart your computer."
Hope this can be useful. Cheers!
Her lips said "no!" but her eyes said "read my lips".
Re: Final checks (World's longest post!) by darren john on Aug 26, 2008 at 10:47:44 am
Howdy there! It's never too late to hear any tips and advice from you guys!
Very interesting tips and scripts, I currently use the preLoadMember but I might just try out those other ones ; )
Also had another bit of a breakthrough where I now simply load any media files into the project via external dummy media. Here is a breakdown, quoted from Irv Kalb at director-online, for anyone that isn't sure how the dummy media functions:
QUOTE:
Regarding the dummy media, here's the idea. Imagine that you have all your photos stored externally in a folder called "photos" which is at the same level as your movie. For simplicity, let's say that you have A.jpg, B.jpg, C,jpg, etc. in that folder. In that photos folder, create an additional picture called "dummy.jpg", and have it consist of a single black pixel.
Now, in Director, you create a single bitmap cast member, give it a name (let's call it "PhotoToShow"). In the properties for this member, you set the "linked" option. This says, this member will always be linked to some external media (file). By default, set the linkage to the dummy.jpg so it links to the smallest possible file (one pixel).
In your program, when you are ready to display a picture from your photos folder, you set the "filename" property. So to show a different picture, you do this:
delimChar = the last char of the moviePath -- or just "" is this is PC only
member("PhotoToShow").filename = the moviePath & "photos" & delimChar & This changes the linkage from the one member in the cast to whatever picture you want to show. Using this approach, your Director program will only take up memory for the largest picture you are showing.
UNQUOTE
I've now implemented this approach to hopefully improve memory usage and this coupled with PreLoadMember and a few other of those scripts, Brodd, might just solve any issues I'm having : ) so fingers crossed!
Re: Final checks (World's longest post!) by Brodd Nesset on Aug 26, 2008 at 11:01:26 am
Great to hear Darren! Good tip you picked up and passed on there too.
In my previous post I used a large video as an example of a large castmember (100 mB needs 100 mB memory), but video is actually an exception to this rule. Since the early days Director has been able to play huge videos on rather low memory computers, like 100 mB video on a 64 mB computer (which was a pretty well specced machine back in the days), with streaming. For video I'd rather be concerned about unLoadMember; i.e. free up the memory a certain video have used the sooner the better.
I think manual preloading can be smart for letting your app run (even) smoother, accessing the disc in good time before switching videos for instance. Otherwise such stops could cause some problems and even crashes on less robust computers.
Her lips said "no!" but her eyes said "read my lips".
Re: Final checks (World's longest post!) by darren john on Aug 26, 2008 at 11:32:49 am
Excellent, thanks for the extra input. I'm thinking the unLoadMember could well be an important piece of lingo to counter-attack what the preLoadMember statement does so I'll focus on that ; )
Don't you just love Director huh!
One thing I forgot to add, for anyone interested, is that ideally you should have some "stopMovie" code that resets all such linked members back to point to their dummy file(s) and it might help if you have an unload() statement if your project is structured in a way that there are multiple director movies (like mine) and the unload() should also free up memory when moving from one director movie to the other.
Re: Final checks (World's longest post!) by darren john on Aug 26, 2008 at 6:19:18 pm
Guys,
Got another slight problem - printing!
I use both BuddyAPI (to print word and pdf files) and PrintOMatic lite (to print bitmap files).
All was fine, that is until I decided to use a dummy media to import the bitmaps from an external folder into the movie cast (when required) and then printing the castlib with the newly imported bitmap files from there.
See my previous post for more about the dummy media, above.
The images that I need to print are high res JPEG images and there are about 50 of them altogether and the total file size of the images only is roughly 40MB. (I can't reduce the image sizes etc as these are to be used as printable resources on the project disc for the end users.)
If I import the images directly into a cast member in my movie, it adds a good 100MB/200MB or more to my movie file size so I thought it would be a better idea to use the dummy media to import the images only when required, in this case, only when the user wants to print them.
However, using the dummy media causes the projector crash, which I think is understandable as the images being imported are high res and large file sizes and thus seem to cause a memory overload and director displays a "Fatal error. Director needs to close" message.
So basically I'm wondering if there is an easier way of printing the images, such as printing them DIRECTLY from the folder they are located in (which is external to the director movie)? If so, this would prevent the need to import the images directly into the cast or via the dummy media and hence preventing memory overload and the projector crashing. That's the theory anyway.
Or maybe there is a better, easier way?
Please let me know, would appreciate if any of you guys could help.
The client is also concerned that the images printed directly from the director movie is of a MUCH lower quality than that of printing them directly from the folder that the images are located in (on the DVD-Rom disc). But maybe this is a different matter altogether so I'll just focus on the above issue first! : P
Re: Final checks (World's longest post!) by Brodd Nesset on Aug 27, 2008 at 10:39:32 am
Printing in Flash is much better (another arrgh! Why they haven't updated printing in Director for so long?), but I'm not sure if it's good enough for your purpose. Nevertheless I managed to print out some crispy graphics via an imported .swf set to print a linked image in much better quality than straight from the Stage, which (a screen dump) is what Director can print. Print-o-matic should be able to offer much better quality than that, but I'm no expert at all on using it. Perhaps you could use Buddy API to send your image straight to your printer too.
Her lips said "no!" but her eyes said "read my lips".
Re: Final checks (World's longest post!) by darren john on Aug 28, 2008 at 5:37:03 pm
Sorry for the delay, been snowed under at work! Finally got a chance to respond...
Yeah printing with Director is the only thing I hate about it, surely there must be easier ways! Still, we're stuck with the limitations for now! Unless the new release, Director 11, has improved printing capabilities? (Note to self: must investigate...!)
Anyway drifted off from my point there!
I had thought about using flash, but there are roughly 50 high res images that need to be printed at the same time via a single button hence the information overload, it seems, but the method that seems to use less memory is a simple linking to external file option where the high res images are linked rather than imported directly into the movie and this seems to be more consistent and uses less memory, not to mention reducing the movie file size greatly (by a few hundred MBs).
Since we are on the topic of printing I would like to expand on this - might come in useful for others -
the client also mentioned numerous times that in addition to the printing issues discussed above, printing the actual movie stage (there is a button on the stage to allow them to do this using a simple printStage command from PrintOmatic Lite) resulted in odd prints, namely when printed in black and white and thus resulted in a dramatic loss of quality with just a few identifiable lines/shapes here and there. Now...anyone can see that printing in black and white will obviously result in some detail being lost but to only print very vague lines etc seems a bit extreme (as this doesn't happen on my own printer) and I'm thinking this is a printer/hardware issue at their end.
You said you got good results using flash to print from the stage - but would this have any effect on the printed result itself, whether its printed in colour or black/white? I would presume that flash is just a better way of sending the data to the printer?
See also a quote below from client for your reference (ignore the doc references):
QUOTE:
Doc 1 shows the selected screen and subsequent menu options on selecting the print button on the DVD interface. The screen prints fine on the colour printer connected to X's computer. However, whatever settings are selected on X's black-and-white printer, the resulting print always bitmaps and prints in line only (as the example emailed previously).
Doc 2 shows a print screen, this time pasted into MS Word (plus another screen to show the relevant printer settings). When this print screen is printed from MS Word, it prints in greyscale, ie it prints OK.
Hope this will help you to identify and resolve the problem. To me this suggests that the button on the DVD interface is not capturing and/or sending the data to the printer correctly.
UNQUOTE
What do you guys reckon? Printer/hardware problem? Director printing problem? How much control can Director really have over the end users printer settings?
It would be good to be accurate in updating the client on what can or cannot be done from Director. One can't say that it is a printer/hardware issue if it 100% isn't.
Re: Final checks (World's longest post!) by Brodd Nesset on Aug 29, 2008 at 6:47:56 am
Printing from Flash is a screendump of the Stage too, but it just seems crisper to me. As if Director prints at 72 dpi, but you get say 120 or 150 dpi when using Flash. With anti-aliased text this makes a difference - it's much smoother, but still not like printing from Word.
On a stage with video, the video member must temporarily be DTS (DirectToStage) off, or it won't print at all (you'll get a black square). Printing a Stage like that can be done more predictable by taking a snapshot of it, storing it as a new member, and then print that member.
member("currentVideo").directToStage = false
myImage = window("stage").image
member("image2print").image = myImage --That member must be created in advance!
Print "image2print" --Your printing routine here
member("currentVideo").directToStage = true
...something like this.
Her lips said "no!" but her eyes said "read my lips".
Re: Final checks (World's longest post!) by darren john on Aug 29, 2008 at 5:17:39 pm
Thanks for that mate, tweaked it and tried it just there and seems to work perfectly. Now for some testing to see if it makes a difference to the print out issue!
