Page 3 of 4

Posted: 21 Jan 2007 09:53
by peter1138
Freetype has a specific define to enable better font hinting. It's disabled for most builds due to patents. Apple's patents, of course...

But this cannot be considered an OpenTTD bug.

Posted: 21 Jan 2007 09:58
by Bjarni
peter1138 wrote:Freetype has a specific define to enable better font hinting. It's disabled for most builds due to patents. Apple's patents, of course...

But this cannot be considered an OpenTTD bug.
Well, if I can figure out how to link against a library that improves the display compared to what I just did, it would be an issue for the binary releases.

Posted: 21 Jan 2007 10:56
by Bjarni
ok, I tried linking against freetype 2.3.0 (I had to compile that one myself)
See if this helped with the Japanese text.
Install instructions are the same as the last time.

This time I would also like if anybody are able to test this on OSX 10.3.9. This test is only to see if it works, on that version as well. Which language to use is of little interest. Even English will be good enough.

edit: oops, didn't make a universal binary. Uploading the right one

Posted: 21 Jan 2007 13:55
by Darkvater
It will not help unless you have enabled the TrueType when you have compiled the freetype library.

Code: Select all

  /*************************************************************************/
  /*                                                                       */
  /* Define TT_CONFIG_OPTION_BYTECODE_INTERPRETER if you want to compile   */
  /* a bytecode interpreter in the TrueType driver.  Note that there are   */
  /* important patent issues related to the use of the interpreter.        */
  /*                                                                       */
  /* By undefining this, you will only compile the code necessary to load  */
  /* TrueType glyphs without hinting.                                      */
  /*                                                                       */
  /*   Do not #undef this macro here, since the build system might         */
  /*   define it for certain configurations only.                          */
  /*                                                                       */
/* #define TT_CONFIG_OPTION_BYTECODE_INTERPRETER */

Posted: 21 Jan 2007 14:34
by ickoonite
Bjarni wrote:ok, I tried linking against freetype 2.3.0 (I had to compile that one myself)
Yeah, I rolled my own freetype 2.3.0 too. And that binary you have just compiled works the same as the one I made, so do we have a winner? :D (If needs be, I might be able to arrange a test on a 10.3 box.)
peter1138 wrote:Freetype has a specific define to enable better font hinting. It's disabled for most builds due to patents. Apple's patents, of course...
Darkvater wrote:It will not help unless you have enabled the TrueType when you have compiled the freetype library.
Well, I did not enable anything - I literally just did a ./configure && make. I realise we don't want to walk into some patent mindfield, but I don't think it's a problem:
freetype.org wrote:Is FreeType 2 Affected by the Patents?
The answer is no for any recent build of FreeType 2, since it comes with an ‘auto-hinting’ module that was specifically designed to completely ignore the TrueType bytecode instructions.
Straight from the horse's mouth.

Posted: 21 Jan 2007 14:40
by Bjarni
ickoonite wrote:
Bjarni wrote:ok, I tried linking against freetype 2.3.0 (I had to compile that one myself)
Yeah, I rolled my own freetype 2.3.0 too. And that binary you have just compiled works the same as the one I made, so do we have a winner? :D (If needs be, I might be able to arrange a test on a 10.3 box.)
I don't think you get the issue. Whenever I need a library, I need a universal one, which makes compiling them somewhat tricky. It's way easier to use the one Apple provide since they already did the hard work.

And it would be nice to get this tested on 10.3 as I don't have access any computer running that version anymore :(

Posted: 21 Jan 2007 17:40
by ickoonite
Bjarni wrote:I don't think you get the issue. Whenever I need a library, I need a universal one, which makes compiling them somewhat tricky. It's way easier to use the one Apple provide since they already did the hard work.
Right, I see. A universal static binary. That is a bit of a pain in the arse.

I suppose the thing to do is to have a look at what results Apple's shipped freetype library gives for other languages. If it's only Japanese that's crap (and probably Chinese as well, although that's not included yet, of course), then for the moment, it's probably just best to stick with compiling against the included library.

On a related note, is there an easy way to make it do anti-aliasing? If that worked, it would surely go a long way to make things look better on screen.

Posted: 21 Jan 2007 17:49
by Darkvater
ickoonite wrote:On a related note, is there an easy way to make it do anti-aliasing? If that worked, it would surely go a long way to make things look better on screen.
See this post just above. If the library included with OSX does not use it or their own auto-hinter it will not work. Based on the screenshots you showed it seems it's not.

