1,7 Мб, 1200x675Тут есть треды посвященные движкам, есть тред посвященный срачу о движках. Но нет треда для тех кто хочет для своей уютной игры написать свой движок и пообсуждать эту тему. Так что решил создать. Это не тема обсуждения и срачей о других движках. Это тема о реализации своего движка, о том как оно работает изнутри и т.д.
В качестве шапки https://github.com/deltafran/enginethread/blob/master/README.md
(на данный момент я только начал пополнять страницу - ресурсов очень много. Также приветствуются советы, по верстке, оформлению, наполнению.
Зачем нужна эта тема в 2020 году?
Ну кому-то движкоделие может быть само по себе интересным (не решайте за других что им делать и чем им увлекаться).
У кого-то могут быть свои особые требования (например уютный софтрендер, как например делает sb3d; 4D измерение; микровоксели или возможно редкие платформы под которые нет движков)
А возможно кому-то на работе дали приказ сделать движок.
Но еще раз - это не тема о движкосраче, это тема о разработке СВОЕГО движка и всех нужных для этого ресурсов.
В качестве шапки https://github.com/deltafran/enginethread/blob/master/README.md
(на данный момент я только начал пополнять страницу - ресурсов очень много. Также приветствуются советы, по верстке, оформлению, наполнению.
Зачем нужна эта тема в 2020 году?
Ну кому-то движкоделие может быть само по себе интересным (не решайте за других что им делать и чем им увлекаться).
У кого-то могут быть свои особые требования (например уютный софтрендер, как например делает sb3d; 4D измерение; микровоксели или возможно редкие платформы под которые нет движков)
А возможно кому-то на работе дали приказ сделать движок.
Но еще раз - это не тема о движкосраче, это тема о разработке СВОЕГО движка и всех нужных для этого ресурсов.
Пишу в годный трэд. У меня такой вопрос. Я абсолютный нуб, никогда не занимался программированием. Что мне лучше почитать и какой язык взять, чтобы накодить простенькую 2Д игрушку с физикой?
>>692134
Ну легче всего в 2д вкатываться через фреймворки - SDL/SFML/Raylib. Raylib - новенькое и перспективное, но пока плохо документированное.
Из книг
Если SDL:
https://www.amazon.com/SDL-Game-Development-Shaun-Mitchell-ebook/dp/B00DL0CFI6
Если SFML:
https://www.amazon.com/SFML-Development-Example-Raimondas-Pupius/dp/1785287346
по SDL еще есть годные уроки тут (это вообще топ)
https://lazyfoo.net/tutorials/SDL/index.php
по SFML были хорошие туториалы в ютубе. например:
https://www.youtube.com/c/SurajSharmaFourKnob/videos
(да и у них своя офф документация хороша)
Вот у этого чела есть много теории и интересных идей по 2д
https://www.youtube.com/c/javidx9/videos
Если уж совсем хочется вникать с нуля - то тогда придется идти в тред OpenGL и осваивать его:)
>>692134
Юзать box2d - он легко встраивается. Там с ним можно разобраться за пару часов и получить полноценную 2д физику.
Ну легче всего в 2д вкатываться через фреймворки - SDL/SFML/Raylib. Raylib - новенькое и перспективное, но пока плохо документированное.
Из книг
Если SDL:
https://www.amazon.com/SDL-Game-Development-Shaun-Mitchell-ebook/dp/B00DL0CFI6
Если SFML:
https://www.amazon.com/SFML-Development-Example-Raimondas-Pupius/dp/1785287346
по SDL еще есть годные уроки тут (это вообще топ)
https://lazyfoo.net/tutorials/SDL/index.php
по SFML были хорошие туториалы в ютубе. например:
https://www.youtube.com/c/SurajSharmaFourKnob/videos
(да и у них своя офф документация хороша)
Вот у этого чела есть много теории и интересных идей по 2д
https://www.youtube.com/c/javidx9/videos
Если уж совсем хочется вникать с нуля - то тогда придется идти в тред OpenGL и осваивать его:)
>>692134
>с физикой?
Юзать box2d - он легко встраивается. Там с ним можно разобраться за пару часов и получить полноценную 2д физику.
>>692135
Спасибо, анон! Буду пробовать
Спасибо, анон! Буду пробовать
>>692117 (OP)
Пишу в единственный годный тред в /gd/. Какие у анона завалялись материалы по ECS? Может, какие-то советы, плюсы/минусы/подводные камни?
Пишу в единственный годный тред в /gd/. Какие у анона завалялись материалы по ECS? Может, какие-то советы, плюсы/минусы/подводные камни?
Отписался в эпичном треде. А читать буду потом. ебаный фуллтайм
>>692117 (OP)
За пайплайны рендера кто пояснит? Читать книги не хочу. Хочу готовый говнокод.
За пайплайны рендера кто пояснит? Читать книги не хочу. Хочу готовый говнокод.
>>692228
Что тебе пояснять? Пайплан это очень условное название некого абстрактного куска, который отвечает за рендер и его порядок. То есть готовый говнокод ты не скопируешь, потому что такое на оче высоком уровне реализуется.
Вообще очень странный вопрос, лучше бы даже не начинал тратить время на движок, если всё готовое хочешь. Юнити бери.
Что тебе пояснять? Пайплан это очень условное название некого абстрактного куска, который отвечает за рендер и его порядок. То есть готовый говнокод ты не скопируешь, потому что такое на оче высоком уровне реализуется.
Вообще очень странный вопрос, лучше бы даже не начинал тратить время на движок, если всё готовое хочешь. Юнити бери.
>>692234
Всё. Какие варианты рендера применять для Webgl 1/2, OpenGL ES 2/3, Open GL 3. Нихуя нипонятна.
На низком же. И в пайплайне составляются функции для высокого уровня.
Так пайплайн рендера, вместе с сценарным графом, по сути и есть весь движок. Всё остальное вторично.
> Что тебе пояснять?
Всё. Какие варианты рендера применять для Webgl 1/2, OpenGL ES 2/3, Open GL 3. Нихуя нипонятна.
> То есть готовый говнокод ты не скопируешь, потому что такое на оче высоком уровне реализуется.
На низком же. И в пайплайне составляются функции для высокого уровня.
> Вообще очень странный вопрос
Так пайплайн рендера, вместе с сценарным графом, по сути и есть весь движок. Всё остальное вторично.
>>692238
Что значит "варианты рендера"? Книги читай, презентации смотри. Тебе нужно базовые концепты изучать, судя по всему. Всё не так просто.
Что значит "варианты рендера"? Книги читай, презентации смотри. Тебе нужно базовые концепты изучать, судя по всему. Всё не так просто.
>>692234
На Юнити тоже можно свой условный пайплайн заебошить с помощью urp вроде.
На Юнити тоже можно свой условный пайплайн заебошить с помощью urp вроде.
>>692244
MRT, простой forward, воксельный свет, запеченные воксели и вот это всё.
А шобы сразу говнокод был, протестированный и рабочий нету что ли? Это уже научные статьи. Разбирать их пиздец неудобно и долго.
Не базовые, а какой-никакой сборник пайплайнов или либы пайплайнов и сценарных графов. Чтобы просто взял и подключил всё. Ну либо просто переписал логику.
Да я в курсе, поэтому и спрашиваю. Ебала какая-то пиздец конечно.
> Что значит "варианты рендера"?
MRT, простой forward, воксельный свет, запеченные воксели и вот это всё.
> Книги читай, презентации смотри.
А шобы сразу говнокод был, протестированный и рабочий нету что ли? Это уже научные статьи. Разбирать их пиздец неудобно и долго.
> Тебе нужно базовые концепты изучать, судя по всему.
Не базовые, а какой-никакой сборник пайплайнов или либы пайплайнов и сценарных графов. Чтобы просто взял и подключил всё. Ну либо просто переписал логику.
> Всё не так просто.
Да я в курсе, поэтому и спрашиваю. Ебала какая-то пиздец конечно.
>>692253
Я уже говорил, готовое ты что-то вряд-ли найдешь. Это очень высокоуровневая абстракция (плюс каждый может что-то свое под пайпланом понимать), то есть она тянет за собой кучу другого кода. Тогда уже и до движка недалеко.
Вообще, когда ты напишешь все шейдеры и эффекты, то не должно быть сложно из этого всего собрать пайплайн.
Я уже говорил, готовое ты что-то вряд-ли найдешь. Это очень высокоуровневая абстракция (плюс каждый может что-то свое под пайпланом понимать), то есть она тянет за собой кучу другого кода. Тогда уже и до движка недалеко.
Вообще, когда ты напишешь все шейдеры и эффекты, то не должно быть сложно из этого всего собрать пайплайн.
>>692134
ИМХО лучше всего учиться программировать на Python. Потому что это простой и понятный язык, в который реально можно вкатиться новичку, и в то же время мощный, удобный, современный, хорошо описанный с кучей обучающих видео/статей/курсов, в том числе и посвященных именно программированию игр, плюс куча всевозможных УЖЕ написанных библиотек. Кроме того многие движки поддерживают Python или имеют очень похожий синтаксис. Начинать учиться прогать на крестах или шарпе - слишком сложно будет, все равно что начинать учить иностранный язык не с инглиша, а с латыни. Есть еще Java, но там много подводных камней, новичку не рекомендую.
ИМХО лучше всего учиться программировать на Python. Потому что это простой и понятный язык, в который реально можно вкатиться новичку, и в то же время мощный, удобный, современный, хорошо описанный с кучей обучающих видео/статей/курсов, в том числе и посвященных именно программированию игр, плюс куча всевозможных УЖЕ написанных библиотек. Кроме того многие движки поддерживают Python или имеют очень похожий синтаксис. Начинать учиться прогать на крестах или шарпе - слишком сложно будет, все равно что начинать учить иностранный язык не с инглиша, а с латыни. Есть еще Java, но там много подводных камней, новичку не рекомендую.
>>692259
Ну по сути это и есть движок тащемта. Мне так кажется.
Просто копирую и ворую, и в материалы/объекты вставляю всё. На похуе сделал инстансы для парочки vfx, получилось годно, через симуляцию магнитных полей уравнение движения сделол.
А как сделать пайплайн просто не понимаю ни ху я. Все эти форварды-деференды. Чего блядь, как это должно работать с bgfx, например? Коакоак? Короче пиздец сложно. Даже если разбирать примеры рендера на js.
Мне кажется это первое чему должны обучать все эти книги.
Как делать пайплайн годный, как туда добавлять все меши, граф сцены и делать всяческие уравнения движения камерой. На это всё готовое любой нуфаг напердолит любую свою игру. Лишь бы это было. А этого почему-то нет. Странно это всё.
> Тогда уже и до движка недалеко.
Ну по сути это и есть движок тащемта. Мне так кажется.
> Вообще, когда ты напишешь все шейдеры и эффекты,
Просто копирую и ворую, и в материалы/объекты вставляю всё. На похуе сделал инстансы для парочки vfx, получилось годно, через симуляцию магнитных полей уравнение движения сделол.
> то не должно быть сложно из этого всего собрать пайплайн.
А как сделать пайплайн просто не понимаю ни ху я. Все эти форварды-деференды. Чего блядь, как это должно работать с bgfx, например? Коакоак? Короче пиздец сложно. Даже если разбирать примеры рендера на js.
Мне кажется это первое чему должны обучать все эти книги.
Как делать пайплайн годный, как туда добавлять все меши, граф сцены и делать всяческие уравнения движения камерой. На это всё готовое любой нуфаг напердолит любую свою игру. Лишь бы это было. А этого почему-то нет. Странно это всё.
>>692273
Питон в геймдеве не используется, это один из самых медленных языков, так что учить его в перспективе делать игры - пустая трата времени, потом все равно переучиваться на нормальные языки типа c+/c#.
(Автор этого поста был предупрежден.)
Питон в геймдеве не используется, это один из самых медленных языков, так что учить его в перспективе делать игры - пустая трата времени, потом все равно переучиваться на нормальные языки типа c+/c#.
(Автор этого поста был предупрежден.)
>>692146
Спрашивай конкретные ответы. Что-нибудь посоветуем.
Прост пару статей из гугла по ецс прочитай, этого будет вполне достаточно.
Спрашивай конкретные ответы. Что-нибудь посоветуем.
Прост пару статей из гугла по ецс прочитай, этого будет вполне достаточно.
Вот немного аналитики на основе 100500 проектов с гитхаба:
2D multiplayer game from scratch = ~25k LOC;
Game + Engine (Openspades, Vox, Tesseract, Quake3):
Drawer ~25k – Clustered Deferred, VBO/VAO, Texture, FX Render, GUI Render, Post FX Render, Terrain Render, Sky Render, Shadow Render, Water Render;
Client ~25k – Game Modes, Input, GUI Manager, Font Manager, Map Manager, Network, Player, Weapon, AI;
Engine ~25k – Image Loader, Model Loader, GUI Loader, Scripts Loader, ECS, Streaming, Low Network, Zip, Hash, Threads, Low Audio, SIMD/Math, Memory Pool, Memory Manager, Low Physics, Low Scripts, Secure, Win/Unix Wrappers, Generators, Parsers;
Scripts ~20k – UI Framework, Core API, Gameplay API, Bindings API;
GUI ~15k – Core, Views, Screens, L8n, Atlas Packer;
Shaders ~10k – Materals, Terrain, Vegetation, Water, Sky/Atmosphere, GI/Reprojection, Clustered Deferred, SSAO/HBAO, FXAA, Blur, Fog, SSSSS, SSR, SSGI, Bloom/Glow, Lens Flare, Volumetrics, PBR/IBL, Skin/Hairs, Exposure, DoF, Color Grading LUT, Contrast, Saturation, Shadows, Voxels, GUI, Particles/Fire/Sparcs, Chromatic Aberration, Vignette, Dithering;
Tools ~35k – Level Editor, Script Editor, Rosource Editor, Quest Editor, Particle Editor, Material Editor, Debugger/Clocks, UI Builder;
TOTAL = 150 000 LOC;
Vulkan/DX12 LOC = 3-5x OGL4/DX11 LOC;
Tesseract = ~150k LOC;
0a.d. = ~175k LOC;
DOOM 3 = ~300k LOC;
STALKER CoP = ~500k LOC;
Godot Engine = ~600k LOC;
CryEngine V = ~1kk LOC;
UnrealEngine 4 = ~2.5kk LOC;
>>692146
Можешь смотреть всё, что найдешь: entt, entityx и прочее. Но проблема их всех в том, что они делаются под сферический в вакууме арканоид-змейку. А не ММО. И имеют кучу проблем и минусов.
https://habr.com/ru/company/pixonic/blog/413729/
2D multiplayer game from scratch = ~25k LOC;
Game + Engine (Openspades, Vox, Tesseract, Quake3):
Drawer ~25k – Clustered Deferred, VBO/VAO, Texture, FX Render, GUI Render, Post FX Render, Terrain Render, Sky Render, Shadow Render, Water Render;
Client ~25k – Game Modes, Input, GUI Manager, Font Manager, Map Manager, Network, Player, Weapon, AI;
Engine ~25k – Image Loader, Model Loader, GUI Loader, Scripts Loader, ECS, Streaming, Low Network, Zip, Hash, Threads, Low Audio, SIMD/Math, Memory Pool, Memory Manager, Low Physics, Low Scripts, Secure, Win/Unix Wrappers, Generators, Parsers;
Scripts ~20k – UI Framework, Core API, Gameplay API, Bindings API;
GUI ~15k – Core, Views, Screens, L8n, Atlas Packer;
Shaders ~10k – Materals, Terrain, Vegetation, Water, Sky/Atmosphere, GI/Reprojection, Clustered Deferred, SSAO/HBAO, FXAA, Blur, Fog, SSSSS, SSR, SSGI, Bloom/Glow, Lens Flare, Volumetrics, PBR/IBL, Skin/Hairs, Exposure, DoF, Color Grading LUT, Contrast, Saturation, Shadows, Voxels, GUI, Particles/Fire/Sparcs, Chromatic Aberration, Vignette, Dithering;
Tools ~35k – Level Editor, Script Editor, Rosource Editor, Quest Editor, Particle Editor, Material Editor, Debugger/Clocks, UI Builder;
TOTAL = 150 000 LOC;
Vulkan/DX12 LOC = 3-5x OGL4/DX11 LOC;
Tesseract = ~150k LOC;
0a.d. = ~175k LOC;
DOOM 3 = ~300k LOC;
STALKER CoP = ~500k LOC;
Godot Engine = ~600k LOC;
CryEngine V = ~1kk LOC;
UnrealEngine 4 = ~2.5kk LOC;
>>692146
Можешь смотреть всё, что найдешь: entt, entityx и прочее. Но проблема их всех в том, что они делаются под сферический в вакууме арканоид-змейку. А не ММО. И имеют кучу проблем и минусов.
https://habr.com/ru/company/pixonic/blog/413729/
>>692146
Я особо не шарю, но начал бы с этого
https://github.com/jslee02/awesome-entity-component-system
>Какие у анона завалялись материалы по ECS?
Я особо не шарю, но начал бы с этого
https://github.com/jslee02/awesome-entity-component-system
>>692277
Это не совсем пайплайны. Пайплайн - это конвеер, работает как завод
Форвард-деференд - это техники.
Forward - это когда ты прочитал книгу по OpenGl (или D3D или Vulkan) и сразу начал рисовать. Это прямая отрисовка. И ты сразу же столкнешься с проблемой - источники света, в форварде для каждого источника света надо рисовать всю связанную геометрию.
Поэтому придумали деференд - рисовать свет и связанное в отдельные текстуры, а их уже накладывать.
Потом придумали форвард плюс, так как деференд тяжелый
Потом придумали тайлед-деференд
Потом придумали Clustered shading - но мало кто использует
>А как сделать пайплайн просто не понимаю ни ху я. Все эти форварды-деференды.
Это не совсем пайплайны. Пайплайн - это конвеер, работает как завод
Форвард-деференд - это техники.
Forward - это когда ты прочитал книгу по OpenGl (или D3D или Vulkan) и сразу начал рисовать. Это прямая отрисовка. И ты сразу же столкнешься с проблемой - источники света, в форварде для каждого источника света надо рисовать всю связанную геометрию.
Поэтому придумали деференд - рисовать свет и связанное в отдельные текстуры, а их уже накладывать.
Потом придумали форвард плюс, так как деференд тяжелый
Потом придумали тайлед-деференд
Потом придумали Clustered shading - но мало кто использует
>>692277
Вообще вот тут https://triplepointfive.github.io/ogltutor/
есть уроки про деференд - 35/36/37 уроки.
или статья https://habr.com/ru/post/420565/
И конкретно по bgfx - у них же есть пример
https://bkaradzic.github.io/bgfx/examples.html#deferred
Просто начни с основ, и постепенно придет понимание - не гонись за модными словами. Ведь каждое из них решает некую проблему, и только зная эту проблему ты понимаешь цель этой техники.
Для простых игр хватит и форварда - то есть "делаешь как получится". 8 источников света - это уже классика на которой делали и квайки, и анреалы.
>Все эти форварды-деференды
Вообще вот тут https://triplepointfive.github.io/ogltutor/
есть уроки про деференд - 35/36/37 уроки.
или статья https://habr.com/ru/post/420565/
И конкретно по bgfx - у них же есть пример
https://bkaradzic.github.io/bgfx/examples.html#deferred
Просто начни с основ, и постепенно придет понимание - не гонись за модными словами. Ведь каждое из них решает некую проблему, и только зная эту проблему ты понимаешь цель этой техники.
Для простых игр хватит и форварда - то есть "делаешь как получится". 8 источников света - это уже классика на которой делали и квайки, и анреалы.
>>692277
Я не знаю цифр. Помогите освоить теорию чисел....
>А как сделать пайплайн просто не понимаю ни ху я. Все эти форварды-деференды.
Я не знаю цифр. Помогите освоить теорию чисел....
>>692376
А воксельный GI ето что? Не зависит от пайплайна? Воксели дают охуенный результат так-то, все эти конусы. А как это с шадовмап совместить? Очевидно что карты теней будет еще лучше чем воксели, тому что можно в блендере их рассчитать, но воксели нужны для динамического света. Шадовмапы и воксели, например, они смогут выдавать хотя бы 60 фпс на вебжл/днопк?
>>692377
Втыкал в deferred.cpp или в github.com/bkaradzic/bgfx/tree/master/examples/16-shadowmaps и так нихуя и не понял. Ебаные 2к строк, пиздец просто, всё утро пытался структурировать нихуя не поня.
Наверное нужно реально выбрать стек, что-то вроде воксели, шадовмапы, форвардкластерплюс и просто сидеть изучать неделю подряд и прототипы делать на js, а потом переписать на плюсы. Но я даже не понимаю какой стэк эффективнее всего будет. Кластерный форвард нормально? Воксели? Хуексели. Вротебал.
>>692428
Просто хочу готовую маленькую, но удаленькую библиотеку конвейеров, просто взять и всё... Почему в этом мире всё настолько сложно......
А воксельный GI ето что? Не зависит от пайплайна? Воксели дают охуенный результат так-то, все эти конусы. А как это с шадовмап совместить? Очевидно что карты теней будет еще лучше чем воксели, тому что можно в блендере их рассчитать, но воксели нужны для динамического света. Шадовмапы и воксели, например, они смогут выдавать хотя бы 60 фпс на вебжл/днопк?
>>692377
Втыкал в deferred.cpp или в github.com/bkaradzic/bgfx/tree/master/examples/16-shadowmaps и так нихуя и не понял. Ебаные 2к строк, пиздец просто, всё утро пытался структурировать нихуя не поня.
Наверное нужно реально выбрать стек, что-то вроде воксели, шадовмапы, форвардкластерплюс и просто сидеть изучать неделю подряд и прототипы делать на js, а потом переписать на плюсы. Но я даже не понимаю какой стэк эффективнее всего будет. Кластерный форвард нормально? Воксели? Хуексели. Вротебал.
>>692428
Просто хочу готовую маленькую, но удаленькую библиотеку конвейеров, просто взять и всё... Почему в этом мире всё настолько сложно......
>>692444
Это воксель кон трейсинг.
https://github.com/JoeyDeVries/LearnOpenGL
https://learnopengl.com/book/book_pdf.pdf
https://github.com/JoeyDeVries/Cell
Вот с этого начни. Хотяб прочитай book_pdf.pdf. Там всё есть.
Это воксель кон трейсинг.
https://github.com/JoeyDeVries/LearnOpenGL
https://learnopengl.com/book/book_pdf.pdf
https://github.com/JoeyDeVries/Cell
Вот с этого начни. Хотяб прочитай book_pdf.pdf. Там всё есть.
>>692451
Это я уже пытался читать. Но там нету каких-нибудь примеров псевдокода или пояснений с вертухи про граф сцены.
Короче как я понял, лучше всего будет просто выпустить уже дрисяток говноигр на чужом говнокоде и чужом форвард рендере, а потом нанять топовых программестов которые всё это напишут, самый эффективные и минималистичные рендеры из существующих. Благо топовые погромместы вроде как не против.
Это я уже пытался читать. Но там нету каких-нибудь примеров псевдокода или пояснений с вертухи про граф сцены.
Короче как я понял, лучше всего будет просто выпустить уже дрисяток говноигр на чужом говнокоде и чужом форвард рендере, а потом нанять топовых программестов которые всё это напишут, самый эффективные и минималистичные рендеры из существующих. Благо топовые погромместы вроде как не против.
>>692473
Это надо движки смотреть лучше. Огр какой-нибудь.
Меня в последнее время интересует вот что. Некий командный буфер для отрисовки: забиндить такие-то буферы я юзаю опенгл, такие текстуры, такой шейдер, отрисовать столько геометрии. Это не учитывая постпроцессинг в фреймбуферами и прочими штуками.
А про граф сцены можно глянуть как было в Думе 3 сделано. Там, как я понял, большой массив поверхностей (surface). Каждый кадр этот массив перестраивается и отрисовывается.
> Но там нету каких-нибудь примеров псевдокода или пояснений с вертухи про граф сцены.
Это надо движки смотреть лучше. Огр какой-нибудь.
Меня в последнее время интересует вот что. Некий командный буфер для отрисовки: забиндить такие-то буферы я юзаю опенгл, такие текстуры, такой шейдер, отрисовать столько геометрии. Это не учитывая постпроцессинг в фреймбуферами и прочими штуками.
А про граф сцены можно глянуть как было в Думе 3 сделано. Там, как я понял, большой массив поверхностей (surface). Каждый кадр этот массив перестраивается и отрисовывается.
>>692499
деферендциальный - смесь деферреда и дифура
деферендциальный - смесь деферреда и дифура
>>692495
Еще и огр разбирать ебать же работы. Годик придется убить только на это.
Вот кстати это тоже проблема. Нужен командный буфер, да и прост буфера всякие, понять как их организовывать правильнее всего. Литературы на этот счет дохуя, с пустословием в основном - примеров псевдокода почти нет, разве что разбирать конкретные движки.
В исходниках копаться? Ух ебать, страшно стало.
> Это надо движки смотреть лучше. Огр какой-нибудь.
Еще и огр разбирать ебать же работы. Годик придется убить только на это.
> Некий командный буфер для отрисовки
Вот кстати это тоже проблема. Нужен командный буфер, да и прост буфера всякие, понять как их организовывать правильнее всего. Литературы на этот счет дохуя, с пустословием в основном - примеров псевдокода почти нет, разве что разбирать конкретные движки.
> А про граф сцены можно глянуть как было в Думе 3 сделано.
В исходниках копаться? Ух ебать, страшно стало.
>>692507
По думу 3 кстати можно всякие разборчики поискать
https://umumble.com/blogs/cpp/source-code-analysis-doom-3/
По думу 3 кстати можно всякие разборчики поискать
https://umumble.com/blogs/cpp/source-code-analysis-doom-3/
>>692542
Если не разбираешься с этим несколько лет подряд - нихуя с наскока не понять.
видать это точно не моё, разве что требования к рендеру и движку составлять, эх епты бля
Если не разбираешься с этим несколько лет подряд - нихуя с наскока не понять.
видать это точно не моё, разве что требования к рендеру и движку составлять, эх епты бля
>>692549
Ну если ты хотя бы в общих чертах понимаешь про устройство проц/гпу, типичные понятия по архитектуре кода, то это можно раскурить, просто первый раз надо чуть больше 5 минут посидеть.
Без этих знаний скорее всего действительно тяжеловато будет, слишком специфичная область.
Ну если ты хотя бы в общих чертах понимаешь про устройство проц/гпу, типичные понятия по архитектуре кода, то это можно раскурить, просто первый раз надо чуть больше 5 минут посидеть.
Без этих знаний скорее всего действительно тяжеловато будет, слишком специфичная область.
Увидел тред. Обрадовался, ведь я тоже пытаюсь писать движки.
Прочитал тред. Задепрессовал, ведь тут обсуждают только графику.
Вот скажите, если вы для физики сразу берёте Box2D/Bullet, то зачем вам графику самим делать?
Физику вы УЖЕ берёте чужую, уже движок получается не ваш. Почему бы и графику чужую не взять?
И вообще, если уж на то пошло, нужно свой OpenGL писать с нуля, чтобы движок был 100% твоим личным.
А ещё свою операционную систему и свой язык программирования, но это для особо упорных, ящитаю.
Прочитал тред. Задепрессовал, ведь тут обсуждают только графику.
Вот скажите, если вы для физики сразу берёте Box2D/Bullet, то зачем вам графику самим делать?
Физику вы УЖЕ берёте чужую, уже движок получается не ваш. Почему бы и графику чужую не взять?
И вообще, если уж на то пошло, нужно свой OpenGL писать с нуля, чтобы движок был 100% твоим личным.
А ещё свою операционную систему и свой язык программирования, но это для особо упорных, ящитаю.
>>692557
Я писал свою 2д физику, там буквально 200 строк: проверка столкновений и выталкивание объектов.
Я писал свою 2д физику, там буквально 200 строк: проверка столкновений и выталкивание объектов.
>>692557
А я бы задумался о том, как сделать йоба звук. Вообще инфы нет.
А я бы задумался о том, как сделать йоба звук. Вообще инфы нет.
>>692572
На AABB кубиках что ли?
Ты бы попробовал OBB, или вообще произвольные фигуры, лол.
Плюс всякие некрасивые граничные случаи, пролет сквозь, десятки тысяч динамических объектов.
На AABB кубиках что ли?
Ты бы попробовал OBB, или вообще произвольные фигуры, лол.
Плюс всякие некрасивые граничные случаи, пролет сквозь, десятки тысяч динамических объектов.
>>692554
Да тут не только в этом дело. Вот к примеру, какой самый эффективный рендер для качественных теней в webgl? Для gles3? Gl4.6? А если динамический свет?
Короче, нетривиальные задачи. Если писать под одну платформу - всё впринципе ясно-понятно, можно даже несколько рендеров скопировать и понять. Но каких-то объективных данных по тестам я так и не смог найти, по эффективности подходов. Есть только буквально обрывки информации и тесты-сравнения, без пояснений.
>>692557
Личноя взял threejs тому шо под html5 нужно качественно сделать. Но самих рендеров не так и много на самом деле. А качественных и мультиплатформенных - вообще нет.
> Без этих знаний скорее всего действительно тяжеловато будет
Да тут не только в этом дело. Вот к примеру, какой самый эффективный рендер для качественных теней в webgl? Для gles3? Gl4.6? А если динамический свет?
Короче, нетривиальные задачи. Если писать под одну платформу - всё впринципе ясно-понятно, можно даже несколько рендеров скопировать и понять. Но каких-то объективных данных по тестам я так и не смог найти, по эффективности подходов. Есть только буквально обрывки информации и тесты-сравнения, без пояснений.
>>692557
> Почему бы и графику чужую не взять?
Личноя взял threejs тому шо под html5 нужно качественно сделать. Но самих рендеров не так и много на самом деле. А качественных и мультиплатформенных - вообще нет.
>>692575
OBB. Алгоритм SAT для нахождения точки пересечения. Это очень кривая физика, для нормального выталкивания нужно рассчитывать не точку, а площадь. Но для простой игры сойдёт.
OBB. Алгоритм SAT для нахождения точки пересечения. Это очень кривая физика, для нормального выталкивания нужно рассчитывать не точку, а площадь. Но для простой игры сойдёт.
>>692557
Я как раз делаю свой язык программирования и его компилятор-интерпретатор. Уже небольшие функции и типы данных можно писать, но не более.
Когда-то задумывался о том, чтобы сделать свой формат ассетов и использовать свой язык программирования в качестве встраиваемого в эти ассеты, чтобы запускать всякие там анимации, движения. И один ассет включал в себя другие, а в связке с настройками (например, рендеринг, физика и всё прочее) создало бы игру. Но мне не очень нравится геймдев, так что я пока собирался язык встраивать только в некоторые другие будущие проекты.
Уже написал свой софтрендер-рейтрейсер, может сферы и треугольники с освещением рисовать. У меня есть и библиотека-недоделка, которая описывает графический мир через вложенные ноды и рисует их через бекенды. Есть 2 бекенда — софтрендерный и GLSL-ный, оба производят рейтрейсинг. Но даже второй не очень производительный, штук 500 треугольников в 60 ФПС в FullHD потянет.
Когда-нибудь, может, попробую написать Пастрейсер и фотонтрейсер.
Когда доделаю язык программирования и его компилятор-интерпретатор, хотел попробовать запилить и физический движок. Можно несколько — механический, жидкостный, термодинамический, электродинамический. Если пойму, как описываются атомы, то и химический. Но все кроме механического (и жидкостного?) подходят скорее для всяких технических задач.
Потом и графическую либу, и свою ГУИ-библиотеку переведу на свой язык программирования и выпущу в открытый свет.
Я как раз делаю свой язык программирования и его компилятор-интерпретатор. Уже небольшие функции и типы данных можно писать, но не более.
Когда-то задумывался о том, чтобы сделать свой формат ассетов и использовать свой язык программирования в качестве встраиваемого в эти ассеты, чтобы запускать всякие там анимации, движения. И один ассет включал в себя другие, а в связке с настройками (например, рендеринг, физика и всё прочее) создало бы игру. Но мне не очень нравится геймдев, так что я пока собирался язык встраивать только в некоторые другие будущие проекты.
Уже написал свой софтрендер-рейтрейсер, может сферы и треугольники с освещением рисовать. У меня есть и библиотека-недоделка, которая описывает графический мир через вложенные ноды и рисует их через бекенды. Есть 2 бекенда — софтрендерный и GLSL-ный, оба производят рейтрейсинг. Но даже второй не очень производительный, штук 500 треугольников в 60 ФПС в FullHD потянет.
Когда-нибудь, может, попробую написать Пастрейсер и фотонтрейсер.
Когда доделаю язык программирования и его компилятор-интерпретатор, хотел попробовать запилить и физический движок. Можно несколько — механический, жидкостный, термодинамический, электродинамический. Если пойму, как описываются атомы, то и химический. Но все кроме механического (и жидкостного?) подходят скорее для всяких технических задач.
Потом и графическую либу, и свою ГУИ-библиотеку переведу на свой язык программирования и выпущу в открытый свет.
>>692578
Почему каждый пилит свой движок? Почему бы не помочь развивать существующие опенсорсные?
Почему каждый пилит свой движок? Почему бы не помочь развивать существующие опенсорсные?
>>692584
Их нет, опенсорсных, чтобы подходил всем и все бы над ним работали. Большинство - рендеры под опенжл/dx.
Собратсья в улей люди не очень способны, нужны деньги и менеджмент.
Их нет, опенсорсных, чтобы подходил всем и все бы над ним работали. Большинство - рендеры под опенжл/dx.
Собратсья в улей люди не очень способны, нужны деньги и менеджмент.
>>692591
Но вот ты можешь подобрать заброшеный движок - например, Urho 3D - и объявить себя его главным разработчиком.
Или форкнуть Годот, и соревноваться с Хуаном.
Вообще много увлекательных способов пилить движок, и не быть при этом никому не известным горбуном сидящем в своём подвале.
Но вот ты можешь подобрать заброшеный движок - например, Urho 3D - и объявить себя его главным разработчиком.
Или форкнуть Годот, и соревноваться с Хуаном.
Вообще много увлекательных способов пилить движок, и не быть при этом никому не известным горбуном сидящем в своём подвале.
>>692584
https://en.wikipedia.org/wiki/Not_invented_here
https://ru.wikipedia.org/wiki/Синдром_неприятия_чужой_разработки
>>692594
Ты его ответ глазами читал или чем? Он же писал, >>692591
Очевидно, приведённые примеры ему не подходят.
Если тебе это важно - вперёд и с песней. Некоторым сидеть в подвале намного приятнее и спокойнее.
>Почему каждый пилит свой движок? Почему бы не помочь развивать существующие опенсорсные?
https://en.wikipedia.org/wiki/Not_invented_here
https://ru.wikipedia.org/wiki/Синдром_неприятия_чужой_разработки
>>692594
>Urho 3D
>Годот
Ты его ответ глазами читал или чем? Он же писал, >>692591
>чтобы подходил всем
Очевидно, приведённые примеры ему не подходят.
>и не быть при этом никому не известным горбуном сидящем в своём подвале
Если тебе это важно - вперёд и с песней. Некоторым сидеть в подвале намного приятнее и спокойнее.
>>692578
Я тоже несколько раз пробовал писать свой ЯП. И скажу честно, в долгосрочной перспективе это адЪ, потому что все эти функции-шмункции - пустяк, реализовать интерпретатор языка с функциями можно за несколько часов. Но в долгосрочной перспективе тебе придётся поддерживать огромный набор огромных API. Достаточно только взглянуть на WinAPI и ужаснуться. Зачем тебе API? Потому что ЯП без поддержки сторонних API - бесполезная игрушка, что-то вроде брейнфака - код писать возможно, но этот код ничего кроме простых арифметических операций делать не способен (ни файл с диска считать или записать, ни картинку на экран вывести, ни кнопочку нарисовать и нажатие на неё обработать). Пока ты пишешь интерпретатор на уже существующем ЯП, ты неявно используешь API системы благодаря готовым библиотекам этого ЯП, но когда тебе захочется сделать компилятор, чтобы твои программки выполнялись отдельно от чужого кода - тебе потребуется лезть во все эти дремучие API, если не в прерывания BIOS и коды процессора (зависит от того, во что будешь компилировать/транспилировать). Ну нафиг такое, даже если твой ЯП будет гениальным и лучшим в мире, без API он даже тебе ничем не поможет...
>Уже небольшие функции и типы данных можно писать, но не более.
Я тоже несколько раз пробовал писать свой ЯП. И скажу честно, в долгосрочной перспективе это адЪ, потому что все эти функции-шмункции - пустяк, реализовать интерпретатор языка с функциями можно за несколько часов. Но в долгосрочной перспективе тебе придётся поддерживать огромный набор огромных API. Достаточно только взглянуть на WinAPI и ужаснуться. Зачем тебе API? Потому что ЯП без поддержки сторонних API - бесполезная игрушка, что-то вроде брейнфака - код писать возможно, но этот код ничего кроме простых арифметических операций делать не способен (ни файл с диска считать или записать, ни картинку на экран вывести, ни кнопочку нарисовать и нажатие на неё обработать). Пока ты пишешь интерпретатор на уже существующем ЯП, ты неявно используешь API системы благодаря готовым библиотекам этого ЯП, но когда тебе захочется сделать компилятор, чтобы твои программки выполнялись отдельно от чужого кода - тебе потребуется лезть во все эти дремучие API, если не в прерывания BIOS и коды процессора (зависит от того, во что будешь компилировать/транспилировать). Ну нафиг такое, даже если твой ЯП будет гениальным и лучшим в мире, без API он даже тебе ничем не поможет...
>>692594
>>692599
Дело не в самом создании движка, а в том что почти большинство современных движков какой-то дикий оверхед делают, который нахуй нинужен ни при каких условиях типичной игори. Или занимаются бессмысленными велосипедами, хотя можно взять SoLoud/OpenAL, Bullet, bgfx, Ozz-animation, Assimp а вот это уже хз, тут от реализации сцены всё зависит и собрать это всё в нормальный кросплатформенный двиг.
Алсо можно в этом треде собрать либы для движков, в стиле:
Системы анимации: Ozz-animation, ???, ?????
Звук: SoLoud, OpenAL
2d физика: Box2d
3d физика: Bullet
Рендеры: filament
Кросс-шейдеры: bgfx
Управление окном/вводом-выводом: SDL, SFML, GLFW
Граф сцены: бхуй))00 (возможно можно спиздить от ozz-animation, но это не точно)
Форматы данных: Assimp
вроде такие списочки есть на гитхабе, но хуле бы свой не сделать.
>>692599
Дело не в самом создании движка, а в том что почти большинство современных движков какой-то дикий оверхед делают, который нахуй нинужен ни при каких условиях типичной игори. Или занимаются бессмысленными велосипедами, хотя можно взять SoLoud/OpenAL, Bullet, bgfx, Ozz-animation, Assimp а вот это уже хз, тут от реализации сцены всё зависит и собрать это всё в нормальный кросплатформенный двиг.
Алсо можно в этом треде собрать либы для движков, в стиле:
Системы анимации: Ozz-animation, ???, ?????
Звук: SoLoud, OpenAL
2d физика: Box2d
3d физика: Bullet
Рендеры: filament
Кросс-шейдеры: bgfx
Управление окном/вводом-выводом: SDL, SFML, GLFW
Граф сцены: бхуй))00 (возможно можно спиздить от ozz-animation, но это не точно)
Форматы данных: Assimp
вроде такие списочки есть на гитхабе, но хуле бы свой не сделать.
>>692614
Вот тут полностью согласен, самому хочется сделать простой худенький движок <100кб, но, видимо, не судьба.
Вообще тут всё от ЯП сильно зависит, если б ЯП умел выкидывать лишние функции из кода - было бы проще.
>какой-то дикий оверхед делают, который нахуй нинужен ни при каких условиях типичной игори
Вот тут полностью согласен, самому хочется сделать простой худенький движок <100кб, но, видимо, не судьба.
Вообще тут всё от ЯП сильно зависит, если б ЯП умел выкидывать лишние функции из кода - было бы проще.
>>692602
На самом деле мой компилятор не интерпретирует код, он интерпретирует исходники как, например, linux-ld.so интерпретирует ELF-файлы в процессы. Просто мой ЯП предназначен для исполнения из исходников, а компиляция в бинарники это дополнительная фича.
Немного неудачно написал.
Что насчёт API, то не вижу тут ничего слишком сложного. Что там в этом API надо? Писать в файлы, октрывать сокеты, управлять памятью. В линуксе всё просто, open, read, write, close, sbrk и ещё парочка системных вызовов. Думаю, в виндовсе тоже не слишком усложнены операции записи в файлы.
Что насчёт сокетов и управления памятью, я пока не знаю, но в линуксе всё-равно не очень много системных вызовов (около 100), а для виндовса наверняка можно найти библиотченые слои совместимости с линуксовым и использовать их.
Например, поддержку потоков (через отдельную библиотеку моего ЯП) я собирался реализовать, используя pthread, а он есть и под линукс, и под виндовс (хотя, может быть, я пересмотрю это решение). Надо будет просто слинковать библиотеку.
Этим пусть занимается SDL2. Думаю, я сделаю программку для перевода хедер-файлов Си в библиотеку моего языка программирования (бинарная библиотека линкуется отдельно) и всё готово.
У меня уже есть недоделка библиотеки ГУИ (на C++), которая умеет создавать окна и рисовать туда, обрабатывать нажатия. И базируется она на SDL2, так что можно запустить хоть на линдовсе, хоть на вуниксе, на микроконтроллере (но программисту придётся написать реализацию SDL2 для него, либо использовать более низкоуровневые функции), так как моя ГУИ-библиотека базируется на моей графической библиотеке, а к ней уже есть софтрендер-рейтрейсер. Да, рейтрейсить ГУИ это сомнительная идея, но растеризатор я ещё не писал
На самом деле мой компилятор не интерпретирует код, он интерпретирует исходники как, например, linux-ld.so интерпретирует ELF-файлы в процессы. Просто мой ЯП предназначен для исполнения из исходников, а компиляция в бинарники это дополнительная фича.
Немного неудачно написал.
Что насчёт API, то не вижу тут ничего слишком сложного. Что там в этом API надо? Писать в файлы, октрывать сокеты, управлять памятью. В линуксе всё просто, open, read, write, close, sbrk и ещё парочка системных вызовов. Думаю, в виндовсе тоже не слишком усложнены операции записи в файлы.
Что насчёт сокетов и управления памятью, я пока не знаю, но в линуксе всё-равно не очень много системных вызовов (около 100), а для виндовса наверняка можно найти библиотченые слои совместимости с линуксовым и использовать их.
Например, поддержку потоков (через отдельную библиотеку моего ЯП) я собирался реализовать, используя pthread, а он есть и под линукс, и под виндовс (хотя, может быть, я пересмотрю это решение). Надо будет просто слинковать библиотеку.
>ни картинку на экран вывести, ни кнопочку нарисовать и нажатие на неё обработать
Этим пусть занимается SDL2. Думаю, я сделаю программку для перевода хедер-файлов Си в библиотеку моего языка программирования (бинарная библиотека линкуется отдельно) и всё готово.
У меня уже есть недоделка библиотеки ГУИ (на C++), которая умеет создавать окна и рисовать туда, обрабатывать нажатия. И базируется она на SDL2, так что можно запустить хоть на линдовсе, хоть на вуниксе, на микроконтроллере (но программисту придётся написать реализацию SDL2 для него, либо использовать более низкоуровневые функции), так как моя ГУИ-библиотека базируется на моей графической библиотеке, а к ней уже есть софтрендер-рейтрейсер. Да, рейтрейсить ГУИ это сомнительная идея, но растеризатор я ещё не писал
>>692584
Хуан плез
Хуан плез
>>692616
Я ничего не понял (в линуксе не разбираюсь). Компилятор не может интерпретировать код, компилятор код компилирует (преобразует текст в машинный код). Интерпретируют код интерпретаторы (непосредственно выполняют команды, соответствующие тексту). Компилятор и интерпретатор относятся к трансляторам, помимо них ещё есть транспилятор (отличается от компилятора тем, что транслирует код не в машинный код, а в исходный код другого ЯП). Если твой ЯП "предназначен для исполнения из исходников" - то у тебя интерпретатор.
Кстати, траспиляторы - возможный способ уйти от проблем с машинным/ассемблерным кодом. Можно компилировать в промежуточный ЯП типа C, а уже компилятор промежуточного ЯП будет заниматься созданием машинного кода. У этого способа есть свои недостатки, но по идее проще и удобнее, чем возиться с машинным кодом и API системы.
Всё, что там есть) Хотя по идее можно транспилировать заголовочные файлы из C в свой ЯП...
Но его тоже придётся как-то линковать. А для этого нужны заголовочные файлы на твоём ЯП. А их писать нужно.
Короч писать ЯП - это интересно, но на сегодняшний день сильно бесполезно(
>На самом деле мой компилятор не интерпретирует код, он интерпретирует исходники как, например, linux-ld.so интерпретирует ELF-файлы в процессы. Просто мой ЯП предназначен для исполнения из исходников, а компиляция в бинарники это дополнительная фича.
Я ничего не понял (в линуксе не разбираюсь). Компилятор не может интерпретировать код, компилятор код компилирует (преобразует текст в машинный код). Интерпретируют код интерпретаторы (непосредственно выполняют команды, соответствующие тексту). Компилятор и интерпретатор относятся к трансляторам, помимо них ещё есть транспилятор (отличается от компилятора тем, что транслирует код не в машинный код, а в исходный код другого ЯП). Если твой ЯП "предназначен для исполнения из исходников" - то у тебя интерпретатор.
Кстати, траспиляторы - возможный способ уйти от проблем с машинным/ассемблерным кодом. Можно компилировать в промежуточный ЯП типа C, а уже компилятор промежуточного ЯП будет заниматься созданием машинного кода. У этого способа есть свои недостатки, но по идее проще и удобнее, чем возиться с машинным кодом и API системы.
>Что там в этом API надо?
Всё, что там есть) Хотя по идее можно транспилировать заголовочные файлы из C в свой ЯП...
>Этим пусть занимается SDL2
Но его тоже придётся как-то линковать. А для этого нужны заголовочные файлы на твоём ЯП. А их писать нужно.
Короч писать ЯП - это интересно, но на сегодняшний день сильно бесполезно(
>>692615
За тебя сделали Sokol и Oryol. Орёл потолще 100кб будет, сокол - то что тебе нужно. В 100кб кроссплатформенного кода уложишься.
Но лично я хз как сделать на этих пернатых полноценную игру готовую к продакшену. Исходники по 1к строк для теней только. Документация хорошая, но я нихуя не понял, тупой слишком.
https://github.com/floooh/sokol
https://github.com/floooh/oryol
Это делается при сборке. В теории, покрайней мере, на практике движкопицы редко занимаются обрезкой сборок под конфигурации. Даже библиотеки в одну свалку бросают.
> простой худенький движок <100кб
За тебя сделали Sokol и Oryol. Орёл потолще 100кб будет, сокол - то что тебе нужно. В 100кб кроссплатформенного кода уложишься.
Но лично я хз как сделать на этих пернатых полноценную игру готовую к продакшену. Исходники по 1к строк для теней только. Документация хорошая, но я нихуя не понял, тупой слишком.
https://github.com/floooh/sokol
https://github.com/floooh/oryol
> если б ЯП умел выкидывать лишние функции из кода - было бы проще.
Это делается при сборке. В теории, покрайней мере, на практике движкопицы редко занимаются обрезкой сборок под конфигурации. Даже библиотеки в одну свалку бросают.
>>692643
Примеры сокола, да. И примеры теней на 200 строк, загрузка gtlf2 - 1к. Там вроде есть какие-то ништяки, но. Но.
> Исходники по 1к строк для теней только.
Примеры сокола, да. И примеры теней на 200 строк, загрузка gtlf2 - 1к. Там вроде есть какие-то ништяки, но. Но.
>>692648
Это уже какое-то 2d.
> для конкретной игры достаточно проверки столкновений прямоугольников в 200 строк кода
Это уже какое-то 2d.
>>692649
Если у тебя игра 2д, зачем тащить 3д?
Ну и наоборот, если игра 3д, то вряд ли нужны библиотеки для 2д анимации.
Если у тебя игра 2д, зачем тащить 3д?
Ну и наоборот, если игра 3д, то вряд ли нужны библиотеки для 2д анимации.
>>692651
Не, я к тому что для любого 3d столкновений недостаточно. Придется оклюжены всякие тащить и 3d аудио.
Не, я к тому что для любого 3d столкновений недостаточно. Придется оклюжены всякие тащить и 3d аудио.
>>692668
Нет, сейчас он пилит ИИ для Скайнета
Нет, сейчас он пилит ИИ для Скайнета
>>692648
Если достаточно, то не надо тащить.
Если недостаточно, то надо тащить.
> Если для конкретной игры достаточно проверки столкновений прямоугольников в 200 строк кода, зачем тащить полную библиотеку?
Если достаточно, то не надо тащить.
Если недостаточно, то надо тащить.
>>692673
Тогда это должен быть не движок, а ворох различных библиотек: вот физика 1, вот физика 2, вот физика 3 и т. д.
Тогда это должен быть не движок, а ворох различных библиотек: вот физика 1, вот физика 2, вот физика 3 и т. д.
>>692507
Всё уже сделали за тебя. У Фабиана Сангларда где-то был разбор Дума 3
https://fabiensanglard.net/doom3/renderer.txt
https://fabiensanglard.net/doom3/doom3_notes.txt
> В исходниках копаться? Ух ебать, страшно стало.
Всё уже сделали за тебя. У Фабиана Сангларда где-то был разбор Дума 3
https://fabiensanglard.net/doom3/renderer.txt
https://fabiensanglard.net/doom3/doom3_notes.txt
>>692675
Ебать. Ну да ладно поцаны, пойду игру делать, ебал я в рот это всё писать.
Ебать. Ну да ладно поцаны, пойду игру делать, ебал я в рот это всё писать.
>>692674
Если ты пишешь движок под конкретную игру, то будет только одна физика.
Движок - не обязательно монстр типа Юнити. Например idTech1 тоже движок, вполне себе компактный и под конкретную задачу.
Если ты пишешь движок под конкретную игру, то будет только одна физика.
Движок - не обязательно монстр типа Юнити. Например idTech1 тоже движок, вполне себе компактный и под конкретную задачу.
>>692626
Мне кажется, у тебя какое-то старомодное отношение к програмимрованию.
Хорошо, у меня интерпретируемый язык программирования, где можно написать только одну, но очень длинную команду, раскиданную по нескольким файлам. Так же как линуксовый линковщик интепретирует ELF-файл (+ библиотеки) в процесс или виндовсовский экзекутор интерпретирует .exe в процесс или что там.
На самом деле, грань между компиляцией и интепретацией не такая уж и жёсткая. Ведь часто и команды интерпретируемых ЯП JIT-компилируются.
Современные модные молодёжные языки программирования используют компиляцию в LLVM IR, а из него уже компилируется в любой поддерживаемый машинный код.
Так я делаю и со своим языком. По правде, я его перевожу сначала в свой промежуточный формат, который когда-нибудь станет байткодом как в джаве или питоне, а потом его в LLVM IR.
Да. В случае с линуксом сделать интерфейс к сотне самостоятельных системных вызовов — проще простого. Для SDL2 уже сложнее, поэтому следует сделать утилиту для перевода хедеров си в код моего ЯП.
В моём ЯП, кстати, поддерживаются многие сишные типы, а ABI стандартный, так как им занимается LLVM, так что это действительно не сложно.
Что сложнее, так это совладать с кодом. Компилятор я пишу на питоне (как бы это странно не звучало) планирую потом на мой ЯП переписать, а я не очень разбираюсь в ООП и вообще наговнокодил, что перебирать и перебирать.
Мне кажется, у тебя какое-то старомодное отношение к програмимрованию.
>Если твой ЯП "предназначен для исполнения из исходников" - то у тебя интерпретатор.
Хорошо, у меня интерпретируемый язык программирования, где можно написать только одну, но очень длинную команду, раскиданную по нескольким файлам. Так же как линуксовый линковщик интепретирует ELF-файл (+ библиотеки) в процесс или виндовсовский экзекутор интерпретирует .exe в процесс или что там.
На самом деле, грань между компиляцией и интепретацией не такая уж и жёсткая. Ведь часто и команды интерпретируемых ЯП JIT-компилируются.
>в промежуточный ЯП типа C
Современные модные молодёжные языки программирования используют компиляцию в LLVM IR, а из него уже компилируется в любой поддерживаемый машинный код.
Так я делаю и со своим языком. По правде, я его перевожу сначала в свой промежуточный формат, который когда-нибудь станет байткодом как в джаве или питоне, а потом его в LLVM IR.
>А их писать нужно
Да. В случае с линуксом сделать интерфейс к сотне самостоятельных системных вызовов — проще простого. Для SDL2 уже сложнее, поэтому следует сделать утилиту для перевода хедеров си в код моего ЯП.
В моём ЯП, кстати, поддерживаются многие сишные типы, а ABI стандартный, так как им занимается LLVM, так что это действительно не сложно.
Что сложнее, так это совладать с кодом. Компилятор я пишу на питоне (как бы это странно не звучало) планирую потом на мой ЯП переписать, а я не очень разбираюсь в ООП и вообще наговнокодил, что перебирать и перебирать.
>>692681
Ой все
>Так же как линуксовый линковщик интепретирует ELF-файл (+ библиотеки) в процесс или виндовсовский экзекутор интерпретирует .exe в процесс или что там.
Ой все
>>692681
Надеюсь твой язык называется v. Иначе смысла чет-то мало.
Надеюсь твой язык называется v. Иначе смысла чет-то мало.
>>692614
Постепенно сделаю по ссылке. Примерно в таком же виде. Просто всего много, надо еще и собрать
>вроде такие списочки есть на гитхабе, но хуле бы свой не сделать.
Постепенно сделаю по ссылке. Примерно в таком же виде. Просто всего много, надо еще и собрать
>>692681
Исполняемый файл не интерпретируется. Он загружается системой в оперативную память целиком, после того, как прошёл проверку по заголовку на корректность. И исполняется процессором как набор машинных кодов (с данными, но данные в отдельном сегменте). Да, разумеется, центральный процессор - это физическая реализация интерпретатора машинных кодов, однако когда речь идёт об "интерпретации кода", подразумевается программная интерпретация: программа-интерпретатор по байтам/по словам/по строкам считывает код, ищет в словаре соответствующие машинные команды/наборы команд и исполняет их (т.е. транслирует кусочки программы только когда нужно их исполнить).
Имхо, часто лучше переписать с нуля, так код получится компактнее и понятнее, чем был с первой попытки. Вторая попытка займёт немного времени, ведь выдумывать намного меньше, чем первый раз.
А я не вижу смысла накручивать какие-то новомодные штучки, если от них куча проблем, а работать можно и без них)
Я вот забил на выдумывание своего языка ещё и потому, что осознал, что мне он и не нужен в общем-то. Что я на нём буду писать? Какие задачи решать? У меня по жизни почти не бывает таких задач, для решения которых нужно было бы писать программу, а если такая задача и появляется, то проще и быстрее всего решить её на лучше всего известном мне Pascal. Да, когда-то я мечтал о том, что придумаю ЯП, который многократно ускорит процесс решения задач, но теперь я понимаю, что самое главное в программировании - это придумать/найти/понять алгоритм, а реализация алгоритма мало зависит от применяемого языка. И вот придумывать алгоритмы никакой ЯП не поможет...
>виндовсовский экзекутор интерпретирует .exe в процесс или что там
Исполняемый файл не интерпретируется. Он загружается системой в оперативную память целиком, после того, как прошёл проверку по заголовку на корректность. И исполняется процессором как набор машинных кодов (с данными, но данные в отдельном сегменте). Да, разумеется, центральный процессор - это физическая реализация интерпретатора машинных кодов, однако когда речь идёт об "интерпретации кода", подразумевается программная интерпретация: программа-интерпретатор по байтам/по словам/по строкам считывает код, ищет в словаре соответствующие машинные команды/наборы команд и исполняет их (т.е. транслирует кусочки программы только когда нужно их исполнить).
>Что сложнее, так это совладать с кодом.
>я не очень разбираюсь в ООП и вообще наговнокодил, что перебирать и перебирать.
Имхо, часто лучше переписать с нуля, так код получится компактнее и понятнее, чем был с первой попытки. Вторая попытка займёт немного времени, ведь выдумывать намного меньше, чем первый раз.
>Мне кажется, у тебя какое-то старомодное отношение к програмимрованию.
А я не вижу смысла накручивать какие-то новомодные штучки, если от них куча проблем, а работать можно и без них)
Я вот забил на выдумывание своего языка ещё и потому, что осознал, что мне он и не нужен в общем-то. Что я на нём буду писать? Какие задачи решать? У меня по жизни почти не бывает таких задач, для решения которых нужно было бы писать программу, а если такая задача и появляется, то проще и быстрее всего решить её на лучше всего известном мне Pascal. Да, когда-то я мечтал о том, что придумаю ЯП, который многократно ускорит процесс решения задач, но теперь я понимаю, что самое главное в программировании - это придумать/найти/понять алгоритм, а реализация алгоритма мало зависит от применяемого языка. И вот придумывать алгоритмы никакой ЯП не поможет...
>>692648
Будет, если будет написан на языке, поддерживающим частичную сборку (изолированный код отбрасывается).
>>692674
Зачем? Ну вот, допустим, у нас есть:
- проверка коллизий 2д фигур: круги, прямоугольники, линии
- проверка коллизий 3д фигур: сферы, параллелепипеды, линии
Итого 6 разных функций. Если мы из своего кода обращаемся только к одной из этих 6 функций (прямоугольники), то остальные 5 нам не нужны, так? Да, если мы где-то в движке неявно их вызываем, то они нам нужны, но если мы не делаем необдуманных вызовов, то они нам не нужны. А раз не нужны, то в игру (.exe) их можно просто не включать.
Вообще, любую программу можно рассматривать как дерево процедур/функций. Главная процедура - это собственно программа (program в Pascal, void main в C и т.д.), из которой вызываются процедуры первого уровня, из которых вызываются процедуры второго уровня, из которых - третьего, и так далее до самых примитивных процедур, "листьев" дерева кода. Нетрудно догадаться, что если мы написали какую-то ветку кода, а затем разорвали единственную связь между этой веткой и остальным деревом (закомментировали вызов корневой процедуры данной ветки), то наша ветка становится бесполезной - полностью изолированной от остального кода, и вставлять её в исполняемый код будет неблагоразумно. Почему бы не отбросить эту лишнюю ветку?..
Кстати, я слышал, что именно так и делает компилятор C/C++, т.е. не оставляет неиспользуемое в исполняемом коде, но в таком случае для меня остаётся загадкой, почему современное ПО, которое якобы почти всегда пишется на C++, так сильно жиреет. Ладно там игровые конструкторы типа Unity, но что на счёт реальных движков, для запуска игры на которых нужно произвести сборку кода игры вместе с кодом этого движка?
>Так движок общего назначения и не будет никогда "худеньким".
Будет, если будет написан на языке, поддерживающим частичную сборку (изолированный код отбрасывается).
>>692674
>Тогда это должен быть не движок, а ворох различных библиотек: вот физика 1, вот физика 2, вот физика 3 и т. д.
Зачем? Ну вот, допустим, у нас есть:
- проверка коллизий 2д фигур: круги, прямоугольники, линии
- проверка коллизий 3д фигур: сферы, параллелепипеды, линии
Итого 6 разных функций. Если мы из своего кода обращаемся только к одной из этих 6 функций (прямоугольники), то остальные 5 нам не нужны, так? Да, если мы где-то в движке неявно их вызываем, то они нам нужны, но если мы не делаем необдуманных вызовов, то они нам не нужны. А раз не нужны, то в игру (.exe) их можно просто не включать.
Вообще, любую программу можно рассматривать как дерево процедур/функций. Главная процедура - это собственно программа (program в Pascal, void main в C и т.д.), из которой вызываются процедуры первого уровня, из которых вызываются процедуры второго уровня, из которых - третьего, и так далее до самых примитивных процедур, "листьев" дерева кода. Нетрудно догадаться, что если мы написали какую-то ветку кода, а затем разорвали единственную связь между этой веткой и остальным деревом (закомментировали вызов корневой процедуры данной ветки), то наша ветка становится бесполезной - полностью изолированной от остального кода, и вставлять её в исполняемый код будет неблагоразумно. Почему бы не отбросить эту лишнюю ветку?..
Кстати, я слышал, что именно так и делает компилятор C/C++, т.е. не оставляет неиспользуемое в исполняемом коде, но в таком случае для меня остаётся загадкой, почему современное ПО, которое якобы почти всегда пишется на C++, так сильно жиреет. Ладно там игровые конструкторы типа Unity, но что на счёт реальных движков, для запуска игры на которых нужно произвести сборку кода игры вместе с кодом этого движка?
>>692602
Дык FFI с C в помощь. Если в твоём супер-языке есть FFI C, всё, считай, у тебя есть и WinAPI, и POSIX API, и какое угодно API а если разработчику не нужно для этого руками писать биндинги, вообще улёт
Дык FFI с C в помощь. Если в твоём супер-языке есть FFI C, всё, считай, у тебя есть и WinAPI, и POSIX API, и какое угодно API а если разработчику не нужно для этого руками писать биндинги, вообще улёт
>>692823
Они и не включаются. Компилятор выкидывает - об этом в студии даже есть специальный варнинг (что-то типа "данная функция нигде не используется, она будет исключена из кода")
>А раз не нужны, то в игру (.exe) их можно просто не включать.
Они и не включаются. Компилятор выкидывает - об этом в студии даже есть специальный варнинг (что-то типа "данная функция нигде не используется, она будет исключена из кода")
73 Кб, 960x720Как рисовать псевдотрёхмерные домики в стиле GTA 2? Я знаю, что GTA 2 полностью 2D, и домики рисуются какой-то сложной техникой (без использования 3D-ускорителя), но не понимаю, какой. Неужели прямо на процессоре рендерили?.. Хочется сделать что-то похожее, но 3D графика слишком сложная - я могу рисовать домики с помощью OpenGL 1.1, но шейдеры мне не понять. Подскажите что-нибудь на эту тему.
Кроме того, как лучше реализовать физику в стиле GTA 2? Я кое-как сделал физику кругов на плоскости, но так и не смог реализовать правильные отскоки (не знаю, как посчитать вектор отскока без использования сложных вычислений). А с прямоугольниками вообще непонятно что делать. И как быть с разными уровнями карты (в GTA 2 есть дороги под наклоном и даже лестницы)...
Кроме того, как лучше реализовать физику в стиле GTA 2? Я кое-как сделал физику кругов на плоскости, но так и не смог реализовать правильные отскоки (не знаю, как посчитать вектор отскока без использования сложных вычислений). А с прямоугольниками вообще непонятно что делать. И как быть с разными уровнями карты (в GTA 2 есть дороги под наклоном и даже лестницы)...
>>692837
Это если все линковать в один бинарник. А если делать длл то все что экспортируется, то не выкинется.
Это если все линковать в один бинарник. А если делать длл то все что экспортируется, то не выкинется.
>>693045
Зачем делать длл с движком? DLL нужно только в двух случаях - когда функции DLL используются несколькими независимыми программами (изначальный замысел DLL, сегодня с ростом объёмов памяти это неактуально), или когда функции DLL нужно вызывать из кода на другом языке, но мы же тут пишем свои игры на своём движке, т.е. и игра, и движок на одном языке. Ещё по идее на неё немного другие лицензионные блаблабла, но лицензионный бред оставьте лицензионным бредологам. Ненавижу опенсурс за то, что приходится разбираться в лицензиях, тысячах лицензий!
Зачем делать длл с движком? DLL нужно только в двух случаях - когда функции DLL используются несколькими независимыми программами (изначальный замысел DLL, сегодня с ростом объёмов памяти это неактуально), или когда функции DLL нужно вызывать из кода на другом языке, но мы же тут пишем свои игры на своём движке, т.е. и игра, и движок на одном языке. Ещё по идее на неё немного другие лицензионные блаблабла, но лицензионный бред оставьте лицензионным бредологам. Ненавижу опенсурс за то, что приходится разбираться в лицензиях, тысячах лицензий!
>>692917
Ничего там сложного нет, простейшая система диффуров - второй закон Ньютона да закон сохранения импульса.
> не знаю, как посчитать вектор отскока без использования сложных вычислений
Ничего там сложного нет, простейшая система диффуров - второй закон Ньютона да закон сохранения импульса.
>>693059
Единственная лицензия, о которой как программисту приходится задумываться, это (L)GPL. Окей, две лицензии. Все остальные по сути означают "бери и пользуйся на здоровье, никто тебе ни слова ни скажет".
> Ненавижу опенсурс за то, что приходится разбираться в лицензиях, тысячах лицензий!
Единственная лицензия, о которой как программисту приходится задумываться, это (L)GPL. Окей, две лицензии. Все остальные по сути означают "бери и пользуйся на здоровье, никто тебе ни слова ни скажет".
>>693107
Из курса математики я выпал примерно в 8-9-м классе, в 10-11 мне ставили тройки за красивые глаза...
>>693112
Если б всё так просто было. Нужно ведь ещё авторов указать (или не нужно), текст лицензии приложить (или не нужно) в каком-то определённом формате (или неопределённом), ссылку на оригинал дать (или не давать), указать список изменений (или не указывать)... Ну уж нет, лучше я напишу велосипед или совсем программирование брошу, чем буду насиловать себе мозг такими бессмысленными деталями. Вот как хорошо было бы, если бы были только собственнические лицензии - ты ничей код использовать не можешь, сидишь себе велосипед попиливаешь, но велосипед этот 100% твой, никто у тебя его отобрать не может и засудить на огромные бабки за разработку этого велосипеда тоже не может... Да, медленно, да, долго, зато безопасно и надёжно, т.к. варианты исхода известны (ты либо напишешь велосипед и получишь профит, либо не напишешь и не получишь, а не как с использованием чего-либо стороннего - подключил либу и дальше тебя ждёт неизвестно что).
>система диффуров
Из курса математики я выпал примерно в 8-9-м классе, в 10-11 мне ставили тройки за красивые глаза...
>>693112
>бери и пользуйся
Если б всё так просто было. Нужно ведь ещё авторов указать (или не нужно), текст лицензии приложить (или не нужно) в каком-то определённом формате (или неопределённом), ссылку на оригинал дать (или не давать), указать список изменений (или не указывать)... Ну уж нет, лучше я напишу велосипед или совсем программирование брошу, чем буду насиловать себе мозг такими бессмысленными деталями. Вот как хорошо было бы, если бы были только собственнические лицензии - ты ничей код использовать не можешь, сидишь себе велосипед попиливаешь, но велосипед этот 100% твой, никто у тебя его отобрать не может и засудить на огромные бабки за разработку этого велосипеда тоже не может... Да, медленно, да, долго, зато безопасно и надёжно, т.к. варианты исхода известны (ты либо напишешь велосипед и получишь профит, либо не напишешь и не получишь, а не как с использованием чего-либо стороннего - подключил либу и дальше тебя ждёт неизвестно что).
>>693190
Наверняка в гугле есть удобная таблица, в которую сведены все особенности свободных лицензий. Но мне влом её искать за тебя.
> Если б всё так просто было.
Наверняка в гугле есть удобная таблица, в которую сведены все особенности свободных лицензий. Но мне влом её искать за тебя.
>>693190
Всё это хуйня. Просто тебе нужны лицензии полностью свободные - BSD. Всё остальное можешь пропускать мимо.
> Если б всё так просто было. Нужно ведь ещё авторов указать (или не нужно), текст лицензии приложить (или не нужно) в каком-то определённом формате (или неопределённом), ссылку на оригинал дать (или не давать), указать список изменений (или не указывать)... Ну уж нет, лучше я напишу велосипед или совсем программирование брошу, чем буду насиловать себе мозг такими бессмысленными деталями.
Всё это хуйня. Просто тебе нужны лицензии полностью свободные - BSD. Всё остальное можешь пропускать мимо.
>>693204
Да, есть: https://tldrlegal.com
>>693206
Ты не понимаешь, о чём говоришь. MIT, например (которая на самом деле не MIT, а X11/Expat), ещё "свободнее", чем BSD (трёхпунктная, по крайней мере) - тупо меньше условий в тексте лицензии.
Да, есть: https://tldrlegal.com
>>693206
Ты не понимаешь, о чём говоришь. MIT, например (которая на самом деле не MIT, а X11/Expat), ещё "свободнее", чем BSD (трёхпунктная, по крайней мере) - тупо меньше условий в тексте лицензии.
297 Кб, 1200x1500>>693233
Самая свободная вот http://www.wtfpl.net/ (способ отдать работу в общественное достояние)
Но я лично не хочу вкладывать в свой софт файл с чужим именем (почему я вообще должен давать ссылку на какого-то Сэма?). И что значит "changing it is allowed as long as the name is changed"? Как вообще возможно закопирайтить такой огрызок текста? Получается, не может существовать WTFPL-лицензии с другим текстом, потому что изменяя текст, меняется и название? Бред какой-то. Даже в писательстве и кинематографе нет такого строгого ограничения на совпадающие имена... Короче, не хочется лезть в это дерьмо, ни как лицензиат, ни как лицензиар, а то вдруг засудят.
О, представьте, что вы собираете движок из готовых библиотек, библиотеки линкуете статически, результатом выходит один-единственный exe (как у годота). В итоге у вас в папке \движок\ будет один файл движка и несколько десятков файлов лицензий. Почему не объединить в один файл или не зашить прямо в exe? Потому что "менять текст лицензии нельзя" (конкатенация = изменение; перекодирование, кстати, тоже изменение) и потому что "текст лицензии должен быть доступен без запуска приложения", то есть по факту тот же готот нарушает условия лицензирования (запечатывает лицензию внутри exe и не содержит копии в txt-файле). Бред какой-то, ну нафиг такое.
Самая свободная вот http://www.wtfpl.net/ (способ отдать работу в общественное достояние)
Но я лично не хочу вкладывать в свой софт файл с чужим именем (почему я вообще должен давать ссылку на какого-то Сэма?). И что значит "changing it is allowed as long as the name is changed"? Как вообще возможно закопирайтить такой огрызок текста? Получается, не может существовать WTFPL-лицензии с другим текстом, потому что изменяя текст, меняется и название? Бред какой-то. Даже в писательстве и кинематографе нет такого строгого ограничения на совпадающие имена... Короче, не хочется лезть в это дерьмо, ни как лицензиат, ни как лицензиар, а то вдруг засудят.
О, представьте, что вы собираете движок из готовых библиотек, библиотеки линкуете статически, результатом выходит один-единственный exe (как у годота). В итоге у вас в папке \движок\ будет один файл движка и несколько десятков файлов лицензий. Почему не объединить в один файл или не зашить прямо в exe? Потому что "менять текст лицензии нельзя" (конкатенация = изменение; перекодирование, кстати, тоже изменение) и потому что "текст лицензии должен быть доступен без запуска приложения", то есть по факту тот же готот нарушает условия лицензирования (запечатывает лицензию внутри exe и не содержит копии в txt-файле). Бред какой-то, ну нафиг такое.
>>693236
Потому что ты используешь труд другого человека, и публично признать, что ты это делаешь - это самое меньшее, что ты можешь сделать. Обрати внимание, тебя не просят за его труд отдавать деньги, тебя просто просят сказать "да, я использовал труд Сэма", просто чтобы ему было приятно. Твой подход к этому вопросу выдаёт в тебе малолетнюю свинью - тебе бесплатно дают крутые вещи, а ты хочешь их брать и взамен не отдавать вообще ничего.
Разумеется. Представь себе, что я возьму текст GPL, напишу в нём "ты сосёшь хуи" и буду распространять свой софт по этой лицензии, и внезапно масса людей оказываются ни за что ни про что зашкваренными.
> Но я лично не хочу вкладывать в свой софт файл с чужим именем (почему я вообще должен давать ссылку на какого-то Сэма?
Потому что ты используешь труд другого человека, и публично признать, что ты это делаешь - это самое меньшее, что ты можешь сделать. Обрати внимание, тебя не просят за его труд отдавать деньги, тебя просто просят сказать "да, я использовал труд Сэма", просто чтобы ему было приятно. Твой подход к этому вопросу выдаёт в тебе малолетнюю свинью - тебе бесплатно дают крутые вещи, а ты хочешь их брать и взамен не отдавать вообще ничего.
> Получается, не может существовать WTFPL-лицензии с другим текстом, потому что изменяя текст, меняется и название?
Разумеется. Представь себе, что я возьму текст GPL, напишу в нём "ты сосёшь хуи" и буду распространять свой софт по этой лицензии, и внезапно масса людей оказываются ни за что ни про что зашкваренными.
> несколько десятков файлов лицензий
>>693242
Ёбаный рот, с каких пор на двачах по Ctrl-enter отправка?
Так вот,
>>693236
Необязательно лицензии в отдельные файлы складывать, можно заставлять тикнуть чекбокс "да, я в курсе про лицензии" при загрузке, можно показывать license agreement в инсталляторе, можно в сплэш-скрине одной строчкой, мол, this software uses libblah library which is MIT-licensed, see https://github.com/libblah/LICENSE for details. Тут возможны варианты.
Да нет, просто ты малолетний долбоёб-неосилятор.
Ёбаный рот, с каких пор на двачах по Ctrl-enter отправка?
Так вот,
>>693236
> несколько десятков файлов лицензий
Необязательно лицензии в отдельные файлы складывать, можно заставлять тикнуть чекбокс "да, я в курсе про лицензии" при загрузке, можно показывать license agreement в инсталляторе, можно в сплэш-скрине одной строчкой, мол, this software uses libblah library which is MIT-licensed, see https://github.com/libblah/LICENSE for details. Тут возможны варианты.
> Бред какой-то, ну нафиг такое.
Да нет, просто ты малолетний долбоёб-неосилятор.
>>693233
Прекрасно понимаю. Бсд и мит просто обычные свободные лицухи с тремя-двумя пунктами, для дэбилов.
>>693236
Не с чужим именем, а лицинезией и с выполнением условий лицензии. Чужое имя это условие лицензии.
Да. Лицензия защищает саму себя, в этом суть лицензий тащемта. Лицензия это как бы программный код исполняемый судами и юристами, ты записываешь в лицензии определённое поведение.
Это не бред, это необходимо для выполнение условий определённого поведения. Ты программист вообще или кто нахуй?
Нарушать лицензирования можно, но только БСД лицензий, потому что нужно выявить нарушение - чтобы истец предъявлял требования. БСД-подобные лицензии предъявлять тебе что-то там не будут.
Нет, бред это делать велосипед, когда есть bgfx.
> Ты не понимаешь, о чём говоришь.
Прекрасно понимаю. Бсд и мит просто обычные свободные лицухи с тремя-двумя пунктами, для дэбилов.
>>693236
> Но я лично не хочу вкладывать в свой софт файл с чужим именем
Не с чужим именем, а лицинезией и с выполнением условий лицензии. Чужое имя это условие лицензии.
> Получается, не может существовать WTFPL-лицензии с другим текстом
Да. Лицензия защищает саму себя, в этом суть лицензий тащемта. Лицензия это как бы программный код исполняемый судами и юристами, ты записываешь в лицензии определённое поведение.
> потому что изменяя текст, меняется и название? Бред какой-то.
Это не бред, это необходимо для выполнение условий определённого поведения. Ты программист вообще или кто нахуй?
> по факту тот же готот нарушает условия лицензирования (запечатывает лицензию внутри exe и не содержит копии в txt-файле).
Нарушать лицензирования можно, но только БСД лицензий, потому что нужно выявить нарушение - чтобы истец предъявлял требования. БСД-подобные лицензии предъявлять тебе что-то там не будут.
> Бред какой-то, ну нафиг такое.
Нет, бред это делать велосипед, когда есть bgfx.
>>693254
Пиздец, у тебя русский - не родной язык, что ли?
Да ещё и с биполярочкой.
>Нарушать лицензирования можно, но только БСД лицензий, потому что нужно выявить нарушение - чтобы истец предъявлял требования
Пиздец, у тебя русский - не родной язык, что ли?
> Просто тебе нужны лицензии полностью свободные - BSD
> для дэбилов
Да ещё и с биполярочкой.
>>693242
Да, а если я сделаю квадрат с чёрной заливкой, должен сделать ссылку на Малевича за такую крутую вещь, как чёрный квадрат.
И всё правильно сделаешь. Твой GPL <> GPL Васи Пупкина <> GPL Маши Петровой <> GPL Ивана Иванова. Читай текст, а не название!
>>693243
Я где-то читал, что обязательно. Потому что, мол, программа может оказаться на машине, которая не может запустить программу.
А если линк протухнет? Спустя лет 10 либо страницу с гитхаба потрут, либо гитхаб закроется, либо ещё чего. А файлы-то останутся...
Пофиксил за тебя.
>>693254
О, спасибо, единственное разумное объяснение смысла лицензий. Вот только учитывая багнутость и уязвимость судов, нестабильность и неэффективность юристов, смысла их программировать нет, лучше выкинуть на свалку истории (или в музей машин прошлого) и заменить более надёжными и эффективными машинами... Это всё равно что программировать сегодня под какой-нибудь компьютер из первой половины прошлого века - можно, но зачем?.. ...так, падажжи, эта аналогия зашла слишком далеко.
Но если я не сделаю велосипед, то чем я смогу гордиться? Тем, что нажал кнопочку "сделать зашибись" на чужом изобретении?
>тебе бесплатно дают крутые вещи
>крутые вещи
>текст лицензии, состоящий только из
>0. You just DO WHAT THE FUCK YOU WANT TO.
Да, а если я сделаю квадрат с чёрной заливкой, должен сделать ссылку на Малевича за такую крутую вещь, как чёрный квадрат.
>Представь себе, что я возьму текст GPL, напишу в нём "ты сосёшь хуи" и буду распространять свой софт по этой лицензии
И всё правильно сделаешь. Твой GPL <> GPL Васи Пупкина <> GPL Маши Петровой <> GPL Ивана Иванова. Читай текст, а не название!
>>693243
>Необязательно лицензии в отдельные файлы складывать
Я где-то читал, что обязательно. Потому что, мол, программа может оказаться на машине, которая не может запустить программу.
>see https://github.com/libblah/LICENSE for details
А если линк протухнет? Спустя лет 10 либо страницу с гитхаба потрут, либо гитхаб закроется, либо ещё чего. А файлы-то останутся...
>Да нет, просто ты долбоёб-неосилятор.
Пофиксил за тебя.
>>693254
>Лицензия это как бы программный код исполняемый судами и юристами, ты записываешь в лицензии определённое поведение.
О, спасибо, единственное разумное объяснение смысла лицензий. Вот только учитывая багнутость и уязвимость судов, нестабильность и неэффективность юристов, смысла их программировать нет, лучше выкинуть на свалку истории (или в музей машин прошлого) и заменить более надёжными и эффективными машинами... Это всё равно что программировать сегодня под какой-нибудь компьютер из первой половины прошлого века - можно, но зачем?.. ...так, падажжи, эта аналогия зашла слишком далеко.
>Нет, бред это делать велосипед
Но если я не сделаю велосипед, то чем я смогу гордиться? Тем, что нажал кнопочку "сделать зашибись" на чужом изобретении?
>>693283
Не забудь сделать свою ОС, чтобы Гейтс у тебя славу не украл.
>Но если я не сделаю велосипед, то чем я смогу гордиться? Тем, что нажал кнопочку "сделать зашибись" на чужом изобретении?
Не забудь сделать свою ОС, чтобы Гейтс у тебя славу не украл.
>>693257
Он прямой, не пизди. Одна из самых прямых либ.
>>693272
Ну и что это ты высрал? А главное, зачем?
>>693283
Так говорю же - доказательство нарушения лицензии (или хотя бы инициировать проверку) должен предъявлять истец. В случае бсд никто не будет этим заниматься.
Скорее просто как под язык с тысячами возможностей неопределённого поведения.
Компухтер из первой половины прошлого века всё же имел вполне определённое поведение.
Ты не сможешь в полной мере гордится велосипедом. Это же велосипед. Он ничего нового не приносит, ничего нового не создает. Можешь статью написать, но статей с описанием велосипедов дохуя уже. Может ты что-то и поймешь новое, при создании велосипеда. Но вряд ли.
А вот если ты сделаешь что-то реально полезное, то чего нет, то что никто до тебя не делал. У тебя не только повод для гордости будет.
Он прямой, не пизди. Одна из самых прямых либ.
>>693272
Ну и что это ты высрал? А главное, зачем?
>>693283
> Вот только учитывая багнутость и уязвимость судов, нестабильность и неэффективность юристов,
Так говорю же - доказательство нарушения лицензии (или хотя бы инициировать проверку) должен предъявлять истец. В случае бсд никто не будет этим заниматься.
> компьютер из первой половины прошлого века - можно, но зачем?
Скорее просто как под язык с тысячами возможностей неопределённого поведения.
Компухтер из первой половины прошлого века всё же имел вполне определённое поведение.
> Но если я не сделаю велосипед, то чем я смогу гордиться? Тем, что нажал кнопочку "сделать зашибись" на чужом изобретении?
Ты не сможешь в полной мере гордится велосипедом. Это же велосипед. Он ничего нового не приносит, ничего нового не создает. Можешь статью написать, но статей с описанием велосипедов дохуя уже. Может ты что-то и поймешь новое, при создании велосипеда. Но вряд ли.
А вот если ты сделаешь что-то реально полезное, то чего нет, то что никто до тебя не делал. У тебя не только повод для гордости будет.
Если б хоть один из вас, срущихся ИТТ, действительно делал свой движок.. Или хотя бы собирался его делать.
Но ведь нет же. Вместо этого новый тип срача изобрести решили. Лицензиосрач.
Этот тред просто попытка протечь из срачезагона..
Но ведь нет же. Вместо этого новый тип срача изобрести решили. Лицензиосрач.
Этот тред просто попытка протечь из срачезагона..
>>693568
Срач про лицензии -- одна из самых унылых вещей, которые я когда-либо читал. А начинался тред неплохо.
Срач про лицензии -- одна из самых унылых вещей, которые я когда-либо читал. А начинался тред неплохо.
>>693568
Прежде чем начать делать движок, надо определиться с лицензией.
Прежде чем начать делать движок, надо определиться с лицензией.
>>693680
с гендером ещё надо определиться
с гендером ещё надо определиться
>>693680
Есть только одна православно верная опенсурс лицензия - CC0.
Остальные - виляние жопой - типа хочу быть свободным, но чтобы никто не украл мое авторство (а это не свободное).
Херня это, кому надо и так нарушит и плевал на писульку в файле License, достаточно обфуцировать код и никто не докажет что там было - mit или gpl (если не майкрософт и не эпл, то никто даже и не будет пытаться)
Есть только одна православно верная опенсурс лицензия - CC0.
Остальные - виляние жопой - типа хочу быть свободным, но чтобы никто не украл мое авторство (а это не свободное).
Херня это, кому надо и так нарушит и плевал на писульку в файле License, достаточно обфуцировать код и никто не докажет что там было - mit или gpl (если не майкрософт и не эпл, то никто даже и не будет пытаться)
>>693568
Я делаю. Но мимо детей-максималистов пройти мимо не могу.
> Если б хоть один из вас, срущихся ИТТ, действительно делал свой движок
Я делаю. Но мимо детей-максималистов пройти мимо не могу.
>>693907
Вот этот малолетний долбоёб, например: не понимает разницу между авторскими и исключительными правами, но Мнение Имеет.
Вот этот малолетний долбоёб, например: не понимает разницу между авторскими и исключительными правами, но Мнение Имеет.
>>693929
Какая разница? Все эти якобы попенсурсные лицензии имеют ограничения - например надо обязательно указывать авторство оригинала.
CC0 же в свою очередь полный отказ от всех прав и передача в общественное пользование - поэтому не ибет, авторские, исключительные или еще какие либо..
И да, мой код я всегда выкладываю под СС0.
Какая разница? Все эти якобы попенсурсные лицензии имеют ограничения - например надо обязательно указывать авторство оригинала.
CC0 же в свою очередь полный отказ от всех прав и передача в общественное пользование - поэтому не ибет, авторские, исключительные или еще какие либо..
И да, мой код я всегда выкладываю под СС0.
>>693965
Учитывая твой психологический возраст, твой код нахуй никому не нужен.
> И да, мой код я всегда выкладываю под СС0.
Учитывая твой психологический возраст, твой код нахуй никому не нужен.
>>693907
>>693680
Можно для себя писать.
Для самого себя лицензия не нужна.
Вероятность что твой код заинтересует кого-то другого примерно равна вероятности стать космонавтом. В эпоху-то юнити и анриалов с гейммейкерами.
Так что вы аноны зря о лицензиях вообще думаете.
>Есть только одна православно верная опенсурс лицензия
>>693680
>Прежде чем начать делать движок, надо определиться с лицензией.
Можно для себя писать.
Для самого себя лицензия не нужна.
Вероятность что твой код заинтересует кого-то другого примерно равна вероятности стать космонавтом. В эпоху-то юнити и анриалов с гейммейкерами.
Так что вы аноны зря о лицензиях вообще думаете.
>>693999
Ну да - типикал двачер
>Учитывая твой психологический возраст, твой код нахуй никому не нужен.
Ну да - типикал двачер
8 Кб, 286x164>>694468
и меня
и меня
>>693680
Главное не вляпаться в GPL. А то когда вам принесут денюшку, будете страдать. Вот как они
https://github.com/TurningWheel/Barony/pull/521
Хотя в их случае то понятно, barony так-то коммерческая игра, поэтому вляпали gpl , как Кармак думы с квайками выкладывал.
Но как начали делать порт под nintendo, так "свободная" лицензия сказала "хуй вам".
Главное не вляпаться в GPL. А то когда вам принесут денюшку, будете страдать. Вот как они
https://github.com/TurningWheel/Barony/pull/521
Хотя в их случае то понятно, barony так-то коммерческая игра, поэтому вляпали gpl , как Кармак думы с квайками выкладывал.
Но как начали делать порт под nintendo, так "свободная" лицензия сказала "хуй вам".
>>694927
Если в твой код никто другой не контрибьютит, вообще не важно какая у твоего кода лицензия, ты обладаешь всеми правами и можешь менять лицензии, закрывать код, выпускать под GPL и продавать коммерческие лицензии.
Можешь вообще никакой лицензии не указывать (это означает что на твой код можно смотреть, но нельзя использовать).
Если в твой код никто другой не контрибьютит, вообще не важно какая у твоего кода лицензия, ты обладаешь всеми правами и можешь менять лицензии, закрывать код, выпускать под GPL и продавать коммерческие лицензии.
Можешь вообще никакой лицензии не указывать (это означает что на твой код можно смотреть, но нельзя использовать).
>>694927
"Хуй вам" сказал коммерческий отдел Nintendo, а не свободная лицензия. Не нужно очеловечивать свободные лицензии, они этого очень не любят)))
>Но как начали делать порт под nintendo, так "свободная" лицензия сказала "хуй вам".
"Хуй вам" сказал коммерческий отдел Nintendo, а не свободная лицензия. Не нужно очеловечивать свободные лицензии, они этого очень не любят)))
>>695990
Только вот будешь вместо игры пердолиться с костылями движка. Особенно если твоя игра - что-то сложнее ангриберда
Только вот будешь вместо игры пердолиться с костылями движка. Особенно если твоя игра - что-то сложнее ангриберда
>>696046
Пуки гринтекстом.
Пуки гринтекстом.
Накидывайте годные ссылки для первопоста, у кого что есть
Чо там, тред то живой еще? Я нуфаня, вот потихоньку вкатываюсь в это дерьмо. Простой вопрос. Есть main loop, в нем происходит рендер и собственно обработка нажатия клавиш. Каждый ебаный цикл, естественно. Типо, я нажал клавишу влево и персонаж сдвинулся влево на одну клетку. Вроде все хорошо, но даже если я быстро по клавише щелкну, у меня цикл успеет итераций сто сделать, соответственно персонаж сдвинется на сто клеток влево, как фиксить?
Далее, блет. Как вообще идет игра? Ну, допустим, для простоты 2д какое-нибудь. Берем террарию, тут вроде очевидно, что за ширмой весь этот мир - это обычный массив и вся игра проходит в этом массиве, блоки двигаются, с персонажами - меняют ячейки массива, а рендер просто этот массив визуализирует, ну или тетрис - та же схема. Хотя с террарией не ясно немного, как персонаж занимает стоит на границе двух блоков - посередине, в тетрисе же четко на одну ячейку сдвигается. Возьмем какую-нибудь хотлайн майами, а тут как? Тут уже вроде как не подходит массив, тогда что?
>>697045
Ты описал самый простой вариант. С которого можно начать.
Но в идеале конечно всё намного сложнее.
Нажатия клавишь запоминай отдельно. Делаешь флаги для каждой, со статусами типа "сейчас нажата" и другими.
Действия персонажа это другая система. Есть несколько общих решений как привязывать действия ко времени, но концептуально ты либо вызываешь действие один раз за отрисовку, передавая дельту времени, либо вызываешь действие различное количество раз за кадр. Где количество вызовов отражает подстройку под текущий фпс игры.
Вообще не пытайся всё сразу.
Начни с малого. Например научись точно ограничивать фпс игры. Научись таймер точный юзать.
Ты описал самый простой вариант. С которого можно начать.
Но в идеале конечно всё намного сложнее.
Нажатия клавишь запоминай отдельно. Делаешь флаги для каждой, со статусами типа "сейчас нажата" и другими.
Действия персонажа это другая система. Есть несколько общих решений как привязывать действия ко времени, но концептуально ты либо вызываешь действие один раз за отрисовку, передавая дельту времени, либо вызываешь действие различное количество раз за кадр. Где количество вызовов отражает подстройку под текущий фпс игры.
Вообще не пытайся всё сразу.
Начни с малого. Например научись точно ограничивать фпс игры. Научись таймер точный юзать.
>>697045
Через дельтатайм. Короче, суть такая - замеряешь время которое у тебя тратится на один кадр и умножаешь на скорость движения.
гугли main loop delta time
>на сто клеток влево, как фиксить?
Через дельтатайм. Короче, суть такая - замеряешь время которое у тебя тратится на один кадр и умножаешь на скорость движения.
гугли main loop delta time
>>697045
вот тут хороший пример
https://codeincomplete.com/articles/javascript-game-foundations-the-game-loop/
Чтобы перс не телепортился, нужно либо уменьшать скорость движения до дробных чисел( типа 0.001), либо делать паузы между движением (если это пошаговое). Дельта-тайм же гарантирует что движение не будет зависеть от фпс
вот тут хороший пример
https://codeincomplete.com/articles/javascript-game-foundations-the-game-loop/
Чтобы перс не телепортился, нужно либо уменьшать скорость движения до дробных чисел( типа 0.001), либо делать паузы между движением (если это пошаговое). Дельта-тайм же гарантирует что движение не будет зависеть от фпс
>>697047
Тут есть несколько подходов. Для тетриса или рогалика достаточно двухмерного массива.
Еще вместо клеток юзают шестиграники (например в героях меча и магии)
Еще клетки могут быть мелкими - например так было в warcraft 2 - вся карта разбита на клетки, но они маленькие, из-за чего создается ощущение плавного движения, хотя на самом деле там движение по клеткам.
Еще есть вариант - смещения между клетками - мир разбит на клетки, но есть анимация перемещения из одной клетки в другую (при этом нельзя встать между клетками) - так сделано в рпг макере
В случае же платформеров делают по другому - любой объект имеет объем/форму, и просто зная курс геометрии мы можем узнать попадание объема игрока в объем земли, и в соответствии этого делаем реакцию - например не даем проваливаться игроку сквозь платформу.
Гуглить коллизии (collision), можно посмотреть на box2d - это двухмерная физика, она обычно не нужна для простых игр, но просто позволит понять как это делается. Или в ютубе поискать ролики по платформерам в юнити (это не рекомендация брать юнити - на готовом движке можно увидеть суть не отвлекаясь на всякие мелкие детали)
>Тут уже вроде как не подходит массив, тогда что?
Тут есть несколько подходов. Для тетриса или рогалика достаточно двухмерного массива.
Еще вместо клеток юзают шестиграники (например в героях меча и магии)
Еще клетки могут быть мелкими - например так было в warcraft 2 - вся карта разбита на клетки, но они маленькие, из-за чего создается ощущение плавного движения, хотя на самом деле там движение по клеткам.
Еще есть вариант - смещения между клетками - мир разбит на клетки, но есть анимация перемещения из одной клетки в другую (при этом нельзя встать между клетками) - так сделано в рпг макере
В случае же платформеров делают по другому - любой объект имеет объем/форму, и просто зная курс геометрии мы можем узнать попадание объема игрока в объем земли, и в соответствии этого делаем реакцию - например не даем проваливаться игроку сквозь платформу.
Гуглить коллизии (collision), можно посмотреть на box2d - это двухмерная физика, она обычно не нужна для простых игр, но просто позволит понять как это делается. Или в ютубе поискать ролики по платформерам в юнити (это не рекомендация брать юнити - на готовом движке можно увидеть суть не отвлекаясь на всякие мелкие детали)
>>697184
Эммм, я хз как там на ассемблере, конечно, но вроде на любом нормальном языке есть события press_down, press_up и тп
И как это сделать?
>Делаешь флаги для каждой, со статусами типа "сейчас нажата" и другими.
Эммм, я хз как там на ассемблере, конечно, но вроде на любом нормальном языке есть события press_down, press_up и тп
>Например научись точно ограничивать фпс игры. Научись таймер точный юзать.
И как это сделать?
>>697196
Так кадры разные могут быть же. Один 12мс а другой писят
>Короче, суть такая - замеряешь время которое у тебя тратится на один кадр и умножаешь на скорость движения.
Так кадры разные могут быть же. Один 12мс а другой писят
>>697197
Хуйня из под коня, на разных машинах по разному будет, у меня, допустим, рендерится 150 кадров в секунду, а у другого человека 24 и чо, у меня же преимущество будет, скорость движения будет различаться
>Чтобы перс не телепортился, нужно либо уменьшать скорость движения до дробных чисел( типа 0.001)
Хуйня из под коня, на разных машинах по разному будет, у меня, допустим, рендерится 150 кадров в секунду, а у другого человека 24 и чо, у меня же преимущество будет, скорость движения будет различаться
>>697198
Не охото ругаться, но ты адекватен, вообще? Программировал когда-нибудь? Какие нахуй шестигранники в коде? Покажи мне код, который шестигранниками оперирует - массив это просто квадрат ячеек по сути
За это спасибо большое, погляжу на досуге
>Еще вместо клеток юзают шестиграники (например в героях меча и магии)
Не охото ругаться, но ты адекватен, вообще? Программировал когда-нибудь? Какие нахуй шестигранники в коде? Покажи мне код, который шестигранниками оперирует - массив это просто квадрат ячеек по сути
>Гуглить коллизии (collision), можно посмотреть на box2d - это двухмерная физика, она обычно не нужна для простых игр, но просто позволит понять как это делается. Или в ютубе поискать ролики по платформерам в юнити
За это спасибо большое, погляжу на досуге
>>697254
нихуя ты дебил поехавший.
просишь совета, а говоришь как скотина, ругаться неохота хуесосу
тебе сказали что шестигранники в игре, ты в глаза долбишься? какой массив?
нихуя ты дебил поехавший.
просишь совета, а говоришь как скотина, ругаться неохота хуесосу
тебе сказали что шестигранники в игре, ты в глаза долбишься? какой массив?
>>697291
Покажи мне реалиацию шестигранников не на массивах, пидор ебаный, ну, давай
Покажи мне реалиацию шестигранников не на массивах, пидор ебаный, ну, давай
>>697294
кто пидор, ты пидор ёпта
ещё и тупой
тебе блядь никто вообще про реализацию слова не сказал, осёл
кто пидор, ты пидор ёпта
ещё и тупой
тебе блядь никто вообще про реализацию слова не сказал, осёл
>>697294
он же блядь тебе пишет, еблан
первый вариант - массивы
и перечисляет примеры
потом второй вариант - смещения
итд
он же блядь тебе пишет, еблан
первый вариант - массивы
и перечисляет примеры
потом второй вариант - смещения
итд
>>697298
себе поссы, чмо тупое
себе поссы, чмо тупое
>>697252
>>697253
Для этого и нужно чтобы ты изучил термин delta time.
смотри. у тебя 60 фпс. это 16 мс на кадр.
Умножаешь скорость 10 на 16 = двигаешь на 160
У тебя 120 фпс. это 8 мс на кадр. умножаешь 10 на 8 - двигаешь на 80. То есть у тебя в два раза больше кадров, поэтому ты двигаешь меньше. Если кадров меньше, то двигаешь больше.
>Один 12мс а другой писят
>>697253
>рендерится 150 кадров в секунду, а у другого человека 24 и чо
Для этого и нужно чтобы ты изучил термин delta time.
смотри. у тебя 60 фпс. это 16 мс на кадр.
Умножаешь скорость 10 на 16 = двигаешь на 160
У тебя 120 фпс. это 8 мс на кадр. умножаешь 10 на 8 - двигаешь на 80. То есть у тебя в два раза больше кадров, поэтому ты двигаешь меньше. Если кадров меньше, то двигаешь больше.
35 Кб, 375x407>>697254
А кроме массивов ничего больше нет? Например списки? Деревья?
вот случайный пример про шестигранники - https://github.com/chenjie199234/HexagonMap
Тебе с таким подходом будет очень тяжело если захочется что-то про не евклидову геометрию, где в принципе вся логика ломается
>Не охото ругаться, но ты адекватен, вообще? Программировал когда-нибудь? Какие нахуй шестигранники в коде?
А кроме массивов ничего больше нет? Например списки? Деревья?
вот случайный пример про шестигранники - https://github.com/chenjie199234/HexagonMap
Тебе с таким подходом будет очень тяжело если захочется что-то про не евклидову геометрию, где в принципе вся логика ломается
>>697251
Это события не языка, а операционки. Она эти события тебе передаёт. А сохранять статусы клавишь надо, чтобы ты мог их юзать из любого места твоей программы.
Если ты прямо в коллбэке где получаешь нажатие "стрелочки влево" начнёшь писать код движения персонажа влево, то далеко так не уедешь. Впрочем, для первого теста работоспособности сойдёт.
Разве не очевидно? Чекаешь таймер в главном цикле игры, если с момента отрисовки прошлого кадра уже прошла 1/60 секунды, то вызываешь новую отрисовку кадра.
>но вроде на любом нормальном языке есть события press_down, press_up и тп
Это события не языка, а операционки. Она эти события тебе передаёт. А сохранять статусы клавишь надо, чтобы ты мог их юзать из любого места твоей программы.
Если ты прямо в коллбэке где получаешь нажатие "стрелочки влево" начнёшь писать код движения персонажа влево, то далеко так не уедешь. Впрочем, для первого теста работоспособности сойдёт.
>научись точно ограничивать фпс игры. Научись таймер точный юзать.
>И как это сделать?
Разве не очевидно? Чекаешь таймер в главном цикле игры, если с момента отрисовки прошлого кадра уже прошла 1/60 секунды, то вызываешь новую отрисовку кадра.
>>697302
Произвольная дельта в вызовах физики иногда приводит к проблемам. И вообще требует более внимательной реализации, это доп-нагрузка на кодера.
Схема с фиксированной дельтой считается более простой в написании и более надёжной.
Ставишь фиксированную дельту к примеру на 2 мс, тогда при 60фпс будешь вызывать физон 8 раз за кадр, а при 120фпс вызываешь 4 раза за кадр.
Однако, затраты процессорного времени у такого решения выше.
Просто для уточнения возможных вариантов пишу.
Произвольная дельта в вызовах физики иногда приводит к проблемам. И вообще требует более внимательной реализации, это доп-нагрузка на кодера.
Схема с фиксированной дельтой считается более простой в написании и более надёжной.
Ставишь фиксированную дельту к примеру на 2 мс, тогда при 60фпс будешь вызывать физон 8 раз за кадр, а при 120фпс вызываешь 4 раза за кадр.
Однако, затраты процессорного времени у такого решения выше.
Просто для уточнения возможных вариантов пишу.
>>697304
Пойди дальше. Посмотри на эту пикчу и мысленно распрями боковые рёбра шестиугольников в ровные линии. Что получится?
Ответ на обороте страницы:
Прямоугольная сетка со сдвинутыми на 1/2 столбцами.
Пойди дальше. Посмотри на эту пикчу и мысленно распрями боковые рёбра шестиугольников в ровные линии. Что получится?
Ответ на обороте страницы:
Прямоугольная сетка со сдвинутыми на 1/2 столбцами.
>>697391
В общем, делаю так - при нажатии клавишы ее id сбрасывается в список нажатых клавиш, но перед тем как туда его сбросить сам список чекается, не была ли уже нажата эта клавиша. Типо, так?
>А сохранять статусы клавишь надо, чтобы ты мог их юзать из любого места твоей программы.
>
>Если ты прямо в коллбэке где получаешь нажатие "стрелочки влево" начнёшь писать код движения персонажа влево, то далеко так не уедешь. Впрочем, для первого теста работоспособности сойдёт.
В общем, делаю так - при нажатии клавишы ее id сбрасывается в список нажатых клавиш, но перед тем как туда его сбросить сам список чекается, не была ли уже нажата эта клавиша. Типо, так?
>>697391
Почему именно 60? Ага, старая еще не досчиталась, а уже новая начала считаться, чет не комильфо как то
>Чекаешь таймер в главном цикле игры, если с момента отрисовки прошлого кадра уже прошла 1/60 секунды, то вызываешь новую отрисовку кадра.
Почему именно 60? Ага, старая еще не досчиталась, а уже новая начала считаться, чет не комильфо как то
Внезапный бамп
Народ, а подскажите за графические библиотеки, я имею ввиду такие как bgfx, magnum и т.д. Я вот смотрю, работа там как и скажем в чистом opengl на низком уровне, вершины/треугольники/шейдеры но в чем их плюс перед pure opengl в таком случаи? Как минимум если проект чисто учебный? в продакшене то понятно, там может пригодиться что библиотека по умолчанию может рендерить, где-то opengl, где-то vulkan, где-то webgl, где-то direct3d. Но в остальном невполне понятно
>>710289
Пока ты будешь вручную пересылать массивы флоатов в вертексы и текскоорды и юниформить материалы, успешный геймдевелопер в пару функций загрузит модельку и скажет движку "Рендерь!". Ещё и проанимирует, и булевые операции, всякие модификаторы на вертексы применит, систему частиц абстрагирует, оптимизирует рейтрейсинг какими-нибудь октодеревьями и отрежет от отрисовки-растеризации то, что находится сзади.
Ну и как ты сказал, разные бекенды.
Я и сам потихоньку пилю свой графический движок, планирую добавить 3 бекенда: демо OpenGL (возможно без поддержки всяких материалов и теней, но может и добавлю), рейтрейсинг на GLSL, рейтрейсинг на софтрендере. Может ещё когда-то софтрастеризацию...
Причём с свой движок я бы добавил примитивы такие как Треугольники и Нурбс. + generic собственный объект, но разработчику придётся писать обработчики всякие под каждый из бекенд. Подумываю ещё, может воксельное октодерево добавить?
Вот, а для опенгла тебе придётся аппроксимировать тот же нурбс, сделать его треугольниковым.
Если учебный, то можно и опенгл. Давай, иди учи свои glBegin и glEnd, а потом узнай, что это 20-й век и современные опенглы перебирают шейдерами, а вместо пересылки вертекс+текскоорд+колор просто массивы флоатов, из которых шейдер выберет, где вертексы, где нормали, где какие-нибудь эффекты и прочее.
Пока ты будешь вручную пересылать массивы флоатов в вертексы и текскоорды и юниформить материалы, успешный геймдевелопер в пару функций загрузит модельку и скажет движку "Рендерь!". Ещё и проанимирует, и булевые операции, всякие модификаторы на вертексы применит, систему частиц абстрагирует, оптимизирует рейтрейсинг какими-нибудь октодеревьями и отрежет от отрисовки-растеризации то, что находится сзади.
Ну и как ты сказал, разные бекенды.
Я и сам потихоньку пилю свой графический движок, планирую добавить 3 бекенда: демо OpenGL (возможно без поддержки всяких материалов и теней, но может и добавлю), рейтрейсинг на GLSL, рейтрейсинг на софтрендере. Может ещё когда-то софтрастеризацию...
Причём с свой движок я бы добавил примитивы такие как Треугольники и Нурбс. + generic собственный объект, но разработчику придётся писать обработчики всякие под каждый из бекенд. Подумываю ещё, может воксельное октодерево добавить?
Вот, а для опенгла тебе придётся аппроксимировать тот же нурбс, сделать его треугольниковым.
>если проект чисто учебный
Если учебный, то можно и опенгл. Давай, иди учи свои glBegin и glEnd, а потом узнай, что это 20-й век и современные опенглы перебирают шейдерами, а вместо пересылки вертекс+текскоорд+колор просто массивы флоатов, из которых шейдер выберет, где вертексы, где нормали, где какие-нибудь эффекты и прочее.
Пилю свой графический движок и я пока не совсем понял по PBR. Как я понимаю, это просто набор условных правил, что диэлектрик отражает свет в таких-то пределах, проводники в таких-то и всё это подстроено под физические правила. Но мне кажется, что курс на PBR мне не нужен и я лучше сделаю более гибкие настройки для рендеринга.
Но я не совсем разобрался с набором материалов. Сразу скажу, что мой движок предназначен прежде всего для рейтрейсинга.
Вот что я надумал:
0. RGBA — цвет + прозрачность. Тут всё понятно, диффузный цвет.
1. reflect 90° и reflect для 0°. Обозначает коэффициент от 0.0 до 1.0, сколько света должно отразиться для того или этого градуса. Для промежуточного угла линейная интерполяция от этих коэффициентов. Ещё можно сделать так, чтобы коэффициенты были разные для каждой RGB компонент.
2. Чёткость отражения. Если посмотреть на металлы, может быть, то можно заметить что в одних случаях отражение может быть чётким и зеркальным, а может быть размытым и зеркальным. Ещё можно заметить, что у всяких листовых металлов чёткость отражения отличается в зависимости от ориентации. Смотришь вертикально и видишь своё лицо, а горизонтально и оно размыто. Вопрос: Как это реализуется на практике и какие физические процессы стоят за этим в реале?
3. Степерь преломления. Тут вроде всё понятно, коэффициент преломления, который изменяет направление луча, падающего на поверхность в зависимости от коэффициентов смежных сред и нормали.
4. Specularity. С этим я не знаю как совладать. Знаю про спекулярность по фонгу, но это же не физическая характеристика, а так, эффект. Если осмотреться вокруг, то можно заметить, что материалы имеют блик от ярких объектов. То есть мне надо учитывать яркость источников освещения и в зависимости от их мощности делать разную яркость блика. Вопрос: Как это реализовать на практике и какие физические процессы? К тому же, блики могут быть цветными.
5. Карта нормалей. Ну тут всё ясно. Нормаль прибавляется к настоящей нормали и получаем ту, что используется для вычисления цвета.
6. Цвет внутренности и коеффициент внутреннего рассеивания. Использовать для объёмных предметов, в которые проникает свет. Например, если через сферу, то по краям будет не сильно затемнено, а в середине всё.
Или я ошибся интернетом и тут никто в PBR не умеет?
Но я не совсем разобрался с набором материалов. Сразу скажу, что мой движок предназначен прежде всего для рейтрейсинга.
Вот что я надумал:
0. RGBA — цвет + прозрачность. Тут всё понятно, диффузный цвет.
1. reflect 90° и reflect для 0°. Обозначает коэффициент от 0.0 до 1.0, сколько света должно отразиться для того или этого градуса. Для промежуточного угла линейная интерполяция от этих коэффициентов. Ещё можно сделать так, чтобы коэффициенты были разные для каждой RGB компонент.
2. Чёткость отражения. Если посмотреть на металлы, может быть, то можно заметить что в одних случаях отражение может быть чётким и зеркальным, а может быть размытым и зеркальным. Ещё можно заметить, что у всяких листовых металлов чёткость отражения отличается в зависимости от ориентации. Смотришь вертикально и видишь своё лицо, а горизонтально и оно размыто. Вопрос: Как это реализуется на практике и какие физические процессы стоят за этим в реале?
3. Степерь преломления. Тут вроде всё понятно, коэффициент преломления, который изменяет направление луча, падающего на поверхность в зависимости от коэффициентов смежных сред и нормали.
4. Specularity. С этим я не знаю как совладать. Знаю про спекулярность по фонгу, но это же не физическая характеристика, а так, эффект. Если осмотреться вокруг, то можно заметить, что материалы имеют блик от ярких объектов. То есть мне надо учитывать яркость источников освещения и в зависимости от их мощности делать разную яркость блика. Вопрос: Как это реализовать на практике и какие физические процессы? К тому же, блики могут быть цветными.
5. Карта нормалей. Ну тут всё ясно. Нормаль прибавляется к настоящей нормали и получаем ту, что используется для вычисления цвета.
6. Цвет внутренности и коеффициент внутреннего рассеивания. Использовать для объёмных предметов, в которые проникает свет. Например, если через сферу, то по краям будет не сильно затемнено, а в середине всё.
Или я ошибся интернетом и тут никто в PBR не умеет?
Пилю свой графический движок и я пока не совсем понял по PBR. Как я понимаю, это просто набор условных правил, что диэлектрик отражает свет в таких-то пределах, проводники в таких-то и всё это подстроено под физические правила. Но мне кажется, что курс на PBR мне не нужен и я лучше сделаю более гибкие настройки для рендеринга.
Но я не совсем разобрался с набором материалов. Сразу скажу, что мой движок предназначен прежде всего для рейтрейсинга.
Вот что я надумал:
0. RGBA — цвет + прозрачность. Тут всё понятно, диффузный цвет.
1. reflect 90° и reflect для 0°. Обозначает коэффициент от 0.0 до 1.0, сколько света должно отразиться для того или этого градуса. Для промежуточного угла линейная интерполяция от этих коэффициентов. Ещё можно сделать так, чтобы коэффициенты были разные для каждой RGB компонент.
2. Чёткость отражения. Если посмотреть на металлы, может быть, то можно заметить что в одних случаях отражение может быть чётким и зеркальным, а может быть размытым и зеркальным. Ещё можно заметить, что у всяких листовых металлов чёткость отражения отличается в зависимости от ориентации. Смотришь вертикально и видишь своё лицо, а горизонтально и оно размыто. Вопрос: Как это реализуется на практике и какие физические процессы стоят за этим в реале?
3. Степерь преломления. Тут вроде всё понятно, коэффициент преломления, который изменяет направление луча, падающего на поверхность в зависимости от коэффициентов смежных сред и нормали.
4. Specularity. С этим я не знаю как совладать. Знаю про спекулярность по фонгу, но это же не физическая характеристика, а так, эффект. Если осмотреться вокруг, то можно заметить, что материалы имеют блик от ярких объектов. То есть мне надо учитывать яркость источников освещения и в зависимости от их мощности делать разную яркость блика. Вопрос: Как это реализовать на практике и какие физические процессы? К тому же, блики могут быть цветными.
5. Карта нормалей. Ну тут всё ясно. Нормаль прибавляется к настоящей нормали и получаем ту, что используется для вычисления цвета.
6. Цвет внутренности и коеффициент внутреннего рассеивания. Использовать для объёмных предметов, в которые проникает свет. Например, если через сферу, то по краям будет не сильно затемнено, а в середине всё.
Или я ошибся интернетом и тут никто в PBR не умеет?
Но я не совсем разобрался с набором материалов. Сразу скажу, что мой движок предназначен прежде всего для рейтрейсинга.
Вот что я надумал:
0. RGBA — цвет + прозрачность. Тут всё понятно, диффузный цвет.
1. reflect 90° и reflect для 0°. Обозначает коэффициент от 0.0 до 1.0, сколько света должно отразиться для того или этого градуса. Для промежуточного угла линейная интерполяция от этих коэффициентов. Ещё можно сделать так, чтобы коэффициенты были разные для каждой RGB компонент.
2. Чёткость отражения. Если посмотреть на металлы, может быть, то можно заметить что в одних случаях отражение может быть чётким и зеркальным, а может быть размытым и зеркальным. Ещё можно заметить, что у всяких листовых металлов чёткость отражения отличается в зависимости от ориентации. Смотришь вертикально и видишь своё лицо, а горизонтально и оно размыто. Вопрос: Как это реализуется на практике и какие физические процессы стоят за этим в реале?
3. Степерь преломления. Тут вроде всё понятно, коэффициент преломления, который изменяет направление луча, падающего на поверхность в зависимости от коэффициентов смежных сред и нормали.
4. Specularity. С этим я не знаю как совладать. Знаю про спекулярность по фонгу, но это же не физическая характеристика, а так, эффект. Если осмотреться вокруг, то можно заметить, что материалы имеют блик от ярких объектов. То есть мне надо учитывать яркость источников освещения и в зависимости от их мощности делать разную яркость блика. Вопрос: Как это реализовать на практике и какие физические процессы? К тому же, блики могут быть цветными.
5. Карта нормалей. Ну тут всё ясно. Нормаль прибавляется к настоящей нормали и получаем ту, что используется для вычисления цвета.
6. Цвет внутренности и коеффициент внутреннего рассеивания. Использовать для объёмных предметов, в которые проникает свет. Например, если через сферу, то по краям будет не сильно затемнено, а в середине всё.
Или я ошибся интернетом и тут никто в PBR не умеет?
>>711333
С чего ты взял, что больше параметров => больше гибкости? Ты просто получаешь бесконечное количество случаев, когда твои материалы выглядят и работают хуёво. Принятые в индустрии физические модели и их параметризации позволяют порождать фотореалистичные и не очень рендеры уже пару десятков лет. Плюсом идёт огромное количество уже созданных материалов, бери и прикладывай.
Возьми какой-нибудь учебник, статью или ещё что, и изучи физику, из которой получаются уравнения и существующие модели рассеивания света на поверхности. Потом сделай всё то же самое, но сам. Раскури короче эту тему достойно, не пожалей времени, потом и сам не пожалеешь. Там ребята уже придумали много интересных вещей, и, даже если хочется придумать что-то своё, хотя бы ознакомься с их методами, иначе потратишь время на какие-то сомнительные вещи. Они делают примерно то же, что и ты, только более корректно.
Кстати, если у тебя лучи, лучше выкинь карты нормалей и завези нормальную геометрию. У тебя там рассеивание лучей по пизде пойдёт из-за таких финтов.
> более гибкие настройки для рендеринга
С чего ты взял, что больше параметров => больше гибкости? Ты просто получаешь бесконечное количество случаев, когда твои материалы выглядят и работают хуёво. Принятые в индустрии физические модели и их параметризации позволяют порождать фотореалистичные и не очень рендеры уже пару десятков лет. Плюсом идёт огромное количество уже созданных материалов, бери и прикладывай.
Возьми какой-нибудь учебник, статью или ещё что, и изучи физику, из которой получаются уравнения и существующие модели рассеивания света на поверхности. Потом сделай всё то же самое, но сам. Раскури короче эту тему достойно, не пожалей времени, потом и сам не пожалеешь. Там ребята уже придумали много интересных вещей, и, даже если хочется придумать что-то своё, хотя бы ознакомься с их методами, иначе потратишь время на какие-то сомнительные вещи. Они делают примерно то же, что и ты, только более корректно.
Кстати, если у тебя лучи, лучше выкинь карты нормалей и завези нормальную геометрию. У тебя там рассеивание лучей по пизде пойдёт из-за таких финтов.
>>711395
Но для геймдева и других проектов очень редко нужен прям фотореалистичный рендер. Это AAA графонослайсы гонятся за улучшением графики, оставляя один и тот же геймплей, тем временем многие успешные инди и не только инди игры используют нереалистичную мультяшную, пиксельную и другую графику.
Если сделать задел именно на PBR, то не получится ли движок кастрированным и без возможности настройки особой графики?
>>711534
Ну да, на топовом проце в фуллхд десяток-двадцаток сфер рисуются с меньше 20 FPS.
Это скорее подойдёт всяким встроенным системам, у которых экран 300x200 пикселей. Модельку на 3D-принтере отобразить или ещё что.
>порождать фотореалистичные и не очень рендеры уже пару десятков лет
Но для геймдева и других проектов очень редко нужен прям фотореалистичный рендер. Это AAA графонослайсы гонятся за улучшением графики, оставляя один и тот же геймплей, тем временем многие успешные инди и не только инди игры используют нереалистичную мультяшную, пиксельную и другую графику.
Если сделать задел именно на PBR, то не получится ли движок кастрированным и без возможности настройки особой графики?
>>711534
Ну да, на топовом проце в фуллхд десяток-двадцаток сфер рисуются с меньше 20 FPS.
Это скорее подойдёт всяким встроенным системам, у которых экран 300x200 пикселей. Модельку на 3D-принтере отобразить или ещё что.
Кто-нибудь читал третье издание оппика?
>>710336
Но ведь glBegin и glEnd будут только в пределах графического движка, который можно в последствии целиком заменить без изменения внешних интерфейсов, так ведь? А учебный проект не ограничен только графикой. Какая разница, каким способом рендерить, если нужно просто пиксели закрасить, чтобы хоть что-то на экране увидеть? Ты ведь не можешь запилить и протестировать, скажем, физический движок, если твоя программа не может ничего на экране отобразить - даже банальный кубик без текстур.
Насколько я знаю, OpenGL считается полностью устаревшим, больше развиваться не будет и теперь все силы прежних разработчиков OpenGL направлены на развитие Vulkan? То есть вместо шейдеров GLSL теперь нужно вулкан какой-то учить...
>Давай, иди учи свои glBegin и glEnd, а потом узнай, что это 20-й век
Но ведь glBegin и glEnd будут только в пределах графического движка, который можно в последствии целиком заменить без изменения внешних интерфейсов, так ведь? А учебный проект не ограничен только графикой. Какая разница, каким способом рендерить, если нужно просто пиксели закрасить, чтобы хоть что-то на экране увидеть? Ты ведь не можешь запилить и протестировать, скажем, физический движок, если твоя программа не может ничего на экране отобразить - даже банальный кубик без текстур.
>современные опенглы
Насколько я знаю, OpenGL считается полностью устаревшим, больше развиваться не будет и теперь все силы прежних разработчиков OpenGL направлены на развитие Vulkan? То есть вместо шейдеров GLSL теперь нужно вулкан какой-то учить...
>>711934
Он будет ещё жить не один десяток лет.
> Насколько я знаю, OpenGL считается полностью устаревшим
Он будет ещё жить не один десяток лет.
>>711934
Если ты собираешься отдельный интерфейс писать для использования опенгла, то пожалуйста. Можешь хоть glBegin, хоть glVertexPointer, хоть glDrawArrays. Когда я начинал учить опенгл, то в программировании не был очень силён и не думал про абстракции. Потом мне пришлось все свои говнокоды переписывать под новый опенгл. А потом под ещё более новый.
Последняя стабильная версия 4.6 3 года назад. Развиваться ему действительно не очень стоит. Опенгл очень рудиментарен. Это раньше люди думали, что надо сделать glBegin, а потом поняли, что легче сразу вертексы пересылать, а затем ещё научили видеокарты почти произвольный код исполнять.
Нет. GLSL это просто сиподобный язык с матрицами, векторами и разными математическими функциями из коробки, у которого убраны указатели, рекуррентное исполнение функций и ещё некоторые фичи, что позволяет как бы из кода сделать комбинационную схему термин тут не уместен, но похож. Он из цифровой электроники, чтобы архитектура видеокарт нормально их восприняла. Вообще, теоретически, любой GLSL-шейдер можно запросто превратить в модуль на верилоге, VHDL или другом HDL.
А вулкан это просто новая обёртка, чтобы запустить GLSL-шейдеры насколько я понимаю. Или там какие-то другие шейдеры, но всё-равно отличий будет немного. На вулкане надо 1000 строчек прописать, чтобы треугольник запустить просто из-за его гибкости и возможности подхвата устройств-видеокарт или что-то такое. Вся отрисовка такая же как и была.
Если ты собираешься отдельный интерфейс писать для использования опенгла, то пожалуйста. Можешь хоть glBegin, хоть glVertexPointer, хоть glDrawArrays. Когда я начинал учить опенгл, то в программировании не был очень силён и не думал про абстракции. Потом мне пришлось все свои говнокоды переписывать под новый опенгл. А потом под ещё более новый.
>Насколько я знаю, OpenGL считается полностью устаревшим, больше развиваться не будет
Последняя стабильная версия 4.6 3 года назад. Развиваться ему действительно не очень стоит. Опенгл очень рудиментарен. Это раньше люди думали, что надо сделать glBegin, а потом поняли, что легче сразу вертексы пересылать, а затем ещё научили видеокарты почти произвольный код исполнять.
>То есть вместо шейдеров GLSL теперь нужно вулкан какой-то учить
Нет. GLSL это просто сиподобный язык с матрицами, векторами и разными математическими функциями из коробки, у которого убраны указатели, рекуррентное исполнение функций и ещё некоторые фичи, что позволяет как бы из кода сделать комбинационную схему термин тут не уместен, но похож. Он из цифровой электроники, чтобы архитектура видеокарт нормально их восприняла. Вообще, теоретически, любой GLSL-шейдер можно запросто превратить в модуль на верилоге, VHDL или другом HDL.
А вулкан это просто новая обёртка, чтобы запустить GLSL-шейдеры насколько я понимаю. Или там какие-то другие шейдеры, но всё-равно отличий будет немного. На вулкане надо 1000 строчек прописать, чтобы треугольник запустить просто из-за его гибкости и возможности подхвата устройств-видеокарт или что-то такое. Вся отрисовка такая же как и была.
Что по-вашему должен приносить графические движок помимо самой отрисовки?
В свой графический движок я собираюсь/уже добавил боксинг и разные анимации.
Под боксингом я подразумеваю, что есть родительские объекты и дочерние. Так, если один объект человек имеет дочерний оружие/шапка/кирка, то трансформация дочернего будет относительна родительскому.
А анимации я подумываю сделать трёх видов. Текстурно-цветовые, скелетные и свойственные.
Текстурно-цветовые это видео или массив цветов, которое меняется по FPS, длине кадра или другим правилам. То есть в случае пиксельной графики можно сразу анимацию загрузить и не думать над тем как перебирать кадрами.
Скелетная анимация это скелетная анимация.
Свойственная анимация это просто коллбек, который будет менять матрицу объекта. Например, заскейлить (когда курсор наводится на кнопку и она прыгает или когда надо дешёвую анимацию на 3D-персонажа нацепить).
Что ещё там может быть?
В свой графический движок я собираюсь/уже добавил боксинг и разные анимации.
Под боксингом я подразумеваю, что есть родительские объекты и дочерние. Так, если один объект человек имеет дочерний оружие/шапка/кирка, то трансформация дочернего будет относительна родительскому.
А анимации я подумываю сделать трёх видов. Текстурно-цветовые, скелетные и свойственные.
Текстурно-цветовые это видео или массив цветов, которое меняется по FPS, длине кадра или другим правилам. То есть в случае пиксельной графики можно сразу анимацию загрузить и не думать над тем как перебирать кадрами.
Скелетная анимация это скелетная анимация.
Свойственная анимация это просто коллбек, который будет менять матрицу объекта. Например, заскейлить (когда курсор наводится на кнопку и она прыгает или когда надо дешёвую анимацию на 3D-персонажа нацепить).
Что ещё там может быть?
>>711961
Различные виды куллинга: фрустум, окклюжн, порталы.
ЛОДы
Батчинг
Инстансинг
Системы частиц
Материалы
ИК
Шейдеры для воды, травы, террейна, скайбокса и т. п.
Различные виды куллинга: фрустум, окклюжн, порталы.
ЛОДы
Батчинг
Инстансинг
Системы частиц
Материалы
ИК
Шейдеры для воды, травы, террейна, скайбокса и т. п.
>>712006
Сейчас перечитал, и понял, что ты имел в виду не эффект Френеля, а анизотропные поверхности.
Сейчас перечитал, и понял, что ты имел в виду не эффект Френеля, а анизотропные поверхности.
>>711959
А разве можно как-то иначе? От голого OpenGL до игровых сущностей несколько слоёв абстракции должно быть.
Так если ты не думал про абстракции и сделал огромный чан с туго запутанной лапшой, тебе его в любом случае пришлось бы переписывать с нуля/рефакторить, даже если решил бы остаться на самом старом OpenGL. Сам проходил такое, и проекты приходилось бросать не из-за выбранных интерфейсов рендеринга, а из-за того, что что-то добавить, убрать или просто понять, как и что работает, становилось чрезвычайно трудно. Какая разница, какой опенгл, если ты через месяц не можешь нарисовать дополнительную кнопку на экране, не сломав полностью весь GUI, и это в лучшем случае; у меня проект, бывало, вообще весь целиком ломался, лол. С тех пор учусь избегать лапши.
Я правильно понимаю, что теперь рендерер движка должен быть написан на GLSL, и загружаться в видеокарту? Потому что я вот скопипастил какой-то базовый пример GLSL-шейдера, а он мне просто экран красным закрашивает и всё, какие бы данные я не отправлял. То есть мне теперь иголкой в видеокарту тыкать, чтобы научить её модели рисовать? Почему всё так, почему нельзя загрузить какой-нибудь default шейдер, почему я должен учить видеокарту рисовать отдельными пикселями... Вот в legacy OpenGL ты отправляешь на видеокарту команды и она их исполняет, а в GLSL ты сам своими руками исполняешь эти команды. Как я буду эти команды своими руками исполнять, если они для меня - "чёрный ящик"?
Вот конкретно из-за GLSL я бросил разработку очередного своего движка последний раз (июль этого года). Не хотел больше даже касаться темы разработки игр, но меня всё равно тянет что-нибудь сделать...
>Если ты собираешься отдельный интерфейс писать для использования опенгла, то пожалуйста
А разве можно как-то иначе? От голого OpenGL до игровых сущностей несколько слоёв абстракции должно быть.
>в программировании не был очень силён и не думал про абстракции
>Потом мне пришлось все свои говнокоды переписывать под новый опенгл
Так если ты не думал про абстракции и сделал огромный чан с туго запутанной лапшой, тебе его в любом случае пришлось бы переписывать с нуля/рефакторить, даже если решил бы остаться на самом старом OpenGL. Сам проходил такое, и проекты приходилось бросать не из-за выбранных интерфейсов рендеринга, а из-за того, что что-то добавить, убрать или просто понять, как и что работает, становилось чрезвычайно трудно. Какая разница, какой опенгл, если ты через месяц не можешь нарисовать дополнительную кнопку на экране, не сломав полностью весь GUI, и это в лучшем случае; у меня проект, бывало, вообще весь целиком ломался, лол. С тех пор учусь избегать лапши.
>вулкан это просто новая обёртка, чтобы запустить GLSL-шейдеры
>Вся отрисовка такая же как и была
Я правильно понимаю, что теперь рендерер движка должен быть написан на GLSL, и загружаться в видеокарту? Потому что я вот скопипастил какой-то базовый пример GLSL-шейдера, а он мне просто экран красным закрашивает и всё, какие бы данные я не отправлял. То есть мне теперь иголкой в видеокарту тыкать, чтобы научить её модели рисовать? Почему всё так, почему нельзя загрузить какой-нибудь default шейдер, почему я должен учить видеокарту рисовать отдельными пикселями... Вот в legacy OpenGL ты отправляешь на видеокарту команды и она их исполняет, а в GLSL ты сам своими руками исполняешь эти команды. Как я буду эти команды своими руками исполнять, если они для меня - "чёрный ящик"?
Вот конкретно из-за GLSL я бросил разработку очередного своего движка последний раз (июль этого года). Не хотел больше даже касаться темы разработки игр, но меня всё равно тянет что-нибудь сделать...
>>711806
Нет, не получится. Получится удобно с точки зрения создания и заимствования материалов. Возьми любой blender и поиграйся с ним, сформируй сам мнение о том, хватит ли тебе того, что он может, или нет. Поищи на ютубе, что всякого охуенного с его помощью получается сделать у других.
> Если сделать задел именно на PBR, то не получится ли движок кастрированным и без возможности настройки особой графики?
Нет, не получится. Получится удобно с точки зрения создания и заимствования материалов. Возьми любой blender и поиграйся с ним, сформируй сам мнение о том, хватит ли тебе того, что он может, или нет. Поищи на ютубе, что всякого охуенного с его помощью получается сделать у других.
qw
>>712094
Посмотрел сейчас на свою первую игру, а там всего 9 функций, в которых и происходит весь игровой процесс. Сама игра это платформер на несколько уровней...
Предполагаю, что твой шейдер имел синтаксические ошибки и просто не скомпилировался. Для хандлинга ошибок надо использовать функции glGetProgramiv glGetShaderiv glGetProgramInfoLog glGetShaderInfoLog
Кстати, посмотрел мельком на вебсайты с упоминанием вулкана и как я понял, там сделали гораздо лучше. Вместо загрузки исходника шейдера можно загрузить сразу SPIRV — новый модный молодёжный промежуточный код для шейдеров, всяких вычислительных ядер и прочего. То есть компилировать GLSL для вулкана надо отдельно. Кажется, с помощью SPIRV можно запускать не только GLSL, но и HLSL, или свой собственный язык шейдинга.
И это плохо по-моему. Плохо то, что для растеризации простых треугольников, линий и точек надо иметь отдельное устройство со своим полусовместимым интерфейсом.
Я считаю, что видеокарты это рак, особенно, что одни версии опенгла или GLSLа можно запустить на одних, а на других нельзя. Хотя это вроде бы просто вычислительное устройство со встроенным выходом на монитор.
По-моему, было бы хорошо, если бы некоторый параллелизующий сопроцессор был в процессоре вместо самой видеокарты. Можно добавить инструкций для рейтрейсинга луча и треугольника или других инструкций для ускорения видео.
>От голого OpenGL до игровых сущностей несколько слоёв абстракции должно быть.
Посмотрел сейчас на свою первую игру, а там всего 9 функций, в которых и происходит весь игровой процесс. Сама игра это платформер на несколько уровней...
>скопипастил какой-то базовый пример GLSL-шейдера, а он мне просто экран красным закрашивает и всё
Предполагаю, что твой шейдер имел синтаксические ошибки и просто не скомпилировался. Для хандлинга ошибок надо использовать функции glGetProgramiv glGetShaderiv glGetProgramInfoLog glGetShaderInfoLog
Кстати, посмотрел мельком на вебсайты с упоминанием вулкана и как я понял, там сделали гораздо лучше. Вместо загрузки исходника шейдера можно загрузить сразу SPIRV — новый модный молодёжный промежуточный код для шейдеров, всяких вычислительных ядер и прочего. То есть компилировать GLSL для вулкана надо отдельно. Кажется, с помощью SPIRV можно запускать не только GLSL, но и HLSL, или свой собственный язык шейдинга.
>в legacy OpenGL ты отправляешь на видеокарту команды и она их исполняет
И это плохо по-моему. Плохо то, что для растеризации простых треугольников, линий и точек надо иметь отдельное устройство со своим полусовместимым интерфейсом.
Я считаю, что видеокарты это рак, особенно, что одни версии опенгла или GLSLа можно запустить на одних, а на других нельзя. Хотя это вроде бы просто вычислительное устройство со встроенным выходом на монитор.
По-моему, было бы хорошо, если бы некоторый параллелизующий сопроцессор был в процессоре вместо самой видеокарты. Можно добавить инструкций для рейтрейсинга луча и треугольника или других инструкций для ускорения видео.
>>712094
ну в текущий момент надо поддерживать два графических api - vulkan и условный gles2/opengl3.3
их достаточно для покрытия большинства целевых игровых устройств на планете, в отдаленном светлом будущем можно будет обойтись одним vulkan (когда на долю устройств с Android 5.0+ будет приходиться ~95% и отомрут старые компы/ноуты 10 летней давности)
ну в текущий момент надо поддерживать два графических api - vulkan и условный gles2/opengl3.3
их достаточно для покрытия большинства целевых игровых устройств на планете, в отдаленном светлом будущем можно будет обойтись одним vulkan (когда на долю устройств с Android 5.0+ будет приходиться ~95% и отомрут старые компы/ноуты 10 летней давности)
14 Кб, 595x419>>712239
Моя первая и последняя полноценная игра имеет целую кучу функций, типов и констант, есть даже ООП-шные классы, в которые я пытался загнать игровые сущности. Но всё это настолько перепутано, что спустя какое-то время я уже не смог разобраться в этой лапше и забил на игру. Клон тетриса, если что.. Наверное, сейчас бы я смог произвести рефакторинг, разделить на отдельные модули и т.д., но мне слишком лень, нет мотивации.
Не угадал. Шейдер на пикриле. Скомпилировать удалось с какой-то попытки (кажется, я не мог получить правильный профиль OpenGL, получался только 1.0/2.0), но что делать дальше - непонятно. Какие-то in и out... Кто я, программист или колдун, чтобы неизвестно что получать и неизвестно куда передавать? В нормальном языке программирования я бы подключил библиотеку и передавал ей данные, а здесь я кому и что передаю? Магия какая-то.
Ну это понятно, байт-код вроде как, да? Непонятно почему сразу такое не сделали...
Придётся копаться в этом SPIRV, наверняка это ещё сложнее, чем почитать туториал по GLSL)
Производители разные ведь. Это вообще с любым железом так (процессоры, SoC смартфонов, микропроцессоры).
Сегодня уже нет "просто вычислителей", там очень много ускоряющих работу костылей, это тебе не калькулятор.
Ну вот Intel с AMD тоже так подумали и выпустили процессоры со встроенным видеоядром. Однако недостатки таких чипов очевидны - они вынуждены пользоваться общей с процессором оперативной памятью (а она медленнее видеопамяти) и делить место на кристалле с ядрами процессора. А у ARM с его SoC вообще всё на одном чипе, и что это меняет? Только позволяет уместить всё железо на пластинке размером с ноготь, но что это даёт разработчику ПО? Новый процессор или процессор другого производителя всё равно будут иметь свои особенности, в т.ч. в работе видеоядра.
>Посмотрел сейчас на свою первую игру, а там всего 9 функций, в которых и происходит весь игровой процесс
Моя первая и последняя полноценная игра имеет целую кучу функций, типов и констант, есть даже ООП-шные классы, в которые я пытался загнать игровые сущности. Но всё это настолько перепутано, что спустя какое-то время я уже не смог разобраться в этой лапше и забил на игру. Клон тетриса, если что.. Наверное, сейчас бы я смог произвести рефакторинг, разделить на отдельные модули и т.д., но мне слишком лень, нет мотивации.
>Предполагаю, что твой шейдер имел синтаксические ошибки и просто не скомпилировался
Не угадал. Шейдер на пикриле. Скомпилировать удалось с какой-то попытки (кажется, я не мог получить правильный профиль OpenGL, получался только 1.0/2.0), но что делать дальше - непонятно. Какие-то in и out... Кто я, программист или колдун, чтобы неизвестно что получать и неизвестно куда передавать? В нормальном языке программирования я бы подключил библиотеку и передавал ей данные, а здесь я кому и что передаю? Магия какая-то.
>SPIRV — новый модный молодёжный промежуточный код для шейдеров
Ну это понятно, байт-код вроде как, да? Непонятно почему сразу такое не сделали...
>свой собственный язык шейдинга
Придётся копаться в этом SPIRV, наверняка это ещё сложнее, чем почитать туториал по GLSL)
>можно запустить на одних, а на других нельзя
Производители разные ведь. Это вообще с любым железом так (процессоры, SoC смартфонов, микропроцессоры).
>просто вычислительное устройство
Сегодня уже нет "просто вычислителей", там очень много ускоряющих работу костылей, это тебе не калькулятор.
>было бы хорошо, если бы некоторый параллелизующий сопроцессор был в процессоре вместо самой видеокарты
Ну вот Intel с AMD тоже так подумали и выпустили процессоры со встроенным видеоядром. Однако недостатки таких чипов очевидны - они вынуждены пользоваться общей с процессором оперативной памятью (а она медленнее видеопамяти) и делить место на кристалле с ядрами процессора. А у ARM с его SoC вообще всё на одном чипе, и что это меняет? Только позволяет уместить всё железо на пластинке размером с ноготь, но что это даёт разработчику ПО? Новый процессор или процессор другого производителя всё равно будут иметь свои особенности, в т.ч. в работе видеоядра.
14 Кб, 595x419>>712239
Моя первая и последняя полноценная игра имеет целую кучу функций, типов и констант, есть даже ООП-шные классы, в которые я пытался загнать игровые сущности. Но всё это настолько перепутано, что спустя какое-то время я уже не смог разобраться в этой лапше и забил на игру. Клон тетриса, если что.. Наверное, сейчас бы я смог произвести рефакторинг, разделить на отдельные модули и т.д., но мне слишком лень, нет мотивации.
Не угадал. Шейдер на пикриле. Скомпилировать удалось с какой-то попытки (кажется, я не мог получить правильный профиль OpenGL, получался только 1.0/2.0), но что делать дальше - непонятно. Какие-то in и out... Кто я, программист или колдун, чтобы неизвестно что получать и неизвестно куда передавать? В нормальном языке программирования я бы подключил библиотеку и передавал ей данные, а здесь я кому и что передаю? Магия какая-то.
Ну это понятно, байт-код вроде как, да? Непонятно почему сразу такое не сделали...
Придётся копаться в этом SPIRV, наверняка это ещё сложнее, чем почитать туториал по GLSL)
Производители разные ведь. Это вообще с любым железом так (процессоры, SoC смартфонов, микропроцессоры).
Сегодня уже нет "просто вычислителей", там очень много ускоряющих работу костылей, это тебе не калькулятор.
Ну вот Intel с AMD тоже так подумали и выпустили процессоры со встроенным видеоядром. Однако недостатки таких чипов очевидны - они вынуждены пользоваться общей с процессором оперативной памятью (а она медленнее видеопамяти) и делить место на кристалле с ядрами процессора. А у ARM с его SoC вообще всё на одном чипе, и что это меняет? Только позволяет уместить всё железо на пластинке размером с ноготь, но что это даёт разработчику ПО? Новый процессор или процессор другого производителя всё равно будут иметь свои особенности, в т.ч. в работе видеоядра.
>Посмотрел сейчас на свою первую игру, а там всего 9 функций, в которых и происходит весь игровой процесс
Моя первая и последняя полноценная игра имеет целую кучу функций, типов и констант, есть даже ООП-шные классы, в которые я пытался загнать игровые сущности. Но всё это настолько перепутано, что спустя какое-то время я уже не смог разобраться в этой лапше и забил на игру. Клон тетриса, если что.. Наверное, сейчас бы я смог произвести рефакторинг, разделить на отдельные модули и т.д., но мне слишком лень, нет мотивации.
>Предполагаю, что твой шейдер имел синтаксические ошибки и просто не скомпилировался
Не угадал. Шейдер на пикриле. Скомпилировать удалось с какой-то попытки (кажется, я не мог получить правильный профиль OpenGL, получался только 1.0/2.0), но что делать дальше - непонятно. Какие-то in и out... Кто я, программист или колдун, чтобы неизвестно что получать и неизвестно куда передавать? В нормальном языке программирования я бы подключил библиотеку и передавал ей данные, а здесь я кому и что передаю? Магия какая-то.
>SPIRV — новый модный молодёжный промежуточный код для шейдеров
Ну это понятно, байт-код вроде как, да? Непонятно почему сразу такое не сделали...
>свой собственный язык шейдинга
Придётся копаться в этом SPIRV, наверняка это ещё сложнее, чем почитать туториал по GLSL)
>можно запустить на одних, а на других нельзя
Производители разные ведь. Это вообще с любым железом так (процессоры, SoC смартфонов, микропроцессоры).
>просто вычислительное устройство
Сегодня уже нет "просто вычислителей", там очень много ускоряющих работу костылей, это тебе не калькулятор.
>было бы хорошо, если бы некоторый параллелизующий сопроцессор был в процессоре вместо самой видеокарты
Ну вот Intel с AMD тоже так подумали и выпустили процессоры со встроенным видеоядром. Однако недостатки таких чипов очевидны - они вынуждены пользоваться общей с процессором оперативной памятью (а она медленнее видеопамяти) и делить место на кристалле с ядрами процессора. А у ARM с его SoC вообще всё на одном чипе, и что это меняет? Только позволяет уместить всё железо на пластинке размером с ноготь, но что это даёт разработчику ПО? Новый процессор или процессор другого производителя всё равно будут иметь свои особенности, в т.ч. в работе видеоядра.
987 Кб, mp4,1200x800, 0:09
Пишу свойу библиотеку движок ГУИ, но чё-то плохо получается.
В нём есть как примитивные виджеты, такие как квадрат, так и сложные, как кнопка, слайдер, прогрессбар, список. Сейчас я остановился на прогресс барах и их очень сложно сделать. Сразу скажу, что тут прогресс бар состоит из двух дочерних виджетов — empty и full, меши которых изменяются в зависимости от value.
Я хочу запилить очень абстрактные прогресс-бары, чтобы они могли быть горизонтальными, вертикальными, со снаппингом, без снаппинга, круговыми или с генерацией своего собственного меша в зависимости от значения. А это ведёт к тому, что надо сделать отдельную библиотеку для булевых операций между 2D-мешами.
Но можно пойти по другому пути и сразу сделать нормально. Для этого придётся написать отдельный шейдер для опенгла, в который пересылать некоторый 2D-меш и если фрагмент (пиксель) попадает в него, то дальнейшие виджеты не рисуются.
Пример: Мы хотим сделать не горизонтальный и не вертикальный прогресс-бар, а диагональный. Для этого в прогресс баре есть 2 поля — для значения и угла, куда виджет full растёт. А чтобы это реализовать, надо сгенерировать 2 меша, которые будут являться разрезанным прямоугольником в определённом месте и под определённым углом. Далее пересылаем один меш во время отрисовки одного виджета и его часть отсекается, а другая нет. Важно чтобы так же отсекался трейсинг виджетов, так как в прогресс бар можно будет засунуть кнопки, например, и нельзя, чтобы их можно было нажать, пока не видны.
Таким образом можно сгенерировать и какой-нибудь свой меш. Например, если человек хочет сделать прогресс-бар, заполняющийся замощёнными шестиугольниками.
Такой шейдер позволит ещё ввести мою систему стилей. У меня стиль виджета это набор материалов (по сути цвет + текстура), связанные со своим индексом. Суть накладываемых стилей в том, чтобы они могли перемешивать индексы других стилей и, например, была белая кнопка с чёрным текстом, а стала синяя с белым текстом. Надо этим надо подумать.
Как тебе такое, Qt?
А по факту я сейчас имею криво работающие горизонтальный прогрессбар и один такой со снаппингом.
Кстати, эта библиотека работает поверх моего графического движка и мне придётся расширять возможности каждого бекенда, чтобы на них работал мой ГУИ.
В нём есть как примитивные виджеты, такие как квадрат, так и сложные, как кнопка, слайдер, прогрессбар, список. Сейчас я остановился на прогресс барах и их очень сложно сделать. Сразу скажу, что тут прогресс бар состоит из двух дочерних виджетов — empty и full, меши которых изменяются в зависимости от value.
Я хочу запилить очень абстрактные прогресс-бары, чтобы они могли быть горизонтальными, вертикальными, со снаппингом, без снаппинга, круговыми или с генерацией своего собственного меша в зависимости от значения. А это ведёт к тому, что надо сделать отдельную библиотеку для булевых операций между 2D-мешами.
Но можно пойти по другому пути и сразу сделать нормально. Для этого придётся написать отдельный шейдер для опенгла, в который пересылать некоторый 2D-меш и если фрагмент (пиксель) попадает в него, то дальнейшие виджеты не рисуются.
Пример: Мы хотим сделать не горизонтальный и не вертикальный прогресс-бар, а диагональный. Для этого в прогресс баре есть 2 поля — для значения и угла, куда виджет full растёт. А чтобы это реализовать, надо сгенерировать 2 меша, которые будут являться разрезанным прямоугольником в определённом месте и под определённым углом. Далее пересылаем один меш во время отрисовки одного виджета и его часть отсекается, а другая нет. Важно чтобы так же отсекался трейсинг виджетов, так как в прогресс бар можно будет засунуть кнопки, например, и нельзя, чтобы их можно было нажать, пока не видны.
Таким образом можно сгенерировать и какой-нибудь свой меш. Например, если человек хочет сделать прогресс-бар, заполняющийся замощёнными шестиугольниками.
Такой шейдер позволит ещё ввести мою систему стилей. У меня стиль виджета это набор материалов (по сути цвет + текстура), связанные со своим индексом. Суть накладываемых стилей в том, чтобы они могли перемешивать индексы других стилей и, например, была белая кнопка с чёрным текстом, а стала синяя с белым текстом. Надо этим надо подумать.
Как тебе такое, Qt?
А по факту я сейчас имею криво работающие горизонтальный прогрессбар и один такой со снаппингом.
Кстати, эта библиотека работает поверх моего графического движка и мне придётся расширять возможности каждого бекенда, чтобы на них работал мой ГУИ.
987 Кб, mp4,1200x800, 0:09
Пишу свойу библиотеку движок ГУИ, но чё-то плохо получается.
В нём есть как примитивные виджеты, такие как квадрат, так и сложные, как кнопка, слайдер, прогрессбар, список. Сейчас я остановился на прогресс барах и их очень сложно сделать. Сразу скажу, что тут прогресс бар состоит из двух дочерних виджетов — empty и full, меши которых изменяются в зависимости от value.
Я хочу запилить очень абстрактные прогресс-бары, чтобы они могли быть горизонтальными, вертикальными, со снаппингом, без снаппинга, круговыми или с генерацией своего собственного меша в зависимости от значения. А это ведёт к тому, что надо сделать отдельную библиотеку для булевых операций между 2D-мешами.
Но можно пойти по другому пути и сразу сделать нормально. Для этого придётся написать отдельный шейдер для опенгла, в который пересылать некоторый 2D-меш и если фрагмент (пиксель) попадает в него, то дальнейшие виджеты не рисуются.
Пример: Мы хотим сделать не горизонтальный и не вертикальный прогресс-бар, а диагональный. Для этого в прогресс баре есть 2 поля — для значения и угла, куда виджет full растёт. А чтобы это реализовать, надо сгенерировать 2 меша, которые будут являться разрезанным прямоугольником в определённом месте и под определённым углом. Далее пересылаем один меш во время отрисовки одного виджета и его часть отсекается, а другая нет. Важно чтобы так же отсекался трейсинг виджетов, так как в прогресс бар можно будет засунуть кнопки, например, и нельзя, чтобы их можно было нажать, пока не видны.
Таким образом можно сгенерировать и какой-нибудь свой меш. Например, если человек хочет сделать прогресс-бар, заполняющийся замощёнными шестиугольниками.
Такой шейдер позволит ещё ввести мою систему стилей. У меня стиль виджета это набор материалов (по сути цвет + текстура), связанные со своим индексом. Суть накладываемых стилей в том, чтобы они могли перемешивать индексы других стилей и, например, была белая кнопка с чёрным текстом, а стала синяя с белым текстом. Надо этим надо подумать.
Как тебе такое, Qt?
А по факту я сейчас имею криво работающие горизонтальный прогрессбар и один такой со снаппингом.
Кстати, эта библиотека работает поверх моего графического движка и мне придётся расширять возможности каждого бекенда, чтобы на них работал мой ГУИ.
В нём есть как примитивные виджеты, такие как квадрат, так и сложные, как кнопка, слайдер, прогрессбар, список. Сейчас я остановился на прогресс барах и их очень сложно сделать. Сразу скажу, что тут прогресс бар состоит из двух дочерних виджетов — empty и full, меши которых изменяются в зависимости от value.
Я хочу запилить очень абстрактные прогресс-бары, чтобы они могли быть горизонтальными, вертикальными, со снаппингом, без снаппинга, круговыми или с генерацией своего собственного меша в зависимости от значения. А это ведёт к тому, что надо сделать отдельную библиотеку для булевых операций между 2D-мешами.
Но можно пойти по другому пути и сразу сделать нормально. Для этого придётся написать отдельный шейдер для опенгла, в который пересылать некоторый 2D-меш и если фрагмент (пиксель) попадает в него, то дальнейшие виджеты не рисуются.
Пример: Мы хотим сделать не горизонтальный и не вертикальный прогресс-бар, а диагональный. Для этого в прогресс баре есть 2 поля — для значения и угла, куда виджет full растёт. А чтобы это реализовать, надо сгенерировать 2 меша, которые будут являться разрезанным прямоугольником в определённом месте и под определённым углом. Далее пересылаем один меш во время отрисовки одного виджета и его часть отсекается, а другая нет. Важно чтобы так же отсекался трейсинг виджетов, так как в прогресс бар можно будет засунуть кнопки, например, и нельзя, чтобы их можно было нажать, пока не видны.
Таким образом можно сгенерировать и какой-нибудь свой меш. Например, если человек хочет сделать прогресс-бар, заполняющийся замощёнными шестиугольниками.
Такой шейдер позволит ещё ввести мою систему стилей. У меня стиль виджета это набор материалов (по сути цвет + текстура), связанные со своим индексом. Суть накладываемых стилей в том, чтобы они могли перемешивать индексы других стилей и, например, была белая кнопка с чёрным текстом, а стала синяя с белым текстом. Надо этим надо подумать.
Как тебе такое, Qt?
А по факту я сейчас имею криво работающие горизонтальный прогрессбар и один такой со снаппингом.
Кстати, эта библиотека работает поверх моего графического движка и мне придётся расширять возможности каждого бекенда, чтобы на них работал мой ГУИ.
>>712333
Тоже страдал такой хуйнёй, бобёр, выдыхай, как говорится в старом анекдоте.
Тетрис это просто:
1. Генератор фигур. Возвращает массив 4 на 4 содержащий булевы. Далее фигура.
1.1. Поле для вывода следующей фигуры. Генератор может загружать фигуру сначала сюда, затем по требованию игры выдавать отсюда, а сюда следующую.
1.2. Поле для удержания фигуры. Обмен фигуры в этом поле и фигуры на игровом поле.
2. Проверка на возможность помещения фигуры (ниже, правее, левее). Принимает фигуру. Возвращает булево.
3. Смещение фигуры (ниже, правее, левее). Принимает фигуру, координаты. Выполняет обнуление игрового поля по старым координатам и прорисовку по новым.
4. Проверка заполненности полей. Выполняется один раз при остановке фигуры, работает снизу вверх, при обнаружении заполненной строки, убирает её, начисляет очки, сдвигает поле всё что выше на 1 вниз.
Всё, нахуй, никакие ООП-классы не нужны.
> Клон тетриса, если что
> целую кучу функций, типов и констант, есть даже ООП-шные классы
Тоже страдал такой хуйнёй, бобёр, выдыхай, как говорится в старом анекдоте.
Тетрис это просто:
1. Генератор фигур. Возвращает массив 4 на 4 содержащий булевы. Далее фигура.
1.1. Поле для вывода следующей фигуры. Генератор может загружать фигуру сначала сюда, затем по требованию игры выдавать отсюда, а сюда следующую.
1.2. Поле для удержания фигуры. Обмен фигуры в этом поле и фигуры на игровом поле.
2. Проверка на возможность помещения фигуры (ниже, правее, левее). Принимает фигуру. Возвращает булево.
3. Смещение фигуры (ниже, правее, левее). Принимает фигуру, координаты. Выполняет обнуление игрового поля по старым координатам и прорисовку по новым.
4. Проверка заполненности полей. Выполняется один раз при остановке фигуры, работает снизу вверх, при обнаружении заполненной строки, убирает её, начисляет очки, сдвигает поле всё что выше на 1 вниз.
Всё, нахуй, никакие ООП-классы не нужны.
Каким образом я могу в своем велосипеде максимальный фреймрейт в vsync привязать?
232 Кб, 1920x1080>>692117 (OP)
Кастомный движок в составе готовой игрры весом 200кб, 300кб хд мод, лол
2,5д фпс шутан на чистом С, без копирайта по сути.
https://gitlab.com/drummyfish/anarch
алсо что почитать на тему процедурной генерации, текстур например, уровней?
Кастомный движок в составе готовой игрры весом 200кб, 300кб хд мод, лол
2,5д фпс шутан на чистом С, без копирайта по сути.
https://gitlab.com/drummyfish/anarch
алсо что почитать на тему процедурной генерации, текстур например, уровней?
914 Кб, 1920x1080>>732568
+
Рендерит кастомная рейкаст либа 60кб,
апаратное 3д ускорение и обчисление плавающей точки- не требуется,
код минимальный\чистый, хорошо коментирован.
-
Из зависимостей с99, сдл2дев, системная либа,
кривая реализация мыши, от мыши проседает фпс
+
Рендерит кастомная рейкаст либа 60кб,
апаратное 3д ускорение и обчисление плавающей точки- не требуется,
код минимальный\чистый, хорошо коментирован.
-
Из зависимостей с99, сдл2дев, системная либа,
кривая реализация мыши, от мыши проседает фпс
>>732829
Да побарабану, каждая точка зрения имеет место быть.
Да побарабану, каждая точка зрения имеет место быть.
84 Кб, mp4,1350x850, 0:02
Как сделать физический движок (механики)?
Вот на видео уже используется примитивный графический движок, а куб я вращаю при помощи кватерниона. Всмысле, провожу операции с кватернионом, а потом превращаю в матрицу, которая передаётся в шейдер.
Но если посмотреть на сами кватернионы, то они же бесполезные в этом деле! Разве можно описать угловую скорость кватернионом? Нет! Когда я создаю кватернион из вектора и угла, над ними проводятся синус и косинус операции, то есть неважно, какой угол, скорость не получится сделать достаточно большой.
Я так понимаю, кватернионы надо выбросить и описывать угловую как скорость, так и положение просто вектором и числовым значением.
Вот на видео уже используется примитивный графический движок, а куб я вращаю при помощи кватерниона. Всмысле, провожу операции с кватернионом, а потом превращаю в матрицу, которая передаётся в шейдер.
Но если посмотреть на сами кватернионы, то они же бесполезные в этом деле! Разве можно описать угловую скорость кватернионом? Нет! Когда я создаю кватернион из вектора и угла, над ними проводятся синус и косинус операции, то есть неважно, какой угол, скорость не получится сделать достаточно большой.
Я так понимаю, кватернионы надо выбросить и описывать угловую как скорость, так и положение просто вектором и числовым значением.
Сука, ненавижу пилить движки
271 Кб, 1188x664>>692117 (OP)
Тред не читал. Вобщем мне уже 30 лет, но я не умею кодить. Я пытался, но каждый раз сливался из-за лени, депрессий и прочего. Ну и плана никакого не было. Не было цели. И вот я подумал - надо уже решаться и научиться кодить, стать специалистом в этой области хотя бы за 5 лет. Я смотрю в сторону Си - не спрашивайте почему и не отговаривайте. Я хочу написать игру с вот такой механикой https://www.youtube.com/watch?v=OUKzvX9-8F8 но без сюжетной линии, только оффлайновое пвп на одном компе, получается короче файтинг наверное. Ну если будет возможность запилить и онлайн версию. У меня нет цели прям заработать на ней или что, просто хочу научиться кодить и добавить эту игру к себе в портфолио если что. Дайте советов с каких книг начать, с чего бы вы сами начали и т.д.
Тред не читал. Вобщем мне уже 30 лет, но я не умею кодить. Я пытался, но каждый раз сливался из-за лени, депрессий и прочего. Ну и плана никакого не было. Не было цели. И вот я подумал - надо уже решаться и научиться кодить, стать специалистом в этой области хотя бы за 5 лет. Я смотрю в сторону Си - не спрашивайте почему и не отговаривайте. Я хочу написать игру с вот такой механикой https://www.youtube.com/watch?v=OUKzvX9-8F8 но без сюжетной линии, только оффлайновое пвп на одном компе, получается короче файтинг наверное. Ну если будет возможность запилить и онлайн версию. У меня нет цели прям заработать на ней или что, просто хочу научиться кодить и добавить эту игру к себе в портфолио если что. Дайте советов с каких книг начать, с чего бы вы сами начали и т.д.
>>741406
Ты похоже по диагонали читал - у меня нет цели заработать на ремейке или сделать убийцу die by the blade. Цель научиться кодить и стать миддлом за 5 лет.
Ты похоже по диагонали читал - у меня нет цели заработать на ремейке или сделать убийцу die by the blade. Цель научиться кодить и стать миддлом за 5 лет.
>>741410
Научиться кодить ЧТО? Какая предметная область? Кодить новые движки не нужно, учись работать в существующих.
Научиться кодить ЧТО? Какая предметная область? Кодить новые движки не нужно, учись работать в существующих.
Сильно
>>693907
Как раз таки это и является свободным. Не путай open source и free source.
> Остальные - виляние жопой - типа хочу быть свободным, но чтобы никто не украл мое авторство (а это не свободное).
Как раз таки это и является свободным. Не путай open source и free source.
Отвечаю в годный и адекватный тред
У меня возникла идея создать рил тайм стратежку с ролевыми элементами. Так вот, в основу идёт разрушаемость мира и и тд.
Так вот вопрос, возможно ли натягивание совы на глобус полигонов на воксельные модели.
Да понимаю что звучит тупо и не оптимально для нынешнего железа, но возможность смотреть как падают деревья и взрываются камни, не запечёным пререндером, меня просто вдохновляют писать код и изучать это проблему.
то есть цимес не про ультра разрушение, а про элегантность падения или деформирования тех или иных объектов на карте.
У меня возникла идея создать рил тайм стратежку с ролевыми элементами. Так вот, в основу идёт разрушаемость мира и и тд.
Так вот вопрос, возможно ли натягивание совы на глобус полигонов на воксельные модели.
Да понимаю что звучит тупо и не оптимально для нынешнего железа, но возможность смотреть как падают деревья и взрываются камни, не запечёным пререндером, меня просто вдохновляют писать код и изучать это проблему.
то есть цимес не про ультра разрушение, а про элегантность падения или деформирования тех или иных объектов на карте.
>>692281
я тя удивлю...
но питон в геймдеве используется по своему прямому назначению.
только не говорите ему про lua и Cython,а то он бедный инфаркт схватит
я тя удивлю...
но питон в геймдеве используется по своему прямому назначению.
только не говорите ему про lua и Cython,а то он бедный инфаркт схватит
>>780032
кста в кодинге я ноль без палки, но пережёвываю информацию и вроде понимаю матан и зачем нужна тригонометрия в 3д движках. За большое ещё не брался, но идеи просто заставляют их себя записывать и изучать Си и Пайтон дальше (нет я не дурачок, питон и правда полезная вещь, главное реализовать продукт, а допиливать ты его потом будешь, главное начать)
кста в кодинге я ноль без палки, но пережёвываю информацию и вроде понимаю матан и зачем нужна тригонометрия в 3д движках. За большое ещё не брался, но идеи просто заставляют их себя записывать и изучать Си и Пайтон дальше (нет я не дурачок, питон и правда полезная вещь, главное реализовать продукт, а допиливать ты его потом будешь, главное начать)
Чем грузите меши кроме ассимпа?
У меня какое-то проклятие - какую либу не беру, а мои модельки в моем движке грузятся в десять раз дольше чем в каком-нибудь другом с той же либой и в той же среде
У меня какое-то проклятие - какую либу не беру, а мои модельки в моем движке грузятся в десять раз дольше чем в каком-нибудь другом с той же либой и в той же среде
>>780354
Иди скачай уже fbx sdk.
Иди скачай уже fbx sdk.
У меня уже есть самописный графический движок. Где можно взять довольно сложную сцену для оптимизации, бенчмарков и всего такого?
>>785625
sketchfab.com
sketchfab.com
>>787238
Посмотрел пару игр которые на нем сделали. Печально.
Посмотрел пару игр которые на нем сделали. Печально.
>>787241
Решительно не согласен. Но допустим соглашусь лол. Меня беспокоит что Юнити на C#, а логику я уже написал на С++. Я C# отрицаю, не знаю и отношусь к нему с недоверием. Мне кажется что это новомодная поделка Майкрософта которые в последнее время написали много глючного копирующего чужие проекты софта. Они просто копирнули Java и сделали язык для веба который медленный по определению. Вот не понимаю - язык новый но он медленнее старого. Это как? В чем смысл? Просто выебнуться? Мне кажется да.
Решительно не согласен. Но допустим соглашусь лол. Меня беспокоит что Юнити на C#, а логику я уже написал на С++. Я C# отрицаю, не знаю и отношусь к нему с недоверием. Мне кажется что это новомодная поделка Майкрософта которые в последнее время написали много глючного копирующего чужие проекты софта. Они просто копирнули Java и сделали язык для веба который медленный по определению. Вот не понимаю - язык новый но он медленнее старого. Это как? В чем смысл? Просто выебнуться? Мне кажется да.
>>787254
Повторить на уровне X-COM2 реально? В смысле графики и физики?
>Кстати, в Годоте можно писать на с++.
Повторить на уровне X-COM2 реально? В смысле графики и физики?
>>787262
Я, наследие Unity, а это целая армия духов и бесконечная вера в успех. Лучше команды не найти во всей Галактике.
Я, наследие Unity, а это целая армия духов и бесконечная вера в успех. Лучше команды не найти во всей Галактике.
>>692146
Подводный камень всего один. Очень неоптимальная хуйня, если твои руки не из плеч и не золотые. Сделать ECS так, чтобы это работало быстро, довольно тяжело.
Это будет очень удобная и расширяемая штука, своего рода конструктор, куда можно легко добавлять новые детальки, но это все равно будет работать медленнее узкоспециализированного движка, заточенного под конкретные цели.
Если ты собрался делать не просто движок, а свой конструктор игр или планируешь моддинг в своей поделке, то полезно. Иначе не рекомендую тратить время, потому что не окупится.
Работаю в компании, где приходится дрочить на ECS, поскольку в нашей экосистеме свой язык программирования и конструктор игор
Подводный камень всего один. Очень неоптимальная хуйня, если твои руки не из плеч и не золотые. Сделать ECS так, чтобы это работало быстро, довольно тяжело.
Это будет очень удобная и расширяемая штука, своего рода конструктор, куда можно легко добавлять новые детальки, но это все равно будет работать медленнее узкоспециализированного движка, заточенного под конкретные цели.
Если ты собрался делать не просто движок, а свой конструктор игр или планируешь моддинг в своей поделке, то полезно. Иначе не рекомендую тратить время, потому что не окупится.
Работаю в компании, где приходится дрочить на ECS, поскольку в нашей экосистеме свой язык программирования и конструктор игор
>>790312
Не пытался бы писать ecs с нуля, а взял бы готовое.
Например, как в bevy сделано. Не знаю, как там работает под капотом, но есть 2 компонента, Transform и GlobalTransform, при апдейте трансформа глобальный пересчитывается системой с учетом всей иерархии. Возможно как раз через "хитрую" сортировку.
https://github.com/bevyengine/bevy/blob/main/examples/ecs/hierarchy.rs
>Как бы вы поступили?
Не пытался бы писать ecs с нуля, а взял бы готовое.
Например, как в bevy сделано. Не знаю, как там работает под капотом, но есть 2 компонента, Transform и GlobalTransform, при апдейте трансформа глобальный пересчитывается системой с учетом всей иерархии. Возможно как раз через "хитрую" сортировку.
https://github.com/bevyengine/bevy/blob/main/examples/ecs/hierarchy.rs
>>790312
Не надо на ЕЦС делать иерархию сцены. ЕЦС отдельно, граф трансформов отдельно.
Не надо на ЕЦС делать иерархию сцены. ЕЦС отдельно, граф трансформов отдельно.
>>790404
Без обхода графа - никак, но это не значит, что у каждой сущности игры должен быть компонент трансформ (как в юнити, например). Или что граф сцены должен что-то знать о ЕЦС (не должен). Просто каждый трансформ должен хранить ссылку на позицию в графе, который уже не является частью ЕЦС.
Без обхода графа - никак, но это не значит, что у каждой сущности игры должен быть компонент трансформ (как в юнити, например). Или что граф сцены должен что-то знать о ЕЦС (не должен). Просто каждый трансформ должен хранить ссылку на позицию в графе, который уже не является частью ЕЦС.
>>790410
Это совершенно ни к чему
>>790410
Тем, что ЕЦС и иерархия трансформов - это две подсистемы игры. Суть в уменьшении зависимости (decoupling). ЕЦС это не серебряная пуля, не надо пихать его везде.
>узел графа должен иметь ссылку на энтитю
Это совершенно ни к чему
>>790410
> или энтитя иметь ссылку на узел графа - а чем это тогда лучше просто компонента трансформа
Тем, что ЕЦС и иерархия трансформов - это две подсистемы игры. Суть в уменьшении зависимости (decoupling). ЕЦС это не серебряная пуля, не надо пихать его везде.
>>790416
А других и нет. Делай тогда на обычном ООП, зачем тебе декомпозиция тогда вообще.
А других и нет. Делай тогда на обычном ООП, зачем тебе декомпозиция тогда вообще.
>>790394
Это как? По ссылке рабочий пример кода с иерархией на ecs движке, который можно скомпилить и запустить.
Чем это не приближено к реалиям?
>приближенного к реалиям
Это как? По ссылке рабочий пример кода с иерархией на ecs движке, который можно скомпилить и запустить.
Чем это не приближено к реалиям?
Бб
Вверх.
Кто нибудь слышал или пробовал этот физический движок
https://github.com/DanielChappuis/reactphysics3d
https://github.com/DanielChappuis/reactphysics3d
>>843801
Зачем нужен движок на с++ от васяна, если physx, bullet и еще куча движков написанных профессионалами?
Зачем нужен движок на с++ от васяна, если physx, bullet и еще куча движков написанных профессионалами?
>>843825
Поэтому я и спросил, кто пользовался или слышал.
Соре, bullet написан мамонтами, может они и профессиАналы, а может и нет, и кста он тоже на с++, но код там так себе.
Может тут чувак все по уму переписал нормально.
Поэтому я и спросил, кто пользовался или слышал.
Соре, bullet написан мамонтами, может они и профессиАналы, а может и нет, и кста он тоже на с++, но код там так себе.
Может тут чувак все по уму переписал нормально.
>>843827
bullet писали и оптимизировали ученые математики
васян в лучшем случае просто скопировал готовый код оттуда, в худшем наговнокодил непонятно чего.
bullet писали и оптимизировали ученые математики
васян в лучшем случае просто скопировал готовый код оттуда, в худшем наговнокодил непонятно чего.
>>843877
СКАЧАЙ @ ПРОТЕСТИРУЙ
Зачем вот это вот всё вангование здесь писать?
>васян в лучшем случае просто скопировал готовый код оттуда, в худшем наговнокодил непонятно чего.
СКАЧАЙ @ ПРОТЕСТИРУЙ
Зачем вот это вот всё вангование здесь писать?
>>843881
Думаешь кто-то изобрел новый гениальный алгоритм расчета коллизий? О чем этот гитхаб? Об очередной реализации физики по туториалам?
Думаешь кто-то изобрел новый гениальный алгоритм расчета коллизий? О чем этот гитхаб? Об очередной реализации физики по туториалам?
>>692273
Как преподаватель со стажем скажу, что - нет. Многим людям он дается гораздо хуже как первый язык из-за вот этих вот значащих отступов. Поэтому советовать его новичкам или людям далеким от программирования не стоит.
>лучше всего учиться программировать на Python
Как преподаватель со стажем скажу, что - нет. Многим людям он дается гораздо хуже как первый язык из-за вот этих вот значащих отступов. Поэтому советовать его новичкам или людям далеким от программирования не стоит.
>>790334
так разраб bevy как раз свою реализацию ecs и писал, потому что другие были тормознутыми, он только в самых первых версиях движка взял готовое, потом выкинул и написал свое
> Не пытался бы писать ecs с нуля, а взял бы готовое. Например, как в bevy сделано.
так разраб bevy как раз свою реализацию ecs и писал, потому что другие были тормознутыми, он только в самых первых версиях движка взял готовое, потом выкинул и написал свое
ВСЁ!!!!!!!!
- Движок на C++.
- Скриптовых языков будет на старте три: C++, C# и какой-то свой «простой язык скриптования, чтобы облегчить вход в разработку начинающих специалистов».
- Визуальный скриптинг будет.
- Будет работать на любой ОС, «в том числе и Linux» 🙃.
- Web-билды будут, консольные версии «в проработке».
- Граф. движки: DX12, Vulkan и Metal. Будет и поддержка RT с DLSS. Хотят сделать «простой пайплайн» по работе с FBX, glTF или USD.
- Хотят запрыгнуть на хайптрейн и добавить ИИ-инструменты.
- Касательно «легаси-кода», ответили, что «в современных реалиях open-source разработки создавать комплексные решения с нуля, очевидно, не имеет смысла». Видимо, и правда за основу что-то готовое взяли.
это про нау энжин
- Движок на C++.
- Скриптовых языков будет на старте три: C++, C# и какой-то свой «простой язык скриптования, чтобы облегчить вход в разработку начинающих специалистов».
- Визуальный скриптинг будет.
- Будет работать на любой ОС, «в том числе и Linux» 🙃.
- Web-билды будут, консольные версии «в проработке».
- Граф. движки: DX12, Vulkan и Metal. Будет и поддержка RT с DLSS. Хотят сделать «простой пайплайн» по работе с FBX, glTF или USD.
- Хотят запрыгнуть на хайптрейн и добавить ИИ-инструменты.
- Касательно «легаси-кода», ответили, что «в современных реалиях open-source разработки создавать комплексные решения с нуля, очевидно, не имеет смысла». Видимо, и правда за основу что-то готовое взяли.
это про нау энжин
>>880874
По набору фич совпадает с годотом.
По набору фич совпадает с годотом.
10 Кб, 329x331>>880874
Мы будем отталкиваться от существующих технологий, поэтому наличие legacy-кода неизбежно. Также мы рассчитываем на вовлечение комьюнити в процесс разработки, а это означает, что большое количество кода будет написано сторонними командами и любой код будет содержать свои legacy-конструкции.
Мы будем отталкиваться от существующих технологий, поэтому наличие legacy-кода неизбежно. Также мы рассчитываем на вовлечение комьюнити в процесс разработки, а это означает, что большое количество кода будет написано сторонними командами и любой код будет содержать свои legacy-конструкции.
Нашел у себя обрывки книжки, по которой в юности изучал софтрендер на си
Там описаны алгоритмы дума и подобного. Заливка, пересечение полигонов. В сети есть djvu.
У автора еще предыдущая книжка с похожим названием гуглится, на ассемблере.
Там описаны алгоритмы дума и подобного. Заливка, пересечение полигонов. В сети есть djvu.
У автора еще предыдущая книжка с похожим названием гуглится, на ассемблере.