[epiar-devel] Threads, Networking, etc..
thezweig at gmail.com
Mon Dec 21 09:30:38 PST 2009
My text problems were only solved by including freetype into Epiar and
rendering .ttf files. I don't mind making afontthe standard, but I
will be maintaining a freetype version of epiar so that I can do
development. I've done my best to implement this as a ./configure
option so that it affects af few people as possible. If anyone had
problems building epiar (on my master branch) without freetype
installed, let me know.
I can't use afont but I'll try not to force it on anyone else.
On Dec 21, 2009, at 8:55 AM, Maoserr <maoserr at gmail.com> wrote:
> To clarify a few things:
> 1) Actually zlib and libpng can be replaced with an alternate image
> loading library (see SOIL for example, which doesn't use libpng),
> not that
> I recommend it, since libpng seems to be the standard that supports
> PNGs, but on the other hand, if we have good control over the format
> our image, it might not be too difficult to use SOIL.
> 2) TinyXML has three major branches, the original, one that supports
> XPath, and TinyXML++ that uses more C++ features (though as far as I
> tell, we aren't using XPath). I personally prefer tinyxml (never
> the xpath or the ++ version).
> 3) Afont is slow for me also, it's not noticeably slower, by only
> 3-5 ms with the current amount of text on screen, but if we draw
> say, 15
> more lines of text, the difference between afont and texturemapped
> font is
> approximately 20 ms which translates to roughly a drop of 15 fps. I
> know if it's just my video cards (two computers, one with ATI, one
> Nvidia), but I believe the difference might not be noticeable
> because the
> amount of text is not large yet. I'm not for or against this right
> but just beware that if the amount of text gets large, we might have
> problems with this if we decide to get rid of ftgl+freetype.
> On Mon, 21 Dec 2009 11:12:17 -0500, Chris Walton
> <chris.r.walton at gmail.com> wrote:
>>> 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
>>> 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
>> for platform abstraction, so there's no reason (I think) to replace
>>> SDL_image -> also can be eliminated with pure OpenGL. 2) other
>>> 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
>>> 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
>>> ftgl -> Same as freetype2 (we can extract only the code we need from
>>> and rewrite it to fit our needs better, it'll still be easier than
>>> 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
>>> 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.
>> -- Chris
>> epiar-devel mailing list
>> epiar-devel at epiar.net
> epiar-devel mailing list
> epiar-devel at epiar.net
More information about the epiar-devel