@Futaura

Never heard of them. So it looks you did. Well until now since they are being raised.

Just a few clarifications.

SView and AK Datatypes were the first to support PPC and really made use of the additional horsepower to a significant extent - regardless of the weaknesses of powerUP and before the platform wars started - and while I made the datatypes shareware and added 68k, PPC and later WOS (WarpUP) support for some, I decided to remove (disable) PPC/WOS support again in the later years, because others could do better by focussing concretely on their platform. 68k/PPC/WOS (version) combination(s) testing became a support mess and it anyway really makes sense to keep a set of core datatypes "close" to the corresponding OS - the counter argument back then was lack of update frequency (especially for 68k OS, which was unmaintained for long), besides lack of PPC versions.

In the end ak Datatypes found a second life in Amikit.

Also at least the pure-C library template approach in general also inspired AROS. So basically everyone is away from assember in library/datatype context now. Furthermore, while in the beginning a lot of changes were taking place in libpng (I contributed, also to support the GIF alternative getting up and running) and libjfif (similar) as well as libtiff (kind of same), these are now quite stable and upgrading is straightforward. This is a solid base to start from.

UI design is a matter of taste. While I never have been a UI person, I have been working with many. But in terms of SView and ak Datatypes some compromises were made always. The "engine" is the asset in both cases. Basically, there are different ak Prefs alternatives (even MUI based) on Aminet and they are easy to be done by anyone in similar form - however pre-configuration always is the better option than tackling manually something that should better work out of the box. If you need to configure a datatype, that should be only once or as fallback for some specific legacy program (when being called by that one).

Descriptors can be made more compact, yes - but by using 68k code, which gets included into the descriptor file. This is basically an approach that I preferred in SView as well (use code instead of patterns) but certainly this does not cause a speed increase in the actual file recognition while making things less portable and harder to maintain. Probably again a matter of taste.

Yes, SView was offered for sale/licensing - this is also true for the Windows .NET port which basically consists of C++ wrapped classes, which are API-wise very similar to the original loader/saver modules of SView and from an engine-perspective also drive/drove some of the datatypes originally (at least the more exotic ones, which are not in scope here currently) in some wrapped form. So SView in the end is a huge code pool for such. - Besides, I just had not the time and motivation to backport all the improvements and bug-fixes back to Amiga platform. In any case I have to admit that the excellent Visual C++ debugging capabilities allowed me to eliminate many issues which before couldn't really be adressed properly.

Last not least: keep having fun and continue using what you like. It is clear that any sort of hobby means also to have different preferences, ideas and opinions - and to talk about. This is not different to soccer :) Won't try to convince anyone of anything and really no interest in pushing anyone's ego (neither my own). There's always someone who does better or claims to do so. From time to time I may have a look over the fence to see what's going on. But I'm really out, hobby-wise.

There already is http://aminet.net/package/util/dtype/JFIFdt44 that supports the AC68080.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@monstercoder
Quote:

if they make it 68080 optimized i will buy it. it would be the fastest datatype ever.

There already is http://aminet.net/package/util/dtype/JFIFdt44 that supports the AC68080.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

* burp *

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC