Модельный компилятор

Содержание

Упрощенная модель компилятора

Выбор схемы компилятора существенно зависит от конкретного обрабатываемого языка. Однако обычно придерживаются следующей общей модели:

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

Рассмотрим каждый блок подробнее.

Не нашли то, что искали? Воспользуйтесь поиском:

Лучшие изречения: Как то на паре, один преподаватель сказал, когда лекция заканчивалась — это был конец пары: «Что-то тут концом пахнет». 8379 — | 8008 — или читать все.

188.64.174.135 © studopedia.ru Не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования. Есть нарушение авторского права? Напишите нам | Обратная связь.

Отключите adBlock!
и обновите страницу (F5)

очень нужно

Модельный компилятор

.qc сценарий — это простой текстовый файл или несколько файлов, созданных в любом простейшем текстовом редакторе и необходимых для того, чтобы cкомпилировать трёхмерную модель для игровых движков. Обычно для моделей достаточно собрать в одну папку все smd и bmp файлы, сам компилятор studiomdl, написать сценарий компиляции — qc-файл и запустить из командной строки:
studiomdl.exe НазваниеСценария.qc
и модель готова. Хотя для компилятора существуют дополнительные настройки для командной строки и даже создан графический интерфейс для управления ими, обычно запуска в командной строке достаточно. А сейчас рассмотрим команды сценариев компиляции главным образом для движка GoldSource, но и в более современных движках используется большинство перечисленных параметров и команд создания моделей.

Короче говоря, в статье собран список общих команд для компилятора studiomdl с параметрами, описанием и примерами. Начнём с основных:

$modelname
Эта команда сообщает studiomdl, как назвать и где поместить откомпилированную модель.
Пример для модели Gordon.mdl:
$modelname «C:\Half-Life\valve\models\player\Gordon.mdl»
Пример, указывающий только название модели и потому сохраняющий в текущую папку:
$modelname «shlang.mdl»

$cd
Эта команда указывает компилятору studiomdl текущую рабочую папку. Команда работает так же, как и в DOS’e команда «cd».
пример относительного пути в ту же папку, где находится и сам .qc файл:
$cd «.\»
пример абсолютного пути:
$cd «C:\Half-Life\valve\models\source\Gordon»

$cdtexture
Эта команда сообщает компилятору studiomdl, где расположены текстуры.
Пример абсолютного пути:
$cdtexture «C:\Half-Life\valve\models\source\Gordon\textures»
Пример относительного пути из текущей папки в подпапку textures:
$cdtexture «.\textures»

$externaltextures
Эта команда сообщает studiomdl, что нужно сохранять текстуры модели как отдельный *t.mdl файл. (Здесь под звёздочкой автоматически подставляется название модели, используемое в основном файле модели *.mdl). В руководстве «Modeling and Animating for Half-Life» рассказывают, что команда $externaltextures нужна тем моделям, которые часто вызываются движком, но не отображаются на экране, для них хранение текстур отдельно от сетки приведёт к ускорению отрисовки графики.
Пример:
$externaltextures
Также разработчики задумали эту команду для удобства замены текстур в некоторых моделях заменой выделенного файла *t.mdl, не трогая объёмные данные. Короче, сейчас эта возможность используется не часто.

$cliptotextures
Эта команда сообщает studiomdl компилировать ли текстуры с моделью. Она обычно используется с моделями игрока для дезматча.
пример:
$cliptotextures

$scale #
Масштаб модели больше или меньше. По умолчанию всегда равно 1.
пример, увеличивающий её в 1,2 раза:
$scale 1.2

$origin
Это смещения начала координат модели. Этот параметр нужен для точной настройки модели, если вы к примеру модель сделали выше 0 по координате Z, то вам надо обязательно указать насколько выше вы её поместили. В противном случае модель будет неправильно показыватся на экране. Внимание: после декомпиляции модели оружия из CS движения рук съезжают нафих совсем не туда куда нужно, а с помощью этой команды можно вернуть модель рук обратно не редактируя анимации.
пример коррекции по оси Z:
$origin 0 0 36

$eyeposition
Для ботов или монстров в одиночной игре нужно, чтобы сообщить игре, где глаза монстра находятся относительно начала координат модели. К примеру, из-за ошибочно низкого положения глаз он может не увидеть что-либо из-за приземистого блока, хотя модель выглядит выше блока раза в 4, а тут можно вправить ему зрение.
пример высоты глаз на уровне 65 единиц над землёй (грубо это на высоте 1,6 метра, если считать, что 40 ед. в 1 м):
$eyeposition 0 0 65

$bbox (мин по x) (мин по y) (мин по z) (макс по x) (макс по y) (макс по z)
Задаёт параллелепипед габаритов отображения сориентированный вдоль осей X, Y и Z. Он даёт знать графическому движку о протяжённости модели. Полезно задавать для крупных моделей, которые без него могут не отрисовываться, когда выглядывают из-за казалось бы некрупных препятствий. Часто этот параллелепипед отцентрирован по длине и ширине, когда (мин по x) = –(макс по x) и (мин по y) = –(макс по y). Также задаём полную высоту в (макс по z) при том, что низ на уровне пола, поэтому задаём (мин по z) = 0. На сайте valvesoftware.com пишут, что его также называют каркасом (англ. hull, но не clipping hull, т.е. это не то же самое, что и каркас границ столкновений).
Пример габаритов дерева высотой примерно 6 метров:
$bbox -48 -48 0 48 48 240

$cbox (мин по x) (мин по y) (мин по z) (макс по x) (макс по y) (макс по z)
Задаёт параллелепипед габаритов столкновений.
NB. Надо будет проверить, в его ли габариты упираешься в игре, когда модель вставляешь в игровую карту с помощью объекта cycler?
Пример объекта размером с человека:
$cbox -16 -16 0 16 16 72

$body [reverse]
Вторая по важности команда в сценарии. Это ссылка на .smd файл главной сеточной оболочки модели; базовая модель с текстурами. Известно, что в подавляющем большинстве игр тыльные стороны граней не прорисовываются для экономии ресурсов. Команда reverse обменивает лицевые и тыльные стороны граней и используется только в случае (!), если возникают проблемы при экспортировании из редакторов типа Blender или 3D MAX, когда нормали поверхностей шиворот навыворот, а модель ошибочно получается текстурами внутрь.
Пример:
$body studio «monster» reverse

$bodygroup
Команда позволяет вашей модели иметь взаимозаменяемые части. Для модели с N заменяемых частей у многих объектов monster. в редакторах карт можно задать параметр body, в значении которого указать номер части от 0 до N–1. Этот пример показывает, как сделать монстра, который может держать дробовик, винтовку MP5 или ничего. Не включайте .smd расширение.
Пример:
$bodygroup weapons
<
studio «shotgun»
studio «mp5»
blank
>

$texturegroup
Команда позволяет вашей модели иметь взаимозаменяемые текстуры. Этот пример показывает, как нормальные текстуры головы и тела могут быть заменены в игре кровавыми текстурами. Убедитесь, что включили .bmp расширение.
Пример предполагает, что на сеточной модели изначально есть текстуры body_normal.bmp и head_normal.bmp:
$texturegroup pain
<
< "body_normal.bmp" "head_normal.bmp" >
< "body_pain.bmp" "head_pain.bmp" >
>

$renamebone
Character Studio версии 2.x и старше использует другое названия для некоторых костей двуногого животного. Если вы смешиваете модели или мультипликации от более ранних версий, тогда они должны быть переименованы. Этой командой можно легко переименовать кости во время компиляции, вместо того чтобы переименовать их в каждом исходном .max файле.
пример:
$renamebone «Bip01 R Clavicle» «Bip01 R Arm»

$include
Чтобы включать в компиляцию другой .qc файл.
Пример:
$include «C:\Half-Life\valve\models\player\player_shared.qc»

$attachment
Задаёт определённую точку в пространстве, которая присоединяется к заданной скелетной вершине. Её задают для того, чтобы из её места воспроизводить различные эффекты, например такие, как отрисовка огня, спрайтов, искрение и т. д. Координаты задают удаление точки от скелетной вершины.
Пример:
$attachment 0 «Bip01 R Hand» 20 2 5

$controller
Эта команда позволяет игре управлять вращением осей модели, т.е. костей. Наиболее очевидный пример — вращение головы монстра, в примере 1. Команда позволяет игре вращать голову от -60 градусов до +60 по оси X. Пример 2 показывает как сделать контроллер рта, чтобы монстр мог говорить.
пример 1:
$controller 0 «Bip01 Head» XR -60 60
пример 2:
$controller mouth «Bone03» ZR 0 45

$hbox
Команда задаёт для костей модели hitbox’ы или по-понятному — габаритные параллелепипеды попаданий. Если звучит всё ещё сложновато, объясню подробно: в игровом движке GoldSource параллелепипеды попаданий отвечают за места получения урона моделью. Если они не заданы, то компилятор создаст их автоматически, но если вам нужно их редактировать, то легче не создавать хитбоксы заново, а сперва декомпилировать модель, исправить габариты в файле qc-сценария и снова её скомпилировать. Получившиеся хитбоксы вам покажут просмотрщики моделей типа Jed’s Half-Life Model Viewer или Half-Life Model Viewer 1.25 или даже в самой игре Half-Life, Counter-Strike или др. с помощью консольной команды r_drawentities 3 (отключить её действие можно командой r_drawentities 1).
Эта пара примеров показывает создание хитбоксов для ноги, если название костей (правой) ноги в модели Bip01 R Leg1 и Bip01 R Foot.
Пример:
$hbox 7 «Bip01 R Leg1» 0.31 -3.97 -2.84 17.60 3.94 2.97
$hbox 7 «Bip01 R Foot» -0.56 -2.34 -2.19 3.81 8.00 2.66

Примечание: действие команды r_drawentities 0 в консоли скроет все энтити, а её работа со значениями 1, 2 и 3 на иллюстрации:

$gamma
Задаёт коэффициент контрастности отображения текстур модели (иначе говоря, коэффициент γ ). По умолчанию этот коэффициент задаётся равным 1,8.
Пример, повышающий контрастность текстур модели до 3,2:
$gamma 3.2
А это пример влияния коэффициента контрастности на отображение модели гнома для значений 5, 3 и 1,8:

$sequencegroupsize
Это отделяет файлы скелетных анимаций от сеточной модели в меньшие файлы. Нужно для того, чтобы анимации загружались в память только когда необходимо, вместо того чтобы загружать их все. Это полезно для монстров с заданным сценарием анимаций. Правда современные компьютеры редко тяготятся подобными мелочами, так что можно не пользоваться, если только Вы не оптимизируете игру для мобильников.
Пример разбивания по 64 Кб:
$sequencegroupsize 64

Подробнее о параметрах команды $sequence [motion extraction] Этот параметр указывает оси по которым будет происходить перемешение модели при воспроизведении анимации. Наиболее общие параметры: X, Y, LX или LY, которые обозначают движения по x и y оси. LX и LY — для линейного движения. X и Y работают также как LX и LY. Это используется в движке GoldSource и в частности в игре Half-Life для того, чтобы перемещать монстра.

[fps ] Устанавливает скорость проигрывания кадров анимации в секунду («frames per second» как раз и значит число «кадров в секунду»).
пример: fps 15

[origin ] То же самое что и $origin но только применяется к данной анимации.
пример: origin 0 0 13

[scale ] то же самое что и $scale но только применяется к данному движению.
пример: scale 1.3

[loop] указывает, что анимация зациклена, т.е. будет проигрываться бесконечно до вызова следующего движения.
пример: loop

[frame ] Это ограничивает воспроизведение кадров движения.
пример: frame 5 10

[‘activity’ ‘multiplier’] Если у вас несколько движений к примеру выстрела из одного и того же оружия, то данная команда укажет игре, что данное движение воспроизводить нужно в 3 раза чаще, чем остальные.
пример:
ACT_RANGE_ATTACK2 3
подразумевается, что движение ACT_RANGE_ATTACK2 уже задано в программном коде объекта.

[‘rotate’] Поворачивает движение на заданный угол
Пример, поворачивающий задаваемое движение на четверть оборота:
rotate -90

События, которые может вызывать данная анимация. Параметр изменяет не очень много, но весьма полезен для создания различных эффектов. Пятитысячные события, т.е. которые начинаются с пятёрки — 5ХХХ обрабатываются клиентом игрового движка и потому важны для оформления модели в игре. События с 0ХХХ по 4ХХХ работают с сервером движка и обрабатывают более глобальные задачи вроде взаимодействий с командой или смены статуса объекта.
Важно то, что событиями 5ХХХ можно вызывать: воспроизведение звука, отображение спрайта в определённой точке, выброс искр или проделать ещё что-нибудь, если заранее запрограмировать то, что вам нужно.

Пример 1:
< event 5004 1 "weapons\shoot.wav" >
Случай 5004 — воспроизведение звука, начиная с 1 кадра. Впишите путь, начинающийся с папки вашего мода. Новички тут встретятся с небольшой заморочкой, которая описана после этого примера.

Пример 2:
< event 5001 1 "20" >
События 5001, 5011 и 5021 — для спрайтов, особенно огня и дыма из оружия. Этот пример запускает спрайт от штурмовой винтовки MP5, muzzleflash1.spr с системой координат в 1 кадре. «20» указывает, что спрайту # 0 масштаб будет увеличен в 2 раза. Ниже — перечень спрайтов с порядковыми номерами и описанием для чего они используются:

