С наступившим!

Цитата Сообщение от CityAceE Посмотреть сообщение
Да, никакую задержку я осознанно не ставил, так как замедлять тут нечего - чем быстрее работает скрипт, тем неограниченно быстрее будет крутиться эмулятор. В холостую тут ничего не крутится и процессор больше положенного не грузит. В настоящий момент на моих компьютерах эмулятор не догоняет по скорости реальный Специалист.
Мне показалось, что тут есть некоторое противоречие, поэтому включаю режим капитана Очевидность и заранее прошу прощения. Задержка в современном понимании -- это засыпание процесса до какого-то события, обычно таймера. Если нет задержки, значит основной цикл крутится постоянно, не отдавая времени системе вообще. pygame.Clock.tick() отмеряет время между вызовами, и включает задержку, если они случаются чаще, чем указанный fps. То, что Python.exe не показывает 100% в Диспетчере задач, так это потому что проц многоядерный. Если ядра 4, там покажется 25%. 25% проца, но 100% одного ядра.

У меня с моими изменениями загрузка опускается до где-то 20%, хотя не всегда. То есть, если реальный Специалист делает INT_TICKS за 1/50 сек, у меня он уже догоняет реал и оставляет 1/5 времени. Убедиться в том, что в принципе tick() отдает время системе, можно сбросив INT_TICKS в два раза, например - тогда моя загрузка падает до 12%. Убедиться в том, что tick() именно уступает время, можно заменив tick() на tick_busy_loop(), который делает задержку, крутясь в цикле -- тогда загрузка не меняется.

Разумеется плюсы всего этого не получается ощутить, если эмулятор не успевает прогнать свои INT_TICKS за кадр. Надо либо апгрейдить компьютер, либо улучшать эмулятор. Эмулятор по-моему пока еще оставляет много возможностей для улучшения

Цитата Сообщение от CityAceE Посмотреть сообщение
Используя твой способ, я попробовал обновлять экран только в случае изменений на нём, но скорости это практически не добавило, хотя в сцене из ZOO можно пропустить порядка 1500 кадров, которые не имеют отличий. Всё сжирают проверки изменений. Однако, существенный минус твоего способа для меня лично состоит в дополнительном использовании numpy. Мне хотелось обойтись только одной внешней библиотекой pygame.
По-моему экономить на рефреше экрана в эмуляторах это не лучший выбор, потому что он должен крутиться исправно в самом сложном случае. Эта игра нечасто обновляет кадры, а что делать в той, которая обновляет каждый кадр?

В любом случае, процедуры преобразования битмапов хорошо оптимизированы (хаха, это неправда, но на Питоне лучше не сделаешь), а битмапы тут крошечные. Обновление плоскости одним вызовом можно написать и на голом Питоне. Будет не так эффективно, но все равно должно получиться быстрее, чем ставить точечки поштучно.

Цитата Сообщение от CityAceE Посмотреть сообщение
В общем, svofski, спасибо, что заморочился и помогаешь улучшить скрипт!
Меня просто удивило, что для Питона Специалист оказался почти неподъемным. Хотя, казалось бы...

Я попробовал копнуть в сторону профайлинга, чего я с Питоном никогда не делал, но столкнулся с какой-то непробиваемой стеной устаревшего и глючного. Один раз получилось получить профайл, который загрузился в kcachegrind, но повторить я это не смог.