|
Урок по созданию прогресс баров.
|
|
| pixeye | Дата: Воскресенье, 20 Февраля 2011, 16:00 | Сообщение # 1 |
Red Winter Software
Сейчас нет на сайте
| Часто встречал вопросы как сделать прогресс бар.
Области применения масса - отображение здоровья,маны, кол-ва энергии и тп. Если вы играли в diablo то наверняка видели подобное (стильные колбы со здоровьем и маной которые опустошались). Сделать себе такое же - не сложно. 1)
В фотошопе создаем текстуру 128 на 128. И заливаем ее например синем цветом.
 2)
Создаем альфа маску для нашей текстуры. Альфа маска может быть любой формы. ( От формы зависит узор, например можно сделать круговой прогресс бар ).
Мы же сделаем самый простой вариант: Горизонтальную линейку.
Вот маска. Ее добавляем в каналы (channels) в фотошопе. Текстуру сохраняем в формате .tif ( незнаю, у меня только с этим форматом нормально удалось сделать )
 Показ прогресс бара будет происходить от белого к черному. То есть слева направо. 3)
Создаем плашку ( plane) либо в unity3d, либо в максе. ( тогда соответственно экспортируем в юнити ) 4)
Cоздаем новый материал. Выставляем ему шейдер Transparent/Cutout/VertexLit 5)
Аттачим нашу текстуру с альфой к этому материалу. 6)
Cоздаем скрипт у нашего объекта-прогрессбара Code var health = 10;
var max_health = 100;
function Update ()
{
renderer.material.SetFloat("_Cutoff",Mathf.InverseLerp(max_health,0,health)); //1 параметр макс значение 2 параметр ноль или отправная величина, третий параметр текущее значение.
} Пример реализации health бара.
ACTORS - мой фреймворк на Unity
Until We Die - игра над которой работаю
Сообщение отредактировал pixeye - Воскресенье, 20 Февраля 2011, 16:04 |
|
|
| |
|
| pixeye | Дата: Воскресенье, 20 Февраля 2011, 16:51 | Сообщение # 3 |
|
Red Winter Software
Сейчас нет на сайте
| Quote (noTformaT) Просто и лаконично.
Но не знаю, плохо это или хорошо, но прийдется все время таскать плейн за камерой sad Насколько уже разобрался это неплохо. Я вообще все ГУИ на плейнах делаю. Игру пишу для айфона. А там говорят не дружат с встроенными функциями GUI (очень медленно работают).
Поэтому я делаю на плашках. Плашку в максе создаешь максимально простую на 4 вертикса. И все хорошо;-) Ну покрайней мере я не жалуюсь. Гуи так же привязываю к камере - всеравно весь гуи должен следовать за камерой, так что это нормально. А вот если что-то хочется скрыть..Ну никто не мешает вам этот плейн относительно объекта камеры отодвинуть в сторону за пределы видимости камеры.
ACTORS - мой фреймворк на Unity
Until We Die - игра над которой работаю
|
|
|
| |
| Левша | Дата: Понедельник, 21 Февраля 2011, 16:04 | Сообщение # 4 |
почти ветеран
Сейчас нет на сайте
| Quote (pixeye) А вот если что-то хочется скрыть..Ну никто не мешает вам этот плейн относительно объекта камеры отодвинуть в сторону за пределы видимости камеры.
Достаточно снять в скрипте галочку с рендера плашки. (и производительность выиграет). 
X.cor.R (Prologue)
Сообщение отредактировал Левша - Понедельник, 21 Февраля 2011, 16:06 |
|
|
| |
| pixeye | Дата: Понедельник, 21 Февраля 2011, 17:38 | Сообщение # 5 |
|
Red Winter Software
Сейчас нет на сайте
| Quote (Левша) Достаточно снять в скрипте галочку с рендера плашки. (и производительность выиграет). ну я как правило делаю так - визуально красиво убираю плашку гуи с области видимости камеры, после этого просто деактивируювсе что ненужно.)
ACTORS - мой фреймворк на Unity
Until We Die - игра над которой работаю
|
|
|
| |
| seaman | Дата: Понедельник, 21 Февраля 2011, 20:22 | Сообщение # 6 |
|
старожил
Сейчас нет на сайте
| Quote Достаточно снять в скрипте галочку с рендера плашки. (и производительность выиграет).
Сорри, я как то не понял. По сравнению с тем, что убрали из видимости камеры?
Это что получается в Юнити нет Фрустум кулинга? Чушь какая-то. Все что за пределами камеры не должно отправляться на рендер. Соответственно производительность не должна практически ни на грамм не измениться - убираем мы за пределы камеры или выключаем рендер. Ну может на микрограмм. Проверить попадают два триангла во фрустум все же дольше, чем проверить у объекта галочку рендера на пару десятков наносекунд...
|
|
|
| |
| pixeye | Дата: Понедельник, 21 Февраля 2011, 22:58 | Сообщение # 7 |
|
Red Winter Software
Сейчас нет на сайте
| Quote (seaman) Сорри, я как то не понял. По сравнению с тем, что убрали из видимости камеры?
Это что получается в Юнити нет Фрустум кулинга? Чушь какая-то. Все что за пределами камеры не должно отправляться на рендер. Соответственно производительность не должна практически ни на грамм не измениться - убираем мы за пределы камеры или выключаем рендер. Ну может на микрограмм. Проверить попадают два триангла во фрустум все же дольше, чем проверить у объекта галочку рендера на пару десятков наносекунд... Это правда. Если за пределами камеры объект он на рендер не отправляется. Ну может левша привык делать лишние действия;-)
ACTORS - мой фреймворк на Unity
Until We Die - игра над которой работаю
|
|
|
| |
| Левша | Дата: Понедельник, 21 Февраля 2011, 23:40 | Сообщение # 8 |
|
почти ветеран
Сейчас нет на сайте
| Quote (pixeye) Ну может левша привык делать лишние действия;-)
ИМХО лишнее это двигать плашку, (за исключением если это анимация или эффект), если ее просто нужно убрать из вида, проще все таки ее вырубить.
Впрочем лишь мое ИМХО. Quote (seaman) Проверить попадают два триангла во фрустум все же дольше, чем проверить у объекта галочку рендера на пару десятков наносекунд...
Все зависит от навороченности меню, для серьезных игр и меню соответствующее, и в таком случае можно получить чувствительный прирост.
А общая производительность игры складываеться как раз из всех учтенных мелочей, особенно для слабых машин. PS. pixeye, и совершенно лишнее отпускать глупые шутки, не вникнув в суть темы...
X.cor.R (Prologue)
Сообщение отредактировал Левша - Понедельник, 21 Февраля 2011, 23:46 |
|
|
| |
| pixeye | Дата: Вторник, 22 Февраля 2011, 06:08 | Сообщение # 9 |
|
Red Winter Software
Сейчас нет на сайте
| Quote (Левша)
ИМХО лишнее это двигать плашку, (за исключением если это анимация или эффект), если ее просто нужно убрать из вида, проще все таки ее вырубить.
Впрочем лишь мое ИМХО. smile То есть вы хотите сказать, что намного более красиво и понятно юзеру если плашка просто так исчезнет резко у вас на глазах?
"ну я как правило делаю так - визуально красиво убираю плашку гуи с области видимости камеры," Помойму это подходит под ваше определение анимации или эффекта. Quote Все зависит от навороченности меню, для серьезных игр и меню соответствующее, и в таком случае можно получить чувствительный прирост. Да нет разницы. (Даже если она есть минимальная, для того кол-ва объектов которые у меня на сцене это вообще не существенно). Оптимизация ради оптимизации - зло.
Чувствительный прирост возможен когда вы не используйте большое кол-во drawcall ов, как один из вариантов, что действительно влияет на производительность. PS.
ACTORS - мой фреймворк на Unity
Until We Die - игра над которой работаю
|
|
|
| |
| Левша | Дата: Вторник, 22 Февраля 2011, 14:26 | Сообщение # 10 |
|
почти ветеран
Сейчас нет на сайте
| Quote (pixeye) Оптимизация ради оптимизации - зло.
Оптимизация в любой игре - это важная часть концепта и стратегии разработки и злом быть никак не может не зависимо от целей. Quote (pixeye) Чувствительный прирост возможен когда вы не используйте большое кол-во drawcall ов, как один из вариантов, что действительно влияет на производительность.
И снова ошибочка pixeye, Не забываем что любая игра обрабатываеться не только видеокартой, но и остальным обородованием компьютера в т.ч. и CPU. И оптимизация кода играет далеко не последнюю роль в повышении производительности. Вы почемуто все сворачиваете на свою сценку, а я подразумеваю глобальные процессы игры. Наверно мы с Вами говорим о разных вещах.
Зло - это наплевательски относиться к оптимизации, делая игры заведомо тормозящие на средних машинах и отсекая от своих игр большую часть коммюнити..., хотя этого можно было бы избежать. Не все имеют 4 ядерные процы, море оперативы и навороченные карты. Производительность и расход ресурсов игрой так же важен как и ее графическая и геймплейная составляющая. Это называеться хорошо сбалансированная игра.
X.cor.R (Prologue)
Сообщение отредактировал Левша - Вторник, 22 Февраля 2011, 14:31 |
|
|
| |
| pixeye | Дата: Вторник, 22 Февраля 2011, 14:54 | Сообщение # 11 |
|
Red Winter Software
Сейчас нет на сайте
| Quote (Левша) Оптимизация в любой игре - это важная часть концепта и стратегии разработки и злом быть никак не может не зависимо от целей.
Перечитайте мою фразу. ГДЕ я написал что оптимизация зло? Я написал черно по белому - оптимизация ради оптимизации - ЗЛО. Это сродни анарексии - человек уже итак худее некуда, но уверен что он все еще толстый и продолжает себя насиловать, пока не превратится в скелет. Quote (Левша) И снова ошибочка pixeye, Не забываем что любая игра обрабатываеться не только видеокартой, но и остальным обородованием компьютера в т.ч. и CPU. И оптимизация кода играет далеко не последнюю роль в повышении производительности. Вы почемуто все сворачиваете на свою сценку, а я подразумеваю глобальные процессы игры. Наверно мы с Вами говорим о разных вещах.
Зло - это наплевательски относиться к оптимизации, делая игры заведомо тормозящие на средних машинах и отсекая от своих игр большую часть коммюнити..., хотя этого можно было бы избежать. Не все имеют 4 ядерные процы, море оперативы и навороченные карты. Производительность и расход ресурсов игрой так же важен как и ее графическая и геймплейная составляющая. Это называеться хорошо сбалансированная игра. Спасибо кэп. Я сворачиваю все на свою сценку тк изначально тема была создана о ней. Создавайте свою тему рядом и называйте ее оптимизация глобальных процессов игры. Есть поговорка. Она придумана не мной- самоучкой любителем, а профессионалом.
Преждевременная оптимизация - корень всех зол в программировании. В игре только процентов 30 кода влияет на производительность. Имеет смысл оптимизировать только критические куски кода или которые ведут к реальному замедлению исполнения программы. Код который за программу выполняется единожды вообще нет смысла оптимизировать. Любая оптимизация делает код менее гибким, а раз так то им сложнее пользоваться, а это не приемлимо если у тебя есть сроки, четко поставленные задачи. Особенно если в твоем коде должен разбираться попутно кто-то другой. Код должен быть гибким. Критические места должны быть оптимизированы.
ACTORS - мой фреймворк на Unity
Until We Die - игра над которой работаю
Сообщение отредактировал pixeye - Вторник, 22 Февраля 2011, 14:59 |
|
|
| |
@noTformaT
