Тут дело вовсе не в удобности и прочих подобных вещах, разработка под эти ОС(Linux и Mac) просто коммерчески невыгодна (или даже бессмысленна), учитывая статистику рынка использования(10-15% max) и специфику вышеперечисленных ОС.
Причем людей, которые являются "геймерами" там вообще проценты.
А далее из этих процентов нужно взять тех, кто совсем по-настоящему покупает лицензии этих игр, т.к. с точки зрения компании разработчика - человек, пользующийся скачанной с торрентов игрой - это абсолютный ноль, т.к. не приносит прибыль компании и поэтому не имеет никакого веса в данном вопросе.
В результате "геймеров" становится банально меньше 1%.

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

Насчет IDE для Linux, есть еще Code::Blocks , тоже весьма неплохая весч, про Eclipse и NetBeans мне известно , т.к. под Линем часто сижу\под него пишу (Debian) и на нем пишу (под Maemo).
Но под виндой провожу все таки больше времени (несмотря на то, что Linux стабильнее и приятнее в целом).

С другой стороны, для Windows сильно больше (не в плане количества, а в плане удобства\функциональности\etc) тулсета, различных средств разработки, профайлеров, etc.
Чего только стоит(!) MSVS , тут думается no comments.
Parallel Nsight от NVidia (многопоточная отладка CPU, аппаратный дебаг шейдеров(DX, HLSL, Compute), DirectX & GPU профайлер, etc). Ставится на MSVS. (сюда же, потихоньку отходящий на задний план - NvPerfHud).
Intel VTune(продвинутый CPU профайлер), правда он доступен и под линуксом, но в связке с MSVS работать удобнее. Etc.
Контраргумент - это стоимость, тут уже ничего не поделаешь.

Вот для примера, установка NVidia драйвера. Если повезет, то нужно только собрать и установить его, это как правило, особых проблем не вызывает. Но драйвер разрабатывается под конкретную версию ядра конкретного дистрибутива и если версия под которую "разрабатывался" драйвер не совпадает с текущей версией ядра, то требуется скачать нужные сырцы и пересобрать ядро, после чего уже собирать драйвер.
Вообщем-то не так то это просто

Другая сторона - это проблемы у AMD с OpenGL, уж очень любит падать (если драйвера различаются). Во времена Doom3, ID рекомендовали ставить конкретную версию драйвера(под которую они отлаживали), получается, что решение проблемы (если появилась) сводится к поиску более устаревшего драйвера и "веселья" с ним

Вообще Linux - это рай для Программистов (с большой буквы ), опытные пользователи скажем, тоже смогут что-то полезное найти в данной ОС (и она им приглянется). Вкратце.

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

Под "стеной" ты подразумеваешь ландшафт(пару треуглов), которые вытянули в высоту? Если я все правильно понял, то так делать немножко хорошо , там будут проблемы с текстурами (они сильно потянутся вверх и размажутся), придеться два раза читать текстуры в шейдере(если есть конечно ).

А вообще, к самой модели пещеры можно приложить "сверху" небольшую окантовку (или бордюр). Представляет собой примерно сетку 8х8 (например) треугольников, в середине которой заранее смоделирован "переход" в пещеру (т.е. реальная окантовка будет меньше 8x8, по высоте не выравниваем).
И далее когда нужно воткнуть пещеру в ландшафт, то убираем в нужном месте 8x8 тайлов и подсовываем туда нашу пещерку с "окантовкой". Окантовку выравниваем по высоте участка(реального ландшафта), который вырезали. От туда же берем текстурные координаты и делаем такой же маппинг.
По высоте(около смоделированного перехода) можно по-разному равнять(можно проинтерполировать, чтобы очень плавные высоты перехода получилось, а для простоты можно взять "среднее арифметическое"), тогда грубых скачков при переходе не будет.

Начать изучать можно отсюда: http://pmg.org.ru/nehe/index.html
Отличные уроки.

Далее когда уже хорошенько со всем разберешься, то советую сходить к NVIDIA: http://developer.nvidia.com
Там найдешь много тулзов, доков и собсна OpenGL SDK (неплохой наборчик примеров). У AMD есть аналогичное - Radeon SDK (там и DX и OpenGL есть).

Вообщем, как то так , попытался более простым языком объяснить

Думаю разберешься и допишешь под свои нужды.

