[Implemented in 2.10] subtitles

[ndk]

http://www.sendspace.com/file/q88fu6

[MoroseTroll]

Here we go . Ok, let's talk about the closed caption (CC) support in TDM. Like I said on TTLG, I think it would be nice to incorporate this feature into TDM. My reason is very simple: many non-English speaking people can't understand English speech, so the CC feature in TDM would help them to understand it, and I'm quite sure that this feature would expand TDM's audience all over the world.

 

My colleague from DarkFate.ru, ndk, has made an alpha-version of the CC support in TDM 1.02. If you are agree with me about the CC support for TDM, please test ndk's work and tell us here what do you think about it.

[Bikerdude]

@ tdm team

 

What are to ins and outs of this..?

[ndk]

uploaded initial version. look first post.

[Mortem Desino]

Interesting. Kind of opaque since I haven't seen the source code, but not a bad system at all, since it appears based on parsing soundshaders.

[greebo]

The dumb download site won't let me have the file, says another download is active from my IP.

[Fidcal]

I hate that utterly misnamed Easy-Share. Any enterprise that deliberately bases its service around being as difficult and unhelpful as possible to try to force you to take its paid for service I would avoid if possible.

 

I managed to get the download after a few minutes wasted and mirrored it to

 

http://www.fidcal.com/TEMP/tdm_subtitles_0002.zip

[ndk]

The dumb download site won't let me have the file, says another download is active from my IP.

 

fixed, see first post. source code will be later (may be at weekend).

[greebo]

Ah, I see, there's a precompiled game DLL. Can't test that right now, but I'll definitely look at the code when it's available.

[MoroseTroll]

So, what do you think, guys, about the implementation of this feature?

[Tels]

So, what do you think, guys, about the implementation of this feature?

 

Haven't looked at it, what exactly does it do? I read there is no source code, so what about documentation or at least a nice little 2 liner description?

[New Horizon]

So, what do you think, guys, about the implementation of this feature?

 

We'll have to test it first and see how it works. If it doesn't create any extra work for us, I'm sure we would be happy to include it.

[ndk]

see first post to get source code

[demagogue]

Is the ability to turn it on & off in the "Video" page of the Settings Menu?

 

I'm thinking about an FM with voice acting. I gather the mapper puts the text in the xml file with tags according to its soundshader name? What if it's a very long speech in one sound-file? Is there a way to break up the subtitles to go in tandem with the speech (like 3 frames for one speech switching at the proper time); so you don't have a long paragraph taking up half the screen?

 

If/when this system gets the green light, we'll need a wiki tutorial on how to implement it. (This is also a good way to get translations of voice acting into the game.)

[Tels]

Just a technical comment: I am sure we don't just want to insert a 220Kbyte patch to add yetr-another-xml-parser just to parse subtitles. (I am atm unsure if we already have an XML parser, I think we do. But even if we don't, a simpler format might be in order.)

[ndk]

 

Is the ability to turn it on & off in the "Video" page of the Settings Menu?

not yet, but in progress

 

 

 

I'm thinking about an FM with voice acting.  I gather the mapper puts the text in the xml file with tags according to its soundshader name?  What if it's a very long speech in one sound-file?

 

exactly

 

Is there a way to break up the subtitles to go in tandem with the speech (like 3 frames for one speech switching at the proper time); so you don't have a long paragraph taking up half the screen?

 

i see two way:

1) use specialized subtitles format like:

 

http://en.wikipedia....wiki/Timed_Text

 

 

http://en.wikipedia.org/wiki/SubViewer

 

http://en.wikipedia.org/wiki/SubRip

 

2) extend existing format with new tags/attributes

 

 

 

existing solution have some restriction:

 

1) sound shader can contain more that one sound.

 

2) impossible to share common subtitles (to prevent copypasted text).

 

 

[ndk]

Just a technical comment: I am sure we don't just want to insert a 220Kbyte patch to add yetr-another-xml-parser just to parse subtitles. (I am atm unsure if we already have an XML parser, I think we do. But even if we don't, a simpler format might be in order.)

 

but xml is universal format and 110kb of rapidxml is documentation

 

 

[Serpentine]

Hey ndk,

 

I think I was the one that told you to go run off and make this - I just wanted to say it's great to see something came of it, subs are an area I think are quite important.

Good to see the russian community taking an interest too, some great talent over there

 

As for the whole xml thing, I think a simpler format would be 'better', I havent looked/tested remotely like that but wouldn't it be possible to just use utf8 text files and store the sub in the shader itself as a comment or similar? I'm assuming doom3 hates parsing utf8 or something?

[ndk]

can someone explain me how to understand what the sound is played? shader may contain more than one sound and engine select sound for playing randomly.

[Tels]

can someone explain me how to understand what the sound is played? shader may contain more than one sound and engine select sound for playing randomly.

 

This is inside the closed parts of the engine AFAIK and we don't know which sound will be played.

[Tels]

As for the whole xml thing, I think a simpler format would be 'better', I havent looked/tested remotely like that but wouldn't it be possible to just use utf8 text files and store the sub in the shader itself as a comment or similar? I'm assuming doom3 hates parsing utf8 or something?

 

I am not sure that even parsing UTF-8 alone is sufficient, because AFAIK, D3 doesn't even have the ability to output UTF-8. It still thinks in 7 bit characters (well, 8 bit but many fonts don't even have the high-bit ISO 8859-1 characters).

 

As for the format, what is wrong with the standard D3 format:

 

english.txt:

 

"ai_level_5_alert" "The AI just snorted and made a crude remark relating to your mother to you."

 

german.txt

 

"ai_level_5_alert" "Der Wachmann lacht Dich aus und beleidigt deine Mutter."

 

It already works, it needs no new code, it can't contain new bugs, it's optimized etc etc. Humans already understand the old format, easy to edit, easy to read.

 

Why re-invent the wheel when we already have a working one? (UTF-8 might be an issue, but sooner or later the D3 parser will need to know about UTF-8 anyway, for the translated XDATA alone. Plus the whole UTF-8 output issue...)

[ndk]

offtopic: how about move all code into static library and link to dll? it's help use TDD for developing new features.

[MoroseTroll]

As for me, as a translator from English to Russian, the simpler format of CC, the better. But, of course, I do understand that the main goal is a simplicity for the FM-makers.

About the absence of Cyrillic symbols in Doom 3 fonts: I hope we (the Russian-speaking community) will solve this problem sooner or later.

Edited October 8, 2010 by MoroseTroll

[Mr Lemony Fresh]

Hey everyone, I know someone who has been helping me with my fm, and so far he has a rough dialogue interface going. If you frobb a living npc, It plays a sound while there is text on screen and when it's finished it brings on the next audio clip and the next bit of text. When you want to choose what to say, you use the mouse wheel to select something, then click to say it, which can either trigger an event or more options/npc dialogue. You can run away during the conversation at a moments notice.

 

He's done a good job on it, although he's a bit busy. If anyone wants to adopt it and finish off the code, contact me and I'll see if he'll part with it.

 

Btw, the reason I haven't mentioned his name is I think he wants to remain anonymous until the fm is released...

[Serpentine]

It already works, it needs no new code, it can't contain new bugs, it's optimized etc etc. Humans already understand the old format, easy to edit, easy to read.

 

Yeah this is what I meant, if we can do it using this in-shader def it'll be simple and wide-spread within a short period of time.

 

Why re-invent the wheel when we already have a working one? (UTF-8 might be an issue, but sooner or later the D3 parser will need to know about UTF-8 anyway, for the translated XDATA alone. Plus the whole UTF-8 output issue...)

 

The reason I was going for utf8 is mostly just an assumption that Cyrillic is better supported in it, I dont know if this is strictly true, but from what I've worked on previously it's always been seen as the best solution when supporting the Russian community. German and such are not a problem either way, but on the same hand I think that most German gamers have a pretty damn good command of English and this would be of a far lesser benefit in comparison.

 

But if we can do Cyrillic and output it, whatever's easiest and lightest will be the best.