Перейти вниз
Admin
Admin
Admin
Сообщения : 46
Дата регистрации : 2019-08-31

Игра в духе Серьёзного Сэма Empty Игра в духе Серьёзного Сэма

в Ср Окт 09, 2019 6:35 pm
Предыстория:
Психанул. Смотрел ролик
Спойлер:
и придумал сию идею.
Суть: было бы неплохо, замутить FPS. (говно)Двиг у меня уже есть, точнее игра срощенная с движковой частью, и если выкинуть из проекта саму игру -- останется лишь двиг. Остается только сделать на нём FPS, что весьма непросто, ибо, в том числе, нужно скриптование геймплея, сценария и спецэффектов, а у меня на это нет ни времени, ни сил. Но graveman... как раз мается без дела -- опять вместо игры ковыряет движковую хренотень -- можно припахать... скажем, в роли гугл-ассистента, адаптирующего готовые скриптовые решения под мой двиг. Осталось лишь замутить тему с подходящим названием, и profit! вуаля!
Движок: самопальный, безымянный 10
Название: "3-й контакт"
Жанр: Серьёзный Сэм
Сеттинг: в духе Серьёзного Сэма
Предыстория: безымянный герой, ни капли не прохожий на Серьёзного Сэма, сражается с ордами, накатывающих волнами, врагов, пытаясь в далёком египетском прошлом, спасти Землю от вторжения пришельцев.
Admin
Admin
Admin
Сообщения : 46
Дата регистрации : 2019-08-31

Игра в духе Серьёзного Сэма Empty Re: Игра в духе Серьёзного Сэма

в Ср Окт 09, 2019 7:30 pm
С чего бы начать... Пожалуй, стоит обсудить, в общем, недостающие "части игры" (в порядке уменьшения важности):
1) Враги;
2) Механика стрельбы из разных стволов;
3) Различные элементы игры;
4) Контроллер игрока.

======================

1) Враги. Самая сложная и непонятная для меня часть. Как подобное сделать -- вообще без понятия. А без нормальных врагов -- Сэм -- не Сэм.
Пока мой максимум -- тупо загрузить модельку врага из какого-нибудь obj-формата и расставить в виде неподвижных болванчиков с цилиндрическими коллайдерами по уровню, а это даже не близко. И кстати это будет сделано говнокодом, вырезанным с прошлых движков, а в текущем нет ни загрузки внешних моделей, ни уровней, ни физики. Считай ничего.

Думаю, чтобы сделать врагов, аналогично, в порядке убывания важности, нужно решить ряд задач:
1.1) AI-врагов. Вообще хз как делать;
1.2) Реакции врагов на события, типа смерть, появление, получение урона, атака цели, перемещение по местности. Аналогично, хз;
1.3) Анимация моделей NPC. Думаю, если почитать тематическую лит-ру, то смогу, но влом. Кстати, можно сделать программную анимацию, это похуже, но при норм AI можно в принципе вытянуть Сэмовский уровень;
1.4) Загрузка NPC (ну там модели, текстуры, анимация, скрипт AI). Это уже хоть как-то могу, хотя лучше нормально... В принципе, этот пункт нужно сделать первым, но поскольку он самый простой в реализации из 4-х + хоть как-то я и так могу = его обсуждение можно отложить в самый конец.

======================

2) Механика стрельбы из разных стволов. Весьма плохо представляю как такое делать. Очень примитивно уже делал, но нужно норм. Так же, качество реализации критически важно.

Аналогично, состоит из подзадач (в прядку убывания важности):
2.1) Анимация (смена оружия, стрельба, перезарядка + блики на стволе). Самая сложная часть. Возможно, без шейдеров никак, а я их вообще никак. (к слову, в моём движке только фиксированный конвеер и без освещения)
2.2) Механика стрельбы (выпускание пули, её полёт, попадание). Пункт чуть попроще в реализации. В принципе даже смогу сделать не сильно убого, да и духу Сэма низкокачественная механика не сильно повредит. Но всё равно лучше сделать "как надо".
2.3) UI (здоровье + боезапас и др.) В принципе, могу. Но это ж нужно делать))
2.4) Загрузка стволов из файла. См. п.1.4 "Загрузка NPC".

======================

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

======================

4) Контроллер игрока. Самая простая в реализации часть игры. В движке есть базовая реализация вращения камеры мышью. Проблема только в том, при беге и вращении камерой должна быть анимация камеры и оружия в руках. В принципе, поскольку пункт самый простой, то его можно сделать первым. Но поскольку он простой, то важность его обсуждения низкая. (Короче сделаем его первым, но сперва нужно решить проблемы первых 3-х пунктов, ибо пока их не решим, пилить сам код контроллера нет смысла -- кому нужен Сэм без врагов и стрельбы, но с покачиваниями камеры при беге?)
graveman
graveman
Сообщения : 22
Дата регистрации : 2019-10-05
Откуда : Татарстан
https://coderdailynotes.wordpress.com

Игра в духе Серьёзного Сэма Empty Re: Игра в духе Серьёзного Сэма

в Пн Окт 14, 2019 8:33 pm
Не читал детально (ибо уставший вхлам). Но наверное стоит начать таки что-то делать, раз уж и эпс и я никак не можем успокоиться. Поскольку работа в геймдев-индустрии мне не светит, да и уже мне давно не охота быть просто каким-то там жалким прогером, то на архитектуру движка можно и забить упростить, хотя не знаю. Уж очень я уважаю крепкий фундамент.
Запуперю я для начала некий математический фундамент - как раз насчет матана загоняюсь вечерами сейчас.
... Было начал я опять крутить старую пластинку. Э-э, плевать! Если дяди с хрустящими купюрами в карманах начнут ими вертеть у моего носа и скажут давай другие игры пиши или там для плейстейшена, то тогда и буду нормальный двиг фигачить. А сейчас драйв геймдизайна, треш и угар - надеюсь хоть с этим эпсилон со мно будет солидарен!
Ну, начнем книжечки товарища Луны читать и товарища Адамса читать.

Admin
Admin
Admin
Сообщения : 46
Дата регистрации : 2019-08-31

Игра в духе Серьёзного Сэма Empty Re: Игра в духе Серьёзного Сэма

в Пн Окт 14, 2019 9:13 pm
Фундамент -- это хорошо, но ты сперва хотя бы в общем распиши свои задачи в блокноте. Ибо практика показала, что недели через 2 всё равно выдохнешься учить теорию и/или строчить код, а так хотя бы перед глазами будет напоминался что, как и вообще зачем планировал делать. Пример как я наступил на эти грабли: меня как-то глюкнуло, и меня опять понесло пилить двигло, писал в угаре несколько часов кряду, очнулся пора спать к тому же застрял на функции рендеринга банера из bmp в окно. ... через пару дней дошли руки опять пописать, а уже начал забывать в чём суть двигла и в каком стиле хотел пилить... короче забросил. Вывод: всегда сперва в общих чертах записывай план работ на бумагу, и лишь потом начинай кодить. Или так: чувствуешь что застрял? Срочно пиши план пока не забыл, ибо вероятно застрвание может оказаться вершиной айсберга который бортанёт твою задумку на дно.

А вообще, я тебя не понимаю: концепцию игры расписывать не хочешь, мелочи движка (навроде DX-обертки, своего std::map, нормальной основы основы движка и т.д.) тоже, контент тоже не клепаешь (но тут ещё можно понять что моделлер из тебя так-себе, но не одними моделями... к тому же можно напылесосить временные модели-заглушки с инета), расписывать архитектуру движка тоже. Что вообще остаётся? Ты будто специально пытаешься загнать себя в рамки "написания норм двигла в один присест и целиком", хех туннельное мышление детектед, если бы мог -- давно бы сделал.
graveman
graveman
Сообщения : 22
Дата регистрации : 2019-10-05
Откуда : Татарстан
https://coderdailynotes.wordpress.com

Игра в духе Серьёзного Сэма Empty Re: Игра в духе Серьёзного Сэма

в Вт Окт 15, 2019 4:37 pm
Чувак. Не нужен свой std::map. Писать аналоги контейнеров - самое бесполезное занятие. Это раз. Два - это то, что частично обертки для DX написаны.
Механика стрельбы тоже частично описана. Модель одну склепал. Анимировать осталось. Основа основ(предлагаю более короткий термин предоснова) движка уже есть.
...
Я сделал вывод, что ты хорош как имплеменьатор алгоритмов и тестер. Так вот давай начнём с дерева. Оно послужит базой скенграфа. У Адамса дебильно сделано - лишние расчёты и вообще структура d3dxframe_ex выглядит как кусок говнп чисто эстетически. Древоузла базовый класс я написал. Допишу производный класс для тестирования и сегодня постараюсь выложить на гитхаб. Твоя задача - протестировать его. Сделать примеры и прогнать. Это основа скелетной анимации.
graveman
graveman
Сообщения : 22
Дата регистрации : 2019-10-05
Откуда : Татарстан
https://coderdailynotes.wordpress.com

Игра в духе Серьёзного Сэма Empty Re: Игра в духе Серьёзного Сэма

в Вт Окт 15, 2019 8:56 pm
Дал себе задание - ложиться не позднее 22.00. Немного не поспеваю сделать NamedHierNode. Задача теста откладывается назавтра. Вот репозиторий библиотеки, помогающей олдскульному геймдевелоперу.
Для теста завтра сделаю NamedHierNode. Сегодня начал делать узел с трансформацией.
Admin
Admin
Admin
Сообщения : 46
Дата регистрации : 2019-08-31

Игра в духе Серьёзного Сэма Empty Re: Игра в духе Серьёзного Сэма

в Вт Окт 15, 2019 9:51 pm
> Не нужен свой std::map.
Ну не мапа, так что-то другое, например свой лог... мало ли самопальной хрени ты писал... короче, разные мелкие мелочи из которых строится движок.

> Два - это то, что частично обертки для DX написаны.
Ну ок, просто я кажется недавно от тебя же слышал, что ты собираешься написть свою обёртку.

> Механика стрельбы тоже частично описана.
Тоже ок. Только чего тогда у тебя её нет? Не вижу ни одной дески со стрельбой на своём двигле. (На КатМазере 1 раз видел и всё.)

> Основа основ(предлагаю более короткий термин предоснова) движка уже есть.
Ок, тогда наверное стоит предложить тебе начать следующий этип... правда я сам хз какой он, ибро я его не осилил -- застрял в самом начале как только написал код хранения и рендеринга Главного меню, UI, руко-пушек и мира. Вроде как потом нужно было писать код заполнения этих компонентов и управления ими, и вроде как всё вместе это назывется менеджером сцены. Но т.к. я застрял считай в самом начале, то хз каким в итоге должен стать этот этап.
А вот основу основы движка я более-менее прошёл, и более-менее разбираюсь что там и как должно быть.

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

> ты хорош как имплеменьатор алгоритмов и тестер.
Да, тестер из меня неплохой. (Хотя знакомый тестер сказал, что без теоретической базы, хорошим темтером мне не стать. Хм.)

> Так вот давай начнём с дерева.
> Древоузла базовый класс я написал.
Что такое древоузел? Это что-то из области Менеджера Сцены, где все визуальные элементы являюися частью древовидной структуры, состоящей из узлов?

> Вот репозиторий библиотеки,
Посмотрел. Пока ни о чём.
- Кстати, зачем нужен метод IsAllowedToAppend, когда можно вызвать Append? И далее действовать в зависимости от возвращённого значения.
- "HierNode::HierNode() : next_(0), prev_(0), parent_(0), child_(0) {}" не знал, что так можно, возможно здесь ошибочный синтаксис.
- "void HierNode::Unlink() {\n    if (!IsLinked()) return;" значит ты никак не обрабатываешь подозрительные события. Ну ок, но если что -- будешь долго искать ошибку...
- "HierNode* HierNode::Parent() {\n    return parent_;" опять ООП-маразм -- сделать метод, чтобы вернуть одноимённый атрибут...
graveman
graveman
Сообщения : 22
Дата регистрации : 2019-10-05
Откуда : Татарстан
https://coderdailynotes.wordpress.com

Игра в духе Серьёзного Сэма Empty Re: Игра в духе Серьёзного Сэма

в Ср Окт 16, 2019 9:02 pm
>Ну не мапа, так что-то другое, например свой лог... мало ли самопальной хрени ты писал... короче, разные мелкие мелочи из которых строится движок.
Н-да, это есть. Но разбросано. ейчас как раз и занимаюсь тем, что собираю все в одну кучу, дописывая попутно новое.
Сегодня написал подкласс узла дерева с поддержкой обновления всей иерархии и грязным битом (паттерн оптимизации). Дальше будет уже "полезный" подкласс собственно узла сцены.

>Ну ок, просто я кажется недавно от тебя же слышал, что ты собираешься написть свою обёртку.
Полностью писать передумал, потому что я изначально это хотел сделать, чтобы потом с этой dll под Паскалем работать. А нужные вещи частично есть. Они делают очень нудную работу.

>Только чего тогда у тебя её нет? Не вижу ни одной дески со стрельбой на своём двигле.
Пока есть теоретические изыскания в LibreOffice-документе. Придумаешь куда выложить, выложу почитать.

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

>> ты хорош как имплеменьатор алгоритмов
>Это что за профессия?
Не профессия, а типа склонности в области программирования. Ты ж запилил тогда прогу для процедурных текстур.

>Что такое древоузел? Это что-то из области Менеджера Сцены, где все визуальные элементы являюися частью древовидной структуры, состоящей из узлов?
Да, верно. Теперь тебе пора мыслить в категориях узлов сцены. Меши, террейн, скайбокс, источники света и даже камера - все это узлы сцены. Во всяком, случае придется, ибо я без этого не мыслю движок.

>> Вот репозиторий библиотеки,
>Посмотрел. Пока ни о чём.
Полезность проявится, когда я сделаю подкласс 4-го уровня. Пока два уровня сделаны.
> - Кстати, зачем нужен метод IsAllowedToAppend
Я и сам думал над тем, чтобы засунуть его в приват, пока не стал. Вдруг пригодится.
>- "HierNode::HierNode() : next_(0), prev_(0), parent_(0), child_(0) {}" не знал, что так можно, возможно здесь ошибочный синтаксис.
Эх, чувак! Я уже забыл время, когда я не использовал этот синтаксис.

>- "void HierNode::Unlink() {\n    if (!IsLinked()) return;" значит ты никак не обрабатываешь подозрительные события.
Не понял вопроса

>- "HierNode* HierNode::Parent() {\n    return parent_;" опять ООП-маразм
 Smile Чтобы не изменяли parent_ из внешнего кода.

P.S.: я опять не успел столько, сколько планировал. Получается только 2 часа после работы.
Admin
Admin
Admin
Сообщения : 46
Дата регистрации : 2019-08-31

Игра в духе Серьёзного Сэма Empty Re: Игра в духе Серьёзного Сэма

в Чт Окт 17, 2019 12:31 pm
>>> ты хорош как имплеменьатор алгоритмов
>>Это что за профессия?
>Не профессия, а типа склонности в области программирования. Ты ж запилил тогда прогу для процедурных текстур.
Ясно. Ну, тогда у меня такой склонности нет. "Прогу для процедурных текстур" не помню. Просто наверное в силу каких-то обстоятельств мне показалось что какие-то там алгоритмы стоит реализовать у себя в двиглу... нужно смотреть конеретику почему я так решил, а на вскидку не отвечу.

А может быть я просто не очень опытный в чтении чужого говнокода и более опытный в реализации сложных алгоритмов. (Зря чтоли пытался сделать свой архиватор, софтрендер, оболочку к винде, увеличяитель картинок в 16 раз чтобы поменьше артефактов и т.д.)

> Теперь тебе пора мыслить в категориях узлов сцены. Меши, террейн, скайбокс, источники света и даже камера - все это узлы сцены. Во всяком, случае придется, ибо я без этого не мыслю движок.
Эм, мне кажется что так категорично кидаться в древовидностьтоже не стоит. Считавй что это моя прогерская интуиция, говорит что такая архитектура не лцучший вариант.

> скайбокс, источники света и даже камера - все это узлы сцены
Хм. Не прекдставляю как такое может быть и нафига. Разьве что это будут непосредственные children root-узла, ибо всё это весьма глобальные вещи.

>- "void HierNode::Unlink() {\n if (!IsLinked()) return;" значит ты никак не обрабатываешь подозрительные события.
>Не понял вопроса
Ну, как прогер, создавший узел, ты и так должен был знать был он присоекдинён или нет. А если результат проверки отличается от ожидаемого -- походу ты чёто не то напрогал => возможна ошибка в алгоритме проги, а такие ошибки сложно отследить. Поэтому если тебе нужна подобная проверка -- ты хреновый прогер, а если она тебе не нужна, но ты её вызвал -- скорее всего ты неуверен в результата проверки, а значит этот результат лучше где-то вывести, а лучше либо в МесседжБоксе, либо в лог.

>- "HierNode* HierNode::Parent() {\n return parent_;" опять ООП-маразм
> Smile Чтобы не изменяли parent_ из внешнего кода.
Для этого есть атрибуты ну там гет-сет-дефолт. Городить метод не обязательно.
(Хотя ткут уже Я СЕБЯ проявляю как маньяк тотальной оптимизации)))

graveman
graveman
Сообщения : 22
Дата регистрации : 2019-10-05
Откуда : Татарстан
https://coderdailynotes.wordpress.com

Игра в духе Серьёзного Сэма Empty Re: Игра в духе Серьёзного Сэма

в Пт Окт 18, 2019 9:07 pm
Короче. Я не знаю, буду ли объединять все или нет. Какой смысл - все разномастно. Кому надо скачает то, что надо. Вопрос в том, что нужно подрихтовать и документацию то же для удобства использования. Пока дрочу на стиль кода в иерархическом узле. Завтра планирую с утра разбираться в трансформациях узла - сделаю типа кубическую модель, обрисую у ней текстуры (лицо, зад, бока, верх, низ) и на основе нее и своих поделок на гитхабе буду проверять правильность работы алгоритмов вращения, масштабирования и перемещения.  
Кстати ИИ в аркадных шутерах прост до безумия - зря ты так волнуещься. Ну и скрипты никто не отменял.
Главное с математикой разобраться и сделать нормальную библиотеку узлов и фундаментальных прибамбасов, а дальше дело попрет. Загрузка меша из файла - это фигня (я пробовал). Ну сейчас ты скажешь, что можешь взять мат.функции из D3DX. Я вот не очень понимаю как работают некоторые из них.
Admin
Admin
Admin
Сообщения : 46
Дата регистрации : 2019-08-31

Игра в духе Серьёзного Сэма Empty Re: Игра в духе Серьёзного Сэма

в Сб Окт 19, 2019 6:45 pm
Ясно.
Опять неконструктивный диалог.

Ладно, а если так: можешь сделать хоть какую основу движка? И залить на dropmefiles.com
Будет хоть какой-то резцультат.
Кстати, напомню, основа движка, т.н. основа основы -- это всё до самого рендеринга и скриптов (в т.ч. контрололера).
Кстати, моя основа движка выглядит так https://dropmefiles.com/oEuHE (но тебе естественно не подойдёт ибо недостаточно ООПонуто и наворочено). P.S.: всё что закоменчено можно удалить.
graveman
graveman
Сообщения : 22
Дата регистрации : 2019-10-05
Откуда : Татарстан
https://coderdailynotes.wordpress.com

Игра в духе Серьёзного Сэма Empty Re: Игра в духе Серьёзного Сэма

в Сб Окт 19, 2019 7:03 pm
Кажись понял. Для меня основа движка - это не окно+D3dinit+Говнокод камеры. Это скорее чистые вылизанные классы типа SceneNode, CameraNode, TerrainNode, Mesh, MeshNode, SkyboxNode, LightNode, Material, анимационные и подобные. То есть ты берешь их и обвязываешь халтурным кодом создания окна, инициализации d3dx-ом.  Основа - это алгоритмы и структуры, форматы, экспортеры.

В марте я еще писал экспортер из блендера на питоне в свой формат. Сегодня сел за его продолжение (свинья на танке пока откладывается). Его фича в том, что он позволяет получить структуру меша, удобную для DirectX9.

>Ладно, а если так: можешь сделать хоть какую основу движка? И залить на dropmefiles.com
О-о! Внезапно, на этой неделе тоже юзал дропмифаелс для себя.
Так-то могу к пятнице написать основу основ.  Давай кстати так - к пятнице или к субботнему вечеру готовим основы основ по-максимуму и хвалимся перед друг другом конструктивно обсуждаем то, что получилось. Если конечно всякие форс мажоры и непредвиденные обстоятельства не испортят планы.

>Кстати, напомню, основа движка, т.н. основа основы -- это всё до самого рендеринга и скриптов (в т.ч. контрололера).
Напишика список, что туда должно входить, при случае
Admin
Admin
Admin
Сообщения : 46
Дата регистрации : 2019-08-31

Игра в духе Серьёзного Сэма Empty Re: Игра в духе Серьёзного Сэма

в Сб Окт 19, 2019 7:36 pm
> Для меня основа движка - это не окно+D3dinit+Говнокод камеры.
Мы это уже обсуждали, поэтому мой теормин "основа движка" мы решили переименовать в "основа основы движка". Какие опять непонятки в моей терминологии вроде ж всё утрясли?

> Это скорее чистые вылизанные классы типа SceneNode, CameraNode, TerrainNode, Mesh, MeshNode, SkyboxNode, LightNode, Material, анимационные и подобные.
Т.е. то, чего у тебя нет)) Это слишком сложно, чтобы делать из этого 1-й этап. И только поэтому я свою "основу основ движка" выделил как 1-й этап. А то б коннечно замутил как положено у больших дядей из мира ААА-игр.)))

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

> Основа - это алгоритмы и структуры, форматы, экспортеры.
Инициализация окна тоже алгоритм... Экспортёры... ну хз, вроде в блендере уже и так их полно...

> Давай кстати так - к пятнице или к субботнему вечеру готовим основы основ по-максимуму
Моя уже у тебя -- я только что дал ссылку на скачивание.

> конструктивно обсуждаем то, что получилось.
Ну... частично это мой план как заставить тебя вместо очередного экспортёра таки начать пилить игру. Только обсуждение моего основы тебе ничего не даст, а вот я думаю смогу выкинуть пару кусоков говнокода из твоей и уболтать тебя хотя бы на твоей основе продолжить пиление игры...

>>Кстати, напомню, основа движка, т.н. основа основы -- это всё до самого рендеринга и скриптов (в т.ч. контрололера).
>Напишика список, что туда должно входить, при случае
Ладно, хотя ты и так мог бы понять открыв её код.
Там просто логически завершённая часть движка, типа до того ничего внешне как бы ничего и нет (ну не считатьпрогу умеющую лишь создать окно движком), а так -- это минимум чтобы хоть что-то можно рендерить (да, рендеринг залитого одноцветом заднего DX9-буфера уже считается за рендеринг хоть чегото). И пилится с нуля всего за сутки. Да нельзя вертеть камерой и нет поддержки рендеринга ветексбуферов.
А вот если делать следующтий этап, чтоб уже рендерить вершинные буфера, то чтоб получилось что-то законченное (с норм рендерингом, глобальными стуктурами, заполнением), то это уже минимум 24 человеко-часа и считай 2 дня очень упорного труда. Короче очень сложно.
Короче это лог законченный этап движка, а если делать следующий то там чтоб его осилить нужно очень дохрена поэтому можно слиться раньше. Хех, вроде несгораеммой суммы в ктохатет стать мсиллионером .
Admin
Admin
Admin
Сообщения : 46
Дата регистрации : 2019-08-31

Игра в духе Серьёзного Сэма Empty Re: Игра в духе Серьёзного Сэма

в Ср Окт 23, 2019 8:23 pm
graveman пишет:>Кстати, напомню, основа движка, т.н. основа основы -- это всё до самого рендеринга и скриптов (в т.ч. контрололера).
Напишика список, что туда должно входить, при случае
Точного списка быть не может, т.к. это сильно зависит от специфики движка: софтрендер либо GAPI, голое WinAPI или VCL-окна, ассерты-логи или нафиг эти ООП-замуты и т.д.
Это как граница между туловищем и головой -- её не провести с точностью до миллиметра, но логически (или с точностью до 10 см) она очевидна.

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

Пойдём этим же путём:
- Пустой проект это двиг? Очевидно, нет.
- Прога, умеющая делать окно, закрывающееся на Escape -- это двиг? Нет, это просто оконное приложение.
- А если прога умеет не только делать окно и инициализацию GAPI? Всё равно как-то маловато.
- А если и инициализацию и рендеринг хоть чего-то (например однородно залитого цветом заднего буфера)? А вот это имхо уже похоже на двиг.

Допустим, у нас классическая связка -- голое WinAPI и DirectX, тогда минимальная граница для статуса "основа основы движка" это наличие:
- код создания окна;
- код функции окна;
- код цикла обработки сообщений;
- код инициализации DX;
- код заливки цветом и рендеринга заднего буфера.

Функционал понятен. А насчёт логической завершённости: убери хоть что-то и вся конструкция перестанет работать (рендерить задний буфер).

НО, зачем останавливаться на минималках?)

Когда ты написал прогу, способную рендерить задний буфер, что будешь делать дальше? Правильно, возиться с рендерингом полигонов. А это сложно.
Хотя бы:
- структура хранения вершин (Vertex либо Mesh);
- структура хранящая компоненты (либо ссылки на них) рендерящихся объектов (вершинный буфер + текстуру + матрицу трансформации);
- массив содержащий все рендерящиеся элементы;
- обход массива рендерящихся элементов, с отрендерингом каждого элемента;
- а если вместо массива рендерящихся элементов мутить свой граф сцены... или менеджеры ресурсов...

Функционально, тут идёт рендеринг многокомпонентных элементов. И так же, пока всё это не реализуешь, результат -- "рендеринг многокомпонентных элементов" -- не увидишь. (Хотя, тут уже не так критично -- можно и схалтурить: вместо графа юзать одномерный массив, вместо менеджера компонентов юзать только сами компоненты, и вообще оставить лишь вершинный буфер с матрицей трансформации.)

И так, если 1-я законченная стадия написания движка -- это отрендерить хоть что-то, то какая 2-я? Правильно! Отрендерить набор элементов. И для этого надо написать всё то, что я расписал выше (а это, к слову, дофига кода). Думаю, очевидно, что это можно назвать "нижней границей второго этапа написания движка".

Думаю, про 1-й и 2-й этапы, более-менее понятно -- чем различаются, функционально и структурно (какие пункты должны быть чтобы реализовать необходимый функционал). Осталось дополнить про структурно, границы, вариации и время.

Границы и структурно.
Нижняя граница 1 этапа -- это минимум для рендеринга вообще. А нижняя для 2-го -- "рендеринг набора элементов". Так вот, между ними -- есть "зазор" в который попадает весь код-функционал-часть_архитектуры_движка что ты написал дополнительно. Например: ассерты, получение состояния клавиш/позиции мыши, код удаления ресурсов при закрытии проги, код чтения файлов, конфигов и т.д.
Так вот, я не знаю, что ты там у себя можешь написать (вдруг ты написание движка начинаешь с написания меша и классов графа сцены), но лично я сперва пишу весь код, позволяющий реализовать весь необходимый функционал для работы с операционкой и самим GAPI. В итоге получается законченная конструкция, в которой я могу сосредоточиться исключительно на рендеринге элементов и скриптах, и не беспокоиться более о "работе с операционкой и самим GAPI".
Короче, моя версия "основы основы движка" -- это "минимум для рендеринга вообще" + "весь необходимый функционал для работы с операционкой и самим GAPI". После чего остаётся только писать "рендеринг элементов и скрипты".

Блин, чёт криво расписал... Короче я расписал минимум для 1-го этапа -- "основы основы движка" и максимум, после которого уже начинается законченный 2-этап -- нижня граница 2 этапа -- рендеринг набора элементов. И мой 1 этап это не только необходимый минимум но и """ "весь необходимый функционал для работы с операционкой и самим GAPI". После чего остаётся только писать "рендеринг элементов и скрипты".""". Всё что сверх того, я отношу уже к 2-му этапу.
Вот только "весь необходимый функционал для работы с операционкой и самим GAPI" у нас разный, и я не помню как там сделано у тебя ибо ты не показываешь (секретничаешь?))). Так что у каждого из нас основа основы будет немного отличаться.

Кроме того, ты кажется ещё до "рендеринга набора элементов" сразу начинаешь строгать свой класс меша, шейдеры и логи и только потом уже создание окна и инициализация GAPI -- т.е. "минимум для рендеринга вообще". Тут такое дело... если делать это с нуля, то половина этого до "рендеринга набора элементов" не может быть использована, а вторая половина довольно сложна и до "рендеринга набора элементов" столь сложные штуки (вроде логов и супер ассертов) -- это как из пушки по воробъям -- мало смысла когда можно юзать средства попроще (вроде обычного if'а с MessageBox'ом).

Осталось про время.
1-й этап у меня уже отработан и пишется примерно за 8 часов чистого времени. (Правда там нет контроллера игрока, лишь переменные для хранения нажатых клавиш, ибо контроллер это уже категория скриптов.)
а 2-й этап я ещё не одолел, и только примерно представляю что там и как. Примерно он занимает 16-20 часов чистого времени.
А теперь смотри, пилю я себе пилю двиг... и вдруг опа -- он наконец может выдать отрендеренную картинку (пускай и однородно залитую цветом)... а чтобы увидеть "набор элементов" следующего этапа, мне ещё несколько часов потом пилить... Так что вот так я примерно и осознаю границу между этапами...

Хотя, в твоём случае, если сперва писать тяжёлые вещи (меш, ассерты, лог и т.д.), которые до 2 этапа просто не нужны, то за 8 часов не управиться.
С другой стороны, если не с нуля, а копипастить части своих наработок, то время на каждый этап сильно меняется. И тогда вполне можно свой меш и лог запихнуть в 1 этап -- меш хоть и не нужен до 2 этапа, но он не мешает получить статус 1 этапа, так что если хочется чтобы заранее было то можно, а лог хоть тоже не нужен до 2 этапа, но он напрямую работает с API-операционки, так что из-за "весь код для работы с API операционки..." можно запихнуть и на стадии 1 уровня.

Как-то так.
Бля Фуууух, как же я задолбался это набирать, убил 3 часа.
graveman
graveman
Сообщения : 22
Дата регистрации : 2019-10-05
Откуда : Татарстан
https://coderdailynotes.wordpress.com

Игра в духе Серьёзного Сэма Empty Re: Игра в духе Серьёзного Сэма

