gamedevlists-general — List for discussing general game development issues

Re: [GD-General] ieee754 -0.0f?

[Jim T. <jim...@gm...>]

Brian,

Hmmm, are you sure about those values? It thought the following was true:

Zeroes are special in IEEE574 since there is an implicit leading 1 in the
mantissa for 754 (which makes it impossible to get zero regardless of which
exponent we choose). So there are special values for zeroes in 754,
similarily to how Inf and NaN are specially represented. Conviniently ,
positive zero is all zeroes and negative zero just have the high bit set.

+0.0f =3D 0x00000000
-0.0f =3D 0x80000000


I don't have VC6 here, but for VC7 on a regular P4 box the following
produces the expected results:

#include <cstdio>

void main()
{
    float a =3D 0.0f;
    float b =3D 0.0f/-1.0f;

    printf( "%f =3D 0x%8.8x\n", a, *(int*)&a );
    printf( "%f =3D 0x%8.8x\n", b, *(int*)&b );
}


/j


On 2/1/06, Brian Hook <ho...@bo...> wrote:
>
> On Wed, 01 Feb 2006 09:50:00 -0700, Andras Balogh wrote:
> > I know that -0.0f =3D=3D +0.0f is true, but the floating point
> > representation of the two numbers should be different, no?
>
> They are different, on an IEEE compliant system.  IEEE-754 has the
> high bit reserved for sign, such that on a 32-bit system you would
> have:
>
> -0.0 =3D 0xbf800000
> +0.0 =3D 0x3f800000
>
> > Shouldn't the negative zero have the sign bit set? Well, on my
> > machine -0.0 and 0.0 are bitwise equal!! What's going on here?
>
> You didn't mention the language or how you're generating those values.
> Using VC6 on a Pentium-M by setting global floats I get the correct
> and expected values.
>
> Brian
>
>
>
>
> -------------------------------------------------------
> 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://sel.as-us.falkag.net/sel?cmdlnk&kid=103432&bid#0486&dat=121642
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_idU7
>

Re: [GD-General] ieee754 -0.0f?

[Ash H. <hen...@gm...>]

Hi Andras,

I suspect you've got "Fast" floating point model selected in VS project
options (check in C++->Code Generation I think).
Running your code here with Strict or Precise gives:
-0.000000 =3D 80000000
but it falls down how you describe (00000000), with Fast selected.

(Turion 64 MSVC8 here).

Cheers.

-- Ash.

On 2/1/06, Andras Balogh <and...@gm...> wrote:
>
> > They are different, on an IEEE compliant system.
>
> Yeah, I know, that's why I'm surprised! :)
>
> > -0.0 =3D 0xbf800000
> > +0.0 =3D 0x3f800000
>
> These are -1.0f and +1.0f, but yeah, I've got the point.
>
> > You didn't mention the language or how you're generating those values.
> > Using VC6 on a Pentium-M by setting global floats I get the correct
> > and expected values.
>
> VS7.1 running on Athlon64, see source in previous post.
>
>
> thanks,
>
>
>
> Andras
>
>
> -------------------------------------------------------
> 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://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=3D557
>

Re: [GD-General] ieee754 -0.0f?

[Andras B. <and...@gm...>]

> They are different, on an IEEE compliant system.

Yeah, I know, that's why I'm surprised! :)

> -0.0 = 0xbf800000
> +0.0 = 0x3f800000

These are -1.0f and +1.0f, but yeah, I've got the point.

> You didn't mention the language or how you're generating those values.
> Using VC6 on a Pentium-M by setting global floats I get the correct
> and expected values.

VS7.1 running on Athlon64, see source in previous post.


thanks,



Andras

Re: [GD-General] ieee754 -0.0f?

[Andras B. <and...@gm...>]

I run this code:

float f = -0.0f;
void* p = *(reinterpret_cast<void**>(&f));
::printf("%f = %p\n", f, p);

And it prints all zeroes. For any other number I see the correct  
hexadecimal representation of the float number.


Thanks,

Andras



On Wed, 01 Feb 2006 10:32:28 -0700, Peter <pe...@to...> wrote:

> what is the context here?  If you're interpreting 0x80000000 (32 bit  
> int) as a 32-bit IEEE float it's -0.0f   and 0x00000000 is 0.0f.
>   Where are you seeing the -0.0f? In a debugger? I think you must be  
> seeing some idiosyncrasy of your development environment or toolchain.
>
> Andras Balogh wrote:
>
>> I know that -0.0f == +0.0f is true, but the floating point  
>> representation  of the two numbers should be different, no? Shouldn't  
>> the negative zero  have the sign bit set? Well, on my machine -0.0 and  
>> 0.0 are bitwise  equal!! What's going on here?
>>
>> thx,
>>
>>
>> Andras

Re: [GD-General] ieee754 -0.0f?

[Brian H. <ho...@bo...>]

On Wed, 01 Feb 2006 09:50:00 -0700, Andras Balogh wrote:
> I know that -0.0f =3D=3D +0.0f is true, but the floating point
> representation of the two numbers should be different, no?

They are different, on an IEEE compliant system.  IEEE-754 has the 
high bit reserved for sign, such that on a 32-bit system you would 
have:

-0.0 =3D 0xbf800000
+0.0 =3D 0x3f800000

> Shouldn't the negative zero have the sign bit set? Well, on my
> machine -0.0 and 0.0 are bitwise equal!! What's going on here?

You didn't mention the language or how you're generating those values.  
Using VC6 on a Pentium-M by setting global floats I get the correct 
and expected values.

Brian

Re: SPAM [GD-General] ieee754 -0.0f?

[Peter <pe...@to...>]

what is the context here?  If you're interpreting 0x80000000 (32 bit 
int) as a 32-bit IEEE float it's -0.0f   and 0x00000000 is 0.0f.
  Where are you seeing the -0.0f? In a debugger? I think you must be 
seeing some idiosyncrasy of your development environment or toolchain.

Andras Balogh wrote:

> I know that -0.0f == +0.0f is true, but the floating point 
> representation  of the two numbers should be different, no? Shouldn't 
> the negative zero  have the sign bit set? Well, on my machine -0.0 and 
> 0.0 are bitwise  equal!! What's going on here?
>
> thx,
>
>
> Andras
>

[GD-General] ieee754 -0.0f?

[Andras B. <and...@gm...>]

I know that -0.0f == +0.0f is true, but the floating point representation  
of the two numbers should be different, no? Shouldn't the negative zero  
have the sign bit set? Well, on my machine -0.0 and 0.0 are bitwise  
equal!! What's going on here?

thx,


Andras

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: [GD-General] scripting via COM?

[Chad A. <ae...@ae...>]

Hi Andras,

I've gone down that road before, and it wasn't very pretty.  That said, XPCOM 
isn't a bad solution.  Integrates with JavaScript and Python and perhaps others. 
  You compile your IDL files into type libraries and C++ headers which the 
scripting language can use to understand how to talk to various interfaces (via 
some platform-dependent assembly).  The main reason I never followed through was 
that it's kind of annoying to use language-independent interfaces that can't 
take advantage of X or Y features of the language people end up using.  (Take 
the DOM as an example.)

Good luck,
Chad

Andras Balogh wrote:
> Well, yeah, this is not really a game engine, although it's similar. The 
> big difference is that with a game engine, one could make a decision 
> that it will be scripted with Lua, and be done with it. In this case 
> however, customers will probably want to use our rendering services from 
> all kinds of different languages, so it would be preferable not to have 
> such binding limitations.
> 
> Do you have any other ideas, how I could make my objects available in a 
> way so it's usable by many languages, yet is simple to implement?
> 
> 
> Andras
> 
> brian sharon wrote:
> 
>> I don't think anyone has pointed this out yet, but COM objects are  
>> not inherently scriptable in and of themselves.  Anything scriptable  
>> by .NET, VB and other such languages has to implement IDispatch.  So  
>> adding scriptability to your engine won't be as simple as just  
>> deriving everything from IUnknown.  For starters, I'm guessing that  
>> all your methods that you wish to expose aren't already returning  
>> HRESULTs.
>>
>> Trying to implement game engine scriptability through COM Automation  
>> has to be just about the most painful way you could go.
>>
>> --brian
>>
>> On 26 Jan 2006, at 18:07, Andras Balogh wrote:
>>
>>> I've heard that you can use COM objects from .NET using some wrapper.
>>> My only problem with pure .NET is that not all customers are ready  
>>> to use it. I would like to have a package that you can use from  
>>> unmanaged C/C++ as well as from VB, Python, Lua, C#...
>>> Also, I definitely want to keep my engine in the unmanaged world.
>>>
>>> Thanks,
>>>
>>> Andras
>>>
>>> Jon Watte wrote:
>>>
>>>> If you want to be Microsoft specific (which COM is), then you  
>>>> probably would do better supporting the CLR (.NET). It is much  
>>>> richer, and there's a wide variety of languages that run within  the 
>>>> CLR. The development and debugging tools are also top-notch.
>>>> Cheers,
>>>>             / h+
>>>> Andras Balogh wrote:
>>>>
>>>>> Now, I believe that most decent scripting languages have some  kind of
>>>>> support to easily call into COM objects. So I was thinking: Wouldn't
>>>>> it be the best to just wrap my engine into a COM object, and then  the
> 
> 
> 
> -------------------------------------------------------
> 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://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
> 

