Jump to content
The Dark Mod Forums

[Implemented in 2.10] subtitles


ndk

Recommended Posts

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.

 

 

 

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.

 

for cyrillic enough ansi 1251, i.e. ansi. of course utf8 is better solution.

 

 

 

Link to comment
Share on other sites

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

Practice has shown:


const int numSounds = shader->GetNumSounds();

const int soundIndex = numSounds * diversity;

const char* const soundName = shader->GetSound(soundIndex);

 

 

So we can support subtitles for individual sounds. :)

Edited by ndk
Link to comment
Share on other sites

first post has been updated

 

+ added support of individual sounds

 

+ slightly reworked format of subtitles

 

Ah, thats good to know. I was thinking about "which particular sound the engine will play", not the "which sound maps to which sound file".

 

i think what xml is universal and extendable format. it easy to add new features as color, timing and other.

 

And so is the standard Doom3 def file format. I don't think it is a good idea to pull in yet-another-100K code just to have yet-another-text-parser, whatever format it is. So please rework your patch to use the def file format :) (I can do it, too, if it is too much work for you, but not before next week)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Ah, thats good to know. I was thinking about "which particular sound the engine will play", not the "which sound maps to which sound file".

 

 

 

And so is the standard Doom3 def file format. I don't think it is a good idea to pull in yet-another-100K code just to have yet-another-text-parser, whatever format it is. So please rework your patch to use the def file format :) (I can do it, too, if it is too much work for you, but not before next week)

 

where is interface to work with def file format?

 

 

 

Link to comment
Share on other sites

A "time" tag is the way to go, I think. So many seconds after the soundshader starts playing, the text switches.

 

Thinking about future situations, I wonder about cases where the player runs off. It might be good if the subtitles can't be seen if the volume goes to zero with distance (or maybe the color varies with volume?), but able to become visible again if the player walks back into hear-able distance again. Looks odd when the player runs far off but the text is still going.

What do you see when you turn out the light? I can't tell you but I know that it's mine.

Link to comment
Share on other sites

A "time" tag is the way to go, I think.  So many seconds after the soundshader starts playing, the text switches.  

 

Thinking about future situations, I wonder about cases where the player runs off.  It might be good if the subtitles can't be seen if the volume goes to zero with distance (or maybe the color varies with volume?), but able to become visible again if the player walks back into hear-able distance again.  Looks odd when the player runs far off but the text is still going.

in future we can take into consideration distance between player and sound source.

 

 

Link to comment
Share on other sites

no such class (1.02)

 

Sorry for the late response, I was offline a few days. I have put the two relevant files here:

 

http://bloodgate.com/mirrors/tdm/pub/missioninfo.zip

 

Although I am don't think they do what you want!

 

As for parsing def, the idDict is the object that stores info from "def" files internally, and it should contain the nec. code, although I have not looked through it on how to use it with a file of your choice. It uses a parser object, so presumable you set up the idParser object, then call repeatedly idDict::Parse(Parser) until the file ends.

 

Afterwards, you can query values from the idDict with Get(). (Just like you do normally GetFloat() etc)

 

If you need more info, just ask. And thank you for your work!

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Sorry for the late response, I was offline a few days. I have put the two relevant files here:

 

http://bloodgate.com...missioninfo.zip

 

Although I am don't think they do what you want!

 

As for parsing def, the idDict is the object that stores info from "def" files internally, and it should contain the nec. code, although I have not looked through it on how to use it with a file of your choice. It uses a parser object, so presumable you set up the idParser object, then call repeatedly idDict::Parse(Parser) until the file ends.

 

Afterwards, you can query values from the idDict with Get(). (Just like you do normally GetFloat() etc)

 

If you need more info, just ask. And thank you for your work!

 

as you see TDM do not uses own common parser. ID's parser too hard to use. may be it's time for implemention? i suggest again to choise format based on xml. :)

Edited by ndk
Link to comment
Share on other sites

as you see TDM do not uses own common parser.

 

Yeah, but I am not to blame for this one :) I guess the motivation behind was that to replicated the old file formats that are included in FMs, because:

 

Title: Some title

 

is more familiar to mappers than:

 

"title" "some title"

 

But definitely both are easier for humans than

 

<?xml version="1.0"?>

<mission_data ver="1">

<storage>

<title>Some title</title>

</storeage>

</mission_data>

 

ID's parser too hard to use. may be it's time for implemention? i suggest again to choise format based on xml. :)

 

Ugh, please no, see above :)

 

Apart from that, we'd rather fix some of the existing bugs than re-inventing parsing of text files. As said, I can looking into using the def file format for storage if you want.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Yeah, but I am not to blame for this one :) I guess the motivation behind was that to replicated the old file formats that are included in FMs, because:

 

 

 

is more familiar to mappers than:

 

 

 

But definitely both are easier for humans than

 

 

 

 

 

Ugh, please no, see above :)

 

Apart from that, we'd rather fix some of the existing bugs than re-inventing parsing of text files. As said, I can looking into using the def file format for storage if you want.

 

xml has some benefits:

1) arbitrarily nesting level of structs

2) flexible modifying

 

3) IMHO, strategically good to move from home-made data formats (even if we are talking about ID Software) to well known technology.

 

 

4) authors of mods is not so often engaged in editing descriptions of missions. it does not cause pain and suffering. small inconvenience exchanged to strongly typed data. it's good for support new features.

 

 

Link to comment
Share on other sites

Doesn't the engine already support localization via the lang files?

 

idLangDict imposes restrictions on key.

 

Why not just make use of that for subtitles?

 

because subtitles required support colors, style, time code.

 

Sure XML has it's advantages but what's the point in implementing it if subtitles are the only place where you use it?

 

why not?

 

 

 

 

 