5A1: muzzleflash1.spr — MP5
51A1: muzzleflash2.spr — дробовик, пистолеты
52A1: muzzleflash3.spr — дротикомёт алиенгранта или «клешня»

Для спрайтов должна быть определена точка крепления, номер которой определяет предпоследняя цифра A. Случай 5001 делает так, чтобы начало координат спрайта было в $attachment 0, начало координат 5011-ых спрайтов — в $attachment 1 и начало координат 5021-ых — в $attachment 2 (и так можно назначать вплоть до 9 аттачмента).

Пример 3:
< event 5002 10 "5" >
Случай 5002 — для искр. Здесь это проигрывается относительно системы координат 10 и их размер увеличивается в 5 раз.

Пример 4:
< event 7 2 >
Это просто запускает случай # 7 к системе координат 2. Случаем 7 может быть всё что угодно, но оно должно быть задано в программном коде ИСКУССТВЕННОГО ИНТЕЛЛЕКТА монстра.

Пример 5:
< event 1003 20 "bigexplosion" >
Случай 1003 запускает некий механизм в карте под названием «bigexplosion» по отношению к системе координат 20.

И вот примеры команды $sequence:

Первый пример:
$sequence crouch_shoot_mp5 «crouch_shoot_mp5»
Очень простая команда содержащая в себе минимум, необходимый для того чтобы она работала. Crouch_shoot_mp5 — название анимации и «crouch_shoot_mp5» — файл анимации без .smd расширения.

Второй пример:
$sequence shoot «shoot» < < event 5001 1 "20" > < event 5004 1 "hks1.wav" >>
Этот пример использует такие события, чтобы показать работу спрайтов и звук стрельбы из оружия. Предполагается, что звук hks1.wav загружается игровым движком в заранее запрограммированном коде объекта (т.е. монстра, персонажа, устройства), в противном случае на картах, где используется эта модель нужно будет загружать звуковой файл через какой-нибудь объект, который позволяет загрузить произвольный звук, например, в Half-Life и CS обычно используют ambient_generic.

Не участвующие в компиляции комментарии в одну строчку, начинаются двумя косыми чертами // и пробелом за ними. Комментарии на целый абзац должны начинаться с символов косая черта и звёздочка /* , а заканчиваться наоборот звёздочкой и косой чертой */ .

Вот и всё что можно было сказать о содержании qc, далее опубликована пара примеров qc файлов с описанием каждой команды.

Пример самого простого файла:

// название будущей модели
$modelname «proba.mdl»

// файлы объёмной сетки и анимаций берутся из текущей папки
$cd «.\»

// файлы текстур берутся из текущей папки
$cdtexture «.\»

// векторная модель из файла proba_ref.smd
$body body «proba_ref»

// 1 однократная мультипликация (7 кадров/с) из файла idle1.smd
$sequence «idle1» «idle» fps 7

Пример для модели из игры Opposing-Force:

// название модели полного охранника из игры Opposing Force
$modelname «otis.mdl»
// путь к файлам модели
$cd «.\»
// путь к текстурам модели
$cdtexture «.\»
// масштаб 1:1
$scale 1.0

// координаты параллелепипеда отображения (полному человеку — большие габариты)
$bbox -17 -17 0 17 17 72
// координаты параллелепипеда столкновений
$cbox -16 -16 0 16 16 72

// высота глаз, как у всех человекоподобных
$eyeposition 0.000000 0.000000 63.000000

// файл модели otis_body_reference.smd
$body studio «otis_body_reference»

// группа подмоделей оружия
$bodygroup gun
<
// По умолчанию пистолет в кобуре берётся из файла сетки otis_reference_wgunnholster.smd
studio «otis_reference_wgunnholster»
// пистолет в руках
studio «otis_reference_wgun»
// в правой руке пончик
studio «otis_donut_reference»
>

// группа подмоделей голов
$bodygroup heads
<
// по умолчанию голова из файла otis_head_bald_wht2_reference.smd
studio «otis_head_bald_wht2_reference»
studio «otis_head_bald_wht_reference»
>

// 1 аттачмент на месте ствола, где рисуется спрайт огня
$attachment 0 «Bip01 R Hand» 12.000000 3.000000 4.500000

// 2 контроллера: может поворачиваться шея
$controller 0 «Bip01 Head» XR -60.000000 60.000000
// и открывается рот во время разговора
$controller mouth «Bone05» ZR 0.000000 45.000000

// 21 хитбокс, т.е. параллелепипед, воспинимающий повреждения
$hbox 3 «Bip01 Pelvis» -9.890000 -5.660000 -8.600000 2.940000 6.520000 6.790000
$hbox 6 «Bip01 L Leg» 0.000000 -5.920000 -4.000000 19.370001 3.780000 3.730000
// остальные не будем показывать, т.к. они автоматически будут созданы и так

// некоторые движения:
// повторяющееся движение холостого стояния с вызовом активности простоя ACT_IDLE (задано в коде) с параметром 50:
$sequence «idle1» «idle1» fps 15 loop ACT_IDLE 50
// движение холостого стояния 15 кадров/с с вызовом активности простоя ACT_IDLE (задано в коде) с параметром 1:
$sequence «idle2» «idle2» fps 15 ACT_IDLE 1
.
// повторяющееся движение ходьбы с поступательным сдвигом по X (LX) с вызовом активности ACT_WALK (также задано в коде) с параметром 1 и звуками шагов npc_step1.wav во время 3 кадра и npc_step3.wav во время 18 кадра:
$sequence «walk» «walk» LX fps 30 loop ACT_WALK 1
// повторяющееся движение бега со сдвигом по X с вызовом активности простоя ACT_RUN (задано в коде) с параметром 1 и звуками шагов npc_step2.wav во время 5 и npc_step4.wav во время 13 кадра:
$sequence «run» «run» LX fps 25 loop ACT_RUN 1
// движение стрельбы с вызовом активности дистанционной атаки ACT_RANGE_ATTACK1 (задано в коде) с параметром 1 и вспышкой на нулевом аттачменте спрайта muzzleflash1.spr, увеличенным в 21 раз, во время 2 кадра + событием 3 (задано в коде, вероятно звук хлопка и выброс гильзы) во время того же 2 кадра. Ещё важно отметить слияние двух движений из shootgun_blend1.smd, когда Отис стреляет под углом 50° вниз, и shootgun_blend2.smd когда стреляет под углом 50° вверх относительно горизонтального положения, их движок игры будет комбинировать в зависимости от положения цели:
$sequence «shootgun» «shootgun_blend1» «shootgun_blend2» blend XR -50 50 fps 25 ACT_RANGE_ATTACK1 1
.
// поворот налево с вызовом активности левого поворота ACT_TURN_LEFT (задано в коде) с параметром 1 :
$sequence «turnleft» «turnleft» fps 15 ACT_TURN_LEFT 1
// поворот направо с вызовом активности правого поворота ACT_TURN_RIGHT с параметром 1 :
$sequence «turnright» «turnright» fps 15 ACT_TURN_RIGHT 1
.
// движение 22 кадра/с, когда Отис машет рукой кому-нибудь:
$sequence «barn_wave» «barn_wave» fps 22
.

Спасибо человеку под псевдонимом Spider за описание команд компиляции на английском и разработчикам из компаний id Software и Valve за движок игры Half-Life и инструментарий.

Упрощенная модель компилятора

Хорошо написанный компилятор имеет модульную структуру и должен представлять пример хорошо сконструированной программы. Логически процесс компиляции разделяется на этапы, которые, в свою очередь, разделяются на фазы. Физически компилятор разделяется на проходы.

Основными (и часто единственными) этапами компиляции являются анализ (определение структуры и значения исходного кода) и синтез (построение целевого кода). Кроме того, может быть этап предварительной обработки, в которой происходит присоединение исходных файлов, развертывание макросов и т.п. Этот этап достаточно прост и в основном связан с языками С и C++.

Типичные фазы процесса компиляции показаны на рис. 1.2.

Генерация машинно-независимого кода

Оптимизация машинно-независимого кода

Генерация машинного кода

Оптимизация машинного кода

Рис. 1.2. Типичные фазы процесса компиляции

Этап анализа принято разделять на три отдельных фазы:

1. Лексический анализ.

2. Синтаксический анализ.

3. Семантический анализ.

Этап синтеза состоит из следующих фаз:

• Генерация машинно-независимого кода.

• Оптимизация машинно-независимого кода.

• Генерация машинного кода.

• Оптимизация машинного кода.

Лексический анализ – это относительно простая фаза, в которой формируются символы (или токены)языка. Слова языка, например,

или пользовательские идентификаторы, например,

или последовательности знаков, например,

удобно воспринимать как один символ, как это делается на этапе анализа. Задачей фазы лексического анализа или лексического анализатораявляется переход от последовательности знаков к символам языка, с которыми в дальнейшем будут работать синтаксическая и семантическая фазы. Такой подход копирует поведение человека при чтении программы. В конечном счете текст программы воспринимается не как простой набор знаков, а как набор символов, состоящих из этих знаков.

Наряду с преобразованием последовательности знаков в символы лексический анализатор также обрабатывает пробелы и удаляет комментарии и любые другие символы, не имеющие смысловой нагрузки для последующих этапов анализа. Важно отметить, что лексический анализатор всего лишьформирует символы – их последовательность не имеет для него никакого значения, т.е., если бы программа, допустим, написанная на языке С, начиналась с

number int return do = = ++

то лексический анализатор просто бы передал этот текст в символьном виде синтаксическому анализатору. Другими словами, лексический анализатор обычно не работает с контекстом. Если он обрабатывает один символ, для него совершенно не важно, что предшествовало этому символу или что последует за ним.

Сравнительная простота и четкая формулировка лексического анализа позволяют легко автоматизировать создание лексических анализаторов, и в настоящее время существует множество инструментальных средств, позволяющих генерировать лексические анализаторы для языка, исходя только из его лексической (т.е. локальной) структуры.

Несмотря на сравнительную простоту лексического анализатора, его выполнение может занимать значительное время в процессе компиляции. Это не должно удивлять, если учесть, что лексический анализ – единственная фаза компиляции, которая имеет дело со знаками, которых значительно больше языковых символов. Если же работа лексического анализатора не занимает значительную часть времени компиляции, то стоит задуматься об эффективности остальных фаз процесса.

В процессе синтаксического анализа определяется общая структура программы, что включает понимание порядка следования символов в программе. Это означает, что синтаксический анализатор должен обладать информацией о контексте, в котором он работает, т.е. учитывать уже прочитанные символы. Результатом работы синтаксического анализатора является представление программы в древовидной форме, которую называют синтаксическим деревом. К примеру, выражение

может быть представлено в виде, показанном на рис. 1.3.

Рис. 1.3. Представление программы в древовидной форме

Это представление называется абстрактным синтаксическим деревом. Следует отметить, что в данном представлении нет необходимости показывать скобки, поскольку структура, задаваемая ими в первоначальном выражении, представляется структурой дерева. Таким же образом вся программа может быть представлена с помощью абстрактных синтаксических деревьев.

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

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

Синтаксические анализаторы для проверки синтаксиса могут быть построены автоматически (с использованием соответствующих инструментальных средств) из определения языка, хотя при этом требуется писать код для формирования абстрактного синтаксического дерева.

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

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

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

Семантический анализ – анализ исходного текста для определения его значения. Он обычно инициируется синтаксическим анализатором для создания и получения доступа к соответствующим таблицам. То, что семантический анализ может не производиться автоматически синтаксическим анализатором, имеет свои положительные стороны: ошибки статической семантики легко обнаруживаются, и после них легко производится восстановление.

Этап синтеза процесса компиляции состоит из следующих фаз.

• Генерации машинно-независимого кода.

• Оптимизации машинно-независимого кода.

• Генерации машинного кода.

• Оптимизации машинного кода.

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

Существуют причины, по которым вначале необходимо создавать машинно-независимый код; это способствует переносимости компилятора и служит для обособления зависимости от языка и зависимости от машины. Многие компиляторы также производят некоторые промежуточные коды, которые могут быть независимы от исходного языка, машинного языка или от обоих.

В свое время были приложены значительные усилия для создания так называемого Универсального промежуточного языка (Universal Intennediate Language – UIL), удобного для использования в качестве промежуточного языка для компиляции всех, или почти всех, языков на любую машину. К сожалению, эта великолепная идея оказалась неосуществимой. Однако на данный момент существуют хорошо разработанные промежуточные языки для компиляции исходных языков, например, Р-код для Pascal, Diana для Ada, байт-код для Java. Также существуют промежуточные языки для компиляции на определенные машины, например, CTL для машины Manchester MU5. Если бы существовал удачный язык UIL, то проблема использования m языков на n машинах решалась бы созданием m препроцессоров (front end) (каждый из них состоял бы из соответствующего анализатора одного из языков и генератора UIL) и n постпроцессоров (back end) (каждый из них состоял бы из соответствующего транслятора с UIL в один из машинных кодов). Сказанное выше иллюстрируется на рис. 1.4. С другой стороны, независимая реализация каждого компилятора потребует создания m*n программных блоков, отображающих каждый язык на каждую машину.

Рис. 1.4. Использование m языков на n машинах

Одной из проблем при создании UIL является проблема выбора уровня языка: UIL может оказаться либо слишком высокоуровневым для некоторых языков, либо слишком низкоуровневым для некоторых машин. Несмотря на это, существует множество примеров компиляторов с одним исходным языком, который преобразуется в коды нескольких машин, и компиляторов, которые преобразуют различные исходные языки в один и тот же машинный.

Рассмотрим вопрос оптимизации кода. Потребность в ней может быть различной. Если требуется очень эффективный код, то компилятор обязан обеспечить значительную оптимизацию. В то же время во многих средах скорость работы программного обеспечения не является критическим параметром, следовательно, необходима всего лишь незначительная оптимизация. Некоторые типы оптимизации реализовать просто, и поэтому их часто включают в компиляторы, тогда как другие формы оптимизации, в особенности глобальные (в отличие от локальных), трудоемки и требуют значительных затрат времени при компиляции, а посему употребляются редко. Многие компиляторы позволяют пользователю самому определить, требуется ли исчерпывающая (а следовательно, дорогая) оптимизация.

В фазе распределения памяти каждая константа и переменная, фигурирующие в программе, получают зарезервированное место в памяти для хранения своего значения. Данная область памяти может иметь один из следующих типов:

Статическая память, если время жизни переменной равно времени жизни программы. Она не может быть освобождена до завершения выполнения программы.

Динамическая память, если время жизни переменной равно времени жизни определенного блока, функции или процедуры. Она может быть освобождена после выполнения данного фрагмента программы.

Глобальная память, которая должна выделяться и освобождаться в процессе выполнения, если на момент компиляции время жизни неизвестно. Эффективный контроль подобной памяти вызывает определенные служебные издержки времени выполнения.

Результатом работы фазы распределения памяти является создание адреса, в котором содержится полная информация о локализации памяти. В дальнейшем адрес передается генератору кода.

Этап синтеза процесса компиляции (в отличие от этапа анализа) не очень поддается автоматизации, поэтому нельзя сказать, что средства его инструментальной поддержки весьма широко распространены. Ранняя идея создания компиляторакомпиляторов(compiler-compiler), программы, вход которой являлся бы спецификацией языка и машины, а выход – реализацией языка на машине, была в значительной степени осуществлена для этапа анализа и в меньшей степени – для этапа синтеза.

Если в логических терминах компилятор рассматривается как состоящий из этапов и фаз, физически он составлен из проходов (pass). Компилятор осуществляет проход каждый раз при считывании исходного кода или его представления. Многие компиляторы являются однопроходными, т.е. полный процесс компиляции полностью выполняется при однократном чтении кода. В этом случае различные описанные фазы будут выполняться параллельно (что, как правило, является наиболее удобным), что устраняет необходимость сложной связи между различными проходами. Ранние компиляторы были многопроходными (обычно 7-8 проходов) по причине недостаточного объема памяти машин того времени, Для современных компиляторов проблем с объемом памяти уже (как правило) не существует, поэтому большинство из них являются однопроходными. В то же время некоторые языки, такие как ALGOL 68, невозможно откомпилировать за один проход. Это связано с тем, что информация, необходимая какой-то конкретной фазе, недоступна в той части исходного кода, в которой она используется. Требуемые многопроходные компиляторы можно легко описать как компиляторы с несколькими предварительными проходами, в течение которых информация собирается и записывается в таблицы с последующим использованием на этапах анализа и синтеза.

Разработка компилятора модельного языка

Информация о работе

Тип Курсовая работа Предмет Программирование Количество страниц 33 Язык работы Русский язык Дата загрузки 2014-12-24 20:53:09 Размер файла 380.13 кб Количество скачиваний 137

Узнать стоимость работы

Заполнение формы не обязывает Вас к заказу работы

Скачать файл с работой

Помогла работа? Поделись ссылкой

Федеральное агентство связи
ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ
ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ
“Поволжский университет телекоммуникаций и информатики”

Факультет информационных систем и технологий

Кафедра программного обеспечения вычислительной техники
и управления в технических системах

по теории языков программирования и методов трансляции

Разработка компилятора модельного языка

Руководитель работы
_______________
«____»______________2014г.
Исполнитель
студентка гр. ПО-12у __________________
«____»______________2014г.

Введение 3
1. Постановка задачи 5
2. Формальная модель задачи 6
2.1 Формальные грамматики 6
2.2 Формы Бэкуса-Наура (БНФ) 6
2.3 Расширенные формы Бэкуса-Наура (РБНФ) 7
3. Спецификация основных процедур и функций 9
3.1 Лексический анализатор 9
3.2 Синтаксический анализатор 14
3.3 Семантический анализатор 14
4. Разработка алгоритма решения задачи 16
5. Структурная организация данных 17
5.1Спецификация входной информации 17
5.2Спецификация выходной информации 17
6. Установка и эксплуатация ПО 18
ЗАКЛЮЧЕНИЕ 19
СПИСОК ЛИТЕРАТУРЫ 20
Приложение 1. Проверка работоспособности программы 21
Приложение 2. Листинг программы 212

Введение
Компилятор — это программа, которая осуществляет перевод исходной программы в эквивалентную ей объектную программу на языке машинных команд или языке ассемблере.
Несмотря на более чем полувековую историю вычислительной техники, формально годом рождения теории компиляторов можно считать 1957, когда появился первый компилятор языка Фортран, созданный Бэкусом и дающий достаточно эффективный объектный код. До этого времени создание компиляторов было весьма творческим процессом. Лишь появление теории формальных языков и строгих математических моделей позволило перейти от творчества к науке. Именно благодаря этому, стало возможным появление сотен новых языков программирования.
Несмотря на то, что к настоящему времени разработаны тысячи различных языков и их компиляторов, процесс создания новых приложений в этой области не прекращается. Это связно как с развитием технологии производства вычислительных систем, так и с необходимостью решения все более сложных прикладных задач. Такая разработка может быть обусловлена различными причинами, в частности, функциональными ограничениями, отсутствием локализации, низкой эффективностью существующих компиляторов. Поэтому, основы теории языков и формальных грамматик, а также практические методы разработки компиляторов лежат в фундаменте инженерного образования по информатике и вычислительной технике.
Цель курсовой работы:
-закрепление теоретических знаний в области теории формальных языков, грамматик, автоматов и методов трансляции;
-формирование практических умений и навыков разработки собственного компилятора модельного языка программирования;
закрепление практических навыков самостоятельного решения инженерных задач, развитие творческих способностей студентов и умений пользоваться технической, нормативной и справочной литературой.
В настоящее время в мире появляются более новые языки программирования и не каждый из ныне существующих трансляторов могут прочитать программы, написанный на новом языке, и перевести его в другой язык. Поэтому сейчас разрабатываются новые трансляторы, в этом и заключается актуальность данной курсовой работы.

1. Постановка задачи
Разработать компилятор модельного языка, выполнив следующие действия:
1. Написать пример программы, раскрывающих особенности конструкций учебного языка программирования, отразив его функциональные возможности.
2. Составить таблицу лексем для тестового примера.
3. Разработать программное средство, реализующее лексический анализ текста программы на входном языке.
4. Вывести примеры таблиц идентификаторов и чисел.
5. Реализовать синтаксический анализатор текста программы на модельном языке методом рекурсивного спуска.
6. Дополнить синтаксический анализатор процедурами проверки семантической правильности программы на модельном языке в соответствии с контекстными условиями варианта.

2. Формальная модель задачи
Существуют три основных метода описания синтаксиса языков программирования: формальные грамматики, формы Бэкуса-Наура и диаграммы Вирта.
2.1 Формальные грамматики
Определение.Формальной грамматикой называется четверка вида:
,
где VN- конечное множество нетерминальных символов грамматики (обычно прописные латинские буквы);
VT — множество терминальных символов грамматики (обычно строчные латинские буквы, цифры, и т.п.),VTVN =;
Р – множество правил вывода грамматики, являющееся конечным подмножеством множества (VT VN)+ (VT VN)*; элемент (, ) множества Р называется правилом вывода и записывается в виде (читается: «из цепочки  выводится цепочка »);
S — начальный символ грамматики, S VN.
Для записи правил вывода с одинаковыми левыми частями вида используется сокращенная форма записи .
2.2 Формы Бэкуса-Наура (БНФ)
Метаязык, предложенный Бэкусом и Науром, использует следующие обозначения:
— символ «::=» отделяет левую часть правила от правой (читается: «определяется как»);
— нетерминалы обозначаются произвольной символьной строкой, заключенной в угловые скобки « »;
— терминалы — это символы, используемые в описываемом языке;
— правило может определять порождение нескольких альтернативных цепочек, отделяемых друг от друга символом вертикальной черты «|» (читается: «или»).
2.3 Расширенные формы Бэкуса-Наура (РБНФ)
Для повышения удобства и компактности описаний, в РБНФ вводятся следующие дополнительные конструкции (метасимволы):
— квадратные скобки «[» и «]» означают, что заключенная в них синтаксическая конструкция может отсутствовать;
— фигурные скобки «<» и «>» означают повторение заключенной в них синтаксической конструкции ноль или более раз;
сочетание фигурных скобок и косой черты «» используется для обозначения повторения один и более раз;
круглые скобки «(» и «)» используются для ограничения альтернативных конструкций.
В соответствии с данными правилами синтаксис модельного языка будет выглядеть следующим образом:
:: =A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W |X |Y | Z |a | b | c | d | e | f | g | h | i | j | k | l | m | n | o | p | q | r | s | t | u | v | w | x | y | z
::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
::= | | |

::= (B | b)
::= (O | o)
::= [D | d]
::= < | A | B | C | D | E | F | a | b |
c | d | e | f> (H | h)
::= < | >
::=
::= dim |ass | % |!| $ | if | then | else | for | to | do| while | end |read |write | true | false
::= <> | = | | >= | ( | ) | < | >| / | * | :
= end
::= dim <, >
::= < ( : | перевод строки) >
::= ass
::= if then [ else ]
::= for to do
::= while do
::= read ( <, >)
::= write ( <, >)

3. Спецификация основных процедур и функций
3.1 Лексический анализатор
Лексический анализатор (ЛА) – это первый этап процесса компиляции, на котором символы, составляющие исходную программу, группируются в отдельные минимальные единицы текста, несущие смысловую нагрузку – лексемы.
Задача лексического анализа — выделить лексемы и преобразовать их к виду, удобному для последующей обработки. ЛА использует регулярные грамматики.
ЛА необязательный этап компиляции, но желательный по следующим причинам:
1) замена идентификаторов, констант, ограничителей и служебных слов лексемами делает программу более удобной для дальнейшей обработки;
2) ЛА уменьшает длину программы, устраняя из ее исходного представления несущественные пробелы и комментарии;
3) если будет изменена кодировка в исходном представлении программы, то это отразится только на ЛА.
В процедурных языках лексемы обычно делятся на классы:
1) операторы;
2) разделители;
3) числа;
4) идентификаторы.
Каждая лексема представляет собой пару чисел вида (n, k), где n – номер таблицы лексем, k — номер лексемы в таблице.
Входные данные ЛА — текст транслируемой программы на входном языке.
Выходные данные ЛА — списковая структура, содержащая лексемы в числовом представлении.
Для модельного языка таблица операторов(1):
0. dim 1. end 2. % 3. ! 4. $
5. read 6. write 7. for 8. to 9. do
10. while 11. if 12. then 13. else 14. true 15. false
Таблицаразделителей(2):
0. <> 1. = 2. 5. >= 6. + 7. —
8. or 9. / 10. not 11.

12. * 13. : 14. ass 15. and
16. ( 17. ) 18. . 19. < 20. >
Таблицы идентификаторов (4) и таблица чисел(3) формируются в ходе лексического анализа.
Опишем результаты работы лексического анализатора для модельного языка М.
Входные данные ЛА:
dim A,I %:
dim Min %:
Min ass 32767:
for I ass 1 to 10 do
read (A)
if A =» и «<>», L2 –проверка знака « Список чисел, результат работы лексического анализатора
identif List Список идентификаторов, результат работы лексического анализатора
lexList List Список лексем, результат работы лексического анализатора

6. Установка и эксплуатация ПО
Для того чтобы установить данное программное средство на ПК необходимо подключить носитель (CD, FlashDevice), на котором это программное средство находится. Далее необходимо открыть проводник, найти данный носитель информации, найти на нем данное программное средство и скопировать его на локальный диск (винчестер).
Данное программное средство позволяет быстро получить результат, не требуя больших затрат ресурсов компьютера. Оно предназначено для использования в семействе операционных систем MSWindows. Поставляется оно в виде одного файла размером 28 Кбайт. Для работы необходимо запустить исполняемыйexe-файл.

ЗАКЛЮЧЕНИЕ
Разработали на языке программирования C# в среде MicrosoftVisualStudio 2010 на базе Microsoft NET Framework4.0 программное средство, реализующее компилятор модельного языка программирования.
Программное средство способно выполнять следующие функции:
— ввод и редактирование текста программ, написанных на определенном модельном языке;
— производить лексический анализ программ;
— выполнять синтаксическую и семантическую проверку программ;
В случае возникновения ошибок на любом из этапов работы программы информирует о них пользователя.
Программное средство протестировано на различных программах, написанных на модельном языке.

СПИСОК ЛИТЕРАТУРЫ
1. Ахо А., Сети Р., Ульман Д. Компиляторы: принципы, технологии и инструменты.: Пер. с англ. – М.: Изд. дом «Вильямс», 2001. – 768с.
2. Опалева Э. А., Самойленко В. П. Языки программирования и методы трансляции. – СПб.: БХВ-Петербург, 2005. – 480 с.: ил.
3. Ишакова Е. Н. Разработка компиляторов: Методические указания к курсовой работе. – Оренбург: ГОУ ОГУ, 2005. – 50 с.
4. Афанасьев А.Н. Формальные языки и грамматики: Учебное пособие. – Ульяновск: УлГТУ, 1997. – 84с.
5. Волкова И.А., Руденко Т.В. Формальные языки и грамматики. Элементы теории трансляции. – М.: Диалог-МГУ, 1999. – 62 с.
6. Пратт Т., Зелковиц М. Языки программирования: разработка и реализация / Под ред. А. Матросова. – СПб: Питер, 2002. – 688с.
7. Рейуорд-Смит В. Теория формальных языков. Вводный курс: Пер. с англ. – М.: Радио и связь, 1988. – 128с.
8. Соколов А.П. Системы программирования: теория, методы, алгоритмы: Учеб.пособие. – М.: Финансы и статистика, 2004. – 320с.
9. Федоров В.В. Основы построения трансляторов: Учебное пособие. – Обнинск: ИАТЭ, 1995. – 105с.

Приложение 1. Проверка работоспособности программы

Рис.3- Лексический анализ

Рис.3- Синтаксический и семантический анализ

Приложение 2. Листинг программы
namespaceAnalis
<
publicclassError : Exception
<
string text;

public Error(string text)
<
this.text = text;
>

publicenumTypeLex//типылексем
<
Operator = 0,
Separator = 1,
Constant = 2,
> Nothing,
Err
>;

publicstaticstring[] operators = newstring[]
<
«dim», «end», «%», «!», «$», «read», «write», «for», «to», «do», «while», «if», «then», «else» , «true», «false»
>;

stringprog;
string value;
TypeLextypeLex;
int index;
charch;
intpos;

List identif;
List constants;

publicLexAnalis(string program)
<
this.prog = program;
>();
constants = newList ();
Comment();
>

boolComment() // проверка комментария
<
if (pos

ch = prog[pos];
else
<
ch = (char)0;
returnfalse; //если не закрыт то false
>

>
pos++;
returntrue; // еслизакрыт true
>
else
<
ch = (char)0;
returnfalse;
>
>
publicTypeLex Next() // определениетипалексем
<
TypeLex ret = TypeLex.Nothing;
value = «»;
typeLex = TypeLex.Nothing;
while (ch != 0) // покане 0
<
if (ch == )
Comment();
elseif (char.IsDigit(ch)) // проверканацифру
<
value = string.Empty;
while (char.IsDigit(ch) || ch == .) // проверкавещественного
<
value += ch;
Comment();
>
index = constants.IndexOf(value); // ищемвхождения
if (index = 0)
ret = TypeLex.Separator;
else
<
index = IsOper(value);
if (index >= 0)
<
ret = TypeLex.Operator; // проверканаоператор
>
else
<

index = identif.IndexOf(value);
if (index = 0)
ret = TypeLex.Separator;
else
<
index = IsOper(value);
if (index >= 0)
<
ret = TypeLex.Operator;
>
else
<
ret = TypeLex.Err;
value = «неизвестныйсимвол » + ch + «»;
thrownewError(value);
>
>
Comment();
break;
>
>
typeLex = ret;
return ret;
>

using System;
usingSystem.Collections.Generic;
usingSystem.Linq;
usingSystem.Text;
usingSystem.Threading.Tasks;
usingSystem.Globalization;
usingSystem.Windows.Forms;

publicclassParsing
<
LexAnalislexer;
stringtextError;
publicList dimvars;

public Parsing(LexAnalislexer)
<
this.lexer = lexer;
textError = string.Empty;
dimvars = newList ();
>

LexAnalis.TypeLexNext(boolIgnEndStr = false) // получаемтипследующегосимвола
<
while (true)
<
LexAnalis.TypeLex type = lexer.Next();
if (!IgnEndStr || lexer.Value != »
«)
return type;
>
>

publicNodeParseProgram() // разборпрограммы
<
LexAnalis.TypeLexlexem = Next(true);
<
Blockblock = newBlock();
if (lexem == LexAnalis.TypeLex.Operator&&lexer.Value == «dim») // если dim илиоператор
<
bool flag = false;
while (true)
<
Next(true);
if (lexer.Value == «dim»)
<
flag = false;
continue;
>
if (lexer.Type == LexAnalis.TypeLex.Ident&& !flag) // еслиидентификтор
<
block.Append(ParseTypeVar()); // определяемтипидентификаторп
>
else
<
block.Append(ParseInstruct());
returnnewPrg(block, string.Empty);
>
flag = true;
>
>
else
thrownewAnalis.Error(«Отсутствует dim илиоператор»);
>
>

publicNodeParseInstructs() // разбороператоров
<
Blockblock = newBlock();
while (true)
<
if (lexer.Type == LexAnalis.TypeLex.Ident)
block.Append(ParseVarEqually());
elseif (lexer.Value == «for»)
block.Append(ParseFor());
elseif (lexer.Value == «while»)
block.Append(ParseWhile());
elseif (lexer.Value == «if»)
block.Append(ParseIf());
elseif (lexer.Value == «read»)
block.Append(ParseRead());
elseif (lexer.Value == «write»)
block.Append(ParseWrite());
elseif (lexer.Value == «end»)
<
return block;
>
elseif (lexer.Value == «:»)
<
Next();
>
elseif (lexer.Value == »
«)
<
Next(true);
return block;
>
elseif (lexer.Type == LexAnalis.TypeLex.Operator)
return block;
else
break;
>
thrownewAnalis.Error(«Нетконцапрограммы»);
>

publicNodeParseInstruct() // разбор end
<
Blockblock = newBlock();
while (true)
<
Nodenode = ParseInstructs();
block.Append(node);
if (lexer.Value == «end»)
<
Next(true);
break;
>
>
return block;
>

publicNodeParseVarEqually() // проверкаобъявленалипеременнаяраннее
<
string name = lexer.Value;
if (dimvars.IndexOf(name) vars = newList ();
if (dimvars.IndexOf(lexer.Value) > 0) thrownewAnalis.Error(«Переменная » + lexer.Value + » ужеобъявлена «);
vars.Add(lexer.Value);
LexAnalis.TypeLexlexem = Next(true);
while (lexer.Value == «,»)
<

lexem = Next(true);
if (lexem == LexAnalis.TypeLex.Ident)
<
if (dimvars.IndexOf(lexer.Value) > 0)
thrownewAnalis.Error(«Переменная » + lexer.Value + » ужеобъявлена «);
vars.Add(lexer.Value);

>
else
thrownewAnalis.Error(«Ожидалсяидентификатор, встретился » + lexer.Value);
lexem = Next();
>
if (lexem == LexAnalis.TypeLex.Operator&& (lexer.Value == «%» || lexer.Value == «!» || lexer.Value == «$»))
<
stringtypeName = lexer.Value;
Next(true);
dimvars.AddRange(vars);
returnnewTypeVar(typeName, vars);
>
elseif (lexer.Value == «ass») returnParseVarEqually();
else
thrownewAnalis.Error(«Типпеременной » + lexer.Value + «неизвестен»);
>

publicNodeParseFor() // разбороператора for
<
Next();
Node from = ParseVarEqually();
if (lexer.Value == «to»)
<
Next(true);
Node to = ParseExpr();
if (lexer.Value == «do»)
<
Next(true);
Node block = ParseBlock();
returnnewFor(from, to, block);
>
else
thrownewAnalis.Error(«Отсутствует do вцикле for «);
>
else
thrownewAnalis.Error(«Отсутствует to вцикле for «);
>

publicNodeParseWhile() // разбороператора while
<
Next();
Nodeexpr = ParseExpr();
if (lexer.Value == «do»)
<
Next(true);
Node block = ParseBlock();
returnnewOpWhile(expr, block);
>
else
thrownewAnalis.Error(«Отсутствует do вцикле while «);
>

publicNodeParseIf() // разбороператора if
<
Next();
Nodeexpr = ParseExpr();
if (lexer.Value == «then»)
<
Next(true);
NodeblockThen = ParseBlock();
NodeblockElse = null;
if (lexer.Value == «else»)
<
Next(true);
blockElse = ParseBlock();
>
returnnewOpIf(expr, blockThen, blockElse);
>
else
thrownewAnalis.Error(«Отсутствует then вцикле if «);
>

publicNodeParseRead() // разбороператора read
<
Next();
List vars = newList ();
if (lexer.Value == «(«)
<
while (Next() == LexAnalis.TypeLex.Ident)
<
vars.Add(lexer.Value);
if (Next() == LexAnalis.TypeLex.Separator)
<
if(lexer.Value == «)» ) break;
if (lexer.Value != «,»)
thrownewAnalis.Error(«Отсутствует , в операторе read»);
>
>
Next();
returnnewOpRead(vars);
>
else
thrownewAnalis.Error(«Отсутствует , воператоре read»);
>

publicNodeParseWrite() // разбороператора write
<
Next();
List vars = newList ();
if (lexer.Value == «(«)
<
while (true)
<
Next();
vars.Add(ParseExpr());
if (lexer.Type == LexAnalis.TypeLex.Separator)
<
if (lexer.Value == «)»)
<
break;
>
if (lexer.Value == «,»)
<
>
else
thrownewAnalis.Error(«Отсутствует ) воператоре write»);
>
>
Next();
returnnewOpWrite(vars);
>
else
thrownewAnalis.Error(«Отсутствует ( воператоре write»);
>

intOpOrder(string op) // опеределениепорядка
<
switch (op)
<
case»<>«: case»=»: case» «: case»>=»:
return 0;
case»+»: case»-«: case»or»:
return 1;
case»*»: case»/»: case»and»:
return 2;
>
thrownewAnalis.Error(«Неизвестнаяоперация » + op);
>

publicNodeParseExpr() // разбороперацийспеременными
<
Exprexpr = newExpr();
Stack opOrder = newStack ();
Stack opName = newStack ();
while (true)
<
if (lexer.Type == LexAnalis.TypeLex.Constant)
<
string type = «!»;
if (lexer.Value.IndexOf(.) >= 0)
type = «%»;
expr.Append(1, lexer.Value, double.Parse(lexer.Value, CultureInfo.InvariantCulture.NumberFormat), type);
>
elseif (lexer.Type == LexAnalis.TypeLex.Ident)
<
int i = dimvars.IndexOf(lexer.Value);
if (i 0)
<
int o = opOrder.Pop();
string name = opName.Pop();
if (o == -1)
<
LP = true;
break;
>
expr.Append(0, name, 0, string.Empty);
>
if (!LP) break;
Next();
>
if (lexer.Type == LexAnalis.TypeLex.Separator)
<
int o = OpOrder(lexer.Value);
if (opOrder.Count> 0 &&opOrder.Peek() >= o)
<
opOrder.Pop();
expr.Append(0, opName.Pop(), 0, string.Empty);
>
opOrder.Push(o);
opName.Push(lexer.Value);
>
else
if (lexer.Type == LexAnalis.TypeLex.Operator)
break;
else
thrownewAnalis.Error(«Ожидаласьоперация , вместо » + lexer.Value);
>
else
if (lexer.Type == LexAnalis.TypeLex.Operator )
break;
else
thrownewAnalis.Error(«Ожидаласьоперацияилиразделитель, вместо » + lexer.Value);
Next();
>
while (opName.Count> 0)
expr.Append(0, opName.Pop(), 0, string.Empty);
returnexpr;
>
>

publicclassPrg : Node
<
Node block;
string name;

publicPrg(Node block, string name)
<
this.block = block;
this.name = name;
>
>

publicclassBlock : Node
<
List nodes;

public Block()
<
nodes = newList ();
>

publicvoid Append(Node node)
<
nodes.Add(node);
>
>

publicclassTypeVar : Node
<
List vars;
string type;

publicTypeVar(string type, List vars)
<
this.type = type;
this.vars = vars;
>

publicclassVar : Node
<
string name;
Nodeexpr;

publicVar(string name, Nodeexpr)
<
this.name = name;
this.expr = expr;
>

publicclassFor : Node
<
Node from;
Node to;
Node block;
public For(Node from, Node to, Node block)
<
this.from = from;
this.to = to;
this.block = block;
>

publicclassOpWhile : Node
<
Nodeexpr;
Node block;

publicOpWhile(Nodeexpr, Node block)
<
this.expr = expr;
this.block = block;
>
>

publicclassOpIf : Node
<
Nodeexpr;
NodeblockThen;
NodeblockElse;

publicOpIf(Nodeexpr, NodeblockThen, NodeblockElse)
<
this.expr = expr;
this.blockThen = blockThen;
this.blockElse = blockElse;
>

>
publicclassOpRead : Node
<
List vars;

Source Inside

Source Tools

1\\Valve\\Steam\\Steamapps\\Sourcemods\\ваш мод\\materialsrc\\models\\*.tga
Не забывайте указывать вместо слов «ваш мод» и «ваш аккаунт» свои аккаунт и название вашего мода!
Теперь сохраняем этот файл как texture.bat и запускаем его, после чего произойдёт конвертация текстуры из формата tga в формат vmt, в папке: C:\\program Files\\Valve\\Steam\\Steamapps\\Sourcemods\\ваш мод\\materials\\models появятся 2 файла:
taburetka.vmt и taburetka.vtf
С текстурой всё.
Возвращаемся в 3dsmax и создаём там кость, выбираем вкладку Systems, командной панели, тыкаем на bones и создаём одну кость.
Теперь о том как в максе присоединять кость к модели:

1 способ.
Веделяете всю модель и применяете к ней модификатор skin, нажимаете на кнопку add в свитке parameters:

и в окне указываете единственную кость. Далее жмём на кнопку Edit Envelopes, появятся контейнеры, как на рисунке, увеличиваем значение в поле radius… как видите из рисунка, я увеличил радиус и левая сторона табуретки окрасилась в красный цвет… далее выделяем квадратик с правой стороны табуретки и опять увеличиваем радиус, вся наша модель должна быть окрашена в красный цвет, вы также можете включить режим wireframe, чтобы увидеть сетку, на ней будут видны вертексы, точки этой модели.
Чтобы убедится в том, что наша модель полностью присоединена к кости, выделите эту кость и подвигайте, модель должна перемещаться вместе с костью.
2 способ.
Второй способ, на мой взгляд самый лёгкий:
Выделяете всю модель и нажимаете на кнопку Select and Link, в панели Main Toolbar, , далее наводите курсор на модель, зажимаете левую кнопку мыши и наводите курсор на кость (курсор примет другой вид), отпускаете. Всё кость присоединилась, можете это также проверить.
Ну и теперь осталось только сделать экспорт модели в формат smd.
Нажимаем File => Export и сохраняем как reference с именем taburetka.smd в папку с названием, mymodel, которая должна находится здесь: C:\\program Files\\Valve\\Steam\\Steamapps\\Sourcemods\\ваш мод
Настало время создать qc файл. В папке C:\\program Files\\Valve\\Steam\\Steamapps\\Sourcemods\\ваш мод\\mymodel создадим с помощью блокнота файл, в нём напишем это:

$cd «C:\\program Files\\Valve\\Steam\\Steamapps\\Sourcemods\\ваш мод\\mymodel» // Это путь к qc файлу
$modelname «mymod/taburetka.mdl» //здесь указываем название модели, а mymod это папка в которой будет лежать готовая модель, вы должны создать эту папку вручную, до компиляции, вот здесь: C:\\program Files\\Valve\\Steam\\Steamapps\\Sourcemods\\ваш мод\\models
$scale 1.0 // масштаб модели
$body «body» «taburetka.smd» // тут указываем наш smd
$cdmaterials «models/» // путь к текстуре
$surfaceprop «wood» // материал, из которого сделана модель
$sequence idle «taburetka» fps 30 aCT_iDLE 1 // тут указывают smd с анимацией, у нас её нет, поэтому мы используем наш единственный smd
$keyvalues < «prop_data» <"base» «Wooden.Medium» >// это модели того на что будет разлетаться основная модель, ну скажем если постоянно колотить эту модель гвоздодёром, то она разлетится, в данном случае, на деревянные щепки, другие виды осколков можно посмотреть в файле propdata в папке scripts.
$collisionmodel «taburetka.smd» // здесь указывается физическая модель, если указать основную модель то будет создан неправельный физбокс, ну например, между ножек табуретки не будут пролетать пули, поэтому нужно создавать правильный физбокс и писать здесь smd физбокса, об этом чуть позже.
<
// Mass in kilograms
$concave // эт я незнаю чё такое, кто знает пишите в комментах =))
$mass 2.0 // ну, а это масса модели в килограммах
>

Сохраняем этот файл как taburetka.qc

Примечание:
Если вы собираетесь компилировать статичную модель то надо заменить параметр:
$keyvalues
на
$staticprop

Теперь в папке: C:\\program Files\\Valve\\Steam\\Steamapps\\Sourcemods\\ваш мод
Создадим, с помощью блокнота, батник… в нём пишем:
C:\\progra

Гайд по декомпиляции моделей движка Source

MDL является собственным форматом моделей движка Source. Он определяет структуру модели, вместе с анимацией, ограничивающей коробкой, хит коробкой, материалами, и сеткой детализации модели (LOD). Сам по себе формат MDL не хранит всей необходимой информации о данной модели.

Дополнительные данные хранятся в PHY, ANI, VTX и VVD файлах, а иногда , в MDL файлах может храниться и анимация, которую используют несколько моделей т.е это общая библиотека анимации, которую могут использовать несколько моделей.

Такая вот история. Вам захотелось декомпилировать модельку, ну например вам нужен ее исходник что бы изменить его, поставить в другую игру, или же просто интересно что же внутри загадочного файла MDL

Приступаем к роботе.

Декомпилировать модели движка Source, можно с помощью программы MDLDecompiler.
MDLDecompiler это программа стороннего разработчика которая может получать исходники формата SMD из MDL файлов. Зашли вы значит в google скачали откуда то этот самый MDLDecompile, запустили, выбрали модельку, нажали кнопку Extract, и в лучшем случае получили ошибку «unable to load model», в худшем — программа просто крешнулася. Ваши емоции после геморного хождения по google в поисках хоть какой то инфы примерно такие , вы начинает задаваться вопросами , и биться головой об стену , потому что не понимаете, что этой программе еще от вас нужно
Пару секунд упорных стараний и вы повесили нос
Но не все так плохо, выход есть

К примеру будем декомпилировать модель breen’а из Half life 2
И так, разделю на пункты, так проще:

1)
Естественно нам нужно получить модель. Идем в SteamApps ищем файл source models.gcf :

открываем его с помощью GCF Scape,
ищем модель Брина , она тут

2)
Выделяем модель, и все ее (выше упомянутые) прилагаемые файлы

