Всем привет! Решил создать отдельную тему, т.к. разработка начала активно вестись после обсуждения в этой теме. Итак, что же это такое? Nuke3D - конструктор олдскульных игр жанра FPS Жанровая направленность: FPS, Action GAPI: OpenGL, DirectX, Software Rendering (Burning's Video) Язык программирования: C++ для "запускатора", ObjectPascal/FreePascal для редактора карт и ресурсов, JavaScript для скриптовой части Двигатель: в раннере используется WorldSim3D Платформы: Linux, Windows, гипотетически MacOS Лицензия: коммерческая, проприетарная?
Планируемые (реализованные) отличия от оригинала (RGM?): - три типа рендеринга; - поддержка современных разрешений экрана; - текстуры более высокого разрешения (ограничено искусственно); - гипотетическая возможность добавления бесконечного количества текстур, спрайтов, кадров анимации; - настраиваемые коллизии; - масштабирование спрайтов; - скайбоксы и их предпросмотр прямо в редакторе; - послойное рисование полов, стен, потолков; - поддержка множества форматов текстур: jpg, jp2000, bmp, png, tiff, tga и проч. - автоматическая подгонка редактором загружаемых текстур под размеры и необходимый движку формат; - управление количеством карт и скайбоксов; - удобный редактор, включающий в себя редактор ресурсов, карт, IDE для написания скриптов; - скриптовый язык программирования для управления логикой игры.
За прогрессом разработки вы можете следить здесь (обновляю редко) или в моем дневнике на ВКонтакте - Antoshka's Diary (обновляю довольно часто).
Что готово сейчас: [2017-09-07] + рендеринг мира из кубов аля Wolf3D, но с полом/потолком, дырами в потолке/полу, отображение неба; + разные плитки для пола/потолка; + лютые оптимизации рендеринга, потратил на это несколько дней, выжимая FPS по единичке. Думаю, что всё равно есть над чем поработать; + туман; + ускорение рендеринга потоками из стандарта C11 (библиотека tinycthread); + управление качеством картинки "на лету"; + текстуры 128х128 (можно и больше, но зачем?);
Скриншоты
Тестовые билды: v007 Win32 Описание В архиве несколько раннеров: rgm_one_thread_double - однопоточный рендеринг, плавающая точка rgm_one_thread_fixed - однопоточный рендеринг, фиксированная точка с потоками rgm_c11_threads_double - 4 потока, плав.точка rgm_c11_threads_fixed_4thrd - 4 потока, фикс.точка rgm_c11_threads_fixed_8thrd - 8 потоков, фикс.точка
v006 Win32 v006 Linux x64 (однако поведение странное. Надо и над этим поработать) Описание Более-менее стабильная и быстрая работа рендера. В архиве несколько экспериментальных "раннеров". full_screen.bat - запуск в полноэкранном режиме
Горячие кнопки: F - включить/выключить туман G - включить/выключить "красивое" небо H - включить/выключить рисование потолка J - включить/выключить рисование пола "-" - уменьшить детализацию "+" - увеличить детализацию
Очень интересны результаты тестов пользователями - какой FPS выдает раннер и на каком железе. Можно здесь, можно в личку.
Всем спасибо за внимание!
Сообщение отредактировал Vuvk - Пятница, 09 Ноября 2018, 08:19
А почему бы и нет, вдруг найдется художник, который с помощью красивых больших текстур захочет сделать более красивую картинку к примеру. Если есть возможность, лучше предоставить этот выбор пользователям.
Цитата
Язык программирования: C11 для "запускатора", ObjectPascal/FreePascal для редактора карт и ресурсов
Одного меня беспокоит зачем было делать два языка и почему нельзя было сделать для редактора карт и ресурсов что-то си-подобное раз используется аж новый стандарт чистого Си?
Цитата
после обсуждения в этой теме.
Почитал тему, да в Steam можно продать все что угодно. Так что ориентируйся на продажу. Данный инструмент, если он будет не сложным купят однозначно.
Нечего не скажу определенного. Но меня просто беспокоит, что вы зачем-то решили использовать сразу несколько языков для разработки, подобное тяжело поддерживать. Разве что связка С++ + "Script_Name" (или C + скрипт_нэйм не важно). Т.е. второй язык как бы является служебным. Зачем использовать два "главных" языка для меня загадка, если честно.
Притом судя по теме вы еще хотите ввести lua. Lua сам по себе неплохая идея. Просто у вас получается будет уже 4 языка?
Сообщение отредактировал GWÁLÐ - Пятница, 08 Сентября 2017, 00:09
Я насчитал только три... В любом случае пользователи получат готовые исполняемые файлы, так что на чем оно написано - моя головная боль. Как я вижу процесс использования конструктора : 1. пользователь создает новый проект в редакторе, выбрав целевую папку. В эту папку закидываются среда исполнения, паки со стандартными ресурсами и скрипты на lua (если всё-таки я буду их использовать) 2. пользователь меняет стандартные ресурсы / добавляет новые 3. пользователь при желании правит lua-скрипты, но это не обязательно
По поводу разных языков. Оба языка я активно использую ежедневно, так что для меня ничего нового. Я мог бы всё написать на FreePascal, но FPC выдаёт чуть более медленный код, чем GCC, а для программного рендеринга это непростительная роскошь. Я мог бы написать всё на Си + какой-нибудь GTK, но тогда пользователям Windows нужно будет устанавливать что-то лишнее (среду GTK). Win API? Но для других осей его нет)) Поэтому я решил писать среду исполнения на Си для максимального быстродействия, а для кросс-платформенного "формошлёпства" использовать Lazarus (IDE для FPC + LCL). Также я использую заведомо кросс-платформенные библиотеки, чтобы это всё работало на разных ОС без плясок с бубном или варганом.
Благодарю за проявленный интерес, комментарии и за ободрение:
ЦитатаGWÁLÐ ()
в Steam можно продать все что угодно
Сообщение отредактировал Vuvk - Пятница, 08 Сентября 2017, 06:04
Vuvk, качнул архив (v006 Win32), пытаюсь распаковать WinRarом а он мне:
! C:\...\RGC_006.7z: Неизвестный метод в fonts\FreeSans.ttf ! C:\...\RGC_006.7z: Неизвестный метод в full_screen.bat ! C:\...\RGC_006.7z: Неизвестный метод в hardware.bat ! C:\...\RGC_006.7z: Неизвестный метод в high_quality.bat ! C:\...\RGC_006.7z: Неизвестный метод в images\sky.bmp ! C:\...\RGC_006.7z: Неизвестный метод в images\texture0.bmp ! C:\...\RGC_006.7z: Неизвестный метод в images\texture1.bmp ! C:\...\RGC_006.7z: Неизвестный метод в images\texture2.bmp ! C:\...\RGC_006.7z: Неизвестный метод в images\texture3.bmp ! C:\...\RGC_006.7z: Неизвестный метод в libfreetype-6.dll ! C:\...\RGC_006.7z: Неизвестный метод в rgm.exe ! C:\...\RGC_006.7z: Неизвестный метод в rgm_c11_threads.exe ! C:\...\RGC_006.7z: Неизвестный метод в rgm_one_thread.exe ! C:\...\RGC_006.7z: Неизвестный метод в rgm_sdl_threads.exe ! C:\...\RGC_006.7z: Неизвестный метод в SDL2.dll ! C:\...\RGC_006.7z: Неизвестный метод в SDL2_ttf.dll ! C:\...\RGC_006.7z: Неизвестный метод в zlib1.dll
Заново скачал, то же самое. Я не силен в кроссплатформенном программировании, но почему бы не сделать все на Си? А то что придется устанавливать что-то лишнее это уже юзеры пусть думают, зато все на одном языке. Но это имхо, возможно ошибочное, однозначно тебе виднее)) Что используешь для программного рендера (как-то библиотека)? Мой блог - ссылка Мои проекты: SkyXEngine - графический 3D движок с real-time рендером s4g - скриптовый язык программирования
Сообщение отредактировал Byurrer - Пятница, 08 Сентября 2017, 08:29
Byurrer, пора обновить винрар)) Или использовать 7-zip. В будущем буду выкладывать в архивах zip, чтобы не было таких оказий...
ЦитатаByurrer ()
Что используешь для программного рендера (как-то библиотека)?
Нет, только свои мозги. Оптимизировал алгоритмы, активно использую битовые операции, заменил все повторяющиеся операции деления на умножение, сократил количество побочных переменных и вызовов функций. Узнал много нового (например, double работает быстрее на 64-битных процессорах даже если приложение 32-битное, инлайновые функции могут тормозить программу и т.д.). Сейчас попробую заменить числа с плавающей точкой на фиксированную - должно дать прирост на слабых/старых процессорах. Далее на повестке многопоточность через thread pool. Всё-таки главная проблема - быстрый рендеринг. Редактор это уже фигня.
Сообщение отредактировал Vuvk - Пятница, 08 Сентября 2017, 08:47
само собой)) А какое средство используешь? Какие функции, откуда? В режиме ядра? Мой блог - ссылка Мои проекты: SkyXEngine - графический 3D движок с real-time рендером s4g - скриптовый язык программирования
Byurrer, попиксельно формирую буффер и его вывожу на экран. На самом деле буфферов несколько будет, они будут склеиваться в один (для минимизации лишних расчетов). Никаких функций ядра...
Byurrer, по умолчанию блиттинг, в SDL2 создается рендерер с флагом SDL_RENDERER_SOFTWARE. При запуске с ключом "-accelerated" создается SDL2-рендерер с флагом SDL_RENDERER_ACCELERATED ("the renderer uses hardware acceleration"). Подозреваю, что во втором случае рисуется через OpenGL, но в исходники sdl лезть неохота. Да и если это так, то просто рисуется полигон с формируемой на лету текстурой. Профита почти никакого (+ 1-3 FPS).
Сообщение отредактировал Vuvk - Пятница, 08 Сентября 2017, 13:28
если не меньше) Еще интересно почему именно программный рендер? Почему не хочешь сосредоточится именно на игровой составляющей и использовать аппаратные возможности рендера? Это же ускорило бы релиз, не? Мой блог - ссылка Мои проекты: SkyXEngine - графический 3D движок с real-time рендером s4g - скриптовый язык программирования
Еще интересно почему именно программный рендер? Почему не хочешь сосредоточится именно на игровой составляющей и использовать аппаратные возможности рендера? Это же ускорило бы релиз, не?
Во-первых, желание сделать, как в оригинале, но лучше/быстрее. Во-вторых, потренироваться в оптимизации и научиться чему-то новому. Всё же полезные навыки. Также, возможно, я и сделаю отдельный рендер на OpenGL. Но это не точно.
Цитатаbodya_WM ()
Vuvk не осилил GUI на C, поэтому решил формошлепать его на FPC.
Йее, шуточки за 300 подъехали. Кто-то вообще даже смысл рейкаста не осилил
По таким мелким вопросам можете в ЛС писать. Не хочется тему засорять.
Добавлено (09 сентября 2017, 12:54) --------------------------------------------- + Изменение качества картинки на лету поправлено. Теперь больше похоже на правду. + Исправлен тайминг - отныне игра идет с одинаковой скоростью на Win и Lin. + Некоторые повторяющиеся расчеты вынесены в таблицу, которая формируется при старте. Прирост ~5%. + Частично перенесены расчеты вещественных чисел с плавающей точки на фиксированную с помощью библиотеки libfixmath. В однопоточном рендеринге прирост ~10%. Результат будет разниться от машины. Почему частично: 1. неизбежны потери из-за погрешностей. В оригинале с разрешением 320х200 это бы прокатило. Но не здесь... 2. в некоторых местах конверсия из одного вида числа в другое медленнее, чем расчет напрямую.
Заметил несколько интересных фактов: 1. антивирус Касперского очень сильно просаживает фпс 2. на Linux FPS примерно вдвое выше (даже в однопоточном режиме), чем на Windows. Одна и та же машина, один и тот же код, а результат разный в зависимости от ОСи. 3. режим "-accelerated" (вывод через OpenGL сформированного буффера) иногда неплохо добавляет производительности - зависит опять же от машины и от ОСи.
Остаётся попробовать thread pool (например, адаптировать этот - A simple C thread pool). Если и это не даст особого прироста, то стоит задуматься... Может схитрить и сделать портальный рендеринг вместо рейкастинга... или вообще отказаться от программного рендеринга и на OpenGL слепить... слишком просто ))
Результат проведенных махинаций:
Сообщение отредактировал Vuvk - Суббота, 09 Сентября 2017, 20:53
Подкинул тестовый билд v007 под Win32. Ссылка в шапке. Туда-сюда перестану выкладывать промежуточные итоги. Сейчас я делаю это в надежде на тестирование желающими, которые отпишутся мне о FPS и их машине. Уже сейчас в голове есть соображения, как я могу сделать быстрое "освещение" секторов. Оно будет "квадратное", но думаю, что в тему. Также есть идейка добавить анимированные текстуры для карты.
bodya_WM,
Сообщение отредактировал Vuvk - Суббота, 09 Сентября 2017, 20:35
salewa, огромное спасибо за тестирование на разном железе и подробный отчет! Хоть некоторые результаты и выглядят странно, но я вижу, что целевые 60 FPS уже достигнуты даже на слабых ПК (я про ноут). Посмотрим, что нам даст трэд пул
--- После тестирования на восьми разных машинах, включая ну очень древние, подтвердилось, что из всех "раннеров" лучше всех себя показал вариант в 4 потока с фиксированной запятой. Ну, как я и подозревал.
Добавлено (10 сентября 2017, 11:51) --------------------------------------------- + ускорены функции перевода числа с фиксированной запятой в плавающую в библиотеке libfixmath; + исправлен мелкий баг с образованием неверных линий на полу/потолке (из-за погрешностей); + адаптирована библиотека A simple C thread pool. В оригинале используется pthread (который, как известно, работает только на системах POSIX), я переписал на С11 threads дабы это всё было кроссплатформенным. Прирост FPS нулевой. Однако рендеринг всё равно стал менее прожорливым, что однозначно плюсик:
Может есть какой-то инструмент, через который правильней производительность измерять, чем подсчет FPS?
Добавлено (13 сентября 2017, 17:26) --------------------------------------------- Сейчас я пробую свою технику рейкастинга, основанную на секторах и сегментах. Плюс техники в том, что можно с легкостью создавать кривые стены, а также перемещающиеся. Просчет точки столкновения быстрый, но луч бьёт насквозь и нужно проверять все элементы карты. Так что нужно теперь быстро сортировать видимые/невидимые сектора и оптимизировать уже новые алгоритмы. Принцип на видео. Реализовал что-то типа "фрустум куллинга" (на последнем видео с 0:50 видно, как отсекается вращающийся треугольник). Есть ещё идея проверять на пересечение только повернутые к игроку сегменты (на картинке ниже луч бьет в стены, но проверяются только зеленые сегменты).
В общем, теперь надо пол/потолок и попытаться это всё оптимизировать. ФПС в этой реализации более стабильный, т.к. удаленность сегмента от камеры вообще не играет никакой роли.
Добавлено (23 сентября 2017, 14:12) --------------------------------------------- Так, давненько я ничего не писал... В общем, поигравшись с обновленным рейкастингом, описанным выше, я пришёл к выводу, что оно всё равно не может работать быстро на высоких разрешениях. Что у меня получалось, можно увидеть в этом ролике. Затем я решил попробовать последний шанс - растеризацию, аналогичную OpenGL, но без аппаратной поддержки. Попробовал tinyGL, но там всё грустно внутри (так всё написано, что даже разбираться не хочется). В итоге начал писать свой рендер. Обозвал его tinyRender . Пока что ничего не ясно в том плане, насколько это может (и будет ли) работать быстрее. Демо в двух роликах один два
Если кому-то интересно будет, то вот демки рендера (те, что на видео). Пока забагованные...
И да. Если оно не взлетит, то запилю на OpenGL да и всё
Добавлено (19 Января 2018, 16:31) --------------------------------------------- Всем привет. Отпишусь хоть, что после длительного запоя каникул и после долгой маеты с написанием собственного софтверного рендера, я решил забить и взять готовый движок для среды исполнения уровней. Выбор пал на WorldSim3D. Точнее на его последнюю версию под С/С++. "Запускатор" пишется на Си, короче. А редактор в Lazarus'e на FreePascal. Как я и планировал. На данный момент готова загрузка текстур стен, спрайтов, кадров, установка свойств для спрайтов (твердость, анимация) и формирование паков собственного формата. Рисование карт простое, как 5 копеек. Есть зум карты, возможность включения/выключения сетки. Прикладываю пару скриншотов:
И два видео с демонстрацией работы того, что сейчас готово: раз и два (видео во вконтаче).
Всем спасибо, всем пока.
Сообщение отредактировал Vuvk - Пятница, 19 Января 2018, 16:33
мне кажется что лучше все-таки сделать геометрию уровней по круче, как в думе хотя бы, и еще воксели прикрутить. и для скриптов луа какой-нибудь, чтоб на пример оружие свое с особым функционалом можно было сделать и так далее. Weedman
Hobo_Gus, я сначала думал допилить свой старый редактор карт - видео во вконтаче, но потом, когда пообщался в интернетах с целевой аудиторией, то понял, что новичкам нужно МАКСИМАЛЬНО простое редактирование. Так что пока так. Более крутой формат карт отложил на RGC v2.0. Насчет вокселей задумка интересная. У меня уже есть загрузчик моделей формата VOX (Magica Voxel). Мой код впоследствии даже внедрили в движок, который я сейчас и использую. Видео с загрузкой вокселей на Юпубе. Думаю для статики вполне достаточно было бы.
Добавлено (23 Января 2018, 17:43) --------------------------------------------- Изменил формат паков карт, когда увидел, что его нехило раздувает от добавления слоев пола и потолка и увеличения количества карт в игре. В общем, теперь всё это хранится в сжатом виде. Также заложены настройки для каждого уровня: цвет пола, потолка, тумана, отображать ли текстурный пол, потолок, туман, небо? Добавил преобразование формата текстур при загрузке под софтверный рендер: с ARGB8888 в ARGB1555. Программный рендеринг наконец запустился. Но выглядит это... на видео понятней - обрезаются все полигоны, у которых хоть одна вершина не попала на экран. Если ничего нельзя изменить, то отключу его. Программный рендеринг под названием Burning's Video тоже работает с небольшим нареканием - смазывает текстуры (( Direct3D и OpenGL работают без нареканий. Последний почему-то работает медленней и кушает больше оперативной памяти. Череда оптимизаций только впереди. Также добавилось послойное рисование пола и потолка и их генерация в запускаторе. Буду ещё экспериментировать по поводу удобства. Не стал разделять текстуры мира на разные паки, а просто расширил их максимальное количество до 60. Далее я хочу добавить возможность задания кадров для текстур мира (стены, потолок, пол), чтобы создавать анимированное окружение (ну там ручейки всякие или еще чего). Смотреть видео во вконтаче
Добавлено (27 Января 2018, 10:40) --------------------------------------------- Работа над оптимизацией количества полигонов закончена. Также сотворил батчинг по именам текстур. Т.е., если используется 60 текстур, то значит будет 60 мешей. И всего 60 draw calls на статический мир. Думаю, с такой детализацией это нормально. Как итог на моем компе количество фпс выросло с 1000 до 4000 в этой сцене. К тому же манипуляции с батчингом позволяют мне сделать быструю смену кадров анимированных текстур у всех объектов её использующих, т.к. технически это будет один меш. Первые два скрина как было до, вторые два - как стало после. Кликабельно.
Последние два скрина об эффекте тумана.
Совместно с Николаем заставили работать программный рендеринг как надо. Ну а далее работа над анимацией окружения.
Добавлено (29 Января 2018, 19:37) --------------------------------------------- Увеличил размер текстур до 128*128. Паки заметно распухли. Добавлена работа с анимацией для окружения (пол, стены, потолок) - до 5 кадров, задание скорости проигрывания. В очередной раз некоторые изменения в структуре паков, включая защиту паролем. То, что я планировал для быстрой обработки смены кадров работает на ура. Подробнее на видео во Вконтактике.
.