Link to comment
Share on other sites

Are you saying the idLangDict class cannot be extended? Is it not included in the SDK? That would explain why you are set on implementing a separate parser.

 

At any rate, I've just done a quick test based on a hunch and it seems there's already support for colors...

 

post-1779-128695017461_thumb.jpg

 

And this was done using the old carat color changing trick from Quake 3. It still works...

 

    "#str_02916"    "Game ^1Saved..."

 

There's also a mod called Doom[CC], the 'CC' meaning closed captions. You might be able to contact the author for the source although I can't say it's going to aid you on your quest to support an extended character set.

Link to comment
Share on other sites

Are you saying the idLangDict class cannot be extended? Is it not included in the SDK? That would explain why you are set on implementing a separate parser.

 

mandatory requirement for the key name.

 

 

 

 

There's also a mod called Doom[CC], the 'CC' meaning closed captions. You might be able to contact the author for the source although I can't say it's going to aid you on your quest to support an extended character set.

Doom[CC] source is ugly. :)

Edited by ndk
Link to comment
Share on other sites

Just brainstorming here:

 

As our voice sets are "implemented" as simple entity defs, I think the subtitle sets should also be defined in these terms. The code can then just access the right entity def and use it's spawnargs to read out the subtitles.

 

Something along:

 

entityDef atdm:subtitles_english
{
 "language_name" "English" // to be displayed in the menu

 "sound"         "sound/voices/animal/horse/horse_death01.ogg"
 "english"       "Horse dying."

 "sound1"        "sound/voices/animal/horse/horse_death02.ogg"
 "english1       "Horse dying."
 "german1"       "Ein Pferd stirbt."

//.. and so on

 

Simply looping over all "sound" spawnargs of that entitydef (which can be read out without spawning such an entity) will yield a list that can be stored as key=>value (for easier lookup).

 

It might even be feasible (or better) to store the translations directly with the sound shaders. Or would that hinder translation too much?

 

The above scheme has the disadvantage that you have all languages at once (e.g. everyone needs to parse/store all languages even if they only use say German subtitles), but the advantage that you need to only once define the name of the sound. Another advantage is that you can easily fallback to English if the language is not defined for one sound.

 

Some questions:

 

* As for colors, I am not sure why subtitles need colors. I'd think they might need markup (bold?), but colors?

 

* Some might need multi-line definitions (if the sound is too long and needs to much text), but this also needs to be supported by the code and the GUI, too. Extending the format to understand "\nSomeTimeValue:" should be easy, tho. What other time codes are needed?

 

* Do translators need all texts for one language in a sep file, or can they live with everything at once in a huge file?

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Just brainstorming here:

 

As our voice sets are "implemented" as simple entity defs, I think the subtitle sets should also be defined in these terms. The code can then just access the right entity def and use it's spawnargs to read out the subtitles.

 

Something along:

 

entityDef atdm:subtitles_english
{
 "language_name" "English" // to be displayed in the menu

 "sound"         "sound/voices/animal/horse/horse_death01.ogg"
 "english"       "Horse dying."

 "sound1"        "sound/voices/animal/horse/horse_death02.ogg"
 "english1       "Horse dying."
 "german1"       "Ein Pferd stirbt."

//.. and so on

 

Simply looping over all "sound" spawnargs of that entitydef (which can be read out without spawning such an entity) will yield a list that can be stored as key=>value (for easier lookup).

 

It might even be feasible (or better) to store the translations directly with the sound shaders. Or would that hinder translation too much?

 

it's not convenient for third party.

 

 

 

The above scheme has the disadvantage that you have all languages at once (e.g. everyone needs to parse/store all languages even if they only use say German subtitles), but the advantage that you need to only once define the name of the sound. Another advantage is that you can easily fallback to English if the language is not defined for one sound.

sounds can be split into two categories: TDM sounds and FM sounds. as you see there is need to support more than one files.

 

Some questions:

 

 

 

* As for colors, I am not sure why subtitles need colors. I'd think they might need markup (bold?), but colors?

 

different events. look HL2 for example.

 

 

 

* Some might need multi-line definitions (if the sound is too long and needs to much text), but this also needs to be supported by the code and the GUI, too. Extending the format to understand "\nSomeTimeValue:" should be easy, tho. What other time codes are needed?

 

time codes not so critical.

 

 

 

* Do translators need all texts for one language in a sep file, or can they live with everything at once in a huge file?

 

must be support many files: [subtitles]x[language]x[FM].

 

 

 

 

in summary all my arguments are reduced to the DIP. we have a particular solution of particular problems (def, lang and so). i will write new parser but ideologically it is not good. :)

 

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

 

 

Edited by ndk
Link to comment
Share on other sites

reworked. url at first post. no new features.

 

Thanx, I am running out of time today, but I will look tomorrow!

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

since that time i learned a little more about engine. something is simplified. added rudimentary support for displaying multiple subtitles. maybe not the best solution but i not so much know gui scripts. perhaps listDef is better solution. first post is updated.

 

 

 

 

P.S. time to show subtitles is set to 20 sec. for testing

Edited by ndk
Link to comment
Share on other sites

since that time i learned a little more about engine. something is simplified. added rudimentary support for displaying multiple subtitles. maybe not the best solution but i not so much know gui scripts. perhaps listDef is better solution. first post is updated.

 

P.S. time to show subtitles is set to 20 sec. for testing

 

Thanx again, I must apologize for not looking into it. My new server here was more difficult to install than I imagine (now I know why I choose Ubuntu over Debian, its not 2 years behind the curve and much more user-friendly but I digres :D.

 

Will look into it tonight, when I have an evening off.

 

Edit: URL does not work, tried a few variations but comes up with 404.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
×
×
  • Create New...