E-mail just sent. It's a frame with 3 circles drawn. A green one in the upper left hand was drawn first. then a blue circle in the middle and finally a red circle at the bottom right. It was reported as being 144 points. Upon exporting it and giving it the name "3 circles.ild" it reported 147 points. I then tried to import it into cue spaces in both Beyond and Quickshow and the only thing that shows up is the green circle in the upper left.
This just gets stranger and stranger. I tried opening the file in three different viewers, and as you can see they all read it correctly: http://i.imgur.com/6VP1WFn.png
I also opened the file in a hex reader and manually inspected it for anomalies.. I found none.. From what I can tell there is no reason for any reader not to show all three circles. But I do not own quickshow or beyond so I cannot test. I don't mean to shift the blame, but are you positive this is not caused by those programs? Like maybe the rest of the frame is being blanked by some active effect or something. Are quickshow or beyond able to display all points in the frame, even blanked or black ones? If so maybe try that and it might bring some insight. What are cue spaces by the way?
Hello,
In Quickshow:
Select the cue
Right click and select "Edit Frame/Animation..."
In Editor, click View and select Show Blanking
If you or Brad can post the .ild file, I will take a look at it too. I can also check Beyond.
ED
Aha! I found it, it was a bug after all. The frame ending bit was set high after each object rather than at the actual end of frame only. Can't believe I didn't catch that. The reason it works everywhere else is probably because the ILDA standard says the frame ending bit is only there for backwards compatibility, it should not take priority over the "number of points in frame" word, which was working normally.
I've compiled a hotfix: zip download
Let me know if that did the trick
I believe Laserboy even ignores the number of points entry and just looks for ILDA000 occurencies. The chances of that randomly occuring in a frame are 1/(256^7) anyway. (It's the same method I use for all my own programs as well).
Weird that a program like Quickshow still uses the end of frame bit. It's not 1995 anymore...
example4.ild Sadly, I don't know that it did. Here is a similar file created and saved as example4.ild
Maybe it does have to do with trying to open an ILDA file in either Quickshow or BEYOND.
Oh, and I tried Ed's suggestion and it didn't reveal anything else but the first green circle.
I see the problem, the end of frame bit is still high.. Even though I thought I just fixed the problem, and sure enough the hotfix seems to work for me.. Are you sure you are running the right .exe? Try downloading the hotfix again
It is supposed to be only one frame though, I don't think that is the issue. There are different circles in the same frame.