Вторник, 19 Марта 2024, 12:16

Приветствую Вас Гость

[ Новые сообщения · Игроделы · Правила · Поиск ]
  • Страница 1 из 2
  • 1
  • 2
  • »
Форум игроделов » Программирование » Общие обсуждения программистов » Выбор ЯП и движка
Выбор ЯП и движка
HeavyMetalДата: Суббота, 01 Августа 2015, 21:42 | Сообщение # 1
уже был
Сейчас нет на сайте
Здравствуйте!
Хотелось бы спросить вашего совета. Я сейчас изучаю C++ и графическую библиотеку SFML, надеясь в будущем использовать связку OpenGL + SFML или Unreal Engine. Но подумываю переходить на C# и Unity. Собственно хотелось бы спросить, стоит ли переходить? Или всё же лучше будет оставаться на C++ и продолжать изучать SFML и OpenGL? Или же вообще забить на всё и взяться за Unreal Engine?
GudleifrДата: Суббота, 01 Августа 2015, 22:16 | Сообщение # 2
почти ветеран
Сейчас нет на сайте
Цитата HeavyMetal ()
стоит ли переходить?
Давайте исходить из того, что изобретатели этих языков и обезьянников не совсем идиоты. Значит, то, что они придумали для чего-то нужно и полезно. А вот, подходит ли оно для Ваших целей, без миелофона не скажу.


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
HeavyMetalДата: Суббота, 01 Августа 2015, 22:43 | Сообщение # 3
уже был
Сейчас нет на сайте
Цитата Gudleifr ()
подходит ли оно для Ваших целей

Ну раз я спросил это на этом форуме, то в моих целях программирование графики.
GudleifrДата: Суббота, 01 Августа 2015, 23:05 | Сообщение # 4
почти ветеран
Сейчас нет на сайте
Цитата HeavyMetal ()
в моих целях программирование графики.
По сравнению с "фамилией, званием и личным номером" это, конечно прогресс, но не хотелось бы втыкать Вам под ногти булавки, чтобы выяснить, что за "графику" Вы имеете в виду.
Всегда помните о трех практически независимых этапах программирования:
1. Нужно решить задачу. Как Вы ее формулируете? В каких терминах? Можете ли, вообще, ее решить или считаете, что достаточно продвинутый язык решит ее за Вас?
2. Нужно записать решение на языке программирования. Опять же как Вы себе это видите? Есть ли опыт? Сколько дней у Вас уходит на изучение нового языка? Насколько богата Ваша библиотека алгоритмов?
3. Нужно приспособиться к конкретной ОС. Сколько ОС, IDE, библиотек Вы видели? По каким критериям их сравнивали? Видели ли то, что удовлетворяло Ваши художественные запросы?


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.

Сообщение отредактировал Gudleifr - Суббота, 01 Августа 2015, 23:42
berilДата: Воскресенье, 02 Августа 2015, 00:48 | Сообщение # 5
Я не ленивый, я — энергосберегающий
Сейчас нет на сайте
"Написание скриптов на C++ не является официальной целью IL2CPP и в ближайшее время ничего подобного не появится, хотя это и может произойти когда-нибудь в будущем как побочное следствие принятых решений" - из ответов разработчиков Unity. Возможно и в Unity с++ появится )
Если твоя цель разработка игр и ты этим собираешься зарабатывать на жизнь, и при этом хочешь C++ бери, как основу UE4 а в свободное время играйся SFML и OpenGL если тебе хочется побаловать себя "чистым программированием".
Если твоя цель разработка игр и ты этим собираешься зарабатывать на жизнь, и при этом хочешь C# бери, как основу Unity 5 а в свободное время играйся опять же с OpenGL а именно с оберткой под c# - OpenTK или XNA, если тебе хочется побаловать себя "чистым программированием".
большинство игр сделанные на мобильные платформы, сделаны на Unity и поэтому спрос на Unity программистов выше и будет проще найти работу.
Если же цель программирование графики, тогда однозначно C++, тут без вариантов




Накодил? Убери за собой!
Инвентарь в Unity(UI)
Инвентарь в Unity(GUI)
SaiteiДата: Воскресенье, 02 Августа 2015, 02:16 | Сообщение # 6
старожил
Сейчас нет на сайте
Цитата beril ()
Если же цель программирование графики, тогда однозначно C++, тут без вариантов

Или С. Обычно многие уроки по компьютерной графики пишутся с упором на эти два языка.
Ну а так-то можно использовать любой ЯП (и даже СЯП =) ) и полноценно заниматься программированием графики в нём.
GAPI OpenGL, по крайней мере, есть практически везде =)

