If you have anything to add, please email me.
Synopsis: If you view a number of images concurrently (usually five), FYEO2 will crash with two errors (when JPEG decoding, at least). The first will be "Unexpected EOF in JPEG file", followed by an internal error (abort on data transfer). Proposition: If you quickly toggle the image windows full size, the one that will fail contains a few rows of pixels, usually near the bottom of the image. When decoding reaches this point - boom! This points to some memory being incorrectly allocated. Historical: A similar problem existed with the older version 2.05 though not in the same form; however after ~5 images it would complain about running out of WimpSlot, and crash. Solution: Given the 'historical' message, I have increased the WimpSlot to 320K (from 256K). I do not consider this bug to be fully 'fixed' as whatever memory allocator is failing SHOULD detect when the application runs out on memory... ...I suspect that this is related to the intermixed calls to malloc() while flex allocations are active, hence clashes over who belongs where. However I have just viewed 108 JPEGs (from my website directory) using the same FYEO2 and no corruption or crashes...
Synopsis: If you open the iconbar menu, then the "Dithering" menu will behave like the iconbar menu (which can be pretty weird to see). Proposition: I think this is due to a tiny difference between the RISC_OSLib that was originally used, and the 26/32 neutral one, which doesn't appear to export one of it's internal variables that FYEO2 uses. Workaround: Open the preferences window by clicking SELECT on the iconbar icon; DO NOT use the iconbar menu, except to Quit (unless you will not need to alter the dithering).
Synopsis: Some 4bpp BMPs fail to decode, the output gets all screwed up. Proposition: Most likely my maths in the bit shifting. I will look into this, obviously, and I would appreciate SMALL examples that exhibit this behaviour. The same goes for 1bpp, 8bpp, and 24bpp; though I'm fairly confident that 8bpp and 24bpp work 'just fine'. Workaround: None. If you can send me SMALL examples (say, under 12K unless otherwise arranged with me), then I'll have more to go on.
Synopsis: When reading a JPEG on a corrupted disc, as the corruption is encountered, FYEO2 fails with the error: Internal error, no stack for trap handler: Internal error, abort on data transfer at &xxxxxxxx, pc = xxxxxxxx: registers at xxxxxxxx. Proposition: I tried inserting specific signal handling, and also tried to trap the file read where the error occurs; neither had any effect. I suspect that this goes back to something earlier (and possibly deep within the JPEG code). A truncated JPEG does not cause this problem to occur (an EOF is not an error, just a condition), while an actual disc read error (an OS error) is likely to cause things to be handled differently. It is also interesting to see the double error message... Workaround: None. Given that this error occurs due to a corrupted JPEG file, I suspect you'll have more important things to worry about. :-(
Synopsis: FYEO2 fails to render, aborting with the error message: "Bad parameters to get_mode_from_specs" Proposition: Possibly an incompatibility with calls to work out the screen dimensions, which are not compatible with the non-VIDC hardware in the Iyonix (James has an Nvidia GeForce 2). FYEO2, currently, only handles a 'standard' selection of DPI and BPP types, and it may be that RISC OS 5 offers more that FYEO2 simply does not recognise. Can people with FYEO2 and an Iyonix please run the program below and tell me what the results are (unless every Iyonix has the Nvidia GeForce 2 installed...?). REM >Get mode dimensions REM SYS &35, -1, 4 TO ,, xeig% SYS &35, -1, 5 TO ,, yeig% SYS &35, -1, 9 TO ,, bpp% PRINT "Xdpi = " + STR$(180 / (1 << xeig%)) PRINT "Ydpi = " + STR$(180 / (1 << yeig%)) PRINT "BPP = " + STR$(1 << bpp%) END Workaround: Switch off "Use current mode" in the output options, and tell FYEO2 to use a specific BPP/DPI combination.