zabil Jul 27 2011 at 14:51

Игровой цикл в Silverlight

9 min

4.3K

Silverlight*

From sandbox

+14

Comments 27

UFO just landed and posted this here

BaHeK Jul 27 2011 at 18:56

Максимальная скорость машинки 745 чего то/час))

Frozik Jul 27 2011 at 20:53

У меня 744.7

4ekin Jul 27 2011 at 23:02

Если учитывать то, что мы еще ловим нажатие мыши по машинке, а в обработчике увеличиваем скорость на 300 у.е., я добивался до 1100 ;)

s1im Jul 28 2011 at 07:55

Многочисленными кликами разгонял до 1500.

BaHeK Jul 27 2011 at 19:02

Полное обездвиживание объекта =(

apih Jul 27 2011 at 19:58

Я так понимаю, что этот же код можно переложить на WP7?
Кроме устройства ввода (клавиатуру), что нужно будет ещё доделывать?

zabil Jul 28 2011 at 08:01

Изначально пример хотел делать на WP7, но т.к. на эмуляторе не нажать сразу несколько кнопок(мышью по крайне мере), решил под браузер.
При испытание проблем не возникло, все так же анимировалось. Код, не считая куска работы с клавиатурой, почти полностью с примера на WP7.

UFO just landed and posted this here

ApeCoder Jul 28 2011 at 06:28

пруфлинк?

UFO just landed and posted this here

ApeCoder Jul 28 2011 at 19:49

Извините, а где пруфлинк-то? Слухи только.

Есть и другие слухи

Danov Jul 28 2011 at 08:15

SL не может не быть. А ваши мечты лишь эхо желаний адоба.
ИМХО, SL уже есть в WP7 и обязательно будет на планшетах под W8

Skiminok Jul 28 2011 at 09:46

О майнготт, тысячу раз уже обсуждалось, а люди никак не уймутся.
Silverlight останется и будет в вин8. WPF тоже останется и тоже будет в вин8. Ничего не убирают из API, только добавляют.

KilgortTraut Jul 28 2011 at 09:49

Недавно новая версия вышла, так же обещали обновлять в будущем.

HomoLuden Jul 28 2011 at 10:58

> System.Threading.Timer – работающий в отдельном потоке.
Насколько мне известно в SL все работает в одном потоке.

HomoLuden Jul 28 2011 at 11:17

Странно… Почему-то был уверен, что настоящей мультипоточности нет в SL. Давно данную тему не исследовал. Сейчас не нахожу подтверждения.

zabil Jul 28 2011 at 11:17

Под отдельным потоком подразумевался, не поток UI.
Если обратиться из такого потока напрямую к свойствам элемента интерфейса, будет ошибка меж потокового доступа(cross-thread access).
В System.Windows.Threading.DispatcherTimer можно по обычному с UI работать, но если вычисления длительные, интерфейс будут подвисать. Все как в настольных приложениях.

Внутреннее(физическое) устройства потоков в Silverlight мне не известно. Но снаружи, в плане программных манипуляций, все вполне многопоточно и асинхронно. Работают же многозадачные ОС на одно ядерных машинах)

HomoLuden Jul 28 2011 at 15:12

Вот я раньше так и думал, что в SL под потоками понимается нечто свое, искусственно введенное для имитации потоковости. Но после отправки коммента решил все-таки снова поисследовать тему. В итоге прочитал, что, вроде, DispatcherTimer создает лиш имитацию — генерирует некие Tick'и по которым таски разделяются во времени. Однако BackgroundWorker'ы работают взаправду многопотоково. Даже видел пруф в виде скрина менеджера задач, где загружены оба ядра процессора для двупоточной реализации SL-вычислений (считались рпайм-числа).
Так что в итоге в непонятках. Нужно самому проверять. Если истинной многопоточности нет, то смысл в параллельном программировании в SL особого не вижу. Один лишь кейс — разблокировка UI, да и та будет неполной.

zabil Jul 28 2011 at 17:19

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

HomoLuden Aug 1 2011 at 09:27

Вот и мне кажется в данном случае нецелесообразным использование потоков.

dzhidaj Jul 28 2011 at 13:41

У меня машинка какая-то дёрганая. На больших скоростях и без поворотов особенно заметно. Примерно каждые полсекунды рывок, то есть движение выглядит не плавным. Отчего так?

zabil Jul 28 2011 at 17:01

fps прыгает или низкий. Т.к. пройденное расстояние зависит от времени прошедшее с предыдущего кадра. Т.е. машина за секунду, что за 60, что за 5 кадров пройдет примерно одно и то же расстояние(напомню, время между кадрами разное). Но глаз не обманешь, не которые шажки будут короче, некоторые длиннее.
Плюс, алгоритм вычисления скорости, зависит от значения самой скорости. От скорости отнимается 40 процентов ее значения. Это дает лишнею привязку к частоте кадров.

Danov Jul 29 2011 at 15:55

> Но глаз не обманешь,…

Как вариант, как раз обман глаза может спасти ситуацию: на длинные прыжки нарисовать две машины, одну на текущий момент и одну на предыдущий.

zabil Jul 29 2011 at 16:17

В принципе, если присмотреться за машиной, при высокой скорости остается шлейф(полупрозрачный хвостик), при скриншотах все чисто. Хвостик и есть обман зрения и вторая машина.
Идея интересная, но сработает ли, можно проверить только на практике.

HomoLuden Aug 1 2011 at 09:31

А можно заюзать WriteableBitmapEx и реализовать блиттинг, т.е. новый кадр отрисовывать накладывая на него с темно-серой маской предыдущий. Как раз появится мягкий шлейф, не нужно будет отрисовывать одну (две или более) машинок. К тому же на сложных сценах подобное битмап-кэширование улучшить сможет производительность.

Show the best of all time