gamedevlists-general

RE: [GD-General] DLLs for game objects

[Jeff L. <je...@SP...>]

> From:     Brian Hook <bri...@py...>
> Subject: [GD-General] DLLs for game objects

One thing that bears consideration is what you allow those external DLL's to
do.

Its gotta be cool to be able to wire in an external (3rd party) AI engine,
that would not be available from your scripting language.

And it certainly lends itself to user developed MODs.

The downside, from my opinion, tends to be at the mechanical level inside
the cross-DLL boundary.

You need to work *hard* to get C++ inheritance to work across DLL
boundaries.  (Consider your vorpal_sword : sword example)

You need to work *hard* to get C++ exceptions to work across DLL boundaries.

At least, in all previous attempts that we've made (in a non-game
environment), we had so much woe that we fell back on insisting that you
only have C interfaces, that return status values, rather than throw
exceptions.

Oh, and watch out for malloc'ing in one DLL, and free'ing in another - you
need a lot of discipline to ensure that all your DLL's - remember those
customer MODs - use a single, consistent, dynamic memory manager.

That'll be 2 cents please.

Jeff Laing <je...@sp...>
-----------------------------------------------------------------
"When your hammer is C++, everything begins to look like a thumb."
   - Steven Haflich, Franz, Inc.

RE: [GD-General] DLLs for game objects

[Brian H. <bri...@py...>]

>One thing that bears consideration is what you allow those=
 external
>DLL's to do.

Well, I'm thinking of this from a server side type of thing (a la=
 
MUDs), which I should have been more explicit about.

>You need to work *hard* to get C++ inheritance to work across=
 DLL
>boundaries.  (Consider your vorpal_sword : sword example)

Yes, agreed.

>You need to work *hard* to get C++ exceptions to work across=
 DLL
>boundaries.

Don't use them =3D)

>At least, in all previous attempts that we've made (in a=
 non-game
>environment), we had so much woe that we fell back on insisting=
 that
>you only have C interfaces, that return status values, rather=
 than
>throw exceptions.

Using straight up C has so many advantages that it's not funny,=
 that 
much I agree with.  Little things like transmitting networked=
 entity 
state just come off much more naturally using C than it does=
 trying 
to incorporate all the extra goodness that C++ theoretically 
supplies.

Sometimes monolithic is good.

Brian

RE: [GD-General] DLLs for game objects

[Tom H. <to...@3d...>]

At 02:38 PM 3/25/2003, you wrote:
> >One thing that bears consideration is what you allow those external
> >DLL's to do.
>
>Well, I'm thinking of this from a server side type of thing (a la
>MUDs), which I should have been more explicit about.

Personally, I can't stand DLLs. There's simply far too many problems with 
them and things you have to watch out for. For anything complex you 
invariably you end up painting yourself into a design corner when something 
comes up you didn't anticipate and you end up having to hack your way out 
in one way or another.

