doom2d.org

Привет всем. Я здесь новенький (на iddqd.ru известен как Super_DooMer) и заинтересован в том, чтобы по возможности (когда время будет позволять), помогать проекту по части кода. В частности, мой главный интерес в данный момент - создание полностью кроссплатформенного кода. В этой теме я хочу поделиться своими соображениями на этот счет и, самое главное, послушать мнение программистов и в целом всей команды, которая работает в данный момент над проектом, чтобы понять, стоит ли мне вообще за это браться. Меня интересует в первую очередь, готова ли комманда:
• перейти с Delphi на кроссплатформенный Lazarus
• на кардинальные изменения кода в сторону оптимизации, упрощения и универсальности в плане рендеринга, работы с локализациями, файлами, скриптами и т. п. (естественно, после того, как все дают "добро")

Если да, то я составлю подробный план о переходе и всех его аспектах, но для начала набросаю в общих чертах, что нужно сделать, и описание первой конкретной проблемы, которую нужно решить - Юникод.

План:
• Первое и самое главное, что нужно сделать - перейти на Unicode, иначе никакая кроссплатформенность не светит. Об этом читайте ниже.
• Избавиться от Windows-зависимых вещей, начиная с библиотек и заканчивая компилятором. Здесь все просто: SDL 2 для бэкэнда, lua для скриптов, FPC компилятор (соответственно Lazarus вместо Delphi). Код при этом переписывать почти не придется, потому что Lazarus может импортировать проект Delphi со всеми формочками и т. п..
• Избавится от ошибок и костылей, сделать рефакторинг. Код в данный момент жутковат и использует корявые велосипеды вместо готовых решений. Очень многие вещи, на мой взгляд, нужно переписать. Например, первое, что бросается в глаза - полное игнорирование порядка байтов при записи и чтении из бинарных файлов. Кстати, я уже читал здесь тему о неудавшейся попытке компиляции при помощи FPC. И хотя скомпилировать текущий код без изменений по-любому не получится, странные ошибки еще раз говорят о необходимости реорганизации кода.

UNICODE
На дворе 2014 год. Везде без исключения используется UTF-8, а исходники D2D в CP1251. Я, конечно, понимаю: кириллическая Винда, Delphi 7 и все такое, но если делать с умом и кроссплатформенно, нужно все сорцы переконвертировать в UTF-8 и переписать куски кода, отвечающие за работу с текстом.
Если это сделать, то получаем следующее:
• нормальная работа с Lazarus-ом (он, как и весь современный софт, использует UTF-8)
• работа с любой внешней библиотекой без геморроя
• поддержку локализации на любом языке мира
• поддержку FreeType (т. е. вменяемые векторные шрифты в ttf, otf) - соответственно, не нужно пилить растровый шрифт для каждого языка и долбаться с восьмибитными кодировками
• локализации не нужно хардкодить в экзешник
• на Гитхабе нормальные комментарии вместо кракозябров

Просто к надбавке - уже не раз упоминалось, что нужно сперва выковырять игру из движка.

_________________
DM2002 testing
Total Destruction - F
EDODLΔ

Я считаю, для этого сперва нужно скрипты реализовать. Lua, естественно, чтобы велосипеды не городить. И тогда уже будет полная свобода для воображения: например, можно будет описывать монстров и объекты как lua-таблицы, добавлять новые, писать собственные моды, скрипты и т. п., короче, сделать игру полностью независимой от движка.

Идея перехода на Free Pascal очень верна, хоть это будет очень не просто (как мне кажется).

• Переход на UTF-8 полностью поддерживаю
• По поводу внешних локализаций совсем недавно обсуждали, поддерживаю
• Насчёт скриптов может быть не всё так очевидно
• Насчёт отказа от растровых шифтов, некоторые негодуют (обсуждали только что в IRC)

А так ход мысли верный. Однако, одного моего согласия не достаточно. Жду мнений от Джа, ЧД, PSS и Примуса в этом треде.

_________________
by Stas'M

Ну если растровые шрифты так критичны, от в любом случае нужно увязать их с Юникодом. Большинство пользуется http://www.angelcode.com/products/bmfont/: там главная фишка в формате, который поддерживается многими генераторами растровых шрифтов (можно даже онлайн сделать). Там и Юникод, и кернинг, и даже Signed Distance Field (для последнего, правда, нужно шейдеры запилить).

Я пытался как-то собрать ДФ на FPC, как и DEAD, но от DirectInput/WinAPI не отучивал и оно сегфолтилось на _Menu_CreateAll() или как там ее, и я так и не разобрался, в чем там дело.
А так - да, это очень надо сделать. Только мне этим заниматься сейчас немножко некогда.
Если честно, было бы время, я бы лучше с нуля переписал все это дело, или хотя бы переделал некоторые крупные куски кода, в частности g_gui.pas.
EDIT: Тред, где я матерился по поводу сборки на ФПЦ, до сих пор висит где-то в этом подфоруме.

_________________
aka fgsfds & PrimuS

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

Но у нас все-таки Doom2D. И поэтому векторные шрифты прокатят только если выглядеть они будут не хуже растровых.

1). Нормального кириллического векторного дум-шрифта в природе на данный момент не существует, или я об этом не знаю. Трудозатраты на создание ХОРОШЕГО (а на другой я не согласен) векторного шрифта очень велики.
Лучше вместо этого нарисовать дополнительные анимации для модельки, когда у нас наконец будет новый ее формат, улучшить тайтл и внести кое-какие долгожданные изменения в анимацию монстров.
2). Текстурирование. Наверняка есть технология наложения текстур и обводок на векторные шрифты, но мне о ней ничего не известно.

За bmfont огромное спасибо, выглядит очень перспективно. Не знал про него, по старинке bitmap font writer'om пользуюсь.

_________________
И неважно, что нет морей на Марсе, каждый морпех носит море в сердце.

Внесу и я свои пять копеек.

Это очень спорно. В игре текстурированные растровые шрифты, перегнать их в вектор с сохранением текстуры вряд ли возможно, а если даже и так, то это очень трудно в художественном плане.

Это безусловно, однако тогда нужно придумать, как для локализаций описывать соответствие символов в растровом шрифте символам UTF-8. У меня только один вариант - для каждой локализации пилить таблицу соответсвий номера символа индексу в UTF-8. Если я правильно мыслю - скажите, буду рад.

SDL 2 не нужен. Насколько я помню код D2D:F, там особо нет строго шиндозависимых вещей, окромя DirectInput для работы с клавиатурой и возможных вставок WinAPI. Так игра пользует OpenGL, FMOD и ENet, а это всё - вещи кроссплатформенные. Подключать же SDL только ради обработки ввода - изврат, мне кажется. Особенно учитывая его реальные возможности.

Если будешь согласовывать работу со всей нашей дружной командой - искренне будем рады тебя в ней видеть.

По поводу попыток PrimuS'а собрать проект на FPC можешь почитать вот это, если интересно:
http://doom2d.org/forum/viewtopic.php?f=11&t=1670

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

ЧД, он уже )

Изучил bmfonter - все-таки это не то.
Насколько я понял, он генерит растровые шрифты на основе векторного с добавлением пары эффектов. Способа загрузить и отредактировать существующий растровый шрифт я не нашел.

_________________
И неважно, что нет морей на Марсе, каждый морпех носит море в сердце.

Вообще-то SDL можно (и даже, наверное, нужно) подключать для обработки ввода (флаги SDL_INIT_* для этого есть), а еще его можно комбинировать с GL и вообще. Еще есть GLUT.

_________________
aka fgsfds & PrimuS

Шрифты и прочее - это уже частности. Беда в другом.
Игра разрабатывается уже очень долго и нудно много лет, но при этом представляет собой нагромождение костылей, местами абсолютно бессмысленных. Это при том, что технически игра ну очень простая. То же касается и форматов. Вот зачем, например, было городить WAD, вместо того, чтобы использовать ZIP, который одним махом кроет все нужды, начиная от проверки хеша и заканчивая сжатием, не требуя при этом изобретения велосипеда.
Я что хочу сказать. Чтобы непродуктивная тягомотина не продолжалась дальше, нужен план, который бы составила вся команда, и который затрагивал все темы без исключения: разбиение кода на независимые модули, логику и структуру этих модулей, план их реализации (кто чем занимается), форматы файлов и прочее. Все это нужно забабахать в текстовый документ, чтобы у каждого к нему был доступ, у чтобы каждый ему четко следовал.
Звучит, может, и зверски, но так всегда поступают два и более человека, работающие в команде, потому что:
• Логическая структура.
• Это экономит до черта времени. Даже если каждый будет продолжать работать над D2D время от времени по чуть-чуть, это в разы повысит эффективность.
• Каждый работает над отдельными частями проекта без опаски создать другим геморрой (ну и самому его не получить), потому что эти части независимы. Т. е. работаю без опаски, что у кого-то из команды внезапно бомбанет фееричесая идея, из-за которой половину кода придется переписывать.
Планирование - вот чего не хватает.

Вы главное мне скажите: подобные вопросы вообще нужно здесь, на форуме, обсуждать, или вы где-то еще кучкуетесь. Я к тому, что если принимать какие-то решения, то всем вместе, синхронно.


Я имел в виду изначально пользоваться векторными. Это я упомянул чисто как один из профитов перехода на юникод. Тем не менее, с растровыми шрифтами вменяемая локализация невозможна, потому что рисовать новый шрифт для каждой - это ужас. А так можно было бы найти подходящий по рисунку, и использовать его без проблем.
Обводку векторным шрифтам можно делать силами FreeType, что касается других эффектов, то для этого нужно уже шейдеры пилить (текстурированный шрифт при этом без проблем делается маскированием).


Скажи подробнее, что ты имеешь в виду по "редактированием". Если он растровый, то редактировать его вроде как в Фотошопе нужно.


Пилить таблиц не нужно - Юникод сам по себе таблица. Если ты используешь формат уже упомянутого BMfont, то для каждого символа в твоем шрифте уже написан индекс. Дальше все просто: ты берешь из строки один символ и смотришь его наличие в таблице, которую сгенерировал BMFont. Если он есть, то используешь ассоциированные с ним координаты для вывода куска из текстуры. Опять же, с векторными шрифтами все проще.


Он нужен обязательно. Практически все без исключения кроссплатформенные игры его используют по ряду объективных причин (главная из них - чтобы не городить собственные багованные велосипеды). Тут даже и сомневаться нечего. Например, сейчас D2D использует win api (через Delphi) для создания окна и какой-то Delphi-костыль для создания OpeGL-контекста. И то, и другое кроссплатформенно можно сделать через SDL. Ввод, опять же: как ты сделаешь его кроссплатформенно (да еще и с джойстиком)? При помощи SDL! Плюс в нем полно всяких фич типа обстракции для ввода-вывода, таймеров и прочего, и все это - в одной библиотеке. Можно, по желанию, заменить проприетарный FMOD на православный опенсорсный SDL_Mixer. И даже использовать SDL_ttf, чтобы не долбаться с FreeType и UTF-8 напрямую. Причем эти дополнительные библиотеки разрабатывает тот же автор, что и основной SDL, и все они есть в репозиториях каждого дистрибутива Linux-а, что очень большой плюс.

Я бы юзал просто SDL вместо SDL2. Во втором большинство новых фич нам не нужно. Нам нужен только ввод, эвенты и контекст/окно.
И не помню, есть ли в SDL_mixer позиционный звук или хотя бы instance'ы одного звука.
Насчет говна в коде - это да. ДФ разрабатывали по очереди (не одновременно!) уже довольно много людей, причем разница во времени между этими "по очереди" довольно здоровая, и каждому из них было тяжело разбираться в коде предыдущего.
Навряд ли мы будем юзать векторные шрифты, потому что испокон веков в игре были текстурированные буковки, с обводочкой и так далее. Если умеешь их текстурировать - скажи как.
И у нас есть канал в ирке, где никто не сидит почти сейчас, он по ссылке в верхнем правом углу.

_________________
aka fgsfds & PrimuS

Лучше использовать вторую версию из за массы улучшений и упрощений по сравнению с первой, в частности из-за OpenGL: в первой есть такая фигня, что когда ты переключаешь окно на полный экран, OpenGL-контексту приходит конец (тупо черный экран). Это даже отдельно упомянули в Migration Guide. Первая версия вообще больше не разрабатывается - нет никакого смысла ей пользоваться.


Есть. И группировка каналов, и даже отдельные функции для работы с музыкой. Например, она используется в Saurbraten для позиционирования в 3D пространстве, так что для Doom 2D ее будет более чем достаточно. Кстати, enet тоже изначально создавался специально для этого шутера (точнее, для его первой версии).


Я уже писал выше: это только через шейдеры. То есть нужно переписать весь рендер на OpenGL 3.x вместо древней первой версии (но я этим точно заниматься не буду). А когда есть шейдеры, то это уже вопрос фантазии. Самый простой способ: рендерить символ или целую строку векторным шрифтом, а потом получившееся черно-белое изображение использовать в качестве альфа-маски для текстуры. Ну а иначе, если текстурки и обводка принципиально важны, то придется мучиться с растровыми, хотя я лично считаю, что это лишний гемор и FreeType рулит.
Еще есть вариант использовать два подхода: для латиницы и кириллицы (и других локалей, если нарисуем) используем няшный растр, а для других языков - вектор. В этом случае и перевод на любой язык можно сделать, и по возможности теплый ламповый doom-шрифт показать.


Вот как раз для этого я и предлагаю всей толпой составить и утвердить план разработки игры и ее структуру, чтобы все ему следовали и не городили всякого ужаса. Иначе эту, казалось бы, простую в плане реализации игру будут бестолку долбать еще много лет.

Вообще, я хотел, чтобы выложили на сайт 0.62, поэтому и делал бетки. А затем хотел начать заново. С планом, как daniel_p говорит. Но тут вдруг появилась сеть и все заверте... Не, Примус очень молодец, я бы не смог за 3 недели сеть сделать Но как-то это все... не вовремя. А то вся эта жесть в коде копится и добавлять новое все сложнее. Я за: проектирование до разработки, начать сначала, SDL (2), zip, lua, шрифты (мне кажется, при правильном использовании векторные будут выглядеть не хуже, чем сейчас растровые), С++. Про шейдеры не знаю - мы же, вроде, обсуждали, что openGL старый - для совместимости. А то есть люди со старыми слабыми компами.

Ну тогда я пас. Знания и опыт в C++ у меня не так велики, как FPC и C, а учитывая еще и то, что код C++ может быть как более-менее сносным, так и с легкой руки говнокодера-извращенца превратиться в абсолютный кошмар (что характерно, соответствующий всем стандартам и парадигмам C++), в команде я работать не рискну. Вообще я полностью согласен с Торвальдсом. Плюс более строгие и низкоуровневые языки, вроде C и Паскаля, не позволяют городить такой ад, какой позволяет C++.
Да и вообще: если большинство народа здесь дельфисты, то переход на FPC и Lazarus будет вообще безболезненным (учитывая еще и то, что Lazarus по ряду объективных причин лучше Delphi).

Этим вопросом уже долгое время задаётся всё местное сообщество, на самом деле.) И да, мы теперь тоже хотим ZIP, но проблема обратной совместимости и общая жопа в коде не особо дают возможность для реализации.

Вот это кстати вопрос. С одной стороны, D2D:F от шейдеров сильно выиграет в графике. С другой, сейчас он идёт практически везде, даже на самых старых видеокартах, что вполне соответствует образу олдскульной игры и в теории может привлечь к нам больше игроков (например, если он распространится где-нибудь в компьютерных классах, где компы древние по определению).

Шрифты спорно, с C++ не согласен - больно перегруженный это язык, да и прогать на нём не в пример сложнее. И код из нынешнего D2D:F в новый проект будет переносить в разы проблематично. И тут все паскальщики в той или иной степени в основном.
Остальное всё верно.

В общем, я целиком и полностью за грамотный план разработки - Даниэль всё правильно говорит.

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

Народ, все жду от вас ответа: если пишем на Паскале, и если все готовы кардинально и с умом переделать, то я как бы при делах и мы всей толпой пилим план. Если C++ - тогда уже сами.


Не только в графике, а и в производительности (если сильно со спецэффектами не извращаться). Никто сегодня не использует OpenGL 1.0, и использовать его, специально ограничивая движок технически ради компов конца девяностых, которые попробуй где найди - это на мой взгляд бессмысленно. Плюсов же - уйма. Даже если очень захотеть, трудно будет найти человека с компом, видеокарта которого поддерживала только 1.0 версию (а по факту - вплоть до второй). А если поддержка говна мамонта так критична, то можно без проблем это организовать как отдельный модуль и включать во время компиляции специальным флагом (скажем, -dOLD_SCHOOL_MOD ). Ведь модуль рендеринга все равно будет иметь абстрагированный API (по сути, он и сейчас такой), а за кулисами можно хоть вообще software использовать. Только вот смысла в этом ну абсолютно никакого.

Еще вот что (это не важно, но все же): сейчас версия игры 0.666. Ну, типа, уже больше половины сделано. А по факту где-то так 0.001 Pre-Alpha. Придется делать практический полный рефакторинг, другие форматы и прочее, в техническом плане будет чуть ли не новая игра, так что, я считаю, номер версии нужно будет сбросить.

Что плохого в С++ ?
Ну пусть будет Паскаль. FPC поддерживает Object Pascal?


Doom 2D: Forever After

Давайте на FPC, что уж.

Такой вариант идеален, мне кажется.
Смысл есть - ставить как раз на эти самые старые компы.

Ни в коем случае. D2D:F - уже раскрученный и довольно узнаваемый бренд, так что сброс версии вызовет у многих лишь смятение и непонимание. А вот начать отсчёт с 1.0 - это да, это было бы логично, я думаю.

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

Я не знаю и не хочу знать крестов, а паскаль недолюбливаю. На приемлемом уровне я умею только в С и несколько скриптовых языков. Я бы взял его, прикрутил Lua, ENet и SDL2 и пилил бы уже так. Без всяких там шейдеров, потому что не нужно и я не рублю в GL. Но кому охота этим заниматься сейчас, кроме меня? Тем более в 19870 раз делать с нуля очередной псевдоримейк ДФ/Д2д.

_________________
aka fgsfds & PrimuS