I'll look into it
I think it will be due to the fact that it contains Local Color Tables and I've not seen those before and haven't written the code to deal with them.
Back in a few days
When I went to test out how fast it is after the update, I found out that it draws the new frame on top of the other frames. To fix this, I just added
which just resets the image pixels, so it doesn't include other frames pixels. I did remove the wait (1) secs block because that would make it slower.
Can you post the gif that gave you the problem please?
why dont you use flask and pil
also, this gif
doesn't work anymore.
I think I know what the issue is.
The GIF specification has something called disposal method which says how each frame of the GIF should be dealt with and I'm currently ignoring it - I'll add in code to deal with it - thanks for pointing it out
Your top GIF should work now - I've added in code to work with disposal methods 1 & 2 (not done 3 yet but not seen any examples of it so far)
The bottom GIF contains XMP metadata! It looks like it's information not need for simple image decoding - I just need to bypass it but not worked out how yet
I did this in GP as an exercise to show how block programming languages can be used to perform any algorithm that text based ones do.
And also did it as an intellectual challenge to myself on implementing the GIF algorithm
And GP (like Snap!) doesn't have a native GIF file reader, so it's a useful tool.
PIL supports gif editing.
Now copes with the bottom sprite as well
also, btw, the set [ v] <> block in the sensing category has an option to set turbo mode, so it's probably better if you used the primitive block instead of a custom block.
@dardoro Your butterfly GIF should work now
@ego-lay_atman-bay Having now made my script follow the GIF decoding rules - the last frame of your top GIF goes wrong again.
I'll keep looking into it but the data in the file says to treat the last frame differently from all the others (disposal method = 1, all the others = 2 which a decoder should take to make clean frames each time)
When a frame has disposal method 1, the decoder should merge it into the previous frame (at least that's how I interpret the specification)
The thing that make's me think I still haven't quite grasped what to do, is that if I load the file into GIMP - it says the the last frame uses disposal method 2!
But when I examine the bytes myself and check it out with an online tool - the file says to use disposal method 1 so I'm very confused!
[Update 08:38 24Nov20 GMT - I may be onto something - it might be that the disposal method is there to tell the decoder what to do AFTER it's drawn the current frame - I've been treating it as what to do BEFORE drawing the current frame !]
Updated it with new method of clearing pixels (if told to) AFTER the image has been drawn
Seems to cope with all the images in this thread and some other test ones I've picked up
[15:50 24Nov20 GMT - minor tidying up]
Ok, I found proper GIF file, but it's a
little VERY slow....Is it because it is a large GIF file, or is it the project?
the GIF I used:
While making this comment, it is still halfway done on the second costume, and it started converting the GIF file 6 minutes ago
EDIT: Turbo mode helps a little, but it's still slow
(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)
My program is slow
It was an exercise in getting Snap! to do something that is usually done by an optimised library module
I'm sure it can be sped up but someone would probably have to rewrite it from the beginning
The past like 8 posts are off-topic
why are all of their posts flagged and hidden