изучать язык? (6 стр)

Zefick
> С# не нужен.
-2

Zefick
+1

unnamed
/2

seaman
Это про Unity3D, а не про UDK. И потроха у него всё равно на C++ написаны.

FedeX
>засорение памяти маленько..)
надо форматировать мозг
>С++ в геймдейве сейчас самый популярный.
обнадёжил меня
>Ява ... , наверно, самый высокооплачиваемый из них (в общем случае).
ещё больше обнадёжил:)

Zefick
>В общем мой совет таков, что надо изучать сначала С, потом уже С++
Приходилось мне как-то (в целях обучения) компилировать код, написанный на Си
в каком-то борландском компиляторе (кажется в 3-й версии, для msdos которая),
в дальнейшем .exe-шник заливался в микроконтроллер и запускался в нём под MiniDOS.
Не знаю, поддерживает ли язык Си ООП или нет, но код который я правил не содержал ничего похожего.
Впечатления остались так сказать "не очень" в связи с наличием
документации к контроллеру, переведённой с китайского на английский,
а также тем, что мои познания в Си чрезвычайно поверхностные.
Поэтому мне хотелось бы ликвидировать пробелы в знаниях касающихся Си,
но время не резиновое и я решил, что лучше его потратить на C++
(тем более если компиляторы C++ умеют компилировать код C, то что я собственно потеряю?)
>К тому же не долог (надеюсь) тот момент, когда Java OpenGL войдёт в состав JRE и не надо будет мучаться с библиотеками вроде JOGL.
я из-за этого начал ворошить историю браузера, пытаясь найти ссылку, где я читал о том, что последняя версия jre использует OpenGL.
т. е. всмысле сама jre использует, а от этого не холодно, не жарко... так что без JOGL не обойтись.

VisualBasic - при помощи этой штуки я впервые познакомился с программированием.
(этим всё сказано)
Но, как ни странно, знакомство с ООП началось с Java.
На языке PHP пробовал сделать форум и небольшую БД.
Форум так и не заработал, а вот MySQL это вещь!

Nigility
>На PHP не наговаривать, хорошая штука, но это другая область...
Действительно хорошая, только каким образом привязать PHP к играм я даже не представляю
(хотя может быть, наверно подразумевается поддержка PHP в .Net)

P. S.
Всё, убедили, иду курить мануалы по C++
Всем большущее спасибо за советы.
Только вот лучше посоветовали бы, где взять гору оптимизма.
Ну или хотя бы ящик антидепрессантов.
А то ведь у меня уже полно электронной документации по C++, а там толстые, толстые книжки...