Posted: 27 Jan 2007 16:31
by bazilio_lg
Hello. I'm from Ukraine and I want to use russian interface and chat in Russian when in multiplayer.
But the .deb (RC3 and RC4) packages seem to be compiled without freetype support.
Check this:

Code: Select all

bazilio@bazilio:~$ ldd /usr/games/openttd |grep type
bazilio@bazilio:~$ 
nothing of freetype.
Here's the full output:

Code: Select all

bazilio@bazilio:~$ ldd /usr/games/openttd
        linux-gate.so.1 =>  (0xffffe000)
        libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7ee2000)
        libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0xb7e31000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb7e1d000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb7dfa000)
        libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0xb7d40000)
        libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7d1a000)
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7be9000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7bde000)
        /lib/ld-linux.so.2 (0xb7f08000)
        libasound.so.2 => /usr/lib/libasound.so.2 (0xb7b1d000)
        libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7b19000)
        libdirectfb-0.9.so.25 => /usr/lib/libdirectfb-0.9.so.25 (0xb7ac2000)
        libfusion-0.9.so.25 => /usr/lib/libfusion-0.9.so.25 (0xb7abb000)
        libdirect-0.9.so.25 => /usr/lib/libdirect-0.9.so.25 (0xb7aac000)
        libvga.so.1 => /usr/lib/libvga.so.1 (0xb7a4c000)
I use Debian Etch.

Perhaps someone can build .deb with freetype support, it's kinda wrong when this new feature is not available. Or is there any manual on how to build a .deb package from OpenTTD source?

Posted: 27 Jan 2007 23:20
by Darkvater
It might be a static freetype library. Did you try using russian as input and specifying fonts?

Posted: 28 Jan 2007 01:42
by Quark
bazilio_lg wrote:Hello. I'm from Ukraine and I want to use russian interface and chat in Russian when in multiplayer.
If you can't make freetype work, then you can add rusianw.grf file to [newgrf-static] setcion in openttd.cfg
Also you can read that topic in russian about new UTF support.

Posted: 28 Jan 2007 08:46
by matthijs
Hmm, I might have forgotten to add freetype as a build dependency to freetype in the debian package. I remember thinking about it, but I'm not sure it actually happened. I'll check next week (busy right now).

Matthijs

Posted: 30 Jan 2007 00:41
by OzTrans
There was a mention (in another topic) that the sprite limit has been increased with 0.5.0 RC4. However, when starting a new game, I still get the message :

Code: Select all

Error : Tried to load too many sprites (#16383; max 16383)
Changes since RC3:
- Feature: Increase spritecache size to 2MB, will increase performance in games using newgrf files (r8218)
What is this all about ?

Posted: 30 Jan 2007 01:14
by glx
spritecache increase is not sprite limit increase ;)

The sprite limit has been increased in trunk though.

Posted: 30 Jan 2007 10:28
by Darkvater
glx wrote:spritecache increase is not sprite limit increase ;)
The spritecache does indeed has been increased in RC4. With a whole whopping 1 sprite ;)

For the above poster: the spritecache is a memory buffer that keeps used sprites there so you don't have to load them from disk. With 1MB this buffer was full really fast and you had to fetch the sprites from disk, which is much slower than from memory.

Posted: 31 Jan 2007 00:08
by OzTrans
... sprite limit ...
Are we going to see an increase of that sprite limit in the near future ? Just to what TTDPatch offers would do nicely, i.e 11'400+ per category (trains, road vehicles, ships, planes, houses and other).

Thanks for the explanation of the sprite cache.

Posted: 31 Jan 2007 00:15
by Rubidium
OzTransLtd wrote:Are we going to see an increase of that sprite limit in the near future?
glx wrote:... The sprite limit has been increased in trunk though.
but only increased up to 16 million for everything in total, i.e. there is no separation between 'categories'. I don't know how many categories TTDPatch has, so I cannot compare it with their sprite limit.

Posted: 31 Jan 2007 00:28
by DaleStan
TTDPatch has ... six categories[0]. Anyway, it's a total of 65535 sprites, including the 4900 TTD sprites.

[0] Three (other, trains, and RVs) at ~11k and three (ships, planes, houses) at ~8k.

Posted: 31 Jan 2007 00:29
by OzTrans
A high enough sprite limit in total regardless of category is better anyway; just TTDPatch has those categories with lower limits for each.
glx wrote: ... The sprite limit has been increased in trunk though. ...
I'm sorry to be a bit ignorant how things work in your world ... but is there a download available somewhere ?

Posted: 31 Jan 2007 00:44
by DaleStan
"trunk" is the source from which the nightlies are built: http://nightly.openttd.org