Помощь с скриптами (RGSS)

**Andrew** · 08.02.2012, 19:18

Сообщение от Equilibrium Keeper

Да вы извращенец, батенька. Нет, можешь конечно погуглить на предмет создания скриншотов во флеше, но это очень плохая идея. Есть класс Bitmap, который выводит картинки. Подцепить его (или BitmapData) в качестве исходника к какому-нибудь контролу, способному его корректно отображать, думаю, также не составит труда. Один из первых запросов в гугле, аля "actionscript gallery" выдаст тебе ссылку на подробную статью с примерами кода. Например, эту: http://flashexplained.com/actionscri...ry-in-flash-8/

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

Решил забить на getPixel. Использую hitTest

**Equilibrium Keeper** · 08.02.2012, 20:59

Сообщение от 100500

Equilibrium Keeper, спасибо, снова выручил! Вроде бы помогло - сколько ни тестил, ещё не вылетало.

Вот теперь задумался. Недавно прикручивал Neo Message System 3 (по-моему, так называется), и после этого вроде как ошибка и стала появляться. Однако эту систему я удалил, даже не из-за ошибки, а из-за ненужности.
Может ли такое быть, что ошибка была вызвана тем скриптом системы сообщений, и осталась даже после её удаления?

1) Ну, это всего лишь костыль, ввиду того, что я не знаю - что у тебя там творится. По уму надо понять - почему появляется несуществующий элемент и либо исключить его появление, либо изменить алгоритм этого скрипта.
2) Только если ты не все хвосты удалил.

Andrew
Ну, мое мнение ты уже слышал. Это неправильно. Модель данных не должна зависеть от представления. В твоем текущем проекте это наверняка неважно (ну, разве что hitTest будет значительно дольше работать), но вообще нужно стараться всегда писать красивый, читабельный, правильный код. Сегодня у тебя черные стенки на белом, завтра - белые на черном, послезавтра True Color, а через неделю ты прикрутишь сетевую игру и переведешь ее на отношения клиент-сервер. Это уже не говоря о том, что юзвери - народ ушлый. Могут и тему сменить, и какой-нибудь апплет навесить, который будет одни контролы другими заменять. И полетит к демонам вся логика твоего приложения. Но, в твоем случае, наверное, достаточно и hitTest'а.

**Andrew** · 08.02.2012, 21:28

ну, разве что hitTest будет значительно дольше работать

Что правда?(((
Я выбрал хитТест, потому что с ним можно делать двигающие платформы(лифты).

**Equilibrium Keeper** · 09.02.2012, 00:13

Ну, смотри что нужно чтобы проверить проходимость в двумерном массиве?

Код:

mov eax, @y // поместили координату y
mul eax, @arraySize2 // умножили ее на количество столбцов
add eax, @x // прибавили координату y
mov eax, "@array[eax] // извлекли значение из массива
cmp eax, 0 // сравнили с 0
je **** // переход, если равно
nop // иначе продолжаем что-нибудь делать

Это псевдоассемблерный код (на асме не пишу, так что по-человечески изобразить не могу). Но, думаю, понятно, что тут мы имеем меньше 10 команд, каждая из которых выполняется в 1-2 такта.

В твоем случае (hitTest) проверяется попадание одного объекта в другой. Даже имея простейший случай - точка в полигоне, можешь погуглить на предмет алгоритмов проверки. Так как механизмы в AS универсальные, то это будет проверка попадания точки в невыпуклый полигон с произвольным количеством вершин и защитой от "паравозиков" и прочих исключительных ситуаций. Вот и представь - насколько данная проверка будет выполняться дольше, в отличии от простенькой матрицы проходимостей.
Ну, а у если у тебя проверяются два произвольных объекта, то все становится еще сложнее и медленнее.

**Andrew** · 09.02.2012, 15:22

всё же остановлюсь на хитТест.
Предположим у меня есть платформа, которая поднимается на 300пкс и опускается на 300пкс. Мне же придётся каждый кадр массив изменять. А как я массив создам. это же 307200 элементов при самой маленькой карте.

**Equilibrium Keeper** · 09.02.2012, 23:09

Сообщение от Andrew

всё же остановлюсь на хитТест.
Предположим у меня есть платформа, которая поднимается на 300пкс и опускается на 300пкс. Мне же придётся каждый кадр массив изменять. А как я массив создам. это же 307200 элементов при самой маленькой карте.

Да, придется. И?

Ну изменишь ты 20 ячеек памяти. Ну, потратишь на это 1мс.

Что до массива в 307200 элементов, это некритичная ситуация. Всего-то 300кб мозгов. У тебя одна картинка больше весит.
Вот когда это число приблизится к 10мб, тогда уже стоит подумать о других алгоритмах хранения. Например, нет смысла хранить непроходимую зону 10х120 в виде набора точек, когда можно обойтись 4мя по углам.
Тут то и начинается настоящее программирование. А все остальное - это так, бестолковый кодинг.

**Andrew** · 09.02.2012, 23:19

Вот когда это число приблизится к 10мб, тогда уже стоит подумать о других алгоритмах хранения. Например, нет смысла хранить непроходимую зону 10х120 в виде набора точек, когда можно обойтись 4мя по углам.

двумя углами
а вообще это идея. сделать массив 2*n и проверять с помощью него. Вот только я опять подошёл к проблеме. не в ручную же мне забивать массив.

**Equilibrium Keeper** · 10.02.2012, 00:34

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

Конечно не вручную. Именно поэтому и нужны редакторы карт.

А данные не задаются напрямую в программе, а хранятся во всевозможных игровых архивах. Можешь и сам сгенерировать его на основе цветов изображения, правда это возвращает тебя к проблеме обращаения к bitmapData.

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

Просто учти на будущее.

**Andrew** · 11.02.2012, 10:12

А данные не задаются напрямую в программе, а хранятся во всевозможных игровых архивах.

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

**Рыб** · 11.02.2012, 12:52

Про файлы: Ну вообще все зависит от того, как и что ты планируешь хранить, так как если ты планируешь работать на десктопах(AIR) то есть куча способов использовать файлы не вшитые в swf(я к примеру сейчас активно разбираюсь с SQLite, которая является базой данных, которая не требует установки и настройки серверов, достаточно лишь пару библиотек подключить к исходному коду, а сама база хранится в отдельном файле).
Так же все можно хранить все в XML-файле(и положить его либо в код swf либо в отдельную папку). Но все равно все предполагает написание простенького редактора карт.
Про хранение: для у тебя систему очень напоминает тайловую(на данный момент) можно сделать отдельную карту проходимостей. Можно сделать массив вершин препятствий, что тоже, правда для полноценной работы(чтобы можно было рисовать карты состоящие не только из прямоугольников, а более угловатых) необходимо под рихтовать физику(ее переписывание отнимит приличный кусок времени).