Rick's history:


The last prior modification was by Jérôme Mathevet:

      2.05, le 26 Juillet 98:
      - Le chargement via Wimp$Scrap marche mais le nom est erroné. Ceci
        vient probablement du fait que je ne suis pas du tout le protocole de
        la RiscOS_Lib, je remplis les champs 'a la main' et envoie moi-même
        le message.

      Roughly translated, it says "Oh look, another bug in RISC_OSLib!". :-)



2.05a   2004/01/29

        Minor modifications to get it to compile on my machine, using the
        new compiler.

        The dither menu is broken. This is due to small differences between
        the older RISC_OSLib (yuck!) into which Frank Lyonnet pokes; and the
        32bit version which apparently doesn't make its guts so visible.
        Thanks, guys, why'd you fix something that has been 'broken' for over
        a decade? :-)

        The thing crashes with a "heap overwritten" error when you close the
        display window. I'm not sure why (I don't fancy wading into the
        memory handling right now!), so the "quick-fix" is to simply NOT free
        the window definition workspace.
        Side effect? You'll lose 64 bytes per window instance (plus whatever
        crud the heap itself adds). Not a big issue, really...

        Modifications made to the assembler code. FYEO2 (v2.05a, my version)
        should now be 32bit safe and 26/32 neutral. Obviously I don't have an
        Iyonix to test it on, so if somebody could check it over for me...

        FYEO2 now supports progressive JPEGs! It does so by detecting it as
        such, and then calling "jpegtran" to convert the JPEG to be a
        baseline (regular) JPEG. This, called "<Wimp$ScrapDir>._jpeg", is
        then pushed into FYEO2's queue for subsequent display.
        This will work quite-nicely-thank-you if you drag/double-click on one
        (progressive) JPEG at a time, however IT *WILL* FAIL MISERABLY if you
        select a number of progressive JPEGs and drag them to FYEO2 at once.
        This is because FYEO2 will dutifully convert each JPEG to baseline
        form, calling it "<Wimp$ScrapDir>._jpeg", and then it'll load that
        (same!) file as many times as was necessary, so you might wait a few
        minutes for "jpegtran" to do it's stuff, only to end up staring at
        five or so copies of the *same* image!

        By the way, !FYEO2.!RunImage v2.05a is dated 2004/01/30 05:25:59,
        that is the real honest compile time (in the CET timezone). :-)

It can now display those other sorts of JPEG.

2.05b   2004/02/24

        FYEO2 now detects and pre-loads BMP files. It will "die with message"
        after that state, as the decode code has not been written... yet.

        Guess what? It's 05h40 CET. Why doesn't our stupid insurance company
        just insure the frigging pump so I can go to bed while it is dark
        outside? <sigh>
        Still, I get to spend Quality Time with my keyboard (or watching teen
        slasher flicks starring Love Hewitt (mmmm), or Neve Campbell, or
        clones)...
        It's a pity that, during coding time, I can't put on Evanescence and
        turn it up - mom would get somewhat annoyed, given it's nearly 6am!

        Wild idea - maybe I should add PCX support? ;-)
        You *know* I've been awake too long when things like that actually
        start to make sense; so if you'll excuse me, my guts I have to puke
        out.

        Okay, the dither menu *DOES* apparently work. Funny that, since I
        commented out a chunk of its code to shut up a compiler warning that
        I didn't feel like tracking down. Go figure...

        Oh the other hand, it seems to obstinately refuse to reload it's
        preferences...

        ...now, you see, if you threaten it with a big enough stick, it will
        BEHAVE.
        Actually, I noticed that "OK" then "Save Preferences" did what was
        expected. For some reason, it seems the "Save" committed the last
        updated settings (i.e. those 'set' by clicking OK) but not what was
        actually visible in the settings window(s)!
        Now it reads from the settings windows AND it automatically closes
        the settings window(s); so you can now treat "Save Pref's" sanely,
        like and "OK, but save this too" button.

        Added 'warning' to appear if there is no preferences file.

        That'll do, pig. That'll do.

Stuff happened.

2.05c   2004/03/03

        If you open six images in turn, leaving the previous ones visible,
        FYEO2 will crash with weird messages like "premature EOF" and then
        an abort. If you were to toggle the sixth image full size, you'd see
        a few pixel rows of data. Things go wrong when the image being
        decoded overwrites this...
        I *am* aware of the problem, but do not plan to look at it *yet* as
        FYEO2's memory allocation appears to be an uneasy blend of malloc()
        and flex() side-by-side!

        Now supports 24bpp BMPs, but upside down. Bloody Microsoft!!!

        Found bug with 8bpp BMPs: My document says that a word gives the size
        of the colour table. This is bogus, the colour table size is
        determined by the bpp value...

More stuff happened.

2.05d   2004/03/04

        Okay. That was simple (after a can of beer!). The BMP decoding works
        for all supported formats - 1bpp, 4bpp, 8bpp, and 24bpp. Those bpps
        correspond to 2, 16, 256, and 16m colours. Other bpps should not
        occur. The palette is used, if one is present.

        Please note the following caveats:
          1. Right-pixel error in 1bpp and 4bpp modes. Possibly due to my
             maths (or lack of) when bit shifting. I don't classify this as
             'urgent' as you're unlikely to encounter many BMPs of such a low
             quality, these days...
          2. It is quite slow and 'jerky' to update. This is an effect of the
             fact that the file is being read BACKWARDS (as BMPs are stored
             upside down).
             Obviously, attempting to view a 24bpp BMP from a floppy disc
             will be an exercise in desperation, on par with watching paint
             dry. :-)
          3. 'Odd' BMPs (other depths, >1 plane, RLE compressed) are not
             supported. They are unlikely to be supported because:
               a. Other colour depths should not occur, though I do wonder if
                  a CMYK format exists these days.
               b. BMPs should only have 1 colour plane. If you want freaky
                  levels of colour, play with a PCX...
               c. The only RLE compressed BMPs I've *ever* seen in actual
                  use are the Windows startup do-dahs.

        Oops - corrected the pixel order for the 4bit handler.

Ohmigod, it can, like, totally show, like, Windows piccies. That is, like, so not cool...

2.05e   2004/03/05

        Fixed the right-hand column bug in 1bpp and 4bpp modes.

        I thought I'd better explain why the BMP is so slow compared to other
        formats, like GIF, and why RLE is unlikely to be implemented...

        BMP is slow because, as you know, the file is read line-by-line
        backwards. This, sadly, destroys any attempt that the filing system
        (or harddisc) might try to 'cache' the next few fragments of the file
        as it is rare that you'll be going backwards.
        Now, it is entirely possible to speed up the BMP process by recoding
        FYEO2's internals to work in both directions (bottom-up for BMPs and
        top-down for everything else). That would reduce reliability and make
        the code larger and messier. In short, not a good option.
        Alternatively, we could try doing what the GIF code does for
        interlaced GIFs, and decode the image into memory before reading it
        out line-by-line. Given that BMPs are a tad 'wasteful' and that you
        might want to look at an enormous BMP using, say, 1:8 scale... such
        an activity isn't terribly useful either.
        So, backwards-reading may be slow but it is the least likely to cause
        you problems in the future, okay?

        The method works by calculating where each line is to begin, and then
        moving to that position (in the file) prior to reading a line. Now
        with RLE compression, this isn't possible as the line starts won't be
        in predictable places. The only method would be to scan through the
        file decoding but *not* storing, and make a note of where each line
        begins. Obviously, this is not only time-consuming, but wasteful. I
        may consider it if there is call for RLE decoding, but since I've
        only ever seen it used for the Windows start-up screen, I don't think
        I'll have twenty dozen emails begging for RLE support!

        Fixed 1bpp colourmap bug. Oddly, it only seemed to show up for the
        Windows "SETUP.BMP" file!

        Tested with 1bpp/4bpp/8bpp/24bpp images created using !Creator from
        a CD-ROM.
        Tested with 8bpp images created using !ToBMP, downloaded.
        Tested by scanning my PC partition and tossing any BMPs found to
        FYEO2; 4bpp and 8bpp.
        Tested with C:\WINDOWS\SYSTEM\VGALOGO.SYS - it correctly reports that
        compressed images aren't supported.

        IMPORTANT: There is an outstanding bug in the 4bpp mode, where some
                   images require a byte realignment and some don't. I
                   suspect my grasp of maths isn't good enough to spot what
                   is actually going on here.
                   Anyway, FYEO2 tries to work out which type of alignment
                   is required - but it doesn't always get it right.

        Obviously, the most effort has been put into getting 8bpp and 24bpp
        support working well...

        Thus, line-at-a-time buffering has been implemented for 8bpp and 
        24bpp modes to give a small improvement in the conversion speed. On
        the test picture, this amounted to approx. 2/10ths of a second (!);
        this is liable to vary according to the image size that is converted;
        it may be more useful to people using floppy discs...?

        I did examine the output generated by the compiler to see if it could
        be optimised further by writing the line conversion core in a small
        assembler routine. Well, the compiler code is a bit freaky (nothing
        new, there) but it is pretty tight, so any savings made won't be
        much (given the line-at-a-time buffering didn't add /that/ much!).

        Filetyping now uses OS_File instead of creating a *command to do a
        SetType operation.
        Additionally, it won't try to set the type of a file that already has
        the correct filetype. In some cases, this can cause attributes to
        become updated.

        Updated the Messages file so the help for the "Save Preferences" icon
        reflects the change in behaviour introduced in version 2.05b...

        From ChangeFSI's format documents:
          [BMP files]
            · Recognised by 'BM' at the start of the file; or 'RIFF' at the
              start of the file, and 'RDIBdata' at offset 8 and 'BM' at
              offset 20 in file.
        I have never seen a "RIFF" type, so be aware that they are NOT
        supported, the first two bytes MUST be "BM".

        Additionally, the OS/2 versions (and possibly the DIB version) are
        not currently supported. There is one of these in the examples
        archive, and you'll be lucky to find something that'll load it - most
        software (including FYEO2, at the time) will report the planes and/or
        colour depth is invalid.

        I've managed to get hold of the BMP icon used by ImageMaster (it's an
        old version apparently so it has the old name) and I am using them in
        FYEO2 because I feel that it best represents the 'Windows' connection
        with the BMP format. Some icons, such as those in Creator (the
        'windows') were possibly a little bit *too* abstract. :-)

        FYEO2 now 'claims' BMP files, along with it's usual line-up of known
        image formats, when you start it.

Blah blah blah, yadda yadda yadda...

2.05eß  2004/03/06

        I 'repaired' the multiple-windows-causes-crash problem by increasing
        the WimpSlot from 256K to 320K.
        Just viewed 108 images (mostly JPEG), using the same instance of
        FYEO2 without a problem, so the bug hasn't been cured - it has just
        gone away.

        Given that nothing was done to the software itself, this version will
        identify itself as "2.05e" and NOT "2.05eß". Indeed, this is the ONLY
        document in which you'll find any mention of the 'ß' version...

Something really small happened.