Re: [GD-General] scripting via COM?

[Kent Q. <ken...@co...>]

If you need cross-language scripting capability, definitely consider 
using SWIG. (http://www.swig.org/)

The pain you'll go through getting SWIG to read your header files is a 
tiny fraction of the agony you'll feel implementing scriptable COM 
objects and teaching your customers to use them in various ways.

SWIG can generate bindings for everything from Python and Perl and Ruby 
to Java to C# to Lua.

I haven't used it myself, but it comes pretty highly recommended if this 
is the kind of problem you have.

    Kent


Andras Balogh wrote:

> Well, yeah, this is not really a game engine, although it's similar. 
> The big difference is that with a game engine, one could make a 
> decision that it will be scripted with Lua, and be done with it. In 
> this case however, customers will probably want to use our rendering 
> services from all kinds of different languages, so it would be 
> preferable not to have such binding limitations.
>
> Do you have any other ideas, how I could make my objects available in 
> a way so it's usable by many languages, yet is simple to implement?
>
>
> Andras

Re: [GD-General] scripting via COM?

[Andras B. <and...@gm...>]

Well, yeah, this is not really a game engine, although it's similar. The 
big difference is that with a game engine, one could make a decision 
that it will be scripted with Lua, and be done with it. In this case 
however, customers will probably want to use our rendering services from 
all kinds of different languages, so it would be preferable not to have 
such binding limitations.

Do you have any other ideas, how I could make my objects available in a 
way so it's usable by many languages, yet is simple to implement?


Andras

brian sharon wrote:
> I don't think anyone has pointed this out yet, but COM objects are  not 
> inherently scriptable in and of themselves.  Anything scriptable  by 
> .NET, VB and other such languages has to implement IDispatch.  So  
> adding scriptability to your engine won't be as simple as just  deriving 
> everything from IUnknown.  For starters, I'm guessing that  all your 
> methods that you wish to expose aren't already returning  HRESULTs.
> 
> Trying to implement game engine scriptability through COM Automation  
> has to be just about the most painful way you could go.
> 
> --brian
> 
> On 26 Jan 2006, at 18:07, Andras Balogh wrote:
> 
>> I've heard that you can use COM objects from .NET using some wrapper.
>> My only problem with pure .NET is that not all customers are ready  to 
>> use it. I would like to have a package that you can use from  
>> unmanaged C/C++ as well as from VB, Python, Lua, C#...
>> Also, I definitely want to keep my engine in the unmanaged world.
>>
>> Thanks,
>>
>> Andras
>>
>> Jon Watte wrote:
>>
>>> If you want to be Microsoft specific (which COM is), then you  
>>> probably would do better supporting the CLR (.NET). It is much  
>>> richer, and there's a wide variety of languages that run within  the 
>>> CLR. The development and debugging tools are also top-notch.
>>> Cheers,
>>>             / h+
>>> Andras Balogh wrote:
>>>
>>>> Now, I believe that most decent scripting languages have some  kind of
>>>> support to easily call into COM objects. So I was thinking: Wouldn't
>>>> it be the best to just wrap my engine into a COM object, and then  the

Re: [GD-General] scripting via COM?

[brian s. <bri...@gm...>]

I don't think anyone has pointed this out yet, but COM objects are  
not inherently scriptable in and of themselves.  Anything scriptable  
by .NET, VB and other such languages has to implement IDispatch.  So  
adding scriptability to your engine won't be as simple as just  
deriving everything from IUnknown.  For starters, I'm guessing that  
all your methods that you wish to expose aren't already returning  
HRESULTs.

Trying to implement game engine scriptability through COM Automation  
has to be just about the most painful way you could go.

--brian

On 26 Jan 2006, at 18:07, Andras Balogh wrote:

> I've heard that you can use COM objects from .NET using some wrapper.
> My only problem with pure .NET is that not all customers are ready  
> to use it. I would like to have a package that you can use from  
> unmanaged C/C++ as well as from VB, Python, Lua, C#...
> Also, I definitely want to keep my engine in the unmanaged world.
>
> Thanks,
>
> Andras
>
> Jon Watte wrote:
>> If you want to be Microsoft specific (which COM is), then you  
>> probably would do better supporting the CLR (.NET). It is much  
>> richer, and there's a wide variety of languages that run within  
>> the CLR. The development and debugging tools are also top-notch.
>> Cheers,
>>             / h+
>> Andras Balogh wrote:
>>> Now, I believe that most decent scripting languages have some  
>>> kind of
>>> support to easily call into COM objects. So I was thinking: Wouldn't
>>> it be the best to just wrap my engine into a COM object, and then  
>>> the

Re: [GD-General] scripting via COM?

[Andras B. <and...@gm...>]

I've heard that you can use COM objects from .NET using some wrapper.
My only problem with pure .NET is that not all customers are ready to 
use it. I would like to have a package that you can use from unmanaged 
C/C++ as well as from VB, Python, Lua, C#...
Also, I definitely want to keep my engine in the unmanaged world.

Thanks,

Andras

Jon Watte wrote:
> 
> If you want to be Microsoft specific (which COM is), then you probably 
> would do better supporting the CLR (.NET). It is much richer, and 
> there's a wide variety of languages that run within the CLR. The 
> development and debugging tools are also top-notch.
> 
> Cheers,
> 
>             / h+
> 
> Andras Balogh wrote:
> 
>> Now, I believe that most decent scripting languages have some kind of
>> support to easily call into COM objects. So I was thinking: Wouldn't
>> it be the best to just wrap my engine into a COM object, and then the
> 
> 

Re: [GD-General] scripting via COM?

[Jon W. <hp...@mi...>]

If you want to be Microsoft specific (which COM is), then you probably 
would do better supporting the CLR (.NET). It is much richer, and 
there's a wide variety of languages that run within the CLR. The 
development and debugging tools are also top-notch.

Cheers,

			/ h+

Andras Balogh wrote:

> Now, I believe that most decent scripting languages have some kind of
> support to easily call into COM objects. So I was thinking: Wouldn't
> it be the best to just wrap my engine into a COM object, and then the

-- 
-- The early bird gets the worm, but the second mouse gets the cheese.

[GD-General] Re: scripting via COM?

[Andras B. <and...@gm...>]

I forgot to mention, that I'm mainly interested in extending scripting
languages, not embedding them. So the entrypoint is in the script, and
it just uses the services of the engine to do low level stuff.


Andras

Wednesday, January 25, 2006, 9:09:45 PM, you wrote:

> My biggest annoyance with scripting has always been somehow exporting
> my C++ classes and functions to the scripting languages. I know that there
> are tools to help with this, but I never really liked any of them.
> They are always a pain to setup and use, and the binding is too rigid.

> Now, I believe that most decent scripting languages have some kind of
> support to easily call into COM objects. So I was thinking: Wouldn't
> it be the best to just wrap my engine into a COM object, and then the
> scripting language just makes calls into it through COM? This would
> also make the binding between the scripting and the engine much more
> dynamic. So it would be possible to use the same engine from virtually
> any scripting language that can access COM objects.

> I'm not terribly experienced in scripting, so it's possible that I'm
> missing out on a lot of important issues..
> What are your thoughts on this?




> Andras

[GD-General] scripting via COM?

[Andras B. <and...@gm...>]

My biggest annoyance with scripting has always been somehow exporting
my C++ classes and functions to the scripting languages. I know that there
are tools to help with this, but I never really liked any of them.
They are always a pain to setup and use, and the binding is too rigid.

Now, I believe that most decent scripting languages have some kind of
support to easily call into COM objects. So I was thinking: Wouldn't
it be the best to just wrap my engine into a COM object, and then the
scripting language just makes calls into it through COM? This would
also make the binding between the scripting and the engine much more
dynamic. So it would be possible to use the same engine from virtually
any scripting language that can access COM objects.

I'm not terribly experienced in scripting, so it's possible that I'm
missing out on a lot of important issues..
What are your thoughts on this?




Andras

[GD-General] CATRuntime and animation engine

[jason z. <dir...@21...>]

SGksDQogICAgIERvZXMgYW55Ym9keSBrbm93IENBVFJ1bnRpbWU/IEl0IGNhbiBiZSBpbnRlZ3Jh
dGVkIGludG8gYSBnYW1lIGVuZ2luZSBhbmQgZG8gYSANCm11Y2ggYmV0dGVyIGFuaW1hdGlvbiB3
aXRoIG5vbi1zbGlkaW5nIGZvb3RzdGVwcyBhbmQgSUssIGFjY29yZGluZyB0byB3aGF0IHRoZXkg
c2F5IGluOg0KaHR0cDovL3d3dy5jYXRvb2xraXQuY29tL3Byb2R1Y3RzL0NBVFJ1bnRpbWUvZGVm
YXVsdC5hc3ANCiAgICBJdCBzZWVtcyBwb3dlcmZ1bCBhbmQgcHJvbWlzaW5nIHRvIG1lLiBTbyBJ
J20gaW50ZXJlc3RpbmcgaW4gYW55IGNvbW1lbnRzDQphbmQgYW55IG90aGVyIHNpbWlsYXIgc29s
dXRpb25zLg0K

Re: [GD-General] Was: FreeType

[<bac...@ke...>]

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
> 
> 

RE: [GD-General] FreeType

[Brian H. <ho...@bo...>]

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

RE: [GD-General] FreeType

[Nick T. <ni...@ro...>]

> 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

Re: [GD-General] FreeType

[Brian H. <ho...@bo...>]

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

Re: [GD-General] FreeType

[Andras B. <and...@gm...>]

> 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

Re: [GD-General] FreeType

[Chad A. <ae...@ae...>]

Brian Hook wrote:
> Unfortunately there is no clean way in Python to call into Windows and 
> do all GDI stuff and call back out unless I write that myself.  Which 
> I'm not sure I'm eager to do on the off chance it does look better =)
> 
> That said, I'd still mightily consider it if it gets me away from this 
> asstasticness I'm dealing with right now.

