Cursed Earth: HOWTO для программистов

[IDoL]

а, это какой-то вызов команд допосле сборки видимо... тут у меня тоже не работало, но я не пользовался какими-либо сборщиками (для небольших софтин они в принципе не нужны имхо, не считая стандартного makefile под линух), можно попробовать вызвать запуск батника - внутри батников переменные точно должны работать.
[right][snapback]40012[/snapback][/right]

Да, это уже вызов собраных спайков
Согласен, с батниками будет работать через переменные окружения с одной стороны.
Но с другой - надо или сразу много переменных - для пути к EI, для зоны, для флагов, или править для этого батники. Не нативно
Сам пользуюсь батниками, если под win из терминала тяну обновления из гит, сразу собираю и вызываю. Удобно. Но через атрибуты для Run не менее удобно выходит в итоге, если собирать и пускать из Code::Blocks.

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

[Guest]

Итак, проверил scons в Code::Blocks — решение волне работоспособное.
Однако Вам все же понадобится пройти шаги с получением исходного кода и установкой компилятора и scons.
Code::Blocks вы можете скачать по

Возможно также будет работать сборка со встроенным MinGW(без выполнения шага установки MinGW), но я не пробовал (если кто попробует и отпишется — было бы здорово).
Скачиваем, устанавливаем, выбираем workspace.

У нас 2 пути. Мы можем использовать несолько проектов (по совету Sagrer) или использовать таргеты. Эта заметка по использованию таргетов(т.к. большинство исходного кода едино), но Вы можете пойти другим путем через создание нескольких проектов по 1 для каждого спайка — это делается аналогично и в итоге получается примерно одинаково по удобству. Для scons [все же] присутствуют флаги для компиляции отдельных спайков.

Создаем новый проект “Empty Project” назовем его cursedearth. Подменяем путь “Folder to create project in” на C:dev. Убеждаемся, что “Resulting filename” будет содержать строку C:devcursedearthcursedearth.cbp. На самом деле, мы можем использовать для файла проекта любую директорию но так наиболее наглядно при работе с одним проектом. Next.
Тут мы создадим таргеты для релиза и дебага mprviewer`а. Конфигурации будут соответственно такими: mprviewer_debug и mprviewer_release. Очищаем опции с директориями результатов для обеих конфигураций. Finish.
В окне Management появился проект вложеный в наш workspace.

Вся последующая настройка уже выполнена для mprviewer и texviewer в  (файл проекта и Makefile). Вы можете разархивировать его в папку с созданым проектом замещая существующие файлы. Притом конфигурировать таргеты в этом случае не обязательно.
Однако аргументы для выполнения спайков расчитаны на то, что ресурсы игры лежат в папке “EI” в рабочей папке проекта (например C:devcursedearthEI — путь к EI относительный). Следовательно Вы можете или изменить аргументы или добавить ресурсы в папку EI. Еслы вы создаете папку EI не забудьте добавить ее в исключения git, в дополнение к остальным исключениям(см. ниже).

Выберем его и добавим файлы проекта Правая кнопка → “Add files recursively...”. Тут выберем папку в которой находятся все наши файлы (C:devcursedearth). По умолчанию выбрана папка проекта, так что если Вы создали проект в папке с исходном кодом жмем OK выбираем все файлы Select All, OK, выбираем все таргеты Select All, OK. Т. к. Code::Blocks не обращает внимание на то, какие файлы находятся в папке с проектом, нам будет необходимо выполнять эти действия каждый раз при появлении новых файлов с исходным кодом — или просто после обновления из git(частично будут бесполезно выполненые действия, но будет так же и уверенность что ничего не пропустили).
Лезем в настройки проекта “Project” → “Properties”.
Во вкладке “Project settings” установим флажок “This is a custom Makefile”.
Во вкладке “Build Targets” для mprviewer_debug установим “Output filename” во чтото вроде

Код:

spikesmprviewerbini386-win32-mingwdebugmprviewer.exe

в зависимости от архитектуры и платформы.  Снимем флажки “Auto-generate filename prefix” и “Auto-generate filename extension”. Для mprviewer_release - 

Код:

spikesmprviewerbini386-win32-mingwreleasemprviewer.exe

и снимем те же флажки.
Следующие действия необходимо будет выполнять при появлении новых спайков (если Вы выбрали работать с таргетами). Здесь будет рассмотрено создание таргетов для texviewer.
В панели “Build Targets” выбираем и создаем копии для mprviewer_debug и mprviewer_release кнопкой Duplicate, называя их texviewer_debug и texviewer_release. И подменим “Output filename” в дублированых таргетах на

Код:

spikestexviewerbini386-win32-mingwdebugtexviewer.exe

и

Код:

spikestexviewerbini386-win32-mingwreleasetexviewer.exe

соответственно. Жмем ОК.
Создадим в папке C:devcursedearth файл с именем Makefile(без расширения) со следующим содержанием:

Код:

all:
    scons

mprviewer_release:
    scons mprviewer
mprviewer_debug:
    scons RELEASE=0 mprviewer
cleanmprviewer_release:
    scons mprviewer -c
cleanmprviewer_debug:
    scons RELEASE=0 mprviewer -c

texviewer_release:
    scons texviewer
texviewer_debug:
    scons RELEASE=0 texviewer
cleantexviewer_release:
    scons texviewer -c
cleantexviewer_debug:
    scons RELEASE=0 texviewer -c

Для каждого нового спайка Вам понадобится создать новую секцию(при использовании таргетов). Для нескольких проектов Вы можете использовать несколько Makefile`ов а можете один, но тогда Вам придется называть таргеты примерно так же как в этой заметке.
Сейчас мы можем попробовать, что у нас получилось используя Build(шестеренка) и Run(синий треугольник) или сразу Build and Run(шестеренка с красным треугольником).
Нам покажется экран с помощью по спайку, где будут описаны правила использования и аргументы. Закрываем появившуюся командную строку.
Теперь нам необходимо передать аргументы для собраных файлов. “Project” → “Set programs' arguments...”. В появившемся окне для обоих таргетов mprviewer вставим в текстбокс “Program Arguments” нечто вроде

Код:

-s 0.5 -f -b "C:EI" zone13

Для таргетов texviewer -

Код:

-d 50 "C:EIRestextures.res"

Для новых спайков смотрите аргументы показаные в командной строке, при вызове без аргументов.
Учтите что после добавлении строки с аргументами для таргета необходимо нажать на ОК. После этого придется заново вызвать окно для задания аргументов.
Теперь спомощью Run вызывается спайк с необходимыми аргментами.
Сохраним проект.
Не забывайте закрывать командную строку после завершения работы спайка.
Так же не забываем добавить в C:devcursedearth.gitinfoexclude строчки:

Код:

Makefile
*.cbp
*.layout

Ну вот наверное и все.
[right][snapback]40000[/snapback][/right]

[Guest]

Проделал все вышесказанное, но выдает ошибку:
"cursedearth - mprviewer_debug" uses an invalid compiler. Skipping...
Nothing to be done.
По всей видимости компилятор не тот?

[IDoL]

Первый вопрос под чем собираете?
Далее вопросы основаны на предположении что используете Windows

MinGW(компилятор gcc для Win) устанавливали отдельно (пользовались ли моей сборкой? прописали ли пути в переменную окружения Path?) или вместе с Code::Blocks?

Если установлен MS Visual C возможно Code::Blocks подхватил его. Посмотрите в Project -> Build Options в самом верху окна "Selected compiler" выбран ли там "GNU GCC Compiler".

Установлен ли Python и scons, прописали ли пути в переменную окружения?

Пользовались моим проектом или сами выполняли инструкцию?

[Guest]

Да, стоит MS Visual C. но компилятор прописан именно вышесказанный.
ВОт с Питоном и сконсом хуже.
ПОльзовался и вашим и своим.
Я не вник про PATH для питона,
"Добавляем в конец переменной стреды PATH "
Но scons установлен.
И еще один шаг не пошел:
"Итак система сборки и компилятор готовы. Через командную строку в папке C:devcursedearth выполним команду CODEsconsи получим готовые исполняемые файлы."

[IDoL]

Если проверки gcc, python и scons (из первого поста темы) выполняются и так то проблема не в этом

Переменные окружения прописываются так (для WinXP):

Правая кнопка мыши на "Мой компьютер" -> "Свойства" -> вкладка "Дополнительно" -> кнопка "Переменные среды"
В появившемся окне в переменных среды пользователя или в системных (лично я делаю в системных чтобы было доступно всем пользователям). Ищем переменную PATH (в переменных пользователя может не быть тогда создаем)
Выбираем, жмем кнопку "Изменить". В значении переменной уже будет несколько записей(разделенных точкой с запятой без пробела), например(скорее всего будет больше)

Код:

C:WindowsSystem32;C:Windows

в итоге при установке MinGW, Python и scons нам необходимо будет в конец этой строки(НЕ удаляя уже существующие там значения!!!) дописать

Код:

;C:mingwbin;C:Python26;C:Python26Scripts

чтобы в итоге значение было равно

Код:

C:WindowsSystem32;C:Windows;C:Program FilesGitbin;C:mingwbin;C:Python26;C:Python26Scripts

OK -> OK -> OK

можем проверить - в командной строке(Пуск -> Программы -> Стандартные -> Командная строка) написать

Код:

echo %PATH%

В результате будет комбинированая строка из системных и пользовательских переменных(если пользовательских нет то покажутся только системные)

так же советую выполнить проверки scons, python, gcc из папки с проектом (cd C:devcursederth для перехода в папку проекта)

Код:

gcc -v
python -V
scons -v

результаты в первом посте темы. Главное чтобы все обнаружил.


"Итак система сборки и компилятор готовы. Через командную строку в папке C:devcursedearth выполним команду scons и получим готовые исполняемые файлы."

это вызов сборки из командной строки. выполняется из папки с проектом (cd C:devcursederth для перехода в папку проекта) так же как проверки - в командной строке.

[Sagrer]

Но с другой - надо или сразу много переменных - для пути к EI, для зоны, для флагов

зачем столько много? Я пока хз что такое "зона и флаги" (э, не флаги ли для компиляторалинкера? Если да то зачем, можно же жёстко забить?), но мне лично требовались только пути к библиотекам или утилитам-зависимостям - скажем, где искать wxWidgets или где лежит архиватор 7zip или сборщик инсталлеров вроде нульсофта или Inno - все остальное вроде куда ложить собранные экзешники например - вычислялось через относительные пути от текущего каталога.

Я так понимаю что тут вообще никаких зависимостей нет кроме пути к ПЗ, т.е. хватило бы и одной переменной. Или даже написать простенький экзешник на чистом WinAPI который бы вынимал путь к ПЗ из реестра и возвращал его на стандартный выход (но это уже из области извращений) %).

[IDoL]

Нет для сборки никаких дополнительных флагов не надо. Так же как знать путь к ПЗ.
Это флаги и атрибуты вызова. Например mprviewer вызывается так

Код:

mprviewer -s 0.5 -f -b "C:EI" zone13

-s 0.5 атрибут скорости смены времени суток
-f флаг полноэкранного режима
-b "C:EI" атрибут папки ПЗ - здесь должна быть переменная. Если -b нет то ищет в папке с проекта
zone13 зона которую смотрим. единственный обязательный атрибут.
у texviewer соответственно подругому.
Так что жестко прошить не получится. А через редактирование .bat вызывать будет, думаю, не лучше чем через правку атрибутов, а хуже...

[Sagrer]

