Fix for loop count

The NETSCAPE loop count value was not being returned correctly. This fixes the problem.

Added 1-bit cooked output

This release adds additional code to simplify 1-bit output. I added this to make it easier to display animations on monochrome OLED and LCD displays. See the new oled_gif_demo example sketch for how to make it work. Here it is running on a SSD1306 OLED:

https://youtube.com/shorts/vXoxLuuGIeM?feature=share

Turbo mode

This release adds 4 important changes:

• Turbo mode: trade more RAM for more speed. Most likely will be useful for PCs, not MCUs.
• Improved speed for the 'old' way of using the library. I optimized the code further and got 5-10% more speed for all use cases.
• COOKED pixel output: Have the library take care of merging new frames onto the canvas. This requires a full framebuffer for the 8-bit canvas pixels.
• RGB8888 (32-bit pixel) support

New example: play GIF from SPI FLASH

This release adds a comprehensive example sketch showing how to copy a file from uSD card to SPI FLASH and play it from there with greater efficiency using DMA.

Best Practices Example

This release fixes a bug in the getInfo() method that caused it to fail with certain files. It also adds a more comprehensive example (best_practices_example) which shows how to use DMA and optionally a backing buffer to get the best performance possible.

Added openFLASH option for ESP8266

My gif.open() function was using memcpy to access the source data and on the ESP32, this worked because it recognizes FLASH vs RAM addresses. On the 8266 the address spaces overlap and this was causing problems, so I added gif.openFLASH() which uses memcpy_P to correctly access the FLASH address space.

TinyPico IPS Display Shield Example

Added an example sketch to draw animated GIFs on the TinyPico IPS Display Shield (160x80 ST7735 LCD).

NeoPixel Player example

This release adds a new example sketch to play tiny (5x14) GIF animations on the UnexpectedMaker LOLRGB LED shield.

Fixed linux demo and problems with files having extra data after the last frame

This release includes two fixes:

1. The linux demo code needed to be updated after a recent change to the playFrame parameters
2. Some GIF files contain data after the end of the last frame. The previous release would incorrectly try to decode this extra data or get stuck in a loop.

Fix API incompatibility

The last set of changes broke backwards compatibility, so this fix adds the needed changes to allow old and new code to work correctly.
I also had to rename gif.c to gif.inl to allow it compile properly for the Arduino Nano RP2040 Connect.