В качестве шапки https://github.com/deltafran/enginethread/blob/master/README.md
(на данный момент я только начал пополнять страницу - ресурсов очень много. Также приветствуются советы, по верстке, оформлению, наполнению.
Зачем нужна эта тема в 2020 году?
Ну кому-то движкоделие может быть само по себе интересным (не решайте за других что им делать и чем им увлекаться).
У кого-то могут быть свои особые требования (например уютный софтрендер, как например делает sb3d; 4D измерение; микровоксели или возможно редкие платформы под которые нет движков)
А возможно кому-то на работе дали приказ сделать движок.
Но еще раз - это не тема о движкосраче, это тема о разработке СВОЕГО движка и всех нужных для этого ресурсов.
Ну легче всего в 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д физику.
Пишу в единственный годный тред в /gd/. Какие у анона завалялись материалы по ECS? Может, какие-то советы, плюсы/минусы/подводные камни?
За пайплайны рендера кто пояснит? Читать книги не хочу. Хочу готовый говнокод.
Что тебе пояснять? Пайплан это очень условное название некого абстрактного куска, который отвечает за рендер и его порядок. То есть готовый говнокод ты не скопируешь, потому что такое на оче высоком уровне реализуется.
Вообще очень странный вопрос, лучше бы даже не начинал тратить время на движок, если всё готовое хочешь. Юнити бери.
> Что тебе пояснять?
Всё. Какие варианты рендера применять для Webgl 1/2, OpenGL ES 2/3, Open GL 3. Нихуя нипонятна.
> То есть готовый говнокод ты не скопируешь, потому что такое на оче высоком уровне реализуется.
На низком же. И в пайплайне составляются функции для высокого уровня.
> Вообще очень странный вопрос
Так пайплайн рендера, вместе с сценарным графом, по сути и есть весь движок. Всё остальное вторично.
Что значит "варианты рендера"? Книги читай, презентации смотри. Тебе нужно базовые концепты изучать, судя по всему. Всё не так просто.
На Юнити тоже можно свой условный пайплайн заебошить с помощью urp вроде.
> Что значит "варианты рендера"?
MRT, простой forward, воксельный свет, запеченные воксели и вот это всё.
> Книги читай, презентации смотри.
А шобы сразу говнокод был, протестированный и рабочий нету что ли? Это уже научные статьи. Разбирать их пиздец неудобно и долго.
> Тебе нужно базовые концепты изучать, судя по всему.
Не базовые, а какой-никакой сборник пайплайнов или либы пайплайнов и сценарных графов. Чтобы просто взял и подключил всё. Ну либо просто переписал логику.
> Всё не так просто.
Да я в курсе, поэтому и спрашиваю. Ебала какая-то пиздец конечно.
Я уже говорил, готовое ты что-то вряд-ли найдешь. Это очень высокоуровневая абстракция (плюс каждый может что-то свое под пайпланом понимать), то есть она тянет за собой кучу другого кода. Тогда уже и до движка недалеко.
Вообще, когда ты напишешь все шейдеры и эффекты, то не должно быть сложно из этого всего собрать пайплайн.
Джон Блоу одобряе
https://www.youtube.com/watch?v=pW-SOdj4Kkk
ИМХО лучше всего учиться программировать на Python. Потому что это простой и понятный язык, в который реально можно вкатиться новичку, и в то же время мощный, удобный, современный, хорошо описанный с кучей обучающих видео/статей/курсов, в том числе и посвященных именно программированию игр, плюс куча всевозможных УЖЕ написанных библиотек. Кроме того многие движки поддерживают Python или имеют очень похожий синтаксис. Начинать учиться прогать на крестах или шарпе - слишком сложно будет, все равно что начинать учить иностранный язык не с инглиша, а с латыни. Есть еще Java, но там много подводных камней, новичку не рекомендую.
> Тогда уже и до движка недалеко.
Ну по сути это и есть движок тащемта. Мне так кажется.
> Вообще, когда ты напишешь все шейдеры и эффекты,
Просто копирую и ворую, и в материалы/объекты вставляю всё. На похуе сделал инстансы для парочки vfx, получилось годно, через симуляцию магнитных полей уравнение движения сделол.
> то не должно быть сложно из этого всего собрать пайплайн.
А как сделать пайплайн просто не понимаю ни ху я. Все эти форварды-деференды. Чего блядь, как это должно работать с bgfx, например? Коакоак? Короче пиздец сложно. Даже если разбирать примеры рендера на js.
Мне кажется это первое чему должны обучать все эти книги.
Как делать пайплайн годный, как туда добавлять все меши, граф сцены и делать всяческие уравнения движения камерой. На это всё готовое любой нуфаг напердолит любую свою игру. Лишь бы это было. А этого почему-то нет. Странно это всё.
Питон в геймдеве не используется, это один из самых медленных языков, так что учить его в перспективе делать игры - пустая трата времени, потом все равно переучиваться на нормальные языки типа c+/c#.
(Автор этого поста был предупрежден.)
Спрашивай конкретные ответы. Что-нибудь посоветуем.
Прост пару статей из гугла по ецс прочитай, этого будет вполне достаточно.
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/
>Какие у анона завалялись материалы по ECS?
Я особо не шарю, но начал бы с этого
https://github.com/jslee02/awesome-entity-component-system
>А как сделать пайплайн просто не понимаю ни ху я. Все эти форварды-деференды.
Это не совсем пайплайны. Пайплайн - это конвеер, работает как завод
Форвард-деференд - это техники.
Forward - это когда ты прочитал книгу по OpenGl (или D3D или Vulkan) и сразу начал рисовать. Это прямая отрисовка. И ты сразу же столкнешься с проблемой - источники света, в форварде для каждого источника света надо рисовать всю связанную геометрию.
Поэтому придумали деференд - рисовать свет и связанное в отдельные текстуры, а их уже накладывать.
Потом придумали форвард плюс, так как деференд тяжелый
Потом придумали тайлед-деференд
Потом придумали Clustered shading - но мало кто использует
>Все эти форварды-деференды
Вообще вот тут https://triplepointfive.github.io/ogltutor/
есть уроки про деференд - 35/36/37 уроки.
или статья https://habr.com/ru/post/420565/
И конкретно по bgfx - у них же есть пример
https://bkaradzic.github.io/bgfx/examples.html#deferred
Просто начни с основ, и постепенно придет понимание - не гонись за модными словами. Ведь каждое из них решает некую проблему, и только зная эту проблему ты понимаешь цель этой техники.
Для простых игр хватит и форварда - то есть "делаешь как получится". 8 источников света - это уже классика на которой делали и квайки, и анреалы.
>А как сделать пайплайн просто не понимаю ни ху я. Все эти форварды-деференды.
Я не знаю цифр. Помогите освоить теорию чисел....
А воксельный GI ето что? Не зависит от пайплайна? Воксели дают охуенный результат так-то, все эти конусы. А как это с шадовмап совместить? Очевидно что карты теней будет еще лучше чем воксели, тому что можно в блендере их рассчитать, но воксели нужны для динамического света. Шадовмапы и воксели, например, они смогут выдавать хотя бы 60 фпс на вебжл/днопк?
>>692377
Втыкал в deferred.cpp или в github.com/bkaradzic/bgfx/tree/master/examples/16-shadowmaps и так нихуя и не понял. Ебаные 2к строк, пиздец просто, всё утро пытался структурировать нихуя не поня.
Наверное нужно реально выбрать стек, что-то вроде воксели, шадовмапы, форвардкластерплюс и просто сидеть изучать неделю подряд и прототипы делать на js, а потом переписать на плюсы. Но я даже не понимаю какой стэк эффективнее всего будет. Кластерный форвард нормально? Воксели? Хуексели. Вротебал.
>>692428
Просто хочу готовую маленькую, но удаленькую библиотеку конвейеров, просто взять и всё... Почему в этом мире всё настолько сложно......
Это воксель кон трейсинг.
https://github.com/JoeyDeVries/LearnOpenGL
https://learnopengl.com/book/book_pdf.pdf
https://github.com/JoeyDeVries/Cell
Вот с этого начни. Хотяб прочитай book_pdf.pdf. Там всё есть.
Это я уже пытался читать. Но там нету каких-нибудь примеров псевдокода или пояснений с вертухи про граф сцены.
Короче как я понял, лучше всего будет просто выпустить уже дрисяток говноигр на чужом говнокоде и чужом форвард рендере, а потом нанять топовых программестов которые всё это напишут, самый эффективные и минималистичные рендеры из существующих. Благо топовые погромместы вроде как не против.
> Но там нету каких-нибудь примеров псевдокода или пояснений с вертухи про граф сцены.
Это надо движки смотреть лучше. Огр какой-нибудь.
Меня в последнее время интересует вот что. Некий командный буфер для отрисовки: забиндить такие-то буферы я юзаю опенгл, такие текстуры, такой шейдер, отрисовать столько геометрии. Это не учитывая постпроцессинг в фреймбуферами и прочими штуками.
А про граф сцены можно глянуть как было в Думе 3 сделано. Там, как я понял, большой массив поверхностей (surface). Каждый кадр этот массив перестраивается и отрисовывается.
> Это надо движки смотреть лучше. Огр какой-нибудь.
Еще и огр разбирать ебать же работы. Годик придется убить только на это.
> Некий командный буфер для отрисовки
Вот кстати это тоже проблема. Нужен командный буфер, да и прост буфера всякие, понять как их организовывать правильнее всего. Литературы на этот счет дохуя, с пустословием в основном - примеров псевдокода почти нет, разве что разбирать конкретные движки.
> А про граф сцены можно глянуть как было в Думе 3 сделано.
В исходниках копаться? Ух ебать, страшно стало.
По думу 3 кстати можно всякие разборчики поискать
https://umumble.com/blogs/cpp/source-code-analysis-doom-3/
Если не разбираешься с этим несколько лет подряд - нихуя с наскока не понять.
видать это точно не моё, разве что требования к рендеру и движку составлять, эх епты бля
Ну если ты хотя бы в общих чертах понимаешь про устройство проц/гпу, типичные понятия по архитектуре кода, то это можно раскурить, просто первый раз надо чуть больше 5 минут посидеть.
Без этих знаний скорее всего действительно тяжеловато будет, слишком специфичная область.
Прочитал тред. Задепрессовал, ведь тут обсуждают только графику.
Вот скажите, если вы для физики сразу берёте Box2D/Bullet, то зачем вам графику самим делать?
Физику вы УЖЕ берёте чужую, уже движок получается не ваш. Почему бы и графику чужую не взять?
И вообще, если уж на то пошло, нужно свой OpenGL писать с нуля, чтобы движок был 100% твоим личным.
А ещё свою операционную систему и свой язык программирования, но это для особо упорных, ящитаю.
Я писал свою 2д физику, там буквально 200 строк: проверка столкновений и выталкивание объектов.
А я бы задумался о том, как сделать йоба звук. Вообще инфы нет.
На AABB кубиках что ли?
Ты бы попробовал OBB, или вообще произвольные фигуры, лол.
Плюс всякие некрасивые граничные случаи, пролет сквозь, десятки тысяч динамических объектов.
> Без этих знаний скорее всего действительно тяжеловато будет
Да тут не только в этом дело. Вот к примеру, какой самый эффективный рендер для качественных теней в webgl? Для gles3? Gl4.6? А если динамический свет?
Короче, нетривиальные задачи. Если писать под одну платформу - всё впринципе ясно-понятно, можно даже несколько рендеров скопировать и понять. Но каких-то объективных данных по тестам я так и не смог найти, по эффективности подходов. Есть только буквально обрывки информации и тесты-сравнения, без пояснений.
>>692557
> Почему бы и графику чужую не взять?
Личноя взял threejs тому шо под html5 нужно качественно сделать. Но самих рендеров не так и много на самом деле. А качественных и мультиплатформенных - вообще нет.
OBB. Алгоритм SAT для нахождения точки пересечения. Это очень кривая физика, для нормального выталкивания нужно рассчитывать не точку, а площадь. Но для простой игры сойдёт.
Я как раз делаю свой язык программирования и его компилятор-интерпретатор. Уже небольшие функции и типы данных можно писать, но не более.
Когда-то задумывался о том, чтобы сделать свой формат ассетов и использовать свой язык программирования в качестве встраиваемого в эти ассеты, чтобы запускать всякие там анимации, движения. И один ассет включал в себя другие, а в связке с настройками (например, рендеринг, физика и всё прочее) создало бы игру. Но мне не очень нравится геймдев, так что я пока собирался язык встраивать только в некоторые другие будущие проекты.
Уже написал свой софтрендер-рейтрейсер, может сферы и треугольники с освещением рисовать. У меня есть и библиотека-недоделка, которая описывает графический мир через вложенные ноды и рисует их через бекенды. Есть 2 бекенда — софтрендерный и GLSL-ный, оба производят рейтрейсинг. Но даже второй не очень производительный, штук 500 треугольников в 60 ФПС в FullHD потянет.
Когда-нибудь, может, попробую написать Пастрейсер и фотонтрейсер.
Когда доделаю язык программирования и его компилятор-интерпретатор, хотел попробовать запилить и физический движок. Можно несколько — механический, жидкостный, термодинамический, электродинамический. Если пойму, как описываются атомы, то и химический. Но все кроме механического (и жидкостного?) подходят скорее для всяких технических задач.
Потом и графическую либу, и свою ГУИ-библиотеку переведу на свой язык программирования и выпущу в открытый свет.
Почему каждый пилит свой движок? Почему бы не помочь развивать существующие опенсорсные?
Их нет, опенсорсных, чтобы подходил всем и все бы над ним работали. Большинство - рендеры под опенжл/dx.
Собратсья в улей люди не очень способны, нужны деньги и менеджмент.
Но вот ты можешь подобрать заброшеный движок - например, Urho 3D - и объявить себя его главным разработчиком.
Или форкнуть Годот, и соревноваться с Хуаном.
Вообще много увлекательных способов пилить движок, и не быть при этом никому не известным горбуном сидящем в своём подвале.
>Почему каждый пилит свой движок? Почему бы не помочь развивать существующие опенсорсные?
https://en.wikipedia.org/wiki/Not_invented_here
https://ru.wikipedia.org/wiki/Синдром_неприятия_чужой_разработки
>>692594
>Urho 3D
>Годот
Ты его ответ глазами читал или чем? Он же писал, >>692591
>чтобы подходил всем
Очевидно, приведённые примеры ему не подходят.
>и не быть при этом никому не известным горбуном сидящем в своём подвале
Если тебе это важно - вперёд и с песней. Некоторым сидеть в подвале намного приятнее и спокойнее.
>Уже небольшие функции и типы данных можно писать, но не более.
Я тоже несколько раз пробовал писать свой ЯП. И скажу честно, в долгосрочной перспективе это адЪ, потому что все эти функции-шмункции - пустяк, реализовать интерпретатор языка с функциями можно за несколько часов. Но в долгосрочной перспективе тебе придётся поддерживать огромный набор огромных API. Достаточно только взглянуть на WinAPI и ужаснуться. Зачем тебе API? Потому что ЯП без поддержки сторонних API - бесполезная игрушка, что-то вроде брейнфака - код писать возможно, но этот код ничего кроме простых арифметических операций делать не способен (ни файл с диска считать или записать, ни картинку на экран вывести, ни кнопочку нарисовать и нажатие на неё обработать). Пока ты пишешь интерпретатор на уже существующем ЯП, ты неявно используешь API системы благодаря готовым библиотекам этого ЯП, но когда тебе захочется сделать компилятор, чтобы твои программки выполнялись отдельно от чужого кода - тебе потребуется лезть во все эти дремучие API, если не в прерывания BIOS и коды процессора (зависит от того, во что будешь компилировать/транспилировать). Ну нафиг такое, даже если твой ЯП будет гениальным и лучшим в мире, без API он даже тебе ничем не поможет...
>>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
вроде такие списочки есть на гитхабе, но хуле бы свой не сделать.
>какой-то дикий оверхед делают, который нахуй нинужен ни при каких условиях типичной игори
Вот тут полностью согласен, самому хочется сделать простой худенький движок <100кб, но, видимо, не судьба.
Вообще тут всё от ЯП сильно зависит, если б ЯП умел выкидывать лишние функции из кода - было бы проще.
На самом деле мой компилятор не интерпретирует код, он интерпретирует исходники как, например, linux-ld.so интерпретирует ELF-файлы в процессы. Просто мой ЯП предназначен для исполнения из исходников, а компиляция в бинарники это дополнительная фича.
Немного неудачно написал.
Что насчёт API, то не вижу тут ничего слишком сложного. Что там в этом API надо? Писать в файлы, октрывать сокеты, управлять памятью. В линуксе всё просто, open, read, write, close, sbrk и ещё парочка системных вызовов. Думаю, в виндовсе тоже не слишком усложнены операции записи в файлы.
Что насчёт сокетов и управления памятью, я пока не знаю, но в линуксе всё-равно не очень много системных вызовов (около 100), а для виндовса наверняка можно найти библиотченые слои совместимости с линуксовым и использовать их.
Например, поддержку потоков (через отдельную библиотеку моего ЯП) я собирался реализовать, используя pthread, а он есть и под линукс, и под виндовс (хотя, может быть, я пересмотрю это решение). Надо будет просто слинковать библиотеку.
>ни картинку на экран вывести, ни кнопочку нарисовать и нажатие на неё обработать
Этим пусть занимается SDL2. Думаю, я сделаю программку для перевода хедер-файлов Си в библиотеку моего языка программирования (бинарная библиотека линкуется отдельно) и всё готово.
У меня уже есть недоделка библиотеки ГУИ (на C++), которая умеет создавать окна и рисовать туда, обрабатывать нажатия. И базируется она на SDL2, так что можно запустить хоть на линдовсе, хоть на вуниксе, на микроконтроллере (но программисту придётся написать реализацию SDL2 для него, либо использовать более низкоуровневые функции), так как моя ГУИ-библиотека базируется на моей графической библиотеке, а к ней уже есть софтрендер-рейтрейсер. Да, рейтрейсить ГУИ это сомнительная идея, но растеризатор я ещё не писал
>На самом деле мой компилятор не интерпретирует код, он интерпретирует исходники как, например, linux-ld.so интерпретирует ELF-файлы в процессы. Просто мой ЯП предназначен для исполнения из исходников, а компиляция в бинарники это дополнительная фича.
Я ничего не понял (в линуксе не разбираюсь). Компилятор не может интерпретировать код, компилятор код компилирует (преобразует текст в машинный код). Интерпретируют код интерпретаторы (непосредственно выполняют команды, соответствующие тексту). Компилятор и интерпретатор относятся к трансляторам, помимо них ещё есть транспилятор (отличается от компилятора тем, что транслирует код не в машинный код, а в исходный код другого ЯП). Если твой ЯП "предназначен для исполнения из исходников" - то у тебя интерпретатор.
Кстати, траспиляторы - возможный способ уйти от проблем с машинным/ассемблерным кодом. Можно компилировать в промежуточный ЯП типа C, а уже компилятор промежуточного ЯП будет заниматься созданием машинного кода. У этого способа есть свои недостатки, но по идее проще и удобнее, чем возиться с машинным кодом и API системы.
>Что там в этом API надо?
Всё, что там есть) Хотя по идее можно транспилировать заголовочные файлы из C в свой ЯП...
>Этим пусть занимается SDL2
Но его тоже придётся как-то линковать. А для этого нужны заголовочные файлы на твоём ЯП. А их писать нужно.
Короч писать ЯП - это интересно, но на сегодняшний день сильно бесполезно(
Специализированый движок под конкретную игру намного проще, чем движки общего назначения.
>>692557
Физику сложно качественно реализовать самому, рендеринг же с использование API вроде D3D пишется довольно легко.
> простой худенький движок <100кб
За тебя сделали Sokol и Oryol. Орёл потолще 100кб будет, сокол - то что тебе нужно. В 100кб кроссплатформенного кода уложишься.
Но лично я хз как сделать на этих пернатых полноценную игру готовую к продакшену. Исходники по 1к строк для теней только. Документация хорошая, но я нихуя не понял, тупой слишком.
https://github.com/floooh/sokol
https://github.com/floooh/oryol
> если б ЯП умел выкидывать лишние функции из кода - было бы проще.
Это делается при сборке. В теории, покрайней мере, на практике движкопицы редко занимаются обрезкой сборок под конфигурации. Даже библиотеки в одну свалку бросают.
> Исходники по 1к строк для теней только.
Примеры сокола, да. И примеры теней на 200 строк, загрузка gtlf2 - 1к. Там вроде есть какие-то ништяки, но. Но.
>>692639
Так движок общего назначения и не будет никогда "худеньким". Если для конкретной игры достаточно проверки столкновений прямоугольников в 200 строк кода, зачем тащить полную библиотеку?
> для конкретной игры достаточно проверки столкновений прямоугольников в 200 строк кода
Это уже какое-то 2d.
Если у тебя игра 2д, зачем тащить 3д?
Ну и наоборот, если игра 3д, то вряд ли нужны библиотеки для 2д анимации.
Не, я к тому что для любого 3d столкновений недостаточно. Придется оклюжены всякие тащить и 3d аудио.
> Если для конкретной игры достаточно проверки столкновений прямоугольников в 200 строк кода, зачем тащить полную библиотеку?
Если достаточно, то не надо тащить.
Если недостаточно, то надо тащить.
Тогда это должен быть не движок, а ворох различных библиотек: вот физика 1, вот физика 2, вот физика 3 и т. д.
> В исходниках копаться? Ух ебать, страшно стало.
Всё уже сделали за тебя. У Фабиана Сангларда где-то был разбор Дума 3
https://fabiensanglard.net/doom3/renderer.txt
https://fabiensanglard.net/doom3/doom3_notes.txt
Ебать. Ну да ладно поцаны, пойду игру делать, ебал я в рот это всё писать.
Если ты пишешь движок под конкретную игру, то будет только одна физика.
Движок - не обязательно монстр типа Юнити. Например idTech1 тоже движок, вполне себе компактный и под конкретную задачу.
Мне кажется, у тебя какое-то старомодное отношение к програмимрованию.
>Если твой ЯП "предназначен для исполнения из исходников" - то у тебя интерпретатор.
Хорошо, у меня интерпретируемый язык программирования, где можно написать только одну, но очень длинную команду, раскиданную по нескольким файлам. Так же как линуксовый линковщик интепретирует ELF-файл (+ библиотеки) в процесс или виндовсовский экзекутор интерпретирует .exe в процесс или что там.
На самом деле, грань между компиляцией и интепретацией не такая уж и жёсткая. Ведь часто и команды интерпретируемых ЯП JIT-компилируются.
>в промежуточный ЯП типа C
Современные модные молодёжные языки программирования используют компиляцию в LLVM IR, а из него уже компилируется в любой поддерживаемый машинный код.
Так я делаю и со своим языком. По правде, я его перевожу сначала в свой промежуточный формат, который когда-нибудь станет байткодом как в джаве или питоне, а потом его в LLVM IR.
>А их писать нужно
Да. В случае с линуксом сделать интерфейс к сотне самостоятельных системных вызовов — проще простого. Для SDL2 уже сложнее, поэтому следует сделать утилиту для перевода хедеров си в код моего ЯП.
В моём ЯП, кстати, поддерживаются многие сишные типы, а ABI стандартный, так как им занимается LLVM, так что это действительно не сложно.
Что сложнее, так это совладать с кодом. Компилятор я пишу на питоне (как бы это странно не звучало) планирую потом на мой ЯП переписать, а я не очень разбираюсь в ООП и вообще наговнокодил, что перебирать и перебирать.
>Так же как линуксовый линковщик интепретирует ELF-файл (+ библиотеки) в процесс или виндовсовский экзекутор интерпретирует .exe в процесс или что там.
Ой все
>вроде такие списочки есть на гитхабе, но хуле бы свой не сделать.
Постепенно сделаю по ссылке. Примерно в таком же виде. Просто всего много, надо еще и собрать
>виндовсовский экзекутор интерпретирует .exe в процесс или что там
Исполняемый файл не интерпретируется. Он загружается системой в оперативную память целиком, после того, как прошёл проверку по заголовку на корректность. И исполняется процессором как набор машинных кодов (с данными, но данные в отдельном сегменте). Да, разумеется, центральный процессор - это физическая реализация интерпретатора машинных кодов, однако когда речь идёт об "интерпретации кода", подразумевается программная интерпретация: программа-интерпретатор по байтам/по словам/по строкам считывает код, ищет в словаре соответствующие машинные команды/наборы команд и исполняет их (т.е. транслирует кусочки программы только когда нужно их исполнить).
>Что сложнее, так это совладать с кодом.
>я не очень разбираюсь в ООП и вообще наговнокодил, что перебирать и перебирать.
Имхо, часто лучше переписать с нуля, так код получится компактнее и понятнее, чем был с первой попытки. Вторая попытка займёт немного времени, ведь выдумывать намного меньше, чем первый раз.
>Мне кажется, у тебя какое-то старомодное отношение к програмимрованию.
А я не вижу смысла накручивать какие-то новомодные штучки, если от них куча проблем, а работать можно и без них)
Я вот забил на выдумывание своего языка ещё и потому, что осознал, что мне он и не нужен в общем-то. Что я на нём буду писать? Какие задачи решать? У меня по жизни почти не бывает таких задач, для решения которых нужно было бы писать программу, а если такая задача и появляется, то проще и быстрее всего решить её на лучше всего известном мне Pascal. Да, когда-то я мечтал о том, что придумаю ЯП, который многократно ускорит процесс решения задач, но теперь я понимаю, что самое главное в программировании - это придумать/найти/понять алгоритм, а реализация алгоритма мало зависит от применяемого языка. И вот придумывать алгоритмы никакой ЯП не поможет...
>Так движок общего назначения и не будет никогда "худеньким".
Будет, если будет написан на языке, поддерживающим частичную сборку (изолированный код отбрасывается).
>>692674
>Тогда это должен быть не движок, а ворох различных библиотек: вот физика 1, вот физика 2, вот физика 3 и т. д.
Зачем? Ну вот, допустим, у нас есть:
- проверка коллизий 2д фигур: круги, прямоугольники, линии
- проверка коллизий 3д фигур: сферы, параллелепипеды, линии
Итого 6 разных функций. Если мы из своего кода обращаемся только к одной из этих 6 функций (прямоугольники), то остальные 5 нам не нужны, так? Да, если мы где-то в движке неявно их вызываем, то они нам нужны, но если мы не делаем необдуманных вызовов, то они нам не нужны. А раз не нужны, то в игру (.exe) их можно просто не включать.
Вообще, любую программу можно рассматривать как дерево процедур/функций. Главная процедура - это собственно программа (program в Pascal, void main в C и т.д.), из которой вызываются процедуры первого уровня, из которых вызываются процедуры второго уровня, из которых - третьего, и так далее до самых примитивных процедур, "листьев" дерева кода. Нетрудно догадаться, что если мы написали какую-то ветку кода, а затем разорвали единственную связь между этой веткой и остальным деревом (закомментировали вызов корневой процедуры данной ветки), то наша ветка становится бесполезной - полностью изолированной от остального кода, и вставлять её в исполняемый код будет неблагоразумно. Почему бы не отбросить эту лишнюю ветку?..
Кстати, я слышал, что именно так и делает компилятор C/C++, т.е. не оставляет неиспользуемое в исполняемом коде, но в таком случае для меня остаётся загадкой, почему современное ПО, которое якобы почти всегда пишется на C++, так сильно жиреет. Ладно там игровые конструкторы типа Unity, но что на счёт реальных движков, для запуска игры на которых нужно произвести сборку кода игры вместе с кодом этого движка?
Дык FFI с C в помощь. Если в твоём супер-языке есть FFI C, всё, считай, у тебя есть и WinAPI, и POSIX API, и какое угодно API а если разработчику не нужно для этого руками писать биндинги, вообще улёт
>А раз не нужны, то в игру (.exe) их можно просто не включать.
Они и не включаются. Компилятор выкидывает - об этом в студии даже есть специальный варнинг (что-то типа "данная функция нигде не используется, она будет исключена из кода")
Кроме того, как лучше реализовать физику в стиле GTA 2? Я кое-как сделал физику кругов на плоскости, но так и не смог реализовать правильные отскоки (не знаю, как посчитать вектор отскока без использования сложных вычислений). А с прямоугольниками вообще непонятно что делать. И как быть с разными уровнями карты (в GTA 2 есть дороги под наклоном и даже лестницы)...
Это если все линковать в один бинарник. А если делать длл то все что экспортируется, то не выкинется.
Зачем делать длл с движком? DLL нужно только в двух случаях - когда функции DLL используются несколькими независимыми программами (изначальный замысел DLL, сегодня с ростом объёмов памяти это неактуально), или когда функции DLL нужно вызывать из кода на другом языке, но мы же тут пишем свои игры на своём движке, т.е. и игра, и движок на одном языке. Ещё по идее на неё немного другие лицензионные блаблабла, но лицензионный бред оставьте лицензионным бредологам. Ненавижу опенсурс за то, что приходится разбираться в лицензиях, тысячах лицензий!
> не знаю, как посчитать вектор отскока без использования сложных вычислений
Ничего там сложного нет, простейшая система диффуров - второй закон Ньютона да закон сохранения импульса.
> Ненавижу опенсурс за то, что приходится разбираться в лицензиях, тысячах лицензий!
Единственная лицензия, о которой как программисту приходится задумываться, это (L)GPL. Окей, две лицензии. Все остальные по сути означают "бери и пользуйся на здоровье, никто тебе ни слова ни скажет".
>система диффуров
Из курса математики я выпал примерно в 8-9-м классе, в 10-11 мне ставили тройки за красивые глаза...
>>693112
>бери и пользуйся
Если б всё так просто было. Нужно ведь ещё авторов указать (или не нужно), текст лицензии приложить (или не нужно) в каком-то определённом формате (или неопределённом), ссылку на оригинал дать (или не давать), указать список изменений (или не указывать)... Ну уж нет, лучше я напишу велосипед или совсем программирование брошу, чем буду насиловать себе мозг такими бессмысленными деталями. Вот как хорошо было бы, если бы были только собственнические лицензии - ты ничей код использовать не можешь, сидишь себе велосипед попиливаешь, но велосипед этот 100% твой, никто у тебя его отобрать не может и засудить на огромные бабки за разработку этого велосипеда тоже не может... Да, медленно, да, долго, зато безопасно и надёжно, т.к. варианты исхода известны (ты либо напишешь велосипед и получишь профит, либо не напишешь и не получишь, а не как с использованием чего-либо стороннего - подключил либу и дальше тебя ждёт неизвестно что).
> Если б всё так просто было.
Наверняка в гугле есть удобная таблица, в которую сведены все особенности свободных лицензий. Но мне влом её искать за тебя.
> Если б всё так просто было. Нужно ведь ещё авторов указать (или не нужно), текст лицензии приложить (или не нужно) в каком-то определённом формате (или неопределённом), ссылку на оригинал дать (или не давать), указать список изменений (или не указывать)... Ну уж нет, лучше я напишу велосипед или совсем программирование брошу, чем буду насиловать себе мозг такими бессмысленными деталями.
Всё это хуйня. Просто тебе нужны лицензии полностью свободные - BSD. Всё остальное можешь пропускать мимо.
Да, есть: https://tldrlegal.com
>>693206
Ты не понимаешь, о чём говоришь. MIT, например (которая на самом деле не MIT, а X11/Expat), ещё "свободнее", чем BSD (трёхпунктная, по крайней мере) - тупо меньше условий в тексте лицензии.
Самая свободная вот http://www.wtfpl.net/ (способ отдать работу в общественное достояние)
Но я лично не хочу вкладывать в свой софт файл с чужим именем (почему я вообще должен давать ссылку на какого-то Сэма?). И что значит "changing it is allowed as long as the name is changed"? Как вообще возможно закопирайтить такой огрызок текста? Получается, не может существовать WTFPL-лицензии с другим текстом, потому что изменяя текст, меняется и название? Бред какой-то. Даже в писательстве и кинематографе нет такого строгого ограничения на совпадающие имена... Короче, не хочется лезть в это дерьмо, ни как лицензиат, ни как лицензиар, а то вдруг засудят.
О, представьте, что вы собираете движок из готовых библиотек, библиотеки линкуете статически, результатом выходит один-единственный exe (как у годота). В итоге у вас в папке \движок\ будет один файл движка и несколько десятков файлов лицензий. Почему не объединить в один файл или не зашить прямо в exe? Потому что "менять текст лицензии нельзя" (конкатенация = изменение; перекодирование, кстати, тоже изменение) и потому что "текст лицензии должен быть доступен без запуска приложения", то есть по факту тот же готот нарушает условия лицензирования (запечатывает лицензию внутри exe и не содержит копии в txt-файле). Бред какой-то, ну нафиг такое.
> Но я лично не хочу вкладывать в свой софт файл с чужим именем (почему я вообще должен давать ссылку на какого-то Сэма?
Потому что ты используешь труд другого человека, и публично признать, что ты это делаешь - это самое меньшее, что ты можешь сделать. Обрати внимание, тебя не просят за его труд отдавать деньги, тебя просто просят сказать "да, я использовал труд Сэма", просто чтобы ему было приятно. Твой подход к этому вопросу выдаёт в тебе малолетнюю свинью - тебе бесплатно дают крутые вещи, а ты хочешь их брать и взамен не отдавать вообще ничего.
> Получается, не может существовать WTFPL-лицензии с другим текстом, потому что изменяя текст, меняется и название?
Разумеется. Представь себе, что я возьму текст GPL, напишу в нём "ты сосёшь хуи" и буду распространять свой софт по этой лицензии, и внезапно масса людей оказываются ни за что ни про что зашкваренными.
> несколько десятков файлов лицензий
Ёбаный рот, с каких пор на двачах по Ctrl-enter отправка?
Так вот,
>>693236
> несколько десятков файлов лицензий
Необязательно лицензии в отдельные файлы складывать, можно заставлять тикнуть чекбокс "да, я в курсе про лицензии" при загрузке, можно показывать license agreement в инсталляторе, можно в сплэш-скрине одной строчкой, мол, this software uses libblah library which is MIT-licensed, see https://github.com/libblah/LICENSE for details. Тут возможны варианты.
> Бред какой-то, ну нафиг такое.
Да нет, просто ты малолетний долбоёб-неосилятор.
> Ты не понимаешь, о чём говоришь.
Прекрасно понимаю. Бсд и мит просто обычные свободные лицухи с тремя-двумя пунктами, для дэбилов.
>>693236
> Но я лично не хочу вкладывать в свой софт файл с чужим именем
Не с чужим именем, а лицинезией и с выполнением условий лицензии. Чужое имя это условие лицензии.
> Получается, не может существовать WTFPL-лицензии с другим текстом
Да. Лицензия защищает саму себя, в этом суть лицензий тащемта. Лицензия это как бы программный код исполняемый судами и юристами, ты записываешь в лицензии определённое поведение.
> потому что изменяя текст, меняется и название? Бред какой-то.
Это не бред, это необходимо для выполнение условий определённого поведения. Ты программист вообще или кто нахуй?
> по факту тот же готот нарушает условия лицензирования (запечатывает лицензию внутри exe и не содержит копии в txt-файле).
Нарушать лицензирования можно, но только БСД лицензий, потому что нужно выявить нарушение - чтобы истец предъявлял требования. БСД-подобные лицензии предъявлять тебе что-то там не будут.
> Бред какой-то, ну нафиг такое.
Нет, бред это делать велосипед, когда есть bgfx.
>Нарушать лицензирования можно, но только БСД лицензий, потому что нужно выявить нарушение - чтобы истец предъявлял требования
Пиздец, у тебя русский - не родной язык, что ли?
> Просто тебе нужны лицензии полностью свободные - BSD
> для дэбилов
Да ещё и с биполярочкой.
>тебе бесплатно дают крутые вещи
>крутые вещи
>текст лицензии, состоящий только из
>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
>Лицензия это как бы программный код исполняемый судами и юристами, ты записываешь в лицензии определённое поведение.
О, спасибо, единственное разумное объяснение смысла лицензий. Вот только учитывая багнутость и уязвимость судов, нестабильность и неэффективность юристов, смысла их программировать нет, лучше выкинуть на свалку истории (или в музей машин прошлого) и заменить более надёжными и эффективными машинами... Это всё равно что программировать сегодня под какой-нибудь компьютер из первой половины прошлого века - можно, но зачем?.. ...так, падажжи, эта аналогия зашла слишком далеко.
>Нет, бред это делать велосипед
Но если я не сделаю велосипед, то чем я смогу гордиться? Тем, что нажал кнопочку "сделать зашибись" на чужом изобретении?
>Но если я не сделаю велосипед, то чем я смогу гордиться? Тем, что нажал кнопочку "сделать зашибись" на чужом изобретении?
Не забудь сделать свою ОС, чтобы Гейтс у тебя славу не украл.
Он прямой, не пизди. Одна из самых прямых либ.
>>693272
Ну и что это ты высрал? А главное, зачем?
>>693283
> Вот только учитывая багнутость и уязвимость судов, нестабильность и неэффективность юристов,
Так говорю же - доказательство нарушения лицензии (или хотя бы инициировать проверку) должен предъявлять истец. В случае бсд никто не будет этим заниматься.
> компьютер из первой половины прошлого века - можно, но зачем?
Скорее просто как под язык с тысячами возможностей неопределённого поведения.
Компухтер из первой половины прошлого века всё же имел вполне определённое поведение.
> Но если я не сделаю велосипед, то чем я смогу гордиться? Тем, что нажал кнопочку "сделать зашибись" на чужом изобретении?
Ты не сможешь в полной мере гордится велосипедом. Это же велосипед. Он ничего нового не приносит, ничего нового не создает. Можешь статью написать, но статей с описанием велосипедов дохуя уже. Может ты что-то и поймешь новое, при создании велосипеда. Но вряд ли.
А вот если ты сделаешь что-то реально полезное, то чего нет, то что никто до тебя не делал. У тебя не только повод для гордости будет.
Но ведь нет же. Вместо этого новый тип срача изобрести решили. Лицензиосрач.
Этот тред просто попытка протечь из срачезагона..
Срач про лицензии -- одна из самых унылых вещей, которые я когда-либо читал. А начинался тред неплохо.
Прежде чем начать делать движок, надо определиться с лицензией.
Есть только одна православно верная опенсурс лицензия - CC0.
Остальные - виляние жопой - типа хочу быть свободным, но чтобы никто не украл мое авторство (а это не свободное).
Херня это, кому надо и так нарушит и плевал на писульку в файле License, достаточно обфуцировать код и никто не докажет что там было - mit или gpl (если не майкрософт и не эпл, то никто даже и не будет пытаться)
> Если б хоть один из вас, срущихся ИТТ, действительно делал свой движок
Я делаю. Но мимо детей-максималистов пройти мимо не могу.
Вот этот малолетний долбоёб, например: не понимает разницу между авторскими и исключительными правами, но Мнение Имеет.
Какая разница? Все эти якобы попенсурсные лицензии имеют ограничения - например надо обязательно указывать авторство оригинала.
CC0 же в свою очередь полный отказ от всех прав и передача в общественное пользование - поэтому не ибет, авторские, исключительные или еще какие либо..
И да, мой код я всегда выкладываю под СС0.
> И да, мой код я всегда выкладываю под СС0.
Учитывая твой психологический возраст, твой код нахуй никому не нужен.
>Есть только одна православно верная опенсурс лицензия
>>693680
>Прежде чем начать делать движок, надо определиться с лицензией.
Можно для себя писать.
Для самого себя лицензия не нужна.
Вероятность что твой код заинтересует кого-то другого примерно равна вероятности стать космонавтом. В эпоху-то юнити и анриалов с гейммейкерами.
Так что вы аноны зря о лицензиях вообще думаете.
Мой код с гитхаба включили в программу Artic Vault, так-то. А твой включили?
>Учитывая твой психологический возраст, твой код нахуй никому не нужен.
Ну да - типикал двачер
Главное не вляпаться в GPL. А то когда вам принесут денюшку, будете страдать. Вот как они
https://github.com/TurningWheel/Barony/pull/521
Хотя в их случае то понятно, barony так-то коммерческая игра, поэтому вляпали gpl , как Кармак думы с квайками выкладывал.
Но как начали делать порт под nintendo, так "свободная" лицензия сказала "хуй вам".
Если в твой код никто другой не контрибьютит, вообще не важно какая у твоего кода лицензия, ты обладаешь всеми правами и можешь менять лицензии, закрывать код, выпускать под GPL и продавать коммерческие лицензии.
Можешь вообще никакой лицензии не указывать (это означает что на твой код можно смотреть, но нельзя использовать).
>Но как начали делать порт под nintendo, так "свободная" лицензия сказала "хуй вам".
"Хуй вам" сказал коммерческий отдел Nintendo, а не свободная лицензия. Не нужно очеловечивать свободные лицензии, они этого очень не любят)))
Только вот будешь вместо игры пердолиться с костылями движка. Особенно если твоя игра - что-то сложнее ангриберда
> например уютный софтрендер, как например делает sb3d
олдфаги всплакнули по картошке
Ты описал самый простой вариант. С которого можно начать.
Но в идеале конечно всё намного сложнее.
Нажатия клавишь запоминай отдельно. Делаешь флаги для каждой, со статусами типа "сейчас нажата" и другими.
Действия персонажа это другая система. Есть несколько общих решений как привязывать действия ко времени, но концептуально ты либо вызываешь действие один раз за отрисовку, передавая дельту времени, либо вызываешь действие различное количество раз за кадр. Где количество вызовов отражает подстройку под текущий фпс игры.
Вообще не пытайся всё сразу.
Начни с малого. Например научись точно ограничивать фпс игры. Научись таймер точный юзать.
>на сто клеток влево, как фиксить?
Через дельтатайм. Короче, суть такая - замеряешь время которое у тебя тратится на один кадр и умножаешь на скорость движения.
гугли main loop delta time
вот тут хороший пример
https://codeincomplete.com/articles/javascript-game-foundations-the-game-loop/
Чтобы перс не телепортился, нужно либо уменьшать скорость движения до дробных чисел( типа 0.001), либо делать паузы между движением (если это пошаговое). Дельта-тайм же гарантирует что движение не будет зависеть от фпс
>Тут уже вроде как не подходит массив, тогда что?
Тут есть несколько подходов. Для тетриса или рогалика достаточно двухмерного массива.
Еще вместо клеток юзают шестиграники (например в героях меча и магии)
Еще клетки могут быть мелкими - например так было в warcraft 2 - вся карта разбита на клетки, но они маленькие, из-за чего создается ощущение плавного движения, хотя на самом деле там движение по клеткам.
Еще есть вариант - смещения между клетками - мир разбит на клетки, но есть анимация перемещения из одной клетки в другую (при этом нельзя встать между клетками) - так сделано в рпг макере
В случае же платформеров делают по другому - любой объект имеет объем/форму, и просто зная курс геометрии мы можем узнать попадание объема игрока в объем земли, и в соответствии этого делаем реакцию - например не даем проваливаться игроку сквозь платформу.
Гуглить коллизии (collision), можно посмотреть на box2d - это двухмерная физика, она обычно не нужна для простых игр, но просто позволит понять как это делается. Или в ютубе поискать ролики по платформерам в юнити (это не рекомендация брать юнити - на готовом движке можно увидеть суть не отвлекаясь на всякие мелкие детали)
>Делаешь флаги для каждой, со статусами типа "сейчас нажата" и другими.
Эммм, я хз как там на ассемблере, конечно, но вроде на любом нормальном языке есть события press_down, press_up и тп
>Например научись точно ограничивать фпс игры. Научись таймер точный юзать.
И как это сделать?
>Короче, суть такая - замеряешь время которое у тебя тратится на один кадр и умножаешь на скорость движения.
Так кадры разные могут быть же. Один 12мс а другой писят
>Чтобы перс не телепортился, нужно либо уменьшать скорость движения до дробных чисел( типа 0.001)
Хуйня из под коня, на разных машинах по разному будет, у меня, допустим, рендерится 150 кадров в секунду, а у другого человека 24 и чо, у меня же преимущество будет, скорость движения будет различаться
>Еще вместо клеток юзают шестиграники (например в героях меча и магии)
Не охото ругаться, но ты адекватен, вообще? Программировал когда-нибудь? Какие нахуй шестигранники в коде? Покажи мне код, который шестигранниками оперирует - массив это просто квадрат ячеек по сути
>Гуглить коллизии (collision), можно посмотреть на box2d - это двухмерная физика, она обычно не нужна для простых игр, но просто позволит понять как это делается. Или в ютубе поискать ролики по платформерам в юнити
За это спасибо большое, погляжу на досуге
нихуя ты дебил поехавший.
просишь совета, а говоришь как скотина, ругаться неохота хуесосу
тебе сказали что шестигранники в игре, ты в глаза долбишься? какой массив?
Покажи мне реалиацию шестигранников не на массивах, пидор ебаный, ну, давай
кто пидор, ты пидор ёпта
ещё и тупой
тебе блядь никто вообще про реализацию слова не сказал, осёл
он же блядь тебе пишет, еблан
первый вариант - массивы
и перечисляет примеры
потом второй вариант - смещения
итд
>Один 12мс а другой писят
>>697253
>рендерится 150 кадров в секунду, а у другого человека 24 и чо
Для этого и нужно чтобы ты изучил термин delta time.
смотри. у тебя 60 фпс. это 16 мс на кадр.
Умножаешь скорость 10 на 16 = двигаешь на 160
У тебя 120 фпс. это 8 мс на кадр. умножаешь 10 на 8 - двигаешь на 80. То есть у тебя в два раза больше кадров, поэтому ты двигаешь меньше. Если кадров меньше, то двигаешь больше.
>Не охото ругаться, но ты адекватен, вообще? Программировал когда-нибудь? Какие нахуй шестигранники в коде?
А кроме массивов ничего больше нет? Например списки? Деревья?
вот случайный пример про шестигранники - https://github.com/chenjie199234/HexagonMap
Тебе с таким подходом будет очень тяжело если захочется что-то про не евклидову геометрию, где в принципе вся логика ломается
>но вроде на любом нормальном языке есть события press_down, press_up и тп
Это события не языка, а операционки. Она эти события тебе передаёт. А сохранять статусы клавишь надо, чтобы ты мог их юзать из любого места твоей программы.
Если ты прямо в коллбэке где получаешь нажатие "стрелочки влево" начнёшь писать код движения персонажа влево, то далеко так не уедешь. Впрочем, для первого теста работоспособности сойдёт.
>научись точно ограничивать фпс игры. Научись таймер точный юзать.
>И как это сделать?
Разве не очевидно? Чекаешь таймер в главном цикле игры, если с момента отрисовки прошлого кадра уже прошла 1/60 секунды, то вызываешь новую отрисовку кадра.
Произвольная дельта в вызовах физики иногда приводит к проблемам. И вообще требует более внимательной реализации, это доп-нагрузка на кодера.
Схема с фиксированной дельтой считается более простой в написании и более надёжной.
Ставишь фиксированную дельту к примеру на 2 мс, тогда при 60фпс будешь вызывать физон 8 раз за кадр, а при 120фпс вызываешь 4 раза за кадр.
Однако, затраты процессорного времени у такого решения выше.
Просто для уточнения возможных вариантов пишу.
Пойди дальше. Посмотри на эту пикчу и мысленно распрями боковые рёбра шестиугольников в ровные линии. Что получится?
Ответ на обороте страницы:
Прямоугольная сетка со сдвинутыми на 1/2 столбцами.
Так и в каком месте это шестиугольники, если это просто ебаный массив?
>А сохранять статусы клавишь надо, чтобы ты мог их юзать из любого места твоей программы.
>
>Если ты прямо в коллбэке где получаешь нажатие "стрелочки влево" начнёшь писать код движения персонажа влево, то далеко так не уедешь. Впрочем, для первого теста работоспособности сойдёт.
В общем, делаю так - при нажатии клавишы ее id сбрасывается в список нажатых клавиш, но перед тем как туда его сбросить сам список чекается, не была ли уже нажата эта клавиша. Типо, так?
>Чекаешь таймер в главном цикле игры, если с момента отрисовки прошлого кадра уже прошла 1/60 секунды, то вызываешь новую отрисовку кадра.
Почему именно 60? Ага, старая еще не досчиталась, а уже новая начала считаться, чет не комильфо как то
Пока ты будешь вручную пересылать массивы флоатов в вертексы и текскоорды и юниформить материалы, успешный геймдевелопер в пару функций загрузит модельку и скажет движку "Рендерь!". Ещё и проанимирует, и булевые операции, всякие модификаторы на вертексы применит, систему частиц абстрагирует, оптимизирует рейтрейсинг какими-нибудь октодеревьями и отрежет от отрисовки-растеризации то, что находится сзади.
Ну и как ты сказал, разные бекенды.
Я и сам потихоньку пилю свой графический движок, планирую добавить 3 бекенда: демо OpenGL (возможно без поддержки всяких материалов и теней, но может и добавлю), рейтрейсинг на GLSL, рейтрейсинг на софтрендере. Может ещё когда-то софтрастеризацию...
Причём с свой движок я бы добавил примитивы такие как Треугольники и Нурбс. + generic собственный объект, но разработчику придётся писать обработчики всякие под каждый из бекенд. Подумываю ещё, может воксельное октодерево добавить?
Вот, а для опенгла тебе придётся аппроксимировать тот же нурбс, сделать его треугольниковым.
>если проект чисто учебный
Если учебный, то можно и опенгл. Давай, иди учи свои glBegin и glEnd, а потом узнай, что это 20-й век и современные опенглы перебирают шейдерами, а вместо пересылки вертекс+текскоорд+колор просто массивы флоатов, из которых шейдер выберет, где вертексы, где нормали, где какие-нибудь эффекты и прочее.
Но я не совсем разобрался с набором материалов. Сразу скажу, что мой движок предназначен прежде всего для рейтрейсинга.
Вот что я надумал:
0. RGBA — цвет + прозрачность. Тут всё понятно, диффузный цвет.
1. reflect 90° и reflect для 0°. Обозначает коэффициент от 0.0 до 1.0, сколько света должно отразиться для того или этого градуса. Для промежуточного угла линейная интерполяция от этих коэффициентов. Ещё можно сделать так, чтобы коэффициенты были разные для каждой RGB компонент.
2. Чёткость отражения. Если посмотреть на металлы, может быть, то можно заметить что в одних случаях отражение может быть чётким и зеркальным, а может быть размытым и зеркальным. Ещё можно заметить, что у всяких листовых металлов чёткость отражения отличается в зависимости от ориентации. Смотришь вертикально и видишь своё лицо, а горизонтально и оно размыто. Вопрос: Как это реализуется на практике и какие физические процессы стоят за этим в реале?
3. Степерь преломления. Тут вроде всё понятно, коэффициент преломления, который изменяет направление луча, падающего на поверхность в зависимости от коэффициентов смежных сред и нормали.
4. Specularity. С этим я не знаю как совладать. Знаю про спекулярность по фонгу, но это же не физическая характеристика, а так, эффект. Если осмотреться вокруг, то можно заметить, что материалы имеют блик от ярких объектов. То есть мне надо учитывать яркость источников освещения и в зависимости от их мощности делать разную яркость блика. Вопрос: Как это реализовать на практике и какие физические процессы? К тому же, блики могут быть цветными.
5. Карта нормалей. Ну тут всё ясно. Нормаль прибавляется к настоящей нормали и получаем ту, что используется для вычисления цвета.
6. Цвет внутренности и коеффициент внутреннего рассеивания. Использовать для объёмных предметов, в которые проникает свет. Например, если через сферу, то по краям будет не сильно затемнено, а в середине всё.
Или я ошибся интернетом и тут никто в PBR не умеет?
> более гибкие настройки для рендеринга
С чего ты взял, что больше параметров => больше гибкости? Ты просто получаешь бесконечное количество случаев, когда твои материалы выглядят и работают хуёво. Принятые в индустрии физические модели и их параметризации позволяют порождать фотореалистичные и не очень рендеры уже пару десятков лет. Плюсом идёт огромное количество уже созданных материалов, бери и прикладывай.
Возьми какой-нибудь учебник, статью или ещё что, и изучи физику, из которой получаются уравнения и существующие модели рассеивания света на поверхности. Потом сделай всё то же самое, но сам. Раскури короче эту тему достойно, не пожалей времени, потом и сам не пожалеешь. Там ребята уже придумали много интересных вещей, и, даже если хочется придумать что-то своё, хотя бы ознакомься с их методами, иначе потратишь время на какие-то сомнительные вещи. Они делают примерно то же, что и ты, только более корректно.
Кстати, если у тебя лучи, лучше выкинь карты нормалей и завези нормальную геометрию. У тебя там рассеивание лучей по пизде пойдёт из-за таких финтов.
>порождать фотореалистичные и не очень рендеры уже пару десятков лет
Но для геймдева и других проектов очень редко нужен прям фотореалистичный рендер. Это AAA графонослайсы гонятся за улучшением графики, оставляя один и тот же геймплей, тем временем многие успешные инди и не только инди игры используют нереалистичную мультяшную, пиксельную и другую графику.
Если сделать задел именно на PBR, то не получится ли движок кастрированным и без возможности настройки особой графики?
>>711534
Ну да, на топовом проце в фуллхд десяток-двадцаток сфер рисуются с меньше 20 FPS.
Это скорее подойдёт всяким встроенным системам, у которых экран 300x200 пикселей. Модельку на 3D-принтере отобразить или ещё что.
>Давай, иди учи свои glBegin и glEnd, а потом узнай, что это 20-й век
Но ведь glBegin и glEnd будут только в пределах графического движка, который можно в последствии целиком заменить без изменения внешних интерфейсов, так ведь? А учебный проект не ограничен только графикой. Какая разница, каким способом рендерить, если нужно просто пиксели закрасить, чтобы хоть что-то на экране увидеть? Ты ведь не можешь запилить и протестировать, скажем, физический движок, если твоя программа не может ничего на экране отобразить - даже банальный кубик без текстур.
>современные опенглы
Насколько я знаю, OpenGL считается полностью устаревшим, больше развиваться не будет и теперь все силы прежних разработчиков OpenGL направлены на развитие Vulkan? То есть вместо шейдеров GLSL теперь нужно вулкан какой-то учить...
> Насколько я знаю, OpenGL считается полностью устаревшим
Он будет ещё жить не один десяток лет.
Если ты собираешься отдельный интерфейс писать для использования опенгла, то пожалуйста. Можешь хоть glBegin, хоть glVertexPointer, хоть glDrawArrays. Когда я начинал учить опенгл, то в программировании не был очень силён и не думал про абстракции. Потом мне пришлось все свои говнокоды переписывать под новый опенгл. А потом под ещё более новый.
>Насколько я знаю, OpenGL считается полностью устаревшим, больше развиваться не будет
Последняя стабильная версия 4.6 3 года назад. Развиваться ему действительно не очень стоит. Опенгл очень рудиментарен. Это раньше люди думали, что надо сделать glBegin, а потом поняли, что легче сразу вертексы пересылать, а затем ещё научили видеокарты почти произвольный код исполнять.
>То есть вместо шейдеров GLSL теперь нужно вулкан какой-то учить
Нет. GLSL это просто сиподобный язык с матрицами, векторами и разными математическими функциями из коробки, у которого убраны указатели, рекуррентное исполнение функций и ещё некоторые фичи, что позволяет как бы из кода сделать комбинационную схему термин тут не уместен, но похож. Он из цифровой электроники, чтобы архитектура видеокарт нормально их восприняла. Вообще, теоретически, любой GLSL-шейдер можно запросто превратить в модуль на верилоге, VHDL или другом HDL.
А вулкан это просто новая обёртка, чтобы запустить GLSL-шейдеры насколько я понимаю. Или там какие-то другие шейдеры, но всё-равно отличий будет немного. На вулкане надо 1000 строчек прописать, чтобы треугольник запустить просто из-за его гибкости и возможности подхвата устройств-видеокарт или что-то такое. Вся отрисовка такая же как и была.
В свой графический движок я собираюсь/уже добавил боксинг и разные анимации.
Под боксингом я подразумеваю, что есть родительские объекты и дочерние. Так, если один объект человек имеет дочерний оружие/шапка/кирка, то трансформация дочернего будет относительна родительскому.
А анимации я подумываю сделать трёх видов. Текстурно-цветовые, скелетные и свойственные.
Текстурно-цветовые это видео или массив цветов, которое меняется по FPS, длине кадра или другим правилам. То есть в случае пиксельной графики можно сразу анимацию загрузить и не думать над тем как перебирать кадрами.
Скелетная анимация это скелетная анимация.
Свойственная анимация это просто коллбек, который будет менять матрицу объекта. Например, заскейлить (когда курсор наводится на кнопку и она прыгает или когда надо дешёвую анимацию на 3D-персонажа нацепить).
Что ещё там может быть?
Различные виды куллинга: фрустум, окклюжн, порталы.
ЛОДы
Батчинг
Инстансинг
Системы частиц
Материалы
ИК
Шейдеры для воды, травы, террейна, скайбокса и т. п.
>Смотришь вертикально и видишь своё лицо, а горизонтально и оно размыто.
Это эффект Френеля.
Сейчас перечитал, и понял, что ты имел в виду не эффект Френеля, а анизотропные поверхности.
>Если ты собираешься отдельный интерфейс писать для использования опенгла, то пожалуйста
А разве можно как-то иначе? От голого OpenGL до игровых сущностей несколько слоёв абстракции должно быть.
>в программировании не был очень силён и не думал про абстракции
>Потом мне пришлось все свои говнокоды переписывать под новый опенгл
Так если ты не думал про абстракции и сделал огромный чан с туго запутанной лапшой, тебе его в любом случае пришлось бы переписывать с нуля/рефакторить, даже если решил бы остаться на самом старом OpenGL. Сам проходил такое, и проекты приходилось бросать не из-за выбранных интерфейсов рендеринга, а из-за того, что что-то добавить, убрать или просто понять, как и что работает, становилось чрезвычайно трудно. Какая разница, какой опенгл, если ты через месяц не можешь нарисовать дополнительную кнопку на экране, не сломав полностью весь GUI, и это в лучшем случае; у меня проект, бывало, вообще весь целиком ломался, лол. С тех пор учусь избегать лапши.
>вулкан это просто новая обёртка, чтобы запустить GLSL-шейдеры
>Вся отрисовка такая же как и была
Я правильно понимаю, что теперь рендерер движка должен быть написан на GLSL, и загружаться в видеокарту? Потому что я вот скопипастил какой-то базовый пример GLSL-шейдера, а он мне просто экран красным закрашивает и всё, какие бы данные я не отправлял. То есть мне теперь иголкой в видеокарту тыкать, чтобы научить её модели рисовать? Почему всё так, почему нельзя загрузить какой-нибудь default шейдер, почему я должен учить видеокарту рисовать отдельными пикселями... Вот в legacy OpenGL ты отправляешь на видеокарту команды и она их исполняет, а в GLSL ты сам своими руками исполняешь эти команды. Как я буду эти команды своими руками исполнять, если они для меня - "чёрный ящик"?
Вот конкретно из-за GLSL я бросил разработку очередного своего движка последний раз (июль этого года). Не хотел больше даже касаться темы разработки игр, но меня всё равно тянет что-нибудь сделать...
> Если сделать задел именно на PBR, то не получится ли движок кастрированным и без возможности настройки особой графики?
Нет, не получится. Получится удобно с точки зрения создания и заимствования материалов. Возьми любой blender и поиграйся с ним, сформируй сам мнение о том, хватит ли тебе того, что он может, или нет. Поищи на ютубе, что всякого охуенного с его помощью получается сделать у других.
Что такое ИК?
мимо пишу курсач по графике, изучаю основные штуки
>От голого OpenGL до игровых сущностей несколько слоёв абстракции должно быть.
Посмотрел сейчас на свою первую игру, а там всего 9 функций, в которых и происходит весь игровой процесс. Сама игра это платформер на несколько уровней...
>скопипастил какой-то базовый пример GLSL-шейдера, а он мне просто экран красным закрашивает и всё
Предполагаю, что твой шейдер имел синтаксические ошибки и просто не скомпилировался. Для хандлинга ошибок надо использовать функции glGetProgramiv glGetShaderiv glGetProgramInfoLog glGetShaderInfoLog
Кстати, посмотрел мельком на вебсайты с упоминанием вулкана и как я понял, там сделали гораздо лучше. Вместо загрузки исходника шейдера можно загрузить сразу SPIRV — новый модный молодёжный промежуточный код для шейдеров, всяких вычислительных ядер и прочего. То есть компилировать GLSL для вулкана надо отдельно. Кажется, с помощью SPIRV можно запускать не только GLSL, но и HLSL, или свой собственный язык шейдинга.
>в legacy OpenGL ты отправляешь на видеокарту команды и она их исполняет
И это плохо по-моему. Плохо то, что для растеризации простых треугольников, линий и точек надо иметь отдельное устройство со своим полусовместимым интерфейсом.
Я считаю, что видеокарты это рак, особенно, что одни версии опенгла или GLSLа можно запустить на одних, а на других нельзя. Хотя это вроде бы просто вычислительное устройство со встроенным выходом на монитор.
По-моему, было бы хорошо, если бы некоторый параллелизующий сопроцессор был в процессоре вместо самой видеокарты. Можно добавить инструкций для рейтрейсинга луча и треугольника или других инструкций для ускорения видео.
ну в текущий момент надо поддерживать два графических api - vulkan и условный gles2/opengl3.3
их достаточно для покрытия большинства целевых игровых устройств на планете, в отдаленном светлом будущем можно будет обойтись одним vulkan (когда на долю устройств с Android 5.0+ будет приходиться ~95% и отомрут старые компы/ноуты 10 летней давности)
>Посмотрел сейчас на свою первую игру, а там всего 9 функций, в которых и происходит весь игровой процесс
Моя первая и последняя полноценная игра имеет целую кучу функций, типов и констант, есть даже ООП-шные классы, в которые я пытался загнать игровые сущности. Но всё это настолько перепутано, что спустя какое-то время я уже не смог разобраться в этой лапше и забил на игру. Клон тетриса, если что.. Наверное, сейчас бы я смог произвести рефакторинг, разделить на отдельные модули и т.д., но мне слишком лень, нет мотивации.
>Предполагаю, что твой шейдер имел синтаксические ошибки и просто не скомпилировался
Не угадал. Шейдер на пикриле. Скомпилировать удалось с какой-то попытки (кажется, я не мог получить правильный профиль OpenGL, получался только 1.0/2.0), но что делать дальше - непонятно. Какие-то in и out... Кто я, программист или колдун, чтобы неизвестно что получать и неизвестно куда передавать? В нормальном языке программирования я бы подключил библиотеку и передавал ей данные, а здесь я кому и что передаю? Магия какая-то.
>SPIRV — новый модный молодёжный промежуточный код для шейдеров
Ну это понятно, байт-код вроде как, да? Непонятно почему сразу такое не сделали...
>свой собственный язык шейдинга
Придётся копаться в этом SPIRV, наверняка это ещё сложнее, чем почитать туториал по GLSL)
>можно запустить на одних, а на других нельзя
Производители разные ведь. Это вообще с любым железом так (процессоры, SoC смартфонов, микропроцессоры).
>просто вычислительное устройство
Сегодня уже нет "просто вычислителей", там очень много ускоряющих работу костылей, это тебе не калькулятор.
>было бы хорошо, если бы некоторый параллелизующий сопроцессор был в процессоре вместо самой видеокарты
Ну вот Intel с AMD тоже так подумали и выпустили процессоры со встроенным видеоядром. Однако недостатки таких чипов очевидны - они вынуждены пользоваться общей с процессором оперативной памятью (а она медленнее видеопамяти) и делить место на кристалле с ядрами процессора. А у ARM с его SoC вообще всё на одном чипе, и что это меняет? Только позволяет уместить всё железо на пластинке размером с ноготь, но что это даёт разработчику ПО? Новый процессор или процессор другого производителя всё равно будут иметь свои особенности, в т.ч. в работе видеоядра.
В нём есть как примитивные виджеты, такие как квадрат, так и сложные, как кнопка, слайдер, прогрессбар, список. Сейчас я остановился на прогресс барах и их очень сложно сделать. Сразу скажу, что тут прогресс бар состоит из двух дочерних виджетов — empty и full, меши которых изменяются в зависимости от value.
Я хочу запилить очень абстрактные прогресс-бары, чтобы они могли быть горизонтальными, вертикальными, со снаппингом, без снаппинга, круговыми или с генерацией своего собственного меша в зависимости от значения. А это ведёт к тому, что надо сделать отдельную библиотеку для булевых операций между 2D-мешами.
Но можно пойти по другому пути и сразу сделать нормально. Для этого придётся написать отдельный шейдер для опенгла, в который пересылать некоторый 2D-меш и если фрагмент (пиксель) попадает в него, то дальнейшие виджеты не рисуются.
Пример: Мы хотим сделать не горизонтальный и не вертикальный прогресс-бар, а диагональный. Для этого в прогресс баре есть 2 поля — для значения и угла, куда виджет full растёт. А чтобы это реализовать, надо сгенерировать 2 меша, которые будут являться разрезанным прямоугольником в определённом месте и под определённым углом. Далее пересылаем один меш во время отрисовки одного виджета и его часть отсекается, а другая нет. Важно чтобы так же отсекался трейсинг виджетов, так как в прогресс бар можно будет засунуть кнопки, например, и нельзя, чтобы их можно было нажать, пока не видны.
Таким образом можно сгенерировать и какой-нибудь свой меш. Например, если человек хочет сделать прогресс-бар, заполняющийся замощёнными шестиугольниками.
Такой шейдер позволит ещё ввести мою систему стилей. У меня стиль виджета это набор материалов (по сути цвет + текстура), связанные со своим индексом. Суть накладываемых стилей в том, чтобы они могли перемешивать индексы других стилей и, например, была белая кнопка с чёрным текстом, а стала синяя с белым текстом. Надо этим надо подумать.
Как тебе такое, Qt?
А по факту я сейчас имею криво работающие горизонтальный прогрессбар и один такой со снаппингом.
Кстати, эта библиотека работает поверх моего графического движка и мне придётся расширять возможности каждого бекенда, чтобы на них работал мой ГУИ.
> Клон тетриса, если что
> целую кучу функций, типов и констант, есть даже ООП-шные классы
Тоже страдал такой хуйнёй, бобёр, выдыхай, как говорится в старом анекдоте.
Тетрис это просто:
1. Генератор фигур. Возвращает массив 4 на 4 содержащий булевы. Далее фигура.
1.1. Поле для вывода следующей фигуры. Генератор может загружать фигуру сначала сюда, затем по требованию игры выдавать отсюда, а сюда следующую.
1.2. Поле для удержания фигуры. Обмен фигуры в этом поле и фигуры на игровом поле.
2. Проверка на возможность помещения фигуры (ниже, правее, левее). Принимает фигуру. Возвращает булево.
3. Смещение фигуры (ниже, правее, левее). Принимает фигуру, координаты. Выполняет обнуление игрового поля по старым координатам и прорисовку по новым.
4. Проверка заполненности полей. Выполняется один раз при остановке фигуры, работает снизу вверх, при обнаружении заполненной строки, убирает её, начисляет очки, сдвигает поле всё что выше на 1 вниз.
Всё, нахуй, никакие ООП-классы не нужны.
Кастомный движок в составе готовой игрры весом 200кб, 300кб хд мод, лол
2,5д фпс шутан на чистом С, без копирайта по сути.
https://gitlab.com/drummyfish/anarch
алсо что почитать на тему процедурной генерации, текстур например, уровней?
+
Рендерит кастомная рейкаст либа 60кб,
апаратное 3д ускорение и обчисление плавающей точки- не требуется,
код минимальный\чистый, хорошо коментирован.
-
Из зависимостей с99, сдл2дев, системная либа,
кривая реализация мыши, от мыши проседает фпс
> А этого почему-то нет.
Есть. Называется "любой готовый графический движок".
Да побарабану, каждая точка зрения имеет место быть.
Вот на видео уже используется примитивный графический движок, а куб я вращаю при помощи кватерниона. Всмысле, провожу операции с кватернионом, а потом превращаю в матрицу, которая передаётся в шейдер.
Но если посмотреть на сами кватернионы, то они же бесполезные в этом деле! Разве можно описать угловую скорость кватернионом? Нет! Когда я создаю кватернион из вектора и угла, над ними проводятся синус и косинус операции, то есть неважно, какой угол, скорость не получится сделать достаточно большой.
Я так понимаю, кватернионы надо выбросить и описывать угловую как скорость, так и положение просто вектором и числовым значением.
Тред не читал. Вобщем мне уже 30 лет, но я не умею кодить. Я пытался, но каждый раз сливался из-за лени, депрессий и прочего. Ну и плана никакого не было. Не было цели. И вот я подумал - надо уже решаться и научиться кодить, стать специалистом в этой области хотя бы за 5 лет. Я смотрю в сторону Си - не спрашивайте почему и не отговаривайте. Я хочу написать игру с вот такой механикой https://www.youtube.com/watch?v=OUKzvX9-8F8 но без сюжетной линии, только оффлайновое пвп на одном компе, получается короче файтинг наверное. Ну если будет возможность запилить и онлайн версию. У меня нет цели прям заработать на ней или что, просто хочу научиться кодить и добавить эту игру к себе в портфолио если что. Дайте советов с каких книг начать, с чего бы вы сами начали и т.д.
Ты похоже по диагонали читал - у меня нет цели заработать на ремейке или сделать убийцу die by the blade. Цель научиться кодить и стать миддлом за 5 лет.
Научиться кодить ЧТО? Какая предметная область? Кодить новые движки не нужно, учись работать в существующих.
> Остальные - виляние жопой - типа хочу быть свободным, но чтобы никто не украл мое авторство (а это не свободное).
Как раз таки это и является свободным. Не путай open source и free source.
Разберись в простеньком, уже написанном
https://gitlab.com/drummyfish/small3dlib
>(Автор этого поста был предупрежден.)
(Автор этого поста был предупрежден.)
У меня возникла идея создать рил тайм стратежку с ролевыми элементами. Так вот, в основу идёт разрушаемость мира и и тд.
Так вот вопрос, возможно ли натягивание совы на глобус полигонов на воксельные модели.
Да понимаю что звучит тупо и не оптимально для нынешнего железа, но возможность смотреть как падают деревья и взрываются камни, не запечёным пререндером, меня просто вдохновляют писать код и изучать это проблему.
то есть цимес не про ультра разрушение, а про элегантность падения или деформирования тех или иных объектов на карте.
я тя удивлю...
но питон в геймдеве используется по своему прямому назначению.
только не говорите ему про lua и Cython,а то он бедный инфаркт схватит
кста в кодинге я ноль без палки, но пережёвываю информацию и вроде понимаю матан и зачем нужна тригонометрия в 3д движках. За большое ещё не брался, но идеи просто заставляют их себя записывать и изучать Си и Пайтон дальше (нет я не дурачок, питон и правда полезная вещь, главное реализовать продукт, а допиливать ты его потом будешь, главное начать)
У меня какое-то проклятие - какую либу не беру, а мои модельки в моем движке грузятся в десять раз дольше чем в каком-нибудь другом с той же либой и в той же среде
Юнити или свой ламповый движ? Замечу что игра не AAA.
Решительно не согласен. Но допустим соглашусь лол. Меня беспокоит что Юнити на C#, а логику я уже написал на С++. Я C# отрицаю, не знаю и отношусь к нему с недоверием. Мне кажется что это новомодная поделка Майкрософта которые в последнее время написали много глючного копирующего чужие проекты софта. Они просто копирнули Java и сделали язык для веба который медленный по определению. Вот не понимаю - язык новый но он медленнее старого. Это как? В чем смысл? Просто выебнуться? Мне кажется да.
>Кстати, в Годоте можно писать на с++.
Повторить на уровне X-COM2 реально? В смысле графики и физики?
Я, наследие Unity, а это целая армия духов и бесконечная вера в успех. Лучше команды не найти во всей Галактике.
Подводный камень всего один. Очень неоптимальная хуйня, если твои руки не из плеч и не золотые. Сделать ECS так, чтобы это работало быстро, довольно тяжело.
Это будет очень удобная и расширяемая штука, своего рода конструктор, куда можно легко добавлять новые детальки, но это все равно будет работать медленнее узкоспециализированного движка, заточенного под конкретные цели.
Если ты собрался делать не просто движок, а свой конструктор игр или планируешь моддинг в своей поделке, то полезно. Иначе не рекомендую тратить время, потому что не окупится.
Работаю в компании, где приходится дрочить на ECS, поскольку в нашей экосистеме свой язык программирования и конструктор игор
> используется по своему прямому назначению.
На нем делают змейку?
>Как бы вы поступили?
Не пытался бы писать ecs с нуля, а взял бы готовое.
Например, как в bevy сделано. Не знаю, как там работает под капотом, но есть 2 компонента, Transform и GlobalTransform, при апдейте трансформа глобальный пересчитывается системой с учетом всей иерархии. Возможно как раз через "хитрую" сортировку.
https://github.com/bevyengine/bevy/blob/main/examples/ecs/hierarchy.rs
Не надо на ЕЦС делать иерархию сцены. ЕЦС отдельно, граф трансформов отдельно.
Без обхода графа - никак, но это не значит, что у каждой сущности игры должен быть компонент трансформ (как в юнити, например). Или что граф сцены должен что-то знать о ЕЦС (не должен). Просто каждый трансформ должен хранить ссылку на позицию в графе, который уже не является частью ЕЦС.
>узел графа должен иметь ссылку на энтитю
Это совершенно ни к чему
>>790410
> или энтитя иметь ссылку на узел графа - а чем это тогда лучше просто компонента трансформа
Тем, что ЕЦС и иерархия трансформов - это две подсистемы игры. Суть в уменьшении зависимости (decoupling). ЕЦС это не серебряная пуля, не надо пихать его везде.
А других и нет. Делай тогда на обычном ООП, зачем тебе декомпозиция тогда вообще.
>приближенного к реалиям
Это как? По ссылке рабочий пример кода с иерархией на ecs движке, который можно скомпилить и запустить.
Чем это не приближено к реалиям?
https://github.com/DanielChappuis/reactphysics3d
Зачем нужен движок на с++ от васяна, если physx, bullet и еще куча движков написанных профессионалами?
Поэтому я и спросил, кто пользовался или слышал.
Соре, bullet написан мамонтами, может они и профессиАналы, а может и нет, и кста он тоже на с++, но код там так себе.
Может тут чувак все по уму переписал нормально.
bullet писали и оптимизировали ученые математики
васян в лучшем случае просто скопировал готовый код оттуда, в худшем наговнокодил непонятно чего.
>васян в лучшем случае просто скопировал готовый код оттуда, в худшем наговнокодил непонятно чего.
СКАЧАЙ @ ПРОТЕСТИРУЙ
Зачем вот это вот всё вангование здесь писать?
Думаешь кто-то изобрел новый гениальный алгоритм расчета коллизий? О чем этот гитхаб? Об очередной реализации физики по туториалам?
>СКАЧАЙ @ ПРОТЕСТИРУЙ
Не, спс. Если бы мне понадобилось, я бы physx скачал лучше
>лучше всего учиться программировать на Python
Как преподаватель со стажем скажу, что - нет. Многим людям он дается гораздо хуже как первый язык из-за вот этих вот значащих отступов. Поэтому советовать его новичкам или людям далеким от программирования не стоит.
> Не пытался бы писать ecs с нуля, а взял бы готовое. Например, как в bevy сделано.
так разраб bevy как раз свою реализацию ecs и писал, потому что другие были тормознутыми, он только в самых первых версиях движка взял готовое, потом выкинул и написал свое
- Движок на C++.
- Скриптовых языков будет на старте три: C++, C# и какой-то свой «простой язык скриптования, чтобы облегчить вход в разработку начинающих специалистов».
- Визуальный скриптинг будет.
- Будет работать на любой ОС, «в том числе и Linux» 🙃.
- Web-билды будут, консольные версии «в проработке».
- Граф. движки: DX12, Vulkan и Metal. Будет и поддержка RT с DLSS. Хотят сделать «простой пайплайн» по работе с FBX, glTF или USD.
- Хотят запрыгнуть на хайптрейн и добавить ИИ-инструменты.
- Касательно «легаси-кода», ответили, что «в современных реалиях open-source разработки создавать комплексные решения с нуля, очевидно, не имеет смысла». Видимо, и правда за основу что-то готовое взяли.
это про нау энжин
Мы будем отталкиваться от существующих технологий, поэтому наличие legacy-кода неизбежно. Также мы рассчитываем на вовлечение комьюнити в процесс разработки, а это означает, что большое количество кода будет написано сторонними командами и любой код будет содержать свои legacy-конструкции.
Там описаны алгоритмы дума и подобного. Заливка, пересечение полигонов. В сети есть djvu.
У автора еще предыдущая книжка с похожим названием гуглится, на ассемблере.