>>120054
Это да. Если бы я хотел делать игры то просто взял бы какой-нибудь годот и на нём делал бы. А может, даже, обычные движки, посмотрел бы тот Ogre3D. Но я не такой. Некоторые продукты не находят общего языка с моим психическим организмом, происходит отторжение. Если смотреть на графические программки, то mpv, блендер и lmms (хотя с ним у меня мало XP) мне больше всего зашли (несмотря на то, что мне не нравится блендер, внутри я понимаю, что его просто не понимаю).
Всё остальное — говно, либо продукт ненадлежащего качества.

А вообще, вместо игр можно было бы и ассеты пилить. Я заходил на godot магазины assэтов и там сплошной лохотрон — всё бесплатно, и как на этом можно заработать? Вот юнити ассерт стор другое дело, но сам понимаешь, что происходит с желудкмб.
Существовал бы Лайси в нормально обличии на свете, можно было б запилить отдельный формат ассетов с эмбеддед-лайси скриптами. И конвертировать их хоть в юнитексные, хоть в гондотные ассеты (если это будет позволительно). Можно и отдельный "движок" запилить с такими ассетами и продавать в стиме (я сторонник СПО, так что выбрал бы полусвободную лицензию, где я могу продавать, а другие могут скомпилировать).

Я уже вышел на новый уровень развития, но закрепиться на нём не смог из-за отторжения C/C++. Это как если некоторые кирпичи класть, не прогрунтовав. Или если водоросль ризоидами крепится к камушку, а он промаслен. Нет, это когда пытаешься термоклеем на жирную поверхность наклеить что-то. Мне пора использовать отдельные библиотеки, но надо было изначально продумать полностью архитектуру и все функции, даже не спрограммировав их.
Сейчас я разнёс свою систему ГУИ и собираю её заново, отгородив отдельный модуль с комплексными, но часто встречающимися виджетами. Кнопка, Слайдер, виждет с контекстным меню, лейбел и всё такое. Я одновременно пишу этот модуль и портирую систему ГУИ под рейтрейсер. Поддержку опенгла удалил, чтоб не мешалась, но, может быть, потом введу обратно и частично.

>>120101 (OP)
>Регистрируешься в steamworks, на каждую игру единоразовая комиссия 100 долларов + от продаж около 30% (не считая налогов).
Почему почти треть?

Есть ли доход от продажи пользователями карточек? Вроде бы где-то читал, что есть.

>>120109
>Почему почти треть?
Потому что стим даёт очень удобный сервис для продажи игр. Даже лютое говно может окупиться за пару лет.
Вот если бы ты выдавал самиздатом, то сколько бы продаж у тебя получилось бы? 0? 1? 2?

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

>>120101 (OP)
>FAQ
Сверни его в разворачивающийся спойлер в следующий раз что ли.

Который вот этот

Где можно кратко (в виде статьи) прочитать про гейм-дизайн и его основы?

>>120389
Как ты добился фпс более низкого, чем с шарами в объёме с матрицами и лучами?
Вот это точно в реальном времени рендерится на процессоре. Причём на старом.

>>120396
На самом деле нет, при фуллхд с теми сферами, если близко подойти к объекту (чтоб экран занял), получится тоже 2.5 ФПС. Хотя, когда я портировал свой сырой рейтрейсер на свой абстрактный движок, мне показалось, что на одном моменте ФПС уполовинился.
Что же мне делать, если не смогу поднять ФПС до приемлимого уровня? Наверное, придётся вводить поддержку опенгл и динамически генерировать шейдер для рейтрейсинга всех объектов. Только не получится коллбеки для специальных объектов вызывать, либо и их портировать на GLSL/SPIR-V. Вот же производители процессоров! Лишают меня возможности делать нормальные продаваемые игры. Действительно опенглогулаг. По моим процессорам пока застой. Смог напылить немного меди на кусочек стекла (в самом лучшем образце образовались множественные островки, а на краю даже полноценная блестящая плёнка, которая с небольшим усилием стирается металлической иглой). Теперь пора заняться обработкой кремния.

>>120416
>тоже 2.5 ФПС
Но в плоском случае тебе не нужно ворочать матрицы, углы или ретрейсить. Если теоретическое преимущество ретрейсера в 3d очевидно есть, то в плоском случае просто полностью эквивалентные картинки будут - если у тебя глубина - то просто рисуй по слоям - это не 3d и слои дискретные, вряд ли их больше 5.
Или, если так хочется - ты можешь по сетке разбить экран на куски 32х32 - пройтись по объектам и записать традиционной растеризацией в каждый из кусков номер объекта - и потом ретрейсить только локальный список каждой отдельной клетки 32х32. Но ты просто в десять раз больше вычислений сделаешь, чтобы получить ничего. Твой подход это примерно как использовать сортировку пузырьком, потому что быстрая сортировка с рекурсией это ересь и квиксортогулак по каким-то надуманным причинам.

>>120420
Я, кстати, ошибся. Если на демке со сферами отключить освещение, то ФПС возрастёт до 15, в 3 раза больше, чем в игре. Значит, я где-то там с объектами напортачил. У меня в движке есть ноды и эти ноды могут содержать другие ноды со своей относительной матрицей. И перед рейтрейсингом я их компилирую в один список объектов с просчитанными матрицами.
>ретрейсить
Не, опенгл это конечто плохо, но чтобы менять его на растеризацию, это плохое решение. По-моему лучше оставить рейтрейсинг. Мне надоело уже переписывать своё ПО. Если я буду вводить то одни, то другие алгоритмы, то так и буду писать пустой код.
Опять же, производительность это не столько мои проблемы, сколько проблемы железной части. Вот почему современные процессоры не дружат с рейтрейсингом? Потому что монополия и маркетинг.

>>120433
>Потому что монополия и маркетинг.
тут должна быть шутка про штаны

>>120459
Поздравляю с открытием. Кстати у всех в среднем всего 4 ядра, а не 12.

>>120468
>4 ядра, а не 12.
Но они сильнее моих амдшных или нет?

>>120433
>Вот почему современные процессоры не дружат с рейтрейсингом?
А почему они не дружат то?
Мне кажется процессор любой архитектуры будет ретрейсить дольше растеризации с буфером глубины. Это просто разные алгоритмы как O(n^2) и O(n), и собрать процессор на котором будет быстрее работать первый алгоритм нельзя.

Где можно найти гайд степ бай степо по геймдеву?

>>120514
Таких нету.

Заголовок спойлера

