Моё знакомство с серией Mafia началось с самой первой части — Mafia: The City of Lost Heaven, которая вышла в 2002 году. Главным геймдизайнером был Даниэль Вавра, и у него получилось создать очень атмосферную и интересную историю про мафию 30-х годов.
Первый раз я прошёл игру где-то в 2014 году. Она уже тогда считалась классикой, и я сразу понял почему. Несмотря на то, что игра старая, в ней всё работало: сюжет, герои, атмосфера. А в 2024 году я снова её прошёл, и, честно говоря, был удивлён, как хорошо она сохранилась. Игра всё ещё отлично ощущается, а её мир до сих пор вызывает интерес.
Больше всего мне нравится, что город Лост-Хевен в Mafia не просто для вида. Он живой: по улицам ходят люди, ездят машины, по радио идут передачи — всё помогает почувствовать, что ты действительно в Америке 30-х. История крутится вокруг простого таксиста Томми Анджело, который случайно попадает в мафиозный мир. Сюжет развивается постепенно, но каждый момент держит в напряжении. Персонажи прописаны отлично — у каждого своя история и характер. Даже второстепенные герои, как, например, Винченцо, оружейник мафии, запоминаются. Он всегда даёт напарникам крутое оружие, а мне — какой-нибудь старый кольт. Это немного бесило, но и вызывало улыбку.
Когда разработчики анонсировали ремейк — Mafia: Definitive Edition — я сначала отнёсся к этому с осторожностью. Часто бывает, что ремейки теряют атмосферу оригинала. Но в этом случае всё получилось просто отлично. В 2025 году я прошёл обновлённую версию, и она оставила у меня только положительные впечатления. Вроде бы та же история, но как будто ты смотришь её под новым углом. Графика шикарная, город стал ещё красивее. Озвучка тоже на высоте, актёры хорошо передали эмоции. Стрельба и езда теперь стали удобнее и приятнее. Играть было очень увлекательно!
Недавно я предложил подруге пройти именно ремейк. Думаю, для новичков это лучший способ познакомиться с серией. Оригинал может показаться устаревшим, а вот обновлённая версия — самое то. Было интересно наблюдать, как она вовлекается в сюжет, обсуждает персонажей, переживает за них. В финале она даже расстроилась — концовка её задела. Это говорит о том, насколько сильно игра может затянуть и вызвать настоящие эмоции.
Хотя я сам не имел отношения к созданию Mafia, было очень приятно видеть, как кто-то получает от неё столько же удовольствия, сколько и я. Это и есть настоящий показатель хорошей игры — когда она остаётся в памяти не только как развлечение, а как настоящая история, которую хочется прожить и вспомнить ещё не раз.
Первый раз я прошёл игру где-то в 2014 году. Она уже тогда считалась классикой, и я сразу понял почему. Несмотря на то, что игра старая, в ней всё работало: сюжет, герои, атмосфера. А в 2024 году я снова её прошёл, и, честно говоря, был удивлён, как хорошо она сохранилась. Игра всё ещё отлично ощущается, а её мир до сих пор вызывает интерес.
Больше всего мне нравится, что город Лост-Хевен в Mafia не просто для вида. Он живой: по улицам ходят люди, ездят машины, по радио идут передачи — всё помогает почувствовать, что ты действительно в Америке 30-х. История крутится вокруг простого таксиста Томми Анджело, который случайно попадает в мафиозный мир. Сюжет развивается постепенно, но каждый момент держит в напряжении. Персонажи прописаны отлично — у каждого своя история и характер. Даже второстепенные герои, как, например, Винченцо, оружейник мафии, запоминаются. Он всегда даёт напарникам крутое оружие, а мне — какой-нибудь старый кольт. Это немного бесило, но и вызывало улыбку.
Когда разработчики анонсировали ремейк — Mafia: Definitive Edition — я сначала отнёсся к этому с осторожностью. Часто бывает, что ремейки теряют атмосферу оригинала. Но в этом случае всё получилось просто отлично. В 2025 году я прошёл обновлённую версию, и она оставила у меня только положительные впечатления. Вроде бы та же история, но как будто ты смотришь её под новым углом. Графика шикарная, город стал ещё красивее. Озвучка тоже на высоте, актёры хорошо передали эмоции. Стрельба и езда теперь стали удобнее и приятнее. Играть было очень увлекательно!
Недавно я предложил подруге пройти именно ремейк. Думаю, для новичков это лучший способ познакомиться с серией. Оригинал может показаться устаревшим, а вот обновлённая версия — самое то. Было интересно наблюдать, как она вовлекается в сюжет, обсуждает персонажей, переживает за них. В финале она даже расстроилась — концовка её задела. Это говорит о том, насколько сильно игра может затянуть и вызвать настоящие эмоции.
Хотя я сам не имел отношения к созданию Mafia, было очень приятно видеть, как кто-то получает от неё столько же удовольствия, сколько и я. Это и есть настоящий показатель хорошей игры — когда она остаётся в памяти не только как развлечение, а как настоящая история, которую хочется прожить и вспомнить ещё не раз.
👍2❤1😎1
Посоветовали отличный и бесплатный курс по Си. Говорят, сложный, глубокий, так еще и про современный подход к разработке.
Ссылка: https://stepik.org/course/73618
Будем посмотреть :D
P.S. Если есть что-то на примете, можешь поделиться в комментариях под постом)
Ссылка: https://stepik.org/course/73618
Будем посмотреть :D
P.S. Если есть что-то на примете, можешь поделиться в комментариях под постом)
👍1
Forwarded from Vecxy (Дмитрий Мелков)
⚙️Log #17
Всем привет! Давно не было новостей по движку. Всё потому, что у меня фокус последние месяцы прыгал куда угодно, только не в него. Работы и дел навалено выше крыши, сил не всегда хватает, да и желание часто сдувается. В итоге движок лежал без движения почти пять месяцев.
Почему так? Всё просто: есть основная работа. Мобилки и веб, казуальщина, головоломки и детский кринж. За это платят стабильно и по меркам моего региона — даже очень хорошо. Но по меркам геймдева в целом — это середнячок, а удовольствия от процесса минимум.
А хотелось бы заниматься настоящим геймдевом — делать проекты под ПК, игры мечты, в которые хочется играть самому. Но серьёзный проект требует огромного количества времени и сил, а когда параллельно тащишь основную работу, и ты, и проект страдаете. Чтобы уйти с головой в своё — нужны деньги хотя бы просто на жизнь. Пока такого ресурса нет, поэтому приходится балансировать.
Есть ещё и мой внутренний программист, который грызёт изнутри. За 7 лет я нафигачил кучу опыта: Unity, Cocos Creator, C#, JS/TS. Набежало больше 20.000 часов. Если верить правилу 10.000 часов, я «дважды мастер». Но по факту так себя не ощущаю.
Проблема в том, что я слишком верхнеуровневый. Опыт размазан: работаешь → выгораешь → снова работаешь. Да, могу собрать игру определённого уровня. Но есть потолок. Смотришь на AAA — и вообще не понимаешь, как там такие технологии реализованы. Для этого нужен другой фундамент, а у меня его тупо нет.
Вот поэтому и чешется уйти в низкоуровневое программирование. Зарыться в книги, как червяк в землю. Уехать куда-то в тишину, отрезать весь шум и начать строить нормальный фундамент знаний.
Хочу ещё копать не только в технику, но и в историю. Истории вроде Ады Лавлейс, первых компьютеров и всего этого старого безумия. Это вдохновляет, заряжает и помогает не забывать, ради чего всё начиналось.
Хочу подтянуть теорию. Потому что, когда у тебя только практика, это реально мешает в общении и в работе. Теоретическая база даёт уверенность, системность и другой уровень понимания.
🟢 Теперь к движку. За эти месяцы у меня родились новые идеи, и я начал перестраивать архитектуру.
План такой:
- будет два ядра — одно на C#, другое на JS/TS, чтобы собирать проекты и под веб, и под ПК;
- будет свой скриптовый язык ManuScript, пишу его на Си;
- на C# сделаю собственную библиотеку рендера, а на ней — фреймворк для UI, чтобы можно было собирать как игры, так и десктопные приложения;
- на этом же фреймворке будет написан редактор под Windows.
Короче, разработка движка потихоньку возвращается, но уже с новым взглядом и новой архитектурой.
Всем привет! Давно не было новостей по движку. Всё потому, что у меня фокус последние месяцы прыгал куда угодно, только не в него. Работы и дел навалено выше крыши, сил не всегда хватает, да и желание часто сдувается. В итоге движок лежал без движения почти пять месяцев.
Почему так? Всё просто: есть основная работа. Мобилки и веб, казуальщина, головоломки и детский кринж. За это платят стабильно и по меркам моего региона — даже очень хорошо. Но по меркам геймдева в целом — это середнячок, а удовольствия от процесса минимум.
А хотелось бы заниматься настоящим геймдевом — делать проекты под ПК, игры мечты, в которые хочется играть самому. Но серьёзный проект требует огромного количества времени и сил, а когда параллельно тащишь основную работу, и ты, и проект страдаете. Чтобы уйти с головой в своё — нужны деньги хотя бы просто на жизнь. Пока такого ресурса нет, поэтому приходится балансировать.
Есть ещё и мой внутренний программист, который грызёт изнутри. За 7 лет я нафигачил кучу опыта: Unity, Cocos Creator, C#, JS/TS. Набежало больше 20.000 часов. Если верить правилу 10.000 часов, я «дважды мастер». Но по факту так себя не ощущаю.
Проблема в том, что я слишком верхнеуровневый. Опыт размазан: работаешь → выгораешь → снова работаешь. Да, могу собрать игру определённого уровня. Но есть потолок. Смотришь на AAA — и вообще не понимаешь, как там такие технологии реализованы. Для этого нужен другой фундамент, а у меня его тупо нет.
Вот поэтому и чешется уйти в низкоуровневое программирование. Зарыться в книги, как червяк в землю. Уехать куда-то в тишину, отрезать весь шум и начать строить нормальный фундамент знаний.
Хочу ещё копать не только в технику, но и в историю. Истории вроде Ады Лавлейс, первых компьютеров и всего этого старого безумия. Это вдохновляет, заряжает и помогает не забывать, ради чего всё начиналось.
Хочу подтянуть теорию. Потому что, когда у тебя только практика, это реально мешает в общении и в работе. Теоретическая база даёт уверенность, системность и другой уровень понимания.
🟢 Теперь к движку. За эти месяцы у меня родились новые идеи, и я начал перестраивать архитектуру.
План такой:
- будет два ядра — одно на C#, другое на JS/TS, чтобы собирать проекты и под веб, и под ПК;
- будет свой скриптовый язык ManuScript, пишу его на Си;
- на C# сделаю собственную библиотеку рендера, а на ней — фреймворк для UI, чтобы можно было собирать как игры, так и десктопные приложения;
- на этом же фреймворке будет написан редактор под Windows.
Короче, разработка движка потихоньку возвращается, но уже с новым взглядом и новой архитектурой.
❤7
- Буратино дали три яблока. Два он съел. Сколько яблок осталось у Буратино?
- Одно?
- Нет! Мы же не знаем, сколько яблок у него было до этого.
- Одно?
- Нет! Мы же не знаем, сколько яблок у него было до этого.
🤔3❤1
divы с segfault’ами
Буду верстать интерфейсы на Си, чтобы потролить реактеров
https://github.com/nicbarker/clay
Буду верстать интерфейсы на Си, чтобы потролить реактеров
https://github.com/nicbarker/clay
GitHub
GitHub - nicbarker/clay: High performance UI layout library in C.
High performance UI layout library in C. Contribute to nicbarker/clay development by creating an account on GitHub.
😁2❤1
Зачем писать CSS, если его уже написали за тебя?
CSS в чистом виде конечно можно использовать, но это боль и не очень удобно, особенно с точки зрения IDE и тулинга.
Гораздо адекватнее взять Tailwind или Style-x в комбе с плагином для IDE:
1. Это минимизирует количество CSS, которое летит в билд.
2. Ты получаешь простую и понятную ментальную модель для стилизации компонентов.
Первую неделю будешь страдать, но потом уже никогда не захочешь возвращаться к обычному CSS.
Причина простая: Tailwind и подобные решения сделали чуваки, которые собаку на этом съели и реально понимают, каким должен быть удобный и эффективный инструмент. Плюс в интернете море готовых решений, которые можно просто копипастить без страха заговнякать проект. Из коробки уже есть тёмные/светлые/контрастные темы, а дизайн-токены в Tailwind подобраны так, что всё хорошо стыкуется и интерфейс просто выглядит красивее. Плюс у них есть cookbook, где расписано большинство типовых ситуаций. В общем, кайф.
Поэтому самый правильный ход — ставить Tailwind уже на старте проекта и не изобретать велосипед.
Однако, капец я настрадался копаться в документации Tailwind. Не то что бы она не удобная, чуваки потрудились на славу, были бы все технические докуметации как у них — мир был бы чуточку лучше.
Однако документации много и когда ты ранее не использовал этот CSS-фреймворк, то приходится на каждую хотелку — идти копаться.
Со временем конечно ты большинство необходимого уже изучишь и в доках уже будешь не так часто сидеть, но все равно бывают какие-то моменты, где нужно подглянуть или на глазах держать какую-нибудь табличку в процессе верстки.
Нашел два расширения для VS Code и думаю — почему же я раньше этого не сделал?
1. Tailwind CSS IntelliSense
2. Tailwind Docs
CSS в чистом виде конечно можно использовать, но это боль и не очень удобно, особенно с точки зрения IDE и тулинга.
Гораздо адекватнее взять Tailwind или Style-x в комбе с плагином для IDE:
1. Это минимизирует количество CSS, которое летит в билд.
2. Ты получаешь простую и понятную ментальную модель для стилизации компонентов.
Первую неделю будешь страдать, но потом уже никогда не захочешь возвращаться к обычному CSS.
Причина простая: Tailwind и подобные решения сделали чуваки, которые собаку на этом съели и реально понимают, каким должен быть удобный и эффективный инструмент. Плюс в интернете море готовых решений, которые можно просто копипастить без страха заговнякать проект. Из коробки уже есть тёмные/светлые/контрастные темы, а дизайн-токены в Tailwind подобраны так, что всё хорошо стыкуется и интерфейс просто выглядит красивее. Плюс у них есть cookbook, где расписано большинство типовых ситуаций. В общем, кайф.
Поэтому самый правильный ход — ставить Tailwind уже на старте проекта и не изобретать велосипед.
Однако, капец я настрадался копаться в документации Tailwind. Не то что бы она не удобная, чуваки потрудились на славу, были бы все технические докуметации как у них — мир был бы чуточку лучше.
Однако документации много и когда ты ранее не использовал этот CSS-фреймворк, то приходится на каждую хотелку — идти копаться.
Со временем конечно ты большинство необходимого уже изучишь и в доках уже будешь не так часто сидеть, но все равно бывают какие-то моменты, где нужно подглянуть или на глазах держать какую-нибудь табличку в процессе верстки.
Нашел два расширения для VS Code и думаю — почему же я раньше этого не сделал?
1. Tailwind CSS IntelliSense
2. Tailwind Docs
1👍2
[Bug]: Unhandled Runtime Error: TypeError: undefined is not an object (evaluating 'window.TelegramGameProxy.receiveEvent') #342
Решение поблемы: https://github.com/Telegram-Mini-Apps/telegram-apps/issues/342#issuecomment-3305528384
Решение поблемы: https://github.com/Telegram-Mini-Apps/telegram-apps/issues/342#issuecomment-3305528384
Forwarded from NoName (Дмитрий Мелков)
Приветствуем, товарищи! Это снова мы. Пора рассказать нашу историю
Два года назад мы начали этот путь под именем Itibsoft. Мы были неопытны, горели идеями и… делали многое неправильно. Мы гнались за количеством, превратили разработку в конвейер...
Потом мы решили всё изменить и загорелись амбициозным проектом — «Берестяные свитки». Мы набрали команду, придумали кучу крутых идей, погрузились в историю Руси. Казалось, вот он, наш шанс сделать что-то по-настоящему стоящее.
Однако мы допустили ещё одну роковую ошибку: мы пытались совмещать заказную разработку и полномасштабную работу над проектом. В какой-то момент неопределённость взяла верх: множество вопросов по механикам, размытое видение и постоянное распыление сил между заказами и мечтой привели к кризису.
Мы попытались спасти положение: закрыли заказное направление, чтобы сфокусироваться только на «Берестяных свитках». Но было уже поздно. Бюджет иссяк, пришлось закрыться, распустить команду и… залезть в долги. Это был тяжёлый удар. Казалось, это конец.
Но мы не сдались.
Мы молча, шаг за шагом, восстанавливались. Работали, чтобы расплатиться с долгами. Подсознательно переосмысливали каждую механику, каждую идею «Берестяных свиток». Снова спорили и снова зажигались этой идеей.
И теперь мы возвращаемся. Те же самые люди, та же страсть к созданию игр, но — совершенно другой подход, железная воля и трезвый расчёт.
Давайте разберемся с названием нашей независимой инди студии. «Itibsoft» осталось в том прошлом. Мы не хотим торопиться. Новое имя должно быть тем самым. Оно должно родиться из нашего нового опыта и отражать наш дух.
Пока мы его ищем, мы — Студия NoName. В этом есть своя честность и вызов.
А наша цель теперь ясна как никогда: мы возрождаем «Берестяные свитки». Мы не просто «доделываем» старую версию. Мы начинаем с нового листа, опираясь на весь наш горький опыт и переработанное до мелочей видение.
Наша цель — не быстрый релиз. Наша цель — сосредоточенная и длительная работа, чтобы в итоге показать вам игру, в которую мы вложили душу, а не просто «еще один проект».
Мы будем делиться с вами прогрессом, идеями и трудностями. Мы за честность и открытость. Этот канал будет нашим общим пространством.
Спасибо, что остаетесь с нами. Добро пожаловать в нашу вторую попытку. Настоящую.
Вместе мы придумаем себе имя. А пока — за работу! 🚀
#NoName #БерестяныеСвитки #Возвращение #РазработкаИгр #Геймдев #ИндиСтудия
Два года назад мы начали этот путь под именем Itibsoft. Мы были неопытны, горели идеями и… делали многое неправильно. Мы гнались за количеством, превратили разработку в конвейер...
Потом мы решили всё изменить и загорелись амбициозным проектом — «Берестяные свитки». Мы набрали команду, придумали кучу крутых идей, погрузились в историю Руси. Казалось, вот он, наш шанс сделать что-то по-настоящему стоящее.
Однако мы допустили ещё одну роковую ошибку: мы пытались совмещать заказную разработку и полномасштабную работу над проектом. В какой-то момент неопределённость взяла верх: множество вопросов по механикам, размытое видение и постоянное распыление сил между заказами и мечтой привели к кризису.
Мы попытались спасти положение: закрыли заказное направление, чтобы сфокусироваться только на «Берестяных свитках». Но было уже поздно. Бюджет иссяк, пришлось закрыться, распустить команду и… залезть в долги. Это был тяжёлый удар. Казалось, это конец.
Но мы не сдались.
Мы молча, шаг за шагом, восстанавливались. Работали, чтобы расплатиться с долгами. Подсознательно переосмысливали каждую механику, каждую идею «Берестяных свиток». Снова спорили и снова зажигались этой идеей.
И теперь мы возвращаемся. Те же самые люди, та же страсть к созданию игр, но — совершенно другой подход, железная воля и трезвый расчёт.
Давайте разберемся с названием нашей независимой инди студии. «Itibsoft» осталось в том прошлом. Мы не хотим торопиться. Новое имя должно быть тем самым. Оно должно родиться из нашего нового опыта и отражать наш дух.
Пока мы его ищем, мы — Студия NoName. В этом есть своя честность и вызов.
А наша цель теперь ясна как никогда: мы возрождаем «Берестяные свитки». Мы не просто «доделываем» старую версию. Мы начинаем с нового листа, опираясь на весь наш горький опыт и переработанное до мелочей видение.
Наша цель — не быстрый релиз. Наша цель — сосредоточенная и длительная работа, чтобы в итоге показать вам игру, в которую мы вложили душу, а не просто «еще один проект».
Мы будем делиться с вами прогрессом, идеями и трудностями. Мы за честность и открытость. Этот канал будет нашим общим пространством.
Спасибо, что остаетесь с нами. Добро пожаловать в нашу вторую попытку. Настоящую.
Вместе мы придумаем себе имя. А пока — за работу! 🚀
#NoName #БерестяныеСвитки #Возвращение #РазработкаИгр #Геймдев #ИндиСтудия
Telegram
Берестяные свитки
Официальный канал исторического проекта "Берестяные свитки" от инди-студии @Itibsoft
❤6😎2
Forwarded from Vecxy (Дмитрий Мелков)
⚙️Log #18
Прошлый пост был больше эмоциональным, а в этом — конкретика по новому архитектурному плану. Покопался в идеях, переосмыслил подходы и пришёл к более трезвым и реализуемым решениям.
🟢 Нативное ядро: C# и .NET 8.0 LTS. Это основная сила движка для десктопа. .NET 8 предоставляет отличную производительность и современные возможности. Логика будет разбита на модули в виде отдельных DLL-библиотек. Сам движок соберётся в одну динамическую библиотеку.
🟢 В нативной части рендеринг будет на OpenGL. Это проверенная технология с хорошим балансом сложности и возможностей. В далёкой перспективе — переход на Vulkan для более тонкого контроля и производительности. Для веб-версии, естественно, будет задействован WebGL|GPU.
🟢 Фокус сейчас на Windows. Как только нативное ядро станет стабильным, займусь вебом через WebAssembly (WASM) и того же WebGL.
🟢 От идеи с собственным скриптовым языком ManuScript я отказался. Не вижу смысла тратить силы на создание и поддержку того, что уже прекрасно реализовано другими. Это дикая дистилляция велосипеда.
- Основной язык логики — C#.
- Для гибкости будем подключать скриптовые языки, вроде Lua или JavaScript. Идеально для контента, модов или быстрого прототипирования.
- DSL остаются для конкретных задач, например, для описания UI, сделаю что-то похожее на XML для структуры и подобие CSS для стилей.
- Будет еще визуальный язык, что-то похожее на блюпринты в UE. (это не в приоритете и скорее всего будет являться инструментом для систем, где важна четкая визуальная связь)
Итого план стал более зрелым и сфокусированным. Вместо распыления на два ядра и свой язык — концентрация на сильном нативном ядре на C# с продуманной модульной архитектурой.
Прошлый пост был больше эмоциональным, а в этом — конкретика по новому архитектурному плану. Покопался в идеях, переосмыслил подходы и пришёл к более трезвым и реализуемым решениям.
🟢 Нативное ядро: C# и .NET 8.0 LTS. Это основная сила движка для десктопа. .NET 8 предоставляет отличную производительность и современные возможности. Логика будет разбита на модули в виде отдельных DLL-библиотек. Сам движок соберётся в одну динамическую библиотеку.
🟢 В нативной части рендеринг будет на OpenGL. Это проверенная технология с хорошим балансом сложности и возможностей. В далёкой перспективе — переход на Vulkan для более тонкого контроля и производительности. Для веб-версии, естественно, будет задействован WebGL|GPU.
🟢 Фокус сейчас на Windows. Как только нативное ядро станет стабильным, займусь вебом через WebAssembly (WASM) и того же WebGL.
🟢 От идеи с собственным скриптовым языком ManuScript я отказался. Не вижу смысла тратить силы на создание и поддержку того, что уже прекрасно реализовано другими. Это дикая дистилляция велосипеда.
- Основной язык логики — C#.
- Для гибкости будем подключать скриптовые языки, вроде Lua или JavaScript. Идеально для контента, модов или быстрого прототипирования.
- DSL остаются для конкретных задач, например, для описания UI, сделаю что-то похожее на XML для структуры и подобие CSS для стилей.
- Будет еще визуальный язык, что-то похожее на блюпринты в UE. (это не в приоритете и скорее всего будет являться инструментом для систем, где важна четкая визуальная связь)
Итого план стал более зрелым и сфокусированным. Вместо распыления на два ядра и свой язык — концентрация на сильном нативном ядре на C# с продуманной модульной архитектурой.
👍3
Forwarded from Vecxy (Дмитрий Мелков)
⚙️Log #19
В данный момент занимаюсь модулем рендеринга. Пробую описать какой-то пайплайн...
🟢 Пока что пришел к такой системе: Render Pipeline -> Render Phase -> Render Phase Layer -> IRenderable
Для теста завел объект спрайта и попытался его отрендерить в этойм пайплайне.
🟢 Моя первичная задача:
Реализовать модуль рендеринга до какого-то рабочего состояния.
- Чтобы можно было например отрендерить N спрайтов с уникальными трансформами
- Чтобы все это было за N батчей (система батчинга)
- Чтобы N спрайтов использовали N текстур
- Чтобы были динамические спрайты, которые могут менять свои параметры в процессе. (для анимаций)
🟡 После этого рендеринг можно будет оставить на какое-то время и заняться системой UI. Начну писать каркас на основе XML + CSS.
В данный момент занимаюсь модулем рендеринга. Пробую описать какой-то пайплайн...
🟢 Пока что пришел к такой системе: Render Pipeline -> Render Phase -> Render Phase Layer -> IRenderable
Для теста завел объект спрайта и попытался его отрендерить в этойм пайплайне.
🟢 Моя первичная задача:
Реализовать модуль рендеринга до какого-то рабочего состояния.
- Чтобы можно было например отрендерить N спрайтов с уникальными трансформами
- Чтобы все это было за N батчей (система батчинга)
- Чтобы N спрайтов использовали N текстур
- Чтобы были динамические спрайты, которые могут менять свои параметры в процессе. (для анимаций)
🟡 После этого рендеринг можно будет оставить на какое-то время и заняться системой UI. Начну писать каркас на основе XML + CSS.
Forwarded from Vecxy (Дмитрий Мелков)
⚙️Log #20
Я давно знал о существовании RenderDoc - наблюдал за его использованием на стримах других разработчиков, но тогда он казался мне чем-то сложным и непонятным. До недавнего времени я откладывал глубокое погружение, но сейчас решился - и был приятно удивлен!
🟢 RenderDoc оказался настоящим мастхэвом в геймдеве и графической разработке. Однако мой путь к его освоению начался с неожиданных трудностей.
Я разрабатываю движок и систему рендеринга на .NET 8. При обычном запуске или дебаге все работало идеально, но при попытке захватить процесс через RenderDoc приложение молча падало на старте. Ни ошибок, ни логов - просто краш.
Перелопатил пол-интернета в поисках решения. Находил похожие проблемы, но их фиксы не подходили под мой случай. Начал даже думать, что .NET принципиально несовместим с RenderDoc.
Тут началось детективное расследование.
В отчаянии я решил проверить другие .NET движки - Stride и Prowl. К моему удивлению, их рантайм прекрасно работал с RenderDoc! Это окончательно сбило меня с толку - почему у них работает, а у меня нет?
Погрузившись в документацию OpenTK (обертка над OpenGL), я нашел ключ - нужно было включить дебаг-режим для OpenGL. И вот тут проявилась настоящая причина проблемы!
🟢 Оказалось, в коде освобождения памяти шейдеров после линковки я передавал неверный ID хендлера - вместо ID шейдерной программы указывал ID фрагментного шейдера. Из-за этого система пыталась отцепить шейдер от несуществующей программы.
Самое интересное: в обычном режиме эта ошибка молча игнорировалась, но RenderDoc сразу ее детектил и жестко падал - без каких-либо подсказок о причине.
🟡 Теперь планирую глубже изучить RenderDoc - буду читать документацию и экспериментировать с различными фичами инструмента.
Я давно знал о существовании RenderDoc - наблюдал за его использованием на стримах других разработчиков, но тогда он казался мне чем-то сложным и непонятным. До недавнего времени я откладывал глубокое погружение, но сейчас решился - и был приятно удивлен!
🟢 RenderDoc оказался настоящим мастхэвом в геймдеве и графической разработке. Однако мой путь к его освоению начался с неожиданных трудностей.
Я разрабатываю движок и систему рендеринга на .NET 8. При обычном запуске или дебаге все работало идеально, но при попытке захватить процесс через RenderDoc приложение молча падало на старте. Ни ошибок, ни логов - просто краш.
Перелопатил пол-интернета в поисках решения. Находил похожие проблемы, но их фиксы не подходили под мой случай. Начал даже думать, что .NET принципиально несовместим с RenderDoc.
Тут началось детективное расследование.
В отчаянии я решил проверить другие .NET движки - Stride и Prowl. К моему удивлению, их рантайм прекрасно работал с RenderDoc! Это окончательно сбило меня с толку - почему у них работает, а у меня нет?
Погрузившись в документацию OpenTK (обертка над OpenGL), я нашел ключ - нужно было включить дебаг-режим для OpenGL. И вот тут проявилась настоящая причина проблемы!
🟢 Оказалось, в коде освобождения памяти шейдеров после линковки я передавал неверный ID хендлера - вместо ID шейдерной программы указывал ID фрагментного шейдера. Из-за этого система пыталась отцепить шейдер от несуществующей программы.
Самое интересное: в обычном режиме эта ошибка молча игнорировалась, но RenderDoc сразу ее детектил и жестко падал - без каких-либо подсказок о причине.
🟡 Теперь планирую глубже изучить RenderDoc - буду читать документацию и экспериментировать с различными фичами инструмента.
⚡2
Forwarded from Vecxy (Дмитрий Мелков)
⚙️Log #21
Изучаю потихоньку OpenGL, вникаю в системы рендеринга.
Вот основной список документаций, которые штудирую:
1. OpenTK Learn
2. OpenGL Core
3. OpenGL GLSLang Spec
🟢 Ещё глубже разобрался, как работают атрибуты и юниформы. Всё оказалось гораздо проще, чем я себе представлял. Если условно, то атрибут используется для каждой вершины в вершинном шейдере, а юниформа — глобально для всех шейдеров. Очень удобно их применять на разных этапах рендеринга. Например, атрибут может спокойно принимать целый буфер разных данных в одном массиве. Потом мы просто для атрибута конкретной вершины определяем смещение в байтах и настраиваем офсет. Таким образом, массив становится своеобразной инструкцией для всех вершин. Атрибут можно использовать, например, для настройки градиента для спрайта, указания позиций вершин, нормалей для освещения или тех же UV-координат для наложения текстур.
Если брать юниформу, то она очень полезна для глобальных значений. Например, можно задать цвет материала, настроить металличность, указать индекс текстуры, загруженной в GPU, или, скажем, передать матрицу преобразования.
🟢 Помимо этого, ещё почитал документацию о VBO — это вершинный буфер, который, собственно, принимает в себя данные для загрузки на GPU. Потом углубился в VAO — это некоторая настройка для атрибутов, через которую можно задавать правила чтения этого буфера. Важный момент: я понял, что привязка VAO происходит к текущему привязанному VBO. Это важно учитывать. Если VBO не был привязан или привязался другой, то VAO будет привязан к последнему или выбросит ошибку, потому что нет буфера, с которым он работает.
🟢 Потом познакомился с оптимизацией для работы с вершинами. Условно, мы можем для отрисовки спрайта использовать 6 вершин, что не очень эффективно, потому что в двух местах будет дубликат вершин из-за наложения двух треугольников. Либо же мы можем использовать только 4 вершины, что будет правильнее, и переиспользовать для создания треугольника уже известную вершину. Для этого нам поможет EBO — это буфер элементов, в который мы передаём индексы вершин, загруженные в VBO и определённые при помощи VAO. Здесь, кстати, тоже есть важный момент: EBO нужно привязывать к привязанной VAO, потому что он работает с ней, так как ему нужно понимать индексы вершин.
🟢 Ну и по мелочи: ещё поигрался с настройками OpenGL, например, с включением смешивания.
🟡 Дальше планирую по-прежнему работать над рендерингом. Нужно разобраться более подробно с фундаментом.
Изучаю потихоньку OpenGL, вникаю в системы рендеринга.
Вот основной список документаций, которые штудирую:
1. OpenTK Learn
2. OpenGL Core
3. OpenGL GLSLang Spec
🟢 Ещё глубже разобрался, как работают атрибуты и юниформы. Всё оказалось гораздо проще, чем я себе представлял. Если условно, то атрибут используется для каждой вершины в вершинном шейдере, а юниформа — глобально для всех шейдеров. Очень удобно их применять на разных этапах рендеринга. Например, атрибут может спокойно принимать целый буфер разных данных в одном массиве. Потом мы просто для атрибута конкретной вершины определяем смещение в байтах и настраиваем офсет. Таким образом, массив становится своеобразной инструкцией для всех вершин. Атрибут можно использовать, например, для настройки градиента для спрайта, указания позиций вершин, нормалей для освещения или тех же UV-координат для наложения текстур.
Если брать юниформу, то она очень полезна для глобальных значений. Например, можно задать цвет материала, настроить металличность, указать индекс текстуры, загруженной в GPU, или, скажем, передать матрицу преобразования.
🟢 Помимо этого, ещё почитал документацию о VBO — это вершинный буфер, который, собственно, принимает в себя данные для загрузки на GPU. Потом углубился в VAO — это некоторая настройка для атрибутов, через которую можно задавать правила чтения этого буфера. Важный момент: я понял, что привязка VAO происходит к текущему привязанному VBO. Это важно учитывать. Если VBO не был привязан или привязался другой, то VAO будет привязан к последнему или выбросит ошибку, потому что нет буфера, с которым он работает.
🟢 Потом познакомился с оптимизацией для работы с вершинами. Условно, мы можем для отрисовки спрайта использовать 6 вершин, что не очень эффективно, потому что в двух местах будет дубликат вершин из-за наложения двух треугольников. Либо же мы можем использовать только 4 вершины, что будет правильнее, и переиспользовать для создания треугольника уже известную вершину. Для этого нам поможет EBO — это буфер элементов, в который мы передаём индексы вершин, загруженные в VBO и определённые при помощи VAO. Здесь, кстати, тоже есть важный момент: EBO нужно привязывать к привязанной VAO, потому что он работает с ней, так как ему нужно понимать индексы вершин.
🟢 Ну и по мелочи: ещё поигрался с настройками OpenGL, например, с включением смешивания.
🟡 Дальше планирую по-прежнему работать над рендерингом. Нужно разобраться более подробно с фундаментом.
👍2