правый клик мышью, и извлекаем это все куда то на диск, у меня это будет диск D:\

3)
Смотрим, у нас 6 файлов(breen.dx80.vtx, breen.dx90.vtx, breen.mdl, breen.phy, breen.sw.vtx, breen.vvd) как раз все то, что нужны для декомпиляции, но может быть и по другому.

Важно! Возможные ошибки из за которых срывается компиляция.

I — Обращаем на файл формата .vtx у нас это breen.sw.vtx, а именно на пркладку sw, ее нужно удалить, потому что компиляция сорвется.
Для танкиста: после изменения это будет выглядеть вот так — breen.vtx.

II
— обращаем внимание на те же файлы формата .vtx, с прекладкой dx80, dx90 (сокращенно direct X 8.0, 9.0). Может быть так что будет либо dx80, либо dx90, а для компиляции нужно 2. Решаеться просто — делаем копию существующего, например breen.dx80.vtx, переименовываем, его в недостающего — breen.dx90.vtx.

В общем нужно помнить что для компиляции нужно 6 файлов:

1) Имя.dx90.vtx
2) Имя.dx80.vtx
3) Имя.dx80.mdl
4) Имя.phy
5) Имя.dx80.vtx
6) Имя.vvd

хоть и Имя.dx80.phy может и не быть(например у зараженных с Left 4 Dead), это не страшно . Тут вроде все.

4)

Самый важный момент. Исправления заголовка файла MDL. В основном на это этапе все кто не знают, частенько обламываються. Для редактирования нам понадобиться NotePad++ — очень офигенный текстовый редактор, который может сохранять файлы без изменения кодировки, а это очень важно.

Откроем этим чудом наш MDL файл.
Видим:

Видим закодированные данные в виде текста, и так обращаем внимание на заголовок IDST, , самый главный елемент тут кома, (если не ошибаюсь то это есть версия MDL файла), в даном случае тут все правильно — после IDST должна стоять кома. За месть ее может быть 1(как в Left 4 dead),0(HL 2 ep2), или еще что то. Что бы там не было, меняем этот символ на кому.
Жмем ctrl+s, закрываем notepad. Короче если не изменить этот символ(5 по счету), MDLDecompiler выдаст ошибку.

5)
Вот и дошли до компиляции.
Запускаем MDLDecompiler. Скачать его можно с офиц. сайта -> Cannonfodder’s Half-Life 2 Tools . Там есть 5 версий этой программы, качаем версию MDLDecompiler Version 0.4.1, она более стабильная, чем последняя — 5я.
Скачали — открыли архив извлекли от туда mdldecompiler.exe, и кинули в папку Source sdk ep1/bin, или же если у вас нету SSDK, Ставить его в лом, а исходник модельки нужно, я выложил этот компилятор из всем требуемыми модулями dll, который может обойтись без все папки bin.
Скачать можно с:

Опять же запустили mdldecompiler.exe, сняли чек бокс с «Use steam File Access»

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

Все прошло гладко исходник(и) получили:

Вот и все, процесс декомпиляции закончен. Имея исходники формата smd, вы можете работать с моделью в 3d пакетах таких как 3D’s Max, Maya,softimage mod tool XSI. И после скомпилировать модель по уже существующему qc файлу.
Вот он наш Брин:

Все. Надеюсь этот гайд поможет вам. Удачи

У Вас недостаточно прав для скачивания файлов.

Компиляторы C/C++ для встроенных систем

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

Основные сведения

Компания АстроСофт разрабатывает свой компилятор языков программирования C/C++ с 1999 года. К проекту привлекаются исключительно российские специалисты, на разработку потрачено в общей сложности более 170 человеколет. За это время созданы несколько пакетов средств разработки на базе компилятора UCC, которые используются в производственных процессах крупных промышленных компаний.

За счет архитектуры адаптация компилятора к новой платформе занимает около 2 месяцев в зависимости от сложности процессора и методов низкоуровневой оптимизации. Адаптация включает в себя настройку правил кодогенерации, в то время как основной исходный код компилятора остается неизменным.

  • оборонно-промышленный комплекс
  • системы безопасности и связи
  • авионика
  • приборо- и станкостроение
  • компьютерная периферия

Принципы работы

Первая фаза компиляции – Frontend позволяет произвести первичное преобразование программы в ее высокоуровневое древовидное представление. Одним из основных предназначений данного этапа компиляции является лексический и синтаксический разбор исходного кода и его абстрагирование от конкретного языка программирования. Компилятор поддерживает два Frontend: C и C++.

На следующем этапе проводится первичная оптимизация промежуточного представления.

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

В дальнейшем дерево промежуточного представления проходит фазу кодогенерации. На этой фазе применяются правила кодогенерационной модели, и дерево преобразуется к машиннозависимому виду. После этой фазы в узлах дерева остаются только инструкции и атрибуты, совместимые с целевым процессором. Над этим представлением проводятся дополнительные среднеуровневые оптимизации и распределение переменных на регистры/память в зависимости от настроек модели. Следующим этапом дерево промежуточного представления преобразуется в список ассемблерных инструкций целевой платформы, и над этим списком проводится серия низкоуровневых оптимизаций и прогон алгоритмов, заточенных под конкретную платформу.

В финале список ассемблерных инструкций преобразуется в ассемблерный файл, который передается на трансляцию целевому ассемблеру.

Архитектура

Основная идея компилятора UCC — вынос платформо-специфичных настроек и алгоритмов в отдельный модуль. Этот модуль может быть гибко настроен при помощи описания правил кодогенерации на специализированном языке.

Для этого в компилятор введено понятие промежуточного высокоуровневого представления программы, состоящего из узлов: команд и атрибутов «псевдопроцессора». Этот процессор содержит универсальный набор команд, бесконечное количество регистров и памяти.

Процесс разработки
История разработки компилятора АстроСофт
1999 — 2000
Разработка первой версии мультиплатформенного компилятора C.
2006-2010

Разработка и оптимизация модели процессора южнокорейской компании, предназначенного для медиаприложений.

Разработка новых специализированных методов высокоуровневой и низкоуровневой оптимизации.

2000-2001

Разработка C++ Frontend для мультиплатформенного компилятора.

2008-2010
Разработка и оптимизация модели процессора южнокорейской компании, предназначенного для смарт-карт.
2001-2002
Разработка модели для 32-битного стекового процессора шведской компании.
2011-2014
Поддержка и постоянные улучшения кодогенерационных моделей вышеуказанных процессоров.
2002-2003
Полный рефакторинг компилятора –
обновление платформы и алгоритмов.
Разработка и поддержка.
2012-2013
Разработка кодогенерационной модели для узкоспециализированного 32-битного RISC-процессора для контроллеров SSD-дисков крупнейшего в мире производителя чипов.
2004-2005
кодогенерационной модели для узкоспециализированного многоядерного процессора PRIME (задачи печати) для южнокорейской компании.
Настоящее время
Поддержка обновлённых стандартов языка и реализация новых оптимизаций кода.
Основные сведения

В случае, когда у заказчика нет ограничений по использованию зарубежных разработок и отсутствуют опасения насчет возможных изменений в лицензионной политике таких решений, подходящим вариантом может оказаться компилятор на основе LLVM – набора компиляторных технологий, упакованных в удобную модульную форму.

Стартовав в 2000 году как исследовательский проект Университета Иллинойса, на сегодняшний день LLVM де-факто является стандартом в качестве платформы для создания новых компиляторов и продолжает активно развиваться.

В отличие от компилятора GCC, LLVM не требует раскрытия исходных кодов создаваемых на его основе продуктов, что стимулирует его использование в коммерческих проектах.

АстроСофт обладает соответствующими компетенциями, имея опыт разработки специфических LLVM оптимизаций, а в 2020 году ведет несколько проектов по разработке полных LLVM-компиляторов.

Принципы работы

LLVM не является компилятором сам по себе, а скорее предоставляет инфраструктуру для его создания. Используя эту инфраструктуру, был создан компилятор Clang, на данный момент неотрывно связанный с LLVM и развивающийся параллельно. Сегодня, когда мы говорим LLVM, подразумеваем Clang, и наоборот. А разработка нового компилятора на базе LLVM обычно означает портирование на новую платформу компилятора Clang.

