
В этой записи решил рассказать о нативных курсорах на Flash платформе. О их преимуществах и собственно как их реализовать.
Часто стал замечал, что во многих играх разработчики используют свои курсоры. Особенно если игра не может обойтись обычным системным курсором (различные квесты, hiden objects и другие игры где нужно менять состояние курсора для большей интуитивности в игре). Это безусловно можно отнести к плюсам конечной игры. Но, то что мне не нравится в таком подходе, так это подтормаживание тех самых курсоров. Возможно через 10 минут игры об этом и забывается, но поначалу приходят только негативные эмоции, т.к. кажется, что игра работает не на максимуме FPS.
Также в играх, где пользователю приходится что-то быстро нажимать и на что-то быстро реагировать мышкой, геймплей начинает казаться слегка замедленным, будто желе двигаешь, а не мышь:) Этот неприятный эффект мы и попытаемся устранить.
Это как?
Всего есть 2 способа заменить системный белый курсор своим:
- Мы создаем MovieClip, добавляем событие MOUSE_MOVE (которое возникает при движении мыши) и дальше просто присваиваем координаты нашему курсору
Mouse.hide(); //Прячем системный курсор
myCursor = new MyCursor(); // Создаем свой
addChild(myCursor);
addEventListener(MouseEvent.MOUSE_MOVE, mouseMove); // Добавляем слушатель события
private function mouseMove(e:MouseEvent):void {
myCursor.x = e.stageX; // Задаем x нашему курсору
myCursor.y = e.stageY; // Задаем y нашему курсору
e.updateAfterEvent(); // Дополнительно делаем обновление
}
//И хоть мы дополнительно вызываем метод updateAfterEvent(), 100% скорости курсора этим способом не добиться.
- Второй способ намного лучше первого. С его помощью можно добиться идеальной скорости курсора. Функционал для данного метода добавлен уже в 10.2 версии флешплеера, но как и писал выше не многие им пользуются. Этот способ мы и будем реализовывать. Идем дальше.
Наглядный пример
Комментарии (10)
1. Честно говоря, не сталкивался с проблемой «торможения» кастомного курсора. Хотя проблему встречал в вопросах на разных форумах. Она, как обычно «в голове». Возникакет из-за непонимания механизмов работы плеера: она будет в любом случае, т.к. завязана на ФПС мувика. Ну не сможете вы физически рендерить в мувике с пфс около 30 (обычно, а дефолтно вроде 15 стоит вообще) свою картинку курсора с такой-же частотой как и нативный, который с частотой обновления экрана рендерится (50...100+ фпс). Т.е. эту проблему решить радикально можно только нативным кодом плеера.
2. Дефолтный курсор тоже можно менять комбинацией флагов у спрайта buttonMode и useHandCursor — ленивый метод такой…
Но чтобы быть честным, собственный класс нормального кастомного курсора с двумя состояними занимает у меня больше, чем приведенные в начале 9 строк. Но работает норм и при контекстном меню и при выходах за мувик и прочих замеченных «тонкостях» (вот кстати на флешке-примере можно попробовать с контекстным меню в зоне ненативного кастомного курсора… и еще там кастомный не пропадает при выходе за мувик...).
Сложности — написал 1 раз и используй везде. Но когда за тебя уже все написали, еще и правильно, то оно конечно же лучше. Хотя автор все-же «написал несколько классов» даже и для такого случая :)
В любом случае — автору спасибо за пост и исходники.
Оперу и ИЕ не проверял.
А теперь? (по той же ссылке)
OS X:
Если в теге embed-флеша прописано:
wmode: «opaque» либо wmode: «transparent», то начинается конфликт с курсором.
Соответственно опции window, direct и gpu работают более стабильно.
Windows:
Chrome, FireFox — работает без проблем с любым тегом.
Opera:
wmode: «opaque» — мерцает курсор.
wmode: «transparent» — мерцает курсор.
wmode: «window» — идеально
wmode: «direct» — идеально
wmode: «gpu» — идеально
Слава богу на порталах не используются «opaque» и «transparent». При том очень малая доля людей с Mac'ами играют в флеш. Поэтому думаю можно использовать и не обращать внимания на редкие глюки у небольшого процента аудитории.