Closed GoogleCodeExporter closed 9 years ago
From looking at the docs (we have a copy here :
http://code.google.com/p/grafx2/wiki/AtariFileFormats) the format clearly
indicates it's forbidden to encode across lines, but I'm not so sure if it's
also forbidden across the planes for a single line.
The code of Grafx2 seems to have the same restriction on loading and saving.
IMO, if you know of some legitimate PC1 images that GrafX2 can't load, we
should modify the loader to accept them. But even in this case, we should not
modify the saving, because the resulting files can't be loaded in most
PC1-reading programs.
Original comment by yrizoud
on 12 Jul 2013 at 6:30
I realize my description was not very clear. What I meant was that it seems
Grafx2 (version 2.3.1780) DOES encode across lines. (There is nothing wrong
with the loading code in Grafx2). Images created with Grafx2 cannot be loaded
in, for example, Degas Elite on the Atari ST.
The problem can be replicated like this: Save an empty image in Degas Elite
(empty-degaselite.pc1) and load it Grafx2. It works fine. Save it again in
Grafx2 (empty-grafx2.pc1) and load it in Degas Elite. It bombs.
Original comment by magnu...@algonet.se
on 13 Jul 2013 at 2:14
Attachments:
Can you check if these files load correctly now ? I made same tentative changes
that make the files look much more like the Degas Elite's one, though the file
footer stays quite different.
Original comment by yrizoud
on 29 Aug 2013 at 6:18
Attachments:
Wait, I think I'm getting somewhere. XnView is kind enough to choke on every
non-conforming file, and I think I'm starting to underdand the exact constraint.
Original comment by yrizoud
on 29 Aug 2013 at 6:50
I think it's fixed in r2063.
The PC1 document says "Elite uses a 40-byte buffer to store data being
decompressed (...) The buffer is only emptied when there are EXACTLY 40
characters in it.". Grafx2 was merely limiting RLE length to 39 (instead of the
40 it was allowed - the empty file was longer than needed), now it is correctly
ensuring that the commands end at byte 40, 80, 120, etc.
I've tested all the PC1 files here:
http://samples.libav.org/image-samples/atarist/degas/
After re-saving them in Grafx2, XnView can now reload them fine. I attach them
to this post, if you can test them in Degas Elite...?
Original comment by yrizoud
on 29 Aug 2013 at 10:45
Attachments:
About nonempty-grafx2.pci Degas Elite says "That is not a picture file!"
(because it's actually a GIF file). Everything else work as expected. The
palette cycling information (I know is present in the original version of
magicmtn.pc1) is lost. But I assume that is not intended to be preserved. So,
problem solved.
Original comment by magnu...@algonet.se
on 30 Aug 2013 at 3:20
Woops, sorry about the GIF. I just implemented the palette cycling for this
format (and PI1), r2067. In many cases, the exact timing can't be preserved
because GrafX2 (and Deluxe Paint) use a very different way of measuring speed
than Degas Elite, but it's better than nothing. The case of magicmtn.pc1 is one
that converts exactly in both direction : 2/60s Degas Elite == Timing "70" in
Deluxe Paint & Grafx2
Original comment by yrizoud
on 30 Aug 2013 at 5:29
Original comment by yrizoud
on 30 Aug 2013 at 5:29
Closing, as there is not much more to do here, issue is fixed.
Original comment by pulkoma...@gmail.com
on 10 Feb 2015 at 8:27
Original issue reported on code.google.com by
magnu...@algonet.se
on 9 Jul 2013 at 3:13