Clang создавался с целью замены GCC, который изначально рассматривался в качестве единственного фронт-энда для LLVM. Однако GCC по разным причинам оказался неудобен для некоторых разработчиков. Одной из веских причин стали лицензионные ограничения GCC, которые с появлением Clang были преодолены. Заинтересованность в проекте выразили такие известные компании, как Apple, ARM, Google, Microsoft, Intel и др.

Сам компилятор Clang (как и LLVM) разработан на языке С++, а поддерживаемыми языками стали C, C++, Objective-C, Objective-C++, OpenMP, OpenCL, CUDA.

Архитектура

Как мы уже выяснили, LLVM, по сути, является бек-эндом компилятора, фронт-эндом которого выступает Clang. Как правило, у разработчиков компиляторов на основе Clang/LLVM не возникает потребности модифицировать «ядро», и необходимыми знаниями в этом случае становятся:

  • общее понимание архитектуры LLVM;
  • владение языком внутреннего представления (LLVM IR, LLVM intermediate representation);
  • понимание организации мультиступенчатой оптимизации.
Резюме

Разработка компилятора на базе Clang/LLVM – хороший вариант для компаний, если ожидаемая выгода от постоянного развития «ядра» компилятора и широкий спектр поддерживаемых «из коробки» технологий перевешивают потенциальный риск, связанный с зависимостью от зарубежных решений и невозможностью влиять на направление развития базового функционала. АстроСофт предлагает свои компетенции в создании таких компиляторов. Если же потенциальные риски «перевешивают», мы предлагаем полностью российскую разработку – универсальный компилятор UCC.

Клиент

Транснациональная компания по производству микроэлектроники, потребительской электроники, промышленного и телекоммуникационного оборудования.

Решение

В качестве базы для проекта использовалась собственная разработка АстроСофт — продукт Universal C Compiler (UCC). В нем существует механизм разработки компилятора для новой платформы: реализовано построение кодогенерационной модели, которая настраивает внутренние алгоритмы генерации кода и позволяет конвертировать абстрактное внутреннее представление программы в ассемблерные инструкции целевой машины. С целью сокращения издержек было принято решение портировать ассемблер, линкер и симулятор заказчика на новую платформу.

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

Результат

Разработаны: компилятор С для нового узконаправленного процессора, а также ассемблер, линкер и симулятор для новой платформы.

Компилятор интегрирован и активно применяется заказчиком. Готов к использованию при разработке Flash и SSD-накопителей.

Технологии

Основное средство разработки — Универсальный компилятор C (UCC). Сборка компилятора осуществлялась при помощи MSVC 2010 и модифицированным Yacc. В качестве базы для других инструментальных средств использовались: ассемблер, линкер, симулятор компании-клиента. Для тестирования использовалась собственная система тестирования компиляторов АстроСофт — TestSuite (насчитывает более 25 тысяч тестов и синтезирует в себе признанные сторонние решения с наборами, разработанными сотрудниками компании).

Бесплатные компиляторы и интерпретаторы C / C++

C — это простой процедурный язык программирования общего назначения. Он достаточно прост в освоении. В то же время он мощный, чтобы его можно было использовать для создания любой компьютерной программы.

C++ — это объектно-ориентированный язык программирования, который изначально был создан как надмножество C . Языки C и C++ являются одними из самых популярных технологий, используемых для написания программ.

В этой статье перечислены бесплатные компиляторы C и C++ для различных операционных систем.

Бесплатные компиляторы и интерпретаторы C, C++ для компьютеров

Open Watcom V2 Fork

Он может работать и создавать исполняемые файлы под Windows ( 16-разрядные, 32-разрядные и 64-разрядные версии ), Linux ( 32-разрядные и 64-разрядные версии ), OS / 2 и MS-DOS ( 16-разрядные и 32-разрядные режимы ). Стоит пояснить, что Watcom — это был известный коммерческий компилятор, пока первоначальные разработчики не прекратили его продажи и не опубликовали исходный код ( в соответствии с публичной лицензией Sybase Open Watcom ).

Microsoft Visual Studio Community

Для индивидуальных или начинающих программистов Microsoft Visual Studio Community включает в себя много важных инструментов из коммерческих версий проекта. Вы получите в свое распоряжение IDE , отладчик, оптимизирующий компилятор, редактор, средства отладки и профилирования. С помощью этого пакета можно разрабатывать программы для настольных и мобильных версий Windows , а также Android . Компилятор C++ поддерживает большинство функций ISO C++ 11 , некоторые из ISO C++ 14 и C++ 17 . В то же время компилятор C уже безнадежно устарел и не имеет даже надлежащей поддержки C99 .

Программное обеспечение также поставляется с поддержкой построения программ на C# , Visual Basic , F# и Python . В то время, когда я писал эту статью, на сайте проекта утверждалось, что Visual Studio Community 2015 « бесплатный инструмент для индивидуальных разработчиков, проектов с открытым исходным кодом, научных исследований, образовательных проектов и небольших профессиональных групп ».

Clang: Фронтенд языка программирования C для LLVM

Clang — компилятор C , C++ , Objective C и Objective C++ , разработанный под Apple . Это часть проекта LLVM . Clang реализует различные стандарты ISO C и C++ , такие как C11 , ISO C++ 11 , C++ 14 и частично C++ 1z .

Он также поддерживает расширения, которые можно найти в семействе компиляторов C GNU . Компилятор C для Windows выпущен под лицензией BSD . К сожалению, на момент написания этой статьи, он предоставляется только в исходной форме, и вам придется собирать его самостоятельно.

MinGW-w64

Проект MinGW-w64 предоставляет библиотеки, заголовки, необходимые компиляторам C и C++ GNU для работы в системе Windows . В случае MinGW-w64 эти файлы поддержки позволяют создавать 64-битные программы в дополнение к 32-битным . Проект также предоставляет кросс-компиляторы, так что можно скомпилировать программу Windows из системы Linux .

AMD x86 Open64 Compiler Suite

Это версия набора компиляторов Open64 ( описанного ниже ), которая была настроена для процессоров AMD и имеет дополнительные исправления ошибок. Компилятор C / C++ соответствует стандартам ANSI C99 и ISO C++ 98 , поддерживает межъязыковые вызовы ( так как он включает в себя компилятор Fortran ), 32-битный и 64-битный код x86 , векторную и скалярную генерацию кода SSE / SSE2 / SSE3, OpenMP 2.5 для моделей с разделяемой памятью, MPICH2 для моделей с распределенной и разделяемой памятью; содержит оптимизатор, поддерживающий огромное количество оптимизаций ( глобальную, цикл-узел, межпроцедурный анализ, обратную связь ) и многое другое. Набор поставляется с оптимизированной AMD Core Math Library и документацией. Для этого набора компиляторов требуется Linux .

Компилятор C/C++ Open Source Watcom / Open Watcom

Является бесплатным компилятором для Windows 7 с открытым исходным кодом. Он генерирует код для Win32 , Windows 3.1 (Win16) , OS / 2 , Netware NLM , MSDOS ( 16-битный и 32-битный режим ) и т. д. Watcom был очень популярным компилятором несколько лет назад до тех пор, пока Sybase не закрыла его. Он также включает в себя довольно известный STLport ( реализация библиотеки стандартных шаблонов C++ ). Обновление: этот проект, похоже, застопорился, и в настоящее время запущен новый проект Open Watcom V2 Fork ( описан выше ).

Компилятор Digital Mars C/C++ (замена Symantec C++)

Digital Mars C / C ++ является заменой Symantec C++ с поддержкой компиляции программ для Win32 , Windows 3.1 , MSDOS и 32-разрядных расширенных MSDOS . Если используемый ПК не имеет процессора с плавающей запятой ( машины pre-Pentium ), можно связать эмуляцию с плавающей запятой в вашей программе. Компилятор поддерживает определение C++ из аннотированного руководства по C++ ( ARM ) и расширенные функции языка AT & T версии 3.0 , включая шаблоны, вложенные классы, вложенные типы, обработку исключений и идентификацию типа во время выполнения.

UPS Debugger (интерпретатор C)

Это графический отладчик уровня исходного кода для X Window , который содержит встроенный интерпретатор языка C . Он может обрабатывать один или несколько исходных файлов. Можно использовать его для создания исполняемого файла с байтовым кодом и выполнения интерпретатора в этом исполняемом файле. Если вам нужен интерпретатор для отладки или создания прототипов программ, или просто для изучения языка, попробуйте этот инструмент. Он поддерживает следующие платформы: Solaris , SunOS , Linux , FreeBSD , BSD / OS и некоторые другие Unix-платформы .

The BDS C Compiler

Помните старый ( популярный ) компилятор C BDS для систем CP / M 8080 / Z80 ? В настоящее время этот компилятор языка C находится в публичном доступе, в комплекте с исходным кодом языка ассемблера. Пакет представляет собой розничную версию компилятора с компоновщиком и руководством пользователя. Его можно использовать для простой генерации кода 8080/8085 / Z80 для встраиваемых систем ( то есть создавать собственные процедуры для замены любого кода библиотеки, который обращается к функциям операционной системы ).

Компилятор C / C++ Bloodshed Dev

Это интегрированная среда разработки Win32 , включающая в себя компилятор C++ egcs и отладчик GNU из среды Mingw32 . А также редактор и другие средства, облегчающие разработку программ с использованием компилятора Mingw32 gcc на платформе Windows . Он также содержит программу установки для приложений.

Компилятор C Orange

Он работает как в Windows , так и в DOS , имеет интегрированную среду разработки с редактором программ ( с подсветкой синтаксиса и автоматическим завершением кода ). Он может генерировать программы для Win32 и MSDOS , а также файлы Intel и Motorola hex ( что полезно, если вы пишете программы для встроенных систем ). Для вывода MSDOS ваши программы будут использовать расширитель DOS .

DeSmet C

DeSmet C должен быть знаком тем, кто программировал на C в 1980-х годах. Это компилятор C для MSDOS . Он был выпущен под лицензией GNU GPL и поставляется с руководствами, редактором и сторонним оптимизатором.

Apple Xcode для Mac OS X

Xcode — это интегрированная среда разработки Apple , которая включает в себя редактор с подсветкой синтаксиса, систему управления сборкой, отладчик, компилятор C GNU ( gcc ), конструктор интерфейса, AppleScript Studio , поддержку разработки на Java , инструменты разработки WebObjects . Чтобы получить в свое распоряжение данные инструменты необходимо быть участником Apple Developer Connection ( ADC ) . Но онлайн-членство является бесплатным.

Tiny C Compiler — самый компактный Linux C компилятор

