Fixes for Portuguese Carmageddon

[madebr]

The Portuguese Carmageddon segfaulted because its character set caused signed characters to access out-of-bounds memory.

I also added a few fixes for warnings/errors seen in rec2.

Fixes #352

[PierreMarieBaty]

A possibly related problem: the French version of Carmageddon has text file translations in which accentuated characters over ASCII value 127 are used. This is clearly a mistake from the translator as no corresponding glyphs can represent these characters, but it makes an assertion fail in src/DETHRACE/common/utility.c in the GetALineWithNoPossibleService() function:

    } while (!isalnum(s[0]) // <-- assertion failure
        && s[0] != '-'
        && s[0] != '.'
        && s[0] != '!'
        && s[0] != '&'
        && s[0] != '('
        && s[0] != '\''
        && s[0] != '\"'
        && s[0] >= 0);

When ignoring the assertion, the game runs, but these characters are displayed as blank in the game messages (note that this is consistent with the DOS version).

[madebr]

Using current dethrace master, I don't see glyph related issues with dethrace, using this French game data from archive.org.

(I see a crash on Linux because the audio backend cannot handle audio files with wrong cases)

[madebr]

The last commit fixes the crash due to some French audio files having a wrong casing.

[PierreMarieBaty]

Don't you see missing characters in the menu dialogs where accentuated characters should be used ? https://freeimage.host/i/J7zfjYQ On my version, accentuated characters are missed out, and the "unbreakable space" used by the translator before colons (such as in "xxx<here>: yyy" yields a black block. Another character provokes a carriage return and sometimes a crash. If you don't see such things, then I guess there were several releases of the game in french and I have an early one...

…

Message ID: ***@***.***>

[madebr]

Oh yes, now I see it. I was expecting a crash and did not read all texts.
Muscle memory knows what buttons to press :)

So yes, this pr will fix these messages.

[madebr]

I was wrong, the à in "Retourner à la vie de tous les jours, péniblement calme?" is still missing.

[madebr]

DATA/TRNSLATE contains this:

QUT3STIL,164,34,1,C,L,QUITTER
QUT3STIL,164,80,1,C,L,RETOURNER  LA VIE 
QUT3STIL,164,91,1,C,L,DE TOUS LES JOURS, 
QUT3STIL,164,102,1,C,L,P<C9>NIBLEMENT CALME?
QUT3STIL,116,130,2,C,L,ANNULER
QUT3STIL,213,130,2,C,L,O.K.

(The format is <FLICNAME>,<x>,<y>,<font>,<just>)

So apart from explicitly doing a strcmp, I don't think we can't fix this.
The translators forgot to add the "À".

When I manually modify the file (by adding hexcode 0xc0), it works:

[PierreMarieBaty]

Good point. But there's more to it than just this occurence. See for example DATA/RACES.TXT line 102 (fourth race) situation<A0>: mine du canyon du diable This will display a black block instead of the non-breakable space. And other characters in other places... As soon as the character gets over 0x80 it's likely to not be rendered correctly.

…

Message ID: ***@***.***>

[madebr]

I see the missing whitespace before the colon for the 4th race.
I think it's not too unreasonable for dethrace to require correct input data (as long as it does not crash).
If you want these fixed, I think that works need to be done in a patch set, served by moddb.com or rr2000.

[PierreMarieBaty]

TBH I don’t care as I already patched all my French data files. I was just reporting the problem as it’s something I’ve come across and I thought other people would encounter too. Anyway, defaulting a character to a space (or to nothing) and emitting a console warning when it’s not among the drawable glyphs of the selected font is a quick fix, and would improve the robustness of the app. That’s the way I’d choose in my own code.

[madebr]

Printing a warning is not unreasonable, but we need to be careful to not spam the console.
In some places, carmageddon will draw text every frame.

[dethrace-labs]

what is this doing?

[madebr]

I silences a warning about setting a variable, but not using it.
It's probably better to just remove the a = thing.

[dethrace-labs]

what behavior does this fix?

[madebr]

This fixes StripControls for localized Carmageddon.
e.g. the French version calls this function with the input [NON ATTRIB]\r\n (for the key names in the controls menu).
When you remove the control character at location 12, in the next loop iteration the length of the string is reduced by 1, but you need to also retest the same i index (because it now contains the next character).

Without the fix, this function returns [NON ATTRIB]\n instead of [NON ATTRIB].
This results in the following:

Including this fix, the following options menu is displayed:

The actual behavior is undefined, since the address sanitizer triggers due to buffer overflow.