You probably can do what you want with win32all ( 
http://starship.python.net/crew/mhammond/ ).  We do a fair amount of Win32 
programming in Python, and it's not as weird or painful as you might think...

RE: [GD-General] FreeType

[Ignacio C. <ica...@nv...>]

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

Re: [GD-General] FreeType

[Brian H. <ho...@bo...>]

> I believe the problem you are seeing is that the fonts are small
> _and_ antialiased. 

Well, yeah.  But un-antialiased and they look bad, just in a different 
way =3D)

I ended up hacking a simple Python package that lets me render a 
string in a given font to a buffer, which I can then insert into a 
texture.  I don't have the higher level string caching in place, but 
so far the results are very promising in terms of quality.  The API is 
pretty brute force simple:

import winfont

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')

I'll worry about the string caching and subtex modifications next and 
see if this is all everyone claims it is =3D)

Brian

Re: [GD-General] FreeType

[Andras B. <and...@gm...>]

> You can live with glyph-based fonts if you only need European
> languages - e.g. Latin, Latin-with-funny-guys-on-top, Cyrillic and
> Greek - that is, if you stick with 100s of characters.

Yes, you could. But if you have to use multiple font faces in
different sizes (or, just want to use a huge font size), then it might
take up quite some texture memory to store all the glyphs. Whereas
with the other approach, a texture the size of your window should be
plenty, and you have no restrictions on what kind of font you use. Of
course, you could generate the glyphs on demand too, but at that
point, you are really not too far from word rendering.. Also,
shadowing is more difficult and more expensive to do right with
glyphs. YMMV..


Andras