[epiar-devel] Threads, Networking, etc..

[Matthew Zweig]

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.

~Matt Zweig

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  
> all
> PNGs, but on the other hand, if we have good control over the format  
> of
> 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  
> can
> tell, we aren't using XPath).  I personally prefer tinyxml (never  
> tried
> the xpath or the ++ version).
> 3) Afont is slow for me also, it's not noticeably slower, by only  
> about
> 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  
> don't
> know if it's just my video cards (two computers, one with ATI, one  
> with
> 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  
> now,
> 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  
>>> 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
>> this.
>>
>>> 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.
>>
>> -- Chris
>>
>> _______________________________________________
>> epiar-devel mailing list
>> epiar-devel at epiar.net
>> http://epiar.net/mailman/listinfo/epiar-devel
>
>
> _______________________________________________
> epiar-devel mailing list
> epiar-devel at epiar.net
> http://epiar.net/mailman/listinfo/epiar-devel