3 / 3 / 0
Регистрация: 18.01.2017
Сообщений: 63
|
|
1 | |
Какой язык программирования выбрать для создания игр?08.07.2017, 20:43. Показов 3378. Ответов 15
Какой язык программирования выбрать для создания игр? Си или Си++. Собираюсь писать, как сложные, так и легкие игры. Я имею в виду 3D или 2D графика. Ну и писать свои движки.
0
|
08.07.2017, 20:43 | |
Ответы с готовыми решениями:
15
Какой язык программирования лучше для игр? Какой язык програмирования используется для создания аддонов к играм? Какой язык программирования ПО для программирования игр |
84 / 85 / 48
Регистрация: 12.10.2013
Сообщений: 1,079
|
|
03.09.2017, 18:51 | 2 |
C#.
0
|
Каждому свое
533 / 219 / 81
Регистрация: 05.08.2013
Сообщений: 1,614
|
|
08.09.2017, 20:35 | 3 |
DwapDaBase,
Конечно же C++, ни о каком C# и речи не может быть. Если Вы выберите движок, на котором собираетесь писать игры, то легче всего использовать управляемый язык программирования - C# или Java в приоритете будут.
0
|
84 / 85 / 48
Регистрация: 12.10.2013
Сообщений: 1,079
|
|
08.09.2017, 20:53 | 4 |
Bretbas,почему именно C++???
0
|
Каждому свое
533 / 219 / 81
Регистрация: 05.08.2013
Сообщений: 1,614
|
|
08.09.2017, 21:21 | 5 |
Веселый, потому что, если ты хочешь создавать игровой движок, то должна быть максимальная производительность, а чтобы была максимальная производительность, тебе нужно будет лезть в самые ништяки указателей, смещений. Языки со сборщиком мусора не подойдут в этом случае. Придется все делать ручками. У таких языков, как C# и Java очень много чего скрыто за кулисами, то, что грузит непонятно из-за чего процессор. Если ты хочешь делать систему, на которой будут потом делать игры, тоесть игровой движок, то тебе будет важен каждый такт процессора, каждый цикл, который не будет нарушать целостности твоего кеша при переборе, каждый байтик, который ты занимаешь. C++ в этом случае самое лучше решение. Ну и ассемблер в некоторых местах конечно же.
Говорю по своему опыту.
0
|
12061 / 8369 / 1280
Регистрация: 21.01.2016
Сообщений: 31,559
|
|
13.09.2017, 05:09 | 6 |
Вот это ты уже перегнул. Такое - уже результат самой программы, а не выбранного языка. А так да, С++ для движка - сомое оно.
Но хочу заметить несколько моментов: а) С++ такой быстрый и мощный не просто так, он потребует куда большей дисциплины и глубины познания языка; б) Для написания собственного игрового движка нужно познаний немного больше, чем "какой язык выбрать"; в) Так же неплохо бы иметь обоснование того, зачем нужно писать с нуля, а не брать готовое (хотя бы самое простое); Лично я бы порекомендовал не строить наполеоновские планы по написанию своего Unreal Engine 10 на коленке, а начать с чего-то попроще. Например написать какую-нибудь змейку или Flappy Bird на чистом GDI с применением управляемого языка (чтобы не отвлекаться на сложность С++ чьих плюсов в плане гибкости и производительности просто нет на таких скромных проектах) - C#\Java\Python\Ещё_чё_нить. Так будет получен бесценный опыт и какое-никакое понимание что и как быть должно. Следующим этапом я бы порекомендовал попользоваться простыми open source движками, чтобы сориентироваться в том, что они дают и зачем. Чтобы для себя понять, что это такое. А там уже видно будет, нужно ли писать свой "движёк" или всё-таки написание игрушки в приоритете.
2
|
13.09.2017, 08:10 | 7 |
Есть тут своя логика в этом выборе между С и C++. Если вам С++ кажется слишком большим по объёму для изучения, то возьмите пока C. Он очень маленький. Почти всё его описание изложено в небольшой книге от создателей языка: Язык программирования C. Брайан У. Керниган, Деннис М. Ритчи
В этой книге по OpenGL все примеры на чистом C: Anton's OpenGL 4 Tutorials Исходники примеров: https://github.com/capnramses/... rials_book По поводу ООП мне понравилось, как изложил мысль Otaka:
0
|
Каждому свое
533 / 219 / 81
Регистрация: 05.08.2013
Сообщений: 1,614
|
|
13.09.2017, 18:08 | 8 |
Веселый, Usaga, 8Observer8, Помоему ТС, после наших ответов, уже все равно на GameDev
Добавлено через 14 минут Я не могу утверждать с полной увереностью, так как пока что C# знаю не очень хорошо, но все таки там почти везде ссылки( кроме стандартных типов, структур и перечислений), а это автоматом говорит о том, что циклы, где идет какой-нибудь перебор ссылок, будет при каждой итерации иметь промах кеша... В C++ можно объекты расположить на стеке, и следовательно такие циклы, где будет проходить перебор этих объектов, будет более дружелюбным, чем в C#. Но может я чего не догоняю.
0
|
12061 / 8369 / 1280
Регистрация: 21.01.2016
Сообщений: 31,559
|
|
13.09.2017, 19:08 | 9 |
Bretbas, под "перебором объектов" обычно подразумевают некую коллекцию (от массива до дерева\списка). Где именно эта структура распологается роли не играет - для CPU память одна. Причём сама коллекция может хранить как указатели (ссылки в управляемых языках), так и сами объекты (в С++ и value types в C#).
Т.е. вероятность промаха кеша в С# такая же как и в C++ ибо это зависит только от используемой структуры данных, а не от конкретного ЯП.
0
|
Каждому свое
533 / 219 / 81
Регистрация: 05.08.2013
Сообщений: 1,614
|
|
13.09.2017, 19:13 | 10 |
Usaga, Ну к примеру в List<T>, если T будет ссылочный тип, то в C# этот контейнер будет содержать ссылки?
0
|
12061 / 8369 / 1280
Регистрация: 21.01.2016
Сообщений: 31,559
|
|
13.09.2017, 19:21 | 11 |
Bretbas, да, ссылки. А ссылки это что? Правильно - всегда валидные указатели. Можете посмотреть ассемблерный вывод в отладчике студии, чтобы убедиться своими глазами.
Добавлено через 1 минуту В List<T> центральным местом выступает массив, который пересоздаётся с ростом коллекции. Но в своей основе это - всё равно обычный массив со всеми вытекающими отовсюду последствиями.
0
|
Каждому свое
533 / 219 / 81
Регистрация: 05.08.2013
Сообщений: 1,614
|
|
13.09.2017, 19:35 | 12 |
Usaga,
Ну хорошо, в этом массиве в монолитном участке памяти будут лежать ссылки. При итерации цикла, черпаются соседние ячейки памяти и ложатся в кеш, чтобы потом опять не лезть в оперативку, процессор заглядывает в кеш при следующей итерации, видит там ссылку, и следовательно приходится опять обращаться в какой-то другой участок памяти по адресу ссылки. Вот тут и происходит промах кеша.
Если бы в этом монолитном участке памяти лежали не ссылки, то что можно сделать в C++, расположив объекты на стеке, то не пришлось бы при получении элемента из массива лезть по ссылке вновь
0
|
12061 / 8369 / 1280
Регистрация: 21.01.2016
Сообщений: 31,559
|
|
13.09.2017, 19:50 | 13 |
Bretbas, ссылка - понятие из ЯП. Для CPU существуют только указатели. Ссылка - указатель, для которого тем или иным способом соблюдатются некоторые требования.
Для CPU "стёк" никак не отличается от любого другого участка памяти. В кеш попадают любые данные при первом же к ним обращении. Не важно, где они лежат. Массивы в С++ действительно повзоляют хранить не только указатели, но и объекты целиком. В C# такое можно сделать только со структурами (это умышленное ограничение). Это и плюс и минус. Если объекты крохотные, а сам массив небольшой, то есть вероятность, что вся коллекция поместится в кеш, но без гарантий. Если класс крупный, то такая вероятность сильно снижается (не один этот массив нуждается в кешировании, а кеш не резиновый) + вероятность false sharing. В случае с указателями картина иная: при переборе вы, как правило, обращаетесь к определённым полям (а не целиком ко всему объекту), а так же есть надежда на то, что нужный объект найдётся раньше, чем придётся перебирать ВСЮ коллекцию (соответственно, всё тянуть в кеш не придётся). Причём, смею заметить, подобное свойственно и С++, когда в массиве (коллекции) хранятся указатели, а не сами объекты (а такое тоже практикуется), так что тут разницы между языками не особо-то и много.
0
|
Каждому свое
533 / 219 / 81
Регистрация: 05.08.2013
Сообщений: 1,614
|
|
13.09.2017, 20:03 | 14 |
Usaga,
Я и не отрицаю того, что в C++ можно написать код, который тоже будет не дружелюбный к кешу, но
В этом плюс большой плюс, так как еще раз повторюсь, такой момент позволяет писать код более дружелюбным к кешу, без промахов. В C# так нельзя сделать, кроме конечно же наследников ValueType. Вообщем хрен с ним C# тоже крутой язык, сейчас его изучаю, и мне это нравится
0
|
12061 / 8369 / 1280
Регистрация: 21.01.2016
Сообщений: 31,559
|
|
13.09.2017, 20:13 | 15 |
Bretbas, ну, как бы никто вам не гарантирует, что весь массив поместится в кеш (что было бы классно). Плюс ко всему, при манипулации данными в таком массиве (добавление, удаление, перемещение) придётся тягать весь хранимый объект, а не указатель (4\8 байт), что немного компенсирует "профит" от лежания в кеше.
В общем, данный вопрос дискуссионный. Все профиты\недостатки следует оценивать только в контексте конкретной ситуации, а не радикально и категорично. Я об этом
1
|
14.09.2017, 10:17 | 16 |
Я начал писать свой 2D движок на базе архитектуры движка описанном в книге: Build your own 2D Game Engine. В этой книге используется JS в ООПешном стиле, поэтому легко переписывается на такие языки, как: C++, C#, Java, TypeScript и т.д.
Пишу две версии движка:
Ну, это всё так - для упражнений, чтобы знать, как оно работает на низком уровне. Для мобильных игр и игр с простой графикой для Desktop/тв-приставок лучше взять Unity+C#, а для игр сложной графикой: CryEngine/Lua/FlowGraph/C#/C++ или UnrealEngine/Blueprint/C++. Такое моё личное мнение.
0
|
14.09.2017, 10:17 | |
14.09.2017, 10:17 | |
Помогаю со студенческими работами здесь
16
Помогите подобрать язык для программирования 2D игры Программа для создания игр Программа для создания игр Программы для создания игр Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |