The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Индекс форумов
Составление сообщения

Исходное сообщение
"Выпуск движка Free Heroes of Might and Magic II 0.9"
Отправлено Ordu, 08-Фев-21 20:37 
> Что вас смущается с дизайном данного кода?

1. Зачем там виртуальность на виртуальности виртуальностью погоняет? Чтоб динамический диспатч и кеш-промахов побольше?

2. Нахрена OpenGL код добавлять в "наследованный от BaseRenderEngine класс", если можно добавить его в BaseRenderEngine? Может есть отдалённые планы запускать fheroes2 на устройствах на которых нет OpenGL? Это на каких, интересно? Но если и есть, то вот когда до этого дойдёт дело, можно будет добавить "#ifdef NO_OPENGL" и сделать так, как на том устройстве принято, а не усложнять код сегодня, причём усложнять и сорцы, и рантайм. Развели понимаете жабу с её динамизмом там, где всё решается статическим полиморфизмом. При том, что на данный момент и в обозримом будущем полиморфизм тут не нужен. Да, что там Java, я на во все щели динамичном lisp'е напишу с меньшим количеством рантайм диспатча. Как так можно ваще писать на C++?

3. Синглетон -- это разновидность глобальной переменной, что есть суксь и зашквар. Людям сказали, что глобальная переменная плохо. Они не поняли почему, но чтобы не палиться, прекратили использовать глобальные переменные. А поскольку без глобальных переменных не умают, придумали обходной манёвр -- синглетон. Те же яйца, вид в профиль. Только код стал ещё более нечитаемым, и вместо обращения к глобальной переменной display теперь везде вызов Display::instance().

4. В частности использование синглетона приводит к тому, что создание его глобальной^W static переменной оторвано по времени от инициализации, что, в частности, приводит к тому, что на инициализированность её нельзя положиться, откуда лезут _рантайм_ проверки вида if(_window != NULL). Я не думаю, что это сильно влияет на производительность (особенно на фоне рендера в память с пересылкой битмапа), но в любом случае захламляет код ненужными проверками.

5. Зачем копировать спрайты? Пиксельный шейдер может выбрать нужную текстуру с учётом времени (дабы анимацию изобразить), получить из текстуры индекс цвета пикселя, извлечь RGBA цвет из палитры по индексу цвета, наложить сверху заданное преобразование, и отдать видеокарте готовый пиксель. При необходимости, его можно и сглаживающие фильтры научить накладывать, дабы квадратов на экране было бы поменьше (хотя для этого, я подозреваю, придётся рендерить в два этапа -- сначала в текстуру на весь экран, а потом натягивать эту текстуру на экран, фильтруя квадраты). Добавь к этому z-buffer, и он решит проблем перекрытия одних спрайтов другими. То есть, CPU может вообще простаивать, лениво гоняя по шине до видеокарты по три байта на кадр.

6. На счёт этого я не уверен, но тем не менее меня это смущает: зачем держать в сорцах код для SDL1, если есть код для SDL2? SDL2 портируема в не меньшей степени, чем SDL1. Если у кого-то в системе его нет, то можно либо вытянуть скриптом сборки, собрать и слинковать статически с экзешником, либо посоветовать пользователю обновить систему, наконец. Раз в десять лет не помешает.

Не, я как бы понимаю, что коду хренова туча лет, и этот "C с классами" подражающий джаве -- это прям-таки образцовый код для 90-х, написанный согласно топовым рекомендациям топовых гуру C++ тех времён. И тут нет особых претензий к автору кода -- он, видимо, начитался учебников, и в качестве практики написал этот код. Может он с джавы на C++ пересаживался, вот и писал Java код на C++. Но сегодня на дворе не 90-е. И нулевые кончились больше десяти лет назад.

Возможно и неиспользование шейдеров в силу той же причины -- древности кода: шейдеры ведь в начале нулевых где-то появились? И, возможно, только к концу нулевых стали must have фичой для видеокарт, на наличие которой можно полагаться. Хотя, мне кажется, даже на OpenGL 1.2 без всяких шейдеров можно выкрутится, и свалить на видеокарту всё это копирование пикселей. Придётся повозиться, причём на каждый кадр придётся, но, я думаю, что раз в десять нагрузку на CPU можно снизить легко. Более того, я уверен, что HOMM2 нихрена ничего не копировал в видеопамять на каждый чих, он копировал данные из одного места видеопамяти в другое, по 8 пикселей за один movsb. Возможно даже с наложением вот тех самых преобразований, о которых ты упоминаешь выше. То есть HOMM2 рендерил, как минимум, на порядок быстрее, чем fheroes2, несмотря на то, что вместо GPU у него был VGA.

 

Ваше сообщение
Имя*:
EMail:
Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email).
Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:
 
При общении не допускается: неуважительное отношение к собеседнику, хамство, унизительное обращение, ненормативная лексика, переход на личности, агрессивное поведение, обесценивание собеседника, провоцирование флейма голословными и заведомо ложными заявлениями. Не отвечайте на сообщения, явно нарушающие правила - удаляются не только сами нарушения, но и все ответы на них. Лог модерирования.



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру