On 1 Gru, 08:44, " fir" <f...@W...gazeta.pl> wrote:

> pamietam jak czyta em pthreads primer to autor wspomina tam o tzw
> 'mitycznych realtime folks' Warto by dowiedziec sie czegos nt tego od czego
> zalez te piki i spowolnienia. Swego czasu nawet c64 bylo maszyn realtime

Po pierwsze tam nie bylo wielozadaniowego OSa - zadnego shedulera i
(pomijajac przerwania) zadnego wywlaszczania Twojego programu na rzecz
innych, wiec co to wlasciwie za porownanie?

> teraz winda nie jest i to jest smutne!

Nie, to jest normalne.

> to co mi jest potrzebne to po prostu wysoki stopie p ynno ci,
> spodziewam sie ze moge dorownywac jakimis mikrosleepami w g r np
> do granicy 10 milisekund ale chyba i tak jak cos w tle sie podzieje
> to b dzie rwa

Jakie wyrownywanie??? Po prostu nie animujesz scrolla ze stalym
krokiem, tylko zaleznie od tego, ile czasu uplynelo od ostatniego
rysowania. Wszystko chodzi plynnie i z ta sama predkoscia na roznych
prockach. A to, ze fps bedzie plywal, nie ma znaczenia. Sa
zastosowania, gdzie realtime jest niezbedny - ale na litosc nie do
prostego scrolla...

do góry

W dniu 01.12.2010 21:15, thearti pisze:
> Jakie wyrownywanie??? Po prostu nie animujesz scrolla ze stalym
> krokiem, tylko zaleznie od tego, ile czasu uplynelo od ostatniego
> rysowania. Wszystko chodzi plynnie i z ta sama predkoscia na roznych
> prockach. A to, ze fps bedzie plywal, nie ma znaczenia. Sa
> zastosowania, gdzie realtime jest niezbedny - ale na litosc nie do
> prostego scrolla...
Dodajmy jeszcze, że nie opłaca się marnować mocy obliczeniowej na
szybsze rysowanie niż wynosi częstotliwość odśnieżania monitora.

--
Pozdrawiam
Michoo

do góry

thearti wrote:

>> to co mi jest potrzebne to po prostu wysoki stopie p ynno ci,
>> spodziewam sie ze moge dorownywac jakimis mikrosleepami w g r np
>> do granicy 10 milisekund ale chyba i tak jak cos w tle sie podzieje
>> to b dzie rwa
>
> Jakie wyrownywanie??? Po prostu nie animujesz scrolla ze stalym
> krokiem, tylko zaleznie od tego, ile czasu uplynelo od ostatniego
> rysowania. Wszystko chodzi plynnie i z ta sama predkoscia na roznych
> prockach.

Takie rozwiązanie nie chodzi płynnie.
Aby rzeczywiście chodziło płynnie, trzeba wyświetlać klatki w równych
odstępach - synchronizowanych cyklem odświeżania monitora przez kartę
graficzną. Jeśli którąś klatkę się zgubi - utrata płynności jest wyraźnie
widoczna.

> A to, ze fps bedzie plywal, nie ma znaczenia. Sa
> zastosowania, gdzie realtime jest niezbedny - ale na litosc nie do
> prostego scrolla...

Niestety prosty scroll wygląda źle, gdy fps pływa. Niektórym to przeszkadza.
Mnie osobiście też denerwuje, jeśli na szybkim komputerze nawet z pozoru tak
prosta rzecz jak scroll nie działa poprawnie.

do góry

Wojciech Jaczewski <w...@o...pl> napisał(a):
> Takie rozwiązanie nie chodzi płynnie.
> Aby rzeczywiście chodziło płynnie, trzeba wyświetlać klatki w równych
> odstępach - synchronizowanych cyklem odświeżania monitora przez kartę
> graficzną. Jeśli którąś klatkę się zgubi - utrata płynności jest wyraźnie
> widoczna.

To jakie Ty masz odświeżanie monitora? 10Hz?

--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 28 days, 16 hours, 7 minutes and 17 seconds

do góry

Mariusz Marszałkowski <m...@g...com> napisał(a):

> On 1 Gru, 08:59, " fir" <f...@W...gazeta.pl> wrote:
> > w acznie z tym co winda mi wtryni pod spodem
>
> Ok, ale dlaczego wazny jest dla Ciebie czas wykonania nie
> Twojego kodu, tylko kodu czegos czemu winnda odda na
> nie wiadomo jak dlugo sterowanie?
>
> Pozdrawiam

nie wiem czego tu mozna nie rozumiec - interesuje mnie faktyczny czas
wykonywania sie mojego progsa (realny) - od tego realnego czasu (z
wtrętami z systemu) zalezy płynnośc progsa


fir

--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

epsilon$ while read LINE; do echo \>"$LINE"; done < " Parade"
>> > w acznie z tym co winda mi wtryni pod spodem
>> Ok, ale dlaczego wazny jest dla Ciebie czas wykonania nie
>> Twojego kodu, tylko kodu czegos czemu winnda odda na
>> nie wiadomo jak dlugo sterowanie?
>nie wiem czego tu mozna nie rozumiec - interesuje mnie faktyczny czas
>wykonywania sie mojego progsa (realny) - od tego realnego czasu (z
>wtrętami z systemu) zalezy płynnośc progsa

Ale zdajesz sobie sprawę z tego jak działa windows? W szczególności, jak
wygląda zarządzanie procesami?

--
[------------------------]
[ K...@e...eu.org ]
[ http://epsilon.eu.org/ ]
[------------------------]

do góry

Wojciech Jaczewski <w...@o...pl> napisał(a):

> thearti wrote:
>
> >> to co mi jest potrzebne to po prostu wysoki stopie p ynno ci,
> >> spodziewam sie ze moge dorownywac jakimis mikrosleepami w g r np
> >> do granicy 10 milisekund ale chyba i tak jak cos w tle sie podzieje
> >> to b dzie rwa
> >
> > Jakie wyrownywanie??? Po prostu nie animujesz scrolla ze stalym
> > krokiem, tylko zaleznie od tego, ile czasu uplynelo od ostatniego
> > rysowania. Wszystko chodzi plynnie i z ta sama predkoscia na roznych
> > prockach.
>
> Takie rozwiązanie nie chodzi płynnie.
> Aby rzeczywiście chodziło płynnie, trzeba wyświetlać klatki w równych
> odstępach - synchronizowanych cyklem odświeżania monitora przez kartę
> graficzną. Jeśli którąś klatkę się zgubi - utrata płynności jest wyraźnie
> widoczna.
>
> > A to, ze fps bedzie plywal, nie ma znaczenia. Sa
> > zastosowania, gdzie realtime jest niezbedny - ale na litosc nie do
> > prostego scrolla...
>
> Niestety prosty scroll wygląda źle, gdy fps pływa. Niektórym to
przeszkadza.
> Mnie osobiście też denerwuje, jeśli na szybkim komputerze nawet z pozoru
tak
> prosta rzecz jak scroll nie działa poprawnie.
>

yo, nawet w komercyjnych programach za grube miliony (o ile dobrze
pamiętam) jak photoshop czy itunes, scrolle (pionowe z listami nazwisk)
czasem nie wyglądają za dobrze - pominąwszy temat kasy (bo ja na kase nie
jestem specjalnie łasy) też wydaje mi się że taki scroll liczony po czasach
nie wygladałby dobrze - wygladałby dobrze gdyby nie było kwantyzacji, a
jest zarowno 1) 'kwantyzacja czasowa' (ramek - biorąca się z częstotliwosci
odświerzania [PYTANIE: Jak to jest z monitorami LCD? nie wiem jak to jest,
teoretycznie być moze powinien być szał] jak i z czasu generacji ramki
jak i 'kwantyzacja przestrzenna' wynikajaca z kwantyzacji pozycji stawiania
pixeli na ekranie -- wydaje sie ze lepiej stawiac co okragły piksel i
dobierać czasy, choć z drugiej strony jeśliby uprzeć się na plynne 80hz
i zaokrąglac albo antyaliasingowac pozycje tez mogłoby być dobrze, w
każdym razie rozwalanie jednego i drugiego czyli liczenie ze zmiennym
krokiem pozycji i czasu byloby chyba najgorsze

Parade


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

> odświerzania [PYTANIE: Jak to jest z monitorami LCD? nie wiem jak to jest,
> (...)
> pixeli na ekranie -- wydaje sie ze lepiej stawiac co okragły piksel i
> dobierać czasy,

dokładniej to pewnie lepiej by było (ustalac x i doliczac precyzyjnie t)
gdyby nie czestotliwosc odswiezania monitora - [mozliwe ze jak co poniektorzy
mają monitory lcd to u nich ten scroll wyglada lepiej niz u mnie z crt 80Hz
- bo u mnie jak na moj gust i pamiec jak to bylo na c64 wyglada h**jowo -
juz nie wiem czy bierze sie to z 'szumow' z denka windy czy przez te 80Hz)

fir/parade

--
feel a little spanish today

--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

Mariusz Kruk <M...@e...eu.org> napisał(a):

> epsilon$ while read LINE; do echo \>"$LINE"; done < " Parade"
> >> > w acznie z tym co winda mi wtryni pod spodem
> >> Ok, ale dlaczego wazny jest dla Ciebie czas wykonania nie
> >> Twojego kodu, tylko kodu czegos czemu winnda odda na
> >> nie wiadomo jak dlugo sterowanie?
> >nie wiem czego tu mozna nie rozumiec - interesuje mnie faktyczny czas
> >wykonywania sie mojego progsa (realny) - od tego realnego czasu (z
> >wtrętami z systemu) zalezy płynnośc progsa
>
> Ale zdajesz sobie sprawę z tego jak działa windows? W szczególności, jak
> wygląda zarządzanie procesami?
>

niezbyt (dlatego jak ktos chce cos tu 'zablogowac' na ten temat to chetnie
bym przeczytał) - to jednak nie powinno miec zwiazku z tym ze interesuje
mnie realny konkretny czas na realnym konkretnym kompie :-/


parade (feelin' a little spanish today)

--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

epsilon$ while read LINE; do echo \>"$LINE"; done < "fir/ parade"
>> >> > w acznie z tym co winda mi wtryni pod spodem
>> >> Ok, ale dlaczego wazny jest dla Ciebie czas wykonania nie
>> >> Twojego kodu, tylko kodu czegos czemu winnda odda na
>> >> nie wiadomo jak dlugo sterowanie?
>> >nie wiem czego tu mozna nie rozumiec - interesuje mnie faktyczny czas
>> >wykonywania sie mojego progsa (realny) - od tego realnego czasu (z
>> >wtrętami z systemu) zalezy płynnośc progsa
>> Ale zdajesz sobie sprawę z tego jak działa windows? W szczególności, jak
>> wygląda zarządzanie procesami?
>niezbyt (dlatego jak ktos chce cos tu 'zablogowac' na ten temat to chetnie
>bym przeczytał) - to jednak nie powinno miec zwiazku z tym ze interesuje
>mnie realny konkretny czas na realnym konkretnym kompie :-/

To zastanów się jak działa system wielozadaniowy. I jak się to ma do
czasu wykonania pojedynczego procesu. W szczególności gdy procesów jest
więcej niż liczba procesorów.
Potem dodaj do tego różne priorytety procesów. I różne wydarzenia
"zewnętrzne", jak input od użytkownika, I/O i inne takie.


--
[------------------------]
[ K...@e...eu.org ]
[ http://epsilon.eu.org/ ]
[------------------------]

do góry