[messages about PNG] Pasi Ojala (http://www.cs.tut.fi/~albert/Dev/) has written a version of gzip/pkzip/zip for the Commodore 64 in 6502 assembly. If the deflate methood (zlib) can be done in 16Kb then there is a way of doing it in fractint. I've written a huffman decoder before, so I don't think it would be that hard to rewrite the compression routines for what we need. I'll start working on it tonight. I think I might have a copy of MS C around here, I can setup a dos emulator and make sure that the code works in that environment. (What are DOS Fractint's minimum requirements right now? 640K and an 8086?)
IMO, its a waste of effort to do anything more in the medium memory model. Supporting this memory model is holding us back more than it is helping us. DOS can live on with the 32-bit extenders that are around, but we really need to ditch this medium memory model to move forward, as has been stated on this list many times (check the archives). The problem is not that it -couldn't- be done. The question is -why- should it be done? We should move forward and leave the medium model behind. -- Ask me about my upcoming book on Direct3D from Addison-Wesley! Direct3D Book <http://www.xmission.com/~legalize/book/> izfree: Open source tools for Windows Installer <http://izfree.sourceforge.net>
Cute Skunk wrote:
Pasi Ojala (http://www.cs.tut.fi/~albert/Dev/) has written a version of gzip/pkzip/zip for the Commodore 64 in 6502 assembly. If the deflate methood (zlib) can be done in 16Kb then there is a way of doing it in fractint.
Maybe I spoke too soon. What I should have said was that it appeared to me that PNG couldn't be implemented in fractint using LibPNG. This disappointed me a lot, because I worked very hard to make sure Zlib and Libpng could be compiled in the medium model. Now I think it doesn't matter. If you can quickly cobble together a PNG encoder and decoder that would use no more memory than Fractint's GIF encoder and decoder, that would be interesting. But keep in mind that there is a lot of other functionality in Libpng that we would need beside the encoder and decoder. Rich has a point about not investing too much more time in the medium model. Once one is using a flat memory model, Libpmg works fine. Tim
On Fri, 8 Nov 2002, Tim Wegner wrote:
Maybe I spoke too soon. What I should have said was that it appeared to me that PNG couldn't be implemented in fractint using LibPNG. This disappointed me a lot, because I worked very hard to make sure Zlib and Libpng could be compiled in the medium model. Now I think it doesn't matter.
If you can quickly cobble together a PNG encoder and decoder that would use no more memory than Fractint's GIF encoder and decoder, that would be interesting. But keep in mind that there is a lot of other functionality in Libpng that we would need beside the encoder and decoder. Rich has a point about not investing too much more time in the medium model. Once one is using a flat memory model, Libpmg works fine.
I may have spoken too soon as well.. the inflate methood uses a 32K history buffer (the current LZW code in Fractint is only needs a 4K buffer) So this is going to use more memory than I thought at first, I need to take a closer look at what is actually taking up memory where to make sure there is enough. (I don't suppose there's a memory map anywhere?) (*suffix is ~10k, *prefix seems to be 4K at most, *decoderline is a max of 2K, *stack seems to be 4K at most as well, anyone know offhand what else, that is really big, is in that segment?) ... or we could just fork a new version with a flat memory model :)
Cute Skunk wrote:
I may have spoken too soon as well.. the inflate methood uses a 32K history buffer (the current LZW code in Fractint is only needs a 4K buffer) So this is going to use more memory than I thought at first, I need to take a closer look at what is actually taking up memory where to make sure there is enough.
You know what, I am arriving at the view that PNG is a complete non- issue. We could go ahead and implment PNG for Xfractint, and simply write a GIF/PNG converter for DOS using djgpp. As I told Rich, we need a temporary kludge to save the data, and give ourselves time to do a good job on the eventual data saving method using fRAc. Having said all this, I still don't think PNG is the highest priority. Tim
In article <3DCC1177.7272.5B5E3C@localhost>, Tim Wegner <twegner@swbell.net> writes:
issue. We could go ahead and implment PNG for Xfractint, and simply write a GIF/PNG converter for DOS using djgpp.
I think there are open source GIF/PNG converters out there, so we don't need to write one. We just need to modify it to pass along the fractint-specific data, which probably gets dropped in the conversion. -- Ask me about my upcoming book on Direct3D from Addison-Wesley! Direct3D Book <http://www.xmission.com/~legalize/book/> izfree: Open source tools for Windows Installer <http://izfree.sourceforge.net>
Rich wrote:
I think there are open source GIF/PNG converters out there, so we don't need to write one. We just need to modify it to pass along the fractint-specific data, which probably gets dropped in the conversion.
When PNG was designed, we designed a chunk to preserve GIF extension blocks. I doubt anyone has ever used it :-) This is a REALLY simple way to initially store Fractint data. basically, just store it the same way. It's not a permanent solution, but would work well. I think I would rather write a dedicated GIF <-> PNG converter for fractint than use another tool, though there is no harm basing ours on someone elses if the source is available. Tim
In article <3DCC2F30.32088.CF7C04@localhost>, Tim Wegner <twegner@swbell.net> writes:
I think I would rather write a dedicated GIF <-> PNG converter for fractint than use another tool, though there is no harm basing ours on someone elses if the source is available.
A good starting point would probably be pnmtopng: <http://www.libpng.org/pub/png/apps/pnmtopng.html> -- Ask me about my upcoming book on Direct3D from Addison-Wesley! Direct3D Book <http://www.xmission.com/~legalize/book/> izfree: Open source tools for Windows Installer <http://izfree.sourceforge.net>
I know y'all are discussing DOS-based GIF -> PNG converters, but in case no one has checked, Linux comes with gif2png, an open source converter that could be used in Xfractint. Scott On Friday 08 November 2002 21:40, Tim wrote:
Rich wrote:
I think there are open source GIF/PNG converters out there, so we don't need to write one. We just need to modify it to pass along the fractint-specific data, which probably gets dropped in the conversion.
When PNG was designed, we designed a chunk to preserve GIF extension blocks. I doubt anyone has ever used it :-) This is a REALLY simple way to initially store Fractint data. basically, just store it the same way. It's not a permanent solution, but would work well.
I think I would rather write a dedicated GIF <-> PNG converter for fractint than use another tool, though there is no harm basing ours on someone elses if the source is available.
-- sdboyd56@swbell.net http://sdboyd.dyndns.org --------------------------------------- No Microsoft or other proprietary products were used in the creation of this email.
In article <0H5D001ZFS21CX@mta5.rcsntx.swbell.net>, "Scott D. Boyd" <sdboyd56@swbell.net> writes:
I know y'all are discussing DOS-based GIF -> PNG converters, but in case no one has checked, Linux comes with gif2png, an open source converter that could be used in Xfractint.
In Xfractint, we can just output the png directly with libpng. -- Ask me about my upcoming book on Direct3D from Addison-Wesley! Direct3D Book <http://www.xmission.com/~legalize/book/> izfree: Open source tools for Windows Installer <http://izfree.sourceforge.net>
Scott wrote:
I know y'all are discussing DOS-based GIF -> PNG converters, but in case no one has checked, Linux comes with gif2png, an open source converter that could be used in Xfractint.
We can modify gif2png in a way that preserves GOF extension blocks. As we discussed elsewhere, PNG has a chunk defined for exactly that purpose. I lobbied for it because I had fractint in mind. We can't use a gif2png utility that drops the fractal data. Here's some amusing ancient history. I implemented saving fractal data in a GIF in 1988. Originally, fractint put the data neatly after the GIF terminator. Then Compuserve started "cleaning" all the GIFs folks uploaded, thereby stripping out the fractal data! Then GIF was developed mostly behind closed doors. We lobbied relentlessly for a GIF extension block to accomodate our data. When GIF89a came out, it had this feature. Then years later, I had to lobby for a PNG chunk to preserve GIF extension blocks. When we were writing the PNG spec, we thought (well, at least hoped) that it would sweep away GIF quickly. So it had to support close to 100% of the GIF feature set. Things didn't turn out the way we expected, but PNG has been pretty successful. But the explosion of the internet kept GIF alive. I don't want to exaggerate my role in GIF and PNG in telling this story, it was really pretty small. Tim
On Fri, 8 Nov 2002, Tim Wegner wrote:
Cute Skunk wrote:
I may have spoken too soon as well.. the inflate methood uses a 32K history buffer (the current LZW code in Fractint is only needs a 4K
You know what, I am arriving at the view that PNG is a complete non- issue. We could go ahead and implment PNG for Xfractint, and simply write a GIF/PNG converter for DOS using djgpp.
That would probabily be the quickest and easiest way. (Still limited to 8bit color too, but that's not really an issue)
Having said all this, I still don't think PNG is the highest priority.
Actually, I'm replying to this because I had another idea. If it's possible to read/write to the video framebuffer while compressing/decompressing. Then we could put the 32K lookback buffer into the video memory (where it's going to end up anyway) I'm not familiar enough with the code yet to know if you can call readvideo() from decoder() though.
Cute Skunk wrote:
Actually, I'm replying to this because I had another idea. If it's possible to read/write to the video framebuffer while compressing/decompressing. Then we could put the 32K lookback buffer into the video memory (where it's going to end up anyway) I'm not familiar enough with the code yet to know if you can call readvideo() from decoder() though.
You are full of good ideas but let me play devil's advocate. If our top priority is getting off the medium memory model, then what's the point? Just use Libpng the first second we have a flat memory version (e.g. Xfractint right now). If we want to extend the life of the old DOS version and add features, then your idea comes into play. Tim
participants (4)
-
Cute Skunk -
Rich -
Scott D. Boyd -
Tim Wegner