Перед тем как мы начнём, скажу: я знаю об OpenGL гораздо больше чем о Direct3D. Я в жизни не написал ни одной строки кода для D3D, и я писал руководства по OpenGL. Так что то что я тут расскажу, не вопрос предвзятости. Теперь это просто история.
Однажды, в начале 90-х, Microsoft огляделась вокруг. Они увидели замечательные Super Nintendo и Sega Genesis, на которых было много отличных игр. И они увидели DOS. Разработчики писали для DOS так же как для консолей: прямо на железе. Но, в отличии от консолей, где разработчик точно знал каким железом располагает пользователь, разработчики для DOS вынуждены были писать в расчёте на множество различных конфигураций оборудования. А это гораздо сложнее, чем кажется на первый взгляд.
У Microsoft в то время была ещё большая проблема: Windows. Windows хотела единолично распоряжаться оборудованием, в отличие от DOS, позволявшей разработчику делать всё что ему заблагорассудится. Владение оборудованием было обязательно для того чтобы упорядочить взаимодействие между приложениями. Взаимодействие-то и не нравилось разработчикам игр, потому что забирало ценные ресурсы, которые они могли использовать для своих замечательных игр.
Чтобы привлечь разработчиков игр в Windows, Microsoft нужен был единый API который был бы низкоуровневым, работал в Windows и при этом не страдал от тормозов и, самое главное, абстрагировал бы от разработчика оборудование . Единый API для графики, звука и пользовательского ввода.
И так родился DirectX.
3D ускорители появились на свет несколько месяцев спустя. И перед Microsoft встало сразу несколько проблем. Видите ли, DirectDraw, графический компонент DirectX, работал только с 2D графикой: выделением графической памяти и побитовым копированием между разными выделенными секциями памяти.
И Microsoft купили некий промежуточный драйвер и сделали из него Direct3D версии 3. Его ругали все и повсюду . И не просто так; одного взгляда на код было достаточно чтобы отшатнуться в ужасе.
Старый Джон Кармак из Id Software взглянул на этот мусор, сказал: «К чёрту!», и решил писать под другой API - OpenGL.
Другая часть этого клубка проблем состояла в том что Microsoft были очень заняты совместной работой с SGI над реализацией OpenGL для Windows. Идея была проста - привлечь разработчиков типичных рабочих GL-приложений: систем автоматического проектирования, моделирования, всего такого. Игры были последним, о чём тогда думали в Microsoft. Это всё предназначалось для Windows NT, но Microsoft решили добавить эту реализацию и в Win95.
Чтобы привлечь внимание разработчиков профессионального софта к Windows, Microsoft попробовали подкупить их доступом к новым функциям ускорителей трехмерной графики. Microsoft сделали протокол Installable Client Driver: производитель графического ускорителя мог перегрузить программную реализацию OpenGL аппаратной. Код просто автоматически использовал аппаратную реализацию если она была доступна.
Итак, расклад сил был определён: Direct3D против OpenGL. Это действительно интересная история, учитывая насколько ужасен был D3D v3.
Комитет Архитектурных Решений OpenGL («Architectural Review Board», ARB) был организацией, ответственной за поддержку стандарта OpenGL. Они выпустили много расширений, следили за репозиторием расширений и создавали новые версии API. В Комитет входили многие влиятельные игроки графической индустрии и разработчики ОС. Apple и Microsoft в своё время тоже входили в этот комитет.
Потом появился 3Dfx с Voodoo2. Это было первое устройство, способное выполнять мультитекстурирование, чего OpenGL делать раньше не мог. Хотя 3Dfx совершенно не вписывался в стандарт OpenGL, NVIDIA, разработчик последующих графических чипов с мультитекстурированием (TNT1), положили глаз на эту реализацию. ARB пришлось выпустить расширение: GL_ARB_multitexture, которое давало доступ к мультитекстурированию.
В это же время вышел Direct3D v5. Теперь D3D стал настоящим API , а не странным куском кошачьей рвоты. Проблема? Отсутствие мультитекстурирования.
По большому счёту, это было не так важно как должно было быть, потому что люди особо не использовали мультитекстурирование. По крайней мере напрямую. Мультитекстурирование сильно ухудшало быстродействие, и во многих случаях просто не было смысла использовать его вместо multi-passing. И, естественно, разработчики игр старались убедиться что их игры заработают на старом железе, в котором мультитекстурирования не было, и многие игры его просто не использовали.
D3D это сошло с рук.
Прошло какое то время и NVIDIA выпустили GeForce 256 (не GeForce GT-250; самый первый GeForce), по большому счёту прекратив гонку вооружений в графических ускорителях на следующие два года. Основная продающая фишка - возможность делать вертексные преобразования и освещение (T&L) аппаратно. Но это не всё: NVIDIA настолько полюбили OpenGL, что их движок T&L по сути и был OpenGL. Причём буквально: насколько я понимаю, некоторые регистры действительно напрямую принимали объекты OpenGL в качестве значений.
Выходит Direct3D v6. Наконец появилось мультитекстурирование, но… нет аппаратного T&L. У OpenGL всегда был конвеер T&L, даже до того как вышел 256 он был реализован программно. Так что для NVIDIA было не очень сложно преобразовать программную реализацию в аппаратную. В D3D аппаратный T&L появился только к седьмой версии.
Потом вышел GeForce 3 и одновременно произошло много вещей.
Microsoft решили что теперь-то они уж точно не опоздают к празднику. И вместо того чтобы смотреть что делают NVIDIA и копировать это постфактум они пришли к NVIDIA и поговорили. Потом они полюбили друг друга и от этого союза появилась маленькая игровая приставка.
Потом был болезненный развод. Но это совсем другая история.
Для PC это значило что GeForce 3 вышел одновременно с D3D v8. И несложно увидеть насколько GeForce 3 повлиял на шейдеры в восьмерке. Пиксельные шейдеры в Shader Model 1 были очень сильно привязаны к железу NVIDIA. Аппаратной абстракции от NVIDIA не было вообше; SM 1.0 по сути был тем что делал GeForce 3.
Когда ATI вступили в гонку производительных графических карт со своим Radeon 8500, обнаружилась проблема. Пиксельный конвеер 8500 был мощнее чем у NVIDIA. И Microsoft выпустил Shader Model 1.1, который по сути был «тем что делал 8500».
Это может показаться провалом со стороны D3D. Но провал и успех это вопрос относительный. Настоящий провал происходил в стане OpenGL.
NVIDIA любили OpenGL, поэтому когда вышел GeForce 3, они выпустили комплект расширений OpenGL. Проприетартных расширений, подходящих только для NVIDIA. Естественно, когда вышел 8500, он не мог использовать ни одно из них.
Видите ли, в D3D v8 вы по крайней мере можете запустить шейдеры SM 1.0 на железе ATI. Естественно, чтобы использовать вкусности 8500 Вам придётся написать новые шейдеры, но Ваш код по крайней мере работал .
Чтобы получить хоть какие то шейдеры на 8500 в OpenGL, ATI пришлось написать несколько расширений OpenGL. Проприетартных расширений, подходящих только для ATI. Итак, Вам приходилось писать два пути выполнения кода, для NVIDIA и для ATI, чтобы иметь хоть какие то шейдеры.
Сейчас Вы наверняка спросите: «А чем занимался OpenGL ARB, чьей работой было поддержание OpenGL в актуальном состоянии?». Да тем же, чем занимаются большинство комитетов: тупил.
Видите ли, выше я упомянул ARB_multitexture потому что это тоже часть этой истории. С точки зрения внешнего наблюдателя ARB пытался вообще избежать добавления шейдеров. Они посчитали что если создать достаточно конфигурируемый конвеер с фиксированными фунцкиями он сможет сравняться по возможностям с шейдерными конвеерами.
И ARB стал выпускать расширение за расширением. Каждое расширение, в названии которого присутствовало «texture_env» было очередной попыткой залатать этот стареющий дизайн. проверьте реестр: между расширениями ARB и EXT таких вышло аж восемь штук. Многие вошли в основные версии OpenGL.
Microsoft в это время были участником ARB; они ушли примерно во время выхода D3D 9. Так что в принципе, вполне возможно что они каким то образом саботировали разработку OpenGL. Я лично сомневаюсь в этой версии по двум причинам. Во первых, им пришлось бы заручиться помощью других членов комитета, поскольку у одного участника только один голос. И, что более важно, во вторых, Комитету не нужен был Microsoft чтобы прийти к такому провалу. Чуть позже мы увидим что так и получилось.
Со временем ARB, скорее всего под натиском ATI и NVIDIA (очень активных участников) проснулся настолько чтобы принять шейдеры ассемблерного типа.
Хотите увидеть еще большую глупость?
Аппаратный T&L. Который в OpenGL появился раньше . Тут вот что интересно. Чтобы выжать максимальную производительность из аппаратного T&L, Вам необходимо хранить данные в GPU. В конце концов, именно в GPU они используются.
В D3D v7 Microsoft представил концепцию вертексных буферов. Это выделенные области памяти GPU для хранения данных о вертексах.
Хотите узнать когда в OpenGL появился свой аналог этого? О, NVIDIA, будучи фанатом всего что относится к OpenGL (до тех пор пока написанное остаётся проприетарным расширением NVIDIA), выпустили расширение для вертексных массивов еще при первом выпуске GeForce 256. Но когда ARB решил официально предоставить подобный функционал?
Два года спустя . Это случилось после того как они одобрили вертексные и фрагментные шейдеры (пиксели в языке D3D). Вот сколько времени заняла у ARB разработка кроссплатформенного решения для хранения данных в памяти GPU. Именно то, что нужно чтобы выжать максимум из аппаратного T&L.
Итак, разработка OpenGL была раздроблена. Нет единых шейдеров, нет единого хранилища в GPU, когда пользователи D3D уже наслаждались и тем, и другим. Могло ли стать ещё хуже?
Ну… можно сказать и так. Встречайте: 3D Labs .
Кто они такие, спросите Вы? Это разорившаяся компания которую я считаю настоящими убийцами OpenGL. Естественно, общая вялось ARB сделала OpenGL уязвимым, когда он должен был бить D3D на всех фронтах. Но 3D Labs это возможно самая большая причина текущего рыночного положения OpenGL. Что они могли сделать такого?
Они разработали Язык Шейдеров OpenGL.
Дело в том что 3D Labs была умирающей компанией. Их дорогие ускорители стали ненужными когда NVIDIA усилили давление на рынок рабочих компьютеров. И, в отличие от NVIDIA, у них не было никакого присутствия на общем рынке; если бы NVIDIA победила, они бы исчезли.
Так и получилось.
И, в попытке остаться на плаву в мире, которому не нужна была их продукция, 3D Labs появились на Game Developer Conference с презентацией того что они назвали «OpenGL 2.0». Это должно было стать полностью переписанным с нуля API OpenGL. И это имело смысл; в API OpenGL было немало шероховатостей (примечание: они есть и сейчас). Просто посмотрите на что похожа загрузка и привязка текстур; это просто какая то чёрная магия.
Частью их предложения был язык шейдеров. Вот так. Однако, в отличие от текущих кросс-платформенных расширений ARB, их язык шейдеров был «высокоуровневым» (C это высокоуровневый язык для шейдеров. Нет, правда).
Итак, Microsoft в это время работали над своим собственным высокоуровневым языком шейдеров. Назвали они его, по своей давней привычке, «Высокоуровневым Языком Шейдеров» (HLSL). Но подход к языку был в корне другим.
Самая большая проблема языка шейдеров от 3D Labs была в том что он был встроенным. Видите ли, HLSL был языком, определённым Microsoft. Они выпустили для него компилятор, который генерировал ассемблерный код для Shader Model 2.0 (и последующих версий), который Вы вставляли в D3D. В дни D3D v9, HLSL никогда не вызывался из D3D напрямую. Он был удобной абстракцией, но совершенно необязательной. У разработчика всегда оставалась возможность отложить компилятор и доработать код до максимальной производительности.
В языке 3D Labs ничего этого не было. Вы скармливали драйверу код на C-подобном языке, и он возвращал шейдер. Всё, конец истории. И не ассемблерный шейдер, не то что можно вставить куда нибудь. Настоящий объект OpenGL, представляющий шейдер.
Это означало что пользователи OpenGL были беззащитны перед ошибками разработчиков, которые только начали разбираться с компилируемыми ассемблеро-подобными языками. Баги компилятора в новом языке шейдеров OpenGL (GLSL) ходили просто табунами . Что еще хуже, если Вам удавалось правильно скомпилировать шейдер для нескольких платформ (само по себе непростая задача), Вам всё равно приходилось иметь дело с оптимизаторами того времени. Которые были не так оптимальны, как могли бы.
Хотя это было главной проблемой GLSL, но не единственной. Далеко не единственной.
В D3D, как и старых ассемблерных языках OpenGL, можно было смешивать вертексные и фрагментные (пиксельные) шейдеры. Пока они использовали единый интерфейс, можно было использовать любой вертексный шейдер с любым совместимым фрагментным шейдером. Кроме того были уровни несовместимости, которые в принципе можно было терпеть; вертексный шейдер мог выдавать данные, которые фрагментный шейдер просто не читал. И так далее.
В GLSL ничего такого не было. Вертексные и фрагментные шейдеры были собраны в единую абстракцию, которую 3D Labs назвали «программный объект». И если Вам хотелось использовать вместе вертексные и фрагментные программы, Вам приходилось строить несколько таких программных объектов. И это было причиной второй проблемы.
Видите ли, 3D Labs думали что поступают очень умно. Они основали модель компиляции в GLSL на C/C++. Вы берёте.c или.cpp и компилируете в объектный файл. Потом Вы берете один или несколько объектных файлов и линкуете их в программу. Вот так и происходит компиляция в GLSL: вы компилируете шейдер (вертексный или фрагментный) в объект шейдера. Потом Вы помещаете этот объект шейдера в программный объект и связываете их вместе чтобы получить программу.
Хотя это позвляло делать некоторые потенциально крутые вещи вроде «библиотек» шейдеров, содержащих дополнительный код, который совместно использовали основные шейдеры, на практике это означало что шейдеры компилировались дважды. Один раз на этапе компиляции, один раз на этапе линковки. Не создавалось никакого промежуточного объектного кода; шейдер просто компилировался, результат компиляции выбрасывался и компиляция повторялась во время линковки.
Так что если Вы хотели связать Ваш вертексный шейдер с двумя разными фрагментными шейдерами, Вам приходилось компилировать куда больше кода, чем в D3D. Тем более что вся компиляция C-подобных языков происходила при разработке, а не при запуске программы.
У GLSL были и другие проблемы. Возможно неправильно винить во всём 3D Labs, потому что ARB в конце концов одобрила и приняла этот язык (но ничего кроме него из их предложения «OpenGL 2.0» не прошло). Но идея была именно их.
А вот действительно печальная часть. 3D Labs по большому счёту были правы . GLSL это не векторный язык шейдеров, каким всегда был HLSL. Так случилось потому что железо 3D Labs было скалярным железом (так же как современные карты NVIDIA), но в целом они были правы по части направления развития ускорителей.
Они также были правы с «compile-online» моделью для «высокоуровневых» языков. D3D впоследствии тоже на неё перешёл.
Проблема была в том что 3D Labs оказались правы в неправильное время . И в попытке призвать будущее слишком рано, в попытке его предугадать, они отбросили настоящее. Это также как OpenGL всегда имел возможность делать T&L. Если не считать того что конвееры T&L в OpenGL были полезны ещё до выхода аппаратной реализации, а GLSL был просто обузой прежде чем мир оказался готов его принять.
Сейчас GLSL - хороший язык. Но для своего времени он был ужасен. И OpenGL пострадал за это.
Хотя я и утверждаю что 3D Labs нанесли смертельный удар, именно комитет ARB забил последний гвоздь в крышку гроба OpenGL.
Эту историю вы наверняка слышали. Во времена OpenGL 2.1, OpenGL встал перед проблемой. У него было много старых неровностей. API было сложно использовать. Для каждого действия существовало по пять способов и никто не знал, какой окажется самым быстрым. Можно было «изучить» OpenGL по простым руководствам, но никто не говорил Вам какое API даст Вам максимум производительности.
И ARB решил сделать ещё одну попытку изобрести OpenGL заново. Это было похоже на «OpenGL 2.0» от 3D Labs, но лучше, потому что за ней стоял ARB. Попытку назвали «Longs Peak».
Что было не так с попыткой исправить старые API? Плохо было то что Microsoft в то время были уязвимы. Это было время выхода Vista.
В Vista Microsoft решили ввести давно необходимые изменения в драйверах дисплея. Они заставили драйверы обращаться к ОС для виртуализации видеопамяти и многих других вещей.
Хотя можно сомневаться в том было ли это необходимо, но факт остаётся фактом: Microsoft решили что D3D 10 будет только для Vista (и последующих ОС). Даже если у Вас было железо, способное выполнять функции D3D 10, Вы не могли запускать D3D 10 приложения без запуска Vista.
Вы также наверное помните, что Vista… ну, скажем просто что она получилась не очень. Итак, у Вас была тормозная ОС, новое API, работающее только на этой ОС, и новое поколение ускорителей которым было нужно API и ОС чтобы превзойти предыдущее поколение ускорителей.
Однако, разработчики могли бы получить доступ к фунциям уровня D3D 10 через OpenGL. Ну, смогли бы, если бы ARB не были так заняты работой над Longs Peak.
По большому счёту, ARB потратил полтора-два года на то чтобы сделать API лучше. Когда вышел OpenGL 3.0, время Vista уже заканчивалось, на горизонте появилась Win7, и большинство разработчиков уже не интересовались фунцкиями D3D-10. В конце концов, железо для которого предназначался D3D 10 замечательно работало с D3D 9. А с расцветом портов с PC на приставки (или PC-разработчиков, занявшихся разработкой для приставок) функции класса D3D 10 оказались невостребованы.
Если бы у разработчиков был доступ к этим функциям раньше, через OpenGL на машинах с WinXP, разработка OpenGL получила бы так необходимый импульс. Но ARB упустил эту возможность. И знаете что самое плохое?
Несмотря на то что два ценных года были потрачены на разработку API с нуля… они всё равно провалились и вынуждены были вернуться к предыдущей версии.
То есть, ARB не только упустили замечательную возможность, но и не сделали ту задачу, ради которой возможность была упущена. Просто полный провал.
Это и есть история борьбы OpenGL и Direct3D. История упущенных возможностей, огромной глупости, слепоты и просто безрассудства.
Во время своего #shaderchallenge (заинтересовался как устроена красивая графика, какие визуальные эффекты можно делать шейдерами и тд,- и решил непременно изучить) я пришел к тому, что мне необходимо знать как устроены внутри игровые движки. И, конечно, нет способа лучше изучить устройство чем попробовать написать свой!
Так сказать позаколачивать знания в свою голову, наступая на разные грабли, изгугливая разные форумы, доски и тп.
В 2016ом я решил прокачаться в программировании графики и начал изучать программирование шейдеров. И как оказалось в этом деле никуда без математики, поэтому я хорошую часть этого года вспоминал, а по-большей части заново знакомился с линейной алгеброй и кое-каким мат. анализом.
С какими-то простыми эффектами я познакомился в Unity3d, я по роду своей деятельности программирую именно на этом движке. Делал скринэффекты, простой аутлайн и тп. Кстати, знание того, как устроен пайплайн и какие эффекты можно получить, развязывают руки и в некоторых ситуациях просто думаешь: — Ага, так можно вот шейдерочек написать.
Но, как я говорил выше, необходимы более глубокие знания. Пишу свой движок. Конечно на C++ и OpenGL. Не DirectX, потому, что мне казалось, что на консолях именно OpenGL, но это не так.
Все говорят, что OpenGL и DirectX очень похожи, а я понимаю, что главное это понимать концепции и подходы, а фреймворк освоить можно быстро. Поэтому перескакивать на DirectX я не стал.
Про графическую библиотеку пояснил. Теперь про язык. Я очень доволен выбором именно C++, какой он крутой, ребята! Сколько всего я о нем не знал! Сколько добавилось в новых стандартах и сколько еще предстоит изучить!
Итак, встречайте, первое более-менее презентабельное демо, в моей собственном игровом движке Rudy Engine.
Реализовано: cubemap/skybox, загрузка моделей через assimp, half-lambert для освещения, overlay-рендерер для прицела и маркера-указателя на космическую станцию.
(очень дрожит видео, не стал искать какую-то хорошую программу для записи, воспользовался monosnap, наверное он не очень для этого подходит)
В дальнейшем я хочу сделать туман, shadow-mapping, и какие-то эффекты для этой демки и, возможно, переключиться на какую-то следующую. В целом, стараюсь придерживаться взрослой и мучительной разработки: дорабатывать движок таким образом, чтобы старые демо оставались рабочими. Подрихтовываю и подлатываю его. Для чего? Нужно понять этот trade-off как у Unity, чего стоит сделать универсальный инструмент?
Летом в 2017ом году, у меня закончился испытательный срок в крупной игровой студии и я написал в блоге, вся вот эта практика с игровым движком, мне очень помогла!
Всем привет! Что-то последнее время много уроков по конструкторам игр, и не так много по различным языкам программирования. Что бы устранить эту не справедливость, я решил запилить урок по OpenGL C++, надеюсь вы оцените)Сразу же перейдем к геймдеву и будем писать маленькую игрульку нашего детства.
Для начала подключаем библиотеку OpenGL к своей среде разработки, я лично программирую в Microsoft Visual Studio 2013.
200?"200px":""+(this.scrollHeight+5)+"px");">
#include "stdafx.h"
#include
#include
#include
#include
Int N = 30, M = 20; // т.к. змейка будем ездить по квадратикам, создадим их, для нашего окна в идеале будет 30x20 квадратов
int scale = 25; // размер квадрата. Когда OpenGL будет расчерчивать поле для игры, расстояние между гранями квадрата будет 25 пикселей
Int w = scale*N; // ширина поля
int h = scale*M; // его высота
Int dir, num = 4; // 4 направления и начальный размер змеи.
struct { int x; int y; } s; // структура змеи, X и Y координаты, массив с длинной.
Class fruct // класс фруктов, тех самых, которые будет есть наша змея
{
public:
int x, y; //координаты фруктов, что и где будет находится
Void New() // паблик с новыми фруктами. Он будет вызываться в начале игры и в тот момент, когда змея съест один из фруктов
{
x = rand() % N; // вычисление X координаты через рандом
y = rand() % M; // вычисление Y координаты через рандом
}
Void DrawFruct() // паблик, отрисовывающий фрукты
{
glColor3f(0.0, 1.0, 1.0); // цвет фруктов. в openGL он задается от 0 до 1, а не от 0 до 256, как многие привыкли
glRectf(x*scale, y*scale, (x + 1)*scale, (y + 1)*scale); // "Закрашиваем" квадрат выбранным цветом, таким образом в нем "появляется" фрукт
}
} m; // масив с фруктами, таким образом, у нас появится одновременно 5 фруктов в разных местах, а не один, как мы привыкли 
Void Draw() // функция, которая отрисовывает линии
{
glColor3f(1.0, 0.0, 0.0); // цвет наших линий, в данном слуае - красный
glBegin(GL_LINES); // начинаем рисовать и указываем, что это линии
for (int i = 0; i < w; i+= scale) // отрисовываем линии в ширину
{
glVertex2f(i, 0); glVertex2f(i, h); // рисуем прямую
}
for (int j = 0; j < h; j += scale) //отрисовываем линии в высоту
{
glVertex2f(0, j); glVertex2f(w, j); // рисуем ту же самую прямую, но в другом направлении
}
GlEnd(); // конец отрисовки
}
Void tick() // функция в которой будет все обновляться (двигаться змея и т.д.)
{
for (int i = num; i > 0; --i) // движение змеи. Система остроумна и проста: блок перемешается вперед, а остальные X блоков, на X+1(2 блок встанет на место 1, 3 на место 2 и т.д...)
{
s[i].x = s.x; // задаем Х координату i блока координатой i - 1
s[i].y = s.y; // то же самое делаем и с Y координатой
}
// далее у нас система направлений.
if (dir == 0) s.y += 1; // если направление равно 0, то первый фрагмент массива перемещается на один по Y
if (dir == 1) s.x -= 1; // если направление равно 1, то первый фрагмент массива перемещается на минус один по X
if (dir == 2) s.x += 1; // аналогиная система
if (dir == 3) s.y -= 1; // аналогичная система
For (int i = 0; i < 10; i++) //цикл, в котором наша змея будет расти
{
if ((s.x == m[i].x) && (s.y == m[i].y)) // Если голова нашей змеи находится в одном блоке с фруктом, то...
{
num++; //...увеличиваем размер нашей змеи на 1
m[i].New(); // ... запускаем функцию отрисовки нового фрукта.
}
}
// Следующее нужно, что бы змея не выходила за рамка поля. Действует это просто: если змея выходит за рамки поля, то задаем
if (s.x > N) dir = 1; // Ей обратное направление. Например, если она выйдет за экран по высоте, то задаем ей направление, при котором она ползет
if (s.y > M) dir = 3; // вниз
if (s.x < 0) dir = 2;
if (s.y < 0) dir = 0;
For (int i = 1; i < num; i++) // с помощью этого цикла мы "обрежем" змею, если она заползет сама на себя
if (s.x == s[i].x && s.y == s[i].y) // проверка координат частей змеи, если X и Y координата головной части равно координате любого
num = i; // другого блока змеи, то задаем ей длину, при которой "откушенная" часть отпадает.
}
Void Snake() // выводим змейку на экран
{
glColor3f(0.1, 1.0, 0.0); //цвет змеи
for (int i = 0; i < num; i++) // цикл отрисовки.
{
glRectf(s[i].x*scale, s[i].y*scale, (s[i].x + 0.9)*scale, (s[i].y + 0.9)*scale); //Рисуем квадраты, те самые "блоки" змеи
}
}
Void Key(int key, int a, int b) // функция нажатия клавиш
{
switch (key) // используем оператор switch
{
case 101: dir = 0; break; // при нажатии клавиш, задаем направление змеи(вверх, вниз, влево, вправо)
case 102: dir = 2; break;
case 100: dir = 1; break;
case 103: dir = 3; break;
}
}
Void Display() //функция общий отрисовки
{
glClear(GL_COLOR_BUFFER_BIT); // очищаем окно перед началом отрисовки
Draw(); // вызов функции Draw, отвечающей за отрисовку фруктов
Snake(); // вызов функции Snake, отвечающей за отрисовку змейки
For (int i = 0; i < 5; i++) // заполнение карты фруктами
m[i].DrawFruct();
GlFlush(); // выводим на экран все вышеописанное
glutSwapBuffers();
}
Void timer(int = 0) // Таймер игры(промежуток времени, в котором будет производится все процессы)
{
Display(); // Вызов функций
tick();
glutTimerFunc(100, timer, 0); // новый вызов таймера(100 - промежуток времени(в милисекундах), через который он будет вызыватся, timer - вызываемый паблик)
}
Int main(int argc, char **argv) // Главная функция
{
std::cout << "Snake by Alexey Ovchinnikov:P\n Loading..."; // крутой текст в консоле при загрузке
srand(time(0));
for (int i = 0; i<10; i++) // начальная, самая первая отрисовка фруктов
m[i].New();
S.x = 10; // начальное положение змейки по X
s.y = 10; // и Y координате
// следующие функции абсолютно идиентичных почти во всех программах на OpenGL, так то запоминать их не обязательно, кроме...
glutInit(&argc, argv);
glutInitDisplayMode(GLUT_SINGLE | GLUT_RGB);
glutInitWindowSize(w, h); // ... этой, она создаем окно (w - ширина, h - высота)
glutCreateWindow("Game"); // ... этой, она задает название окна
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
gluOrtho2D(0, 640, 0, 480);
glutDisplayFunc (Display); // ... и этой, она вызывает начальную функцию, в нашем случае это главная функция отрисовки - Display
glutSpecialFunc(Key);
glutTimerFunc(50, timer, 0); // ... Ну и в начале программы задаем рекурсивный таймер.
glutMainLoop();
Return 0;
}
И так, на этом все, запускаем, играем. Постарался объяснить максимально понятно, если будут вопросы - задавайте.
P.S. И пожалуйста, не кидайтесь тапками если что-то не понятно или не так написал, первый урок в моей жизни.
Мне нужно сделать что-то вроде рейтресинга, но существенно проще - просто найти депт по лучу из каждой руки, т.е. определить расстояние до обьекта от контроллера (в руке).
Что бы не делать дурную работу, я для черновой отбраковки использовал BoundingBox::Intersects.
Все работало отлично, пока я не стал вращать предметы. Сейчас у меня данный метод работает только для оригинальных обьектов. Положив предмет "на бок" находится только точка строго по оси вращения, т.е все остальное отбрасывается, что совершенно неверно. Наверно надо как-то повернуть BoundingBox, но у него нет такого метода.
Кто-то может дать совет как с этим бороться?
| 4 апр. 2019 | 18:30 | Suslik |
Я методом тыка нашёл ответ, но ума не приложу, почему он такой. Хочу понять, что происходит.
Дан точечный источник света, излучающий по закону . Дана тонкая линза со всеми известными параметрами - фокусное расстояние, положение. Для любого положения источника можно рассчитать положение его образа, а именно линза изменяет волновой фронт от источника таким образом, что после преобразования он получается эквивалентным волновому фронту его изображения. Вопрос - по какому закону будет излучать образ источника в линзе?
| 4 апр. 2019 | 1:52 | zombihello |
Привет народ!
Прикручиваю в своем двигле инстансинг и столкнулся с несколькими траблами ответ на который я так вразумительного не нашел.
Во-первых , как правильно реализовать отсечение геометрии (банально, например, по пирамиде видимости) при отрисовке инстансингом? Первая мысль какая в голову приходить, так это при каждом рендере перезаполнять с помощью glBufferData VBO где хранится информация об экземплярах (копиях) модели которую будем рисовать. Но такой способ меня смущает тем, что при большом количестве данных все упрется в пропускную способность шины.
Во-вторых , как вообще посоветуете организовывать работу с инстансингом, как Вы данную вещь делали? Опишу как у меня сейчас. Для модели (без повторений) формирую один VBO для вершин, другой VBO для инстансиг информации (по началу выделяю на 10.000 байт) и EBO для индексов вершин. При создании копии модели я в буфер инстансинга записываю матрицу трансформации с проверкой на кол-во используемой памяти в буфере, если уже нужно больше чем выделено - копирую во временный буфер все содержимое, с помощью glBufferData(.., useSize + 10000, NULL, ...) выделяю для рабочего буфера на 10.000 байт больше (учитывая текущий размер + новый элемент), копирую с временного буфера всю информацию в рабочий и с помощью glBufferSubData дописываю новый элемент. Но мне что-то подсказывает что это все можно решить куда проще)
Буду благодарен вашим советам.
Имеется полигональная сетка, координаты текстур динамически вычисляются в зависимости от номера ячейки сетки. Номер ячейки передается из вершинного шейдера, на границах ячеек возникает артефакт в виде пунктирной линии (при смене угла зрения меняется и иногда может исчезнуть). Выглядит вот так:
Координаты текстуры меняются так (cell - передается из вершинного шейдера и представляет собой кординаты ячейки):
float PHI = 1.61803398874989484820459; // Golden Ratio vec2 uv = PHI*fragTexCoord + floor(cell)*PHI;
Хотелось бы в общих чертах понять почему эта линия на стыках вообще возникает и как от нее избавится.
Update: Отключение фильтрации в семплере не помогает.
Update2: Если ликвидировать функцию floor - линия на стыках исчезает, но мне нужна целая часть от числа и без floor я обойтись не могу.
Правка: 6:55