Так же хочу отметить, что программирование графики под мобилки немного иная весч. Там придётся всё максимально оптимизировать и ставить разумные цели.
Хотя, на самом-то деле, современный OpenGL ES очень похож на OpenGL 3.3 и выше smile
SaiteiДата: Воскресенье, 02 Августа 2015, 02:20 | Сообщение # 7
старожил
Сейчас нет на сайте
Цитата Gudleifr ()
3. Нужно приспособиться к конкретной ОС. Сколько ОС, IDE, библиотек Вы видели? По каким критериям их сравнивали? Видели ли то, что удовлетворяло Ваши художественные запросы?

Честно говоря, пункт спорный. Зачастую "ОС-зависимые" штуки сводятся к менеджменту окна и получению ввода. В С++ остальное, например, заложено в самом стандарте (работа с файлами, потоки и т.п.).
Если это весь список требований, то можно смело брать SDL или GLFW. В чём смысл писать одно и тоже? Разве что опыт работы с API конкретных ОС, кхм..
GudleifrДата: Воскресенье, 02 Августа 2015, 07:57 | Сообщение # 8
почти ветеран
Сейчас нет на сайте
Оффтоп.
Цитата Saitei ()
В С++ остальное, например, заложено в самом стандарте (работа с файлами, потоки и т.п.).
Обычная ошибка: работа с файлами (как и остальные библиотеки, даже STL) - это часть ОС (в случае с C/C++ - Unix). Считать их частью языка - себе дороже. Лучше сразу запомнить, что даже компилятор самого языка - есть часть ОС (и практически нет языков реализованных "в чистом виде"). Например, работая с Win-API (см. Рихтера) проще проецировать файлы в память, а в 'nix-ах - файл это средство синхронизации и обмена информацией между процессами, а совсем не "место на диске".
Библиотеки, IDE и прочие "свойства машины" конечно влияют на постановку задачи и ее сложность, но не имеют практически никакого отношения к записи вашего решения задачи на языке программирования.


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
SaiteiДата: Воскресенье, 02 Августа 2015, 22:14 | Сообщение # 9
старожил
Сейчас нет на сайте
Цитата Gudleifr ()
Обычная ошибка: работа с файлами (как и остальные библиотеки, даже STL) - это часть ОС (в случае с C/C++ - Unix). Считать их частью языка - себе дороже.

Это и любой дурак поймет, ведь здесь нет магии. Речь только о том, что есть кроссовая реализация.
GudleifrДата: Воскресенье, 02 Августа 2015, 22:44 | Сообщение # 10
почти ветеран
Сейчас нет на сайте
Цитата Saitei ()
Речь только о том, что есть кроссовая реализация.
Это еще одна сказка для чайников. Не бывает переносимых программ. Бывают только совершенно по-разному реализованные ОС, которые внешне ведут себя похоже. Т.е. C-программа не сама понимает, что есть такая штука "файл", а спрашивает у ОС - понимает ли та, что это такое? И не факт, что ответ будет утвердительным. Например, о большинстве полезных свойств 'nix-файлов (о тех же мандатных и дискреционных политиках) DOS не имеет никакого понятия.

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


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
SaiteiДата: Понедельник, 03 Августа 2015, 00:55 | Сообщение # 11
старожил
Сейчас нет на сайте
Gudleifr, как раз-таки я это понимаю. Под "кроссовой реализацией" я имею ввиду единый интерфейс и множество реализаций под множество ОС. Всё это банальные истины, которые не нуждаются в разжёвывании.
ArchidoДата: Понедельник, 03 Августа 2015, 04:42 | Сообщение # 12
Сэнсэй
Сейчас нет на сайте
Цитата Saitei ()
В С++ остальное, например, заложено в самом стандарте (работа с файлами, потоки и т.п.).

Сказки. Переносимой поддержки юникода нет (здравствуй wchar_t из любимого стандарта), поэтому и работы с файлами тоже. А на стандарт надеются только очень наивные. Есть прецеденты в практике, когда вполне корректный код приводил к падению в глубинах std::map при попытке переноса этого кода на другую платформу(другой компилятор, другая реализация STL). Стандарты стандартами, но бОльшие части ОС специфики пишутся руками (или юзают буст:), правда который в свою очередь точно также написан "руками").

Цитата Saitei ()
Или С. Обычно многие уроки по компьютерной графики пишутся с упором на эти два языка.

Ну он то тут зачем? Его стихия это драйверы и микроконтроллеры. Остальные всего лишь пишут на С++ в стиле С.


C++ - он особенный. С помощью него можно не только выстрелить себе в ногу, но и повеситься в пустой комнате:)
XakepДата: Понедельник, 03 Августа 2015, 06:36 | Сообщение # 13
めちゃくちゃちゃ
Сейчас нет на сайте
Цитата Archido ()
Есть прецеденты в практике, когда вполне корректный код приводил к падению в глубинах std::map при попытке переноса этого кода на другую платформу(другой компилятор, другая реализация STL)

у меня такое было, код работающий прекрасно на на Linux и OSX падал на винде, потому-что я использовал VSC++.
Но вообще говоря можно использовать единую стандартную библиотеку на всех ос, к примеру я использую реализацию libcxx от llvm и вполне комфортно работаю с STL, вместо VSC++ использую clang либо mingw


Сообщение отредактировал Xakep - Понедельник, 03 Августа 2015, 08:02
GudleifrДата: Понедельник, 03 Августа 2015, 08:11 | Сообщение # 14
почти ветеран
Сейчас нет на сайте
Цитата Saitei ()
Всё это банальные истины, которые не нуждаются в разжёвывании.
Нуждается, пока кто-то верит в
Цитата Saitei ()
В С++ остальное, например, заложено в самом стандарте (работа с файлами, потоки и т.п.).

Попытка заложить в стандарт языка ОС-зависимые штуки либо приводит к появлению проблемно-ориентировааного языка (BASIC-подобного), либо является просто нечестным маркетинговым ходом: "Вы купили C++? Нет, Вы не купили C++, пока не купили и STL!".


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
XakepДата: Понедельник, 03 Августа 2015, 08:20 | Сообщение # 15
めちゃくちゃちゃ
Сейчас нет на сайте
Цитата Gudleifr ()
Попытка заложить в стандарт языка ОС-зависимые штуки либо приводит к появлению проблемно-ориентировааного языка (BASIC-подобного), либо является просто нечестным маркетинговым ходом: "Вы купили C++? Нет, Вы не купили C++, пока не купили и STL!".

В C++17 будет filesystem основанная на boost::filesystem 3, как раз зависимая от ОС штука, но мне не кажется это плохим.
GudleifrДата: Понедельник, 03 Августа 2015, 08:33 | Сообщение # 16
почти ветеран
Сейчас нет на сайте
Xakep, плохо само "17". В 60-80-е годы прошлого века выходили сборнички алгоритмов на Алголе-60. И пусть сам язык ни разу не был полностью реализован ни на одной машине, программисты свободно обменивались своими идеями и наработками. А, если я даже в рамках одного языка должен постоянно пересматривать свой подход, то о какой работе может идти речь? Только о коллекционировании новых (ненужных!) фич. Просто, пока я не скачаю новый "стандарт" и не изучу никому не нужные инновации, я не буду "конкурентоспособным", а "окно" - остающееся до введения нового "стандарта" уже закрывается...

Как тут не вспомнить баян:
.


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.

Сообщение отредактировал Gudleifr - Понедельник, 03 Августа 2015, 08:35
XakepДата: Понедельник, 03 Августа 2015, 09:26 | Сообщение # 17
めちゃくちゃちゃ
Сейчас нет на сайте
Ну да в принципе,только 14й стандарт вышел, и до сих пор не всеми компиляторами поддерживается, а уже 17й на подходе, но с другой стороны C++14 очень хороший стандарт, много полезного, умные указатели к примеру.
GudleifrДата: Понедельник, 03 Августа 2015, 09:33 | Сообщение # 18
почти ветеран
Сейчас нет на сайте
Цитата Xakep ()
много полезного, умные указатели к примеру.
Поправка. Много хорошо пропиаренного. Полезность определяется результатами. Что, с внедрением умных указателей резко выросло количество хороших игр? Наоборот. Большинство "умных концепций" рассчитано на "тупого потребителя", т.е. заведомо ухудшает качество работника и его работы.


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
XakepДата: Понедельник, 03 Августа 2015, 10:06 | Сообщение # 19
めちゃくちゃちゃ
Сейчас нет на сайте
Цитата Gudleifr ()
Большинство "умных концепций" рассчитано на "тупого потребителя", т.е. заведомо ухудшает качество работника и его работы.

Правильное пользование умными указателями сложнее чем обычными, и дает хороший профит, в тем же UE4 используются умные указатели, только не из стандартной библиотеки, а собственная реализация.
GudleifrДата: Понедельник, 03 Августа 2015, 10:18 | Сообщение # 20
почти ветеран
Сейчас нет на сайте
Цитата Xakep ()
Правильное пользование умными указателями сложнее чем обычными, и дает хороший профит,
Одно противоречит другому. Единственная проблема программирования (выразившаяся в том, что с тех пор не написано ничего полезного), как раз и состоит в сложности. Другие "профиты" - лишь иллюзия.
Цитата Xakep ()
только не из стандартной библиотеки, а собственная реализация.
И так всегда. Если что-то надо, проще сделать самому. И зачем тогда "стандарт"?


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.

Сообщение отредактировал Gudleifr - Понедельник, 03 Августа 2015, 10:23
Форум игроделов » Программирование » Общие обсуждения программистов » Выбор ЯП и движка
  • Страница 1 из 2
  • 1
  • 2
  • »
Поиск:

Все права сохранены. GcUp.ru © 2008-2024 Рейтинг