Furry stuff, oekaki stuff, and other stuff.
You are not logged in.
I visited some others Wacintaki 1.5.6 oekaki boards and I noticed we have all the same problem.
It's since we upgraded to 1.5.6, there is sometimes, a problem with the animation, it stops loading at a point and even on refreshing the page there is still the problem. And it's not only with new pictures, old picutres who had no problem before have now the same problem.
For exemple this recent picture has the animation problem: http://www.poketerra.net/oekaki/viewani.php?recno=8857
And this old picture from 2008 has it too: http://www.poketerra.net/oekaki/viewani.php?recno=1
Hoping the problem will be solved soon, Dragon_red.
The 1.5.6 update didn't change the animation viewer, so I'm pretty sure that's not the problem.
After a few years of trying to track down this issue, I finally came across some new information. Apparently, some Java developers are having problems with Java decompressing files compressed with the ZIP method. Sure enough, when I try to view the animation files on your board (and some on my board as well), the Java console is throwing "incorrect data chunk" errors. Only some broken animations are throwing that Java exception. I will have to look into this further, because this might be the reason why both ShiPainter and ChibiPaint are having problems with their resource files. If they both use ZIP, then the problem may be with Java.
I don't have the source code to ShiPainter or the PCH Viewer, so there's nothing I can do with those applets. However, there might be something I can do to fix ChibiPaint.
This isn't the first time a Java bug has caused headaches. I still have nightmares over the SocketPermission errors. That one drove me nuts for over 3 years before Sun finally admit it was a bug in Java and fixed it.
The good news is that apparently, Java only has problems decompressing files, so the original animations should be fine, so long as they are not retouched.
I've decompiled ShiPainter and the PCHViewer, and am looking at the code that compresses and decompresses animations. It appears that ShiPainter compresses animations in chunks of 65000 bytes, and uses a chunk marker to describe the size of each compressed chunk. Apparently, this is done so animations can be streamed. What doesn't make sense is how the animations are loaded for playback, because ShiPainter and PCHViewer use different techniques, but they both have the same playback issues, and both choke at the same point in a broken animation. So far, it really does look like a bug in Java, but I'm not a Java guy, so I'm not sure how all these bytestream buffers work, and it's possible that ShiPainter is just doing something weird. Also, ShiPainter uses a hashtable to read in the animation playback parameters, but the playback code doesn't seem to skip the parameters. I'm having trouble figuring out how the player knows what is compressed and what isn't. Maybe when the animation is parsed by the hash handler, the hash is automatically chopped off.
Even if I find a problem, though, I'm not sure if I can fix it. Neither of my decompilers (TAD and JD-Core) are decompiling the source correctly, so there's errors all over the place and I can't re-compile the code (PaintBBS can be decompiled correctly, though). As for Shi-Chan, his web site disappeared a while ago, and I've been trying to e-mail him for years asking for the source code, with no success.
Next, I'll look at ChibiPaint, because people are reporting problems with the layers file for that applet as well. If ChibiPaint compresses layers using ZIP, that might be why. ChibiPaint is distributed under the GPL license, so I have the source code.
The fix I mentioned has to do with another issue, where the animation viewer would show garbage that looks like a rainbow checkerboard pattern. It is due (once again) to AMD's terrible graphics drivers. Disabling hardware graphics acceleration seems to be the only solution.