в Сб Окт 26, 2019 9:18 pm
Admin пишет:> Для меня основа движка - это не окно+D3dinit+Говнокод камеры.
Мы это уже обсуждали, поэтому мой теормин "основа движка" мы решили переименовать в "основа основы движка". Какие опять непонятки в моей терминологии вроде ж всё утрясли?
Все нормуль.
Admin пишет:
> Это скорее чистые вылизанные классы типа SceneNode, CameraNode, TerrainNode, Mesh, MeshNode, SkyboxNode, LightNode, Material, анимационные и подобные.
Т.е. то, чего у тебя нет)) Это слишком сложно, чтобы делать из этого 1-й этап. И только поэтому я свою "основу основ движка" выделил как 1-й этап. А то б коннечно замутил как положено у больших дядей из мира ААА-игр.)))

Да, это просто подход с другой стороны.

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

Я бы не сказал, что создание окна и инициализация D3D - фундамент. Ввиду относительной простоты их написания. Нормальную инициализацию, проверяющие наличие всех видеорежимов же ты вроде не сделал. "Халтурные ноды" это и есть фундамент. Ноды как раз нельзя делать халтурными, поскольку их реализация связана с алгоритмом. А только с полным пониманием, иначе в работе движка начнут происходить страшные явления и каша. А что окно? Оно или создастся или нет, тоже с инициализацией директ икса. Ну могут быть глюки, но их мало и они легко находятся, поскольку там нет алгоритма. Ну для тебя фундамент - это что-то готовое на экране.
Я это понимаю также - этот подход. Просто при программировании нодов нужно гораздо сильнее напрягать мозги. Это бывает довольно непрятно. Работа с абстрактным не всегда приятна для мозга. Поэтому, я предпочитаю сделать сначала самую грязную трудную работу, чтобы потом на фане делать окна и присобачивать D3D.

Admin пишет:
Инициализация окна тоже алгоритм...
Где ты там увидел алгоритм. Просто заполнение полей и вызов последовательных функций WinAPI согласно справочнику API и книжке Петцольда и Луны.
Admin пишет:
Экспортёры... ну хз, вроде в блендере уже и так их полно...
Я копался в экспортере DirectX(.x). Там при отметке галочки, ответственной за вывод uv-координат, создаются копии вершин для каждого полигона. Подход с использованием индексного буфера в DirectX жестоко проигнорирован.
И, кстати, по твоему, легко пропарсить .obj?
Admin пишет:
> Давай кстати так - к пятнице или к субботнему вечеру готовим основы основ по-максимуму
Моя уже у тебя -- я только что дал ссылку на скачивание.
Сейчас гляну. Эх, столько всего надо сделать. Хер время найдешь. Я и позабыл об этом. Кстати, не получилось сделать типа движкописательского джема. Ну хотя бы экспортер почти дописал. И то - хорошо. Вот математику трансформаций еще осталось добить и все - дальше интересное пойдет - шейдеры и игровой код. По крайней мере таков план.

Admin пишет:
> конструктивно обсуждаем то, что получилось.
Ну... частично это мой план как заставить тебя вместо очередного экспортёра таки начать пилить игру. Только обсуждение моего основы тебе ничего не даст, а вот я думаю смогу выкинуть пару кусоков говнокода из твоей и уболтать тебя хотя бы на твоей основе продолжить пиление игры...
Про экспортер я уже сказал: нужен оптимизированный выход (меньше вершин, больше индексов) и формат, удобный для парсинга. Кстати парсер я тоже напишу - его можно будет привязать к любому коду с легкостью подтирания задницы посредством туалетной бумаги.
Admin пишет:
да, рендеринг залитого одноцветом заднего DX9-буфера уже считается за рендеринг хоть чегото). И пилится с нуля всего за сутки. Да нельзя вертеть камерой и нет поддержки рендеринга ветексбуферов.
Это же очень скудно, чтобы называть это движком.
Admin пишет:
А вот если делать следующтий этап, чтоб уже рендерить вершинные буфера, то чтоб получилось что-то законченное (с норм рендерингом, глобальными стуктурами, заполнением), то это уже минимум 24 человеко-часа и считай 2 дня очень упорного труда. Короче очень сложно.
Ну дак я для того и пишу все эти ноды и экспортеры, чтобы можно было потом с ними легко загружать и рендерить 3d-модели, развлекаясь и прикалываясь над недодемками.
graveman
graveman
Сообщения : 22
Дата регистрации : 2019-10-05
Откуда : Татарстан
https://coderdailynotes.wordpress.com

Игра в духе Серьёзного Сэма Empty Re: Игра в духе Серьёзного Сэма

в Сб Окт 26, 2019 9:18 pm
На сегодня лимит ответов закончен
Admin
Admin
Admin
Сообщения : 46
Дата регистрации : 2019-08-31

Игра в духе Серьёзного Сэма Empty Re: Игра в духе Серьёзного Сэма

