[epiar-devel] Threads, Networking, etc..
chris.r.walton at gmail.com
Mon Dec 21 08:12:17 PST 2009
> ZLIB -> I don't see how we can eliminate this and still use PNGs
> Libpng -> I don't see how we can eliminate this
> Lua -> I don't see how we can eliminate this (I've already tried LuaJIT,
> doesn't help much in terms of performance on first attempt)
These oughta stay, I think. Lua is the foundation of our Game code,
and all our images are PNG, so ...
> SDL -> 1) can be eliminated with pure OpenGL code - not a good idea. 2)
> Other libraries? SFML? Allegro?
SDL is probably the most lightweight of them. It provides what we need
for platform abstraction, so there's no reason (I think) to replace
> SDL_image -> also can be eliminated with pure OpenGL. 2) other ideas?
> SOIL, glpng?
SDL_image could be eliminated, but it's far from offensive.
> libxml2 -> This is bloated if we're just going to read and write xml.
> other ideas, roll our own parser, use smaller libraries like TinyXML
> (original, xpath, or ++)
I would suggest TinyXML, except that TinyXML does not support xpath,
unless there's some xpath branch I'm not aware of. Plus, libxml is
pretty much guaranteed to exist on any linux distro.
> freetype2 -> Can be eliminated, but then won't be able to read ttf files
> ftgl -> Same as freetype2 (we can extract only the code we need from this
> and rewrite it to fit our needs better, it'll still be easier than writing
> from scratch)
Depending on the status of matt's problem, I'd actually recommend
going back to afont.
> physicsfs -> I don't see a need for it, and since this has been in limbo
> for so long, I vote we get rid of it completely.
Unfortunate, but since half the code for its functinoality is already
present, I guess it can go.
More information about the epiar-devel