If I was interested in doing something like this (server side only makes 
this reasonable .. wouldn't suggest this for clients yet), with the goal of 
having lots of small dynamic "pieces" that could be fitted together at 
run-time in some form of OOP manner I'd be looking at C# and .NET as a 
solution. From what I've seen the stuff is built from the ground up to 
cleanly operate with a C/C++ engine, and C# "scripts".

If I using *nix as my platform, then I would look into the C# stuff that's 
being done there (I think it's called Mono), and if that didn't work, then 
I'd seriously consider going through the (relative) hell of JNI and using Java.

Failing that, I'd look at scripting languages like Lua, or just say to hell 
with it and do it all statically linked to a single executable.

Basically, anything is better than DLLs in my book ... There's a reason 
it's called DLL hell.

Tom

RE: [GD-General] DLLs for game objects

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

>Basically, anything is better than DLLs in my book ... There's=
 a
>reason it's called DLL hell.

Actually, I think the best language for this is easily Obj-C,=
 since 
it was pretty much designed with this in mind.  I would LOVE to=
 use 
Obj-C for something like this.

"DLL hell" is a blanket statement that isn't really valid. =
 Quake2 
used DLLs for game APIs, and without that it wouldn't have been=
 as 
easy to mod (well, there's always QuakeC as a counterpoint, but=
 it 
had its own set of problems).

If you're aware of the problems that DLLs present, then I don't=
 think 
you'll encounter many problems at all.  Just using the Quake 2=
 source 
code as an example:

- well defined import (from engine) and export (from DLL)
- API versioning to prevent problems

In the case of Quake 2, each DLL (ref and game) has exactly ONE 
function that is exported.  It can export anything it wants as=
 long 
as it adheres to the specified API in the import/export=
 structures.

Going to C++ is when you start introducing a lot of the confusion=
 and 
problems that have arisen, since C++ really isn't what I consider=
 a 
proper OOP language.  Types that are not first class objects=
 pretty 
much blows chunks for anything really dynamic (note: that's just=
 my 
opinion, no need to flame).

The reason I bring this up is that looking at each of the various=
 
"monster" files in Quake 2, it's apparent that there was a heavy=
 
Obj-C influence at work.  Each monster file had the required=
 "think" 
functions in it, then local functions accessible only by that 
monster, and "class variables" were statics.  With this in mind,=
 I 
realized that it would be trivial to convert each monster into a=
 
separate DLL.  

The rough gist is that at game startup, you could search all DLLs=
 and 
search for valid "monster files".  If GetProcAddress( "Spawn" ) 
succeeds, it's a valid monster file.  Then you call the Spawn 
function, it fills in a standardized struct, you pass it an=
 exported 
interface from the engine, and you're good to go.

Then you can dynamically load and unload monsters while a server=
 is 
running 24/7, assuming there are no interface changes (note: and=
 if 
there are, you're going to have bring down the server no matter=
 how 
you implement this).

So I thought that would be interesting, but not necessarily good,=
 so 
I decided to post to see what other people have done.  Quake is 
obviously much coarser (game DLL only), but I think it could have=
 
benefited from a slightly finer grain dynamic game mechanism=
 since a 
lot of what's in the game code can easily be shared across a=
 large 
number of mods but right now code has to be duplicated as a=
 result.

I'm not sold on the idea, mind you, so I'm not saying I advocate=
 
this, I'm just throwing it out there as food for discussion.

Brian

RE: [GD-General] DLLs for game objects

[Tom H. <to...@3d...>]

At 05:40 PM 3/25/2003, you wrote:
>Actually, I think the best language for this is easily Obj-C, since
>it was pretty much designed with this in mind.  I would LOVE to use
>Obj-C for something like this.

I think that pretty much the same could be said for C#, and I happen to 
like the syntax better ;) Objective-C, Java, and C# are all good dynamic 
languages that have their own individual problems.

(Skipping ahead, I think it could be tricky in all of these languages to 
unload a loaded type to load in an updated version from disk .. but I 
haven't looked that heavily into it).

>Going to C++ is when you start introducing a lot of the confusion and
>problems that have arisen, since C++ really isn't what I consider a
>proper OOP language.  Types that are not first class objects pretty
>much blows chunks for anything really dynamic (note: that's just my
>opinion, no need to flame).

C++ is definitely a problem with DLLs ... but even straight C has problems 
when you're passing around dynamically allocated memory between DLL and 
EXE, or multiple DLLs. There are solutions, as have been mentioned ... it's 
just something you always have to worry about, and it's easy for new 
programmers to your team to screw this up in painful, and possibly 
non-obvious to find, ways.

I don't think your Quake example applicable to this discussion given the 
very limited interactions you describe between components that kept these 
kind of issues at bay. I think if you start putting individual monsters 
into their own DLLs, you're going to find your passing structures and 
strings around all the time, and it will be far more easy to make a mistake 
or paint yourself into the "Oh hell, how do I free this thing cleanly" corner.

>The rough gist is that at game startup, you could search all DLLs and
>search for valid "monster files".  If GetProcAddress( "Spawn" )
>succeeds, it's a valid monster file.  Then you call the Spawn
>function, it fills in a standardized struct, you pass it an exported
>interface from the engine, and you're good to go.

This works as long as each monster is entirely self-contained. You run into 
issues when monsters inherit from other monster files, or if you have "sub 
monsters" ... ie ... a dog monster with a bunch of flee monsters attached 
to it.

These things are workable to varying degrees.

>Then you can dynamically load and unload monsters while a server is
>running 24/7, assuming there are no interface changes (note: and if
>there are, you're going to have bring down the server no matter how
>you implement this).

If a monster is 100% self-contained, without dependances on other 
dynamically loaded entities (and nothing depends on it) ... then something 
like this could be possible without too much headache.

>So I thought that would be interesting, but not necessarily good, so
>I decided to post to see what other people have done.  Quake is
>obviously much coarser (game DLL only), but I think it could have
>benefited from a slightly finer grain dynamic game mechanism since a
>lot of what's in the game code can easily be shared across a large
>number of mods but right now code has to be duplicated as a result.

You're trying to replicate the dynamic language features of Obj-C, Java, 
and C# in C. While you can do much of this, it's a heck of a lot of work 
and I doubt you'll be able to get is as clean and fast as what you can do 
with one of the other languages.

>I'm not sold on the idea, mind you, so I'm not saying I advocate
>this, I'm just throwing it out there as food for discussion.

If you're stuck with C only, then I think something like this sounds like 
something to really look into for dealing with dynamic objects, especially 
if your goal is to be able to change things around at run time.

Tom

RE: [GD-General] DLLs for game objects

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

On Tue, 25 Mar 2003 19:12:44 -0800, Tom Hubina wrote:
>At 05:40 PM 3/25/2003, you wrote:
>I think that pretty much the same could be said for C#, and I=
 happen
>to like the syntax better ;) Objective-C, Java, and C# are all=
 good
>dynamic languages that have their own individual problems.

<insert religious reasons why I hate C#>

>C++ is definitely a problem with DLLs ... but even straight C=
 has
>problems when you're passing around dynamically allocated=
 memory
>between DLL and EXE, or multiple DLLs. 

There will ALWAYS be problems when you have undisciplined or=
 sloppy 
programmers.  The important thing is finding the right balance 
between the two.  Laying down a real concrete policy up front is=
 the 
first step to avoiding any problems.

In fact, if you don't have a concrete policy on all memory 
management, you're probably pretty much asking for a world of=
 pain no 
matter what language or operating system you're running on.

>I don't think your Quake example applicable to this discussion=
 given
>the very limited interactions you describe between components=
 that

That's my point -- because Quake defined very limited=
 interactions, 
it's completely feasible.  If your interactions are encapsulated=
 into 
a pair of import and export callback tables, you greatly minimize=
 the 
chance of things exploding.

Since the returned values from the DLLs should be opaque pointers=
 or, 
at the worst, pointers to common headers, then the ONLY place=
 you'd 
have to really worry about things is freeing the actual object 
returned from the DLL.  That's it, and I think that's completely=
 
manageable.

>This works as long as each monster is entirely self-contained.=
 You
>run into issues when monsters inherit from other monster files,=
 or
>if you have "sub monsters" ... ie ... a dog monster with a bunch=
 of
>flee monsters attached to it.

This is definitely true.  Sub-classing with a DLL mechanism could=
 be 
tricky.

>If a monster is 100% self-contained, without dependances on=
 other
>dynamically loaded entities (and nothing depends on it) ...=
 then
>something like this could be possible without too much=
 headache.

My instinct is that this is pretty much a given in order to be 
workable.

>You're trying to replicate the dynamic language features of=
 Obj-C,
>Java, and C# in C. While you can do much of this, it's a heck of=
 a
>lot of work and I doubt you'll be able to get is as clean and=
 fast
>as what you can do with one of the other languages.

Possibly.  Except A.) I don't really like Java and C# that much,=
 and 
their run-times are exorbitantly expensive and B.) Obj-C is=
 really 
only usable on OS X.  So you can hack something using DLLs, and I=
 
think it's still workable.

>If you're stuck with C only, then I think something like this=
 sounds
>like something to really look into for dealing with dynamic=
 objects,
>especially if your goal is to be able to change things around at=
 run
>time.

Right.  I'm not saying it's perfect, but I do think it's an 
interesting approach.  You would have to establish some pretty 
serious ground rules up front, but it's very manageable and I=
 think 
it would probably be pretty effective for a limited subset of 
functionality.

Brian

[GD-General] FreeType

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

Any opinions on using FreeType for in-game fonts?  This would=
 seem 
(in theory) to be one way to handle part of the problems with 
interfaces and screen resolution.

I've looked over the docs and API, and so far it looks pretty=
 solid.  
The hardest problem is finding a font you can redistribute, but=
 there 
are lots of places that will license decent fonts for a fairly=
 small 
amount of money ($30).

This just seems much easier than forcing artists to make new=
 fonts 
from scratch for every game and/or screen resolution.

Brian

Re: [GD-General] FreeType

[Tom S. <to...@pi...>]

> Any opinions on using FreeType for in-game fonts?  This would
> seem (in theory) to be one way to handle part of the problems
> with interfaces and screen resolution.

    We we're using it at one point in a racing game, but i scrapped it as
