1) Ну, это всего лишь костыль, ввиду того, что я не знаю - что у тебя там творится. По уму надо понять - почему появляется несуществующий элемент и либо исключить его появление, либо изменить алгоритм этого скрипта.
2) Только если ты не все хвосты удалил.
Andrew
Ну, мое мнение ты уже слышал. Это неправильно. Модель данных не должна зависеть от представления. В твоем текущем проекте это наверняка неважно (ну, разве что hitTest будет значительно дольше работать), но вообще нужно стараться всегда писать красивый, читабельный, правильный код. Сегодня у тебя черные стенки на белом, завтра - белые на черном, послезавтра True Color, а через неделю ты прикрутишь сетевую игру и переведешь ее на отношения клиент-сервер. Это уже не говоря о том, что юзвери - народ ушлый. Могут и тему сменить, и какой-нибудь апплет навесить, который будет одни контролы другими заменять. И полетит к демонам вся логика твоего приложения. Но, в твоем случае, наверное, достаточно и hitTest'а.
Последний раз редактировалось Equilibrium Keeper; 08.02.2012 в 21:04.
Что правда?(((ну, разве что hitTest будет значительно дольше работать
Я выбрал хитТест, потому что с ним можно делать двигающие платформы(лифты).
Ну, смотри что нужно чтобы проверить проходимость в двумерном массиве?
Это псевдоассемблерный код (на асме не пишу, так что по-человечески изобразить не могу). Но, думаю, понятно, что тут мы имеем меньше 10 команд, каждая из которых выполняется в 1-2 такта.Код:mov eax, @y // поместили координату y mul eax, @arraySize2 // умножили ее на количество столбцов add eax, @x // прибавили координату y mov eax, "@array[eax] // извлекли значение из массива cmp eax, 0 // сравнили с 0 je **** // переход, если равно nop // иначе продолжаем что-нибудь делать
В твоем случае (hitTest) проверяется попадание одного объекта в другой. Даже имея простейший случай - точка в полигоне, можешь погуглить на предмет алгоритмов проверки. Так как механизмы в AS универсальные, то это будет проверка попадания точки в невыпуклый полигон с произвольным количеством вершин и защитой от "паравозиков" и прочих исключительных ситуаций. Вот и представь - насколько данная проверка будет выполняться дольше, в отличии от простенькой матрицы проходимостей.
Ну, а у если у тебя проверяются два произвольных объекта, то все становится еще сложнее и медленнее.
всё же остановлюсь на хитТест.
Предположим у меня есть платформа, которая поднимается на 300пкс и опускается на 300пкс. Мне же придётся каждый кадр массив изменять. А как я массив создам. это же 307200 элементов при самой маленькой карте.
Да, придется. И? Ну изменишь ты 20 ячеек памяти. Ну, потратишь на это 1мс.
Что до массива в 307200 элементов, это некритичная ситуация. Всего-то 300кб мозгов. У тебя одна картинка больше весит.
Вот когда это число приблизится к 10мб, тогда уже стоит подумать о других алгоритмах хранения. Например, нет смысла хранить непроходимую зону 10х120 в виде набора точек, когда можно обойтись 4мя по углам.
Тут то и начинается настоящее программирование. А все остальное - это так, бестолковый кодинг.
двумя угламиВот когда это число приблизится к 10мб, тогда уже стоит подумать о других алгоритмах хранения. Например, нет смысла хранить непроходимую зону 10х120 в виде набора точек, когда можно обойтись 4мя по углам.
а вообще это идея. сделать массив 2*n и проверять с помощью него. Вот только я опять подошёл к проблеме. не в ручную же мне забивать массив.
А-а. Вот насчет двух углов не самая лучшая идея. Ее я бы рекомендовал оставить до этапа оптимизации. Если это действительно станет необходимо. По работе много раз сталкивался с всевозможными оригинальными решениями, в итоге почти каждое из них оказывалось весьма неудобным спустя некоторое время эксплуатации. Лучше полигоны задавать набором вершин, нежели рассчитывать их по углам, по радиусу, и т.д. Менять два байта на четыре операции сложения и 4 обращения к массиву - не лучшая мысль.
Конечно не вручную. Именно поэтому и нужны редакторы карт. А данные не задаются напрямую в программе, а хранятся во всевозможных игровых архивах. Можешь и сам сгенерировать его на основе цветов изображения, правда это возвращает тебя к проблеме обращаения к bitmapData.
В любом случае, это на приличное время застопорит твою работу. Так что если ты не собираешься делать что-то серьезное, лучше не заморачивайся. Просто учти на будущее.
Подожди, а где эти архивы будут храниться? Если ты имеешь в виду хранить их как отдельный файл, то не подойдёт, так как преимущество флэш, это то что там всё одним файлом. Значит хранить их надо в библиотеке, это открывает опять проблему с чтением из библиотеки.А данные не задаются напрямую в программе, а хранятся во всевозможных игровых архивах.
Про файлы: Ну вообще все зависит от того, как и что ты планируешь хранить, так как если ты планируешь работать на десктопах(AIR) то есть куча способов использовать файлы не вшитые в swf(я к примеру сейчас активно разбираюсь с SQLite, которая является базой данных, которая не требует установки и настройки серверов, достаточно лишь пару библиотек подключить к исходному коду, а сама база хранится в отдельном файле).
Так же все можно хранить все в XML-файле(и положить его либо в код swf либо в отдельную папку). Но все равно все предполагает написание простенького редактора карт.
Про хранение: для у тебя систему очень напоминает тайловую(на данный момент) можно сделать отдельную карту проходимостей. Можно сделать массив вершин препятствий, что тоже, правда для полноценной работы(чтобы можно было рисовать карты состоящие не только из прямоугольников, а более угловатых) необходимо под рихтовать физику(ее переписывание отнимит приличный кусок времени).
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Социальные закладки