Этот небольшой компилятор C для Linux и Windows генерирует оптимизированные двоичные файлы x86 . Утверждается, что он собирает, компонует и связывает код в несколько раз быстрее, чем GCC . В настоящий момент разработчики стремятся обеспечить соответствие ISO C99 . Компилятор также включает необязательную проверку границ. Он обрабатывает файлы скриптов C ( просто добавьте в Linux shebang код #!/usr/local/bin/tcc -run в первую строку исходного кода на C , чтобы он выполнялся напрямую ). TCC распространяется под лицензией GNU General Public License .

Portable Object Compiler

Это набор библиотек классов и компилятор Objective C , который преобразует код Objective C в простой C-код . Работает на Windows , Linux , OS / 2 , Macintosh и т. д.

C & C++ компиляторы Mingw32

Эта система поставляется с компилятором GNU C / C++ , который можно использовать для создания исполняемых файлов Win32 . Она содержит собственный , который находится в открытом доступе. Предполагается, что приложения, созданные с использованием этой системы, будут быстрее, чем, те которые созданы с помощью Cygwin32 , и они не ограничиваются положениями лицензии GNU . Mingw32 поставляется с инструментами для обработки текста ( sed, grep ), генератором лексического анализатора ( flex ), генератором парсеров ( bison ) и т. д. Mingw32 также поставляется с компилятором ресурсов Windows .

Компилятор C / C++ GNU

На странице компилятора C GNU можно получить ссылки на бинарные файлы и исходный код для компилятора GNU C . Также можно использовать приведенные в этой статье ссылки на наиболее часто запрашиваемые бинарные версии ( MSDOS и Win32 ).

Компилятор C Pelles

Еще один компилятор C , основанный на LCC ( смотрите также LCC-Win32 ). Он включает в себя компилятор C , компоновщик, компилятор ресурсов, сообщений, утилиту make и другие инструменты. Он компилирует код для Windows и Pocket PC .

Компилятор C Compaq

Пользователи Linux / Alpha теперь могут бесплатно скачивать и использовать компилятор Compaq , просто заполнив форму и приняв лицензионное соглашение. Компилятор может использоваться для генерации любых программ, коммерческих или иных. Он включает в себя математическую библиотеку и отладчик ( ladebug ), перенесенный из True64 Unix . Он поставляется с обычными справочными страницами, а также справочником по языку и руководством программиста.

Интерпретатор C / C++ Ch Embeddable (стандартная версия)

Интерпретатор C / C++ , поддерживающий стандарт ISO 1990 C ( C90 ), основные функции C99 , классы C++ , а также расширения к языку С , такие как вложенные функции, строковый тип и т. д. Он может быть встроен в другие приложения и аппаратные средства, использоваться в качестве языка сценариев. Код C / C++ интерпретируется напрямую без компиляции промежуточного кода. Поскольку этот интерпретатор поддерживает Linux , Windows , MacOS X , Solaris и HP-UX , созданный вами код можно перенести на любую из этих платформ. Стандартная версия бесплатна для личного, академического и коммерческого использования. Для загрузки пакета необходимо зарегистрироваться.

Компиляторы C и C++ DJGPP

Это система разработки, основанная на хорошо известном компиляторе C / C++ GNU . Она генерирует 32-разрядные исполняемые файлы MSDOS , которые являются файлами с длинными именами Windows 95 . Это очень функциональная система с IDE , графическими библиотеками, генераторами лексического анализатора ( flex ), генераторами парсеров ( bison ), утилитами обработки текста и так далее. Компилятор языка C , утилиты и библиотеки поставляются с исходным кодом.

Cilk — ANSI компилятор на основе C

Cilk — это язык на основе ANSI C , который может использоваться для многопоточного параллельного программирования. Это особенно эффективно для использования динамического, высоко асинхронного параллелизма в стиле параллельных данных или передачи сообщений. На официальном сайте упоминается, что Cilk уже используется для разработки трех шахматных программ мирового класса: StarTech , Socrates и Cilkchess .

Sphinx — компилятор C—

Это своего рода сочетание компилятора C и ассемблера, который позволяет « создавать программы с возможностями и читабельностью C , сохраняя при этом эффективность языка ассемблера ». Он может создавать исполняемые файлы MSDOS или файлы .OBJ , которые можно применять вместе с другими компоновщиками для создания исполняемого файла. По приведенной выше ссылке можно найти исходный код и документацию для компилятора. Если вы хотите получить предварительно скомпилированный бинарный файл, это можно сделать на неофициальном сайте компилятора C— Sphinx .

Компилятор C LSI C-86

Сайт этого компилятора написан на японском языке. Он выглядит как кросс-компилятор, позволяющий генерировать код для ROM . Старая версия компилятора ( 3.30c ) предоставляется бесплатно. Бесплатная версия работает только на MSDOS .

Кросс-компилятор C SDCC

Это кросс-компилятор C , предназначенный для микропроцессоров Intel 8051 , DS390, Z80, HC08 и PIC. Он также может быть переназначен для других 8-битных микроконтроллеров или ОСТО . SDCC поставляется с перенастраиваемым ассемблером и компоновщиком, отладчиком исходного уровня и симулятором. Библиотеки совместимы со стандартом C99 . Исходный код для компилятора доступен под лицензией GPL . Поддерживаются такие платформы, как Linux , Windows , Mac OS X , Alpha , Sparc и другие.

Компилятор C LADSoft CC386

Это компилятор ANSI C для MSDOS / DPMI и Win32 , который поставляется с библиотекой среды выполнения, компоновщиком, отладчиком, DOS-расширителем ( версия MSDOS ), IDE ( версия Win32 ) и утилитой make . Также доступен исходный код. При работе в режиме совместимости с C99 он компилирует большинство конструкций C99 .

Проект Cygwin (компиляторы C и C ++)

Этот «проект» включает в себя коммерческий компилятор ( GNU C / C++ ), который генерирует графический интерфейс Win32 и консольные приложения. Предоставляется исходный код компилятора, библиотек и инструментов. Обратите внимание, что опция по умолчанию в этом пакете требует от вас распространять исходный код, если вы компилируете и связываетесь со своими библиотеками. Существует также специальная вызываемая опция, которая задает возможность связи с альтернативными библиотеками, позволяя распространять свои приложения без источников.

Компилятор C LCC-Win32

Это компилятор C для Windows , который генерирует графический интерфейс Win32 и консольные приложения. Он поставляется со своим собственным компоновщиком, IDE , отладчиком, редактором и компилятором ресурсов. LCC- Win32 основан на компиляторе LCC и является бесплатным только для некоммерческого использования.

LCC — перенанаправляемый компилятор для ANSI C

LCC — это компилятор C ( только исходный код ), который генерирует код для Alpha , Sparc , MIPS R3000 и Intel x86 . Он является основой как минимум для двух других компиляторов Win32 C ( также описанных выше ).

Cyclone C

Cyclone C не является компилятором ANSI C в строгом значении, а представляет собой компилятор « безопасного диалекта » C . Он обеспечивает безопасность типов, имеет множество проверок для защиты от переполнения буфера, связанных с массивами нарушений и т. д. В настоящее время он работает на Linux и Windows ( в последнем случае через Cygwin ), для него требуется наличие в системе инструментов компиляции GNU .

Leonardo IDE

Это IDE на базе Macintosh , компилятор и отладчик для программ на C . Он включает в себя редактор с подсветкой синтаксиса, ANSI C компилятор, компилятор для языка визуализации ALPHA , редактор графов, обратимый виртуальный процессор и т. д.

Обратите внимание, что программы в код, который будет выполняться для виртуального ЦПУ. Виртуальная машина и отладчик позволяют выполнять код вперед и назад и поддерживать многозадачность. IDE поставляется с анимированными алгоритмами, примерами исходного кода таких игр, как Tetris , Checkers и других. IDE полезна для проверки и отладки исходного кода, поиска процессов, неэффективно использующих память и т. д.

Примечание: этот проект был прекращен.

Turbo C 2.01

Старый, но проверенный Turbo C 2.01 для DOS доступен бесплатно по решению новых владельцев Borland . Это был популярный компилятор C во времена MSDOS , известный своей быстрой сборкой, интегрированной средой разработки (« IDE ») и графической библиотекой ( DOS ).

Данная публикация представляет собой перевод статьи « Free C/C++ Compilers and Interpreters » , подготовленной дружной командой проекта Интернет-технологии.ру

Модельный компилятор

.qc сценарий — это простой текстовый файл или несколько файлов, созданных в любом простейшем текстовом редакторе и необходимых для того, чтобы cкомпилировать трёхмерную модель для игровых движков. Обычно для моделей достаточно собрать в одну папку все smd и bmp файлы, сам компилятор studiomdl, написать сценарий компиляции — qc-файл и запустить из командной строки:
studiomdl.exe НазваниеСценария.qc
и модель готова. Хотя для компилятора существуют дополнительные настройки для командной строки и даже создан графический интерфейс для управления ими, обычно запуска в командной строке достаточно. А сейчас рассмотрим команды сценариев компиляции главным образом для движка GoldSource, но и в более современных движках используется большинство перечисленных параметров и команд создания моделей.

Короче говоря, в статье собран список общих команд для компилятора studiomdl с параметрами, описанием и примерами. Начнём с основных:

$modelname
Эта команда сообщает studiomdl, как назвать и где поместить откомпилированную модель.
Пример для модели Gordon.mdl:
$modelname «C:\Half-Life\valve\models\player\Gordon.mdl»
Пример, указывающий только название модели и потому сохраняющий в текущую папку:
$modelname «shlang.mdl»

$cd
Эта команда указывает компилятору studiomdl текущую рабочую папку. Команда работает так же, как и в DOS’e команда «cd».
пример относительного пути в ту же папку, где находится и сам .qc файл:
$cd «.\»
пример абсолютного пути:
$cd «C:\Half-Life\valve\models\source\Gordon»

$cdtexture
Эта команда сообщает компилятору studiomdl, где расположены текстуры.
Пример абсолютного пути:
$cdtexture «C:\Half-Life\valve\models\source\Gordon\textures»
Пример относительного пути из текущей папки в подпапку textures:
$cdtexture «.\textures»

$externaltextures
Эта команда сообщает studiomdl, что нужно сохранять текстуры модели как отдельный *t.mdl файл. (Здесь под звёздочкой автоматически подставляется название модели, используемое в основном файле модели *.mdl). В руководстве «Modeling and Animating for Half-Life» рассказывают, что команда $externaltextures нужна тем моделям, которые часто вызываются движком, но не отображаются на экране, для них хранение текстур отдельно от сетки приведёт к ускорению отрисовки графики.
Пример:
$externaltextures
Также разработчики задумали эту команду для удобства замены текстур в некоторых моделях заменой выделенного файла *t.mdl, не трогая объёмные данные. Короче, сейчас эта возможность используется не часто.

$cliptotextures
Эта команда сообщает studiomdl компилировать ли текстуры с моделью. Она обычно используется с моделями игрока для дезматча.
пример:
$cliptotextures

$scale #
Масштаб модели больше или меньше. По умолчанию всегда равно 1.
пример, увеличивающий её в 1,2 раза:
$scale 1.2

$origin
Это смещения начала координат модели. Этот параметр нужен для точной настройки модели, если вы к примеру модель сделали выше 0 по координате Z, то вам надо обязательно указать насколько выше вы её поместили. В противном случае модель будет неправильно показыватся на экране. Внимание: после декомпиляции модели оружия из CS движения рук съезжают нафих совсем не туда куда нужно, а с помощью этой команды можно вернуть модель рук обратно не редактируя анимации.
пример коррекции по оси Z:
$origin 0 0 36

$eyeposition
Для ботов или монстров в одиночной игре нужно, чтобы сообщить игре, где глаза монстра находятся относительно начала координат модели. К примеру, из-за ошибочно низкого положения глаз он может не увидеть что-либо из-за приземистого блока, хотя модель выглядит выше блока раза в 4, а тут можно вправить ему зрение.
пример высоты глаз на уровне 65 единиц над землёй (грубо это на высоте 1,6 метра, если считать, что 40 ед. в 1 м):
$eyeposition 0 0 65

$bbox (мин по x) (мин по y) (мин по z) (макс по x) (макс по y) (макс по z)
Задаёт параллелепипед габаритов отображения сориентированный вдоль осей X, Y и Z. Он даёт знать графическому движку о протяжённости модели. Полезно задавать для крупных моделей, которые без него могут не отрисовываться, когда выглядывают из-за казалось бы некрупных препятствий. Часто этот параллелепипед отцентрирован по длине и ширине, когда (мин по x) = –(макс по x) и (мин по y) = –(макс по y). Также задаём полную высоту в (макс по z) при том, что низ на уровне пола, поэтому задаём (мин по z) = 0. На сайте valvesoftware.com пишут, что его также называют каркасом (англ. hull, но не clipping hull, т.е. это не то же самое, что и каркас границ столкновений).
Пример габаритов дерева высотой примерно 6 метров:
$bbox -48 -48 0 48 48 240

$cbox (мин по x) (мин по y) (мин по z) (макс по x) (макс по y) (макс по z)
Задаёт параллелепипед габаритов столкновений.
NB. Надо будет проверить, в его ли габариты упираешься в игре, когда модель вставляешь в игровую карту с помощью объекта cycler?
Пример объекта размером с человека:
$cbox -16 -16 0 16 16 72

$body [reverse]
Вторая по важности команда в сценарии. Это ссылка на .smd файл главной сеточной оболочки модели; базовая модель с текстурами. Известно, что в подавляющем большинстве игр тыльные стороны граней не прорисовываются для экономии ресурсов. Команда reverse обменивает лицевые и тыльные стороны граней и используется только в случае (!), если возникают проблемы при экспортировании из редакторов типа Blender или 3D MAX, когда нормали поверхностей шиворот навыворот, а модель ошибочно получается текстурами внутрь.
Пример:
$body studio «monster» reverse

$bodygroup
Команда позволяет вашей модели иметь взаимозаменяемые части. Для модели с N заменяемых частей у многих объектов monster. в редакторах карт можно задать параметр body, в значении которого указать номер части от 0 до N–1. Этот пример показывает, как сделать монстра, который может держать дробовик, винтовку MP5 или ничего. Не включайте .smd расширение.
Пример:
$bodygroup weapons
<
studio «shotgun»
studio «mp5»
blank
>

$texturegroup
Команда позволяет вашей модели иметь взаимозаменяемые текстуры. Этот пример показывает, как нормальные текстуры головы и тела могут быть заменены в игре кровавыми текстурами. Убедитесь, что включили .bmp расширение.
Пример предполагает, что на сеточной модели изначально есть текстуры body_normal.bmp и head_normal.bmp:
$texturegroup pain
<
< "body_normal.bmp" "head_normal.bmp" >
< "body_pain.bmp" "head_pain.bmp" >
>

$renamebone
Character Studio версии 2.x и старше использует другое названия для некоторых костей двуногого животного. Если вы смешиваете модели или мультипликации от более ранних версий, тогда они должны быть переименованы. Этой командой можно легко переименовать кости во время компиляции, вместо того чтобы переименовать их в каждом исходном .max файле.
пример:
$renamebone «Bip01 R Clavicle» «Bip01 R Arm»

$include
Чтобы включать в компиляцию другой .qc файл.
Пример:
$include «C:\Half-Life\valve\models\player\player_shared.qc»

$attachment
Задаёт определённую точку в пространстве, которая присоединяется к заданной скелетной вершине. Её задают для того, чтобы из её места воспроизводить различные эффекты, например такие, как отрисовка огня, спрайтов, искрение и т. д. Координаты задают удаление точки от скелетной вершины.
Пример:
$attachment 0 «Bip01 R Hand» 20 2 5

$controller
Эта команда позволяет игре управлять вращением осей модели, т.е. костей. Наиболее очевидный пример — вращение головы монстра, в примере 1. Команда позволяет игре вращать голову от -60 градусов до +60 по оси X. Пример 2 показывает как сделать контроллер рта, чтобы монстр мог говорить.
пример 1:
$controller 0 «Bip01 Head» XR -60 60
пример 2:
$controller mouth «Bone03» ZR 0 45

$hbox
Команда задаёт для костей модели hitbox’ы или по-понятному — габаритные параллелепипеды попаданий. Если звучит всё ещё сложновато, объясню подробно: в игровом движке GoldSource параллелепипеды попаданий отвечают за места получения урона моделью. Если они не заданы, то компилятор создаст их автоматически, но если вам нужно их редактировать, то легче не создавать хитбоксы заново, а сперва декомпилировать модель, исправить габариты в файле qc-сценария и снова её скомпилировать. Получившиеся хитбоксы вам покажут просмотрщики моделей типа Jed’s Half-Life Model Viewer или Half-Life Model Viewer 1.25 или даже в самой игре Half-Life, Counter-Strike или др. с помощью консольной команды r_drawentities 3 (отключить её действие можно командой r_drawentities 1).
Эта пара примеров показывает создание хитбоксов для ноги, если название костей (правой) ноги в модели Bip01 R Leg1 и Bip01 R Foot.
Пример:
$hbox 7 «Bip01 R Leg1» 0.31 -3.97 -2.84 17.60 3.94 2.97
$hbox 7 «Bip01 R Foot» -0.56 -2.34 -2.19 3.81 8.00 2.66

Примечание: действие команды r_drawentities 0 в консоли скроет все энтити, а её работа со значениями 1, 2 и 3 на иллюстрации:

$gamma
Задаёт коэффициент контрастности отображения текстур модели (иначе говоря, коэффициент γ ). По умолчанию этот коэффициент задаётся равным 1,8.
Пример, повышающий контрастность текстур модели до 3,2:
$gamma 3.2
А это пример влияния коэффициента контрастности на отображение модели гнома для значений 5, 3 и 1,8:

$sequencegroupsize
Это отделяет файлы скелетных анимаций от сеточной модели в меньшие файлы. Нужно для того, чтобы анимации загружались в память только когда необходимо, вместо того чтобы загружать их все. Это полезно для монстров с заданным сценарием анимаций. Правда современные компьютеры редко тяготятся подобными мелочами, так что можно не пользоваться, если только Вы не оптимизируете игру для мобильников.
Пример разбивания по 64 Кб:
$sequencegroupsize 64

Подробнее о параметрах команды $sequence [motion extraction] Этот параметр указывает оси по которым будет происходить перемешение модели при воспроизведении анимации. Наиболее общие параметры: X, Y, LX или LY, которые обозначают движения по x и y оси. LX и LY — для линейного движения. X и Y работают также как LX и LY. Это используется в движке GoldSource и в частности в игре Half-Life для того, чтобы перемещать монстра.

[fps ] Устанавливает скорость проигрывания кадров анимации в секунду («frames per second» как раз и значит число «кадров в секунду»).
пример: fps 15

[origin ] То же самое что и $origin но только применяется к данной анимации.
пример: origin 0 0 13

[scale ] то же самое что и $scale но только применяется к данному движению.
пример: scale 1.3

[loop] указывает, что анимация зациклена, т.е. будет проигрываться бесконечно до вызова следующего движения.
пример: loop

[frame ] Это ограничивает воспроизведение кадров движения.
пример: frame 5 10

[‘activity’ ‘multiplier’] Если у вас несколько движений к примеру выстрела из одного и того же оружия, то данная команда укажет игре, что данное движение воспроизводить нужно в 3 раза чаще, чем остальные.
пример:
ACT_RANGE_ATTACK2 3
подразумевается, что движение ACT_RANGE_ATTACK2 уже задано в программном коде объекта.

[‘rotate’] Поворачивает движение на заданный угол
Пример, поворачивающий задаваемое движение на четверть оборота:
rotate -90

События, которые может вызывать данная анимация. Параметр изменяет не очень много, но весьма полезен для создания различных эффектов. Пятитысячные события, т.е. которые начинаются с пятёрки — 5ХХХ обрабатываются клиентом игрового движка и потому важны для оформления модели в игре. События с 0ХХХ по 4ХХХ работают с сервером движка и обрабатывают более глобальные задачи вроде взаимодействий с командой или смены статуса объекта.
Важно то, что событиями 5ХХХ можно вызывать: воспроизведение звука, отображение спрайта в определённой точке, выброс искр или проделать ещё что-нибудь, если заранее запрограмировать то, что вам нужно.

Пример 1:
< event 5004 1 "weapons\shoot.wav" >
Случай 5004 — воспроизведение звука, начиная с 1 кадра. Впишите путь, начинающийся с папки вашего мода. Новички тут встретятся с небольшой заморочкой, которая описана после этого примера.

Пример 2:
< event 5001 1 "20" >
События 5001, 5011 и 5021 — для спрайтов, особенно огня и дыма из оружия. Этот пример запускает спрайт от штурмовой винтовки MP5, muzzleflash1.spr с системой координат в 1 кадре. «20» указывает, что спрайту # 0 масштаб будет увеличен в 2 раза. Ниже — перечень спрайтов с порядковыми номерами и описанием для чего они используются:

5A1: muzzleflash1.spr — MP5
51A1: muzzleflash2.spr — дробовик, пистолеты
52A1: muzzleflash3.spr — дротикомёт алиенгранта или «клешня»

Для спрайтов должна быть определена точка крепления, номер которой определяет предпоследняя цифра A. Случай 5001 делает так, чтобы начало координат спрайта было в $attachment 0, начало координат 5011-ых спрайтов — в $attachment 1 и начало координат 5021-ых — в $attachment 2 (и так можно назначать вплоть до 9 аттачмента).

Пример 3:
< event 5002 10 "5" >
Случай 5002 — для искр. Здесь это проигрывается относительно системы координат 10 и их размер увеличивается в 5 раз.

Пример 4:
< event 7 2 >
Это просто запускает случай # 7 к системе координат 2. Случаем 7 может быть всё что угодно, но оно должно быть задано в программном коде ИСКУССТВЕННОГО ИНТЕЛЛЕКТА монстра.

Пример 5:
< event 1003 20 "bigexplosion" >
Случай 1003 запускает некий механизм в карте под названием «bigexplosion» по отношению к системе координат 20.

И вот примеры команды $sequence:

Первый пример:
$sequence crouch_shoot_mp5 «crouch_shoot_mp5»
Очень простая команда содержащая в себе минимум, необходимый для того чтобы она работала. Crouch_shoot_mp5 — название анимации и «crouch_shoot_mp5» — файл анимации без .smd расширения.

Второй пример:
$sequence shoot «shoot» < < event 5001 1 "20" > < event 5004 1 "hks1.wav" >>
Этот пример использует такие события, чтобы показать работу спрайтов и звук стрельбы из оружия. Предполагается, что звук hks1.wav загружается игровым движком в заранее запрограммированном коде объекта (т.е. монстра, персонажа, устройства), в противном случае на картах, где используется эта модель нужно будет загружать звуковой файл через какой-нибудь объект, который позволяет загрузить произвольный звук, например, в Half-Life и CS обычно используют ambient_generic.

Не участвующие в компиляции комментарии в одну строчку, начинаются двумя косыми чертами // и пробелом за ними. Комментарии на целый абзац должны начинаться с символов косая черта и звёздочка /* , а заканчиваться наоборот звёздочкой и косой чертой */ .

Вот и всё что можно было сказать о содержании qc, далее опубликована пара примеров qc файлов с описанием каждой команды.

Пример самого простого файла:

// название будущей модели
$modelname «proba.mdl»

// файлы объёмной сетки и анимаций берутся из текущей папки
$cd «.\»

// файлы текстур берутся из текущей папки
$cdtexture «.\»

// векторная модель из файла proba_ref.smd
$body body «proba_ref»

// 1 однократная мультипликация (7 кадров/с) из файла idle1.smd
$sequence «idle1» «idle» fps 7

Пример для модели из игры Opposing-Force:

// название модели полного охранника из игры Opposing Force
$modelname «otis.mdl»
// путь к файлам модели
$cd «.\»
// путь к текстурам модели
$cdtexture «.\»
// масштаб 1:1
$scale 1.0

// координаты параллелепипеда отображения (полному человеку — большие габариты)
$bbox -17 -17 0 17 17 72
// координаты параллелепипеда столкновений
$cbox -16 -16 0 16 16 72

// высота глаз, как у всех человекоподобных
$eyeposition 0.000000 0.000000 63.000000

// файл модели otis_body_reference.smd
$body studio «otis_body_reference»

// группа подмоделей оружия
$bodygroup gun
<
// По умолчанию пистолет в кобуре берётся из файла сетки otis_reference_wgunnholster.smd
studio «otis_reference_wgunnholster»
// пистолет в руках
studio «otis_reference_wgun»
// в правой руке пончик
studio «otis_donut_reference»
>

// группа подмоделей голов
$bodygroup heads
<
// по умолчанию голова из файла otis_head_bald_wht2_reference.smd
studio «otis_head_bald_wht2_reference»
studio «otis_head_bald_wht_reference»
>

// 1 аттачмент на месте ствола, где рисуется спрайт огня
$attachment 0 «Bip01 R Hand» 12.000000 3.000000 4.500000

// 2 контроллера: может поворачиваться шея
$controller 0 «Bip01 Head» XR -60.000000 60.000000
// и открывается рот во время разговора
$controller mouth «Bone05» ZR 0.000000 45.000000

// 21 хитбокс, т.е. параллелепипед, воспинимающий повреждения
$hbox 3 «Bip01 Pelvis» -9.890000 -5.660000 -8.600000 2.940000 6.520000 6.790000
$hbox 6 «Bip01 L Leg» 0.000000 -5.920000 -4.000000 19.370001 3.780000 3.730000
// остальные не будем показывать, т.к. они автоматически будут созданы и так

// некоторые движения:
// повторяющееся движение холостого стояния с вызовом активности простоя ACT_IDLE (задано в коде) с параметром 50:
$sequence «idle1» «idle1» fps 15 loop ACT_IDLE 50
// движение холостого стояния 15 кадров/с с вызовом активности простоя ACT_IDLE (задано в коде) с параметром 1:
$sequence «idle2» «idle2» fps 15 ACT_IDLE 1
.
// повторяющееся движение ходьбы с поступательным сдвигом по X (LX) с вызовом активности ACT_WALK (также задано в коде) с параметром 1 и звуками шагов npc_step1.wav во время 3 кадра и npc_step3.wav во время 18 кадра:
$sequence «walk» «walk» LX fps 30 loop ACT_WALK 1
// повторяющееся движение бега со сдвигом по X с вызовом активности простоя ACT_RUN (задано в коде) с параметром 1 и звуками шагов npc_step2.wav во время 5 и npc_step4.wav во время 13 кадра:
$sequence «run» «run» LX fps 25 loop ACT_RUN 1
// движение стрельбы с вызовом активности дистанционной атаки ACT_RANGE_ATTACK1 (задано в коде) с параметром 1 и вспышкой на нулевом аттачменте спрайта muzzleflash1.spr, увеличенным в 21 раз, во время 2 кадра + событием 3 (задано в коде, вероятно звук хлопка и выброс гильзы) во время того же 2 кадра. Ещё важно отметить слияние двух движений из shootgun_blend1.smd, когда Отис стреляет под углом 50° вниз, и shootgun_blend2.smd когда стреляет под углом 50° вверх относительно горизонтального положения, их движок игры будет комбинировать в зависимости от положения цели:
$sequence «shootgun» «shootgun_blend1» «shootgun_blend2» blend XR -50 50 fps 25 ACT_RANGE_ATTACK1 1
.
// поворот налево с вызовом активности левого поворота ACT_TURN_LEFT (задано в коде) с параметром 1 :
$sequence «turnleft» «turnleft» fps 15 ACT_TURN_LEFT 1
// поворот направо с вызовом активности правого поворота ACT_TURN_RIGHT с параметром 1 :
$sequence «turnright» «turnright» fps 15 ACT_TURN_RIGHT 1
.
// движение 22 кадра/с, когда Отис машет рукой кому-нибудь:
$sequence «barn_wave» «barn_wave» fps 22
.

Спасибо человеку под псевдонимом Spider за описание команд компиляции на английском и разработчикам из компаний id Software и Valve за движок игры Half-Life и инструментарий.

Компилятор Си в одну инструкцию: обзор инструмента M/o/Vfuscator

M/o/Vfuscator компилирует программы в инструкции mov , и только в них. Инструмент ориентирован на язык Си и архитектуру процессора x86, но адаптивен и легко настраивается под другие языки и архитектуры.

Демонстрация

Компиляция функции, вычисляющей простые числа, с помощью M/o/Vfuscator в сравнении с GCC:

Язык Ассемблера

Граф потока управления

M/o/Vfuscator в действии

movcc prime.c -o prime

Пример поинтереснее

movcc nibbles.c -o nibbles -lncurses

Сборка

M/o/Vfuscator использует LCC в качестве препроцессора. Предлагаемый скрипт сборки автоматически загружает LCC, настраивает его конфигурацию для MOV и собирает M/o/Vfuscator.

Если вы проводите сборку на 64-битной системе, убедитесь, что у вас есть доступ к 32-битной стандартной библиотеке (например, apt-get install libc6-dev-i386 или yum install glibc-devel.i686 ).

Тестирование

Проверьте, что сборка произошла корректно, с помощью следующего скрипта:

Использование

Компилируйте программы как обычно.

Всю остальную необходимую информацию можно найти в репозитории проекта на GitHub.

Илон Маск рекомендует:  Что такое код gettempdrive
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL