Подойдёт ли мать к видюхе(rx 580)?
Хочу вставить сюда rx 580, но боюсь по PCI не подойдёт.
Хочу вставить сюда rx 580, но боюсь по PCI не подойдёт.
Исходный пост: хочу обновить комп для игр
Мой комп сейчас:
Процессор Intel(R) Core(TM) i5-9400F CPU 2.90GHz (6 ядер, 6 потоков)
Оперативная память 16,0 ГБ DIMM
Видеокарта: Radeon RX 580 Series 8гб
Диск 1: SSD m2 1 гб
Диск 2: Hard disk 1 тб
Монитор: AOC AG251FWG2 [25" LCD]
Системная плата Gigabyte H310 D
Друг посоветовал мне такую сборку, прошу оценить:
Процессор AMD Ryzen 5 7600 OEM
Видеокарта: MSI GeForce RTX 4070 VENTUS 3X E OC
Системная плата ASRock B650M Pro RS
Оперативная память ADATA XPG Lancer Blade 32 gb
Кулер процессора DEEPCOOL AK620 DIGITAL
Блок питания DEEPCOOL PQ1000M
Думаю обновить пк для игр. Играю онлайн в соревновательные игры, поэтому фпс важен, но не обязательно на высоких настройках графики.
Сам я вообще не в теме и очень тяжело разбираться в комплектующих пк. Огромное количество процессоров и видеокарт на рынке, так их еще надо соединить между собой чтобы работало. И охлаждение.
Проблема: процессор не менял с первой сборки, т.е. ему уже около 10 лет. Менял видеокарту и материнку в 2018г.
Бюджет около +- 100 - 150к. Корпус для пк большой.
Текущие комплектующие:
Процессор Intel(R) Core(TM) i5-9400F CPU 2.90GHz
Оперативная память 16,0 ГБ
Видекокарта: Radeon RX 580 Series 8гб
Диск 1: SSD 1 гб
Диск 2: Hard disk 1 тб
Монитор: AOC AG251FWG2 [25" LCD]
7. Хз какой у меня блок питания и не знаю нужно ли его менять.
8. UPD: Системная плата Gigabyte H310 D3
Как-то на днях наткнулся здесь на "Пикабу" на пост, в котором пользователь просит помощи с выбором игрового ноутбука и предоставляет в посте скриншоты и ссылки на ноутбуки, некоторые из которых даже игровыми и не являются, а другие можно назвать игровыми с боооольшой натяжкой. Например, в упомянутом посте указаны модели, даже не имеющие дискретной видеокарты, то есть работающие только на графическом ядре, встроенном в процессор (Huawei MateBook D14, Acer Aspire 3, HP 15s-eq1279ur), ну поиграть-то на них можно, конечно, в CS 1.6, например, или же Hitman: Blood Money, но ведь говоря "Игровой ноутбук", мы же подразумеваем не это, а то, что это аппарат, на котором можно запустить любую на данный момент имеющуюся игрушку, пусть уж и не на ультра-настройках графики, с учётом ограничений ноутбучного железа, ну на средне-высоких настройках, что бы было комфортно поиграться в тот же Cyberpunk 2077.
Вот исходя из вышеупомянутого поста решил запилить эту статью, что бы помочь начинающим пользователям в выборе игрового ноутбука.
Сначала давайте разберёмся чем собственно ноутбук отличается от полноценного ПК. Понятно, что различий очень много, но основное, что в данном случае мы должны иметь ввиду - это то, что процессор и видеокарта ноутбука распаяны на материнской плате. То есть в отличии от ПК, нельзя просто взять и заменить процессор или видеокарту в ноутбуке. То есть, исходя из этого, нам сразу необходимо подбирать ноутбук с хорошим полноценным процессором и именно игровой видеокартой, так как в будущем мы не сможем их заменить или же проапгрейдить эти компоненты на что-то более производительное. Добавить оперативной памяти, заменить накопитель - это в большинстве случаев возможно.
Для наглядности нашёл в инете фото материнской платы ноутбука и в Paint обозначил компоненты, о которых идёт речь: 1. Процессор 2. Видеочип (GTX 1650, RTX 2070 Super, RTX 3050 и т.д.) 3. Видеопамять (это на сколько Гб. собственно видеокарта - 4, 6, 8 Gb.)
Итак, мы разобрались, для выбора игрового ноутбука нам нужен ноутбук с мощным процессором и видеокартой, которые потянут все имеющиеся игрушки.
А какие же процессоры и видеокарты можно называть игровыми?
Давайте разбираться.
Первым делом давайте разберёмся какой же процессор нам необходим для запуска требовательных игр. И какой же процессор можно назвать "игровым".
Сразу хочу отметить, что с выходом 14-го поколения процессоров, семейства Meteor Lake, Intel заявила, что перейдёт на новую маркировку процессоров. Откажется от приставки "i", а так же к производительным процессорам добавит приставку "Ultra", то есть вместо привычных сейчас "Intel Core i7-10750H" мы будем примерно наблюдать: "Intel Core Ultra 7 10750", и за счёт приставки "Ultra" будем понимать, что это высокопроизводительный процессор. Или же вместо "Intel Core i7-10510U", будет: "Intel Core 7 10510", видя, что приставка "Ultra" отсутствует, мы понимаем, что это энергоэффективный процессор. Останутся ли суффиксы "H", "U", "G", пока не понятно, нигде точных и достоверных разъяснений по поводу предстоящей маркировки пока что нет. Для каких маркетинговых целей Intel задумала ренейминг линейки процессоров, честно не очень понятно, так как привычная нумерация процессоров использовалась компанией с 2008-го года, с момента появления первых процессоров Intel Core.
Однако, давайте будем реалистами - ноутбуки на свежих только, что вышедших процессорах будут стоить, как крыло от "Боинга", да и процессоры предыдущих поколений вполне мощные и могут выполнять все необходимые на сегодняшний день задачи. Поэтому, давайте разберёмся, как сейчас маркируются процессоры от Intel, как минимум несколько лет эта информация будет полезной, процессоры 11-го, 12-го и 13-го поколений ещё очень не скоро потеряют свою актуальность.
Говорить будем о семействе процессоров "Intel Core", так как Athlon'ы и Pentium'ы не попадают никак под Ваши с нами требования игрового процессора.
Давайте для примера возьмём процессор i7-10750H. i7 - это серия процессора, здесь более-менее всё понятно. Далее идут 4 или 5 цифр и буква, вот здесь стоит остановится поподробнее, если цифр после тире 4, значит это процессор до 9-го поколения включительно, и первая цифра указывает, как раз на его поколение. Например, для i7-8750H, будет понятно, что это Core i7 8-го поколения. Если в маркировке цифр 5, то это значит, что процессор от 10-го поколения и выше, первые две цифры так же указывают на поколение процессора, так на примере нашего i7-10750H, мы можем сказать, что это Core i7 10-го поколения.
Последние три цифры во всех случаях - это SKU-номер (Stock Keeping Unit – Складская Учётная Единица или, другими словами, код товара), как правило чем больше это значение, тем производительней процессор, но это справедливо только в рамках одной серии и одного поколения процессоров. Например i7-10870H будет производительнее i7-10750H, оба процессора серии i7, оба 10-го поколения, но 10870, производительнее чем 10750.
С цифрами на процессорах Intel немного разобрались, но так и не понятно, а какой же процессор нужен нам... Поэтому давайте перейдём к обозначениям буквенных индексов.
Буквенный индекс указывает на версию процессора, а именно - является ли он высокопроизводительным или же энергоэффективным.
Не буду упоминать здесь уже вышедшие из обихода индексы QE, XM, MX, ME, M, HQ, HK, MQ, QM и прочие. На данный момент основных индексов в мобильных процессорах от Intel всего три: G, U, H. Вот с ними и разберёмся.
U — процессоры со сверхнизким энергопотреблением для ультрабуков (ultra low voltage)
G — процессор с дискретной графикой Intel Iris
Н — обозначение высокопроизводительного полноценного процессора
То есть простым языком процессоры с индексами "G" и "U" предназначены для офисных ноутбуков для решения несложных задач. А вот как раз процессоры с индексом "H" - это для игровых ноутбуков.
Так же многие, наверное знают утверждение, что Core i7, производительнее Core i5. Это от части справедливо, НО только в рамках одного поколения процессоров и то даже в одном поколении есть исключения, когда Core i5 производительнее, чем Core i7. Например уже упомянутый i7-10750H будет мощнее i5-10300H, так как оба процессора 10-го поколения. Но этот же i7-10750H будет значительно уступать i5-11400H, так как i7 10-го поколения, а i5 уже 11-го поколения.
Но возьмём опять же упомянутый i5-11400H и i7-11370H, кажется оба 11-го поколения, но в данном случае Core i5 будет производительнее, чем i7 примерно на 30%
Почему так? Кажется стало ещё больше непонятнее... Всё просто: именно здесь необходимо смотреть на SKU-номер. В одном поколении процессоров Intel, есть несколько разных по производительности категорий, разделённых именно по SKU-номену и в данном случае процессору i7-11370H соответствует процессор i5-11300H, в таком случае i7 будет производительнее, чем i5, так как оба процессора 11-го поколения, оба из одной категории, согласно SKU-номера.
Итак, давайте подведём промежуточный итог: мы разобрались, что процессоры от Intel с маркировкой "U" и "G" так сказать урезанные по ядрам, частотам и т.д., в зависимости от конкретной модели самого процессора, а для игрового ноутбука нам необходим полноценный процессор, то есть при выборе игрового ноутбука на камне от Intel, он обязательно должен быть с индексом "H", так же стоит смотреть на поколение процессора, чем свежее процессор, тем он производительнее, кроме того в одной серии процессоров, например, i7 и в одном поколении, например 10-ом могут быть несколько версий, они различаются SKU-номером и чем выше эта цифра, тем производительнее процессор. Кроме того понятно, что мобильный процессор начального уровня Core i3 никак не подойдёт для запуска всех возможных игр, то есть его рассматривать не стоит. Таким образом, если выбираем процессор от Intel, смотрим Core i5, i7, i9 с индексом "H" и желательно последних поколений.
Давайте теперь обратим внимание на процессоры от AMD, а именно на их серию Ryzen, так как вполне обоснованно полагаю, что они на данный момент ничем не хуже процессоров от Intel. Да, конечно же, как и всегда присутствуют два лагеря: одни за синих, другие за красных, но в общем и в целом на данный момент эти процессоры всё же заслуживают внимания.
Давайте сразу оговорюсь, что с этого 2023-го года AMD так же сменили нейминг своих процессоров, но там гораздо проще, чем у интела. Начиная с 2023-го процессоры маркируются следующим образом:
Первая цифра — поколение процессора и год выпуска (семёрка для 2023-го, восьмёрка для 2024-го, девятка для 2025-го и так далее)
Вторая — положение чипа в иерархии бренда: от единицы для Athlon Silver до девятки для топовых Ryzen 9
Третье — указание поколения архитектуры Zen
Четвёртая — ревизия архитектуры. Быстрые чипы получают цифру 5, а более медленные — 0
Суффикс по-прежнему будет указывать на значение TDP: 55 Вт — HX, 35 Вт — HS, 15-28 Вт — U, C для хромбуков, так же 15-28 Вт, а 9 Вт — строчная буква «e». Таким образом, маркировка Ryzen 5 7640U укажет на чип среднего класса производства 2023 года, построенный на архитектуре Zen 4 и предназначенный для устройств с низким энергопотреблением.
Исходя из этого к примеру мы можем понять, что AMD Ryzen 7 7735H - это процессор седьмого поколения 2023-го года (первая семёрка на это указывает), серия Ryzen 7 (вторая семёрка в числовом коде), на архитектуре Zen 3 (собственно третья цифра) и это высокоэффективный чип (на что указывает четвёртая цифра). Или же к примеру 7945HX - процессор 2023-го года, Ryzen 9, на архитектуре Zen 4, высокоэффективный, так же индекс "HX" указывает на TDP в 55 ватт.
Вроде бы всё понятно, но возникает логичный вопрос - а что это такое TDP и для чего оно нужно?
Давайте к вопросу о TDP процессора вернёмся чуть позже, а пока закончим разбираться с маркировкой процессоров Ryzen. Мы поняли как маркируются процессоры начиная с 2023-го года, но ведь и предыдущие поколения "Райзенов" довольно не плохие и ещё вполне способны вытягивать весьма требовательные игрушки.
У AMD в этом плане всё немного проще, чем у Intel, хотя в нейминге процессоров они используют их логику, что бы не путать пользователей. Поэтому зная как маркируются процессоры от Intel, давайте быстро пробежим по маркировке Ryzen'ов.
Ryzen 3 — начальный уровень,
Ryzen 5 — средний уровень,
Ryzen 7 — предтоповый уровень,
Ryzen 9 — топовый уровень.
Первая цифра в маркировке процессоров Ryzen всегда указывает на поколение, однако же сама цифра не всегда соответствует поколеню, так например Ryzen 5 4600H - это процессор третьего поколения. Ниже приведу список поколений мобильных процессоров от AMD, думаю не сложно будет разобраться.
1-е поколение Ryzen — архитектура Zen (Ryzen 3 2200U, Ryzen 5 2600H и т.д.)
2-е поколение Ryzen — архитектура Zen + (Athlon 300U, Ryzen 5 3500U, Ryzen 7 3750H и т.д.)
3-е поколение Ryzen — архитектура Zen 2 (Ryzen 3 4300U, Ryzen 5 4600H, Ryzen 7 4800HS и т.д.)
4-е поколение Ryzen — процессоры со встроенной графикой только для ОЕМ производителей (Ryzen 3 4300GE, Ryzen 5 Pro 4650GE, Ryzen 7 Pro 4750G и т.д.)
5-е поколение Ryzen — архитектура Zen 3 (Ryzen 3 5300U, Ryzen 5 5600HS, Ryzen 7 PRO 5850U и т.д.)
6-е поколение Ryzen — архитектура Zen 3+ (Ryzen 5 6600U, Ryzen 7 6800HS, Ryzen 9 6980HX и т.д.)
7-е поколение Ryzen — архитектура Zen 4 (Ryzen 5 7640HS, Ryzen 7 7735H, Ryzen 9 7945HX)
Номер процессора
В англоязычных странах этот пункт называется SKU (Stock Keeping Unit), что можно перевести на русский как артикул. Этот номер показывает положение конкретного процессора в рамках одного семейства. Чем больше число, тем лучше процессор. Встречается и еще более детальное наименование, причем разница может быть существенной. Например, у Ryzen 9 3900X 12 ядер, а у 3950X уже 16.
Обратите внимание, что цифры не повторяются в разных семействах: 3600 — это всегда Ryzen 5, а 3700 — Ryzen 7. Не бывает Ryzen 5 3700 или Ryzen 7 3600.
Буквенный суффикс
H — производительная серия для ноутбуков;
HX — еще более производительная серия процессоров для ноутбуков;
HS — особая серия процессоров AMD, производительность которой равна серии H, но теплопакет снижен;
U — энергоэффективная серия для ноутбуков со сниженным теплопакетом.
Таким образом, уже разобравшись с процессорами от Intel, здесь нам тоже уже не сложно сделать выводы о том, какие процессоры нам подойдут, а именно: Ryzen 3 сразу же отбрасываем и не рассматриваем, как начальный процессор линейки, а соответственно и самый низкопроизводительный. Так же мы понимаем, что процессоры нам нужны опять же с индексом "H", либо "HX", в крайнем случае можно рассмотреть "HS", процессоры с индексом "U" не рассматриваем, как урезанные по частотам и ядрам. По поводу поколения, на данный момент с первого по третье поколение процессоры Ryzen уже устарели, поэтому рассматриваем ноутбуки с процессорами 5, 6 и 7 поколений.
В принципе с процессорами более-менее понятно, давайте теперь вернёмся к вопросу "а что такое TDP?"
Абревиатура TDP (Thermal Design Power) обозначает конструктивные требования по теплоотводу или просто требования по теплоотводу для системы охлаждения. Если проще, TDP служит ориентиром для выбора системы охлаждения и отображает количество тепла, выделяемое устройством во время среднестатистической нагрузки. Значение TDP выражается в ваттах, и вот тут зачастую возникает путаница между TDP и энергопотреблением.
TDP — это значение, которое используют в очень широком смысле Intel и AMD для обозначения информации о тепловыделении своих продуктов. По большому счету, TDP — это просто рекомендация по выбору системы охлаждения, чтобы процессор нормально функционировал. Однако для ПК если мы можем самостоятельно выбрать систему охлаждения, то для ноутбука к сожалению нет.
В современных тонких производительных ноутбуках радиаторы способны рассеивать 150-200 Вт тепла, в редких случаях до 250 Вт. Таким образом, если использовать видеокарту с TGP 150 Вт, а радиатор способен рассеять лишь 200 Вт, то процессору останется всего 50 Вт. Это серьезное ограничение мощности, так как в разгоне потребление топовых чипов может доходить до 150 Вт.
Поэтому стоит обратить внимание так же и на качество охлаждения ноутбука, если мы выбираем именно игровой аппарат, то к сожалению он не может быть тонким, такие модели, как например, Asus TUF Dash F15, Asus ROG Zephyrus M15, кажется и тонкие и с топовыми процессорами и видеокартами, однако стоит учитывать, что это ноутбуки изначально созданы инженерами не для гейминга, а для дизайнеров, проектировщиков и т. д., тех специалистов, которые работают с ресурсоёмкими приложениями и программами и в то же время не требуют такой нагрузки одновременно на процессор и видеокарту, как геймеры. Поэтому качественное охлаждение ноутбука такиже необходимо учитывать при выборе, что бы в дальнейшем избежать просадок и фризов в играх.
Ну и теперь главный вопрос: графику в играх отрисовывает видеокарта, поэтому в ноутбуке она необходима. А вот какая именно, давайте разберёмся.
Не совсем верно утверждение, что чем больше видеопамяти, тем видеокарта производительнее. Например возьмём мобильную видеокарту AMD Radeon RX6600M на 8 Гб. видеопамяти и Nvidia RTX 3060 на 6 Гб. видеопамяти, по производительности они практически одинаковы, разница будет составлять порядка 10% то в пользу одной, то в пользу другой видеокарты, в зависимости от конкретной задачи.
Дело всё в том, что помимо объёма видеопамяти, так же необходимо учитывать и пропускную способность этой самой памяти и ширину шины памяти. У RX6600M пропускная способность составляет 256 Гб/с., не мало как бы, а ширина шины памяти 128 бит, но в то же время у RTX 3060 пропускная способность памяти составляет 336 Гб/с., а ширина шины памяти уже 192 бита.
Что же это значит? Если простыми словами: за одно и то же время, RTX 3060 за счёт большей скорости и ширины шины памяти сможет обработать гораздо больший суммарный объём данных, чем за это же время сможет обработать RX6600M. Пока RX6600M будет обрабатывать поступившие в видеопамять 8 Гб. информации, RTX 3060 уже обработает свои 6 Гб. поступившей информации и частично уже обработает вторую порцию информации на 6 Гб.
Но стоит оговориться - с видеокартами от Nvida не всё так просто. Давайте не будем подробно рассматривать в данном посте мобильные видеокарты от AMD, так как они занимают не очень значительную долю рынка и спросом особо не пользуются. А на видеокартах от Nvida остановимся чуть более подробно.
Естественно, мы понимаем, что для игрового ноутбука нам нужна мощная видеокарта, но как вот разобраться в том производительная видеокарта или нет? Что бы разобраться в актуальных мобильных видеокартах, необходимо немного вспомнить с чего всё началось и в таком случае в хронологическом порядке, дойдя до актуальных видеокарт, уже придёт понимание как правильно сделать выбор.
С момента своего появления мобильная графика отставала от аналогичных по названию десктопных версий. В начале нулевых техпроцесс всё ещё измерялся в десятках и сотнях нанометров, и несмотря на то, что топовая десктопная графика того времени не требовала двух- или трёх-слотовых систем охлаждения, уместить её в ноутбуках не представлялось возможным. Ведь остальные электронные компоненты также были большими и требовали больше места для размещения на материнской плате. К тому же системы охлаждения того времени были не так эффективны, как нынешние.
В итоге Nvidia решила снижать мощность мобильных видеокарт, чтобы сделать возможной их установку в ноутбуки. Чтобы пользователи лучше понимали, какая видеокарта устанавливается в ноутбук, мобильная графика обозначалась иначе, чем десктопная. Когда названия серий состояли из одной цифры, в названии мобильной графики появилось дополнительное слово «Go». Например, видеокарта NVIDIA GeForce 4 MX 460 предназначалась для компьютеров, а NVIDIA GeForce 4 Go 460 – для ноутбуков.
Ранее снижение производительности и тепловыделения графики выражалось в понижении тактовых частот. Для сравнения возьмём всё ту же десктопную NVIDIA GeForce 4 MX460 и мобильную GeForce 4 Go 460. Строение видеоядра у двух видеокарт одинаковое: 2 пиксельных конвейера, 4 текстурных блока (TMU) и два блока растеризации (ROP). Изменились только частоты - десктопная GeForce 4 MX 460 работала с частотой 300 МГц, а мобильная GeForce4 Go 460 оказалась на 50 МГц медленнее.
Когда видеокарты NVIDIA стали наращивать количество унифицированных шейдерных процессоров, одного лишь снижения частот стало недостаточно. Чтобы уложиться в теплопакет, с которым может справиться система охлаждения ноутбуков, Nvidia стала отключать часть шейдерных процессоров в видеоядре.
В 2009 году Nvidia изменила наименования линеек своих видеокарт, перейдя на сотые серии, ситуация повторилась - к мобильным видеокартам добавилась буква «M». Просто взглянув на модель графики, можно сразу понять, что NVIDIA GeForce GTX 760 создана для стационарных компьютеров, а GeForce GTX 760M – для ноутбуков. Частоты у мобильной графики также были ниже, а в GPU была отключена часть шейдерных процессоров, которые со временем преобразовались в CUDA-ядра благодаря унифицированной архитектуре.
Разница в производительности десктопных и мобильных видеокарт сохранялась до 2016 года, пока NVIDIA не представила архитектуру Pascal и видеокарты GeForce GTX 10-й серии. На этом этапе NVIDIA смогла свести к минимуму разницу между десктопными и мобильными GPU. Для обозначения мобильных видеокарт больше не требовались дополнительная буква, индекс или слово.
У NVIDIA GeForce GTX 1080 и GTX 1060, созданных для ноутбуков и компьютеров, стало одинаковое количество ядер CUDA. Даже у мобильной GeForce GTX 1070 оказалось чуть больше CUDA-ядер по сравнению с её десктопным аналогом. Разумеется, частоты у мобильных и десктопных видеокарт немного различались, но разрыв между мобильной и «полноценной» десктопной графикой в рамках одного поколения стал не настолько большим и заметным, как это было ранее. А в зависимости от эффективности системы охлаждения, разницы могло и вовсе не быть.
Появление архитектуры Pascal стало прорывом для тех, кто предпочитал играть на ноутбуках которые, в отличии от компьютера, всегда можно взять с собой. Ноутбуки с видеокартами GeForce GTX 10-й серии легко справлялись с играми того времени.
Игровые ноутбуки с топовой графикой, которая справляется с современными играми — это прекрасно. Однако, у любой медали есть две стороны. Производительная видеокарта непременно будет горячей, для неё потребуется большая система охлаждения, которая во многом определяет толщину и вес ноутбука.
Для примера возьмём Asus ROG G703, высокую производительность которого обеспечивал 4-ядерный процессор Intel Core i7-7820HK в паре с видеокартой NVIDIA GeForce GTX 1080. Топовая конфигурация для своего времени! Однако, при толщине в 51 мм и весе в 4,7 кг ROG G703 совершенно точно нельзя назвать ноутбуком, который можно носить с собой на работу каждый день. Скорее, это полноценная замена десктопа, которую при необходимости можно легко перенести в другое место. Главное, не забыть с собой огромный блок питания.
Пользователям хотелось получить не только мощные, но и тонкие игровые ноутбуки, а производители стремились удовлетворить потребности. Все-таки, ноутбук ассоциируется с компактностью и мобильностью. К тому же, игровые ноутбуки многие используют для работы – мощная начинка одинаково хорошо справляется как с играми, так и с большинством тяжёлых задач, вроде сложных расчётов, обработки фото, видеомонтажа и так далее. Но это требовало создания более энергоэффективных видеокарт, которыми в будущем и стали линейки под названием Nvidia Max-Q.
В аэродинамике точкой Max-Q называют момент максимальной нагрузки на ракету в атмосфере, который особенно учитывается конструкторами. Компания Nvidia применила похожий подход при разработке серии видеокарт Max-Q, которые работают на пределе своей энергоэффективности.
Необходимо пояснить, что не стоит путать понятия «энергоэффективность» и «производительность». В первом случае графика работает с максимальной производительностью относительно потребляемой мощности, и не выходит за пределы заложенного лимита энергопотребления. Во втором случае происходит прирост производительности, за который приходится расплачиваться увеличивающимся тепловыделением и энергопотреблением.
Зависимость между потребляемой мощностью и ростом производительности нелинейная. При увеличении потребляемой мощности прирост производительности сперва будет заметным, линейным, а потом, после прохождения точки максимальной эффективности, прирост производительности (который не стоит путать с самой производительностью) замедляется. Проще говоря, видеокарта Nvidia GeForce GTX 1080 будет быстрее GTX 1080 Max-Q, но при этом потребует улучшенной системы охлаждения и станет потреблять больше энергии.
В результате в 2017 году на рынке появилось два типа ноутбуков: с классической графикой GTX 10-й серии и с графикой Max-Q. Появление линейки Max-Q позволило выпускать тонкие и лёгкие игровые модели, чего не удавалось добиться ранее. Для Max-Q не требуется крупногабаритная система охлаждения.
Благодаря появлению видеокарт Max-Q, производители смогли выпустить тонкие, лёгкие и при этом мощные игровые ноутбуки. Одной из первых таких моделей стал 15-дюймовый Asus ROG Zephyrus GX501. В ноутбуке толщиной 17,9 мм и весом 2,26 кг была установлена графика Nvidia GeForce GTX 1080 в дизайне Max-Q в паре с 4-ядерным процессором Intel Core i7-7700HQ. Для рынка ноутбуков 2017 года это стало революцией.
Долгое время энергопотребление видеокарт обозначалось аббревиатурой TDP. Расшифровать эти три буквы можно как Thermal Design Point или Thermal Design Parameter. Значение TDP обозначало, сколько Ватт тепла нужно отводить от кристалла GPU, и не указывало общее энергопотребление видеокарты.
На данный момент в указании характеристик видеокарт 30-ой и 40-ой серий используется другой параметр - TGP. TGP в отличии от параметра TDP напротив указывает, сколько Ватт потребляет вся видеокарта целиком.
Видеопамять и другие электронные компоненты также потребляют свою часть электричества во время работы. Судя по таблице, реальное энергопотребление видеокарт оказалось заметно выше, чем тепловыделения GPU. Например, у GeForce RTX 2080 разница между TDP и TGP составляет 67 Ватт, а у RTX 2070 - 55 Вт.
За время существования графики Nvidia GeForce RTX 10-й и 20-й серий, мы успели привыкнуть к тому, что видеокарты для ноутбуков и десктопов стали практически одинаковыми. Однако, выход мобильных видеокарт нового поколения на архитектуре Ampere снова поменял правила игры.
Десктопные видеокарты Nvidia GeForce RTX 30-й серии оказались не только производительными, но и требовательными к питанию. Согласно официальному сайту Nvidia, энергопотребление GeForce RTX 3080 составляет 320 Вт, когда как GeForce RTX 2080 Super потребляла 250 Вт. При этом, мы имеем в виду энергопотребление, указанное без заводского разгона и самых пиковых значений.
Разница в энергопотреблении у старого и нового поколения видеокарт оказалась заметной. Впервые видеокарта Nvidia с одним GPU потребляет более 300 Вт. Учитывая высокое энергопотребление и впечатляющую производительность графики, перед инженерами Nvidia появилась сложная задача по оптимизации десктопной графики к мобильным реалиям. В случае с ноутбуками производители были ограничены толщиной корпуса, которая не позволяет установить систему охлаждения толщиной в несколько сантиметров.
В результате, инженерам Nvidia пришлось вынужденно вернуться к старым методикам –отключению CUDA-ядер. Также при разработке ноутбука стало возможным ограничивать TGP видеокарты. Это означает, что на этапах проектирования и производства можно выставить максимальное энергопотребление согласно возможностям системы охлаждения. В результате на рынке появились ноутбуки с одинаковым названием видеокарт, но разной производительностью, что закономерно привело в замешательство многих пользователей.
Вот к примеру таблица с некоторыми ноутбуками от Asus на видеокартах 30-ой серии и как мы можем заметить одна и та же на первый взгляд видеокарта по мощности может значительно отличаться. Например RTX 3060 в ROG Zephyrus G14 установлена мощностью 60 ватт, а в том же ROG Strix Scar 17 эта же 3060 уже обладает мощностью в 115 ватт, то есть TGP практически в два раза выше.
Если ранее в названии видеокарт использовался индекс Max-Q для маркировки видеокарт с урезанным теплопакетом, то сейчас именно TGP становится важным параметром для определения производительности при выборе игрового ноутбука. И в то же время компании производители нигде не указывают информацию об энергопотреблении видеокарты и маркируют их все одинаково RTX 3070 может быть, как и на 80 ватт, так и на 130 ватт, сама же компания Nvidia так же пытается не афишировать этой информацией и всё-таки, что бы не нарушать закон и права покупателей, она обязана это указывать, поэтому прячет эту информацию в панели управления Nvidia (справка->информация о системе).
С десктопными видеокартами всё просто: если она показывает определённый уровень производительности, то можно рассчитывать на те же самые показатели у любого бренда. RTX 3060 от Palit будет работать примерно так же, как RTX 3060 от MSI.
С ноутбуками всё несколько сложнее: помимо видеочипа, на производительность влияет и его теплопакет. NVIDIA использует для его обозначения параметр TGP, который указывает на потребление ресурсов видеокартой.
У AMD встречается аббревиатура TBP. По сути, это то же самое.
В 30-ой и 40-ой сериях GeForce уже не используется индекс MAX-Q для маркировки карт с урезанным теплопакетом, поэтому именно TGP становится важным параметром для определения производительности при выборе игрового ноутбука.
Например, RTX 4060 с TGP 75 Вт на 10-20% слабее версии на 120 Вт. Есть и более наглядные примеры — RTX 3070 Ti 105 Вт на 25% слабее модели на 150 Вт.
Согласитесь, неприятно узнать о том, что ваш новенький ноутбук с урезанной видеокартой RTX 3070 Ti работает практически на равных с ноутбуком, у которого полноценная RTX 3060.
Итак, информации довольно много, и всего сразу, не то что бы запомнить, понять не получится, согласен.
Так как же выбирать игровой ноутбук, основываясь на всём вышеизложенном?
Давайте для начала обобщим: мы поняли, что процессоры от Intel и от AMD должны быть полноценными, не урезанными, такими у Intel являются процессоры с буквенным суффиксом "H", а у AMD Ryzen - это HS, H и HX, по сути это один и тот же процессор, только HS, например используется в тонких ноутбуках и чтобы он не перегрелся, урезан по частотам, в остальном этот тот же процессор, что и с суффиксом "H", а вот процессор HX, как раз наоборот - это всё тот же процессор с суффиксом "H", но разогнан максимально по частотам, что бы выжать всю возможную производительность.
Видеокарта, давайте подведём итог в этой части: видеокарта должна быть приближена к максимальному значению TGP для лучшей производительности. Для каждой отдельной видеокарта лучше искать информацию в поисковике, например у MSI GP66 Leopard в конфигурации с видеокартой RTX 3060, TGP составляет 130 ватт, а вот например у дорогущего ASUS ROG Zephyrus G14 GA401I параметр TGP составляет всего 60 ватт, уже очевидно где будет лучше производительность.
Так же стоит обратить внимание и на систему охлаждения ноутбука. В большинстве случаев производитель в игровых линейках учитывает это, но например тот же Asus TUF Dash F15 изначально сконструирован для других целей, не для игр, а для дизайнеров, разработчиков и т.д., которым тоже нужно мощное железо, поэтому ноутбук гораздо тоньше по сравнению со своим братом Asus TUF Gaming F15 и система охлаждения у него рассчитана не под игры, а совершенно под другие задачи и неудивительно, что в играх он будет перегреваться и процессор уходить в троттлинг.
На этом пожалуй закончу данный пост, а то уже и ограничение поста в 30 тысяч знаков подходит к концу.
P. S.: Примерно 70% информации написано мной, остальная часть заимствована из множества разных источников с просторов интернета.
Это первый тематический пост, поэтому сильно прошу не судить за стиль изложения, как сумел, так попытаться донести информацию.
Статьи про инди-разработку игр — это всегда интересно и занимательно. Но статьи про разработку игр с нуля, без каких-либо игровых движков — ещё интереснее! У меня есть небольшой фетиш, заключающийся в разработке минимально играбельных 3D-демок, которые нормально работали бы даже на железе 20-летней давности. Полтора года назад, в мае 2022 года, я написал демку гоночной игры с очень знакомым всем нам сеттингом — жигули, девятки, десятки, и всё это даже с тюнингом! В этой статье я расскажу вам о разработке 3D-игр практически с нуля: рендерер, менеджер ресурсов, загрузка уровней и граф сцены, 3D-звук, ввод и интеграция физического движка. Интересна подробнейшая статья формата "старого Пикабу" о разработке игры с нуля? Тогда добро пожаловать!
На момент написания статьи, я всё ещё остаюсь достаточно юным — буквально 5 дней назад мне исполнилось 22 года. Но если откатиться на 4 года назад и вспомнить момент наступления моего совершеннолетия, то на ум приходят сразу два значимых события: отец приходит в один день и говорит «открывай юлито, будем смотреть авто за 40 тыщ рублей». Понятное дело, что за эту сумму (~700$ по тому курсу) особо не разгуляешься, поэтому мой выбор пал на карбюраторную «семерочку», свою ровесницу (2001 год) синего цвета. Приехали с батькой смотреть на машину, обкатали и приняли решение — надо брать!
С тех пор я ездил на своем «тазе» и горя не знал — машинка не ломалась, ни разу не подводила, вложений в себя не требовала, а я начал все больше увлекаться автомобилями и изучать тематический материал. Со временем я полюбил и другие российские модели автомобилей, но особенно мне нравился АвтоВАЗ. В один момент, вспомнив про популярный и провальный некогдаLada Racing Club, мне захотелось написать «гоночки на жигулях» самому, причём полностью с нуля. А поскольку нормального арта для города у меня не было, игру я решил назвать просто и понятно: «Ралли-кубок ТАЗов» :)
Поём всем Хабром!
Но с чего начинать писать такой объемный проект самому? Тут нам, конечно же, нужен план. У меня уже был готовый самопальный 3D-фреймворк для игрушек, который я использовал в одной из прошлых демок: арена-шутер от первого лица с модельками из модов для Quake. Фреймворк был вполне рабочим, но требовал некоторой доработки для использования в «кубке тазов».
На момент начала разработки гоночки у меня уже были готовы следующие фишки:
Рендерер: Direct3D9, причём полностью FFP — для того, чтобы игра запускалась даже на встройках Intel, где нормальной поддержки шейдеров до HD-серии вообще не было. Практически все текстурные техники работали через комбайнеры — дальний предок пиксельных шейдеров, где программист оперировал целыми стадиями пиксельного конвейера, а не писал программу напрямую, что накладывало множество ограничений. Поддерживались: многослойные материалы, однопроходной сплат-маппинг для плавного текстурирования ландшафтов, отражения в кубмапах, плавный морфинг (вершинная анимация) с линейной интерполяцией между кадрами, MSAA (это заслуга GAPI), отсечение невидимой геометрии по пирамиде видимости и примитивный альфа-блендинг с ручной сортировкой.
Звук: 3D-звук на DirectSound с позиционированием относительно источника звука, ускорением и т. п. Тут моей заслуги особо нет, кроме загрузчика wav-файлов я ничего не писал.
Ввод: WinAPI + DirectInput. Клавиатура опрашивалась с помощью классического GetAsyncKeyState, в то время как геймпады с помощью DirectInput. Была и абстракция осей ввода — дабы не адаптировать управление под кучу разных контроллеров.
Менеджер ресурсов: достаточно примитивен. К менеджеру ресурсов я отнесу и загрузчики — фреймворк поддерживал модели в форматах SMD (не анимированные меши, формат Half-life) и MD2 (анимированные меши, формат Quake 2, строго один материал на один меш), звуки — wav и простенький самопальный формат конфигов. Стандартный набор: трекинг ресурсов на слабых ссылках, пул ассетов для исключения дублирующейся загрузки и т. п.
Фреймворк выдавал не слишком крутую графику:
Зато был очень простым «под капотом», имел довольно неплохую расширяемую архитектуру и в целом, на нем можно было запилить что-то прикольное. Где-то за неделю я запилил вот такую демку шутера от первого лица:
Игрушка даже на VIA UniChrome работала — последователе всем известного S3 Savage/S3 Virge!
Минимальное приложение выглядело примерно так:
Приведённый выше код нарисует модельку с текстурой перед лицом игрока. Всё просто и понятно. Однако, как это всё работает «под капотом»? Давайте попробуем разобраться:
В своих играх я стараюсь придерживаться одной архитектуры: есть условный класс Engine, который управляет созданием платформозависимых окон, организацией главного цикла игры и инициализацией подсистем. Поскольку в одном процессе обычно запущен только один экземпляр игры (исключение — выделенные авторитарные серверы с комнатами, на манер Left 4 Dead), сам по себе Engine является синглтоном и содержит в себе ссылки на все необходимые подмодули.
Game.Initialize(new GameApp());
Game.Current.Run();
Как я уже говорил выше, сам по себе рендерер построен на базе графического API Direct3D9. Выбор DX9 обусловлен его распространенностью на железе прошлых лет, хорошей совместимостью (DX9 легко запускается на железе времен DX8 и даже DX7) и иногда лучшей производительностью на видеочипах от ATI. По сути, всё начинается с создания контекста или устройства в терминологии DirectX: в параметрах создания контекста указывается ширина и высота вторичного буфера, желаемый уровень сглаживания MSAA, видеорежим и частота желаемая частота обновления экрана.
При создании контекста есть свои нюансы, которые необходимо учитывать — например, большинство встроенных видеокарт не поддерживают аппаратную обработку вершин (D3DCREATE_HARDWARE_VERTEXPROCESSING), из-за чего создание контекста будет заканчиваться ошибкой без соответствующего флага, разные видеокарты поддерживают разные форматы буфера глубины и трафарета (сейчас видеокарты нативно даже 24х-битный RGB для рендертаргетов не умеют использовать, только выравненный XRGB), а видеокарты до GF5xxx-GF6xxx не поддерживали Pure режим D3D, который предполагает, что программист возлагает всю обработку ошибок на себя, при этом количество проверок в самом GAPI уменьшается, благодаря чему мы получаем небольшой выигрыш в производительности.
Важно так же отметить такой аспект, как управление ресурсами. К ресурсам видеокарты в терминологии старых GAPI относятся текстуры и буферы (как вершинные, так и индексные). В OpenGL особо нет такого понятия, как Device Lost. Если пользователь сворачивает ваше приложение из полноэкранного режима, или, например, видеодрайвер крашится — то GL сам должен позаботится о перезагрузке ресурсов обратно в видеопамять (исключение — Android и iOS, на мобилках контекст не уничтожится, но ресурсы будут выгружены и их хендлы станут некорректными). У D3D есть событие Lost, которое вызывается при потенциальной потере контекста — и его тоже нужно грамотно обрабатывать. Поэтому в D3D есть несколько пулов:
Managed: D3D9 сам сохраняет копию текстуры или геометрии в ОЗУ, а затем при потере контекста пересоздаёт аппаратные буферы и перезагружает нужные данные сам.
Default: данные загружаются напрямую в видеопамять (в терминологии D3D — AGP memory), или, если видеопамяти не хватает — в ОЗУ, если видеокарта, конечно, поддерживает Shared Memory Architecture.
System: загрузка ресурсов только в ОЗУ. Этот пул обычно не используется в играх — слишком медленно.
И грузить данные желательно в пул Default. Иначе при относительно большом количестве ресурсов, игра начнет «жрать» ОЗУ не в себя (пример — Civilization 5). При потере контекста, ресурсы нужно перезагружать с диска «на горячую»!
Переходим к самому важному — отрисовке геометрии. Для задания внешнего вида объектов на экране, используются так называемые материалы, которые содержат в себе данные о том, какая текстура должна быть наложена на объект, насколько объект отражает свет, какая техника должна использоваться и т. п. В современных движках система материалов обычно гибкая, поскольку шейдеры могут принимать самые разные параметры. В нашем случае шейдеров нет вообще, набор параметров фиксирован и зависит от видеокарты: стандартные техники типа повершинного затенения по Фонгу/Гуро, цвет объекта, туман и т. п.
Формат материалов в фреймворке выглядит вот так:
Однако даже без шейдеров была возможность сделать относительно гибкую систему материалов — с помощью комбайнеров, как это делала Quake 3. Самые первые 3D-ускорители не поддерживали смешивание нескольких текстур за один вызов отрисовки, поэтому некоторые игры шли на ухищрение: к примеру Quake вручную сортировал геометрию по отдаленности без использования буфера глубины, он просто… накладывал альфа-блендингом ту же самую геометрию с затененной текстурой освещения (лайтмапа). Это называется многопроходной рендеринг. Комбайнеры, которые появились ближе к концу 90-х, позволяли смешивать несколько текстур с помощью различных операций (Add, Sub, Mul, Xor и т. п.), а также умножать финальный цвет на определенный коэффициент. Именно комбайнеры я использовал в своём фреймворке для реализации некоторых относительно сложных эффектов — например, плавное смешивание текстур на ландшафте:
Основная проблема комбайнеров — каша из стейтов, поэтому код выглядит не особо презентабельно. Входная текстура-маска выглядит вот так:
Переходим к отрисовке. По сути, за рисование полигональной геометрии отвечает один метод — DrawMesh, с несколькими перегрузками (в идеале — основной должен принимать матрицу трансформации, а остальные принимать обычные World-space координаты, из которых будет построена матрица трансформации). В оригинале метод рисует геометрию с помощью DIPUP, поскольку практически вся геометрия в игре была анимирована (и анимация, само собой, обрабатывалась для каждой вершины софтварно, на ЦПУ, поэтому я не видел разницы между перезаливкой геометрии на GPU каждый кадр и DIPUP), однако в одном из бранчей фреймворка я переписал отрисовку статику на обычный DIP. Обратите внимание, что DIPUP для комплексной геометрии на старых GPU будет слишком медленным — когда-то этим страдал графический движок Irrlicht.
В более позднем бранче добавилось отсечение по дистанции от «глаз» игрока и по пирамиде видимости.
Переходим к анимации. Есть три основных метода анимации геометрии в играх:
Скиннинг: анимация вершин относительно скелета модели. Очень хорошо подходит для различных персонажей. Весь скелет является иерархией, где каждый элемент трансформируется относительно позиции родителя, что позволяет легко интегрировать «скелетку» в граф-сцены самого движка (Unity — самый яркий пример). Иногда скелетку используют и для «неоживленных» предметов — например, анимация подвески авто.
Морфинг: классический способ анимации суть которого заключается в «запекании» всех кадров в виде множества мешей. Затем игра интерполирует вершины между кадрами анимации, благодаря чему достигается эффект плавности.
Object-Transform: классический метод иерархической анимации, очень похож на скиннинг, только трансформируются не сами вершины, а привязанные к ним объекты. Применялась, например, во многих играх на PS1 и в GTA III (замечали отсутствие плавности в местах сочленений персонажей — это и есть OT).
Я не умею нормально работать с скиннингом моделей в 3D-редакторах и обычно не юзаю скиннинг в своих игрушках — для небольших демок хватает обычного морфинга с интерполяцией. Если интерполяцию не использовать, то анимация будет выглядеть топорно (в Quake 1 при отключении CVar'а такая и была):
Работа с анимациями выглядела вот так:
По сути, одна из самых комплексных частей — рендерер, готова. Однако в играх требуются и другие подсистемы, которые реализовать куда проще.
Реализация звука в играх задача не шибко сложная, если дело не доходит до программной реализации микшера, 3D-позиционирования и различных эффектов. Большинству игр хватает обычного не-сжатого wav, звук в котором хранится в виде PCM-потока.
В качестве API для звука я выбрал DirectSound. Очень удобное API, хотя сейчас его фактически вытеснил XAudio. DirectSound поддерживает любые звуковые карты, сам занимается микшированием звука, а в некоторых старичках типа AC97 умеет даже аппаратное ускорение! На современных машинах обычно микширование реализовано полностью софтварно, дабы не упираться в количество каналов/память на борту звукового адаптера, но в прошлом это помогало снизить нагрузку на процессор.
В DirectSound есть два основных объекта: сам IDirectSound8, представляющий интерфейс к звуковой карте и управлению её ресурсами и буфер — который может быть подкреплен как собственными данными, так и данными из другого буфера. В играх, они делятся на три базовых понятия:
Слушатель: описание позиции и иных параметров «слушателя» — позиции ушей в игровом мире. Обычно позиция слушателя совпадает с позицией игрока.
Источник: описание источника звука в 3D-пространстве. Например, если мимо нас проносится машина, то звуковому API необходимо знать позицию, ускорение и дальность звука, дабы правильно скорректировать звук в пространстве.
Поток: поток, который содержит в себе звук. Может быть как обычным буфером, куда звук уже предварительно загружен, так и потоковым буфером, куда загружается часть музыки или другого длинного трека.
Переходим к реализации примитивного звука:
Теперь мы можем воспроизводить звуки в нашей игре!
Однако, нам нужно чтобы пользователь мог взаимодействовать с нашей игрой. Для этого в разных системах есть различные API для взаимодействия с устройствами ввода. В случае Windows — это DirectInput для обычных USB-геймпадов и рулей, и XInput для геймпадов, совместимых с Xbox 360/Xbox One. Нажатия с клавиатуры можно обрабатывать двумя способами: с помощью событий WM_KEYDOWN и WM_KEYUP и функции WinAPI GetAsyncKeyState.
Пока что мне нужна только клавиатура и мышь:
В идеале обработку ввода лучше абстрагировать от физических устройств взаимодействия. Для этого вводятся понятия осей, кнопок действий и т. п. Желательно сразу продумать, как игра будет работать с геймпадом и уже затем назначать кнопкам на клавиатуре действия абстрактного геймпада.
Ну что ж, самый базовый фреймворк для игр у нас есть. Пора переходить к написанию самой игры!
Поскольку у фреймворка нет какого-либо своего графа сцены, я реализовываю механизм загрузки уровней в каждой игре с нуля — под конкретные нужды. В какой-то игре нужен стриминг для открытого мира, в другой — быстрая загрузка уровней, где есть множество объектов с разными параметрами. Изначально я использовал Blender в качестве редактора уровней и экспортировал карты небольшим скриптом, который сохранял основные параметры в файл.
Однако блендер (особенно 2.79 и ниже) не очень удобный редактор для работы с достаточно большими картами. Поэтому в определенный момент встал вопрос с организацией графа сцены и собственного редактора карт.
Граф сцены и графом то не назовешь — это просто линейный список объектов, которые присутствуют на сцене. Каждый объект наследуется от базового абстрактного типа Entity, если это «невидимый» объект, или PhysicsEntity, если объект должен интегрироваться с физическим движком. У базового объекта есть только имя и флаг выборки в редакторе.
Вообще, для редактирования уровней можно хоть редактор Unity использовать, предварительно написав экспортер в самопальный формат. Однако я решил реализовать свой редактор: как обычное Windows Forms приложение + панель, в которую движок рендерит картинку. В его реализации нет ничего необычного: он точно также загружает уровень, как и основная игра, но при этом не создаёт игрока и ботов и имеет свободную камеру.
Формат уровней примитивный донельзя. В процессе разработки небольших игрушек я обычно следую принципу KISS и не люблю распыляться сложными сериализаторами/десериализаторами и прочими заморочками, реализовывая лишь самые необходимый функционал. Формат карт — текстовый, одна линия на один объект:
p ferns 0 0 10.8 0 0 0 1
Где p — «класс» объекта, в случае p — это Prop, «декорация».
ferns — модель пропа. При этом сами пропы описаны в отдельных текстовых файлах, где в виде key-value значений хранятся настройки коллизии, материала, текстуры и т. п.
XYZ — позиция в мире.
XYZ — поворот в мировых координатах, задаётся в углах Эйлера (это только для статики, которая не подвержена Gimbal Lock, под капотом вся работа идёт с кватернионами).
После того, как граф сцены был готов, я приступил к реализации физики автомобилей. Но как я уже говорил, физический движок я использовал готовый — т. е. вся работа по резолвингу столкновений, распаралелливанию вычислений и Joint'ам сводилась чисто к нему. Я лишь использовав физику колеса, реализовал поведение машинки, внеся в него некоторые изменения: в основном — вынес в публичные свойства параметры трения колеса.
Само колесо реализовано по классическому принципу рейкастинга — колесо пускает под себя лучи и определяет трение относительно поверхности, на котором стоит, при этом двигая остальное тело используя собственное ускорение. Сейчас в играх для более точной симуляции используется Pacejka Magic Formula — формула, позволяющая рассчитать физически корректное поведение покрышки с различными диаметрами.
Поскольку класс сущности машинки слишком большой и требует контроля самых разных аспектов (коробка передач, аспекты тюнинга, отрисовка и материалы), я вынес часть физики в отдельный класс CarPhysics:
Как можно видеть из метода Move, наша машинка полноприводная и имеет две управляющие оси (передние, само собой). Конфигурацию привода легко можно модифицировать в будущем.
Коллизия кузова машинки — обычный OBB прямоугольник, ну или «коробка».
А вот как это работает на практике:
Пока что гонки на утюгах. Но ездит же. :))
Но с кем мы гоняемся?
Я не стал называть этот раздел ИИ — боты в игре слишком примитивные. Здесь нет никакого поиска пути, боты просто ездят по заранее отмеченным точкам на карте, которые называются
вейпоинтами. Это стандартная практика во многих гонках, однако её реализация отличается от игры к игре. Вообще, для гонок есть несколько общеизвестных практик реализации навигации противников:
Вейпоинты с поиском путей: довольно комплексный метод, который позволяет сделать, например, гонки в открытом городе, где боты сами смогут находить путь к чекпоинтам. Подобный способ используется для гонок в GTA, например. Строго говоря, сам по себе поиск путей — это тоже набор чекпоинтов и преград, поэтому для такого метода навигации необходимо довольно большое количество информации (пути для трафика, светофоры и т. п).
Вручную раставленые вейпоинты: классика. Левелдизайнер вручную расставляет вейпоинты и задает им параметры: например, на этом повороте нужно притормозить, а на этой прямой можно поддать газку.
Заранее записанные пути: способ с вейпоинтами, где разработчики сначала сами катаются по трассе, стараясь выбить лучшее время, а затем используют записанный набор вейпоинтов для противников.
При этом некоторые разработчики не стесняются красивых фейков: реализация реалистичного входа в поворот с крутой физикой может быть сложной, особенно когда боты «тупые», поэтому в некоторых играх ботам намеренно подкручивали управляемость или максимальную скорость. Помните, как быстро нагоняли соперники в NFS Underground? Вот то-то же. :)
Некоторые могут вообще записать фейковый трек, по которым машина будет просто скользить, без учета физики авто. Но «беспалевные» реализации этого способа я пока не видел.
По настоящему «трушный» способ — это когда противники используют всё те же способы, которые использует игрок — т. е. также «нажимают» на виртуальные кнопки и управляют осями автомобиля. Кроме того, частенько каждому сопернику подмешивают дополнительный фактор, куда он будет ехать — иначе машинки будут толпиться друг за другом и будет выглядеть не интересно.
Я использую классические вейпоинты с подсказками.
Сначала нам необходимо получить угол между машинкой игрока и вейпоинтом. Для этого нам нужно перевести координаты текущего вейпоинта в локальные координаты машинки с учетом её поворота (т. е. относительно неё и её Forward-вектора). Поскольку поворот автомобиля считается в кватернионах, нам нужно помножить матрицу поворота на матрицу позиции машинки в мире и умножить позицию вейпоинта используя полученную инвертированную матрицу. Звучит сложно, на деле легко:
private Vector3 WorldToLocalSpace(Vector3 worldPoint)
{
Matrix transform = Matrix.Invert(Matrix.RotationQuaternion(Rigidbody.Rotation) * Matrix.Translation(Rigidbody.Position));
Vector4 vector4 = Vector4.Transform(new Vector4(worldPoint, 1f), transform);
return new Vector3(vector4.X, vector4.Y, vector4.Z);
}
Если очень условно, то это выражение эквивалентно a — b с учетом поворота. Поскольку мы вычислили локальные координаты вейпоинта, нам остаётся только вычислить угол между ними с помощью классического atan2 и перевести радианы в градусы:
private float AngleBetween(Vector3 v1) {
return (float) Math.Atan2((double) v1.X, (double) v1.Z) * 57.29578f;
}
Полностью логика бота выглядит так:
Легко и просто, да?
Какой интерес в гонках без… гонок? Поскольку у меня не было особо ассетов для создания пригорода, я решил сделать пересеченную местность. А на пересеченной местности у нас есть как кольцевые гонки, так и спринт — от точки до точки.
Помимо этого, в игре должен быть гараж, где игрок мог бы купить новую машину или тюнинговать текущую. В начале игры выдавалась бы старая дедова копейка (модельки Оки не нашел), а то и Москвич, а потом игрок выигрывал бы в гонках и получал возможности про прокачке тачек и покупке новых. Эээх, лавры Lada Racing Club не дали покоя!
Начал я с реализации гаража. Сам по себе гараж — отдельный уровень, который обрабатывается своим контроллером, также в гараже применяется самый первый доступный UI в фреймворке — меню со списками. Сам гараж поделен на множество подменю: тюнинг, гонки и автосалон.
https://pastebin.com/dakm4AvbПараллельно с гаражом, была проработана система тюнячек — они тоже описывались в простых текстовых файлах и так или иначе влияли на ходовые качества машины. Правда, визуального тюнинга не было предусмотрена — некому моделлить апгрейды. :(
Сами гонки можно было начать, обратившись к RaceManager и передав структуру RaceParameters:
public struct RaceParameters {
public string Name;
public string Mode;
public int NumOpponents;
public int Difficulty;
public int Prize;
public int ProgressAffection;
}
После этого, игра загружала уровень, создавала ботов на месте spawnPoint (игрок оказывался, как обычно, последним) и запускала гонку.
А затем каждый кадр просчитывала позиции каждого участника гонки:
Всё! Логикой движения и всем остальным заправляли уже боты. Хотя, там и был костыль на первых этапах, который помечает флаг конца гонки, в остальном — функционал гоночек рабочий. :)
Вот мы и дошли до этапа, когда простенькая, но рабочая демка игры у нас уже есть! Игра запускается на GF4, однако работает не совсем корректно — но оптимизировать её под видеокарты тех лет не составит труда (в основном — пережать текстуры, убрать некоторые техники на комбайнерах и запечь статические пропы в батчи).
Вот так я и написал гоночки за неделю. Время разработки демки с нуля до состояния, которое вы видите в статье — всего неделю. Да, за это время реально написать прототип гоночной игры. И я ведь знаю, что в комментариях игру будут сравнивать с Lada Racing Club и шутить о сроках её разработки — ведь в этом и суть! Слишком мало реально прикольных ламповых гоночек на жигулях. Вот что у меня получилось в итоге:
Исходниками игры я конечно же поделюсь: тык на GitHub.
А вот линки на загрузку демки:
Гоночки
Шутан
Ну а для меня это был своеобразный челлендж. И я его выполнил — у меня получилась рабочая демка на выходе! Я вижу что вам, моим читателям, интересна тематика самопальной разработки игр. Судя по комментариям, вам нравится тематика геймдева, программирования графики и разработки игр. Темой одной из следующих статей может стать описание архитектуры графических ускорителей конца 90х, история их API (без D3D) и написание 3D-игры для 3dfx Voodoo с нуля, на базе Glide!
Кроме того, я хотел бы рассказать о графическом API известного многим «3D декселератора» S3 Virge. Интересна ли вам такая рубрика? Пишите в комментариях!
Статья подготовлена при поддержке TimeWeb Cloud. Подписывайтесь на меня и @Timeweb.Cloud, , чтобы не пропустить новые статьи каждую неделю!
Привет всем, в начале августа решил себе взять ps5 и одновременно с этим встал вопрос о покупке хорошего монитора. Телек у меня на Full hd (он сразу отпал) и старенький монитор Philips с TN матрицей для компа. Поэтому начал выбирать Фулл ХД и на 144 гц. Думал о 4к, но мне был важен режим производительности и стабильные 60 фпс. Первым делом не понимая куда я попал - взял себе GMNG GM-F01.
Настолько плохого монитора я в жизни не видел. Цвета максимально тусклые, ужасный черный цвет. Плюнул и сдал его обратно (благо заказывал через озон)
2)Второй монитор Ardor gaming portal
af24h1. Он был по лучше, но разницы я не особо чуствовал. Та же самая проблема с черным цветом, когда объекты в тени становятся невидимыми, а так же цветопередача была на ниже среднем уровне. Монитор был так же сдан
_____________
Потом я резко понял, что монитор с высокой герцовкой мне абсолютно не нужен. В шутеры я практически не играю, а в обычных играх не доступен режим с повышенной герцовкой. Думал себе взять именно 4к 60 гц, но мне очень важны стабильные 60 фпс. Так что начал выбирать себе мониторы фулл хд на 60 гц
————————-
3)Xioami desktop Monitor 1c
Этот монитор мне и вправду понравился. Отличная цветопередача, отсутствие рамок, приятная картинка и меню настроек. Но к сожалению одна и та же проблема, как и с другими мониторами. Проблема Черных цветов, здесь можно было его настроить, но если повышаешь параметр черных оттенков, то картинка становится как будто с «пленкой». Монитор так же был сдан.
4)Acer SA240YABI (фотки пока что нету) - самый последний мой монитор. Изначально с коробки цвета были ужасные, но покопавшись в настройках сделал очень приятную картинку. Все устраивало - глубина черного цвета, цветопередача, режим настроек и максимальная яркость. Но столкнулся с новой проблемой я впервые - слишком высокая резкость изображения (которую понизить нельзя). От такой четкости в God of War разбегаются лесенки и цветочки превращаются в лютую рябь. В настройках есть два режима - повышенная резкость (вырвиглаз) и обычная резкость (которая тоже ужасна) буду сдавать
—————
Если здесь есть ребята, которые шарят за хорошие мониторы и поняли суть моих проблем. Я буду очень благодарен, если вы покидаете хорошие варианты в комментарии с хорошей цветопередачей и отсутствие проблем черного цвета. P.S с деньгами проблем нету, не могу найти качественные обзоры именно на фулл хд мониторы с хорошей цветопередачей. Давно бы взял 4К, но не хочу снова возвращаются на 30 фпс.
Справились? Тогда попробуйте пройти нашу новую игру на внимательность. Приз — награда в профиль на Пикабу: https://pikabu.ru/link/-oD8sjtmAi
Товарищи, имеем RTX 3050 mobile, по все остальным параметрам проходит.
Как думаете, Starfield на минималках неких потянет ? Нужна якобы 1070 Ti