our implementation with it was slow and at the time there was a patent issue
with FreeType's hinter.  We ended up replacing the entire system with a
simple bitmap font solution.  At the time we we're using FreeType2 and we
did have several memory leaks that we believe we're internal to it.  My
understanding is that all these issues have been corrected now.  If i we're
to do it again i would consider using FreeType to build the bitmap fonts at
startup, but allow for overloading that behavior if the bitmap already
exists in the game data.

    Tom

----- Original Message -----
From: "Brian Hook" <ho...@py...>
To: <gam...@li...>
Sent: Thursday, March 27, 2003 2:24 PM
Subject: [GD-General] FreeType


Any opinions on using FreeType for in-game fonts?  This would seem
(in theory) to be one way to handle part of the problems with
interfaces and screen resolution.

I've looked over the docs and API, and so far it looks pretty solid.
The hardest problem is finding a font you can redistribute, but there
are lots of places that will license decent fonts for a fairly small
amount of money ($30).

This just seems much easier than forcing artists to make new fonts
from scratch for every game and/or screen resolution.

Brian




-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
_______________________________________________
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

[<cas...@ya...>]

Tom Spilman wrote:
>     We we're using it at one point in a racing game, but i scrapped it as
> our implementation with it was slow and at the time there was a patent
issue
> with FreeType's hinter.  We ended up replacing the entire system with a
> simple bitmap font solution.  At the time we we're using FreeType2 and we
> did have several memory leaks that we believe we're internal to it.  My
> understanding is that all these issues have been corrected now.  If i
we're
> to do it again i would consider using FreeType to build the bitmap fonts
at
> startup, but allow for overloading that behavior if the bitmap already
> exists in the game data.

I've written a simple font engine based on FreeType2 recently, and I've
never had any problem with the FreeType2 library. The latest FreeType's
autohinter is as good as the patented one. I generate a bitmap font for each
page of unicode on request, and I use a font size that depends on the screen
resolution, it works fine, and I'm quite happy with it. The only problem so
far is that the generation of the font bitmaps is a bit slow, and if the
bitmap is generated on runtime it produces a small hiccup, but I'm planning
to cache on disk the fonts that have been generated recently to avoid that.


Ignacio Castaño
cas...@ya...

Re: [GD-General] FreeType

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

Thread necromancy!

I've started using FT2 via PyGame, and the font rendering...sucks.  
I'm sticking with Courier New on the Windows platform and generating 
glyphs, anti-aliased, into 

At least two problems have surfaced.  The first is that the fonts just 
don't look that good compared to the built-in Windows renderer, which 
presumably uses ClearType or something similar (using zoomin the 
difference is fairly obvious).  

The second problem, which is not FT2 specific, is that it seems that 
where I need to index my texels differs from driver to driver.  On 
some drivers I need to go from 0,0 to glyph.width,glyph.height, and on 
other drivers I need to offset those values by 0.5 texels.  Anyone 
else seen this?

Brian

Re: [GD-General] FreeType

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

Brian,

I'm not sure exactly where your problem is. Do the generated glyphs
look bad themselves? Or do they look bad only when rendered on screen?
Anyways, I used to have a pretty bad font renderer too, here are some
links that helped me perfect it:

About ClearType font rendering:
http://grc.com/ctwhat.htm
ClearType is absolutely great, but it only works in 2D pixel perfect
rendering, as soon as you get some perspective, or stretch, you are
gonna miss pixels, and it ruins the whole idea of ClearType. Another
problem is, that the Windows text renderer creates a true color image
for cleartype, and there's no alpha information. And it's not obvious
how to combine those 1/3 pixel parts when blending it on a non-solid
background..

