За свои ~8 лет проганья я понял одну очень важную вещь. Если ты пишешь какую-то миддлварь(библиотеку и.т.п), она должна уметь минимальный требуемый функционал. Так же вышло и с движками, свои первые обертки над DX9 я выкладывал сюда 5 лет назад, и они были максимально просты(на уровне LoadSprite, DrawSprite, LoadSound, PlaySound), и я на них сделал даже одну-две игры. Время шло, опыт набирался, мой миддлварь стал быть чем-то сложным и неповоротливым - огромная куча абстракций, оно умело все, но в то же время следить за кодовой базой стало сложно, начал путаться в своей же библиотеке. На этом движке я так и не сделал ни одной игры, любой потуг заканчивался наращиванием функционала движка.
Поэтому я решил написать небольшой 3D движок, который мог бы выполнять 3 самых важных вещи - рисовать модельки/спрайты используя несложную систему материалов, играть звук, обрабатывать ввод. Всё, никаких сценграфов, никакого сложного API, весь движок умещается в ~50 экспортированных функций.
Рендер:
DX9 рендеререр с заделом под мультирендер, правда статичный(порт на GLES будет первой задачей после релиза), только FFP, фактически все гапи умещается в 4 функции: wgeSetTransform, wgeSetMaterial, wgeSetProjectionParams, wgeDrawVertices, ну и текстуры конечно.
Все рендерстейты задаются через материалы(чуть позже будет стенсил), под капотом все три захардкоженных слоя(диффуз + отражение + лайтмап) смешиваются быстро и эффективно. Сначала хотел сделать как и раньше в своих движках - многослойную(до 8 слоев) программируемую систему материалов на манер шейдеров в Quake 3, но потом подумал что это не нужно.
Анимация только морфинг, скиннинг ненужон учитывая простоту конкурсных игр. Хотел запилить поддержку BSP из первой халвы, но там свои заморочки есть с индексами и UV, поэтому чуть позже будет поддержка BSP из Q3.
Из оптимизаций будет куллинг по дистанции с затуханием, фрустум, возможно будет квадтри. Алсо попробую сделать куллинг по перекрытию - откопаем так называемый Occlusion Query(кстати зачем его выпилили из новых API?). Батчинга нет даже для 2D.
В идеале хочу чтобы движок запускался и работал на GeForce 2. Пеки с такими хар-ками есть, так что для тестов буду запускать и там.
Текст только ASCII, причем для шрифтов юзаю древнюю прогу xproger'а - xfont.
Звук:
Ну тут все просто, как везде.
Ввод:
Пока поддержка только клавиатур, затем - мышей и геймпадов. Пока никаких аксисов еще нет.
Движок писался для души, чисто сюда на конкурсы или на гамин, или просто что то для души сделать. Для сложного есть юнити.
Алсо касательно исходников, сначала хочу SDK зарелизить с заголовочником, если кому понравится то и исходники подъедут. Скрины чуть позже залью, когда будет что показать из демок(скорее всего вместе с конкурсной игрой).
mv2 написал:
движок, который мог бы выполнять 3 самых важных вещи - рисовать модельки/спрайты используя несложную систему материалов, играть звук, обрабатывать ввод. Всё, никаких сценграфов, никакого сложного API, весь движок умещается в ~50 экспортированных функций.
А этого достаточно для игры? Мно просто интересно, я не с целью поддеть или вроде того. Вот, по возможной теме конкурса следующей - скроллер осилит? Я, скорее всего, неправильно себе представляю и ты сейчас с недоумением читаешь мои вопросы, но что поделать - я не понимаю)
mv2 написал:
движок, который мог бы выполнять 3 самых важных вещи - рисовать модельки/спрайты используя несложную систему материалов, играть звук, обрабатывать ввод. Всё, никаких сценграфов, никакого сложного API, весь движок умещается в ~50 экспортированных функций.
А этого достаточно для игры? Мно просто интересно, я не с целью поддеть или вроде того. Вот, по возможной теме конкурса следующей - скроллер осилит? Я, скорее всего, неправильно себе представляю и ты сейчас с недоумением читаешь мои вопросы, но что поделать - я не понимаю)
Ну да, функционал не в количестве функций измеряется)
Игрушку на конкурс и собираюсь на нем делать.
StormT_GMS написал:
Вот, по возможной теме конкурса следующей - скроллер осилит?
Осиливает участник, а не движок. Суть в том, что если участник знает что и как нужно сделать, движок дело сильно второстепенное.
В случае с своим великом было бы странно не приценивать возможности :)
Ну или не иметь возможности допилки, но тут мы не упираемся не в API, не в архитектуру.
Вопрос "а можно ли сделать X на Y" живучее гриппа и неистребимее тараканов :)
И с 99.9% вероятности задающий не сделает Y, какой бы X ему не дали. Потому что он не очень представляет как делается Y и ожидает, что за него всё сделает X :)
Тот кто знает, и подыскивает себе двиг, он задаёт не философские, а более конкретные вопрос по движку
(пример:
пусть будет скроллер. Брём за идёю, скажем, Blast-Off.
Нужно выводить задник, базы, звёзды/мусор, корапь героя, выстрелы, врагов, взрывы
Что нужно от движка (чтобы не мудохать это самому)
Вывод текстур как спрайты (или любой другой аналог)
Апскейл с билинейной экстраполяцией.
Базовые операции бленда (+, -, мульт)
Вывод около 1000 спрайтов за фрейм (т.е. около 1000 спрайтов за 1000/60 мс) без просадки.
Всё :)
Из того, что я читал в описании, твой двиг такое осилит и не подавится (если вообще заметит напряг из-за каких-то 1000 спрайтов. Просто потому, что он у тебя достаточно низкоуровневый).
Сможет ли произвольный юзер написать на нём скроллер? ;) Да фиг там. И не потому, что двиг плохой. :) Вот о чём речь.
)
Это вообще сложный и дискуссионный вопрос про оптимальное апи
Так то операция ИЛИ-НЕ с доступом по произвольной памяти Тьюринг полная (хотя не представляю как) и можно что хочешь писать
Удобство - другой вопрос.
Но Я согласен, что для конкретных случаев (те же спрайтовые движки) можно обойтись очень компактным апи.
Mefistofel написал:
Это вообще сложный и дискуссионный вопрос про оптимальное апи
Так то операция ИЛИ-НЕ с доступом по произвольной памяти Тьюринг полная (хотя не представляю как) и можно что хочешь писать
Удобство - другой вопрос.
Но Я согласен, что для конкретных случаев (те же спрайтовые движки) можно обойтись очень компактным апи.
Про ограничения архитектуры я говорил что проблемы начинаются когда ты хочешь написать условный 2д сайдскроллер с шейдерами, а у тебя есть условный движок который умеет рисовать только 3д модельки да и то только с диффузом условным. т.е здесь ограничения заложены движком, но если же архитектуру достаточно упростить и ввести более низкий уровень(например вывести низкоуровневое апи для управления камерой и треугольнками) - то такие проблемы отсеиваются.
Ну и к чему я по большей части клоню этой пеленой текста - чем проще тем лучше, но иногда оставлять простую высокоуровщину это очень хорошо. Примерно так и взлетел первый DGLE например, да и у тебя ж вроде движки на паскале были, думаю там примерно такая же философия.
Тут как с офисом - люди используют только 10% его возможностей.
Но разные люди - разные 10%
Поэтому скорее важен не минимализм в целом (попытаться выразить функции минимальным набором команд), но компромисс минимализма, функциональности и удобства для всех покрываемых областей. Ну и другие есть требования - например производительность
Поэтому да, как в твоем примере - нужно сделать, условно, простой метод вывода спрайтов, даже если он не производительный. А для производительности оставить более сложное апи, позволяющее выводить спрайты батчами, к примеру.