в Вс Окт 27, 2019 12:03 am
graveman пишет:Я бы не сказал, что создание окна и инициализация D3D - фундамент. Ввиду относительной простоты их написания. Нормальную инициализацию, проверяющие наличие всех видеорежимов же ты вроде не сделал. "Халтурные ноды" это и есть фундамент. Ноды как раз нельзя делать халтурными, поскольку их реализация связана с алгоритмом. А только с полным пониманием, иначе в работе движка начнут происходить страшные явления и каша. А что окно? Оно или создастся или нет, тоже с инициализацией директ икса. Ну могут быть глюки, но их мало и они легко находятся, поскольку там нет алгоритма. Ну для тебя фундамент - это что-то готовое на экране.
Я это понимаю также - этот подход. Просто при программировании нодов нужно гораздо сильнее напрягать мозги. Это бывает довольно непрятно. Работа с абстрактным не всегда приятна для мозга. Поэтому, я предпочитаю сделать сначала самую грязную трудную работу, чтобы потом на фане делать окна и присобачивать D3D.
Да, "нормальную" инициализация, я не делал, потому что:
- кто, кроме меня это заметит?
- а время на это нужно убить не мало;
- а если на перспективу... какова вероятность, что в ближайший год-два кто-то сможет оценить преимущества нормальной инициализации в сравнении с текущей? (Вот если бы мою игру запустили хот бы на паре тысяч компов -- я б ещё подумал, а так...)
|
ААААААА, чувак, у тебя в корне неверное представление о фундаментах: фундамент не должен быть неприменно сложным -- фундамент должен быть тем, на чём строится всё остальное, основой основ Wink А вот быть неприменно сложным он быть не обязан.
И, да, для меня "фундамент - это что-то готовое на экране", потому что лучше "готовое на экране", чем неготовое на бумаге Wink)
|
Давай немного уточним:
- Мой подход -- это: сперва 1 раз сделать норм обязку, а потом сколько-влезет пили нормальные ноды;
- Твой подход -- это: пилить нормальные ноды (до готовности), а в процессе (каждый раз, с нуля) пилить халтурные обвязки "на фане".
Всё верно? Если да, то продолжим...
А "(каждый раз, с нуля) пилить халтурные обвязки" это сколько раз? 5? 10? Допустим 10.
Что по твоему проще и быстрее: написать 1 раз нормальную обвязку или 10 раз с нуля писать халтурную? Имхо, по-любому, выгоднее 1 раз нормальную.
Если тут тоже согласен, тогда... может не будешь каждый раз с нуля писать халтурную, и просто будешь каждый раз улучшать старую, пока она не станет нормальной?
Тогда, в итоге, также получится нормальная обвязка, просто не сразу, а со временем. Кстати, тогда твоя версия немного изменится на...
"Твой подход -- это: попилить нормальные ноды (до готовности), а в процессе "на фане" допиливать халтурную обвязку до нормальной."
А теперь фокус-покус: через несколько итераций улучшения обвязки, у тебя получится тоже самое, что и в моём варианте, просто нормальная обвязка будет написана чуть позже.
В связи с чем, вопрос: а если не видно разницы -- зачем писать позже? Тем более, что не факт, что ты продержишься все 10 иттераций... а так, уже сразу можно будет показать "хоть что-то на экране".
ЧТД. (Что и Требовалось Доказать)
|
К чему это я.
Если собираешься пилить нормальные ноды долго, то, в далекой перспективе, выгоднее сперва 1 раз написать норм обвязку, и больше на неё не отвлекаться, а твой фан и настрой на "самую грязную трудную работу" от этого ничего потеряют (даже не заметишь).
А если вдруг сольёшься ещё до окончания написания норм нодов, то на руках будет хотя бы законченная обвязка, которую можно увидеть "на экране", а вот незаконченные ноды у тебя будут лежать мёртвым грузом... разве что потом продолжишь работать, но тогда ты не слился и см. аргумент для "собираешься пилить нормальные ноды долго"...
Вроде железобетонные аргументы. Должно пронять даже тебя))

graveman пишет:И, кстати, по твоему, легко пропарсить .obj?
Не знаю. Но кажется пример парсинга есть в DX SDK.
Кстати, в конкурсе гоночного AI с геймдева кажется модель гонки была в формате "mesh", т.е. тупо неиндексированный массив вершин.

graveman пишет:Про экспортер я уже сказал: нужен оптимизированный выход (меньше вершин, больше индексов) и формат, удобный для парсинга. Кстати парсер я тоже напишу - его можно будет привязать к любому коду с легкостью подтирания задницы посредством туалетной бумаги.
Не нужны тебе такие заморочки. Эти оптимизации кроме тебя никто не заметит. Помнишь фразу, что мол оптимизировать нужно только там , где это действительно нужно? Так вот там никто оптимизацию не заметит, а когда заметят -- тогда и будешь думать.

graveman пишет:
admin пишет:да, рендеринг залитого одноцветом заднего DX9-буфера уже считается за рендеринг хоть чегото). И пилится с нуля всего за сутки. Да нельзя вертеть камерой и нет поддержки рендеринга ветексбуферов.
Это же очень скудно, чтобы называть это движком.
Кстати, я нигде не писал, что "основа основы движка" -- это движок. Да и название говорит за себя, что это лишь основа.
А чуть выше цитированного текста написано, что это "логически завершённая часть движка". Часть движка, не движок.

graveman пишет:Ну дак я для того и пишу все эти ноды и экспортеры, чтобы можно было потом с ними легко загружать и рендерить 3d-модели, развлекаясь и прикалываясь над недодемками.
WTF?! Зачем это вообще было написано?
Я писал почему в основу основы движка не вошли ноды и рендеринг вершин, а ты в ответ, что поэтому и пишешь "все эти ноды и экспортеры".
graveman
graveman
Сообщения : 22
Дата регистрации : 2019-10-05
Откуда : Татарстан
https://coderdailynotes.wordpress.com

Игра в духе Серьёзного Сэма Empty Re: Игра в духе Серьёзного Сэма

в Вс Окт 27, 2019 9:10 am
Admin пишет:
graveman пишет:Напишика список, что туда должно входить, при случае
Точного списка быть не может
Ок
Admin пишет:
Короче, 1-й этап пиления движка это: первая логически и функционально завершённая структура, получающаяся в процессе создания движка.
Как определить что туда должно входить... в ходе пиления движков, я постепенно стал приходить к мысли, что пиление движка с нуля проходит по примерно одинаковой схеме, причём, процесс можно разбить на стадии, в конце каждой из которых получается вполне себе завершённая конструкция.
...
- А если и инициализацию и рендеринг хоть чего-то (например однородно залитого цветом заднего буфера)? А вот это имхо уже похоже на двиг.

Допустим, у нас классическая связка -- голое WinAPI и DirectX, тогда минимальная граница для статуса "основа основы движка" это наличие:
- код создания окна;
- код функции окна;
- код цикла обработки сообщений;
- код инициализации DX;
- код заливки цветом и рендеринга заднего буфера.

