Форум Flasher.ru

Форум Flasher.ru (http://www.flasher.ru/forum/index.php)
-   ActionScript 3.0 (http://www.flasher.ru/forum/forumdisplay.php?f=83)
-   -   Вопрос по добавлению в список отображения (http://www.flasher.ru/forum/showthread.php?t=214554)

Appleman 18.09.2017 01:45

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

Код AS1/AS2:

package view 
{
        import flash.display.*
 
        public class MinigameView extends Sprite
        {
 
                private var mainTextArea:Shape = new Shape();
 
                public function MinigameView()
                {
                        mainTextArea.graphics.lineStyle(1);
                        mainTextArea.graphics.beginFill(0x0000FF, 1);
                        mainTextArea.graphics.drawRect(125, 0, 150, 75);
                        addChild(mainTextArea);       
                }
        }
}

Запускаю. Создаю экземпляр этого класса записью

Код AS1/AS2:

private var _view:MinigameView = new MinigameView;

На экране ничего не появляется. Ошибок тоже правда нет в строгом режиме. Попробовал перенести код в основной класс - синий прямоугольник появился. Что я делаю не так?

И ещё вопрос. Каким образом можно перевести запись цвета из RGB в вид 0x0000FF?

Wolsh 18.09.2017 02:51

Потому что нет "добавления в список отображения".
То есть _view то надо где-то добавить в дисплейлист.

Что такое "запись цвета в RGB"? Как выглядит?
0x0000FF это R=00, G=00, B=FF.

Appleman 18.09.2017 10:15

Спасибо, wolsh, в который раз меня выручаешь советом.

А как практически добавить? Если в основном классе прописать что-то типа addChild(view.Minigame._view), то наверное это не получится из-за ошибки доступа к private переменной _view. Сделать её публичной?

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

Godwarlock 18.09.2017 14:34

Appleman
Цитата:

Почему-то нигде не смог найти вразумительного объяснения
Скачай учебник автора "Колин Мук". Там хорошее введение в as3. Читай и делай, тогда 80% твоих будущих вопросов сразу отпадет.

Appleman 18.09.2017 16:33

Цитата:

Сообщение от Godwarlock (Сообщение 1201967)
Appleman
Скачай учебник автора "Колин Мук". Там хорошее введение в as3. Читай и делай, тогда 80% твоих будущих вопросов сразу отпадет.

Вот не поверишь, его и штудировал, по нему и делаю. А озвученного мною вопроса как раз не нашёл :) Вчера специально соотв. разделы второй части перечитал.

UPD: После серии экспериментов и гугления допёр до такого решения. В основном классе приложения создал экземпляр класса GameView и добавил его в список отображения (и проверил, что он там действительно есть):

Код AS3:

_view = new GameView;
addChild(_view);
trace(this.getChildAt(0).toString());

Wolsh, ты это имел в виду в своём ответе? Теперь объекты из класса GameView начали попадать на экран, но только при условии добавления их в список отображения через префикс this.

GBee 18.09.2017 16:42

Цитата:

Если в основном классе прописать что-то типа addChild(view.Minigame._view)
почти, в главном классе
Код AS3:

private var _view:MinigameView = new MinigameView(); //создаем экземпляр класса MinigameView 
addChild(_view); //добавляем его в список отображения

addChild(view.Minigame._view) - это тоже почти валидно, если _view статическая переменная класса, но тут куча нюансов и пока не надо.

Appleman 18.09.2017 17:18

Цитата:

Сообщение от GBee (Сообщение 1201969)
почти, в главном классе
Код AS3:

private var _view:MinigameView = new MinigameView(); //создаем экземпляр класса MinigameView 
addChild(_view); //добавляем его в список отображения


Спасибо, я как раз и сам допёр. Но тогда у меня такой вопрос. Предположим, у нас есть несколько относительно независимых элементов приложения, которые имеют абсолютно разную разметку экрана, т.е. вообще всё, начиная от фона и заканчивая текстами, иконками и т.п. Пусть это будет несколько миин-игр, каждая из которых прописана в своём классе: MiniGame1, MiniGame2, MiniGameN. Я предполагал, что для каждой из них необходимо сделать по отдельному классу MiniGame1View, MiniGame2View, MiniGameNView. В зависимости от выбора пользователя все экранные объекты должны перерисовываться. Как управлять подобным хозяйством на уровне всего приложения, начиная с класса Main? Интересует именно концептуальный подход.

GBee 18.09.2017 17:31

Сейчас вам расскажут про MVC. Но я не очень понял какие экранные объекты имеются в виду?

Appleman 18.09.2017 18:56

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

undefined 18.09.2017 19:12

бардак - это когда на кто-угодно добавляет дисплей обжекты на сцену.Правильно:есть один DO-контейнер, который создает дочерние DO-компоненты, каждый компонент рисует свои внутренности.Если надо выввести что-то специфичное(хинт или диалог поверх всего что есть на экране) - шлем контейнеру ивент с описанием что хотим.

GBee 18.09.2017 19:15

А, ну ненужный элемент можно же убрать с экрана.
Я так понимаю будет какое то меню для выбора игры. Кликнули в кнопку 1 - запустилась игра 1 (меню убрали), нажали выйти из игры - убрали игру, отобразили меню. И так далее.

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

Wolsh 18.09.2017 21:33

Цитата:

Почему-то нигде не смог найти вразумительного объяснения
:)
http://flasher.ru/forum/showpost.php...96&postcount=9

Appleman 18.09.2017 22:08

Цитата:

Сообщение от undefined (Сообщение 1201976)
бардак - это когда на кто-угодно добавляет дисплей обжекты на сцену.Правильно:есть один DO-контейнер, который создает дочерние DO-компоненты, каждый компонент рисует свои внутренности.Если надо выввести что-то специфичное(хинт или диалог поверх всего что есть на экране) - шлем контейнеру ивент с описанием что хотим.

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

Цитата:

Сообщение от Wolsh (Сообщение 1201978)

Спасибо.

Wolsh 18.09.2017 22:59

Код AS3:

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

В парадигме MVC это вторая буква называется View. Обычно это класс, наследующий DisplayObjectContainer (через Sprite, DOC нельзя наследовать напрямую) и отвечающий за вывод на экран изображения, а также воспроизведение звуков и всю интерактивность (мышиные и тач-события могут получать только дисплейные объекты).
То есть верх цепочки выглядит как Stage > Main > View.
Далее идут компоненты View, то есть какие-то модули, добавляемые в контейнер-View.
Например, ты сейчас смотришь форум в браузере? У браузера есть Окно, которое содержит Панель вкладок, Панель адреса, Панель поиска, Панель инструментов, и собственно окно в котором отображается контент (сайт), со скроллбаром. Все это компоненты. View их не рисует своими средствами. Кнопки сами себя рисуют, View только добавляет их в отображение или удаляет из него: как если бы View было столом, на который выкладываются предметы. Нужно показать Меню? Сделали во Вью addChild(_menu); Подписались на событие SELECT от меню. Получили событие — убрали меню из отображения, выяснили, что в нем выбрал юзер, показали то что он выбрал (или окно "сам дурак такого нет").
Как-то так, если вкратце не касаясь остальных друзей в MVC.

undefined 19.09.2017 00:02

Цитата:

Насколько я понимаю, должен быть один и только один класс-"рисовальщик"
Что ты называешь "рисовальщиком"?За рендеринг экранных объектов отвечает flash runtime.Задача корневого do-контейнера - создавать/уничтожать и управлять всеми дочерними визуальными объектами.Компонент- любой визуальный объект внутри контейнера.
Например проект игры на два экрана(игр. меню и игровой экран).Корневой контейнер не имеет визуального представления, но может содержать внутри себя другие визуальные объекты(DO) и другие контейнеры визуальных объектов(DOC).На старте приложения мы просто создаем объект корневого контейнера и говорим ему "поехали".Корневой DOC создает экран "главное меню" и добавляет его в себя.Для простоты будем считать что в меню всего одна кнопка-"старт".Меню слушает события от своих детей.Например при клике по кнопке,она испускает событие "click".Меню ловит это событие и должно оповестить корневой DOC.Меню шлет событие "start game" которое слушает корневой DOC.Корневой DOC уничтожает экран "меню",создает экран "игра" и помещает его в себя.
Тут важно следить чтоб компоненты общались только со своими родителями т.е. корневой DOC должен реагировать только на события,отправленные его детьми(игр. меню и игровой экран).Т.е. не должно быть такого чтоб родитель родителя реагировал на события детей детей :).В данном примере это значит что корневой DOC не должен слушать событие "click" от кнопки старт.

Appleman 19.09.2017 10:52

Цитата:

Сообщение от Wolsh (Сообщение 1201981)
В парадигме MVC это вторая буква называется View. Обычно это класс, наследующий DisplayObjectContainer (через Sprite, DOC нельзя наследовать напрямую) и отвечающий за вывод на экран изображения

Да, пока всё складывается так, что подход MVC оказывается наиболее логичным, как минимум, он в мою голову укладывается и помогает упорядочить кипящую там кашу. Я правда других не видел :), но есть впечатление, что использовать MVC - это как есть вилкой и ножом: не интеллигентская блажь, а тупо удобно.

Цитата:

Далее идут компоненты View, то есть какие-то модули, добавляемые в контейнер-View.
View их не рисует своими средствами. Кнопки сами себя рисуют, View только добавляет их в отображение или удаляет из него: как если бы View было столом, на который выкладываются предметы. Нужно показать Меню? Сделали во Вью addChild(_menu); Подписались на событие SELECT от меню. Получили событие — убрали меню из отображения, выяснили, что в нем выбрал юзер, показали то что он выбрал (или окно "сам дурак такого нет").
Да, общую логику я понял, здесь все ответившие в теме выше едины. Мне бы получше на уровне реализации понять. Я даже не про код, а про нормальную архитектуру классов и их взаимодействие... Всё по отдельности понимаю, а как воедино собрать - нет :(

Понятно, что корневой DOC создаётся в основном классе приложения. Далее создаём специальный класс (пусть будет GameView) для эксклюзивного выполнения функции управления DO-компонентами, создаём экземпляр этого класса в главном классе, добавляем его там же в корневой DOC через addChild(). Теперь всё, что попадёт в контейнер GameView (что кстати будет этим контейнером, переменная типа Sprite?), будет выведено на экран.

А вот дальше что? Например, у нас есть отдельный класс для меню. Он по логике также должен содержать контейнер. Плюс отдельный класс для кнопки меню, которая содержит загруженное изображение кнопки, либо её рисование программными средствами со всеми параметрами (цвета, линии и т.п.), не важно. Я понял на принципиальном уровне, что при выводе меню нам нужно поместить контейнер из класса "меню" в контейнер GameView, а потом уже в контейнер "меню" добавить какое-то число кнопок, по ситуации.

Как это реализуется? Какие классы к каким обращаются для выполнения того, что я описал выше?

Цитата:

Сообщение от undefined (Сообщение 1201983)
На старте приложения мы просто создаем объект корневого контейнера и говорим ему "поехали".Корневой DOC создает экран "главное меню" и добавляет его в себя.Для простоты будем считать что в меню всего одна кнопка-"старт".Меню слушает события от своих детей.Например при клике по кнопке,она испускает событие "click".Меню ловит это событие и должно оповестить корневой DOC.Меню шлет событие "start game" которое слушает корневой DOC.Корневой DOC уничтожает экран "меню",создает экран "игра" и помещает его в себя.
Тут важно следить чтоб компоненты общались только со своими родителями т.е. корневой DOC должен реагировать только на события,отправленные его детьми(игр. меню и игровой экран).Т.е. не должно быть такого чтоб родитель родителя реагировал на события детей детей :).В данном примере это значит что корневой DOC не должен слушать событие "click" от кнопки старт.

