Black_Star: пасиб, это буду пробовать.


mihanik: Привет! )
Ну, первый пример - ничего нового, а 100 mS это, конех, мало для слитного движения, а только типа моргания индикаторной лампочки.

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

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

Засунь ее тогда в исходник (в буфер какой-нибудь)...

Black_Star:
Попробовал твой код. К моему изумлению, реалтайм не дал ни малейшего прироста в равномерности, даже характер рывков остался прежним. 
  Вот такого варианта я никак не ожидал!..


Akina:
Попробовал - код выдает ошибку Run time error 6 Overflow в строке
Я не стал тратить силы на вылавливание этой ошибки (вечер перешел в ночь уже), и попробовал изобразить собственный вариант с хорошо знакомой мне бейсиковой функцией Timer, благо ее период (55ms) близок к нужному мне.



Здесь NextFrame - Это код смены кадра, приведенный мной в самом начале темы. Хотя лишний Call чуть замедляет выполнение, но облегчает отладку. Да!,- и там в конце добавлено DoEvents, потому что без него кадры не отрисовываются. При запуске таймером отрисовывались сами,  а в цикле - не отрисовываются без DoEvents.
Цикл For применен, чтобы обезопаситься от бесконечного цикла (с которыми в VB головная боль).

то, что я увидел, запустив, изумило меня еще больше! Рисунок мгновенно повертывался на пол-оборота с максимально возможной скоростью (порядка за десятую секунды) и застывал затем на 2 секунды. Потом опять пол-оборота и стоп. Клянусь, сам не поверил бы, если б не видел. (Приводимый здесь код прямо копирован из VB.) Вставка дополнительного DoEvents внутрь цикла Do картины не изменила.
Тогда я вместо цикла Do поставил для проверки паузу Sleep 40. Сразу же пошло нормальное вращение, но как и прежде, с небольшими рывками. (Кстати, Sleep адекватно работал даже на интервале 5, давая очень быстрое вращение, в отличие от стандартного таймера.)

Каким образом Do - Loop мог застревать на две секунды - для меня полная загадка! Всё, уже ночь, больше не могу, гашу машину и отрубаюсь.


Это сообщение отредактировал(а) cardinal - 2.8.2007, 15:19

Из темы: Скорость инициализации переменных



Можно в native. (Project > Properties > Comile > Compile to Native Code). 
Само собой прирост будет. У меня доходило до того, что прирост составлят чуть ли не в два раза по сравнению с пикодом. 

JusTalionis, у тебя был код без посдветки - я поменял...  

W4FhLF
Ааа, ты про это! Посмотрел. Стоит опция Native. Но компилится все равно не в нормальный машинный код (как, например, досовский екзешник); я и думал, что это P-код.
А для сравнения переключил в P и посмотрел, что будет. Размер екзешника сделался чуть меньше, потому что в нем не стало списка всех употребленных имен. Но на скорости в данном случае почему-то не отразилось; и, что плохо - на равномерности не отразилось (скорости-то мне хватает, запас есть).
А еще поигрался с флажками отмены всяческих защит - тоже никакого видимого эффекта, как и при смене опций оптимизации (изначально стояло "оптимизировать скорость").

Практически никакие установки VB не влияют существенно - и я думаю, что дело в самой работе ОС. Но ведь кино нормально на этой самой машине смотрится, а там площадь кадра - ого-го, по сравнению с моей картиночкой - а оно без рывков крутится (да еще ресурс на декодирование звука ведь берется). Можно значит, если правильно делать?!..

P-CODE исполняется на виртуальной машине msvbvm, остальное всё машинный код. Не знаю, что ты подразумеваешь под словом "ненормальный". 




ОС я бы стал винить в последнем случае, А ТЕМ БОЛЕЕ, если ты пишешь на VB. Вот тебе для сравнения, простейшая программа на VB:



Компилятор превращает это всё в такое вот машинное чудо:



Без комментариев вообще, это просто ужоснах

Теперь вариант на С/С++:



Скомпилированный GCC такой код превращается в следующий аналог машинного:



Достаточно плохая оптимизация, а точнее такое впечатление, что её вообще нет. Хотя флаг /O стоял. 

Теперь гвоздь программы, MS VS C++ 7.1:



Очень красивый код, хорошо оптимизирован, но не предел  Ручками можно было бы выжать ещё. 

Делай выводы. Это элементарная рекурсия и арифметика. То, что творится с объектами и строками ещё хуже. 

Я в курсе. Но, тем не мненее, впечатляет. Да еще если развернуть все задействованные рутины MSVBVM...
Я в ассемблере рублю чуть-чуть, но он же машинно-зависимый, так что если я чё написал и у меня работает - еще не факт, что заработает на другом компе. По этой причине предпочитаю все же Бейсик (хотя у VB с переносимостью - крупные траблы :( ) Ну в большинстве случаев VB все же позволяет строить внешне сносные программки, за исключением вот таких вот узкоспециальных случаев. Да собсно на форуме таковые и разбираются.
Вот и вопрос: существует ли путь в данном частном случае повысить равномерность? Главное - непонятно: что именно вносит лишнюю задержку, чтоб убрать или обойти это место.
Кстати, наблюдаю интересное проявление: когда программа запущена, и рисунок начинает крутиться, сначала он движется весьма неравномерно, скачками. Но пройдя три-четыре оборота, как будто "входит в режим", остаются один-два рывка в обороте. Не знаю почему такое. Причем повторяется только в среднем: когда может дергаться больше, когда - меньше.
А работа функции Timer меня вообще убила. Вы прочитали выше? А вот интересно, ведь в BIOS есть прерывание, на котором всё это и базируется... нельзя ли его сюда привлечь?

Он процессорнозависимый, то есть от набора команд, которые понимает конкретный процессор.

Как уже сказано выше, всё зависит от того под какой камень ты пишешь. пишешь под ARM, заработает на всех арм'ах, пишешь под x86(x64) заработает на них.



Я, честно говоря, не смотрел твой пример. Может есть смысл глянуть тебе под профайлером? Локализуешь место. 



Это кеширование. 

А архитектура компа? Особенности шины, BIOSа? Когда я занимался этим, это было как раз первое на что я и напоролся: на разных компах устройства работали чуточку не так. Где-то требовалась только определенная последовательность, а где-то допускались и другие (типа записи в незадействованные биты регистра), где-то между командами требовалась некоторая задержка, и тому подобное. Но результат был один: что работало на одном компе - висло на другом.
Так что, чтоб писать на ассемблере, надо наперечет знать ВСЕ эти нюансы, то есть быть профессионалом неслабым.
А работа с видеокарточкой, особенно в высоких разрешениях? На асме никто не пробовал для прикола?  

JusTalionis, то, что ты описываешь похоже на программирование времён начала-середины 90х или конца 80х. Сейчас в целом всё стандартизировано и существуют интерфейсы предоставляемые ОС даже на самых низких уровнях. Короче тех проблем, что ты описал сейчас практически не существует. 

Да, эт давно было, я под дос писал. 
 А может все-таки посмотреть? А то за оффтоп Акина щас громы и молнии метать начнет ;))

Прикрепи проект с картинками. 

JusTalionis, то есть один и тот же ассмеблер-код на одном работал, на другом нет? Ну в принципе конечно возможно, но это уже говорит только о плохой схеме, т.к. ассемблер как таковой то воспринимался. Если одна плата при этом все успевает, а вторая нет, то это проблемы второй платы, а не твои как разработчика по. На самом деле это конечно автоматом становится твоей проблемой...