1. Придумываешь идею. Геймдев разный и нужно примерно представлять что ты хочешь делать и на какой роли.
2. Игра состоит из кода и контента.
Код:
- Можно использовать движок. Придётся изучить 30..50% программирования, просто чтобы мочь эффективно использовать движок, подходит не для всех жанров. Рекомендуется начать с базовых основ программирования без движка - изучить (можно в теории) что такое переменные, функции, циклы и массивы, дополнительно посмотреть что такое объекты и методы в ооп (99% движков используют ооп). После этого садиться за гайды по движку, если не понятно - вернуться к основам программирования.
- Можно не использовать движок. Нужно изучить 90% программирования, и помимо этого изучить многие из нижепредставленных разделов:
- линейная алгебра (матрицы, расстояния от прямых до точки, решение систем уравнений - нужно для всего кроме визуальной новеллы или другой текстовой игры)
- основы компьютерной графики (знание какого-то апи для вывода графики, общие сведения про текстуры и полигоны - нужны чтобы нарисовать хоть что-то)
- пользовательский интерфейс, многие игры годами страдают от невнятного интерфейса, которым неудобно пользоваться. Особенно этим страдают инди-игры вроде майнкрафта или project zomboid, и даже использования движка не всегда спасает от этой беды. Логика работы интерфейса может быть очень сложной и требует отдельного изучения.
- представление игрового мира - может быть довольно нетривиальной задачей разобраться каким образом должны храниться и взаимодействовать игровые объекты. Например, даже простое взаимодействие рельефа, игроков и каких-то боевых способностей можно сделать множеством разных способов. А если это ещё рпг с квестами, которые взаимодейтсвуют друг с другом... Скорее всего это тоже требует отдельного изучения и практики.
- библиотеки для загрузки разнообразных форматов изображений, анимаций, моделей или звуков - представление этого в коде (использования движка очень хорошо тем, что избавляет от всех этих проблем разом - разобраться и сделать то, каким образом загружается и используется трёхмерная моделька с костной анимацией может быть довольно трудоёмкой задачей)
- вычислительные алгоритмы (тонкости работы чисел с плавающей запятой, эффективные алгоритмы и структуры данных - нужны для любой трёхмерной игры с картой больше чем 30х30 метров, или двухмерной игры с множеством объектов)
- сеть и мультиплеер (знание какого-либо апи для передачи данных, p2p и клиент-серверная модель, lock step и компенсация пинга - понимание что и в каких случаях лучше подойдёт)
- подробности компьютерной графики (тени, шейдеры, hdr, DoF, скелетные анимации и прочее - если игра трёхмерная и там нужна более красивая картинка)
- основы физики при использовании физического движка (численные методы интегрирования, минимальные сведения про обнаружение столкновений, вращения в пространстве через кватернионы - нужны просто чтобы эффективно использовать уже имеющийся физический движок) Разработка собственного физического движка задача намного более трудоёмкая, чем создание игры.
- кучи мелких мелочей, вроде воспроизведения звука, которые не такие крупные - но всё ещё могут потребовать нескольких часов изучения.
(плохие новости - из всего этого "степ бай степо" гайды есть только по компьютерной графики и движкам, численным методам - какого-то внятного хотя бы просто сборника статей про физику или ui я никогда не встречал)
Контент:
- модельки
- создание геометрии
- текстурирования моделек
- анимация моделек
- эффекты (взрывы, искры и анимации способностей могут потребуют чего-то большего, тем моделька с текстурой)
- левел-дизайн (придётся создавать собственный редактор карт или использовать процедурную генерацию мира, алгоритмы которой могут быть очень сложны)
- Если есть квесты или другие события изменяющие глобальное состояние мира, то задача усложняется ещё сильнее
- компьютерные противники
- разработка внятного интеллекта даже для отдельных мобов может быть сложна (если уровни имеют сложную форму, укрытия или если есть какие-то сложны способности)
- разработка внятного глобального противника (вроде вражеского игрока в стратегии) контролирующего множество юнитов и с возможностью создавать новых юнитов выходит за возможности соло-разработчика в любой нетривиальной игре.
- музыка и звуки
3. Выписываешь вышепредставленные разделы необходимые для твоей игры, то за какие разделы в ней ты будешь отвечать. Нанять художника для создания модельки просто - он может сделать часть работы и уйти, нанять программиста сложно - скорее всего он должен быть один на протяжении всей разработки, он не может сделать часть работы и уйти, в противном случае следующему будет намного сложнее - возможно настолько, что будет проще начать с начала скопировав лишь отдельные части.
4. Выбираешь языки и инструменты. По очереди исследуешь выписанные разделы, возможно по "степ бай степо" гайдам, которые для отдельных разделов могу существовать.
5. Создаёшь техникал-превью - простейший прототип с демонстрацией основных идей.
6. В этом месте нужно подумать про маркетинг - разобраться для какой ца ты делаешь игру, как много денег и времени ты готов на это потратить, где продавать и чем завлекать игроков.
7. Теперь можно переделывать более чистую альфа-версию, куда внедрять часть контента. Возможно будет смысл начать с начала, а не модернизировать техникал-превью. Есть смысл создать план, что в альфе будет и чего там быть не должно.
8. После завешения альфы нужно тестировать и балансировать, ты её создал - ты знаешь её как пять пальцев, но для стороннего игрока она может оказаться невероятно непонятной и сложной, неудобной в управлении.

>>120538
Просто вау!
>>120761
Ты молодец анон, продолжай в том же духе

Годаны, объясните кто-нибудь, как без огромных массивов малопонятного кода сделать машину состояний для 2Д-платформера? Сколько ни смотрел, у каждого свои способы - от массивов магических рун кода на целые экраны до отдельных нод.

>>120814
>Как вам такое, опенглогулагеры?
Всё ещё ничего такого, что нельзя нарисовать с использованием opengl с минимумом изменения кода.

>>120859
>bare-metal на микроконтроллере
>МКУ
>LLVM-pipe
>софтрендер
Что?

>>120859
> Эта женщина бегает неправильно!
Больше на полет в невесомости похоже.

>>120874
Бляяяядь, я надеялся, что ты на сосаче останешься.

>>120869
bare-metal на микроконтроллере это частный и частый случай запуска программ на МКУ.
МКУ это микроконтроллер, по английски Micro Controlling Unit.
LLVM-pipe это софтовая видеокарта, можно опенгл на процессоре считать.
Софтрендер это софтрендер.

>>120921
Какое отношение имеют микроконтроллеры к рендеру картинки для платформера?

>>120935
прикольно. А как траектории движения сделаны, когда они летают и стреляют?
тред выше не читал

>>120928
На них легче рендерить софтрендер, а не щзутпд

>>120935
Неплохо, хорошо.

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

>>120935
Почему свои и вражеские снаряды ничем не отличаются?
Почему твой корабль такой медленный, по сравнению с вражескими?

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

>корабль в таком случае, должен двигаться во все стороны
Может добавлю потом небольшой маневр по Y. Вообще можно будет сыграть в игру вдвоем за одной клавиатурой, у каждого игрока есть своя высота, так чтобы они не пересекались. Если добавить перемещение по Y, то нужно решить, что делать с пересекающимися игроками.

>>120958
>Почему свои и вражеские снаряды ничем не отличаются?
Оружие на одних и тех же физических принципах, поэтому и одинаковые. У игрока лазер чуть похуже кстати, у него релоад 2 секунды, против 1 секунды у чужих.
>Почему твой корабль такой медленный, по сравнению с вражескими?
Чужие развитая цивилизация ослившая дальние путешествия со сверхсветовыми скоростями. Понятно что у них ветка движков будет прокачена лучше чем у человечков сычующих на земле. Жестокая галактика короче.

>>120986
>попукивая в левый верхний угол экрана
Тучую, в реальном мире мне бомбы из-за этого не нравятся. Зачем они взрываются во всех стороны, они что, такие тупые? Взяли бы бомбу, да направлили бы всю энергию в одну точку, так что можно снимать террориста с расстояния в километры. Или в банках поставить по бомбе и пусть они взрываются, убивая только грабителей.
А Ким Чен Ын уже давно мог взять свою ядерку, направить её под углом в землю и задестроить вашингтон. Но он же даже не тиран, а простой позёр.

>>121006
>Планирую потом сделать игру пиксельной.
Это как? Сделать текстуры с пикселями размером с кулак? Зачем так уродовать графин, сейчас неплохо ведь выглядит. Остави так.

Вообще правильные пиксельный игорь должен следовать разрешению экрана, а не огрублять и растягивать текстуры как принято у всяких каргодаунов делающий индиговно под ретро.

Алсо, у тебя прыжки неправильно сделаны. В полете нельзя управлять направлением меняя его чуть ли не на протвоположное как у тебя.

>>121206
В такое я играть нибуду! Серьезно, уебищные же пиксели-мутанты все портят.

Оставь графен как вот в этом видосе >>121006 Один пиксель богоугодно соответсвует одному пикселю реального экрана, выглядит збс.

>похвастайся персонажем
Прогрессом же.

>>121275
> уебищные же пиксели-мутанты
Но ведь не так уж и плохо... а что рук нет - так их потом прикрутим отдельной нодой...

>>121275
Можешь назвать хоть одну успешную игру, где виртуальный пикусель соответствует физическому?

>>121275
>Один пиксель богоугодно соответсвует одному пикселю реального экрана, выглядит збс.
По-моему, в таком случае игра перестаёт быть пиксельной и становится просто 2д.

>>121412
АоЕ 2. Её 20 лет и до сих пор в неё играют тысячи игроков через воблу. Может быть сейчас меньше из-за DE-версии (это ремейк).

>>121554
>Второй пик это тру пиксель арт
Что? Это совсем не пиксель арт. Паул Робертсон рисует в мультяшном стиле, просто контуры без антиалиазинга. Есть такое движение, когда рисуют обычные картинки, но с пиксельным контуром. И это совсем не пиксель-арт. Как я и говорю, пиксель-арт схож с импрессионизмом.
С таким большим разрешением может любой дурак художник рисовать, а ты попробуй уместить лицо персонажа в размер 4x3 пикселя.

>>121579
И что это за лицо? То, что ты нарисовал это уровень дошкольника. Где тени, где ресницы, где эмоции? Такое вряд ли пойдёт в коммерческий геймдев.

Кстати, вот список успешных пиксельных игр: https://store.steampowered.com/tags/en/Pixel+Graphics#p=0&tab=TopSellers (правда, там не все игры пиксельные). Это говорит о том, что пиксель-арт это нормальное художество.

Мне не нравятся всякие графонослайсы типа зе ласт оф аз, резидент эвил ремейк, анчартед, но, всё-таки, такие игры существуют и не считаю их чем-то плохим или неправильным. Просто они для детей.

>>121612
Всё ясно, автору 12 лет.
/thread

>>121554
>Пиксели это ручная работа с формой и цветом.
Любая работа с растровыми изображениями – это работа с формой, цветом и пикселями.
Но ты почему-то не отличаешь пиксель арт от остального 2д.

>Второй пик это тру пиксель арт. Зацените детализацию.
Если для тебя обычный алиасинг – это пиксель арт, то ок.

>>120101 (OP)
>Наверное, тебе надо копать в сторону уравнений Навье-Стокса
Аноньчик, я никогда этим не занимался, но давай порешаем уравнение Навье-Стокса на этой неделе? Ну, кто как сможет. Например, я даже не знаю как решать такое уравнение численно.
Для начала начать с двумерного случая, если там всё плохо с вычислительными мощностями.

>>121955
Можно попробовать, но надо разобраться со всеми операторами. Вот что такое ∇ {\displaystyle \nabla } \nabla — оператор набла и Δ {\displaystyle \Delta } \Delta — векторный оператор Лапласа? Смотрим на википедии, ага, это из векторных полей. Если не знаешь, что такое векторное поле и с чем его едят, то можно зайти на сайт mathprofi.ru.
Я пока не рассматривал что это такое.

>если там всё плохо с вычислительными мощностями.
https://www.shadertoy.com/view/WdVXWy
https://en.wikipedia.org/wiki/Computational_fluid_dynamics
кину попавшиеся сслыки

>>121977
>Вот что такое ∇
Довольно странно что кто-то связанный с программированием может этого не знать.

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

>>122109
Придумал новою механику, и предлагаю её тебе. Корабль игрока должен лететь вперед с любой скоростью, но не 0 и плавно уклоняться. Чем больше скорость корабля, тем больше его урон. Когда корабль выйдет за границы экрана, то он должен обратно появится снизу с той же скоростью.

>>122121
Это будет уже больше похоже не скролл шутер. Надо чтобы хоть в чем-то оставалс элемент классики, я из-за этого не хочу даже добавлять движение по Y.

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

>>122150
Пока не сказал я не замечал баг с шипами, лол.

Почему ГГ в конце видео падает, хотя вроде стоит на блоках?

>>122150
Прикольный персонаж.

>>122126
С такими вот стратегиями игр полно, я не говорю что это плохо, просто игроки остаются в играх где важен скилл, а с помощью интернета они будут хвастаться, тем самым продвигая твою игру.

>>122186
>чтобы рейтрейсить глсл-шейдером
Да просто отрендери без шейдера ванильным opengl. Ну что же ты так упорствуешь, чем это тебе повредит? Думаешь он не в состоянии нарисовать твои 16-цветные картинки?

А ещё у тебя не может быть для такой картинки меньше 60 фпс, это просто дичь какая-то.

>>122191
По-моему, растериазция для такой графики это бред. Ну ладно, может для 2D ещё зашло бы, но нет.
А моя игра будет требовать рейтрейсинг и обязательно. преломление света, отражения, рендеринг 3D-фракталов, мб, всё это будет.
А опенгл это как и точка.

>это просто дичь какая-то
Это неправильное использование системы по объектам, вычислениям, неоптимизировано.

>>122192
>По-моему, растериазция для такой графики это бред.
Для двухмерной?

Рестеризация: Ты указываешь для прямоугольника координаты x1, y1, x2, y2, сдвигаешь и масштабируешь их, и потом двойным циклом проходишь по прямоугольнику, получая st координаты текстуры как (x-x1)/(x2-x1). Нагрузка - 4х(время преобразования координаты)x(количество полигонов) + (количество пикселей полигонов)х(время выборки из текстуры). При этом тебе даже делить (деление работает раз в несколько десятков раз медленнее умножения) для каждого прямоугольника нужно только один (два) раза, ты считаешь чему равно 1/(x2-x1) и потом умножаешь на это для вычисления текстурных координат.

Ретрейсинг: Ты считаешь координаты луча-пикселя, проходишь по всем объектам высчитывая его st-координаты, при этом ты в каждом пикселе проходишь по всем объектам. Нагрузка - 2x(количество пикселей экрана)x(время преобразования координаты)+(время выборки из текстуры)х(количество полигонов)х(количество пикселей экрана).

Если у тебя весь экран разрешения 1200х800 закрашен мелкими квадратами и их 113 штук, то в первом случае нагрузка 452k₁+960000k₂, а во втором 1920000k₁+108480000k₂, в десятки раз больше даже с оптимизациями.
Вот давай сравним софтверный 2d-растеризатор, и софтверный 2d-"ретрейсер". Я думаю растеризатор победит абсолютно на всех задачах.

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

>>122204
>шебм
Блин анон, это охуенно!

>>122204
>софтверном ретрейсере
Так зачем на рейтрейсере считать фракталы? Я вон мандельброта на сферу считаю вручную, исходя из координат текстуры.
>>122208
Тучую, он меня немного вдохновил тоже подобное сделать — с масштабированием. Только я, может быть, сделаю с темплейтами и посмотрю с флоатами, даблами и своим рациональным велосипедом.
Сейчас, если мою волю не перемнёт какая-нибудь другая вещт.

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

>>122216
>Сначала я долго пытался сделать масштабирование в место, куда показывает курсор, а потом забил и сделал как получилось.
Ты передвигаешь изображение так, чтобы кусок под мышкой оказался в центре, масштабируешь, и потом передвигаешь обратно на то же количество пикселей но с другим масштабом. Можно один раз перенести после, если вычесть из 1.4 1.0 и из 1.0 1.0/1.4
#p1 - точка (тупл из двух чисел) соответствующая центру экрана
#zoom - соотношение размера экрана и масштаба фрактала
#self.mx - позиция мышки (симметричная, от -1 до +1)
self.p1=self.p1[0]+self.zoom*(self.mx),self.p1[1]+self.zoom*(self.my)
if (z<0):#Вращение колёсиком в одну сторону
self.zoom*=1.4
else:#в другую сторону
self.zoom/=1.4
self.p1=self.p1[0]-self.zoom*(self.mx),self.p1[1]-self.zoom*(self.my)

>>122224
Нет, то ли тучка, то ли тор-браузер, то ли файрфокс, первый при 429 Too Many Requests, вторые в случае "повреждения" файла показывают твой пикрелейтед. Не знаю, кто именно так делает, но явно, что лучше не использовать веб и смотреть через mpv. Но админ всё никак не хочет убрать ошибку 429 Too Many Requests.

Я ставил -qmax 0 в ffmpeg. Кстати, ПНГ-картинки суммарно занимали меньше места, чем данная вебемка.

>>122241
Пофиксил качество и ещё замедлил до 15 фпс - а то не видно ничего.
У меня открывается оффлайн, и в vp9 сконвертировалось без ошибок с дефолтными настройками. Не открывает только браузер-лисичка, возможно из-за gbrp(pc, gbr/unknown/unknown), 1200x800, lossless.

>>122235

>Что не так с этим кодом

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

>ray->normal = normalize(cross(AB,AC));
У тебя идёт цикл по всем треугольникам, верно? То есть ты определяешь пересечение, считаешь и нормализуешь нормаль (корень очень тяжёлый), а потом на луч попадает ещё один другой треугольник и ты снова считаешь нормаль? Хотя бы нормализовать уж точно можно было бы после всех операций.
Нужно проходить циклом по всему, записывая лишь глубину пересечения, и лишь в самом конце записывать одну нормаль, и один раз проводить рассчёт текстурных координат/освещения - по крайне мере в случае cpu, которое дружит с ветвлением и не дружит с корнями.

Ещё возможно нужно изучать квадрат расстояния до треугольника, как в случае со сферами.
Вроде бы вот тут написано что-то похожее для точки, судя по формулам: https://www.geometrictools.com/Documentation/DistancePoint3Triangle3.pdf
Но я не читал, не знаю английского.
Кстати, зашёл на их сайт: https://www.geometrictools.com/Source/Intersection3D.html#LinearPlanar - там что-то потенциально полезное для задач тобою решаемых.

По хорошему нужно сгенерировать массив лучей и треугольников разными способами и смотреть насколько быстро какой способ поиска пересечения использовать, прям отдельно вне рейтрейсинга тестировать функцию TriangleRaycast.

>>122324
Красиво получается.

>>122330
Это твоя мамка, анон

>>122324
Зайчем ты это делаешь, анон? Ведь есть ж гейммайкер.

>>122346
Я свой путь гейпдевера начал раньше, чем программиста при помощи гейммейкера и юнити и я знаю, что обычное программирование гораздо лучше, ведь оно гибкое. Если бы я использовал гондот или юнитекство, то получались бы лагающие багающие глитчащие проваливающиеся коллайдеры, каждый раз игра вылетала, а я злился на элементы ГУИ этих конструкторов игр.
Кроме того, разве способен гейммейкер в рейтрейсинг? Я собираюсь добавить 3D-уровни с рейтрейсингом.

>>122371
Это имитация волн? Они сами генерируют направление или можно управлять с помощью мышки?

>>122381
Мне кажется, что тебе надо сначала убрать следы от пуль, в конце фпс жестко просел.

А еще можно сделать чтобы девочка по команде крепко схватывала пушку и когда начнет стрелять, то имела дополнительную инерцию

>>122385
Для русских это так, им только такими делают.

>>122371
>>122383
Можна код? Хочу запустить.

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

>>122431
Хорошо, перепиши и скинь.

>>122646
Дата-классы это структуры из си?

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

>>122761
>ФПС очень мало
Я бы удалил игру с таким графоном тут же, если бы она потребляла больше 2% загрузки cpu или gpu. Это графон уровня gameboy advance с 17 мгц и половиной мб оперативки. Только что разрешение больше.

Даже флеш рисовал графику намного быстрее, причём во весь экран и со сглаживанием: https://files.catbox.moe/gokxl9.swf

>>122766
Это же прототип, я собираюсь ввести преломлящие элементы типа линз. Во флеше есть линзы?

>>122768
Вроде бы нету, но всё остальное он рисует намного быстрее. Стало быть если в него добавить такие же лизны как ты добавишь в свой код, то он будет за счёт рисования всего остального всё ещё быстрее.

>преломлящие элементы типа линз
Зачем тебе линзы? У тебя игра про линзы и оптику? А если это визуальный эффект, то это того не стоит и ты можешь сделать нереалистичные линзы через костыль вроде линейного растяжения изображения в линзе.
https://ru.wikipedia.org/wiki/%D0%94%D0%B8%D1%81%D0%BF%D0%B5%D1%80%D1%81%D0%B8%D1%8F_%D1%81%D0%B2%D0%B5%D1%82%D0%B0
Что ты думаешь про это? Разные цвета преломляются по разному. Тебе придётся отказываться от rgb-модели и задавать цвета массивом-гистограммой, верно?

>>122773
Да, я мог бы сделать графический движок гибридным — растеризация+рейтрейсинг, но зачем? Зачем переделывать код? Ради парочки оптимизаций, чтобы быстрее исполнять на тупых древних процессорах? Оставь свои микроконтроллеры и демосцены фанатикам. А то потом начнутся ошибки, баги, я не пойму, что не так. Прозрачность будет багованная как в опенгле. Это не нужно. Я всё-равно собирался делать бекенд для исполнения на видеокарте через GLSL.
>если это визуальный эффект, то это того не стоит и ты можешь сделать нереалистичные линзы через костыль
Вот именно, я не хочу делать костыль.

Слушай, есть грань, когда надо оптимизировать, а когда сохранять удобность кода. Ранняя оптимизация может всё уничтожить, у меня даже стандарт графического движка не сделан.

>Тебе придётся отказываться от rgb-модели и задавать цвета массивом-гистограммой, верно?
Что? Нет, это реалистичное преломления и освещение это уже из разряда path-трейсинга и суперреалистичного рендеринга. У меня игра с фантастической, а не реалистичной графикой.

Кроме того, в финальных для этапа уровнях понадобится рейтрейсинг, так как игра станет почти тридешной и с отражениями.

>>122766
Все-таки поговорка что дуракам половину работы не показывают верна.

>>122819
>#version 420
>
>uniform mat4 camera;
>uniform mat4 camera_notrans;
>
>out vec4 FragColor;
>
>#define WIDTH 1200.0
>#define HEIGHT 800.0
>
>#define FOV 1.309
>
>
>vec3 objposs[2] = {vec3(0.0,0.0,-35.0),vec3(7.0,-5.0,-38.0)};
>float radiuss[2] = {5.0,3.5};
>vec3 colors[2] = {vec3(1.0,1.0,0.0),vec3(1.0,0.0,0.0)};
>
>vec3 lightposs[1] = {vec3(-4.0,15.0,-5.0)};
>
>
>struct CastRet_t {
>bool casted;
>
>vec3 normal;
>vec3 intersect;
>};
>
>CastRet_t SphereRaycast(vec3 o,vec3 d,vec3 pos,float r) {
>CastRet_t ret;
>ret.casted = false;
>
>vec3 o_minus_c = o - pos;
>
>float k1 = dot(d,d);
>float k2 = 2dot(o_minus_c,d);
>float k3 = dot(o_minus_c,o_minus_c) - rr;
>
>float undersq = k2k2 - 4k1k3;
>
>if (undersq >= 0.0) {
>float t_test = (-k2 - sqrt(undersq));
>
>if (t_test >= 0) {
>float t = t_test/(2k1);
>
>vec3 intrs = (o + dt);
>
>ret.intersect = intrs;
>ret.normal = normalize(intrs - pos);
>
>ret.casted = true;
>}
>}
>
>return ret;
>}
>
>#define OBJ_NUM 2
>
>#define SMALLADD 0.004
>
>vec3 RaytraceObjects(vec3 pos,vec3 dir) {
>vec3 color = vec3(0.0,0.0,0.0);
>
>int index = -1;
>vec3 intersect = pos;
>vec3 normal = vec3(0.0,0.0,0.0);
>
>CastRet_t ret;
>
>for (int i = 0; i < OBJ_NUM; i++) {
>ret = SphereRaycast(pos,dir,objposs[i],radiuss[i]);
>if (ret.casted) {
>vec3 lvec0 = ret.intersect - pos;
>vec3 lvec1 = intersect - pos;
>if (index == -1 || dot(lvec0,lvec0) < dot(lvec1,lvec1)) {
>index = i;
>intersect = ret.intersect;
>normal = ret.normal;
>}
>}
>}
>
>
>if (index != -1) {
>int shadow_index = -1;
>
>vec3 lightvec = normalize(lightposs[0] - objposs[index]);
>
>vec3 shadow_pos = intersect + lightvecSMALLADD;
>
>
>
>for (int i = 0; i < OBJ_NUM; i++) {
>ret = SphereRaycast(shadow_pos,lightvec,objposs[i],radiuss[i]);
>if (ret.casted) {
>shadow_index = i;
>break;
>}
>}
>
>if (shadow_index != -1) {
>color = vec3(0.0,0.0,0.0);
>}
>else {
>color = colors[index];
>}
>
>color = dot(normal,lightvec);
>}
>
>
>return color;
>}
>
>void main() {
>vec3 pos = (cameravec4(0.0,0.0,0.0,1.0)).xyz;
>
>float x = gl_FragCoord.x;
>float y = gl_FragCoord.y;
>
>vec3 dir = (camera_notransnormalize(vec4((x - WIDTH/2)/WIDTHtan(FOV/2)WIDTH/HEIGHT,(y - HEIGHT/2)/HEIGHTtan(FOV/2),-1.0,1.0))).xyz;
>
>FragColor = vec4(RaytraceObjects(pos,dir),1.0);
>}


Разметка потерялась. Я имел ввиду


#version 420

uniform mat4 camera;
uniform mat4 camera_notrans;

out vec4 FragColor;

#define WIDTH 1200.0
#define HEIGHT 800.0

#define FOV 1.309


vec3 objposs[2] = {vec3(0.0,0.0,-35.0),vec3(7.0,-5.0,-38.0)};
float radiuss[2] = {5.0,3.5};
vec3 colors[2] = {vec3(1.0,1.0,0.0),vec3(1.0,0.0,0.0)};

vec3 lightposs[1] = {vec3(-4.0,15.0,-5.0)};


struct CastRet_t {
bool casted;

vec3 normal;
vec3 intersect;
};

CastRet_t SphereRaycast(vec3 o,vec3 d,vec3 pos,float r) {
CastRet_t ret;
ret.casted = false;

vec3 o_minus_c = o - pos;

float k1 = dot(d,d);
float k2 = 2*dot(o_minus_c,d);
float k3 = dot(o_minus_c,o_minus_c) - r*r;

float undersq = k2*k2 - 4*k1*k3;

if (undersq >= 0.0) {
float t_test = (-k2 - sqrt(undersq));

if (t_test >= 0) {
float t = t_test/(2*k1);

vec3 intrs = (o + d*t);

ret.intersect = intrs;
ret.normal = normalize(intrs - pos);

ret.casted = true;
}
}

return ret;
}

#define OBJ_NUM 2

#define SMALLADD 0.004

vec3 RaytraceObjects(vec3 pos,vec3 dir) {
vec3 color = vec3(0.0,0.0,0.0);

int index = -1;
vec3 intersect = pos;
vec3 normal = vec3(0.0,0.0,0.0);

CastRet_t ret;

for (int i = 0; i < OBJ_NUM; i++) {
ret = SphereRaycast(pos,dir,objposs[i],radiuss[i]);
if (ret.casted) {
vec3 lvec0 = ret.intersect - pos;
vec3 lvec1 = intersect - pos;
if (index == -1 || dot(lvec0,lvec0) < dot(lvec1,lvec1)) {
index = i;
intersect = ret.intersect;
normal = ret.normal;
}
}
}


if (index != -1) {
int shadow_index = -1;

vec3 lightvec = normalize(lightposs[0] - objposs[index]);

vec3 shadow_pos = intersect + lightvec*SMALLADD;



for (int i = 0; i < OBJ_NUM; i++) {
ret = SphereRaycast(shadow_pos,lightvec,objposs[i],radiuss[i]);
if (ret.casted) {
shadow_index = i;
break;
}
}

if (shadow_index != -1) {
color = vec3(0.0,0.0,0.0);
}
else {
color = colors[index];
}

color *= dot(normal,lightvec);
}


return color;
}

void main() {
vec3 pos = (camera*vec4(0.0,0.0,0.0,1.0)).xyz;

float x = gl_FragCoord.x;
float y = gl_FragCoord.y;

vec3 dir = (camera_notrans*normalize(vec4((x - WIDTH/2)/WIDTH*tan(FOV/2)*WIDTH/HEIGHT,(y - HEIGHT/2)/HEIGHT*tan(FOV/2),-1.0,1.0))).xyz;

FragColor = vec4(RaytraceObjects(pos,dir),1.0);
}

Как продумать геймплей игры?

>>122855
Погугли хуету про геймлупы, наверное. Там есть что-то core-механиками называлось вроде бы. И ещё какие-то термины были.

>>122855
Берешь и играешь в голове в свое поделие. Оцениваешь насколько увлекает, просто или наоборот неприятно. Потом придумываешь как все пофиксить чтобы игорь всплыл.

Какой сервис посоветуете, чтобы вести публичный документ с информацией об игре?

>>122855
Кроме того, что аноны свыше сказали, помни, что люди любят планировать. Используй их любовь к планированию, чтобы создать геймплей. Например, если монстры в игре генерируются совершенно рандомно, то игрок не знает их способностей и не может спланировать тактику и игра становится скучной!

>>122892
Гитхаб? Вообще не улавливаю, что тебе нужно от такого сервиса и почему инфу об игре нужно держать публичной. У меня опыта работы в команде нет, но меня устроило бы получать самую актуальну версию диздоков на игорь из соответсвующей ветки репозитория.

>>122819
Я случайно твоё сообщение, где приводится пример кода через вычислительный шейдер.
Ты будешь пробовать, чтобы сравнить производительность вычислительного с фрагментным?

Я могу взять один из вариантов - предлагаю сделать какую-нибудь простую сцену, где 50 треугольников, 10 сфер, из которых 2 сферы и 5 треугольников полностью зеркальные. Просто как несколько си-массивов их указать, а дальше каждый уже сам как захочет эти массивы использует.
Можно с текстурами или ещё чем-нибудь.

Как на Си делать замедление экрана лучше всего?

>>123420
Что такое замедление экрана; и какое отношение к этому имеет си, если это вопрос исключительно к архитектуре движка, а не к си?

>>123424
Причём здесь движок?
Допустим, моделирую движение звёздочки по экрану. Мне нужно же как-то её рисовать. Для этого нужно замедление.

>>123427
Движок, не в смысле движок, а в смысле ядро твоей программы, то как она работает и моделирует звёздочки.

Не могу понять что такое "замедление".
Например, у тебя звёздочка двигается по закону x=a+b*t, в момент рисования получаешь, например, системное время, и считаешь t как текущее системное время минус начальное системное время, после чего рисуешь звезду в соответствующем месте?

>>123427
>Мне нужно же как-то её рисовать. Для этого нужно замедление.
Рисуй ее каждый кадр по одним и тем же координатам. А сами координаты изменяй со временем. Для времени используй что-нибудь системное типо GetTickCount. Формула движения оче проста: x = x + (Vel * dt), тут dt твое время между кадрами, а Vel желаемая скорость в пх/сек.

>на Си
Это конечно непрошеный совект, но если ты нюфаг(судя по вопросу), то лучше выкини богоподобную Си начни с чего-нибудь полехче. Я рикаменду связку C# + XNA. Профит в том что есть базовый каркас приложения в котором уже за тебя решили проблемы вроде расчета времени и управления окном и при этом есть полный доступ к низкому уровню графона - пиши какие угодно шейдоры и как угодно реализуй свой конвеер отрисоркив и в целом любую архитектуру игры.

сап, тучка, подкинте русскоязычных доков а лучше туторов степ бай степ по Vulkan.

Мне нагуглился сайт https://vulkan-tutorial.com/Drawing_a_triangle, там всё понятно расписано, но что-то я почти в голос расхохотался от всего этого кода, который нужен просто для создания контекста или как там это называется. Ненормальные, там в самом деле почти тысяча строк (https://vulkan-tutorial.com/code/16_swap_chain_recreation.cpp).

Я бы порекомендовал изучать opengl 4, при его изучении всё-равно вникнешь во все эти буферы, поллы команд и конвейер - но не нужно вникать сразу во всё ради отрисовки треугольника, что позволит немного более последовательно изучать это. Вулкан выглядит как что-то с высоким порогом вхождения, можно сказать я вовсе не понимаю зачем он нужен.

>>123485
> что-то я почти в голос расхохотался от всего этого кода, который нужен просто для создания контекста
Издержки полного и детерменированого контроля стейта на видеокарте. Раньше этим всем рулил драйвер видеокарты напополам с ГАПИ, и было слегка неоптимально в некторых местах отчег разработчики очень плакали. А теперь все можно сделать очень круто, но вручную, но зато очень круто.

>>123410
Баловство это всё. На шейдоры можно угробить кучу времени, а импакт на игру будет 0.5% вау-эффекта.

Тоже раньше баловался, но во время осознал какой же я бесперспективной хуйней страдаю.

Вот взять туже сверу что есть выше по треду (кстати вот она >>122819). Ее тупо не существует в коде, она есть только на экране ибо целеком захардкожена в шейдоре. Как к ней прикрутить например физон? Завести еще одну сферу в коде? А нахера их две, если мы можем одну и рисовать передавая ее как вершины, и сразу считать по ней физон. Она будет реально в коде, т.е. с ней потенциально можно делать все что угодно, в отличии от вкомпилиной в шейдер.

Шейдеры это та еще ересь.

>>123490
>было слегка неоптимально в некторых местах отчег разработчики очень плакали
>но зато очень круто
И сколько эти дополнительные расходы на работы драйвера и апи составляли от общего времени рендера? 3% или 1%? Брр, бред какой-то.
Мне кажется, что это даст заметный выигрыш только если постоянно переключаешь глобальное состояние и другим способом злоупотребляешь вызовами функций opengl. Достаточно просто держать низким соотношения количества геометрии к количествам вызовов opengl.

>>123491
>ибо целеком захардкожена в шейдоре.
Достаточно прикрутить ubo или ssbo со всей информацией про геометрию. Это раньше даже ubo не было, и люди кодировали геометрию в текстуру, которую в шейдере "распаковывали" потом.

Как написать точный физический (механический) движок?
Меня интересует как описывается вращение тела. Есть некий тензор инерции, но я не совсем понимаю, что он означает.
Меня интересует как сделать его точным. Не получится сделать прямую зависимость от формулы, так как задача трёх тел неразрешима, значит, придётся итерировать. Существует алгоритм Гилберта — Джонсона — Кирти, можно ли при пересечении сделать так, что используется одна дельта, если пересечение есть, то уменьшаем дельту и считаем заново и так до тех пор, пока пересечение не станет достаточно маленьким или есть более простой метод?

Придумал вам идейку для выживалки. Сам я реализовывать её не буду.

Жизнь монстра с нуля в человеческом мире. Игра начинается историей эмбриона, о том как он живёт, как развивается, он это рассказывает. Что он недавно осознал себя, исследовал окружающий мир (утробу), про поток крови извне. Что он научился управлять своими тканями и вырастил себе 4 ноги, 4 руки и 2 декоративных отростка, так как посчитал привлекательным. О том, как он децентрализовал себе сердце и некоторые другие органы (в т.ч. мозг, но его сложнее), так как считает децентрализацию более правильной. Но потом случилось непроправимое. Он родился.
Почувствовал как что-то происходит вокруг, это было очень страшно и неприятно, как его перевернуло головой и начало толкать. Когда он вышел, то сразу же заорал как резанный, ведь ничего не понятно, раньше он жил в прекрасном мире, а теперь его выбросило в совершенно неизвестную среду обитания. Приниматель родов стоит в кататании и офиге, ассистентка заорала и сбежала, мать спрашивает, что не так, что с её ребёночком. А сам ГГ встаёт на свои 8 конечностей и инстинктивно убегает. В этом этапе нельзя управлять им точно, разброс движения большой и он бежит по одному нажатию, пока не врежется в стену (не привык ещё). После того как он смог выбежать в коридор и перепугать весь персонал, добегает до поворота и показывают катсцену, где его мать с потными патлами, кровью падающей с низа и дикой болью в нижней части туловища добирается (думала, что какое-то животное утащило ребёночка), но осознает, что это то, что она родила и падает на четвереньки. Тут у главного героя проявляется нёбное жжение вокруг зубов (знаете, когда волнуешься или что-то типа того), он кусает свой рот и чувствует вкус своей крови. На экране появляется резкая надпись ГОЛОД, экран мутнеет, но обозначается цветом. Мать обозначена жёлтым цветом еды. Теперь ему надо побежать к ней, он врывается в неё и... Через несколько минут мирно сосёт молоко из груди. Врачи боязно положили нашу парочку на кушетку. Вызвали полицию на всякий случай, так как полученное существо точно не человек и очень непредсказуемо.
Когда ребёнок накормлен, пора на волю. Теперь ГГ научился управлять руками и может нелепо, но бегать. Тут управление нормальное, игроку надо прорваться сквозь полицию и сбежать в природные места. Лес, пустыня, равнина, дикий пляж, что-то из этого. А дальше идёт обычный геймплей выживалки. Построить укрытие, научиться искать еду. Бонусом надо сделать возможность ему изменять своё тело как в Spore или подругому.

Можно использовать такой сюжет и не для игры, а для комикса/мультфильма/фильма, но вряд ли он многим зайдёт, ведь ГГ — одиночка и alien. Иначе давно были бы популярны манги про протаганистов линуксоидов, безумных учёных, единственных оставшихся человеках на Земле.

>>123761
>Как написать точный физический (механический) движок?
Хз что имеешьпод словом "точный", но написать двиг чтобы считал точно как ирл за разумное время(реалтайм) невозможно. Всегда тела будут немного наезжать друг на друга при столкновениях, это лечится грязными хаками расталкивания или сткрытия фейловых пересечений.

Применительно к играм дествительно ценное качество физ.движка - детерминированость. т.е. он для одних и тех же исходных данных он должен давать одинаковые ответы. Из-за повторяемости результатов например в онлайндрочильнях можно исключить синхронизацию физики по сети каждый кадр, а делать ее значительно реже проверяя что игрок не читерит.

>>123821
А почему вообще можно написать недетерменированный движок? Я понимаю, что это возможно, но для чего? Авторы таких движков данные из /dev/urandom берут? Или сортируют указатели по адресам?

>>123830
>А почему вообще можно написать недетерменированный движок?
Любой физон сам по себе получается недерменированым. На хардварном уровне влияет тот как реализован числа с плавающей точкой. Вроде как есть для этого стандарт, но он не покрывает граничных случаев и на разных процессорах можно получить результаты различающиеся в младших разрядах. Еще влияет как на системном уровне сделана функция времени, в туже копилку функция рандома. Все это дает расхождение результатов со временем для одинаковых физических тел.

>>123835
Хорошо получается. Тем временем я вообще обленился, лол.

>>123857
А что если использовать числа с неплавающей точкой ака инты, а дельту считать исходят из тиков (N тиков в секунду), то есть будет одинаковый шаг? Тогда она должна быть детерменирована (если шаг будет одинаков).
Вообще я вчера придумал как сделать дельты. Пусть будет дельта максимальная и дельта минимальная. Дельта максимальная это обычный шаг, обозначающий пройденной время, но если тела начинают сталкиваться, то можно уменшить дельту и просчитать заново и так до тех пор, пока он не будет равной минимальной дельте. Таким образом, столкновения будут более точными. Но будет ли это работать в риалтайме, я не знаю.

Я что-то вообще в механике плох, хотя и читал когда-то учебник по теормеху. С материальной точкой всё ясно, у неё одна мера инертности — масса. Вектора скорости и силы, вот и всё.
С 2D-телом я вчера пытался вспомнить, как разложить силу, приложенную в произвольную точку на силу, приложенную к центру масс и момент сил, но не смог. Ладно, сейчас пойду снова читать.
Я также не понимаю как происходит вращение 3D-тел. Они что, вращаются относительно трёх осей? Можно ли приложить к телу один момент сил в произвольном направлении и разложить его на моменты сил относительно ортогональных осей? Мне надо будет это узнать и понять. Также я не понимаю, почему волчок не падает и почему существует эффект Джанибекова.

>>120101 (OP)
А куда делся анон с индастриворксом? Треды, если что, не читал.

>>126686
Вот он >>125168

>>126686
Я тут есть и был, даже после того, как админ убил тучку джва раза.

Индустриворкс я уже давно забросил, собираюсь и игру про помидорку забросить. Недавно в треде я рассуждал, что у меня слабая воля, так как я не делаю игру, а ведь сделав, я мог бы заработать некоторые деньги. Но что если рассудить подругому? Мне не нравится делать игры. Можно было бы за денёк нарисовать демосценку по фану, но месяцами делать одну игру это не то. Я не хочу. И разве это моё волеизъявление — делать игры? Нет. Мои волепродукты были бы совсем другие.
Когда-то давно я начал и продолжал делать Индустриворкс, питая данный вектор воли надеждой на получении денег. А игра про девочку-помидорку по моим прикидкам принесёт всего лишь 250 долларов с продаж в первый месяц. -100 долларов на стим директ, итого 150. Да, доход, но я и так уже научился зарабатывать гораздо больше за месяц при помощи фриланса и сверхспособностей. Можно сделать игру, а можно просто поработать. В первом случае я смогу избежать большого стресса, а во втором случае всё будет быстрее. В глубине моя психика понимает, что мне ни к чему делать игры.
И ситуация в мире сейчас такова, что некогда развлекаться, надо заниматься реальными делами.
Боюсь, это закат моей игроиндустрии. Но надо подождать ещё пару месяцев для окончательного решения.

>>126775
>админ убил тучку джва раза
Чего?

>>126881
Помнишь, когда админ выключал постинг на пару недель, но при этом другие аноны могли постить?

>>126902
Не помню, у тебя шиза, кажется.

>>126902
Ты про то когда он без повода треды тёр? Помню-помню, но я бы не оскорблялся от такого

>>126902
Постинг с тора?

>>131281
Галактика Сомбреро, наверняка.

>>120101 (OP)
на последнемм видосе симулятор травы?

>>131934
Можешь станций прикрутить?
Напомнило reassembly

>>131952
Прикручу. Но потом.

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

>>120101 (OP)
>хочу сразу делать игру. Как?
>Ответ: Учи C или C++
Это, пожалуй, самый идиотский совет, который можно было бы дать. Если человек хочет сразу делать игру, то он может взять условную lua и начать делать игру (а не учить коболы, которые к играм вообще никакого отношения не имеют (кроме крестов и ААА, но это нерелевантно, если человек только собирается запилить первую игру)).

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

>>132877
>Любая 3д-модель с анимациями может быть отрендерена в набор спрайтов.
Это не нужна, вторая часть игры про помидородевочку была бы 3D-шной (так как по сюжету этой, главная героиня освободится от оков двадешного мира и перейдёт в 3D).

Что насчёт анимаций, то чем красивее и разнообразнее анимации, плюс щепотка реализма и будет гораздо лучше.

>>135145
Попробуй лучше kotlin. А то java слишком оопная, офисная и юриспруденческая. Когда пишешь на джаве, ощущение, будто зашёл в отдел бухгалтерии.

>клон марио на андроиде
Не, тогда выбирай Годот. Можешь ещё юнити попробовать, но он проприетарный.

>Пиклейтед
Я считаю, что если хочешь стать программистом, то надо начинать с Си, Ассемблера.

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

>>135146
>А то java слишком оопная
А чем это плохо? Любишь писать в процедурном стиле?

>>135145
>на андроиде
Джава. В десять раз больше инфы и примеров.

Ищу художника чтобы вместе делать игры.

>>135972
Го

>>136110
Есть телега, или еще что-нибудь? Пиши в тг если что @sober_sue

>>137262
Очень уже бросатеся в глаза разный размер пикселей на переднем и заднем плане. Мне кажется надо делать одинаковый размер чтобы было #нормально.

>>145064

>в последнее время мне не очень нравится ,что происходит на тучкЕ
Ты про набег политоты, который в половину тредов проник?
Мне тоже очень не нравится - я никак не влияю на политику, обсуждение её - пустая трата времени. Даже еот треды лучше - они хотя бы не противные, и тема отношений и психологии интересная. А политота всегда негативная - кто кого обманывает, где и кому плохо.

>>145183
Попробуй пидорни их отсюда. У тебя ничего не выйдет.

Давайте скатите и Gamedev, один из немногих нормальных тредов, в сраную мету. Долбоёбы, своими же руками борду скатываете в говно.

>>145781
А мне статья не понравилась.

Во-первых она сообщает банальные и очевидные вещи для тех кто хоть раз делал гуй в игру. Выебать иерархию прямогугольников с текстурами может любой погромист - тут много ума не надо.

Во-вторых она не отвечает на действительно важные вопросы. Один из таких вопросов например, это лейауты - компоновка экрана под любые разрешения экрана. Проблема сложна и не решается тривиальным - вот эти контролы мы в столбик рендерим когда у нас строка заканчивается. Еще пример это сохранение и восстановление состояния контролов. Можно словить очень много приключений в дебагере, если не будет простого способа воспроизвести гуй.

Кстати, недавно насасаче я писал, что новый вид Индустриворкса должен стать не как факторио с заклинаниями, сердечными кристаллами и MP, а просто крафтодрочильня, где как в GregTech надо очень много крафтить и это идёт медленно.
Тем не менее, некоторые заводы будут, но я не заставлю игроков строить тонны бельтов, потому что в Индустриворксе теперь должен быть просто крафт ради крафта. А в конце надо улететь на ракете в гигантскую дыру, с которой выпал главный герой.

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

Тут

0. Палка + Палка = Огонь.
1. Палка + Камень = Топор.
2. Камни + Глина = Печь.
3. Печь: Древесина + Огонь = Зола + Древесный уголь.
Доломит — флюс.
Лимонит — поверхностная железная руда.
Магнетит — недровая железная руда.
4. Печь: Глина = Тигель.
5. Печь + Тигель: Лимонит + Доломит + Древесный уголь/Кокс = Чугун.
6. Керамика = Керамический Порошок.
7. Глина = Глинистый порошок.
8. Печь: Глинистый порошок + Керамический Порошок = Шамотный кирпич.
9. Керамический Порошок + Глинистый порошок = Мертель.
10. Вода + Мертель + Шамотный кипрчи = Высокотемпературная печь.
11. Шамотный кирпич = Проволочная насадка.
12. Шамотный кирпич + Чугун = Трубная насадка.
13. Высокотемпературная печь + Проволочная насадка = Проволочно-экструзионный высокотемпературный станок.
14. Высокотемпературная печь + Трубная насадка = Трубно-экструзионный высокотемпературный станок.
... Профильная насадка.
15. Чугун + Трубно-экструзионный высокотемпературный станок = чугунная труба.
16. Древесина + Чугун = Механический Нагнетатель.
17. Древесина = Вал.
18. Древесина + Вал = Гидромельница.
19. Поддувало = Труба + Нагнетатель.
20. Высокотемператураная печь + Поддувало = Печь для стали.
К печи для стали подключить вал.
21. Печь для стали: Чугун = Сталь.
22. Печь: Глина = Литьевая Форма: Наковаленная, Кулачковая, Шестерёночная, etc.
23. Печь для стали + Наковальная Форма: Сталь = Наковальня.
24. Наковальня: Сталь = Режущие инструменты I-ного (наинизшего) класса — свёрла, резцы.
25. Печь для стали + Формы: Сталь = изделие.
26. 3 кулачка + шестерня с архимедовой спиралью + древесина (корпус) = Трёхкулачковый патрон наинизшего класса.
27. Чугун + Профильно-экструзионный высокотемпературный станок = чугунная проволока.
28. Чугунный профиль + трёхкулачковый патрон + сталь + древесина = Токарный Станок (наинизшего уровня).
К токарке подключить вал.
29. Токарный станок + Сталь = Прокатный вал.
30. Прокатный вал + шестерня + профиль = прокатный станок.
31. Прокатный станок: Сталь = стальные листы.

Малахит — медная руда.

32. Печь + Малахит + Древесный уголь/Кокс = медь.
33. Медь + проволочный станок(печь) = Медная проволока.

Напольник — культура для выработки биоспирта.

34. Напольник + Глиняный контейнер: Спирт.
35. Спирт + Смола = Лак.

36. Накручивальник (вал) + Лист металла = Покрывающий станок.
37. Покрывающий станок + Лак + Медная проволока = Лакированная медная проволока.

38. Печь + Медная проволока = Намагничивающий станок.

39. Намагничивающий станок: Сталь (или другая заготовка) = магнит.

40. Лакировання медная проволока + тонкий стальной лист (или другой) + медь + стальной лист + магнит = Электрогенератор.

Сфалерит — цинковая руда.
Касситерит — оловянная руда.
Галенит — свинцовая руда.

41. Цинк + Медь + Вода/Щёлочь/Кислота = химический источник тока.

42. Лакировання медная проволока + тонкий стальной лист (или другой) + медь + стальной лист + магнит + графит = Электродвигатель.

>>147420
>Вот, что пока наваял
Лучше бы ты это в редакторе майндмапов рисовал, или в какой-нибудь приблуде типа uml если ничего другого не знаешь, лол. По схеме можно сразу одним взглядом оценить что как и из чего получается, а в списке теряешься.

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

Аргх, технология не работает, я снова не могу так просто брать и делать игры.

Очень печально, ведь если осознать, то я за 2-3 месяца мог бы сделать игру, которая принесла бы мне десятки тысяч долларов, на которые можно купить не только предметы, но и недвижимость!
Все проблемы в мозгах.

>>147729
Интересно, можно ли как-то сделать витки технологий Индустриворкса такими, чтобы каждый тип игроков своё выбирал? Например, один решил использовать батарейки на алюминий-воздухе, второй литиевые аккумуляторы, а третий водородом заправлять движки? Сделать такое очень сложно, я в геймплее очень плохо разбираюсь.
Моя голова гаразда придумывать разве что сюжеты с высоким уровнем упоротости, но очень мало из них реализовались на практике. А когда реализовались, комьюнити приняло-неприняло (рейтинг ушёл вроде бы в ноль, но на самом деле в небольшой минус). Из-за того что навыки реализации были маленькими.
А в Индустриворкс сюжеты не запихнёшь. Сюжеты надо пихать во вторую часть игры про помидородевочку, а перед этим сделать её первую часть.

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

Например, железо и магний. Есть магниты, где в любом случае необходимо некоторое количества железа, и есть какая-нибудь фигня из химии, для которой нужно какое-то количество магния.
Переложить обязанности "по выбору сюжета" на генератор карты. Все инструменты и металлические конструкции можно сделать как из железа, так и из магния - и если тебя заспавнило на планете где железо в дефиците - то ты будешь играть в "свой путь" вешаясь от сложности производства магния и недостаточной прочности магниевых конструкций, и только в критических местах использовать драгоценное железо, если что-то после магнитов останется.

>>152089
Версия 2020
>Здраствуйте. Я, Номад. Я пишу рицензии на саите riotpixels. Делаю обзоры на девайсы фирмы razer, суть такова… Пользователь может купить мембранную клавиатуру за 10k. И если пользователь думает нахуя ему так много платить за то, что в Китае стоит копейки, то тут есть ЛГБТ подсветка, китайские кнопки которые не всегда прожимаются и зелёный геймерский логотип для геймеров. А ещё мне за это платят. Это самое главное. Можно грабить корованы…

А пробовали читать рецензии на уг.ру на игры 90-х? До появления номада. Это такой лютейший треш...Уровня малолетних гопарей на лавочке под пивас обсуждающих как вчера они чиста в конкретную игруху шпилили

>>152089
Так это он написал про андертейл, как почти дошёл до первого домика и жаловался, мол всё розовое?

Что-то чессмейтов не получается обновить... Графический движок багает. Поэтому его надо подчистить.
У меня возникли вопросы по рендерингу.
Во-первых, какие характеристики есть у PBR? Я не совсем понял про тот же roughness, например. Вот можно взять посмотреть на свет. У него есть длина волны и поляризация. От этих характеристик и от угла падения зависят характеристики отражения и преломления. По-сути их можно велосипедно описать функциями, мол частоты такого диапазона отражаются на такой угол, а другие на такой. Но мне лучше бы коэффициентов и готовых формул, чтобы не утруждать возможных будущих пользователей писать функции под все 2-4 бекенда. опенгл, глсл, софтрендер, етц.
Что делают всякие свойства, которые позволяют немного проникнуть свету под материал (под кожу, например) и отразиться? Я совсем этого не понимаю и почему бы просто не заменить его цветом?
Алсо я подумал над таким свойством материала, как карта высот. Это как карта нормалей, но влияет и на форму меша. Думаю, сложно будет сделать реализацию для опенгла, но не сложно для рейтрейсинга. Или реймаршинга.
Ещё можно добавить такое свойство как карта микровысот для симуляции интерференции света. Чтобы, например, рендерить мыльный пузырь. Он будет шаром, но его стенки как бы будут иметь разные толщины и света проинтерферируют меж собой.

Во-вторых, какие примитивы следует добавить?
Сейчас у меня стоит triangles, nurbs и generic. Всё это время реализованы были только trinagles. С нурбсами я пока не очень разобрался. Знаю только, что в них входит линия Безье и, скорее всего, с их помощью можно и суперэллипсы рендерить. Не придётся писать аппроксиматор для библиотеки ГУИ.
И тут я подумал о введении такого примитива как воксельное октодерево. Его будет легче рейтрейсить или реймаршить, чем сетку треугольников. И аппликаций, вроде, не мало. Начиная майнкрафт-подобной игрой и заканчивая визуализацией всяких скан-данных или скульптинга тридемоделек.

В-третьих, что насчёт рендеринга объёмов?
Я недавно понял, что иногда же надо рендерить всякие мать-дымки, пары, желе. Но для них нужны объёмные меши, а не треугольники или нурбсы. Ввести сферы? Или, скорее, абстрактные частицы? Можно даже сделать так, чтоб в случае текстурных частиц просто навесить на них текстуры и они автоматически будут повёрнуты в камеры... А в случае рендеринга дыма можно представить их как signed distance function с смусовым юнионом...
Но такое я бы реализовывал только для рейтрейсинга. Не уверен, что в опенгл-бекенд буду даже тени вводить. Только если не получится добиться хорошей производительности для какой-нибудь своей будущей игры, может...

>>152985
По-русски плиз

Антивайперский бамп.

Господа игроделы, чем вы пользуетесь для отладки шейдеров? Есть ли годная интерактивная IDE?

>>163098
Лично я ни чем не пользуюсь. Делаю отдельную тестовую прогу в которой только нужный шейдер и его отладка. Все как у дидов из 90-х.

А так юнити годная интерактивная ИДЕ для отладки шейдоров собранных на нодах. Еще вариант попробовать блендер - там тоже есть ноды и где-то был их экспорт в тектовый глсл который понимает любой движок.

Алсо, давно у нвидии была отдельна ИДЕ под шейдеры - FX Composer. Я ее пробовал, но она мне непонравилась. В ней сложно настраивать тестовое окружение. То что в самопальной программе делается парой строчек пресетов надо пердолить через неочевидный гуй.

Из онлайна есть очевидный shadertoy.com, отдебажить мелкую ерунду там тоже вполне можно.

>>163111
Спасибо, анон.

>>171561
Лайси-кун ушел на эндчан.

>>171564
Нашёл его. И игру больше не делает, зануда он такая.

>>171561
Где фигурные скобки? Ты че, сишников не уважаешь? Объяснись!

>>176439
То не моё видео, я просто замедлил, потому что у анона слишком быстро было.

У меня вот тут упирается на 39 секунде, что хорошо видно >>122204
Может быть это был float, я не помню.

>А при переходе на числа с неопределенной длиной, все работает в 100-500 раз дольше.
Какая-то хуёвая реализация, мне кажется.
Если что, есть нативно поддерживающийся long double на 80 бит, который на всех пк процессорах. Так называемый набор инструкций x87. Просто пишешь в си long double.
Ещё в gcc есть quadmath на 128 бит, который работает раз в 20-40 медленнее нативно поддерживающегося типов при использовании делений и тригонометрии. Скорее всего при использовании только лишь умножения и сложения там разница будет раз в 10-15 едва ли.
Я могу попробовать сделать свою реализацию на 256 бит, если интересно - и проверить на тех же фракталах.

>>176448
> Какая-то хуёвая реализация, мне кажется.
Так и есть, использовал BigDecimal, предназначенный для точных операций с валютой, там можно любую длину задавать.
> нативно поддерживающийся
Не подумал про это, или не хотел тогда разбираться.
> Я могу попробовать сделать свою реализацию на 256 бит, если интересно - и проверить на тех же фракталах.
Твое дело, анон. Но интереснее было бы именно неограниченную длину. Так называемая "длинная арифметика".
Мне предлагали для тренировки написать подобную библиотеку на джаве, но это довольно нудная задача(копипаст), скорее всего, можно готовое найти на с/c++.
С другой стороны, если будет быстро работающий вариант на 256 бит, чтобы можно было вручную двигать, будет круто. Я бы скачал, поигрался с ней.

>>176737
> Или ты хочешь отказаться от плавающей запятой вовсе и хранить в виде n/10²⁰?
Да, отдельной переменной запятую хранить. Данные в массиве из ulong, например.

> Или даже хранить почти что в символьном виде, в виде пары целых чисел n/m?
Пара целых чисел будет помещаться в куда меньший диапазон, чем f64, хотя точность будет больше. Будет долго работать, скорее всего, быстро дойдет до переполнения даже с u64.

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

>>120101 (OP)
>4

Сколько за машграф получил?

>>176794
> (a+x)e
Можешь показать пример кода, где ты это применил?

>>176821
>friend
>перегрузка *
Чёт горит с этих лишних сущностей.

>>176849
Так не используй их, бака. Никто не заставляет.
Да ладно, нет ничего логичнее перегрузки математических операторов для численного типа. Не писать же add(a,b,&c).
>friend
Нахожу сложение аргументов a и b куда более логичным, чем сложение *this и b. Не очень понятно почему нельзя использовать static в этом случае, ну да хрен с ним.

А вообще да. Только лишние сущности это noexcept и вся система исключений, шаблоны по типу std::enable_if вместо нормальных ограничений на допустимые типы для шаблонов и кучу легаси-приблуд, по типу что sin меняет глобальное состояние, и ты не можешь написать constexpr float x = sin(0.3f); лол.

Не очень понимаю, почему комитет стесняется добавлять удобный синтаксический сахар по типу питоновского оператора with (внутреннее устройство которого очень понятно, а использование очень ёмко и лаконично) - или хотя бы просто синтаксический сахар для умных указателей - есть же свободные символы $ и @. И почему в стандартной библиотеке нет и не предвидится кроссплатформенной функций для работы с сетью.
А вот [[fallthrough]] это очень полезная фича, сразу пошёл добавлять во все проекты. Или всё то что они с шаблонами делают, всякие кастомные deduction guides про которые я бы предпочёл никогда в своей жизни не слышать.

Но как говорят есть два типа языков - на которые все ругаются, и которые никто не использует. Кресты на восьмёрочку, они очень неплохи сейчас. Особенно по сравнению с тем, что было в 11 стандарте или упаси боже в 03 стандарте.

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

>>177220
А что за задачи?

>>177212
Я готов ждать джва года.

Зачем вам гейдев, если крудошлепам и тырпарйзмакакам больше платать за меньше ебли?

>>177258
Для души, как говорят.

А где ты геймдев тут увидел?
Нет критической массы, тут только смежные области фрагментами. Где-то 0.6-0.8 от критической массы, так что тухнет через несколько итераций. Вот лайси-кун ненормальный — и у него уровень самомотивации был такой, что получалось около 1.1 критической массы - он достаточно продолжительное время не забрасывал своё, при этом делал другое и ещё куски мотивации перепадали остальным.

>>177212
>Сюжет, игра и персонажи вымышлены.
Потриксил.

В чём твоё предложение то?
И почему в этом (>>177256 (OP)) треде что-то очень похожее, но с другой группой вк? Какой-то местный абуз ради просмотров группы? Но там 50 человек.

>>177258
Никакое бабло не сделает ненавистное формошлепство более привлекательным. Долго не протянешь, выгоришь.

>>177262
Я выгорел. Но это, наверное, потому что я сам ленивое говно.

А так - выгорание зависит от места работы, если потогонка, то да. Так же и в гейдеве, думаю.
А если месяц строите архитектуру ГетЮзер - то и норм.

>>177235
Системные задачи.

А никто прошлый тред не сохранил? У меня есть первый, но второго нет.

>>120874
ебать дед правду матку говорит, а быдло его обсмеяло. Еще блять лену притянули. Вот пидоры

>>179498
Какую правду? Дед сам всю жизнь нихуя не делал и сейчас делать не хочет, но воняет на молодых, чтобы они ему коммунизм сделали. Всю жизнь прожил, а так и не понял, что просто так нихуя не делается.

С помощью C++ и SDL можно сделать игру с графоном как в Daggerfall?

>>179498
Всё так. Завсегдатаи геймдева, конечно же могут возразить, что они не для дебилов убивалку времени делают, а какое-то там искусство творят. Вполне может быть. Но ведь речь о другом. О том, что большинство игроблядей именно такие, какими их описал дедуля. Великовозрастные идиоты, играющие в дноту. Немощные социальные инвалиды. Дегенераты.
>>179499
Дедуля ни слова о коммунизме не сказал. Судя по его речи, он кое-что таки делал в жизни. Во всяком случае, то что делал он и что делают игродебилы не идет даже ни в какое сравнение. Пусть совок, пусть плановое говно, но тогда люди умели спроектировать целый завод при помощи карандаша и бумажек. И это даже не шутка. Это курсачи и дипломы такие у них были в послевоенное время. Он-то знает что просто так нихуя не делается. И наверняка знает, что с чего-то начинать нужно. А игродебилу лишь бы похихикать и ничего не делать.

Что из перечисленного лучше для разработки игр: C, C++, C# или Python?

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

>>179502
Все кроме питона

>>179504
А из оставшегося что лучше выбирать?

>>179505
Смотря какие цели. Мощные масштабные игры только на С и c++. Что нибудь полегче для инди например идеально подходит C#.

>>179506
Я хочу создать RPG уровня Daggerfall или Might and Magic VI-VIII.

>Мощные масштабные игры только на С и c++.
А что лучше из этого брать?