Получается, что механизм реализуется исключительно через систему событий с их грамотной "фильтрацией по этажам"?

Wolsh 19.09.2017 15:28

Цитата:

что кстати будет этим контейнером, переменная типа Sprite?
this
Цитата:

при выводе меню нам нужно поместить контейнер из класса "меню" в контейнер GameView
да не "из", а само меню и есть контейнер. Не "имеет", а "является" (has/is).
Мы же стремимся думать в категориях ООП, верно? Каждый Объект является законченным самостоятельным модулем. Настолько, что он может использоваться в разных проектах, в идеале — вообще без каких-либо изменений. Вчастности, это означает, что GameView не будет добавлять какие-то ОТДЕЛЬНО существующие кнопки в меню, если ты представляешь себе это как _menu.addChild(_blueButton);
Меню, скорее всего, позволяет себя НАСТРАИВАТЬ (для конкретной игры это необязательно, но в идеале да). То есть, при создании или после, Меню предоставляет возможность задать параметры — например список кнопок (всмысле их названий, текстов на кнопках). Получив все необходимые данные, Меню строит себя САМОСТОЯТЕЛЬНО, это его ответственность. Оно создает необходимое количество кнопок, распределяет их в "себе"-контейнере и подписывается на события нажатий. Когда кнопку нажмут, Меню(!) должно послать событие что юзер сделал выбор. На события наведение и увода мыши, нажатия и отпускания Кнопки должны уметь реагировать самостоятельно — это их ответственность. И, наконец, тот кто создал экземпляр Меню, подписывается на событие от Меню "юзер сделал выбор", и получив это событие, разбирается что делать дальше. Надо четко понимать где чья ответственность. Каждый элемент ниже по иерархии является самостоятельным в выполнении своей задачи ИНСТРУМЕНТОМ для того, кто выше: Кнопка должна уметь "нажиматься", Меню должно уметь предоставить выбор, тот кто создал меню — знать что делать с выбором. Это называется иерархия. Тот, кто ниже, обычно извещает того кто выше — своего создателя — о происходящих в нем изменениях, но РЕШЕНИЯ принимает только в своей области ответственности. То есть внутри Кнопки не содержится кода, запускающего игру. И в Меню его не содержится. Меню не запускает игру, это не его ответственность.

