Сохранен 66
https://2ch.hk/gd/res/644712.html
24 декабря 2023 г. Архивач восстановлен после серьёзной аварии. К сожалению, значительная часть сохранённых изображений и видео была потеряна. Подробности случившегося. Мы призываем всех неравнодушных помочь нам с восстановлением утраченного контента!

Как это сделано, в чем секрет архитектуры кода?

 Аноним 24/02/20 Пнд 13:21:54 #1 №644712 
fd1f632099404d13bb4a9c2ce3f1284e92058e00078b28baf5e6858887e[...].jpg
Как это сделано, в чем секрет архитектуры кода? Несколько миллионов объектов с кучей взаимодействий друг с другом, обновляется 60 раз в секунду и не тормозит. Каким образом? Давайте обсудим.
Аноним 24/02/20 Пнд 13:31:55 #2 №644713 
>>644712 (OP)
Просто не надо пользоваться памятью как распиздяй.
Ну и по возможности батчить все что можно, конвейеры обрабатывать группами, а не каждый по отдельности.
Аноним 24/02/20 Пнд 13:32:50 #3 №644714 
>>644712 (OP)
Секрет, в том, что большая часть объектов не взаимодействует. Их следующее состояние определяется предыдущим состоянием и прошедшим временем. Поэтому нет необходимости обновлять 60 раз в секунду.
Видел SwarmSim? Пока пользователь не вмешивается в ход вещей, состояние полностью детерминировано.
Аноним 24/02/20 Пнд 13:40:45 #4 №644715 
>>644714
В факторио сложнее выразить функцию x(t), ибо надо учитывать повороты конвейеров, кол-во предметов на линии.
В сворм сим действительно хуйня, экспоненциальную или линейную формулу размножения бахнул, и считай сколько хочешь. Факторио все же более динамичная, ибо объекты могут рандомно на конвейере появляться/уходить.
Аноним 24/02/20 Пнд 17:11:26 #5 №644742 
>>644712 (OP)
>Несколько миллионов объектов
Ты считал? Тысяча объектов хотя бы наберется?
Обычным циклом обновления можно обновлять десятки, если не сотни тысяч объектов безо всякой оптимизации. Ты недооцениваешь современные процессоры.
Аноним 24/02/20 Пнд 17:16:50 #6 №644743 
>>644742
Да считал, у меня на одиночной карте 1100000+ объектов было. Сейчас появилась возможность играть в онлайн на супер огромных картах для двухсот человек. И это все дело не тормозит.
Аноним 24/02/20 Пнд 17:38:40 #7 №644747 
>>644743
ты думаешь вся твоя карта обновляется каждый кадр?
Аноним 24/02/20 Пнд 18:59:32 #8 №644772 
>>644715
Сложнее, не значит невозможно, конечно там не все на 100% можно выразить через x(t), но многое все же можно.
В каких то девблогах, они писали о чем-таком, мол поезда, когда их не было видно ездили неправильно, телепортировались через пробки на развязках или типа того.
И на ковеере каждый итем не просчитывается каждый тик, а считается сколько итемов на белт попало, с какой скоростью они движутся, в зависимости от заполненности белта.
Короче секрет в том, что не симулировать, то что можно рассчитать.
Аноним 24/02/20 Пнд 19:20:45 #9 №644780 
>>644743
Важно не сколько объектов на карте, а сколько событий происходит за один кадр. Если посчитать, то даже для таких игр как factorio будет совсем незначительные числа.
Аноним 24/02/20 Пнд 19:32:28 #10 №644787 
>>644712 (OP)
Ты бы попробовал технодемку сделать, имитирующую факторио, и рассказал бы нам, где какие проблемы возникли. А так это пустой разговор.
Аноним 24/02/20 Пнд 22:36:02 #11 №644820 
>>644712 (OP)
Свой движок на плюсах, где каждому байтику уделяется внимание, на каком-нибудь каловом юнити такое не запилишь.
Аноним 25/02/20 Втр 02:09:31 #12 №644859 
>>644712 (OP)
https://www.factorio.com/blog/
Аноним 25/02/20 Втр 08:47:19 #13 №644877 
>>644712 (OP)
Не интересовался. Скорее всего просто посчитали, сколько всего влезает в кеш линию процессора, сколько всего влезает в батчинг на видеокарте. Какие нибудь трюки, с расчетами через кадр, каждый четный кадр просто ехать по прямой.
Аноним 25/02/20 Втр 09:07:16 #14 №644879 
>>644712 (OP)
Умножение работает быстрее, чем деление. Поэтому в сложных расчётах по возможности заменяй деление (10/2) на умножение (10*0,5)
Аноним 25/02/20 Втр 09:09:23 #15 №644880 
>>644879
Как там в 2002?
Аноним 25/02/20 Втр 09:11:05 #16 №644881 
>>644880
Точно так же. Умножение всё ещё работает быстрее, чем деление. Хочешь возразить?
Аноним 25/02/20 Втр 09:16:20 #17 №644882 
>>644881
Умножение на флоат быстрее сдвига на 1 бит?
Аноним 25/02/20 Втр 09:28:46 #18 №644884 
>>644882
Так и знал, что найдётся байтоёб и доебётся к делению на два. А если нам не на кратное степени двойки поделить надо?
Аноним 25/02/20 Втр 09:40:23 #19 №644885 
>>644880
В 2016-ом: https://qna.habr.com/q/295947
Аноним 25/02/20 Втр 10:21:28 #20 №644891 
>>644879
Разве это не оптимизируется при компиляции уже 15 лет как?
Аноним 25/02/20 Втр 10:44:20 #21 №644899 
>>644820
>на каком-нибудь каловом юнити такое не запилишь
Анус ставишь? Я в этот симулятор экселя не играл, конечно же, но судя по видео, там просто трансформация одного типа ресурса в другой. Что-то типа продюсер-консумера. Там самое сложное - это сделать конвеер.
С чего такие ньюфаги как ты решили, что это что-то сложное - я не понимаю.
Аноним 25/02/20 Втр 10:50:19 #22 №644901 
>>644899
Потому что ты не пытался этого сделать и от того у тебя типичный эффект Даннинга-Крюгера, выразающийся простой и известной фразой: "Да что там эта ваша виндовс? Мы такую же с приятелем на коленке за пару ночей напишем! Даже лучше."
Аноним 25/02/20 Втр 10:55:00 #23 №644902 
>>644899
Конечно можно. Просто натаскиваешь ассеты мышкой и все.
Аноним 25/02/20 Втр 11:40:28 #24 №644921 
image.png
>>644899
Все уже сделано до нас.Конвейеры из Factorio в Unity3D [Experiment] [High Performance] - 3 000 000 блоков при 60fps https://www.youtube.com/watch?v=L_uwDygZe48
Аноним 25/02/20 Втр 11:50:03 #25 №644924 
>>644921
Эмеральд крут. Нашёл его канал самостоятельно. Когда спрашивал о годных туториалах в юнититреде - ни одна сука не посоветовала.
Аноним 25/02/20 Втр 16:38:03 #26 №644995 
>>644712 (OP)
Секрет в том, что факторио сделано не на сирешётке.
Аноним 25/02/20 Втр 18:01:33 #27 №645011 
muldiv.png
>>644881
Ну я хочу возразить, например.
Аноним 25/02/20 Втр 18:49:49 #28 №645026 
>>645011
>>644881
Хотя, сейчас проверил без использования fpu — там действительно проц делит медленнее.
Но поскольку проц без фпу работает только с целыми числами, то твое замечание
>по возможности заменяй деление (10/2) на умножение (10*0,5)
все равно является ошибочным.
Аноним 25/02/20 Втр 19:50:53 #29 №645037 
>>645026
заменяю только когда подразумеваю взятие процента от чего-либо

