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

> 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.
>
'ogólnie' wiem jak to dziala - nie zmienia to faktu ze jak sobie zarzucisz
stoper i wykresik to możesz oglądac ak to dziala w praktyce - dlatego nie
rozumiem zarzutow co do moich pomiarów (wiadomo ze na innym komie moze
dzialac inaczej ale mnie interesuje chociaż ten mój a inne stą też 'w częsci'
podobne)

parade

--
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 < " "
>> >> >> > 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.
>'ogólnie' wiem jak to dziala - nie zmienia to faktu ze jak sobie zarzucisz
>stoper i wykresik to możesz oglądac ak to dziala w praktyce - dlatego nie
>rozumiem zarzutow co do moich pomiarów (wiadomo ze na innym komie moze
>dzialac inaczej ale mnie interesuje chociaż ten mój a inne stą też 'w częsci'
>podobne)

Zrozum, że nie masz żadnej gwarancji, że w danym okresie twój proces
dostanie określony procent czasu procesora (runtime pomijamy).

--
d'`'`'`'`'`'`'`'`'`'`'`'`'Yb
`b K...@e...eu.org d'
d' http://epsilon.eu.org/ Yb
`b,-,.,-,.,-,.,-,.,-,.,-,.d'

do góry

>
> Zrozum, że nie masz żadnej gwarancji, że w danym okresie twój proces
> dostanie określony procent czasu procesora (runtime pomijamy).
>

'gwarancji' moze i nie ale 'czas procesora' to zwykle jakiś
jednak tak - chcę zobaczyć jak to jest w praktyce

szczegółów niestety nie znam - nie rozumiem tez co w powyzszym posicie ma
znaczyc "(runtime pomijamy)"

parade


--
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"
>> Zrozum, że nie masz żadnej gwarancji, że w danym okresie twój proces
>> dostanie określony procent czasu procesora (runtime pomijamy).
>'gwarancji' moze i nie ale 'czas procesora' to zwykle jakiś
>jednak tak - chcę zobaczyć jak to jest w praktyce

No to widzisz - raz dostajesz więcej, raz mniej, przez co od momentu
uruchomienia, do momentu zakończenia raz mija więcej czasu, raz mniej.

>szczegółów niestety nie znam - nie rozumiem tez co w powyzszym posicie ma
>znaczyc "(runtime pomijamy)"

Tfu. Miało być "realtime".

--
\.\.\.\.\.\.\.\.\.\.\.\.\.\
.\....@e...eu.org.\.\.
\.http://epsilon.eu.org/\.\
.\.\.\.\.\.\.\.\.\.\.\.\.\.

do góry

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

> epsilon$ while read LINE; do echo \>"$LINE"; done < " parade"
> >> Zrozum, że nie masz żadnej gwarancji, że w danym okresie twój proces
> >> dostanie określony procent czasu procesora (runtime pomijamy).
> >'gwarancji' moze i nie ale 'czas procesora' to zwykle jakiś
> >jednak tak - chcę zobaczyć jak to jest w praktyce
>
> No to widzisz - raz dostajesz więcej, raz mniej, przez co od momentu
> uruchomienia, do momentu zakończenia raz mija więcej czasu, raz mniej.
>
> >szczegółów niestety nie znam - nie rozumiem tez co w powyzszym posicie ma
> >znaczyc "(runtime pomijamy)"
>
> Tfu. Miało być "realtime".
>

a czy ja mowiłem ze nie jest tak jak mowisz? i kto tu jest zakręcony..
i tak nie rozumiem co to ma znaczyc "(realtime pomijamy)" niewazne

ktos tu sie obruszał na nazywanie commodore 64 maszyną realtime,
czy tez porownywanie go ze wsp. pecetami ale mz (w pewnym wspomianym
sensie przynajmniej c64 byl maszyną realtime i scrolle muzyczki itd
byly płynne) a pc+win jest rozlazłe jak szmata: z drugiej strony widzialem
raczej dobry emulatorek commodore wiec jesli mozna emulowac tak plynne
scrolle to mozna i je zrobic - swoja drogą ciekawe czego uzywali do
blitowania - moze czegos lepszego niz ja [?]

pzdr, parade



--
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 < " ombre"
>> >szczegółów niestety nie znam - nie rozumiem tez co w powyzszym posicie ma
>> >znaczyc "(runtime pomijamy)"
>> Tfu. Miało być "realtime".
>a czy ja mowiłem ze nie jest tak jak mowisz? i kto tu jest zakręcony..
>i tak nie rozumiem co to ma znaczyc "(realtime pomijamy)" niewazne

Po pierwsze, pisz po polsku, bo produkujesz jakiś strumień świadomości,
który ciężko zrozumieć.

>ktos tu sie obruszał na nazywanie commodore 64 maszyną realtime,
>czy tez porownywanie go ze wsp. pecetami ale mz (w pewnym wspomianym
>sensie przynajmniej c64 byl maszyną realtime i scrolle muzyczki itd
>byly płynne) a pc+win jest rozlazłe jak szmata:

Nie "rozlazłe", tylko jest normalnym wielozadaniowym systemem. Możesz
stosować pewne sztuczki żeby odpowiednio schedulować swój proces, ale
i tak nie masz pewności, że nie zostaniesz "wykopany" poza przewidziany
czas.

>z drugiej strony widzialem
>raczej dobry emulatorek commodore wiec jesli mozna emulowac tak plynne
>scrolle to mozna i je zrobic

To teraz uruchom ten emulatorek ze scrollem, a w sąsiednim procesie
allokuj pamięć aż system będzie musiał swapować i zobacz co się stanie.

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

do góry

> >
>
> a czy ja mowiłem ze nie jest tak jak mowisz? i kto tu jest zakręcony..
> i tak nie rozumiem co to ma znaczyc "(realtime pomijamy)" niewazne
>
> ktos tu sie obruszał na nazywanie commodore 64 maszyną realtime,
> czy tez porownywanie go ze wsp. pecetami ale mz (w pewnym wspomianym
> sensie przynajmniej c64 byl maszyną realtime i scrolle muzyczki itd
> byly płynne) a pc+win jest rozlazłe jak szmata: z drugiej strony widzialem
> raczej dobry emulatorek commodore wiec jesli mozna emulowac tak plynne
> scrolle to mozna i je zrobic - swoja drogą ciekawe czego uzywali do
> blitowania - moze czegos lepszego niz ja [?]
>
> pzdr, parade
>

wogóle dodam przy okazji co mi przyszlo do glowy [wspominkowo] - za moich
mlodych czasow, swego czasu, wsrod uzytkownikow amigi (kontra ewentualnie
pc) pojawial się wątek pt "amiga kontra pc" - chodzilo o to ze amiga i pc
mialy dwie zupelnie odrebne filozofie generowania obrazu - pc choćby
ze swoim trybem 320x200x8bit reprezentowal tzw 'raw power' po prostu
tablica pikseli - cos wlasnie jak te przyklady z blitem i gdi - dzieki
temu ze tej mocy bylo duzo mozna bylo stworzyc dooma (co na amidze jakos
nie szlo) - amiga miala podejscie z mniejsza ilościa surowej mocy ale
za to ze sprzetowymi akceleracjami typu blity i sprite'y (dokladnie nie
wiem bo pod vga w dosie troche pisalem a na amidze nigdy nic) - ta
druga 'filozofia' z kolei bardziej przypomina OpenGl - wiem skądinąd
(bo eksperymentowalem) że zrobienie takiego scrolla pod openGl - gdzie
jest sprzetowa rotacja itd - byloby szybsze; tymsamym mozna powiedziec ze
opengl trzyma troche ducha amigi czy jej kosci AGA - choc asadniczo we wsp
pc jest i raw power jak i 'aga' czyli akceleracja :/ :) [na podlozu
szmacianego systemu]

parade




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

do góry

On 12/02/2010 11:28 AM, ombre wrote:
> ktos tu sie obruszał na nazywanie commodore 64 maszyną realtime,
> czy tez porownywanie go ze wsp. pecetami ale mz (w pewnym wspomianym
> sensie przynajmniej c64 byl maszyną realtime i scrolle muzyczki itd
> byly płynne) a pc+win jest rozlazłe jak szmata: z drugiej strony widzialem
> raczej dobry emulatorek commodore wiec jesli mozna emulowac tak plynne
> scrolle to mozna i je zrobic - swoja drogą ciekawe czego uzywali do
> blitowania - moze czegos lepszego niz ja [?]

Czego używali? Tysiąckrotnie większej mocy obliczeniowej.

Proponuję Ci, zamiast postmodernistycznej literatury i dołującej muzyki,
medytację nad zwrotem "good enough" w kontekście programowania.

Jeżeli chcesz realtime i ducha Amigi, to zdobądź skądś dowolną konsolę i
jakiś "zestaw developerski" do niej.

A jeżeli musisz robić na PC, to naucz się żyć z jego ograniczeniami.
Rzemiosło wymaga znajomości narzędzia i materiału.

JD

do góry

Grzegorz Niemirowski wrote:

> 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?

Wyświetl sobie jakiś przewijający się tekst, ale dość dużą czcionką, tak na
wysokość np. 1/3 monitora i zobacz, czy płynnie chodzi oraz na ile złe
wrażenie robi efekt o nazwie "tearing" (nie wiem jak dokładnie należałoby to
na polski przetłumaczyć; w google jest sporo odnośników na temat zwalczania
tego efektu).
Kiedyś testowałem to na monitorze z odświeżaniem chyba 85Hz -
synchronizowałem z odświeżaniem monitora za pomocą glXWaitVideoSyncSGI.
Początkowo chciałem zrobić przesuwanie tekstu co drugą klatkę, ale nie było
to płynne, pomimo że to przecież aż 42.5 klatki na sekundę! W przypadku
zwykłego filmu pewnie ciężko byłoby zauważyć że coś jest nie tak, natomiast
przy przesuwającym się tekscie widać to bardzo wyraźnie.

do góry

> > (pragnac zobaczyc czy uda się zrobic cos takiego jak intro
> > pod c64) PRAWIE da się bo pojawiają sie drobne problemy -
> >

jeszcze zdeczko poprawilem dodalem prosty blending
( typu "SetPixel(i,j) = 0.7*GetPixel(i,j);" ) i zgrywanie obrazow
zb mandelbrota na dysk jako bitmapy - mozna zgrac monstrualną bitmape
10tys x 10tys pixeli ) -

http://www.fir1664.webpark.pl/g2d3.zip

teraz to mniej intro a bardziej przegladarka zb mandelbrota ale akurat to
moglem sobie podpiąć - fajnie ze przy okazji odkrylem jak robić "dzielone
zadania" tak by nie blokowaly kolejki komunikatow windy - robi sie to latwo
- po prostu zamiast CalcAndDrawAll() wywoluje co ramke CalcAndDrawPart(od, do)
- bez drugiego wątku (choć powinno być wtedy szybciej ale dziala
nadspodziewanie dobrze i jest ok - cenne doswiadczenie)

parade

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

do góry