About texture fonts:
http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=009649
Look for Jon's (jwatte) posts, the truth is with him. ;) I also
thought that glyph based rendering was the way to go, until I've found
this thread. Rendering entire words is definitely a superior approach.
Especially, if you need support for arabic, chinese or cirillic
languages. Windows text rendering is very fast, and async texture
uploads (via PBO) are very efficient.

About texture filtering:
http://www.mindcontrol.org/~hplus/graphics/opengl-pixel-perfect.html
And so far, I haven't seen any drivers that would not conform to this..

Oh, and here's a great utility to check that everything is pixel
perfect (much better than Windows' built-in magnifier):
http://magnifier.sourceforge.net/

Hmm, one more thing: when rendering text on top of a 3D scene, then
you'll need shadows to make the font readable in every situation. I
prefer one pixel thick crisp hard shadow around the text, but you can
also compute soft shadows easily during the texture generation. Now,
do this with a glyph based renderer. :)


Hope this helps,



Andras



Sunday, January 1, 2006, 9:03:41 PM, you wrote:

> Thread necromancy!

> I've started using FT2 via PyGame, and the font rendering...sucks.
> I'm sticking with Courier New on the Windows platform and generating
> glyphs, anti-aliased, into

> At least two problems have surfaced.  The first is that the fonts just
> don't look that good compared to the built-in Windows renderer, which
> presumably uses ClearType or something similar (using zoomin the
> difference is fairly obvious).

> The second problem, which is not FT2 specific, is that it seems that
> where I need to index my texels differs from driver to driver.  On
> some drivers I need to go from 0,0 to glyph.width,glyph.height, and on
> other drivers I need to offset those values by 0.5 texels.  Anyone
> else seen this?

> Brian

Re: [GD-General] FreeType

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

> I'm not sure exactly where your problem is. Do the generated glyphs
> look bad themselves? Or do they look bad only when rendered on
> screen?

They look bad, period.  This is a 128x256 texture of Courier New 
rendered with anti-aliasing.

http://bookofhook.com/shittyfonts.png

It just looks grim.  Maybe I'mm doing something horrible (I'm using 
Pygame.font to render, which uses FreeType2).

> bb=3Dget_topic;f=3D3;t=3D009649 Look for Jon's (jwatte) posts, the truth
> is with him. ;)

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 =3D)

That said, I'd still mightily consider it if it gets me away from this 
asstasticness I'm dealing with right now.

Also, I'm not quite sure what Jon was recommending in that thread -- 
every time a string needs to be rendered on screen, render it in its 
entirety into a texture?

Brian

Re: [GD-General] FreeType

[Ivan-Assen I. <iva...@gm...>]

