Discussion:
2.0.1 alpha 73
(too old to reply)
Josef Drexler
2006-02-14 03:00:04 UTC
Permalink
This time I'm not even going to mention the beta. Just get the latest
alpha at http://www.ttdpatch.net/src/

Lots of bugs and crashes have been fixed again. Some may not be fixed, in
particular I haven't been able to reproduce the "weird text" problem that
has been reported, and until I can reproduce it I probably can't fix it.
As for the DOS version, there are some indications that the crashes at
start are fixed, although I still have no idea what caused them or what
fixed them...

The only new feature in alpha 73 is complete Unicode support: it is now
possible to load glyphs (character symbols) for any Unicode character, and
use it by encoding text strings with UTF-8. This allows TTD and TTDPatch
to be translated into languages whose characters don't normally exist in
TTD (even Japanese or Chinese... if someone makes the necessary fonts).

Anyway, enjoy the new version.

Josef.


All changes in 2.0.1 alpha 73:
- made callback 33 takeoff sound work for helicopters
- fixed vehicles being unable to enter enhanced tunnels
- fixed bug in DOS crash logger occasionally writing giant crash log
- by stevenh:
* fixed crash when displaying tram bridges
* fixed bridge display problem if trams on but buildonslopes off
* when removing a bridge, tram tracks under it stay
* repaired rv and tram depot finding
* misc. graphical fixes for tram tracks on bridges and in tunnels
- (devel) added -xt option to OpenWatcom to prevent DGROUP overflow
- by Csaba:
* added industry variable 60 to get tile IDs
* added industry variable 23: industry remove cost multiplier
* allow lumber mill to have two output types
* added callback 3B to control special industry effects
* new industry var 61 to get random bits of an industry tile
* allow industry production callback to have some state information
- defined language ID 3F to match any language setting
- finished UTF-8 support and font glyph loading (action 12)
- made higherbridges and grf helper window texts translatable
- fixed crash with enhancetunnels on if no newgrf files loaded
- fixed crash with multiple station IDs in one action 3
- reduced newplanes/newships/newhouses sprite limits to stay within 64K
sprite limit
--
Josef Drexler | http://jdrexler.com/home/
---------------------------------+---------------------------------------
Please help Conserve Gravity | Email address is *valid*.
Play Hockey, not Baseball. | Don't remove the "nospam" part.
Marcin Grzegorczyk
2006-02-15 14:20:04 UTC
Permalink
Post by Josef Drexler
The only new feature in alpha 73 is complete Unicode support
Well, not really complete: limited to Plane 0, no bidi support, no
combining character support ;-)

But seriously, what TTDPatch really lacks now is a Unicode support in
the keyboard handler. Hmm, that's going to be rather difficult -- the
existing code assumes 1 byte per character throughout (and DOS version
assumes 1 character per key).
--
Marcin Grzegorczyk
Josef Drexler
2006-02-16 02:38:05 UTC
Permalink
Post by Marcin Grzegorczyk
Post by Josef Drexler
The only new feature in alpha 73 is complete Unicode support
Well, not really complete: limited to Plane 0, no bidi support, no
combining character support ;-)
Well, yes, it's UCS Level 1.
Post by Marcin Grzegorczyk
But seriously, what TTDPatch really lacks now is a Unicode support in
the keyboard handler. Hmm, that's going to be rather difficult -- the
existing code assumes 1 byte per character throughout (and DOS version
assumes 1 character per key).
It think it may be easier to implement that at the text input level.
That's really the only place it matters. I'm not sure how to design it
though. In Linux I create my non-standard characters with the "combine"
key, e.g. the sequence <combine " a> becomes ä. Something like that
would be workable, but won't support all needed characters.
--
Josef Drexler | http://jdrexler.com/home/
---------------------------------+---------------------------------------
Please help Conserve Gravity | Email address is *valid*.
Boycott multistory buildings. | Don't remove the "nospam" part.
Daan
2006-02-16 10:40:50 UTC
Permalink
Post by Josef Drexler
It think it may be easier to implement that at the text input level.
That's really the only place it matters. I'm not sure how to design it
though. In Linux I create my non-standard characters with the "combine"
key, e.g. the sequence <combine " a> becomes ä. Something like that
would be workable, but won't support all needed characters.
Ehh? this works already like that in the windows version on winxp? If I
type "+A I get ä in ttdpatch. Or do you want to make it work like that
for the dos version of the patch?
Marcin Grzegorczyk
2006-02-16 13:30:06 UTC
Permalink
Post by Daan
Post by Josef Drexler
That's really the only place it matters. I'm not sure how to design it
though. In Linux I create my non-standard characters with the "combine"
key, e.g. the sequence <combine " a> becomes ä. Something like that
would be workable, but won't support all needed characters.
Ehh? this works already like that in the windows version on winxp? If I
type "+A I get ä in ttdpatch. Or do you want to make it work like that
for the dos version of the patch?
There are several separate issues here.

For the Windows version, the Windows keyboard driver takes care of
converting key combinations to characters. However, TTD uses
byte-oriented Win32 API, so it always gets characters in the active
Windows code page (which supports only a limited set of characters and,
depending on what the active code page is, may be slightly or radically
different from what TTD displays). Fixing this shouldn't be hard in
principle -- just use Unicode API instead, and convert to single bytes
(or UTF-8) as necessary. What may be messy is text input, since we need
a way to avoid mixing TTD's native code page with UTF-8.

For the DOS version, the problem is completely different, since DOS TTD
handles keyboard itself at a very low level. I think the only
reasonable solution is to rewrite the existing TTDPatch's keyboard
handler extension (probably replacing the original handler entirely),
add Unicode support to ttdpatch.kbd and store the last pressed key's
Unicode character separately from the one-byte character (the former
would be accessed only by the text input field; also, I guess we could
use some otherwise-unused code in the range 0x01..0x1F to signal an
unmappable Unicode character to the byte-oriented code). The need to
avoid mixing UTF-8 with pre-existing native strings is the same here.

The 'combine' solution could be a later addition to this model, but
AFAIK the key-combo input method tends to be more common, so it should
be supported first. (It's also easier to support IMHO, as it's stateless.)
--
Marcin Grzegorczyk
Josef Drexler
2006-02-16 15:57:08 UTC
Permalink
Post by Daan
Post by Josef Drexler
It think it may be easier to implement that at the text input level.
That's really the only place it matters. I'm not sure how to design it
though. In Linux I create my non-standard characters with the "combine"
key, e.g. the sequence <combine " a> becomes ä. Something like that
would be workable, but won't support all needed characters.
Ehh? this works already like that in the windows version on winxp? If I
type "+A I get ä in ttdpatch. Or do you want to make it work like that
for the dos version of the patch?
That's because you're using the dutch keyboard setting which has " as a dead
key. The "compose" key is more general though, for example <compose , c>
gives me ç, <compose = C> gives me €, <compose 1 2> is ½, and <compose a e>
is æ, and thousands more variations like that.
--
Josef Drexler | http://jdrexler.com/home/
---------------------------------+----------------------------------------
Please help Conserve Gravity | Email address is *valid*.
Play Chess, not Basketball. | Don't remove the "nospam" part.
Loading...