daemolisher
> Действительно хорошая, только каким образом привязать PHP к играм я даже не
> представляю
Это можно. Запускаешь PHP машину не на сервере, а на компьютере с необходимыми(например http://phpopengl.sourceforge.net/) библиотеками.
Но для игр это бред.

X512
phpopengl - ужас до чего додумались и куда только прогресс катится ...

тут вопросик возник один, но мне в общем это знать и не надо, просто спросил:
"ассемблер на разных версиях виндовс разный?"

знаете такой проц из 80 серии, ну 16-битный, программируется на асме - страшная вещь скажу я вам...
пытался асм изучить - только понял то, что там с регистрами нужно шаманить - и ещё запомнил запах припоя и канифоли
на винде асм оказывается совсем другой :(

daemolisher
> на винде асм оказывается совсем другой :(
Винда к асму не имеет никакого отношения. Машинный код исполняется ПРОЦЕССОРОМ. И ещё открою страшную тайну: на компьютере стоит ОС и это не всегда Windows.

асм - это не машинный код(хотя не проверял)
если код исполняется процессором - то зачем ОС?(в ней есть апи, драйвер, ядро, hal а потом уже взаимодействие с ЦП)
я думал, что компиляторы сначала переводят ваш код(C++) в ассемблер, а затем в машинный(поправьте меня)
если на компе есть другая ОС (у меня две XP и Debian) то это ещё не значит, что есть ПО которое работает  в обеих (процессор то один и тот же).

daemolisher
> то зачем ОС?
Для пользователя в первую очередь. А также для API разработчиков.

> а потом уже взаимодействие с ЦП
ЩИТО? Программа исполняется на ЦП, а не ядром ОС. Программа может вызывать API ОС, тогда ЦП будет исполнять код ОС.

> я думал, что компиляторы сначала переводят ваш код(C++) в ассемблер, а затем в
> машинный(поправьте меня)
Не все. И в конечном результате получается не машинный код(так было только с COM файлами DOS), а в образ загрузчика модулей ОС(например PE, NE, ELF).

хм почему же существуют, к примеру, ограничения на используемую оперативу (разве XP не выбирает свои ядра в зависимости от 3Gb RAM и более)?
и бывает ли такое что exe-шники не совместимы с ядрами ОС?
некоторые файлы от старых ОС не запускаются - пишут не win32
я думал так: прога вызывает апи, он подхватывается ядром, ядро отправляет его драйверу, а драйвер тоже на ядре сидит,
но там как-бы драйвер параллельно обрабатывается ядром вместе с другими прогами за счет квантования времени ядром.
если такое понимание неверно, то это многое меняет в понимании остального.

подскажите, пожалуйста, где узнать поболее про PE, NE, ELF

daemolisher
> я думал так: прога вызывает апи, он подхватывается ядром, ядро отправляет его
> драйверу, а драйвер тоже на ядре сидит,
> но там как-бы драйвер параллельно обрабатывается ядром вместе с другими прогами
> за счет квантования времени ядром.
> если такое понимание неверно, то это многое меняет в понимании остального.

Не обижайся, - это ушло в перлы... А реально у тебя каша в голове. И ядро ОС и пользовательские процессы по очереди выполняются на процессоре. Само ядро это, тоже своего рода процесс, - но только исполняющийся в 0 кольце защиты процессора. Когда выполняется код пользовательского процесса, - процесс ядра находится в, так сказать, спящем режиме, - по тику таймера текущий процесс приостанавливается и управление переходит к планировщику, который в зависимости от приоритетов и очередей отдает управление очередному процессу.

daemolisher
> хм почему же существуют, к примеру, ограничения на используемую оперативу
> (разве XP не выбирает свои ядра в зависимости от 3Gb RAM и более)?
Потому что адреса в PE32 32-битные. Максимум 2^32 = 4 ГБ. На практике меньше(адресация обычно не с 0 начинается).

> подскажите, пожалуйста, где узнать поболее про PE
http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx

> ELF
http://www.skyfree.org/linux/references/ELF_Format.pdf

NE устарел.

таймер значит?
чему же равен период времени которое выделяется на процесс?
ну хотя бы примерно в чём меряется, в наносекундах или милли? (или такт ЦП)
можно ли написать такую прогу, которая выполняет код с точностью до наносекунд?
к примеру перекрашивает цвет экрана через 35,71 миллисекунду, а не через, к примеру, 35,72 ?
не будет ли она прерываться чем нибудь?

daemolisher
> можно ли написать такую прогу, которая выполняет код с точностью до наносекунд?
> к примеру перекрашивает цвет экрана через 35,71 миллисекунду, а не через, к
> примеру, 35,72 ?

Теоретически можно поставить процессу realtime приоритет - но поплохеет всем остальным программам, да опять же ничего не гарантируется. В ОС - реального времени, типа QNX, - гарантируется что процессу управление не перейдет раньше чем нужно, - а вот насчет позже, - такой вариант вполне возможен. Если нужно контролировать всё до тактов, - обходятся без ОС или используют однозадачные.

если отбросить мысль об ОС, то такой вопрос:
как узнать когда началась одна наносекунда и закончилась предыдущая?
в смысле что бы определённый код выполнялся по достижении определённого времени.
это я к тому клоню, что системные часы, представляют дату и время в виде единого числа в миллисекундах от начала времён (1970 год)