Проекты
GameDev.ru / Проекты / Форум / Движок 'Сухарь Ванильный'

Движок 'Сухарь Ванильный'

Страницы: 1 2 361 62 Следующая »
sb3dУдалёнwww14 ноя. 201211:36#0
В этой скромной теме планирую иногда освещать создание движка. И буду очень рад обсудить детали этого нелёгкого процесса.

Название: Vanilla Rusk Engine. (Движок 'Сухарь Ванильный') Сухарь, потому что софтовый. А ванильный, потому что такой тёплый и ламповый! :)
Внутренний мир создаваемого: набор функций, помогающих писать игры. (Для краткости далее 'движок')
Язык: с++
Контакт с внешним миром: WinApi или SDL2 на выбор
Метод рендеринга графики: софтовый, на cpu
Форма существования: файлы исходного кода и заголовочный файл.
Для кого: для себя. Пока нет планов распространять его.
Для чего: планирую писать игры с его помощью

-------------

Итак, сегодня начал писать новый движок. Для начала, кратко история: в 2007 году я написал первый свой вменяемый движок. И за последующие годы понаделал на нём несколько игр, которые можно найти на моём сайте. Но годы идут, я расту над собой, и вот именно сейчас я думаю, что пора. Пора применить мои знания и навыки для написания ещё более удобного движка.

-------------

Достижения в сравнении с предыдущим движком, от 2007 года.

1. Многопоточность в некоторых функциях. Два или четыре потока. Даёт прирост скорости до 2-2.5 раз.
2. Внутреннее представление спрайтов в формате с отсечёнными невидимыми пикселями. (Система 'Имбирный Пряник') Даёт прирост скорости до двух раз.
3. Внутреннее представление спрайтов в формате 8бит на пиксель с палитрой. Даёт прирост скорости до 33%. И всегда показывает экономию памяти в 4 раза!
4. Все внутренние форматы не видимы для пользователя, который работает со спрайтами по прежнему в формате прямоугольника 32 бит на пиксель. Даёт удобство.
5. Свой формат записи спрайтов на диск. В плюсах - достаточно компактно сжимается архиваторами: лучше, чем png. Поэтому выгоднее.
6. Музыка и звук поддерживаются отдельно подключаемым модулем (два файла, .cpp и .h) Благодаря этому в игре без звука можно не линковать звуковые библиотеки.
7. Ядро движка и работа с winapi в двух разных файлах. Поэтому ядро требует лишь с++, без единого include. А небольшой файл работы с api легче переписать под другие системы.
8. Функции чтения и записи форматированных текстовых файлов. Удобно редактировать вручную. Программа может быстро найти, прочитать и записать нужное поле информации.

-------------

VilgOПостоялецwww14 ноя. 201211:46#1
У пользователя, который пишет игру на этом движке, будет "основная функция", которую движок вызывает фиксированное количество раз в секунду. С установленной пользователем частотой.
Отсюда вопрос первый: так делают?
Если не ошибаюсь, Game Maker работает именно так, с условием, что частоту можно менять в процессе.
nesПостоялецwww14 ноя. 201211:47#2
>Пора применить мои знания и навыки для написания ещё более удобного движка.
Пора отказаться от софтварного рендера )

>Отсюда вопрос первый: так делают? Если нет, то почему? Какие есть варианты?
Ну физику например можно обрабатывать с одной частотой, логику с другой, графику с третьей.
Сделал у себя класс манагера, который управляет группой однотипных игровых компонентов, в свою очередь можно задать частоту обновления как самому манагеру, так и отдельно каждому компоненту.
Пока думаю оставить так.

>А вот как освобождать процессорное время?
Sleep(0), но имхо для игры лучше такого не делать.

cNoNimУчастникwww14 ноя. 201212:07#3
sb3d
> Sleep()
ну можно еще WinApi таймеры использовать + MsgWaitForMultipleObjects
sb3dУдалёнwww14 ноя. 201212:29#4
VilgO
> Если не ошибаюсь, Game Maker работает именно так, с условием, что частоту можно
> менять в процессе.
Спасибо. Значит, этот вариант достаточно приемлемый, раз его используют.

nes
> Пора отказаться от софтварного рендера
Недавно я уже объяснял, почему софтрендер. Серьёзных причин две:
а) Невозможность контролировать вывод картинки попиксельно. Например, масштабирование спрайта при выводе через ускоритель мне не подконтрольно.
б) Отсутствие гарантированного стандарта рассчёта изображения. Сейчас, считая в софте, я уверен, что x86 стандарт будет соблюдаться бит в бит. А при использовании шейдеров и ускорителя я буду вынужден приспосабливаться к неясным и плохосовместимым стандартам шейдеров, разным версиям видеокарт, разным производителям, разным версиям драйверов.

> Ну физику например можно обрабатывать с одной частотой, логику с другой,
> графику с третьей.
Ого! Шикарная идея! Это хочу обязательно реализовать. После такого сразу мысль: как же я сам раньше не догадался? Да, предыдущий движок вызывал только одну функцию пользователя, с фиксированной частотой. И теперь я сразу вижу, как будет удобнее сделать в движке вызов произвольного количества функций пользователя со своими частотами.
Спасибо!

> Sleep(0), но имхо для игры лучше такого не делать.
То есть лучше, чтобы игра 100% процессора ела? Не думаю, что это многим понравится. Хотя в наш многоядерный век ОСь всегда сможет выполнять плеер\антивирус и прочее в фоне, даже если одно ядро будет занято. Но всё таки съедать 100% процессора как то не изящно.

cNoNim
> ну можно еще WinApi таймеры использовать + MsgWaitForMultipleObjects
Винапи таймеры достаточно неточные. Я в прошлом движке использовал QueryPerformanceCounter. Только он давал нужную точность. а WM_TIMER давал очень плохой результат по точности.

> MsgWaitForMultipleObjects
А она освобождает ресурс процессора точнее, чем Sleep? Просто основная беда Sleep'а в том, что он любит отдавать управление не точно в срок, а с задержкой. И особенно он не любит выполнять точно небольшие задержки. Поэтому, есть данные о сравнении MsgWaitForMultipleObjects и Sleep?

nesПостоялецwww14 ноя. 201212:40#5
sb3d
>а) Невозможность контролировать вывод картинки попиксельно. Например, масштабирование спрайта при выводе через ускоритель мне не подконтрольно.
Как это не подконтрольно?
Задаешь коэффициент масштабирования, все просто.

>б) Отсутствие гарантированного стандарта расчёта изображения...
Откуда такая информация?
Запуская современные игры на разных машинах, повсеместно использующих шейдеры картинка везде получается одинаковой.

>То есть лучше, чтобы игра 100% процессора ела? ...
Имхо игра это такой тип приложения которому нужно 100% мощности ЭВМ.

sb3dУдалёнwww14 ноя. 201212:50#6
nes
А попиксельного контроля при выводе через ускоритель нет. Сейчас я могу при выводе изменить палитру, проходить алгоритмом повышения чёткости, накладывать освещение, шум, лучи света, ещё кучу эффектов. А ускоритель как спрайт растянет, так уж и растянет. Пример добавлю: настройка масштабирования спрайта в духе "бикубическое", "линейное", "без сглаживания".

Далее, картинка при рендере на ускорителе получается разная в зависимости от настроек драйверов пользователем. И от производителя видеокарты это тоже зависит: может не оказаться поддержки версии шейдеров, или иного функционала. Чтобы это увидеть, достаточно попробовать запустить игры на компе десятилетней давности. Или на ускорителях от Интел.

Давай не будем углубляться в эту тему. Сейчас приоритеты такие, что будет софтрендер.

NomadПостоялецwww14 ноя. 201213:09#7
А с игрой что?
sb3dУдалёнwww14 ноя. 201213:17#8
Nomad
> А с игрой что?
С той игрой, которую делал последние месяцы - она завершена. Тема прямо тут, рядом.
Завершил игру и начал писать движок. :)
trexПостоялецwww14 ноя. 201213:18#9
sb3d
> так делают?
Делаю почти так в своем движке.
Но у меня не одна функция, а 3:
1. draw (тут рисование происходит, точнее все отправляется на GPU для рисования, пока рисуется идем дальше)
2. processEvents (тут обрабатываем пришедшие события (клава, мышь, тач, гироскоп, голос из ада))
3. tick (физика, элементы меняют свои позиции и т.п.)
4. flush
В таком варианте можно очень просто добавить анализатор,
какой этап сколько времени затратил и что необходимо
оптимизировать в первую очередь.

sb3d
> Неужто только функцией Sleep()?
Идеальный вариант. Правда я использую nanosleep.

sb3d
> файл исходного кода и заголовочный файл
файлы исходного кода и заголовочные файлы =)

sb3d
> WinApi
Пичаль. Может быть все же посмотрите в сторону Qt?

CStalkerПостоялецwww14 ноя. 201213:33#10
nes
> Имхо игра это такой тип приложения которому нужно 100% мощности ЭВМ.
Нет, 100% мощности ЭВМ требует только тест-программы на выгорание процессора. Игра, как и все остальные приложения, должна потреблять столько процессорного времени, сколько ей требуется для работы.

sb3d
Я всегда использовал Sleep(0), что полностью разгружало процессор, если верить диспетчеру задач. Самый простой способ. Оптимальный ли - не в курсе.

NecrysПостоялецwww14 ноя. 201213:51#11
sb3d
> А попиксельного контроля при выводе через ускоритель нет. Сейчас я могу при
> выводе изменить палитру, проходить алгоритмом повышения чёткости, накладывать
> освещение, шум, лучи света, ещё кучу эффектов. А ускоритель как спрайт
> растянет, так уж и растянет. Пример добавлю: настройка масштабирования спрайта
> в духе "бикубическое", "линейное", "без сглаживания".
Усё там есть. Пиксельные шейдеры кому придумали?
Developer_AПостоялецwww14 ноя. 201214:02#12
Necrys
автор топика не любит ускорители, ему нравится писать свой рендер, который будет устроен именно так, как ему надо. :)
sb3dУдалёнwww14 ноя. 201214:47#13
CStalker
> Я всегда использовал Sleep(0), что полностью разгружало процессор, если верить
> диспетчеру задач. Самый простой способ. Оптимальный ли - не в курсе.
Беда в том, что разгружать проц обычно нужно очень крохотными по времени участками. Ну, к примеру, 60 раз в секунду вызываем игру, она там крутит-вертит-считает 1/120 секунды. В итоге, когда игра возвращает управление движку, нам нужно освободить 1/120 секунды через Sleep. Ровно до следующего вызова игры, которые 60 раз в секунду. Ну, а Sleep не отдаёт управление точно в срок, а отдаёт всегда позже. Как результат - неровное движение в игре, подёргивания. А иногда и просто тормоза. Так было в прошлом движке.

И это при использовании точнейшего таймера на QueryPerformanceCounter.
Поэтому вопрос, как регулярно и короткими промежутками освобождать процессор? Я вот не знаю даже.

Наверняка сюда могут заглянуть авторы своих движков. Было бы интересно их решение.

ASDПостоялецwww14 ноя. 201214:47#14
Клевое название !!
Страницы: 1 2 361 62 Следующая »

/ Форум / Проекты / Утилиты

Тема в архиве.

2001—2018 © GameDev.ru — Разработка игр