Appleman 19.09.2017 19:02

Wolsh, спасибо. Исчерпывающе. Даже спросить больше нечего, только идти и пробовать :)

Мини-уточнение. Насколько я понимаю, все утилитарные функции, связанные с выводом (например, полная очистка экрана), делегируются классу View и реализуются через его соответствующие методы, верно?

undefined 19.09.2017 20:29

Цитата:

Мини-уточнение. Насколько я понимаю, все утилитарные функции, связанные с выводом (например, полная очистка экрана), делегируются классу View и реализуются через его соответствующие методы, верно?
Еще раз: за рисование отвечает flash runtime никакие очистки/перерисовки экрана не требуются.Если хочется очистить всю сцену- просто отцепляешь от нее все display objects.
Цитата:

только идти и пробовать
золотые слова.

Appleman 19.09.2017 23:17

Цитата:

Еще раз: за рисование отвечает flash runtime никакие очистки/перерисовки экрана не требуются.Если хочется очистить всю сцену- просто отцепляешь от нее все display objects.
Я это и имею в виду. Функцию по уборке компонентов из DOC нужно реализовывать в том классе, где корневой DOС и находится.

undefined 19.09.2017 23:53

DOC - display object container. Он может быть как корневым, так и не корневым.
В любом случае добавлять/отцеплять display object'ы от дисплей-листа должен родительский для этих объектов контейнер.

Wolsh 20.09.2017 01:51

Ты бы на пару дней отбросил амбиции сходу написать игру, которая покорит весь мир, и попробовал силы в написании банальной кнопки, а затем менюшки с тремя-четырьмя этими кнопками.
У меня ученики начинают с CheckBox и RadioButton, затем RadioBar — о каком бы Варкрафте ни мечтали)). И на таких простейших компонентах прекрасно осознают львиную долю концепций ООП.
Скучно, стыдно, но начинать надо с малого — оно в мозгу целиком помещается.

caseyryan 20.09.2017 10:20

Цитата:

