Скачал и опробовал "невидимый луч смерти" - классная штука!

Ещё сильнее усложняет игру - если раньше можно было ориентироваться и искать цели по лучам от ботов, то теперь враги могут подкрасться совершенно незаметно на фоне тёмного неба, даже если будут вести пальбу со всех стволов.

Вот такие пакеты и меняют кардинально вид игры. А самое интересное - какое простое и изящное техническое решение!

В принципе, можно пойти и дальше - в таблице настройки звуков "customsounds.plist" отключить звуки собственного лазера и попадания своим лазером по вражеским целям. Вот тут уж действительно будет полный реализм - невидимая война в полном безмолвии (пока враг не начнёт резать твою обшивку - тут уже будет слышно).

Если кто интересуется - для примера можно скачать мой пакет "Tch_Customsounds_01_1.0.0_2013-01-20.oxp" и посмотреть, как устроена такая таблица звуков, как сделана озвучка в игре и как полностью поменять дистрибутивные звуки на свои собственные. Там у меня подробные комментарии на русском языке.

To Tch
Рад, что понравилось!
Самое забавное, что это Ваш же совет рикошетом к Вам вернулся. Помните, Вы подсказали vasig, как отключить сообщение Press Space commander не редактируя файлы в дистрибутиве?
И кстати, Владимир Петрович, с нетерпением жду продолжение мастер-класса по работе с библиотекой функций.

P.S. А у нас с Вами годовщина на носу! Как раз где-то год назад Вы на форуме объявились. А я 5 декабря свой первый пакет на общий суд выложил на этом форуме.

Для stranger.

Я сейчас экспериментирую с текстурами и столкнулся с такой проблемой - при переводе прямоугольной проекции в кубическую теряется чёткость изображения, и очень существенно.

Вот как выглядит в Игре прямоугольная текстура с разрешением 4000х2000 пикселей:


А это - переведённая в кубическую проекцию с ребром 2000 пикселей(!):


Я пробовал задавать разные значения ребра куба - 512, 1000, 1500, 2000. Качество самой текстуры визуально различалось - с этим было всё в порядке. Но при просмотра в игре между ними не было никакой разницы - одинаково расплывчато!

Я не могу понять - неужели это такое искажение при проекции грани куба в сферу?!

Из Вашего опыта - можно получить кубическую текстуру с чёткостью прямоугольной проекции 4000х2000 ? Если можно - то каким образом?

P.S. Забыл сказать - для перевода проекций я использовал программу "Planettool" - http://wiki.alioth.net/index.php/Planettool

To Tch

В этом как раз узкое место моего подхода - при переводе равнопромежуточной проекции в кубическую картинка мылится. Приходится поднимать резкость.
Исходник лучше брать с аспектом 2:1 и разрешением 2 в степени n - в моем случае 2048 * 1024 px.
После конверсии я обрабатываю каждую грань куба фильтром Smart Sharpen, параметры Amount 100%, Radius 0.5 pixels.
Чтобы избежать артефактов на гранях, я делаю выделение - квадратную область с отступом примерно 2 px, затем преобразую это выделение:
Select -> Modify -> Contract 4 pixels
Select -> Modify -> Feather 3 pixels
Разумееется, нерезкие зоны по граням остаются, но они практически незаметны и всяко это гораздо лучше, чем артефактнвые контуры.

То есть, получается, что это всё-таки во время перевода резкость падает, а не во время игры, когда плоская грань куба выгибается в сферу?

Впрочем, теперь это легко будет проверить. Вот уж действительно - одна голова хорошо, а две лучше!

А что у нас есть из программ, которые могли бы сразу рубить обыкновенную плоскую фотографию в кубическую проекцию, без перевода её в равнопромежуточную? Ведь это же должно быть даже намного проще, чем конвертировать фотографию в равнопромежуточную проекцию в Фотошопе!

И - спасибо за подробное описание постобработки после конвертации! Весьма ценный опыт, надеюсь, что заниматься текстурами мы будем не только вдвоём, так что пригодится всем. Думаю, что совместно выработаем приличную оптимальную технологию.


А что конкретно интересует? Мне казалось, что там всё предельно ясно: можно подключать пакет "Tch_Functions.oxp", а затем в своих пакетах использовать любую функцию из этого пакета. Подробное описание функций вместе с примерами я привёл, нужно только в шаблон подставлять свои параметры - и всё. Я просто хотел привести там пару примеров кодов - как выводить информацию в лог-файл с помощью этих функций, и как использовать, например, функцию ориентации объекта, ну, или поворота объекта на заданный угол, или ещё что-нибудь в этом роде...

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

Так это ж совсем элементарно, даже никаких "обстоятельных разборов" не нужно!

Создаёте свой пакет "ST_Functions.oxp" и все функции в файле "Config\script.js" начинайте описывать таким образом:


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

либо так, если она возвращает какое-то значение:

Связано это с областью видимости - такие функции "видны" из других пакетов, в то время, как функции, описанные так:

видны только в пределах своего файла-скрипта.

Но про "видимость" - это, уже, действительно, курс информатики...

Даже и не знаю, что тут ещё можно добавить. Наверное, то, что если кто-то другой в своём пакете тоже опишет функцию Name_Function(), то возникнет коллизия.

Поэтому я своим глобальным функция решил давать имя с префиксом "globfunc_" (хотя если по-хорошему, то надо бы префикс "globfunc_Tch_" - тогда уж точно не будет совпадения с чужими глобальными функциями )

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

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

stranger, Вы меня пугаете, чесслово!

Хорошо, попробую объяснить просто практически. Я сделал Вам для примера два тестовых пакета, самых наипростейших, какие только смог - чтобы было предельно понятно.

Пакет "ST_Functions.oxp" имеет одну папку "Config", в ней находится файл "script.js", в скрипте описана следующая функция:

Эта функция принимает два параметра - переменную parameter_1 с названием планеты и переменную parameter_2 с радиусом в числовом значении. Само тело функции состоит из вывода текстового сообщения на дисплей, а в текстовом сообщении содержатся эти две переменные.

Другой пакет - "Test_ST_Functions.oxp" - тоже имеет одну папку "Config", в ней находится файл "script.js", в скрипте описано следующее событие:

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

Если Вы поместите эти два пакета в папку игры "AddOns" и запустите игру, то в процессе игры, когда гипер-прыжком прыгнете в другую систему и только-только выйдете из туннеля гипер-пространства, из пакета "Test_ST_Functions.oxp" при этом событии вызовется функция Name_Planet_Radius, в которую передадутся два параметра - название планеты "Diso" и число 6155, которое выражает радиус планеты.

Этот вызов пойдёт в соседний пакет "ST_Functions.oxp", потому что тело функции Name_Planet_Radius находится там.

В этом пакете в теле этой функции эти два параметра подставятся в строку, и функция player.consoleMessage выведет на дисплей следующий текст: "Название планеты - Diso, радиус планеты - 6155 км"

Так из одного пакета можно вызвать функцию, которая находится в другом пакете.

Если и это моё объяснение будет непонятно, то я в приложении "2013-12-04 For_ST.zip" прилагаю эти два пакета ОХР. Можете поставить их в папку игры "AddOns", запустить игру на выполнение, прыгнуть в соседнюю звёздную систему и лично убедиться, что всё происходит именно так, как я описал выше.

Если и это не поможет, тогда да - попробуйте разобраться таки самостоятельно, потому что я уже и не знаю, что ещё сказать и как объяснить.

To Tch

Да уж, действительно, пример подобран предельно старательно, чтобы ненароком не проболтаться о самом главном.
Самое ведь главное - какие именно параметры обязательно нужно передавать на вход функции, а какие значения можно и нужно вычислять в ее теле?
Так что Ваш курс информатики опять ни о чем. Бухгалтершам проканает, а мне нужно понимать, что я делаю, для чего и почему именно так.

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

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


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

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

Для этого я просто на белом кубе с ребром 1000 пикселей нарисовал чёрные круги с резкой границей - и вот как это видится в игре:



А жаль. Мне для моих орбитальных полётов на низких высотах такая замыленность не подходит. Придётся пользоваться прямоугольной проекцией - хоть она и искажает сильно у полюсов, но зато более чётко показывает мелкие детали на поверхности.

To Tch

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

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

To Tch

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

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

Поэтому первые мои эксперименты с кубической проекцией вызвали у меня сильное воодушевление - форма кратеров практически не изменялась.

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

А я ведь так надеялся, что мы подберём оптимальную технологию, что это просто огрехи перевода...

Опишу это всё подробно в следующей части "Руководства по созданию своих планетных текстур" - народ должен знать это.

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

Потому что фарш обратно не прокрутишь: полёты на низких орбитах и посадки - это уже неотъемлемый элемент игры, их нельзя игнорировать. Между прочим, я сравнивал с реальным видео полёта над поверхностью Луны с сайтов NASA - просто очень похоже, очень, я доволен...

Ну, а если Вы переведёте всё обратно в прямоугольную из кубической - несомненно, я возьму Ваши прямоугольные.

Ладно, не унывайте. У меня сейчас тоже, практически, нет готового Параллельного Мира номер 002 - всё, что было, разбросал, переделал, а наполнять нечем - сижу без текстур, пытаюсь чего-то делать, заполняю дыры Вашими текстурами - а конца-края даже не видно, и когда это всё будет готово - даже не знаю...

To Tch

Так вот знал бы весной про то, насколько просто штопается шов по меридиану через фильтр Offset - не убил бы зазря столько времени.
И все же PlanetTool таки полезная штука, чтобы бысто оценить, насколько качественно заштопаны швы.
Ладно, исходники текстур у меня сохранились, буду переделывать.
Теперь уж точно до Нового Года не успею.
Ну хорошо хоть Sun Gear и PlanetLand в принципе вполне даже игровые получились, можно пока их не трогать. Хотя насчет PlanetLand есть масштабные задумки.