Прочитал про 1-й и 2-й этап. Ну, дружище, я не пишу каждый раз Окно+d3dInit. Я использую связку своих WAFFDATM + D3D9Helper Lib, которые я давно разместил на гитхабе. Ну да, там не хватает собственно заливки буфера. Но зато есть функционал мыши и клавы (это часть " функционал для работы с операционкой и самим GAPI"), который можно легко привязать к камере. Проще говоря я не пишу 1-й этап с нуля. У меня есть 75% 1-го этапа ("основы основ", меня этот термин *нецензурная брань* своей длиной - долго набирать надо на клавиатуре. Я предлагаю его обозвать "предоснова" или вообще ОО движка).
Ассерты и пулы я могу взять из boost - причем не нужно компилировать, а только подключить соответствующие заголовки. Функционала fread мне в принципе хватает.
Можно сказать, что я 1-й этап + 50% функционала между нижними границами 1-го и 2-го этапов сделал.
Admin пишет:
Вот только "весь необходимый функционал для работы с операционкой и самим GAPI" у нас разный, и я не помню как там сделано у тебя ибо ты не показываешь (секретничаешь?)))
scratch
пжалуйста, бро:
Admin пишет:
столь сложные штуки (вроде логов и супер ассертов) -- это как из пушки по воробъям -- мало смысла когда можно юзать средства попроще (вроде обычного if'а с MessageBox'ом).
В ассерте boost можно именно месседж бокс юзать, что я и делаю.
Admin пишет:
Кроме того, ты кажется ещё до "рендеринга набора элементов" сразу начинаешь строгать свой класс меша, шейдеры и логи и только потом уже создание окна и инициализация GAPI
Опять таки ты прав только на 50%
Про окно с инициализацией я уже сказал - оно готово и леэит на гитхабе. Свой класс меша я уже не строгаю. Шейдеры я не писал. Ну простой лог не трудно написать.
Кстати именно лог очень важен при RnD, а лучше стек ошибок. Чтобы их отлавливать и не копаться часами в коде.

Про 2-й этап.
Про 2-й этап:
Основа нодов (то бишь узлов графа сцены есть) - это проект на гитхабе, к которому ты сделал недавно 16 замечаний. Если я к этой основе нода присобачу методы для управления трансформацией (вращение, перемещение, масштабирование, "повернуться к другому ноду" и пр.), то будет полноценный нод графа сцены. Тебе не придется писать мозгоебучий код установки и перемножения матриц, используя длинные и неинтуитивные названия функций. Ты просто напишешь node->Rotate(yaw, pitch, roll) или node->MoveToPoint(x,y,z). И все! Ну не клево разве, а? Мозги отдыхают.
Второе. Зачем рендерить полигоны? Зачем *нецензурная брань* с созданием мешей в коде? В блендере можно комнату и стены сделать в течение пары минут абсолютному нулю в 3D моделировании. И бац загрузил. И у тебя уже меши, а не какие-то там полигоны. Взял хотя бы даже просто вершинный и индексный буферы и создал производный класс от нода графа сцены, в котором просто прописал указатели на вершинный и индексный буферы (это ведь не сложно). Дальше грузишь модель из файла и все - meshNode->Rotate(yaw, pitch, roll) или meshNode->MoveToPoint(x,y,z). Ну не *нецензурная брань* ли?
Я же над этим работаю. Чтобы сосредоточиться потом на геймлее, игровом коде. А не на возне с матрицами и вершинными буферами. Чтобы 2-й этап не был СЛОЖНЫМ. Точнее я уже и делаю 2-й этап.  
Отчет по экпортеру:
Экспортер почти готов. Я убрал там экспорт материалов, потому что опять надо разбираться. Оставил только таблицу соответствия полигонов индексам материалов. Файл с описанием материалов можно будет с помощью другого экспортера писать (ну это в будущем). Главное геометрия экспортится. Осталось чисто косметически код поправить и комментарии и выложу на гитхаб. Потом начну загрузчик для него писать.

Admin пишет:
Да, "нормальную" инициализация, я не делал, потому что:
ну согласен с причинами

Admin пишет:
ААААААА, чувак, у тебя в корне неверное представление о фундаментах: фундамент не должен быть неприменно сложным
Слушай, ты реально думаешь я фанат сложности и мазохист, которому нравится, что его мозги превращаются в кашу? Сложность возникает естесттвенным путем. Дерево - это сложно, экспортер, который убирает дублированные вершины на основе PythonAPI блендера тоже сложно. Все это не я придумал. Эти сложности возникли в ходе постановки задачи и ее решения. Ну все люди разные и тут мы похоже не придем к единому мнению.

Admin пишет:
потом сколько-влезет пили нормальные ноды;
Вот твое в корне неверное предсавление. Пилить нормальные ноды сложно и "больно" и долго. Поэтому, нужно один раз выполнить эту грязную работу и забыть о ней.
2-й раз писать нод или экспортер у меня нет ни малейшего желания.

Admin пишет:
а в процессе (каждый раз, с нуля) пилить халтурные обвязки "на фане".
Халтурные обвязки для меня - это:
- класс мешнода, производный от класса нода графа сцены. Но я хочу этот пункт сделать нормально.
- класс меша;
- класс камеры (возможно производный от класса нода графа сцены);
- функции рендера - это BeginScene\EndScene, DrawIndexedPrimitive и прочая фигня;
- класс игровых объектов (оружия, предметов и т.д.)
- всякие способы хранения и управления нодами и игровыми объектами;
- форматы и загрузчики игровых объектов и карт уровней.

Admin пишет:
Если собираешься пилить нормальные ноды долго
Нормальные ноды, точнее база мной уже написаны. осталось сделать нормальный нод графа сцены.
Нормальный_нод_графа_сцены = нормальный_нод_на_гитхабе(NodeBase)+(функционал вращения, перемещения и масштабирования).
Как ты понимаешь, это не так уж далеко. Наверное неделя возни после работы+выходные.

Admin пишет:
graveman пишет:
И, кстати, по твоему, легко пропарсить .obj?

Не знаю. Но кажется пример парсинга есть в DX SDK.
Так ты открой и посмотри на obj-файл и сюда . У меня лично это вызывает приступ чувств вроде "О, Боже, опять мозгоебство с обходом комментов, вариациями и комбинациями тегов в строках вершин, сколько ненужной фигни, почему бы просто не сохранять ноды с матрицами и мешами в формате, удобном для DirectX. Нет я не готов."

Admin пишет:
Эти оптимизации кроме тебя никто не заметит.
Ну разработчики тормозного Unity наверное тоже так думали. И потом, тебе не обидно за DrawIndexedPrimitive и вообще за технологичный подход? Для меня это стало делом принципа. Я просто ненавижу UE4 за его прожорливость, необоснованный гигантизм и требования. Насиловать компы пользователей. Я инженер, вашу мать, я не коммерсант (это я не тебе, а миру коммерсов). Тут еще типа аналогии как в случае предрасположенности Джона Конора к модели терминаторов 101. Или олдскул задротов к шотгану.


-
Спонсируемый контент

Игра в духе Серьёзного Сэма Empty Re: Игра в духе Серьёзного Сэма

Вернуться к началу
Права доступа к этому форуму:
Вы можете отвечать на сообщения