Sagrer,Понедельник, 15 Февраля 2010, 23:19 Написал:а, это какой-то вызов команд допосле сборки видимо... тут у меня тоже не работало, но я не пользовался какими-либо сборщиками (для небольших софтин они в принципе не нужны имхо, не считая стандартного makefile под линух), можно попробовать вызвать запуск батника - внутри батников переменные точно должны работать.
[right][snapback]40012[/snapback][/right]
Да, это уже вызов собраных спайков
Согласен, с батниками будет работать через переменные окружения с одной стороны.
Но с другой - надо или сразу много переменных - для пути к EI, для зоны, для флагов, или править для этого батники. Не нативно
Сам пользуюсь батниками, если под win из терминала тяну обновления из гит, сразу собираю и вызываю. Удобно. Но через атрибуты для Run не менее удобно выходит в итоге, если собирать и пускать из Code::Blocks.
Можно конечно попробовать батники, которые будут передавать спайку свои атрибуты. Но это похоже на извращение. Придется писать в них какойто парсинг хоть и элементарный.
IDoL,Пятница, 12 Февраля 2010, 12:47 Написал:Итак, проверил 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
Код:
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
Сейчас мы можем попробовать, что у нас получилось используя Build(шестеренка) и Run(синий треугольник) или сразу Build and Run(шестеренка с красным треугольником).
Нам покажется экран с помощью по спайку, где будут описаны правила использования и аргументы. Закрываем появившуюся командную строку.
Теперь нам необходимо передать аргументы для собраных файлов. “Project” → “Set programs' arguments...”. В появившемся окне для обоих таргетов mprviewer вставим в текстбокс “Program Arguments” нечто вроде
Код:
-s 0.5 -f -b "C:EI" zone13
Код:
-d 50 "C:EIRestextures.res"
Учтите что после добавлении строки с аргументами для таргета необходимо нажать на ОК. После этого придется заново вызвать окно для задания аргументов.
Теперь спомощью Run вызывается спайк с необходимыми аргментами.
Сохраним проект.
Не забывайте закрывать командную строку после завершения работы спайка.
Так же не забываем добавить в C:devcursedearth.gitinfoexclude строчки:
Код:
Makefile
*.cbp
*.layout
Ну вот наверное и все.
[right][snapback]40000[/snapback][/right]
Проделал все вышесказанное, но выдает ошибку:
"cursedearth - mprviewer_debug" uses an invalid compiler. Skipping...
Nothing to be done.
По всей видимости компилятор не тот?
Первый вопрос под чем собираете?
Далее вопросы основаны на предположении что используете Windows
MinGW(компилятор gcc для Win) устанавливали отдельно (пользовались ли моей сборкой? прописали ли пути в переменную окружения Path?) или вместе с Code::Blocks?
Если установлен MS Visual C возможно Code::Blocks подхватил его. Посмотрите в Project -> Build Options в самом верху окна "Selected compiler" выбран ли там "GNU GCC Compiler".
Установлен ли Python и scons, прописали ли пути в переменную окружения?
Пользовались моим проектом или сами выполняли инструкцию?
Да, стоит MS Visual C. но компилятор прописан именно вышесказанный.
ВОт с Питоном и сконсом хуже.
ПОльзовался и вашим и своим.
Я не вник про PATH для питона,
"Добавляем в конец переменной стреды PATH "
Но scons установлен.
И еще один шаг не пошел:
"Итак система сборки и компилятор готовы. Через командную строку в папке C:devcursedearth выполним команду CODEsconsи получим готовые исполняемые файлы."
Если проверки
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
можем проверить - в командной строке(
Пуск -> Программы -> Стандартные -> Командная строка) написать
В результате будет комбинированая строка из системных и пользовательских переменных(если пользовательских нет то покажутся только системные)
так же советую выполнить проверки
scons, python, gcc из папки с проектом (
cd C:devcursederth для перехода в папку проекта)
Код:
gcc -v
python -V
scons -v
результаты в первом посте темы. Главное чтобы все обнаружил.
"Итак система сборки и компилятор готовы. Через командную строку в папке C:devcursedearth выполним команду scons и получим готовые исполняемые файлы."
это вызов сборки из командной строки. выполняется из папки с проектом (
cd C:devcursederth для перехода в папку проекта) так же как проверки - в командной строке.
Цитата:Но с другой - надо или сразу много переменных - для пути к EI, для зоны, для флагов
зачем столько много? Я пока хз что такое "зона и флаги" (э, не флаги ли для компиляторалинкера? Если да то зачем, можно же жёстко забить?), но мне лично требовались только пути к библиотекам или утилитам-зависимостям - скажем, где искать wxWidgets или где лежит архиватор 7zip или сборщик инсталлеров вроде нульсофта или Inno - все остальное вроде куда ложить собранные экзешники например - вычислялось через относительные пути от текущего каталога.
Я так понимаю что тут вообще никаких зависимостей нет кроме пути к ПЗ, т.е. хватило бы и одной переменной. Или даже написать простенький экзешник на чистом WinAPI который бы вынимал путь к ПЗ из реестра и возвращал его на стандартный выход (но это уже из области извращений) %).
Нет для сборки никаких дополнительных флагов не надо. Так же как знать путь к ПЗ.
Это флаги и атрибуты вызова. Например
mprviewer вызывается так
Код:
mprviewer -s 0.5 -f -b "C:EI" zone13
атрибут скорости смены времени суток
-f флаг полноэкранного режима
-b "C:EI" атрибут папки ПЗ - здесь должна быть переменная. Если -b нет то ищет в папке с проекта
zone13 зона которую смотрим. единственный обязательный атрибут.
у
texviewer соответственно подругому.
Так что жестко прошить не получится. А через редактирование .bat вызывать будет, думаю, не лучше чем через правку атрибутов, а хуже...
дык, это же GUI-шная софтина, разве нельзя хранить настройки софтины (тот же путь к игре) в конфиге (тот же *.ini) а открывать файлы через стандартный диалог-открывалку? %).
Цитата:Так что жестко прошить не получится. А через редактирование .bat вызывать будет, думаю, не лучше чем через правку атрибутов, а хуже...
имхо забивать флаги запуска в переменные окружения ещё хуже чем писать это в bat-файл, по крайней мере батник уж точно проще отредактировать. А вообще я когда отлаживал консольный софт - просто жёстко забивал все флаги запуска прямо в настройки проекта (там где выбирается чего запускать для отладки) - оно требуется только на момент отладки, по-хорошему дефолтный запуск софтины не должен требовать указать ей чего открывать и с какими параметрами - по крайней мере в вендах всегда достаточно тупо даблкликнуть по экзешке - если какие-то параметры её в самом деле нужны - их можно вынуть либо из реестра либо из конфигов.
Ребята, может я и нуб, но у меня по прежнему не работает компиляция.
"cursedearth - mprviewer_release" uses an invalid compiler. Skipping...
Nothing to be done.
+ SCONS в папке cursedearth выполнилась с ошибками, не находит файлы в сборке.
Простите, добавлюсь:
Определяет в папке версию scons, питона, но gcc -v :не находит, говорит мол не внутренняя команда...
Если не находит gcc, убедитесь что установили MinGW и правильно прописали путь (C:mingwbin по-умолчанию при установке) в переменную окружения Path.
Спасибо, разобрался, не находил gcc
2 Guest
Рад, что смог помочь.
Sagrer,Четверг, 18 Февраля 2010, 14:59 Написал:дык, это же GUI-шная софтина, разве нельзя хранить настройки софтины (тот же путь к игре) в конфиге (тот же *.ini) а открывать файлы через стандартный диалог-открывалку? %).
имхо забивать флаги запуска в переменные окружения ещё хуже чем писать это в bat-файл, по крайней мере батник уж точно проще отредактировать. А вообще я когда отлаживал консольный софт - просто жёстко забивал все флаги запуска прямо в настройки проекта (там где выбирается чего запускать для отладки) - оно требуется только на момент отладки, по-хорошему дефолтный запуск софтины не должен требовать указать ей чего открывать и с какими параметрами - по крайней мере в вендах всегда достаточно тупо даблкликнуть по экзешке - если какие-то параметры её в самом деле нужны - их можно вынуть либо из реестра либо из конфигов.
[right][snapback]40021[/snapback][/right]
Используется GLUT для создания простейшего окна с OpenGL контекстом. Никаких меню и чтения файла настроек.
Минимальное количество кода для проверки(!) правильности разбора игровых ресурсов.
Это не планируемый результат работы, а некоторая демка для разработчиков.
Тоесть добавление GUI именно в эту демку не планируется. Да это и не имеет особого смысла.
Я так же выполняю проверку из под win жестко пробитым батником. Переменные окружения не используются. В то же время редактировать батники, чтобы поиграться... По-моему гораздо проще отредактировать аргументы запуска в IDE, если под ним проект открывать?
IDoL,Thursday, 18 February 2010, 21:28 Написал:Минимальное количество кода для проверки(!) правильности разбора игровых ресурсов.
Это не планируемый результат работы, а некоторая демка для разработчиков.
Тоесть добавление GUI именно в эту демку не планируется. Да это и не имеет особого смысла.
[right][snapback]40026[/snapback][/right]
Совершенно верно. Набор консольных демок нужен для разработки, тестирования, исследования ресурсов. Ну и заодно как промежуточные результаты работы.
Мда, на винде ставить тяжело, судя по размеру этой темы. Самое неочевидное - это, видимо, mingw. Самое главное - скачайте все файлы (ссылки выше) и распакуйте в одну папку + c:mingw в переменную окружения PATH.
Добавлю по поводу scons: если винда пишет, мол, scons не найден, добавьте в PATH что-то типа c:python2.6Scripts (посмотрите, как точно папка называется, в ней должен лежать scons.bat).
П.С. Кросс-компилятор для винды на линуксе ставится проще
Да, вообще про пути расписал(в первом сообщении темы). Надо было наверное поподробнее остановиться как их добавлять в переменные окружения (и какие они по умолчанию
).
На самом деле последние сообщения в большинстве своем посвящены тому, как облегчить вызов спайков из code::blocks
От меня огромная благодарность IDoL за проделанную работу. Без него хз что бы было со сборкой под win. А ведь многие именно там и работают...
Рад помочь
Может быть вопрос не в тему, но всеже...
Я вот читал много постов, от разных пользователей этого сайта и пока что только v1s0r выложил опенсоурс своего проекта, за что очень благодарен ему, ибо многие вещи, при разработки собственных утилит, я только сейчас познал в его коде.
Но тема не в этом, я хотел бы спросить уже бывалых волков данного портала и самого v1s0r, всю необходимую информацию о форматах, структуре файлов и вообще принцыпа работы движка самой игры вы узнаете путем дисасеблинга или как то по другому?
Это наша особая, уличная магия..