|
|
|
This thread is locked; no one can reply to it.
|
1
2
|
| LBM files? drop support ? |
|
Peter Wang
Member #23
April 2000
|
How is loadpng old and broken? I just made an update last week or so. http://members.ozadsl.com.au/~tjaden/loadpng/
|
|
Gnatinator
Member #2,330
May 2002
 |
Sorry, I havent tried it recently, when I did ~6months ago it didnt compile correctly on my version of GCC.. I just ended up using TGA's.
|
|
Thomas Harte
Member #33
April 2000
 |
LBM files are the Amiga interleaved format. Last seen in the wild in about 1994, and even then quite rare. Probably the native format of Deluxe Paint for all I know. Perhaps someone could hunt out a wise and very old man who might remember. If the developers are finally dropping their objections to zlib, can we please dump the olde packfile stuff too? Build datafiles on zlib if you must, but do we really need a worse than zlib compression algorithm? [My site] [Tetrominoes] |
|
Kitty Cat
Member #2,815
October 2002
 |
Quote: If the developers are finally dropping their objections to zlib, can we please dump the olde packfile stuff too? That actually doesn't sound like a bad idea.. though I'm not sure about one thing. The docs say (or at least imply) that the first four bytes of a compressed packfile (not datafile) is some wierd define. Now, AFAIK the define can be changed.. but can you detect a zlib-compressed file that way? Don't forget, you'd also have to retain support for decompressing the old format. -- |
|
A J
Member #3,025
December 2002
 |
its about time we wised up abit, and stopped tip-toe-ing around this ideal world were everything that was once supported needs to continue to be supported. evilution (mispelling intended) also means loosing a few things. ___________________________ |
|
Evert
Member #794
November 2000
 |
Quote: LBM files are the Amiga interleaved format. Ah! That explains why Allegro can load them, I guess. And yes, if we do demand zlib as a dependency, then there's no reason not to use it too for datafiles. |
|
Kitty Cat
Member #2,815
October 2002
|
Either that or Tomasu's VFS for AllegroPro. I don't even think datafiles were gauranteed to be in A5, were they? -- |
|
Thomas Fjellstrom
Member #476
June 2000
 |
I think Peter had some new File code in his A5. And I started a fancy VFS project that will be done "any day now".. -- |
|
Peter Wang
Member #23
April 2000
|
I did write a layered I/O system, but didn't get around to doing a packfile/datafile layer. It might still be useful as a starting point, but the API needs a review. Also, it was a bit inefficient. For packfiles/datafiles, I personally would like to switch to zip files containing PNGs/WAVs, like everybody else is doing. Support for packfiles/datafiles would probably go into the compatibility layer.
|
|
spellcaster
Member #1,493
September 2001
 |
While we are at it: -- |
|
X-G
Member #856
December 2000
 |
Quote: Could we ensure that we can load all datatypes from memory? I definitely want this too. Currently the only way to load things are directly from files, by specifying a filename - this is far from as flexible as it could be, and should be. -- |
|
Richard Phipps
Member #1,632
November 2001
 |