В любом случае добавлять/отцеплять display object'ы от дисплей-листа должен родительский для этих объектов контейнер.
Это ошибочное суждение. Не знаю почему многим так вбилось это в голову. Объекты могут и сами себя удалять из дисплей листа. Ничего плохого в этом нет, если на них нет каких-то дополнительных внешних ссылок. Часто вот такие "правильные" подходы приводят к дико нечитаемому и трудноподдерживаемому коду.
Взять какого-нибудь персонажа в игре. Врага. Игрок убивает этого врага, и вот тут возникает вопрос, а как его удалить? Если пользоваться подходом, что только родитель должен удалять дочерние объекты, то этот враг должен (согласно парадигме флеша) послать событие о том, что он дожен удалиться. Это событие должен слушать родитель. По событию родитель находит целевой объект, отписывается от его событий и удаляет объект.
Хотя все можно было сделать гораздо проще. Не оставлять никаких внешних ссылок на врага, а просто создать в нем метод destroy / dispose, в котором он может сам удалиться из дисплей листа. Никаких ненужных событий и лишних зависимостей.

Zebestov 20.09.2017 11:15

Цитата:

Сообщение от caseyryan (Сообщение 1201999)
Это ошибочное суждение.

Ну не знаю. Мне кажется дикой идея, когда мой мусорный пакет сам выбрасывает себя в мусорный бак.

Appleman 20.09.2017 11:46

Цитата:

Сообщение от Wolsh (Сообщение 1201998)
Ты бы на пару дней отбросил амбиции сходу написать игру, которая покорит весь мир, и попробовал силы в написании банальной кнопки, а затем менюшки с тремя-четырьмя этими кнопками. У меня ученики начинают с CheckBox и RadioButton, затем RadioBar — о каком бы Варкрафте ни мечтали)). И на таких простейших компонентах прекрасно осознают львиную долю концепций ООП. Скучно, стыдно, но начинать надо с малого — оно в мозгу целиком помещается.

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

Я с ходу догадался, что ты преподаёшь :) Чувствуется стиль языка и манера изложения: последовательно, доходчиво и метафорично. У тебя книжек или туториалов нет?

Tails 20.09.2017 11:50

Wolsh,
Мне бы такого учителя в своё время.. Знания моего преподавателя ограничивались кодом на кнопке для перехода в нужный кадр.

Цитата:

Сообщение от Zebestov (Сообщение 1202001)
Ну не знаю. Мне кажется дикой идея, когда мой мусорный пакет сам выбрасывает себя в мусорный бак.

Предприниматель, сумевший реализовать эту идею станет миллионером!

Всё-таки я тоже малась поддержу caseyryan, ну не всегда на практике получается строго придерживаться концепции Родитель -> Ребёнок. Это как с оператором goto в c++, его нужно стараться избегать всегда. Но где-то, единичное и умелое его применение может облегчить, упростить или ускорить выполнение кода.

undefined 20.09.2017 12:19

Цитата:

Это ошибочное суждение.
Правило не строгое.Главное чтоб исключение не стало доминирующим паттерном в проекте.Сам часто для хинтов создаю MC с анимацией появления/исчезновения и в последнем кадре:
Код AS3:

if(parent)
  parent.removeChild(this);

и в любом месте:
Код AS3:

var hint:MyHint=new MyHint();
addChild(hint);


caseyryan 21.09.2017 05:44

Вложений: 4
Цитата:

и в любом месте:
Код AS3:

var hint:MyHint=new MyHint();
addChild(hint);


А лучше через статический метод из пула их брать ;) (знаю, что я сейчас сКЭПил))
Цитата:

Главное чтоб исключение не стало доминирующим паттерном в проекте
Я даже в этом ничего страшного не вижу. Если это удобнее, чем использовать классический подход, то почему бы и нет.
Цитата:

Мне кажется дикой идея, когда мой мусорный пакет сам выбрасывает себя в мусорный бак.
А мне она кажется великолепной :D
Цитата:

