I'm definitely in favor of the gif:frame(n) thing, it will improve readability. Even if it's "just" a loader (maybe
especially if it's just a loader), I think the accessibility and understandability of the format is important. After all, if getting it into a convenient format weren't important, you could just load the raw data, maybe uncompress it, and call that a GIF loader.
I'm also pondering on whether to add a flag to "flatten" the images on load. By that I mean to apply the disposal method to each image, generating the actual frames that can be drawn directly without needing to handle disposal (all frames would have disposal=0).
What about a separate companion module for drawing gifs in your format? Leave them "un-flat" and have a "gifdraw" module with a few methods that draw things loaded by the "gifload" module. I think ideally your main.lua example could mostly just use those two modules and be pretty simple, to the point where someone who comes across the library because they just want to slap a dancing banana into a cutscene or something will think "hey, this looks easy" instead of fleeing in terror
I'm imagining it looking something like this:
Code: Select all
local GifLoad = require 'gifload'
local GifDraw = require 'gifdraw'
-- GifLoad.read is a wrapper for everything under "Example: loading a GIF file"
-- or maybe it's part of GifDraw so you don't need to require 'gifload' at all in user code.
local bananaGif = GifLoad.read('assets/banana.gif')
local banana = GifDraw(bananaGif)
function love.update (dt)
banana:update(dt) -- this just lets the GifDraw instance figure out what frame it's on.
end
function love.draw ()
local x = 400 - bananaGif.width * 0.5 -- or maybe copy width and height to the GifDraw instance
local y = 300 - bananaGif.height * 0.5
banana:draw(x, y)
end
All the low-level stuff would still be there, this would just make it more approachable for the most common use cases. GifDraw instances could have more methods for stuff like changing the time scale or resetting the animation.