doom2d.org

Некорректно отображаются названия папок и ресурсов в игре.

_________________
Давай, картечью демонов
Размажем по стене.
Давай, берсерком выпустим
Весь ливер сатане!
Сделайте нормальный огнемёт!

Только рисует криво? Загружает нормально?

Надо уточнить, не делает ли фпц конвертирование/детект кодировки за нас. А то может там двойная работа делается.
Если не детектит, то надо проверять LC_CTYPE на пинусах/никсах. На ведре и маке всегда можно форсить utf-8. Как там делается с виндой я хз, надо будет экспериментировать.

Очень хорошо, что ты выложил скрин, потому что теперь стало понятно то, чего не было понятно по сообщению в чате.
Такие строки (с большим количеством символов "Р") обычно появляются, если текст в UTF-8 выводится как будто бы он в однобайтовой ANSI-кодировке.

Буквально позавчера человек с похожей проблемой просил помощи в разделе техподдержки нашего Discord-канала, где он показал вот такой лог:

Вопросительные знаки в путях означают, что где-то побилась кодировка. Хотя, конечно, дело может быть просто в том, что он прямиком из консоли текст копировал. У него при этом русская Windows 10, однако он признался, что ставил себе английский языковой пакет. Так что пока это всё же самое логичное предположение о причине ошибки.

По поводу консоли - вероятно, стоит поиграться с SetTextCodePage() и выставлять принудительно ей кодировку в 1251. По поводу строк - можно, конечно, врубить нечто вроде SetMultiByteConversionCodePage(). Но если поступать по уму, то надо сделать как я вот здесь описывал. Однако это имеет смысл делать лишь вместе с преобразованием в UTF-8 всей кодовой базы как таковой.

Ещё мысли вслух:

1. {$MODESWITCH UNICODESTRINGS} - зло, потому что для подавляющего большинства задач достаточно обычных старых добрых ASCII-строк, а для многих из них хватило бы и вообще ShortString. Отсюда же следует, что -Sf UNICODESTRING - ещё большее зло, так как если первая штука хотя бы влияет только на модуль, в котором её указали, то вторая влияет на все модули, собираемые при данном запуске компилятора. То есть включая даже те, которые нам не следует как-либо править (библиотеки типа vampyre, заголовки и прочее).
   
   
2. А поскольку безболезненно редактировать внешний код мы не можем, то SetMultiByteConversionCodePage() может пригодиться как раз для обеспечения его предсказуемого поведения в вопросе перегонки строк из Unicode и обратно, чтобы не зависеть от системных настроек пользователя.

_________________
Чёрный Думер, Чёрный Думер
С монстрами сражается.
Чёрный Думер, Чёрный Думер
Рокетланчер плавится.

Хотя нет, всё же этот подход не годится. Тезис-то верный, вот только проблема в том, что сам язык так не считает - компилятор FreePascal и его стандартная библиотека (RTL) отводят типу String ту же роль, которую в WinAPI играет тип TSTR и его разновидности (LPCTSTR и т.п.), то есть псевдонима либо для ANSI-типов, либо для Unicode - в зависимости от настроек сборки. К тому же, если мы хотим сохранить возможность собирать игру под Win9x (и под системы без Unicode как таковые), то нам придётся с этим соглашаться.

Поэтому теперь вырисовывается примерно такая схема использования типов, в порядке убывания предпочтительности:

• FontString = type AnsiString(1251) - для непосредственного вывода текста на экран.
• String / PChar / Char - для всех языковых строк, содержащих текст. Если сервер запущен на ANSI-системе, то в серверлисте об этом должна быть пометка.
• String[] - для всех технических строк. Явное указание максимальной длины должно быть обязательным, так как оно уточняет по месту смысл употребления.
• RawByteString - для всех тех редких случаев, когда не хватило ограничения String[] на максимум в 255 символов длины, а также для "сырой" работы с текстовыми данными.
  
  
• UnicodeString / PUnicodeChar / UnicodeChar - для работы с Unicode и случаев, где он подразумевается однозначно (например на сервер что-то отправить).
• UTF8String / PUTF8Char / UTF8Char - для сериaлизации Unicode в нечто более компактное или его маршалинга туда, где требуется именно UTF-8 (многие API современных библиотек такие).
• AnsiString / PAnsiChar / AnsiChar - для работы с ANSI-кодировкой в случаях, когда это необходимо (скажем, в какую-нибудь старую библиотеку прокинуть что-нибудь).
  
  
• UCS4String / UCS4Char / TUCS4CharArray - если вдруг потребовалось работать с чистыми Unicode-символами без суррогатных пар и прочей мути.
• WideString / PWideChar / WideChar - для работы с Component Object Model и производными от COM технологиями (вообще не могу себе представить, но вдруг).
• ShortString (синоним к String[255]) - если требуется заранее выделенная на стеке строка. Нужно сугубо для обработки исключений, так как они могут предполагать повреждение кучи.

Есть весьма годная брошюрка от Embarcadero, где описывается смысл введения в Delphi тех или иных строковых типов:
https://www.embarcadero.com/images/dm/technical-papers/delphi-and-unicode-marco-cantu.pdf

_________________
Чёрный Думер, Чёрный Думер
С монстрами сражается.
Чёрный Думер, Чёрный Думер
Рокетланчер плавится.

В Lazarus начали обсуждать инициативу по удалению возможности собирать стандартную библиотеку в режиме без UTF-8 (-dDisableUTF8RTL).
https://forum.lazarus.freepascal.org/index.php/topic,70092.0.html
Для игры это значения не имеет, а вот для редактора может. Пишу сюда просто чтобы не потерять потом.

Ещё надо будет у всех файлов расширения поменять с .pas на .pp, раз уж повод выдался.

_________________
Чёрный Думер, Чёрный Думер
С монстрами сражается.
Чёрный Думер, Чёрный Думер
Рокетланчер плавится.