cpp/openttd-patchpack/source Files · docs/HOWTO_compile_lang_files.txt

Files @ r13257:4c5b8120be59

Branch filter:

Location: cpp/openttd-patchpack/source/docs/HOWTO_compile_lang_files.txt

r13257:4c5b8120be59 2.2 KiB text/plain Show Annotation Show as Raw Download as Raw

rubidium

(svn r17776) -Codechange: [SDL] make "update the video card"-process asynchronious. Profiling with gprof etc. hasn't shown us that DrawSurfaceToScreen takes a significant amount of CPU; only using TIC/TOC it became apparant that it was a heavy CPU-cycle user or that it was waiting for something.
The benefit of making this function asynchronious ranges from 2%-25% (real time) during fast forward on dual core/hyperthreading-enabled CPUs; 8bpp improvements are, in my test cases, significantly smaller than 32bpp improvements.
On single core non-hyperthreading-enabled CPUs the extra locking/scheduling costs up to 1% extra realtime in fast forward. You can use -v sdl:no_threads to disable threading and undo this loss.
During normal non-fast-forwarded games the benefit/costs are negligable except when the gameloop takes more than about 90% of the time of a tick.
Note that allegro's performance does not improve with this system, likely due to their way of getting data to the video card. It is not implemented for the OS X/Windows video backends, unless (ofcourse) SDL is used there.
Funny is that the performance of the 32bpp(-anim) blitter is, at least in some test cases, significantly faster (more than 10%) than the 8bpp(-optimized) blitter when looking at real time in fast forward on a dual core CPU; it was slower.
The idea comes from a paper/report by Idar Borlaug and Knut Imar Hagen.

STRGEN USAGE
------------
This guide is only interesting for people who want to alter something
themselves without access to translator.openttd.org. Please note that
your compiled language file will only be compatible with the OpenTTD version
you have downloaded english.txt, the master language file, for. While this is
not always true, namely when changes in the code have not touched language
files, your safest bet is to assume this 'limitation'.
As a first step you need to compile strgen. This is as easy as typing
'make strgen'. You can download the precompile strgen from:
http://www.openttd.org/download-strgen

strgen takes as argument a txt file and translates it to a lng file, allowing
it to be used inside OpenTTD. strgen needs the master language file
english.txt to work. Below are some examples of strgen usage.

EXAMPLES
--------
Example 1:
if you are in the root of your working copy (svn code), you should type
strgen/strgen -s lang lang/english.txt
to compile englist.txt into english.lng. It will be placed in the lang dir

Example 2:
you only have the strgen executable (no working copy) and you want to compile
a txt file in the same directory. You should type
./strgen english.txt
and you will get and english.lng in the same dir

Example 3:
you have strgen somewhere, english.txt in /usr/openttd/lang and you want the
resulting language file to go to /tmp. Use
./strgen -s /usr/openttd/lang -d /tmp english.txt

You can interchange english.txt to whichever language you want to generate a
.lng file for.

STRGEN COMMAND SWITCHES
-----------------------
-v | --version
strgen will tell what svn revision it was last modified

-t | --todo
strgen will add <TODO> to any untranslated/missing strings and use the english
strings while compiling the language file

-w | --warning
strgen will print any missing strings or wrongly translated (bad format)
to standard error output(stderr)

-h | --help | -?
Print out a summarized help message explaining these switches

-s | --source_dir
strgen will search for the master file english.txt in the directory specified
by this switch instead of the current directory

-d | --dest_dir
strgen will put <language>.lng in the directory specified by this switch; if
no dest_dir is given, output is the same as source_dir