PiBBbHNvLCBJJ20gbm90IHF1aXRlIHN1cmUgd2hhdCBKb24gd2FzIHJlY29tbWVuZGluZyBpbiB0
aGF0IHRocmVhZCAtLQo+IGV2ZXJ5IHRpbWUgYSBzdHJpbmcgbmVlZHMgdG8gYmUgcmVuZGVyZWQg
b24gc2NyZWVuLCByZW5kZXIgaXQgaW4gaXRzCj4gZW50aXJldHkgaW50byBhIHRleHR1cmU/CgpZ
b3UgY2FuIGxpdmUgd2l0aCBnbHlwaC1iYXNlZCBmb250cyBpZiB5b3Ugb25seSBuZWVkIEV1cm9w
ZWFuCmxhbmd1YWdlcyAtIGUuZy4gTGF0aW4sIExhdGluLXdpdGgtZnVubnktZ3V5cy1vbi10b3As
IEN5cmlsbGljIGFuZApHcmVlayAtIHRoYXQgaXMsIGlmIHlvdSBzdGljayB3aXRoIDEwMHMgb2Yg
Y2hhcmFjdGVycy4gVGhlcmUncyBubyB3YXkKaW4gaGVsbCB5b3UgY2FuIGZpdCBnbHlwaHMgZm9y
IGEgQ0pLIGxhbmd1YWdlICgxMDAwMHMpIGludG8gYW55IHNhbmUKYW1vdW50IG9mIHRleHR1cmUg
bWVtb3J5LiBTbyB3aGF0IHlvdSBkbyBpcyBhbGxvY2F0ZSBvbmUgb3Igc2V2ZXJhbAp0ZXh0dXJl
cyBhbmQgdXNlIHRoZW0gYXMgYSBjYWNoZSBmb3Igc3RvcmluZyByZW5kZXJlZCBlbnRpcmUgd29y
ZHMsIG9yCnBocmFzZXMsIG9yIHdoYXRldmVyIG1ha2VzIHNlbnNlIGluIHlvdXIgY2FzZS4gVXNl
IHNvbWUgc29ydCBvZiAyRAphbGxvY2F0b3IgdG8ga2VlcCB0cmFjayBvZiBmcmVlIHN1YnJlY3Rz
LCByZXRpcmUgdGhlIGxlYXN0IHJlY2VudGx5CnVzZWQgc3RyaW5ncyBvciB3aXBlIHRoZSBlbnRp
cmUgdGV4dHVyZSBjbGVhbiwgcmVidWlsZGluZyB3aGF0J3MKbmVlZGVkIGluIHRoaXMgZnJhbWUu
IFR3ZWFrIGFsbCBjb25zdGFudHMgaW52b2x2ZWQgdW50aWwgeW91IGRvbid0CnRyYXNoIHRoZSBj
YWNoZSB0b28gbXVjaCA6LSkKCkFuIGFkZGl0aW9uYWwgYmVuZWZpdCBpcyB0aGF0IHlvdSBnZXQg
c3VicGl4ZWwga2VybmluZyBnbHlwaC10by1nbHlwaCwKd2hpY2ggaXMgcmVhbGx5IGltcG9ydGFu
dCBmb3Igc21hbGwgdHlwZSBzaXplcy4K

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

Re: [GD-General] FreeType

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

Sunday, January 1, 2006, 10:58:59 PM, you wrote:

>> I'm not sure exactly where your problem is. Do the generated glyphs
>> look bad themselves? Or do they look bad only when rendered on
>> screen?

> They look bad, period.  This is a 128x256 texture of Courier New
> rendered with anti-aliasing.

> http://bookofhook.com/shittyfonts.png

I believe the problem you are seeing is that the fonts are small _and_
antialiased. If you look at how Windows renders small fonts, you will
notice that it either uses ClearType, which is basically subpixel
rendering, or, if ClearType is disabled, then it renders without
antialiasing. The problem is, that antialiasing works great for thick
fonts, because it smoothes the edges, but for very small fonts, it
will only make the curves appear more or less translucent. ClearType
on the other hand does not have this problem, because it can make
lines thinner without making them translucent.

So, if subpixel font rendering is not an option, then I would
recommend turning off antialiasing for small fonts.



Andras

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

