![]() |
Вопрос по добавлению в список отображения
Друзья, элементарный вопрос, который меня поставил в тупик. Сделал простенький класс, который должен заниматься выводом информации на экран. В порядке теста практически один-в-один переписал код из книжки:
Код AS1/AS2:
Код AS1/AS2:
И ещё вопрос. Каким образом можно перевести запись цвета из RGB в вид 0x0000FF? |
Потому что нет "добавления в список отображения".
То есть _view то надо где-то добавить в дисплейлист. Что такое "запись цвета в RGB"? Как выглядит? 0x0000FF это R=00, G=00, B=FF. |
Спасибо, wolsh, в который раз меня выручаешь советом.
А как практически добавить? Если в основном классе прописать что-то типа addChild(view.Minigame._view), то наверное это не получится из-за ошибки доступа к private переменной _view. Сделать её публичной? Плюс класс, в котором создаётся _view, также не принадлежит к основному классу приложения. На каком уровне это должно быть прописано? Почему-то нигде не смог найти вразумительного объяснения - все книжки и туториалы с ходу зарываются в нюансы форматирования и вывода, но ни разу не выходили с графикой за пределы основного класса. |
Appleman
Цитата:
|
Цитата:
UPD: После серии экспериментов и гугления допёр до такого решения. В основном классе приложения создал экземпляр класса GameView и добавил его в список отображения (и проверил, что он там действительно есть): Код AS3:
|
Цитата:
Код AS3:
|
Цитата:
|
Сейчас вам расскажут про MVC. Но я не очень понял какие экранные объекты имеются в виду?
|
я имел в виду, что если у нас единственный класс, который выводом на экран заведует, то всё просто - создаём его экземпляр в главном классе, добавляем там его в список отображения и пошло-поехало.
А если у нас не один, а несколько классов, непосредственно выводящих содержимое на экран? Ведь если в главном классе создать по экземпляру каждого, то будет бардак. Или я не прав? Как-то пока совсем не ощущаю логику управления выводом в AS3. |
бардак - это когда на кто-угодно добавляет дисплей обжекты на сцену.Правильно:есть один DO-контейнер, который создает дочерние DO-компоненты, каждый компонент рисует свои внутренности.Если надо выввести что-то специфичное(хинт или диалог поверх всего что есть на экране) - шлем контейнеру ивент с описанием что хотим.
|
А, ну ненужный элемент можно же убрать с экрана.
Я так понимаю будет какое то меню для выбора игры. Кликнули в кнопку 1 - запустилась игра 1 (меню убрали), нажали выйти из игры - убрали игру, отобразили меню. И так далее. А так все на экране лежит слоями, как стопка картинок на столе. Картинки можно убирать из стопки или всовывать в любое место в стопке. Но сама картинка тоже может быть сложной - аппликацией, и на ней тоже может быть куча слоев |
Цитата:
http://flasher.ru/forum/showpost.php...96&postcount=9 |
Цитата:
Цитата:
|
Код AS3:
То есть верх цепочки выглядит как Stage > Main > View. Далее идут компоненты View, то есть какие-то модули, добавляемые в контейнер-View. Например, ты сейчас смотришь форум в браузере? У браузера есть Окно, которое содержит Панель вкладок, Панель адреса, Панель поиска, Панель инструментов, и собственно окно в котором отображается контент (сайт), со скроллбаром. Все это компоненты. View их не рисует своими средствами. Кнопки сами себя рисуют, View только добавляет их в отображение или удаляет из него: как если бы View было столом, на который выкладываются предметы. Нужно показать Меню? Сделали во Вью addChild(_menu); Подписались на событие SELECT от меню. Получили событие — убрали меню из отображения, выяснили, что в нем выбрал юзер, показали то что он выбрал (или окно "сам дурак такого нет"). Как-то так, если вкратце не касаясь остальных друзей в MVC. |
Цитата:
Например проект игры на два экрана(игр. меню и игровой экран).Корневой контейнер не имеет визуального представления, но может содержать внутри себя другие визуальные объекты(DO) и другие контейнеры визуальных объектов(DOC).На старте приложения мы просто создаем объект корневого контейнера и говорим ему "поехали".Корневой DOC создает экран "главное меню" и добавляет его в себя.Для простоты будем считать что в меню всего одна кнопка-"старт".Меню слушает события от своих детей.Например при клике по кнопке,она испускает событие "click".Меню ловит это событие и должно оповестить корневой DOC.Меню шлет событие "start game" которое слушает корневой DOC.Корневой DOC уничтожает экран "меню",создает экран "игра" и помещает его в себя. Тут важно следить чтоб компоненты общались только со своими родителями т.е. корневой DOC должен реагировать только на события,отправленные его детьми(игр. меню и игровой экран).Т.е. не должно быть такого чтоб родитель родителя реагировал на события детей детей :).В данном примере это значит что корневой DOC не должен слушать событие "click" от кнопки старт. |
Цитата:
Цитата:
Понятно, что корневой DOC создаётся в основном классе приложения. Далее создаём специальный класс (пусть будет GameView) для эксклюзивного выполнения функции управления DO-компонентами, создаём экземпляр этого класса в главном классе, добавляем его там же в корневой DOC через addChild(). Теперь всё, что попадёт в контейнер GameView (что кстати будет этим контейнером, переменная типа Sprite?), будет выведено на экран. А вот дальше что? Например, у нас есть отдельный класс для меню. Он по логике также должен содержать контейнер. Плюс отдельный класс для кнопки меню, которая содержит загруженное изображение кнопки, либо её рисование программными средствами со всеми параметрами (цвета, линии и т.п.), не важно. Я понял на принципиальном уровне, что при выводе меню нам нужно поместить контейнер из класса "меню" в контейнер GameView, а потом уже в контейнер "меню" добавить какое-то число кнопок, по ситуации. Как это реализуется? Какие классы к каким обращаются для выполнения того, что я описал выше? Цитата:
|
Цитата:
Цитата:
Мы же стремимся думать в категориях ООП, верно? Каждый Объект является законченным самостоятельным модулем. Настолько, что он может использоваться в разных проектах, в идеале — вообще без каких-либо изменений. Вчастности, это означает, что GameView не будет добавлять какие-то ОТДЕЛЬНО существующие кнопки в меню, если ты представляешь себе это как _menu.addChild(_blueButton); Меню, скорее всего, позволяет себя НАСТРАИВАТЬ (для конкретной игры это необязательно, но в идеале да). То есть, при создании или после, Меню предоставляет возможность задать параметры — например список кнопок (всмысле их названий, текстов на кнопках). Получив все необходимые данные, Меню строит себя САМОСТОЯТЕЛЬНО, это его ответственность. Оно создает необходимое количество кнопок, распределяет их в "себе"-контейнере и подписывается на события нажатий. Когда кнопку нажмут, Меню(!) должно послать событие что юзер сделал выбор. На события наведение и увода мыши, нажатия и отпускания Кнопки должны уметь реагировать самостоятельно — это их ответственность. И, наконец, тот кто создал экземпляр Меню, подписывается на событие от Меню "юзер сделал выбор", и получив это событие, разбирается что делать дальше. Надо четко понимать где чья ответственность. Каждый элемент ниже по иерархии является самостоятельным в выполнении своей задачи ИНСТРУМЕНТОМ для того, кто выше: Кнопка должна уметь "нажиматься", Меню должно уметь предоставить выбор, тот кто создал меню — знать что делать с выбором. Это называется иерархия. Тот, кто ниже, обычно извещает того кто выше — своего создателя — о происходящих в нем изменениях, но РЕШЕНИЯ принимает только в своей области ответственности. То есть внутри Кнопки не содержится кода, запускающего игру. И в Меню его не содержится. Меню не запускает игру, это не его ответственность. |
Wolsh, спасибо. Исчерпывающе. Даже спросить больше нечего, только идти и пробовать :)
Мини-уточнение. Насколько я понимаю, все утилитарные функции, связанные с выводом (например, полная очистка экрана), делегируются классу View и реализуются через его соответствующие методы, верно? |
Цитата:
Цитата:
|
Цитата:
|
DOC - display object container. Он может быть как корневым, так и не корневым.
В любом случае добавлять/отцеплять display object'ы от дисплей-листа должен родительский для этих объектов контейнер. |
Ты бы на пару дней отбросил амбиции сходу написать игру, которая покорит весь мир, и попробовал силы в написании банальной кнопки, а затем менюшки с тремя-четырьмя этими кнопками.
У меня ученики начинают с CheckBox и RadioButton, затем RadioBar — о каком бы Варкрафте ни мечтали)). И на таких простейших компонентах прекрасно осознают львиную долю концепций ООП. Скучно, стыдно, но начинать надо с малого — оно в мозгу целиком помещается. |
Цитата:
Взять какого-нибудь персонажа в игре. Врага. Игрок убивает этого врага, и вот тут возникает вопрос, а как его удалить? Если пользоваться подходом, что только родитель должен удалять дочерние объекты, то этот враг должен (согласно парадигме флеша) послать событие о том, что он дожен удалиться. Это событие должен слушать родитель. По событию родитель находит целевой объект, отписывается от его событий и удаляет объект. Хотя все можно было сделать гораздо проще. Не оставлять никаких внешних ссылок на врага, а просто создать в нем метод destroy / dispose, в котором он может сам удалиться из дисплей листа. Никаких ненужных событий и лишних зависимостей. |
Цитата:
|
Цитата:
Я с ходу догадался, что ты преподаёшь :) Чувствуется стиль языка и манера изложения: последовательно, доходчиво и метафорично. У тебя книжек или туториалов нет? |
Wolsh,
Мне бы такого учителя в своё время.. Знания моего преподавателя ограничивались кодом на кнопке для перехода в нужный кадр. Цитата:
Всё-таки я тоже малась поддержу caseyryan, ну не всегда на практике получается строго придерживаться концепции Родитель -> Ребёнок. Это как с оператором goto в c++, его нужно стараться избегать всегда. Но где-то, единичное и умелое его применение может облегчить, упростить или ускорить выполнение кода. |
Цитата:
Код AS3:
Код AS3:
|
Вложений: 4
Цитата:
Цитата:
Цитата:
Цитата:
|
Цитата:
|
Цитата:
|
Цитата:
Цитата:
|
Цитата:
я не против удаления самого себя, но я думаю логичнее держать зеркальность добавление/удаление рядом. события в данном случае совсем ненужны, есть как минимум два разумных способа. пометить ребенка как доступный для удаления и в родителе в момент обновления удалить всех помеченных или добавить себя в список родителя для удаления, и родитель уже решит когда его удалить |
Цитата:
Я в общем-то не говорю, что подход "родитель удаляет ребенка" плохой. Я просто говорю, что он не является единственным верным, как многие считают. И подход "ребенок удаляет сам себя" тоже вполне рабочий и допустимый во многих случаях. А то у новичков может сложиться впечатление, что так делать ни в коем случае нельзя, а почему нельзя - не понятно. |
Цитата:
Код AS3:
|
Цитата:
Я бы лучше сделал статический аниматор, который принимает объекты применяющие интерфейс IUpdatable из которого объект тоже сам удаляется. Цитата:
|
я один не понимаю что страшного произойдет?Когда Enemy самоуничтожится,numChildren автоматически станет на 1 меньше и цикл либо продолжится дальше,либо остановится.
Добавлено через 24 минуты Гараздо неприятнее что такое самоудаление сдвигает весь dl |
Покойник сам на кладбище не ходит, его хоронят, так заведено.
Развели тут =) |
Цитата:
|
Друзья!
Дошёл я до ввода-вывода, по заветам мэтров начал с программирования кнопочек и менюшек. Возник идиотский вопрос, даже группа вопросов. Во-первых, файлы с растровыми изображениями можно загружать с помощью Loader-ов и с помощью тега метаданных [embed]. Разбирался, в чём их отличие. Пока единственное, что твёрдо усвоил и осознал, это тот факт, что Loader загружает изображение на этапе выполнения, а [embed] - на этапе компиляции. Делаю вывод, что если я планирую игру на flash, работающую в т.ч. оффлайн, то мой выбор, по всей видимости, - это "встраивание" графики на этапе компиляции, т.е. вариант [embed]. Верно? Во-вторых, с этим самым [embed] какой-то стрёмный синтаксис. Вот из нашего отца родного Колина Мука: Код AS3:
Наконец, какие есть рекомендации по загрузке, хранению и администрированию растровых изображений, используемых в приложении? Ведь их может быть много и даже очень много. Если для каждого выполнять последовательность действий из кода выше, то это будет огромная простыня и сумасшедшее количество переменных... |
Синтаксис стремный, потому что это не язык AS3, а команда компилятору.
Photo c заглавной буквы, потому что все классы именуют с заглавной. Компилятор создает автоматически класс-наследник Bitmap с "предустановленной" битмапдатой — Photo. Поэтому в дальнейшем ты можешь создавать сколько угодно экземпляров этого класса и обращаться с ними как с обычным Bitmap. Цитата:
Код AS3:
Код AS3:
Цитата:
Многие по возможности собирают много маленьких в одну большую — спрайтшит или атлас — и в рантайме "нарезают" ее на маленькие. Это особенно удобно, когда картинки являются кадрами какой-то секвенции или например иконками графического интерфейса; удобно, когда не нужен КЛАСС для каждой картинки, и даже отдельная переменная — когда можно хранить их в массиве. |
| Часовой пояс GMT +4, время: 02:44. |
Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.