822096128 errors reported on compile, yet runs fine in Bug Reports

ID:65015
 
Apr 20 2009, 4:59 pm
Resolved
Fixed in 443
BYOND Version:440
Operating System:Windows XP Home
Web Browser:
Status: Resolved (443)
This issue has been resolved.
I imported a very large gif file into a .dmi for use as an opening movie in Vengeance 56. The gif itself is about 10MB in size. Anyway, when I set the dmi as the icon for a given object, DM reports 822096128 errors. If I set the icon var to something else (i.e. no existing references to the dmi movie), no errors are reported. Despite the errors, I'm able to run the game, and it seems to run just fine.

If necessary, I could make a demo later.

edit: I forgot to mention that it cut the movie off at 98 frames (out of about 350 total). It has dimensions of 320X256.
#1 Jun 29 2009, 8:06 pm
Semi-verified on Windows XP Home SP3 running BYOND 442.1020

After importing a lengthy GIF into a DMI file, when that DMI is used in the code, the first time the DMI is consequently compiled into the resources it will report a large number of errors (49 or 3211313 errors in my test) without actually listing any, but will otherwise compile as expected. If you simply compile it again (as it happens only the first time) the errors will disappear.

It seems to based solely on the number of frames in the gif (and thus the number of frames in the .dmi). In my tests, I found these conditions:

Less than 267 Frames: 0 Errors
Exactly 267 Frames: 49 Errors
More than 267 Frames: 3211313 Errors

These appeared to occur consistently regardless of changes in GIF dimensions, bit depth, or file size.

However, results varied slightly when I tried including the DMI in different projects. The number of errors specific to each frame count remained the same, but sometimes compiling a second time would result in DM crashing.

What I am experiencing seems related to Gakumerasara's bug. Neither are really a high-priority (especially since DMIs are only supposed to be 99 frames, which might be the only bug worth fixing in this report)

Here is a test environment I set up:
Long Gif Bug.zip
And here is the GIF I started with:
Swimming Lessons
#2 Jun 30 2009, 12:41 am
why import a gif into a dmi, why not just use the gif directly?
#3 Jun 30 2009, 2:43 am
Looks like it's running into memory corruption and the var that stores the errors is just getting overwritten with garbage. I noticed that the DMI is not accepted as a valid PNG in my paint program, so that's likely the problem. I'm surprised it works on the client. I'm sure we can fix this and the 98 frame limitation (which is probably related).

How did you generate the DMI from the GIF?

Thanks for the helpful demo/report. Keep em coming.
#4 Jun 30 2009, 8:20 am (Edited on Jun 30 2009, 8:28 am)
Tom wrote:
Looks like it's running into memory corruption and the var that stores the errors is just getting overwritten with garbage. I noticed that the DMI is not accepted as a valid PNG in my paint program, so that's likely the problem. I'm surprised it works on the client.

GIMP opens the DMIs for me without a problem. MS Paint doesn't want to open it, though.

I'm sure we can fix this and the 98 frame limitation (which is probably related).

I think the frame limitation stems from the icon editor only allowing 99 frames (in fact, if you open one of the DMIs and open the movie state, it won't let you back out of it until you lower the frames to 99). I think import should be clipping or splitting the animation to the maximum number of frames the editor allows, and it seems probable this is happening at runtime or compile time instead*. Of course, I don't think anyone would complain if you want to increase the maximum number ;)

How did you generate the DMI from the GIF?

I created a new DMI file, and then used Graphic > Import to import the GIF, then saved.

Thanks for the helpful demo/report. Keep em coming.

Glad to help :)

*I was unable to reproduce this part of the report. I just tested it, and all of my test animations play through their entirety.
#5 Jun 30 2009, 7:48 pm
The frame-count has also been bumped to 999 in the editor.