Thread: RE: [GD-General] FreeType
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-general
|
From: Ignacio C. <ica...@nv...> - 2006-01-03 23:12:48
|
Brian,
I think that the issues you are seen could be related to the freetype =
autohinter. I got much better looking results with the patented bytecode =
hinter. However, that was some time ago and since then I've heard that =
the autohinter has become much better and produces comparable results =
now.
If you are going to generate strings or words on the fly using the =
autohinter might not be an option, but if you dynamically link freetype =
you just leave that up to the user.
--
Ignacio Casta=F1o
ica...@nv...=20
> -----Original Message-----
> From: gam...@li...=20
> [mailto:gam...@li...] On=20
> Behalf Of Brian Hook
> Sent: Monday, January 02, 2006 11:17 PM
> To: gam...@li...
> Subject: Re: [GD-General] FreeType
>=20
> > I believe the problem you are seeing is that the fonts are small
> > _and_ antialiased.=20
>=20
> Well, yeah. But un-antialiased and they look bad, just in a=20
> different=20
> way =3D)
>=20
> I ended up hacking a simple Python package that lets me render a=20
> string in a given font to a buffer, which I can then insert into a=20
> texture. I don't have the higher level string caching in place, but=20
> so far the results are very promising in terms of quality. =20
> The API is=20
> pretty brute force simple:
>=20
> import winfont
>=20
> f =3D winfont.createfont( 'Courier New', height=3D16,italic=3DTrue)
> buf,w,h =3D f.render('Hello world!',(255,255,255),(64,64,64))
> surf =3D pygame.image.fromstring( buf, w, h, "RGBX", True )
> pygame.image.save( surf, 'test.tga')
>=20
> I'll worry about the string caching and subtex modifications next and=20
> see if this is all everyone claims it is =3D)
>=20
> Brian
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep=20
> through log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. =20
> DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dick
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_idU7
>=20
|
|
From: Nick T. <ni...@ro...> - 2006-01-05 05:11:08
|
> PyGame.Font rendering when it's not available (or until I get off my > ass and write the same thing I just did for Windows for FT2 in C). Ft2.dll + ctypes ? http://starship.python.net/crew/theller/ctypes/tutorial.html Nick |
|
From: Brian H. <ho...@bo...> - 2006-01-05 05:45:19
|
that's pretty interesting looking, but realistically I would probably be able to get the FT2 font renderer extension working faster than I could sort out FT2 and ctypes, particularly with all the structs and what not that FT2 brandishes. Brian On Wed, 4 Jan 2006 21:10:45 -0800, Nick Trout wrote: > >> PyGame.Font rendering when it's not available (or until I get off >> my ass and write the same thing I just did for Windows for FT2 in >> C). >> > > Ft2.dll + ctypes ? > http://starship.python.net/crew/theller/ctypes/tutorial.html |
|
From: <bac...@ke...> - 2006-01-07 22:33:24
|
Sorry for my bad english... As I read this thread, I started thinking
about rewriting our text render engine... We render a lot of text, but
never though about rendering words instead of characters... at this
point, every Object in the game calls the render engine throu 2
functions: renderText, invalidateBuffer ... every time, something
changes, the invalidateBuffer function called, and only one flag for the
Object set... when the rendering starts, the window system starts
searching for visible objet.
At this point it's a little complicated so I go pseudo code :)
window system prerender loop:
for all objects
if(visible(object))
render->renderText(chache);
window system render loop:
for all objects
if(visible(object))
render->renderText(nochache);
renderText(cache)
if(cache)
{
if(!invalidbuffer)
{
cachebuffer(buffer);
}else
{
renderDataToBuffer();
}
}else
{
renderBuffer(buffer);
}
this way, if a text is unchanged, we have an
optimised(tristripped)vertex array, with some special attributes, to be
able to render a text with different fonts... but the idea is if we
render the text with colors, sizes, etc... to a buffer, and the text is
usually unchanged between frames, the only thing happening with the
graphics pipeline, is one call, wich copy's the buffer to the video card
memory, and if we know, the buffer will not change, we can even bind the
buffer up to the card...
My question is, can the render words algorithm be faster in the real
world, and more usable for a game, then our buffer algorithm? My problem
is when your text does not fit in a 2048x2048 texturemap... then you
have to store more than one texturemap, and switch between them... I
think while we are using windows :*((( cause the cost of the render
calls, we have to minimalize the calls made to the videocard...
What do you think about it?
Peter Balogh
bac...@ne...
Cheaf Programmer
Complete IT Bt.
Hungary
, and calls the renderText, with parameters to try to prechache the buffers
Brian Hook wrote:
> that's pretty interesting looking, but realistically I would probably
> be able to get the FT2 font renderer extension working faster than I
> could sort out FT2 and ctypes, particularly with all the structs and
> what not that FT2 brandishes.
>
> Brian
>
> On Wed, 4 Jan 2006 21:10:45 -0800, Nick Trout wrote:
>
>>>PyGame.Font rendering when it's not available (or until I get off
>>>my ass and write the same thing I just did for Windows for FT2 in
>>>C).
>>>
>>
>>Ft2.dll + ctypes ?
>
>
>>http://starship.python.net/crew/theller/ctypes/tutorial.html
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_idU7
>
>
|
|
From: Andras B. <and...@gm...> - 2006-01-05 04:12:40
|
> I think that the issues you are seen could be related to the > freetype autohinter. I got much better looking results with the > patented bytecode hinter. However, that was some time ago and since > then I've heard that the autohinter has become much better and > produces comparable results now. I have to admit, that I don't truly understand how this subpixel antialiasing wizardry works (anyone knows some good papers on this subject?), but if you look at anti-grain geometry: http://www.antigrain.com it can render some pretty amazing looking text using freetype, even though it's still not using "ClearType like" subpixel rendering (ehh, at this point I'm not even sure what is the correct definition for subpixel rendering..) Anyways, my biggest problem with ClearType text is that I couldn't yet figure out a way to apply such text (as stored in a texture) on top of arbitrary color image, because the edges might use 2/3 or 1/3 pixels.. It's just weird :) Anyone had any success with it? Andras |
|
From: Brian H. <ho...@bo...> - 2006-01-05 05:05:30
|
Upon further research the low quality may just be a side effect of using FreeType through SDL_ttf through PyGame.Font. By the time it reaches PyGame.Font 95% of the available features and options aren't exposed. For example, I don't believe there's a way for me to change the output to "LCD" instead of the current default grayscale output. At this point I'm 95% done with the Windows GDI font renderer extension for Python, so I'll stick with it and suffer through crappy PyGame.Font rendering when it's not available (or until I get off my ass and write the same thing I just did for Windows for FT2 in C). Brian |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X