мимо
Аноним 25/02/20 Втр 20:35:50 #30 №645051 
>>645037
Вместо деления на 100 умножаешь на 0.01? Так это еще хуже получается.
Аноним 25/02/20 Втр 20:50:48 #31 №645055 
>>645051
главное что код читается проще, чем непонятное деление на магическую хуиту.. зачастую узкие места не в единичных делениях и умножениях, че вы так приебались к этому
Аноним 25/02/20 Втр 21:13:46 #32 №645059 
>>645055
Да никто не приебался, просто ищем истину в споре.
В общем, положняк такой: заменять деление умножением имеет смысл только в тех случаях, если множители это целые 64-битные (или 32, в зависимости от битности вашей программы) числа, и если заведомо не будет при этом переполнения. В остальных случаях выигрыша не будет, потому что при умножении вещественных чисел будет задействован фпу, который в разы медленнее цпу. Такие дела.
Таким образом, получаем абсолютную бессмысленность замены деления на умножение, за исключением особых случаев, когда используется битовый сдвиг или магическое число.
Поправьте, если ошибаюсь.
Аноним 25/02/20 Втр 22:16:24 #33 №645065 
>>645059
Если там целочислннная константа, то компилятор сам заменит деление на умножение на (1/x). Т.е. при делении на 5 там будет что то вроде умножения на 0xccccccccd и сдвиг на пару битов.
>>645055
> че вы так приебались к этому
Потому что это было оформлено в отдельный пост как ультимативный совет, который по факту был бы актуален лет 20 назад.
Аноним 25/02/20 Втр 22:28:45 #34 №645070 
>>645065
>Если там целочислннная константа, то компилятор сам заменит деление на умножение на (1/x). Т.е. при делении на 5 там будет что то вроде умножения на 0xccccccccd и сдвиг на пару битов.
Все верно братишка, я это и имел в виду под магическими числами.
Аноним 25/02/20 Втр 22:49:06 #35 №645072 
>>645070
Вот такая штука нагуглилась, считать константы в реалтайме, обещают прирост от 5х раз
https://github.com/ridiculousfish/libdivide/blob/master/README.md
Аноним 26/02/20 Срд 08:52:34 #36 №645119 
>>645065
> было оформлено в отдельный пост как ультимативный совет, который по факту был бы актуален лет 20 назад
По факту ты хуя пососал. Потому что по факту это работает у нативных господ, а у фреймворкохолопов действительно разницы нет, что умножение, что деление одинаково в 10 раз медленнее: >>644995
Аноним 26/02/20 Срд 23:16:34 #37 №645270 
Уважаемые анончики. А что находится в ядре у этой штуки ? с точки зрения программирования. Если про рендер боле менее понятно, что можно применить всякие трюки (которые были в одном видео выше) То вот как они спроектировали саму архитектуру игры? Типо там наверно есть класс Game с методами run stop или что то такое, где про это можно прочитать? Или там в основе всего многопоточный Event обюработчик?
Аноним 26/02/20 Срд 23:31:58 #38 №645272 
>>645270
https://www.amazon.com/Engine-Architecture-Third-Jason-Gregory/dp/1138035459
Аноним 27/02/20 Чтв 12:33:48 #39 №645327 
>>645270
https://github.com/id-Software/DOOM-3-BFG
Аноним 27/02/20 Чтв 13:13:33 #40 №645331 
>>645270
https://github.com/skypjack/entt
Аноним 29/02/20 Суб 17:31:00 #41 №645646 
>>645272
>>645327
>>645331
Спасибо за ответы. До сих пор не могу понять, как соединить ECS с рендером. Хотел запилить небольшую игру и взять entt + sdl, но как их вместе подружить и как организовать - картинки в голове нет.
Аноним 29/02/20 Суб 17:49:38 #42 №645650 
>>644712 (OP)
батчинг
/thread
Аноним 05/03/20 Чтв 19:19:14 #43 №646818 
>>644712 (OP)
хз, но может:
1. все значения в стеке памяти, а не куче
2. многопоточность
3. батчинг калькуляций
Аноним 05/03/20 Чтв 19:20:10 #44 №646819 
>>645646
на ютюбе есть канал codemonkey, там екс подробно разбирается.
Аноним 06/03/20 Птн 08:50:11 #45 №646908 
Прямые руки. Вот и все - это весь секрет. Потому что игру делал программист, а не обезьяна, тыкающая на кнопочки в визуальном редакторе, и делающая 2д-игру на движке на фреймворке на фреймворке на фреймворке... Нет, серьезно, иной раз запускаешь примитивную 2д-парашу, а она тормозит как Крайзис. Если конкретнее, то я считаю, что здесь все так быстро, потому что каждый кадр выполняется за O(~1), а не за O(n^n), потому что нет поиска по массивам объектов. Каждый объект содержит прямую ссылку на тот объект, с которым взаимодействует, тот - на третий и и тд, пока не будет достигнута определенная глубина, критерий или взаимодействие не закольцуется.
Аноним 06/03/20 Птн 11:40:47 #46 №646927 
я просто напомню что в таких играх не нужно делать расчеты каждый кадр (один кадр занимает 16мс - что там игрок увидит?).

достаточно делать расчеты каждую секунду - то есть каждые 60 кадров, размазываем эти расчеты на эти 60 фпс.

А если эти расчеты делать еще и на разных ядрах процессора (например разбиваем игровое пространство на регулярную сетку - обрабатываем набор ячеек на своем процессе)
Аноним 06/03/20 Птн 11:44:32 #47 №646930 
>>646927
Ты в факторио играл вообще?
Там миллионы деталей идут по конвееру в реальном времени, если это будет раз в секунду апдейтиться, никто в это играть не будет.
Аноним 06/03/20 Птн 16:32:23 #48 №646977 
>>646930
проигрывание анимации на экране не равно выполнению логики. На экране ты видишь только анимацию спрайта - это дешевая операция даже если у тебя вдруг будет миллион видимых анимированных спрайтов (ну конечно если игру делаешь не на годоте который не знает о батчинге)

Остальное - это логика. Если у тебя руда перерабатывается 15 секунд - нахрена общитывать ее логику обработки чаще 1секунды? игрок не заметит мелких погрешностей во времени

(а если включить мозг, можно еще и сделать обработку с разными приоритетами по времени - например руда обрабатывается 15 секунд. Делаем три очереди. от 1 до 10 секунд первая очередь. от 10 до 13 перекидываем эту руду на вторую очередь. от 13 до 15 - перекидываем на третью очередь.

Первую очередь мы спокойно можем обрабатывать раз в 5 секунд (даже раз в 10 секунд). Это сразу откинет 60-80% работы
Вторую очередь мы уже обрабатываем более аккуратно - раз в секунду или даже 2 раза в секунду
Третья очередь - это все то что сейчас завершится и очень важно точное время - их мы уже обрабатываем каждый кард, и обычно это будет 10-100 операций
Аноним 06/03/20 Птн 16:38:17 #49 №646978 
>>646930
теперь про движующийся конвеер. на экране ты видишь только анимацию. не более.

В логике кода все что нужно знать - это время, за которое деталь должна пройти от точки А (начало конвеера) до точки Б (конец конвеера) и длину всего конвеера.

Зная время и длину можно определить дельту движения. Дельту не надо считать каждый кадр (конвеер же не ускоряется.... хотя даже если бы ускорялся, то это тоже решаемо)

И просто сдвигать спрайт руды на конвеере каждый кадр

Аноним 06/03/20 Птн 17:04:47 #50 №646982 
>>646977
>>646978
Шизик, ты явно не написал ни одной игры и не понимаешь, что несешь, перестань маня-фантазировать.
Аноним 06/03/20 Птн 18:55:23 #51 №647003 
>>646977
>>646978
В факторио всё должно быть ещё проще. Ведь всё, кроме игроков (и, может быть, мобов) детерменированно. Вот взять и поделить весь мир на чанки разных или одинаковых размеров, вывести для них формулы с коэффициентами и готово. Когда игрок захочет изменить что-то, то изменятся формулы во всех зависимых чанках.
Аноним 06/03/20 Птн 20:02:44 #52 №647017 
>>644921
Ахаха, сейчас бы справнивать тупое 2д под копирку со сложными маршрутами в изометрии, с разными поворотами путей.
Аноним 06/03/20 Птн 20:11:06 #53 №647019 
>>646977
Двачую, не знаю почему тот шизик решил что если много объектов то и рассчеты должны вестись чаще, если там завод выдает объект в дискретные моменты времени, и находится все на грубо говоря тайлах. То там все четко детерменировано, там же неоткуда взяться микроподергиваниям, это же не рассчет физики теннисного мяча.
Аноним 07/03/20 Суб 17:08:20 #54 №647172 
>>646982
я то как раз написал и знаю такое умное слово "интерполяция".

Ну а тебе удачи обсчитывать миллион ненужных вещей
Аноним 07/03/20 Суб 18:38:18 #55 №647201 
>>647172
Что ты там интерполировать собрался, долбоёбушка?
Еще раз. Есть конвеер, по нему идет миллион деталей в реальном времени. Сбоку конвеера стоит тысяча механических рук, которые работают по своему алгоритму, выхватывают рандомные детали в зоне досягаемости с конвеера, перемещают их на другие конвееры, нарушая состояние основного конвеера. То, как они работают - зависит от состояний конвееров, куда они переносят детали - они могут остановиться, если конвееры заполнены, продолжают работать, если место освободилось.
Как ты это интерполировать собрался? Тебе в любом случае придется обсчитывать эти руки и детали в реальном времени каждый фрейм, если хочешь чтобы все работало плавно как в оригинале.
Я понимаю, что с дивана просто кукарекать, но ты бы постыдился хоть немного пороть хуйню.
Аноним 07/03/20 Суб 18:43:47 #56 №647202 
>>647201
Проиграл с безыгорного кукаретика, не сделавшего ничего в своей жизни. Понятно, что с дивана просто рассуждать и мечтать о том, какой ты охуенный разработчик с гениальными идеями.
А ты попробуй что-нибудь сделать на практике, хотя бы не игру, а играбельный прототип из одного уровня, сразу жиденько сходишь под себя и пойдешь обратно на диван мечтать.
Аноним 07/03/20 Суб 19:33:36 #57 №647215 
>>647201
Чел, ты троллишь тупостью. Если ты не понимаешь как, это не значит что они там "рандомные".
Аноним 07/03/20 Суб 22:27:11 #58 №647246 
>>647202
>>647215
Вы хоть знаете сколько операций процессор может выполнить за 1 кадр?
Аноним 07/03/20 Суб 22:52:32 #59 №647251 
>>647246
Что-то типа 100 миллионов.
Аноним 07/03/20 Суб 22:59:38 #60 №647252 
>>647251
Схуяли?
Аноним 07/03/20 Суб 23:09:42 #61 №647259 
>>647252
Посчитал, блеать.
Старые i7 100'000 Million instr. per second
Поделим на среднюю длину инструкции в тактах (примем 10)
Поделим на 100 (фпс)
Вот и 100 миллионов.
Умножим на 4 ядра
400 миллионов
на асме переместить 2 координаты, скажем 20 инструкций
20 миллионов объектов можно двигать не запариваясь особо на старом компе
Аноним 07/03/20 Суб 23:37:10 #62 №647262 
>>647259
МИПСы дохуя пиковые показатели. Для среднего кода можно порядок или два убирать. Плюс скорее всего в нем уже заложена многопоточность. Так что даже при таких подсчетах стоит скорее на 1 лям объектов рассчитывать.
Аноним 07/03/20 Суб 23:56:49 #63 №647264 
>>647259
Проиграл с долбоёба.
Аноним 08/03/20 Вск 00:32:38 #64 №647275 
>>647264
С себя что ли?
Аноним 08/03/20 Вск 05:50:03 #65 №647295 
>>647259
>на асме переместить 2 координаты, скажем 20 инструкций
но зачем перемещать на асме (да и вообще на процессоре) если эту задачу можно перенести на видеокарту? :-/

(на самом деле на видеокарте через вычислительный шейдер идеально обрабатывать конвееры - так как это заложено в архитектуру самой видеокарты и она лучше работает с этим чем линейный процессор)
Аноним 08/03/20 Вск 12:25:59 #66 №647347 
>>647295
Не знаю, анон, почему то кажется сомнительным что вся логика может работать в гпу.
20 инструкций я и имел в виду некое планирование координат.
comments powered by Disqus

Отзывы и предложения