I agree, I would also extend it for all image loading as well. Then of course you get the advantages of compression if required. |
|
Elias
Member #358
May 2000
|
I think, the loading from memory would be solved by any packfile/datafile replacement automatically. I think someone even made a patch once for memory packfiles, so you could just open a memory block, and all allegro file routines (including bitmap loading) would work on it. I also agree that we should add support for libpng/zlib - but I would prefer to do it with some sort of "official addon approach" as well. Official addons wouldn't be in the core allegro, but there could be a distribution of allegro containing all the official addons included. In unix, it probably would be a separat .so, like the addons we already have. This would e.g. allow updating to a new version of libpng, without having to recompile Allegro. Other than that last example - the difference to just re-distributing the source wouldn't be big, I just find it much cleaner if we separate the core lib from addons (and i would move quite a lot of other stuff in such addons as well). Probably the official allegro releases should contain all official addons - so the only difference would be on the CVS level. The core allegro from cvs would only include a base system, and just the zipup.sh would get somewhat more complicated, having to pull in the addons. -- |
|
X-G
Member #856
December 2000
|
Quote: I think someone even made a patch once for memory packfiles, so you could just open a memory block, and all allegro file routines (including bitmap loading) would work on it. This we want. Basically anything that allows us to use one single file interface for loading from many different sources, including but not limited to actual files and memory blocks will be good, assuming that the Allegro internal routines actually use this. For one thing, it's more or less a requirement for making a VFS... If zlib is going to replace the current packfile system somehow, then that would be an automatic dependency in Allegro (and I for one am not opposed to this happening) and included all the time anyway. Most libraries have simple dependencies, and zlib is both license-compatible and widely available, so I personally don't see any reason why it couldn't be included as a dependency or even shipped with Allegro. [Edit: What was I smoking when I wrote that first paragraph?] -- |
|
Kitty Cat
Member #2,815
October 2002
|
Quote: In unix, it probably would be a separat .so, like the addons we already have. This would e.g. allow updating to a new version of libpng, without having to recompile Allegro. I would imagine most Unix systems have libpng/zlib installed as shared libraries already. All you'd have to do is update libpng and/or zlib, and poof. And for the Windows version, Allegro could default to compiling the DLL versions of libpng and/or zlib so users could upgrade them easilly without touching Allegro. -- |
|
Elias
Member #358
May 2000
|
Hm, true. This would apply to the "loadpng" addon then more than libpng itself. I somehow like the idea of having lots of small modules for everything, like what the /usr/local/lib/allegro/4.1 directory already does. The same directory could have loadpng.so, allegrottf.so, aldumb.so.. and only those would depend on libpng.so, freetype.so, dumb.so, or whatever. For other platforms, this probably makes much less sense though. Quote: If zlib is going to replace the current packfile system somehow, then that would be an automatic dependency in Allegro (and I for one am not opposed to this happening) and included all the time anyway. Most libraries have simple dependencies, and zlib is both license-compatible and widely available, so I personally don't see any reason why it couldn't be included as a dependency or even shipped with Allegro. True, zlib would be a much stronger dependence than libpng. But if the new virtual IO system is coded clean enough, the actual compression method could be added at any time. Just like you have register_bmp_type now, you would have register_compression_type - and that could be called from the zlib compression addon. -- |
|
Thomas Fjellstrom
Member #476
June 2000
|
In my scheme, (like in Peter's) compression is a stream filter at the basic level. You can implement any fancy stuff over top. I've gotten a fair bit done, nothing working of course, but enough planning that the rest is cake walk. The interface is based on Streams and Archives/VFSs. You can have a read write zip vfs handler, one for my fancy TFS idea, and whatever else, even a memory file system, not just memory files. This means you get to hand around a VFS handle to a few of the functions, but that should be fine no? -- |
|
Richard Phipps
Member #1,632
November 2001
|
Sounds good. Implement it!! |
|
Peter Wang
Member #23
April 2000
|
Quote: I think, the loading from memory would be solved by any packfile/datafile replacement automatically. I think someone even made a patch once for memory packfiles, so you could just open a memory block, and all allegro file routines (including bitmap loading) would work on it. Remember when I said that Allegro 5 had the problem of making us defer changes and saying, "it'll be in Allegro 5"? This is one of those changes. Forget the layered I/O or VFS schemes -- they won't make it in time before the 4.2 feature freeze. Allowing the user to supply their own hooks for packfile functions is Good Enough, and is not hard so can be done for 4.2. I still have a patch from 2000 that can serve as a starting point. Anyone interested in doing the work, please say so.
|
|
Thomas Fjellstrom
Member #476
June 2000
|
Peter, My stuff won't make it for 4.2. packfile hacks are all we can do for now. Unless I get some major motivation and finish up the api that is. -- |
|
X-G
Member #856
December 2000
|
Packfile hacks are good enough in the meantime. Any kind of solution is sorely needed. -- |
|
A J
Member #3,025
December 2002
|
does a VFS have mount points so a diskfile .z could be loaded into memory and 'mounted' on the VFS ? ___________________________ |
|
X-G
Member #856
December 2000
|
Yes. Any decent VFS would have such capability. -- |
|
Thomas Fjellstrom
Member #476
June 2000
|
The original idea had a unix like approach, but to start with it'll be a little lower level, you have VFS handles and STREAM (and FILTER) handles. a "VFS" handle provides the methods for reading its particular type of "file system", like a .zip file, regular stdio, etc. -- |
|
|
1
2
|
More like "when ever its done".
