TTS almost done

Hello readers, since the last blog post, the TTS project slowly but surely neared it's end. I added OSD message and GUI tooltip reading. We added the possibility to choose what should happen if the TTS gets request to read a message while another message is being read. So it can be added to a queue, it can just be ignored, or it can interrupt the current speech and get read instead (more actions, which depend on the first message in queue are possible). Before only interrupting the currently read message and reading the new one instead was possible. Me and Criezy (who implemented the macOS part) understood some actions differently, so right now the INTERRUPT_NO_REPEAT action, which will interrupt the current speech and delete the speech queue only if the new message is different than the currently spoken message behaves differently on Windows and Linux (it interrupts and deletes the queue if the last message in queue is different, not the currently spoken one.) Once I reimplement this action, the TTS will be ready for a pull request.

In the encoding project, I originally tried to program everything in an Encoding class I created in Common. But Criezy thought it would be better (and it is) to make an encoding conversion method in the OSystem and move all of the platform specific code there. So I reworked everything I had so far. Right now, the code is in a state, it is able to use every way of encoding conversion I wanted to use (iconv, SDL, Win32, TransMan). I even added Cyrillic to ASCII transliteration. Only problem seems to be multi byte encodings (UTF-16 and UTF-32). Because Win32 isn't able to work with UTF-32 at all (at least I didn't find a way to convert from / to UTF-32) so I use the U32String class for this. Another thing is endianness. Iconv and SDL uses BOM (byte order mark) at the begining of the string to specify in which endianness the string is, but the Win32 conversion (which uses U32String for UTF-32 and Win32 ansiToUnicode for UTF-16) and TransMan conversion don't use BOM. The plan is to remove the BOM and use the machine's native endianness or use a different endianness, but only when the programmer specifies (I assume, in such a case the programmer doesn't need the BOM, because he is the one who specified which endianness he wants)


Popular posts from this blog

Google Summer of Code summary

Project update