[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

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

I'm not completely sure how PyGame works but this snippet of OpenGL Red Boo=
k
text was helpful to me when trying to get better 2D rasterisation.

" If exact two-dimensional rasterization is desired, you must carefully
specify both the orthographic projection and the vertices of primitives tha=
t
are to be rasterized. The orthographic projection should be specified with
integer coordinates, as shown in the following example:

gluOrtho2D(0, width, 0, height);

where width and height are the dimensions of the viewport. Given this
projection matrix, polygon vertices and pixel image positions should be
placed at integer coordinates to rasterize predictably. For example,
glRecti(0, 0, 1, 1) reliably fills the lower left pixel of the viewport, an=
d
glRasterPos2i(0, 0) reliably positions an unzoomed image at the lower left
of the viewport. Point vertices, line vertices, and bitmap positions should
be placed at half-integer locations, however. For example, a line drawn fro=
m
(x1, 0.5) to (x2, 0.5) will be reliably rendered along the bottom row of
pixels int the viewport, and a point drawn at (0.5, 0.5) will reliably fill
the same pixel as glRecti(0, 0, 1, 1).

An optimum compromise that allows all primitives to be specified at integer
positions, while still ensuring predictable rasterization, is to translate =
x
and y by 0.375, as shown in the following code fragment. Such a translation
keeps polygon and pixel image edges safely away from the centers of pixels,
while moving line vertices close enough to the pixel centers."

Can't say as I found a completely satisfactory solution yet though. After
watching a few interviews with Bill Hill at Microsoft on ClearView it galls
me that my FT2 fonts look so dodgy. I contemplated the possibility of a
fragment program based subpixel antialiaser, but don't know enough about ho=
w
TrueType works (to account correctly for hinting for example) to proceed at
the moment.

Another hassle I had was what to do if FSAA is forced (as in a driver
control panel).

Sorry if that's not much use to you Brian, a quick search turned up there
was an OpenGL renderer for PyGame (I think?) but wasn't sure if it was an
exclusive or standard thing.

As an aside you can check what your font smoothing mode in windows in
Display Properties->Appearance->Effects and there's a powertoy from MS to
tweak ClearType to your display which is handy.

On 1/2/06, Brian Hook <ho...@bo...> wrote:
>
> Thread necromancy!
>
> I've started using FT2 via PyGame, and the font rendering...sucks.
> I'm sticking with Courier New on the Windows platform and generating
> glyphs, anti-aliased, into
>
> At least two problems have surfaced.  The first is that the fonts just
> don't look that good compared to the built-in Windows renderer, which
> presumably uses ClearType or something similar (using zoomin the
> difference is fairly obvious).
>
> The second problem, which is not FT2 specific, is that it seems that
> where I need to index my texels differs from driver to driver.  On
> some drivers I need to go from 0,0 to glyph.width,glyph.height, and on
> other drivers I need to offset those values by 0.5 texels.  Anyone
> else seen this?
>
> 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://ads.osdn.com/?ad_idv37&alloc_id=16865&opclick
> _______________________________________________
> 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

[Jamie F. <ja...@qu...>]

We use it in our engine, although we render the font to a texture and then
use the texture.

Googling for free fonts brings up quite a few hits, although it can be hard
finding something free which has the style and quality you want.

Jamie


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Brian Hook
Sent: 27 March 2003 20:25
To: gam...@li...
Subject: [GD-General] FreeType


Any opinions on using FreeType for in-game fonts?  This would seem
(in theory) to be one way to handle part of the problems with
interfaces and screen resolution.

I've looked over the docs and API, and so far it looks pretty solid.
The hardest problem is finding a font you can redistribute, but there
are lots of places that will license decent fonts for a fairly small
amount of money ($30).

This just seems much easier than forcing artists to make new fonts
from scratch for every game and/or screen resolution.

Brian




-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
_______________________________________________
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

[Adrian C. <ce...@ce...>]

We've implemented on-the-fly font rendering to a texture using FreeType in
our engine and it works very well. The API is also very easy to use and well
documented.

----- Original Message -----
From: "Brian Hook" <ho...@py...>
To: <gam...@li...>
Sent: Thursday, March 27, 2003 10:24 PM
Subject: [GD-General] FreeType


Any opinions on using FreeType for in-game fonts?  This would seem
(in theory) to be one way to handle part of the problems with
interfaces and screen resolution.

I've looked over the docs and API, and so far it looks pretty solid.
The hardest problem is finding a font you can redistribute, but there
are lots of places that will license decent fonts for a fairly small
amount of money ($30).

This just seems much easier than forcing artists to make new fonts
from scratch for every game and/or screen resolution.

Brian




-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
_______________________________________________
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

[Tom H. <to...@3d...>]

At 12:24 PM 3/27/2003, you wrote:
>Any opinions on using FreeType for in-game fonts?  This would seem
>(in theory) to be one way to handle part of the problems with
>interfaces and screen resolution.

If you can represent the fonts you want with TrueType, then something like 
FreeType would probably work nicely for generating res specific font 
textures or geometry. The big problem is that Truetype fonts are outline 
fonts, so while they scale nicely, it isn't as easy to get nice colors, 
textures, and shading on the fonts as you can with a bitmapped font. Also, 
doing glows and such become more work as well.

Tom

Re: [GD-General] FreeType

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

>The big problem is that
>Truetype fonts are outline fonts, so while they scale nicely,=
 it
>isn't as easy to get nice colors, textures, and shading on the=
 fonts
>as you can with a bitmapped font.

That's a good point, but "easy" really depends on who you're=
 talking 
to.  Generating those effects programmatically would be fairly=
 easy 
to do, albeit not quite as nicely as an artist could do, but at=
 the 
same time artists aren't bogged down with hand drawn fonts at 
multiple resolutions with different effects, etc.

Brian