Pull to refresh

Comments 27

UFO landed and left these words here
Максимальная скорость машинки 745 чего то/час))
Если учитывать то, что мы еще ловим нажатие мыши по машинке, а в обработчике увеличиваем скорость на 300 у.е., я добивался до 1100 ;)
Многочисленными кликами разгонял до 1500.
Полное обездвиживание объекта =(
image
Я так понимаю, что этот же код можно переложить на WP7?
Кроме устройства ввода (клавиатуру), что нужно будет ещё доделывать?
Изначально пример хотел делать на WP7, но т.к. на эмуляторе не нажать сразу несколько кнопок(мышью по крайне мере), решил под браузер.
При испытание проблем не возникло, все так же анимировалось. Код, не считая куска работы с клавиатурой, почти полностью с примера на WP7.
UFO landed and left these words here
UFO landed and left these words here
UFO landed and left these words here
SL не может не быть. А ваши мечты лишь эхо желаний адоба.
ИМХО, SL уже есть в WP7 и обязательно будет на планшетах под W8
О майнготт, тысячу раз уже обсуждалось, а люди никак не уймутся.
Silverlight останется и будет в вин8. WPF тоже останется и тоже будет в вин8. Ничего не убирают из API, только добавляют.
Недавно новая версия вышла, так же обещали обновлять в будущем.
> System.Threading.Timer – работающий в отдельном потоке.
Насколько мне известно в SL все работает в одном потоке.
Странно… Почему-то был уверен, что настоящей мультипоточности нет в SL. Давно данную тему не исследовал. Сейчас не нахожу подтверждения.
Под отдельным потоком подразумевался, не поток UI.
Если обратиться из такого потока напрямую к свойствам элемента интерфейса, будет ошибка меж потокового доступа(cross-thread access).
В System.Windows.Threading.DispatcherTimer можно по обычному с UI работать, но если вычисления длительные, интерфейс будут подвисать. Все как в настольных приложениях.

Внутреннее(физическое) устройства потоков в Silverlight мне не известно. Но снаружи, в плане программных манипуляций, все вполне многопоточно и асинхронно. Работают же многозадачные ОС на одно ядерных машинах)
Вот я раньше так и думал, что в SL под потоками понимается нечто свое, искусственно введенное для имитации потоковости. Но после отправки коммента решил все-таки снова поисследовать тему. В итоге прочитал, что, вроде, DispatcherTimer создает лиш имитацию — генерирует некие Tick'и по которым таски разделяются во времени. Однако BackgroundWorker'ы работают взаправду многопотоково. Даже видел пруф в виде скрина менеджера задач, где загружены оба ядра процессора для двупоточной реализации SL-вычислений (считались рпайм-числа).
Так что в итоге в непонятках. Нужно самому проверять. Если истинной многопоточности нет, то смысл в параллельном программировании в SL особого не вижу. Один лишь кейс — разблокировка UI, да и та будет неполной.
Так и так потоки хорошо усложняют код, как в плане читаемости, так и тестируемость. И если нет, действительно важной причины на их использование(как понимаю, тут идет речь о больших вычислениях, как цель применения потоков), то тоже не вижу в них смысла. Тем более, это все таки Web, сильно суровыми вычислениями, насиловать компьютеры пользователей не принято.
Вот и мне кажется в данном случае нецелесообразным использование потоков.
У меня машинка какая-то дёрганая. На больших скоростях и без поворотов особенно заметно. Примерно каждые полсекунды рывок, то есть движение выглядит не плавным. Отчего так?
fps прыгает или низкий. Т.к. пройденное расстояние зависит от времени прошедшее с предыдущего кадра. Т.е. машина за секунду, что за 60, что за 5 кадров пройдет примерно одно и то же расстояние(напомню, время между кадрами разное). Но глаз не обманешь, не которые шажки будут короче, некоторые длиннее.
Плюс, алгоритм вычисления скорости, зависит от значения самой скорости. От скорости отнимается 40 процентов ее значения. Это дает лишнею привязку к частоте кадров.
> Но глаз не обманешь,…

Как вариант, как раз обман глаза может спасти ситуацию: на длинные прыжки нарисовать две машины, одну на текущий момент и одну на предыдущий.
В принципе, если присмотреться за машиной, при высокой скорости остается шлейф(полупрозрачный хвостик), при скриншотах все чисто. Хвостик и есть обман зрения и вторая машина.
Идея интересная, но сработает ли, можно проверить только на практике.
А можно заюзать WriteableBitmapEx и реализовать блиттинг, т.е. новый кадр отрисовывать накладывая на него с темно-серой маской предыдущий. Как раз появится мягкий шлейф, не нужно будет отрисовывать одну (две или более) машинок. К тому же на сложных сценах подобное битмап-кэширование улучшить сможет производительность.
Only those users with full accounts are able to leave comments. Log in, please.