дык, это же GUI-шная софтина, разве нельзя хранить настройки софтины (тот же путь к игре) в конфиге (тот же *.ini) а открывать файлы через стандартный диалог-открывалку? %).

Так что жестко прошить не получится. А через редактирование .bat вызывать будет, думаю, не лучше чем через правку атрибутов, а хуже...

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

[Guest]

Ребята, может я и нуб, но у меня по прежнему не работает компиляция.
"cursedearth - mprviewer_release" uses an invalid compiler. Skipping...
Nothing to be done.
+ SCONS в папке cursedearth выполнилась с ошибками, не находит файлы в сборке.

[Guest]

Простите, добавлюсь:
Определяет в папке версию scons, питона, но gcc -v :не находит, говорит мол не внутренняя команда...

[IDoL]

Если не находит gcc, убедитесь что установили MinGW и правильно прописали путь (C:mingwbin по-умолчанию при установке) в переменную окружения Path.

[Guest]

Спасибо, разобрался, не находил gcc

[IDoL]

2 Guest
Рад, что смог помочь.

дык, это же GUI-шная софтина, разве нельзя хранить настройки софтины (тот же путь к игре) в конфиге (тот же *.ini) а открывать файлы через стандартный диалог-открывалку? %).
имхо забивать флаги запуска в переменные окружения ещё хуже чем писать это в bat-файл, по крайней мере батник уж точно проще отредактировать. А вообще я когда отлаживал консольный софт - просто жёстко забивал все флаги запуска прямо в настройки проекта (там где выбирается чего запускать для отладки) - оно требуется только на момент отладки, по-хорошему дефолтный запуск софтины не должен требовать указать ей чего открывать и с какими параметрами - по крайней мере в вендах всегда достаточно тупо даблкликнуть по экзешке - если какие-то параметры её в самом деле нужны - их можно вынуть либо из реестра либо из конфигов.
[right][snapback]40021[/snapback][/right]

Используется GLUT для создания простейшего окна с OpenGL контекстом. Никаких меню и чтения файла настроек.
Минимальное количество кода для проверки(!) правильности разбора игровых ресурсов.
Это не планируемый результат работы, а некоторая демка для разработчиков.
Тоесть добавление GUI именно в эту демку не планируется. Да это и не имеет особого смысла.
Я так же выполняю проверку из под win жестко пробитым батником. Переменные окружения не используются. В то же время редактировать батники, чтобы поиграться... По-моему гораздо проще отредактировать аргументы запуска в IDE, если под ним проект открывать?

[v1s0r]

Минимальное количество кода для проверки(!) правильности разбора игровых ресурсов.
Это не планируемый результат работы, а некоторая демка для разработчиков.
Тоесть добавление GUI именно в эту демку не планируется. Да это и не имеет особого смысла.
[right][snapback]40026[/snapback][/right]

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

Мда, на винде ставить тяжело, судя по размеру этой темы. Самое неочевидное - это, видимо, mingw. Самое главное - скачайте все файлы (ссылки выше) и распакуйте в одну папку + c:mingw в переменную окружения PATH.

Добавлю по поводу scons: если винда пишет, мол, scons не найден, добавьте в PATH что-то типа c:python2.6Scripts (посмотрите, как точно папка называется, в ней должен лежать scons.bat).

П.С. Кросс-компилятор для винды на линуксе ставится проще

[IDoL]

Да, вообще про пути расписал(в первом сообщении темы). Надо было наверное поподробнее остановиться как их добавлять в переменные окружения (и какие они по умолчанию).

На самом деле последние сообщения в большинстве своем посвящены тому, как облегчить вызов спайков из code::blocks

[v1s0r]

От меня огромная благодарность IDoL за проделанную работу. Без него хз что бы было со сборкой под win. А ведь многие именно там и работают...

[IDoL]

Рад помочь

[Guest]

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

[ALtair]

Это наша особая, уличная магия..