Настроил типы и дефайны так, чтобы движок, собранный на фпц >=3.0.0 был юникодным, а собранный на 2.6.4 - легаси версия с Ansi путями и именами файлов.
64-битный 2.6.4 делает всё как надо, а 64-битный 3.0.1 генерирует екзешник, всегда дающий AV на строчке
- Код: Выделить всё
Mother^.ExceptionState.AbbrTitleForIndicator:= 'mai';
, где
AbbrTitleForIndicator: ShortString3;
, где
ShortString3 = String[3];
Такштаааа... Юникодной пока может быть только 32-битная версия.
В линуксе пока доступен только 2.6.4 (новейшая версия Дебиан 8 ), но там эта проблема, кагбе, не лежала: утф8 и т.п.
Финальный вердикт: нуегона, этот третий, этот юникод, и эту поддержку SDL2.
Лучше сначала с многослойным миром разберуся.
Главное - знаю, что могу. Не заржавеет.
Добавлено спустя 17 часов 44 секунды:Сегодня мой моСХ, наконец, прорвало, и я понял, что знаю, как надо!
Теперь испытываю душевные муки Буриданова осла, застыв между двумя парадигмами. Каждая имеет свои вкусные плюшки и жирные минусы.
И Я НЕ ЗНАЮ, КОТОРУЮ ВЫБРАТЬ!!!
Сначала общие положения.
-- трёхслойная игровая физика с глобальными лагокомпенсацией и предсказанием. То есть, не общепринятая клиент-серверная, с передачей и лагокомпенсацией объектов поштучно, а хитровывернутый вариант древней lockstep технологии, где передаются только инпуты и контрольные суммы.
1. ТруЪ - слой. Лагает и отстаёт, дожидаясь инпутов всех игроков (с отсечкой в 500..1500мс)
2. Догоняющий слой: периодически, первичный слой копируется ВЕСЬ, и этот новый слой догоняет реальное время так быстро, как потянет процессор.
3. Рилтаймовый слой: тот, который видит игрок. Периодически сносится КЕМ, заменяясь на догнавший его догоняющий слой.
-- число игроков фактически ограничено только сетевой архитектурой: при грамотно построенной системе ретрансляторов от сервера клиентам, тысяча игроков - как два пальца об асфальт.
Парадигма новая, с реальной многослойностью.
*Принципы:
-- объекты ссылаются друг на друга посредством умных индексов со счётчиками ссылок.
-- слои частичные - т.е. реально физически существуют лишь отличия дочерних слоёв от родительского
-- обращаться по индексу можно только через методы «получить на чтение экземпляр текущего слоя» и «получить для записи экземпляр текущего слоя или скопировать из родительского»
*Достоинства и недостатки:
- нужно запиливать новый велосипед класса Чеперси для реализации всех этих слоёв.
- использовать подобную схему удобно, как плавать в валенках
+ позволяет получить гораздо больше контроля за связями и их использованием
+ позволяет организовать взаимодействие объектов через кошерную систему событий
- все слои должны укладываться в одно ядро, т.е. системные требования одного ядра для мультиплеера = 4х от сингла.
+ гораздо более кеш-фриндли: клонируются только *изменения* в слоях, статические объекты лежат в памяти нетронутыми, в *одном* экземпляре
- огромный объём работы по отладке и подводные камни на стыке между родительским слоем и его частичной копией-потомком
Парадигма старая, на основе Чеперси.
Эту я планировал изначально, но потом оказалось, что у Чеперси тупо не хватает скорости завершить клонирование мира за один кадр. Пришлось изобретать лисапед №2. Но! То была лишь косность мЫшления. Уже добавив многопоточность, я понял, что стоимость клонирования ВСЕГО мира можно свалить на отдельный поток, в котором выполнять ТруЪ слой. Раз уж он всё равно по определению лагает.
*Принципы
-- для каждого слоя - свой поток (минимум три, можно 4 или 5, на 6- или 8-ядернике, если у Чеперси пуп не развяжется их плодить. Чтобы параллельно иметь несколько догоняющих слоёв на разной стадии).
-- тяжесть создания ПОЛНОЙ копии мира принимает на себя поток ТруЪ-слоя. Остальные вообще не использут Чеперси.
*Достоинства и недостатки
+ достаточно старой доброй Чеперси, всё уже есть, только пару оптимизаций ей вставить. Былинная экономия затрат труда.
+ гораздо проще связывать объекты и обращаться к ним (обычный Паскаль еси)
- периодическое, несколько раз в секунду, копирование всех объектов, включая все статические чанки мира
- кеш (и память в целом) стонет и плачет, гоняя одновременно три ПОЛНЫХ копии мира
- потенциальный упсник, если игроки в ММО разбредутся по миру. Активно существует зона 500метров округ каждого, это около 4 тысяч чанков. Помножаем на тысячу... Упс? Упс.
А вот в новой парадигме было бы абсолютно по... до лампочки, сколько там миллионов чанков реализовано, если они статические.
+ требования к одному ядру для мультиплеера всего х2 (потянет и х1.5)
- мультиплеер возможен *только* на четырёхъядерном проце. Или оченно быстрый двухъядерник - но это почти оксюморон.
Парадигма гибридная, всё как у старой но со следующими отличиями:
-- пул неизменённых, статических чанков мира - это вообще отдельная сущность за гранью добра и зла. Сидит в отдельном потоке и тикает раз в минуту, согласно глобальному состоянию мира, которое получает из ТруЪ-слоя. Все слои обращаются к нему по индексу,, для изменений клонируют себе копию чанка.
*Достоинства и недостатки
- геморрой с реализацией. Меньше, конечно, чем у новой парадигмы, но всё же
+ можно развести себе гигантский кеш чанков, да хоть толщиной в гигабайт. Коий кеш, при умном сливании на диск, может служить для полного сохранения изменений мира в сингле.
+ может служить отличным сэндбоксом для глобальной модели мира
+ все статические чанки выводятся из механизма многослойной лагокомпенсации нахрен.
Добавлено спустя 5 часов 16 минут 49 секунд:Ежели никто не ответит - буду думать думу тяжкую до января
