Куда девается время?!

[IDOL 1234]

Что-то не так с циклом задержки. Очень много времени расходует свыше отведённых 50 мс. Посмотрите пожалуйста
repeat
...

repeat
delay(1);
until(lastSavedTime-GetRelativeTimeMs<-50);
lastSavedTime:=GetRelativeTimeMs;

...
until(false);
Цикл выполняется 4-5 раз и жрёт где-то 63 мс. При том, что все остальные команды,находящиеся в основном цикле, расходуют 15-30 мс,

[cherepets]

ты философ))))

я обычно делаю так:
delay(getRelativeTimeMs-lastSavedTime);

вроде потерь не замечал, хотя никогда особо и не мерял

[Dj_Alex]

вообще нужно эту разницу брать по модулю, т.к. getRelativeTimeMs возвращает в диапазоне от -2^31 до 2^31, т.е. может принимать отрицательные значения

[IDOL 1234]

Ненавижу философию... А модуль я отсюда стёр, чтобы некоторые особо умные не говорили, что это он тормозит (на всякий случай: я не о присутствующих)
delay(getRelativeTimeMs-lastSavedTime); - а как это работает? Идею понял, но всё же что-то не то... Может, что-то вроде delay(50-abs(getRelativeTimeMs-lastSavedTime)); ?



И ещё вопрос по этой теме: нельзя ли выводить на экран графическую инфу, координаты которой хранятся в типе REAL, не используя тормознутый TRUNC?

[cherepets]

а, ну да)) ты прав. только без модуля я обычно делаю заранее проверив что число >0.

[Dj_Alex]

Сообщение от IDOL 1234

И ещё вопрос по этой теме: нельзя ли выводить на экран графическую инфу, координаты которой хранятся в типе REAL, не используя тормознутый TRUNC?

чем это trunc тормознут, он ж вроде только отбрасывает дробную часть.
а вообще координаты для графики нужны в int, т.к. пиксель ето дискретная штука

[Ksanatos]

trunc округляет число, потому и тормознут.
Делай что-то вроде такого y:=x-frac(x);

это я вычитал в хелпе от odd по мойму

[cherepets]

trunc только отбрасывает. округляет round (не уверен в наличии его в МП).
в любом случае, real у меня всегда выходит только при делении, а значит проще делить div'ом чем округлять/отбрасывать.