Возможно я не прав, но мне представляется, что наличие некой более крупной цели (игра, которая покорит мир и его окрестности) лучше мотивирует на изучение.
Всё верно. Идея нужна, иначе не будет стимула. Я когда начинал изучение, я тоже сразу начал с большой онлайновой игры. И я, таки, сделал её и даже запустил в ВК. Там только с монетизацией получилась беда, в силу недостаточного опыта. Но игра, сама по себе, получилась довольно неплохо. Вот с неё некоторые скрины. А главное, я на ней очень многому научился, как по клиентской части, так и по серверной. Я по ней не только AS3 но и Java изучал. Так что поддержу, наличие такой цели - это очень хорошо. Главное, чтобы руки не опустились после множества неудач, которые обязательно будут на этом нелегком пути ;)

undefined 21.09.2017 11:01

Цитата:

Я даже в этом ничего страшного не вижу. Если это удобнее, чем использовать классический подход, то почему бы и нет.
Удобнее всего чтоб данные писались в модель прямо в хэндлере кнопки.ТС - новичок,сначала надо научиться как правильно, а как легче само придет.

Appleman 21.09.2017 16:26

Цитата:

Сообщение от caseyryan (Сообщение 1202016)
Я когда начинал изучение, я тоже сразу начал с большой онлайновой игры. И я, таки, сделал её и даже запустил в ВК. Там только с монетизацией получилась беда, в силу недостаточного опыта. Но игра, сама по себе, получилась довольно неплохо. Вот с неё некоторые скрины.

Симпатично. На Desert/Jungle Strike чем-то похоже. :) А ссылку в студию?

caseyryan 21.09.2017 16:48

Цитата:

На Desert/Jungle Strike чем-то похоже.
Это и была одна из игр, на которую мы ровнялись, когда делали (говорю мы, потому что графику делал не я). Второй игрой-рефом была сеговская Cannon Fodder.
Цитата:

А ссылку в студию?
Игра отключена уже несколько лет.

Nooob 22.09.2017 00:06

Цитата:

Сообщение от caseyryan (Сообщение 1201999)
Это ошибочное суждение. Не знаю почему многим так вбилось это в голову. Объекты могут и сами себя удалять из дисплей листа. Ничего плохого в этом нет, если на них нет каких-то дополнительных внешних ссылок. Часто вот такие "правильные" подходы приводят к дико нечитаемому и трудноподдерживаемому коду.
Взять какого-нибудь персонажа в игре. Врага. Игрок убивает этого врага, и вот тут возникает вопрос, а как его удалить? Если пользоваться подходом, что только родитель должен удалять дочерние объекты, то этот враг должен (согласно парадигме флеша) послать событие о том, что он дожен удалиться. Это событие должен слушать родитель. По событию родитель находит целевой объект, отписывается от его событий и удаляет объект.
Хотя все можно было сделать гораздо проще. Не оставлять никаких внешних ссылок на врага, а просто создать в нем метод destroy / dispose, в котором он может сам удалиться из дисплей листа. Никаких ненужных событий и лишних зависимостей.

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

caseyryan 22.09.2017 07:46

Цитата:

Если удаление было вызвано в момент итерации по детям
Это же синхронная операция, такого не может быть. А если ты имеешь в виду сравнение какого-то массива, в который добавлены эти объекты, со списком детей в контейнере, то тут, я бы просто выбрал другой подход.
Я в общем-то не говорю, что подход "родитель удаляет ребенка" плохой. Я просто говорю, что он не является единственным верным, как многие считают. И подход "ребенок удаляет сам себя" тоже вполне рабочий и допустимый во многих случаях.
А то у новичков может сложиться впечатление, что так делать ни в коем случае нельзя, а почему нельзя - не понятно.

Nooob 25.09.2017 23:11

Цитата:

Сообщение от caseyryan (Сообщение 1202027)
такого не может быть

Пример конечно странный, но тем не менее он отражает потерю контроля владельца
Код AS3:

//child
        public class Enemy extends Sprite
        {
                public var health:uint;
                //*....*//
                public function update():void
                {
                        if(health == 0)
                                parent.removeChild(this);
                }
        }
//parent
for (var i:int = 0; i < numChildren; i++)
{
    (getChildAt(i) as Enemy).update();
}

Дерево DisplayObject это лишь частный случай родитель-потомок, это может быть и список Enemy в родителе с методами addEnemy, removeEnemy

caseyryan 26.09.2017 09:30

Цитата:

Пример конечно странный
Да. Этим все сказано.
Я бы лучше сделал статический аниматор, который принимает объекты применяющие интерфейс IUpdatable из которого объект тоже сам удаляется.
Цитата:

это может быть и список Enemy в родителе с методами addEnemy, removeEnemy
Ну тут то получается, что архитектура приложения заточена на то, чтобы именно родитель удалял детей. В этом случае, конечно не нужно делать "самоудаление"

undefined 26.09.2017 11:39

я один не понимаю что страшного произойдет?Когда Enemy самоуничтожится,numChildren автоматически станет на 1 меньше и цикл либо продолжится дальше,либо остановится.

Добавлено через 24 минуты
Гараздо неприятнее что такое самоудаление сдвигает весь dl

Zebestov 26.09.2017 12:17

Покойник сам на кладбище не ходит, его хоронят, так заведено.
Развели тут =)

Wolsh 26.09.2017 12:37

Цитата:

numChildren автоматически станет на 1 меньше и цикл либо продолжится дальше,либо остановится.
при этом один ребенок проскочит без апдейта, так как встанет на текущий i вместо удалившегося, а цикл перейдет к следующему. Распространенная ошибка при чистке массивов.

Appleman 04.10.2017 19:05

Друзья!

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

Во-первых, файлы с растровыми изображениями можно загружать с помощью Loader-ов и с помощью тега метаданных [embed]. Разбирался, в чём их отличие. Пока единственное, что твёрдо усвоил и осознал, это тот факт, что Loader загружает изображение на этапе выполнения, а [embed] - на этапе компиляции. Делаю вывод, что если я планирую игру на flash, работающую в т.ч. оффлайн, то мой выбор, по всей видимости, - это "встраивание" графики на этапе компиляции, т.е. вариант [embed]. Верно?

Во-вторых, с этим самым [embed] какой-то стрёмный синтаксис. Вот из нашего отца родного Колина Мука:

Код AS3:

        public class MinigameView extends Sprite
        {
 
                [Embed(source = "../../Bitmaps/Eiffel-Tower-In-Paris-800x600.jpg")]
                private var Photo:Class;
 
                public function MinigameView()
                {
                        var photo:BitmapAsset = new Photo();
                        addChild(photo);
                }
        }

Что это за тип данных Class? Почему приватная переменная Photo записана с большой буквы в нарушение всех конвенций? Каким образом происходит связь загруженного через мета тег графического файла и переменной внутри программы?

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

Wolsh 04.10.2017 20:17

Синтаксис стремный, потому что это не язык AS3, а команда компилятору.
Photo c заглавной буквы, потому что все классы именуют с заглавной.
Компилятор создает автоматически класс-наследник Bitmap с "предустановленной" битмапдатой — Photo. Поэтому в дальнейшем ты можешь создавать сколько угодно экземпляров этого класса и обращаться с ними как с обычным Bitmap.
Цитата:

Что это за тип данных Class?
Все классы являются объектами типа Class. Их можно передавать между функциями, хранить в переменных и получать на них ссылки, зная только название класса (строку). Для удобства этих операций существует тип Class.
Код AS3:

var A:Class = flash.display.Sprite; // класс
var cont:Sprite = new A() as Sprite; // экземпляр

Думаю, понятно почему нельзя написать
Код AS3:

var A:Class = flash.display.Sprite; // класс
var cont:A = new A(); // экземпляр

Потому что на этапе компиляции такого типа "A" не существует, это всего-лишь имя переменной.

Цитата:

то это будет огромная простыня и сумасшедшее количество переменных
а при загрузке в рантайме — не будет простыни и переменных?
Многие по возможности собирают много маленьких в одну большую — спрайтшит или атлас — и в рантайме "нарезают" ее на маленькие. Это особенно удобно, когда картинки являются кадрами какой-то секвенции или например иконками графического интерфейса; удобно, когда не нужен КЛАСС для каждой картинки, и даже отдельная переменная — когда можно хранить их в массиве.


Часовой пояс GMT +4, время: 02:44.

Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.