Начнем с точки зрения разработки\изучения GAPI начинающим разработчиком(скажем, оный не имеет большого опыта в программировании, "ООП" обзывает страшными словами, etc).
OpenGL - имеет простую процедурную архитектуру(аля просто С), DirectX в свою очередь более сложную ООП (дин. память, интерфейсы, etc). Также последний имеет некоторые специфичные вещи (Default/Managed память, Lost Device, etc) и не имеет вещей в чистом виде, упрощающих разработку и изучение(glBegin/glEnd, Matrix Stack, etc).
(Я думаю все поняли, что я имею в виду Direct3D9, ибо 11-тый сильно сложнее. Для кого слово "шейдер" вызывает тихий ужас, с 11-тым пусть лучше не связывается :). Т.к. все особенности и преимущества последнего связаны с шейдерами).
Поэтому со своей колокольни скажу, что начинающему разработчику, пришедшему в мир программирования графики и желающему освоить мощное GAPI - OpenGL mush have. Это мое имхо (так когда-то я и поступил, как результат - обладаю знаниями обоих, за очень небольшой промежуток времени).

С другой стороны, OpenGL на PC платформе находится в очень печальном положении.
Причин, можно сказать, несколько.
Во-первых, внутри драйверов он реализуется "на усмотрение" вендора, они всего лишь подгоняют все под итогую голую спецификацию. Видимо от уделения малого времени на разработку OpenGL драйвера компанией AMD(ATI), OGL ведет себя на их видеокартах очень печально, очень и очень. Для разработчиков появляются другие проблемы. Например, различность компиляторов шейдеров у каждого вендора. Поэтому любой шейдер может скомпилироваться у одного, а у другого нет. Все зависит от специфики компилятора. Ну и так далее.

Во-вторых, это система расширений OpenGL. По-началу, ее относили к его плюсам. Так как, например, если появляется какая-нибудь "фича", ее "оформляют" в виде расширения и после обновления драйвера ею уже можно воспользоваться (для справки, в DirectX для этого нужно ждать выхода новой версии последнего).
Ну, а на практике получилось вообщем-то как обычно: идея хороша, а реализация никакая. В результате появляется куча различных vendor-specific расширений, которые работают только на картах производителей :D. Это создает большую головную боль для разработчиков.
Такую же боль создает отслеживание этих самых расширений на каждой системе, ибо расширения разнятся от видеокарты к видеокарте, и если чего-либо не удается обнаружить приходиться часто в корне менять методы\логику\etc.
В общем случае - это все геморой и никому ненужные трудозатраты.

Ну, а в третьих, самая основная проблема OpenGL - это те, кто ведут его разработку последнее время: ARB (Khronos). Представляет собой большущий консорциум разных компаний, каждой из которых от OpenGL нужно что "особенное" или вообще непонятно что. Каждый приследует свои интересы и договориться они, соответственно, не могут. (хорошим примером этому следует выход OpenGL 3.0, когда обещано было столько, что на него возлагались большие надежды. Но результатом стал большущий epic fail. Многие думаю знают эту историю ).

Direct3D9, в свою очередь, тоже имел некоторую зависимость от видеокарты(Кто работал на DX, знает что такое капсы :D) , как и OpenGL со своими расширениями.
Из Direct3D11 выбросили все недостатки 9\10 (в основном 9), весь заявленный функционал стабильно работает на всех картах, поддерживающих его (нет никаких капсов), следовательно нет никакой головной боли для разработчиков.

Т.е. рынок PC платформы диктует использование именно DX (на Linux и MacOs X мало кто равняется), фактически это означает и поддержку Xbox.
PlayStation поддерживает, как уже выше писали, OpenGL да. Но он основан на стандартной спецификации и частично модифицирован компанией Sony, но в общем-то это тот же OpenGL, с тем лишь отличием, что отсутствуют всяческие проблемы с расширениями и заявленная функциональность отрабатывает на все 100%, никаких проблем.

На Mobile платформах, собственно правит OpenGL ES, некоторые проблемы с расширениями имеются, но они очень небольшого масштаба. Объясняется все обилием Mobile платформ и простой открытой спецификацией.

С точки зрения производительности, между DX и OGL можно поставить знак равно. Удобство\неудобство оных определяется лишь любителями геймдева.

Вообщем как-то так
P.S. Блин, что то слишком много букафф получилось

Считать строку в массив чаров с помощью scanf

Потом уже в цикле нужно распарсить этот массив, выделив операнды и тип операции.
Числа, кстати, проще получить с помощью таблицы ASCI. Примерно так: