SÜRGŐS SEGÍTSÉG!!!

SÜRGŐS SEGÍTSÉG!!!
2002-09-16T17:09:12+02:00
2002-10-11T09:48:41+02:00
2022-11-02T10:15:36+01:00
  • Mivel ms-ben merunk (tudomasom szerint PC ms-nel kisebb idoegysegben nem mer), ezert elvesztettunk 0.459ms-t. akkor hol itt a pontossag?

    Szerintem félreértettél. Olvasd el még egyszer amit írtam!

    A lényeg, hogy mindig a lehető legnagyobb pontosságban vezetjük az időmérő számlálót (ez általában legalább ns nagyságrendben mér), és ha ms pontosságú delta értékre van szükségünk, akkor visszaosztjuk ezt. Nyilván az ms pontosság mellett elveszitjük a tört-ms-okat, de csakis a képzett értékben, nem a számlálóban. Tehát az továbbra is halálpontos lesz (mármint annyira pontos amennyire a mérési alapegység lehetővé teszi).

    Ha még mindig nem érted miről beszélek,akkor nNézd meg a Wi32 API leírásában a QueryPerformanceCounter() és a QueryPerformanceCounterFrequency() fv-ek leírásást, és meg fogod érteni!
    Mutasd a teljes hozzászólást!
  • Azt hiszem, valamit félre értettél...
    [...] Ezúton szeretnék nyilvánosan bocsánatot kérni kijelentéseimért!

    Bocs, akkor meg mea culpa, hogy olyant láttam bele a hozzászólásodba amit nem írtál bele. Sajnos az utóbbi időkben hasonló esetekben inkább csak ilyennel találkoztam, de ennek ellenére persze az én hibám volt a dolog. Szóval, akkor még egyszer bocs a túlspirázásért.
    Mutasd a teljes hozzászólást!
  • Kedves Sting!

    Azt hiszem, valamit félre értettél...
    Egyáltalán nem sértődtem meg és nem vettem flame-nek, amit írtál. Amit írtál teljesen jogos. Meghajlok szaktudásod előtt! Komolyan!
    Mint említettem, nem ismerem a Windows oprendszerek lelki világát és az MCP-t is csak azért említettem, hogy tudassam Veled, megpróbáltam megérteni. Vizsgát sosem tettem, és sosem használtam az ott tanultakat.
    Talán túl kocka fejem van, nem tudom... Azóta egyébként olvasgattam a sorozatotokat és el kell, hogy ismerjem TÉVEDTEM!

    Ezúton szeretnék nyilvánosan bocsánatot kérni kijelentéseimért!

    Igazság szerint én leginkább a problémát szerettem volna megoldani Vakapánknak, de valahogy sikerült elmélyednünk ebben az oprendszer vitában.
    A mi nézetünk teljesen eltér egymástól! Én UNIX hívő vagyok, bár fejlesztettem Windows alá is, mégsem ismerem bit szinten az oprendszert! EGYIKET SEM! Azt viszont tudom, hogy nagyságrendekkel stabilabb a UNIX, akár fejlesztésről, akár üzemeltetésről van szó. Természtesen azt is le kell szögeznünk, hogy teljesen eltérő alapokon működik mindkettő! Vannak közös elemek, de nem minden az.
    Adatbázis kezeléssel foglalkozom, ami ugyebár nem igazán áll közel az oprendszer közeli programozáshoz. Viszont ez előtt hardver fejlesztéssel foglalkoztam, hardver szintű programozással, ezért is éreztem úgy, hogy segíteni tudnék.

    Hasonló problémával már én is találkoztam, akkor ott azt a mérési feladatot sikeresen megoldottuk, elég pontos értékeket kaptunk 386-os gépen.
    MSDOS-t használtunk. Működött.

    Úgy látszik nem sikerült, mert nem értek a Windows-hoz. Az élet ilyen. Suszter maradjon a kaptafánál, nem igaz?

    És mégegyszer! Nem sértődtem meg! Tényleg nem ismerem a Windowst. De mint említettem előző válaszomban (asszem kétszer is), pótolni fogom hiányos tudásomat, éppen Neked, vagy Nektek köszönhetően!
    Szerintem nem én vagyok az egyetlen, aki nem ismeri...
    Mutasd a teljes hozzászólást!
  • reakcioido meres:
    mikortol kell merni a reakcioidot? mikor a kep teljes egeszeben kikerult a kepernyore? vagy mikor elkezded kirajzolni?
    egyebkent ha a gepnek is van 'reakcioideje', akkor logikus megoldasnak latszik az adatok kiertekelesebe beleszamitani azt is, mondjuk egy atlagolt ertek kepeben. a pontossagon vmicsket ez is segithet.
    Mutasd a teljes hozzászólást!
  • nem ertem.
    mondjuk orajelben taroljuk az eltelt idot. tegyuk fel, 1000 orajel(1Mhz)=1ms. tehat az osztonk 1000.
    a szamlalonk tart 13459 orajelnel, ebbol megallapithatjuk, hogy az eltelt ido 13.459ms. Mivel ms-ben merunk (tudomasom szerint PC ms-nel kisebb idoegysegben nem mer), ezert elvesztettunk 0.459ms-t. akkor hol itt a pontossag?
    lehet, hogy hulyesegeket irok egyebkent.
    egy ms-os timert amugy nem tok elkepzelni osztasos modszerrel, mert ki mondja meg, hogy mikor osztunk? ha meg minden orajellel osztunk, az szerintem semmivel sem jobb, mintha 1000-vel leptetunk.
    na jo. nem ertem, mit irok, raadasul offtopic...
    csak azert indultam el, mert nekem is volt ugye ez az idomeros problemam, de letettem a pontossagrol.
    Mutasd a teljes hozzászólást!
  • osszefoglalvan: tudomasom szerint a timerek ms-t orajelgenerator alapjan mernek, megpedig korrekcioval. pl 4mp-ig 1000 orajel=1mp, az 5.mp viszont csak 997 orajel hosszu, ezutan ismet 1000 orajel hosszu mp-ek kovetkeznek....

    Ez nem így működne, mert ez valóban pontatlanságokat eredményezne, hanem úgy, hogy mindig a lehető legnagyobb pontosággal (tehát mondjuk órajelben) tárolják el az egy adott időpont óta eltelt időt, és a mp vagy ms pontosságú delta értéket leosztásból képzik ebből. Így rövid távon a mérési pontosságot az ábrázolási pontosság határozza meg, hosszú távon viszont tökéletesen pontos az óra (persze csak annyira "tökéletesen", amennyira az alapjelet szolgáltató kristály az).

    Egyébként nyilván a PC-k órajelgenerátora sem atomóra, tehát akár viszonylag rövid időn belül is késhetnek viszonylag sokat (nem emberi, hanem műszaki értelemben sokat). Éppen ezért szokás valóban pontos, atomóráról üzemelő ún. timeserverekről (pl. time.kfki.hu) szinkronizálni az időt hálózaton (pl. NTP protokollon) keresztül az olyan működési környezetekben, ahol nem megengedhető még ez a kis pontatlanság sem. Persze pontatlanság itt is fellép, de igen bonyolult algoritmusok segítségével ezt a gyakorlati minimumra lehet szorítani. Persze a legtöbb alkalmazásnál erre nincs szükség.

    (A PC-kben van egyébként még egy nagyon pontatlan időmérő szerkezet, ez pedig az időt a gép kikapcsolt állapotában elemről léptető CMOS illetve a hozzá kapcsolódó valós idejű óraáramkör. Ez akár naponta több mp-et is késhet, de ez a mérési pontosságot nem befolyásolja, mert a modern operációs rendszerek a CMOS időt csak mint bázisidőt használják fel, és a gép bekapcsolt állapotában ennél pontosabb időzítő áramköröket, pl. a PIT-et vagy Penitumok-tól a processzor belső ütemszálálóját használják.)
    Mutasd a teljes hozzászólást!
  • tudja vki, hogyan mukodik egy pc timer-e?
    en nem tom pontosan, viszont volt egy feladatom: van egy spec hardver (ledekbol kirakott kijelzo, vmi ecceru 'processzorral'), aminek tulkepp egy visszaszamlalo (rajtoltatashoz). ezt radugjuk a soros portomra, jol felprogramozom, hany mp mulva hany mp-t szamoljon vissza hanyszor, aztan lehuzzak, es viszik odebb.
    mikor a pc-n futo program kikuldi az inditasi parancsot a kijelzonek, sajat maga is szamol visszafele.
    kb. 1 oraval az indulas utan a kijelzo es a gep eltert 3-5 mp-el.
    erre tanakodtunk egyet a kijelzo keszitojevel, es elmeselte, hogy o tulkepp ugy meri az 1 mp-t, hogy van egy akarhany hz-s orajelgeneratora (kb ms-onkent ebben az esetben), erre szervezett o egy ciklust, ami esetunkben 1000-nel mondja, hogy letelt 1mp.
    a pc szinten vmi ilyen modszerrel mer (pontosabbat nem tudok). ezek a szerencsetlen orajelgeneratorok pedig bizony nincsenek 'hivatalosan kalibralva', tehat kb pontosak.
    lenyeg, hogy szoftveresen piszkaltunk, tettunk vettunk, es vegul sikerult a gepet es a kijelzot osszekalibralni (a kijelzo 1000-es ciklusat noveltuk/csokkentettuk... ja igen, itt lesz majd a lenyeg...). 1 egesz orahosszat egyutt mertek. aztan masodik inditas utani 1 ora mulva mar megint volt 1 mp elteres, az elobb meg pontos beallitasokkal.

    osszefoglalvan: tudomasom szerint a timerek ms-t orajelgenerator alapjan mernek, megpedig korrekcioval. pl 4mp-ig 1000 orajel=1mp, az 5.mp viszont csak 997 orajel hosszu, ezutan ismet 1000 orajel hosszu mp-ek kovetkeznek....
    Mutasd a teljes hozzászólást!
  • Nézd, most emlegethetsz itt MCP-ket, meg "Operációs rendszerek" című könyvet (amit egyébként olvastam), de aki azt mondja, hogy "a Windows egy esemény vezérelt multitaskos oprendszer, ahol egy task képes lefoglalni a teljes processzor időt", az egyértelmű, hogy nem ért hozzá, és nem ismeri a belsejét. (W9X-ekkel kapcsolatban még határesetként el tudnám fogadni ezt a megállapítást, mert bár technikai értelemben és ok-okozati viszonyban nem igaz, de amikor két mondatban fejt ki valamit az ember akkor elég nehéz pontosan fogalmazni. De mivel Te közölted, hogy ez W9X-ekre és NT alapú rendszerekre egyaránt értendő, így egészen biztosan tudom, hogy itt nem ilyen pontatlanságról van szó.)

    Egyébként ha nem/rosszul tud valamit az ember, és ezért szólnak neki, akkor azon lehet megsértődni, meg lehet utánaolvasni a dolgoknak, és megtanulni a helyes változatot. Utóbbi azért jobb megoldás, mert legközelebb majd okosokat is tud mondani az ember.

    Ja, és felréértés ne essék: ezt én nem flame-nek szánom, de nehezen viselem amikor egy szakmai oldalon nyilvánvalóan valótlant állít valaki. Én csakis erre a tévedésre szerettem volna, és fogom a jövőben is a hasonlókra felhívni a figyelmet.
    Mutasd a teljes hozzászólást!
  • Igen, valószínűleg igazad van, hogy fatális tévedésben vagyok a Windows-t illetően. Valóban nem ismerem a Windows működését, de olvasni fogom a sorozatotokat!

    Nem tagadom, hogy már elég régen voltam MCP tanfolyamon (NT 4.0). Azóta szinte minden megváltozott a Windows-ban és talán abszolút hülyeséget írtam. Bocsánatot kérek érte!
    Sőt, mi több elfogult is vagyok. Nekem a UNIX az operációs rendszer, bár otthon Windows-t használok, játszani.
    De ilyen feladatra semmiképpen sem használnék Windows operációs rendszert. De lehet, hogy még UNIX-ot sem...
    Igazából én mindössze csak segíteni szerettem volna a kollégának.

    Köszönöm szépen a javaslatot az olvasmányt illetően, élni fogok vele.

    Cserébe fogadj el Te is egy tanácsot! Olvasd el az Operációs rendszerek című könyvet, ha meg tudod szerezni! Amikor az a könyv íródott, még nem létezett Windows. Nem hülye emberek írták, tulajdonképpen a UNIX azokra az elméletekre épül.

    Mivel nem ismerem a Windows-t, nem tudom a Redmondi srácok olvasták-e a könyvet, de remélem merítettek belőle ötleteket.

    Visszatérve az eredeti problémára, a megoldást abban látom, hogy kell egy hardver és egy szoftver. Mivel az olcsóság is szempont és a PC adott mint hardver, a legkézenfekvőbb megoldás az MSDOS alá írt egytaskos assembly program, ami kontrol alatt tartja a hardvert.
    Természetesen, ha a program floppyra írja ki a start és az end időket, akkor ugyaebár nemigazán használható. De ha egyszerű memória használat mellett dönt a programozó, akkor már sokkal inkább használható. De ahogy Te is írtad, feltételeznünk kell, hogy a hardver elég gyors. Szerintem egy 1GHz-es Celeron elég gyor kell hogy legyen.
    Mutasd a teljes hozzászólást!
  • Bocsánat, még egy dolog...
    Abszolút egyet értek Veled abban, hogy a DOS-nál is lehetnek problémák a megszakítások miatt.
    Éppen ezért javasoltam assembly programot, ahol csak portokat kezel a program, és nem hív meg semmilyen BIOS vagy MSDOS megszakítást.

    Abban is egyet értek Veled, hogy egy valós idejű multitaskos operációs rendszer is alkalmas lehet erre a feladatra. A probléma ott kezdődik, hogy egy Windows-nál nehezebb elérni a portokat (itt most leginkább a 2000-re gondolok), arról nem is beszélve, hogy egy 32 bites alkalmazásba sokkal nehezebb assemblu rutint építeni, mint egy MSDOS-os 16 bites alkalmazásba.

    Természetesen el lehet azon is vitatkozni, hogy a UNIX-ban ez még ennél is nehezebb, de maradjunk inkább annyiban, hogy a UNIX és a Windows operációs rendszerek között ég és föld a különbség, tekintve, hogy az egyik több mint 30 éve működik megbízhatóan, míg a másik még alig egy évtizedes és még mindig vannak betegségei.
    Ezzel nem lebecsülni akarom a Windows-okat, hiszen például otthoni feladatokra ez a legalkalmasabb. De tudományos feladatra egy megbízható operációs rendszert illik hasnzálni, nem pedig egy otthoni oprendszert.
    Valószínűleg ez lehet az oka annak, hogy a világ vezető kutató intézetei mind-mind UNIX-ot használnak, de nagyon messzire sem kell menni, ugyanis maga a Microsoft is Linux oprendszert használ WEB szervernek, s nem a saját termékeit...
    Mutasd a teljes hozzászólást!
  • Bocsáss meg, de én nem szeretnék Veled azon vitatkozni, hogy a Windows milyen operációs rendszer.

    Én sem szeretném ha ebben a témában vitatkoznunk kellene, de ez nem változtat a tényen, hogy FATÁLIS félreértésben vagy a Windows működését illetően. Ajánlom figyelmedbe Windows-os sorozatunkat ebben a témában: Windows API - Cikkek - Prog.Hu (különös tekintettel az első néhány részre). Nagyon hasznos lesz olvasmány lesz Neked.
    Mutasd a teljes hozzászólást!
  • Kedves Sting!

    Bocsáss meg, de én nem szeretnék Veled azon vitatkozni, hogy a Windows milyen operációs rendszer.
    Röviden : a Windows egy esemény vezérelt multitaskos oprendszer, ahol egy task képes lefoglalni a teljes processzor időt. Nincs valódi time sharing. Ha egy process úgy dönt, akkor a többinek nem jut idő.
    UNIX alatt viszont létezik egy kernel (nem tévesztendő össze a Windows kernellel), ami gondoskodik arról, hogy a processzek annyi idő szeletet kapjanak, amennyi jár nekik. Ha letelt az idő, egyszerűen elveszi a vezérlést.
    Ennélfogva a a Windows tökéletesen alkalmatlan erre a mérési feladatra (és itt a win95-re és a 2000-re is gondolok), viszont UNIX-ot feltehetőleg nem fognak e projekt kedvéért felrakni az adott gépre.
    Marad tehát az egy taskos operációs rendszer, az MSDOS. Gondolom ezzel Te is egyet értesz.
    Egy olyan operációs rendszerben, ahol az események befolyásolják a taskok időigényét, nem lehet megbízhatóan mérési feladatokat végrehajtani, különösen ilyen pontossággal.
    Egyébként létezett kb. tíz évvel ezelőtt egy igen jó kis könyv, nem tudom kapható-e még. A SZÁMALK gondozásában jelent meg, a címe pedig Operációs rendszerek. A köny három kötetes. Javaslom mindenkinek, akit érdekelnek az operációs rendszerek belülről.
    Mutasd a teljes hozzászólást!
  • Annál is inkább, mivel a Windows nem olyan multitaskos oprendszer, mint a UNIX. Egyáltalán nem alkalmas multitasking oprendszer mérési feladatra, ha ilyen pontosságú mérés szükséges.

    Szerinted mitől "nem olyan multitaskos oprendszer" egy Windows, mint egy UNIX? (Egyáltalán mit értesz ez alatt?)

    Egyébként a multitaszkos rendszer is tökéletesen alkalmas lehet a mérésre ugyanúgy, mint ahogy egy egytaszkos (pl. DOS) is lehet tökéletesen alkalmatlan. (Pl. DOS alatt is bizony várni kell az OS hívásoktól kezdve a megszakítások lefutásáig nagyon sok mindenre.)

    Az egyetlen dolog ami ebben dönt az az, hogy az operációs rendszer valós idejű vagy sem. (Persze a hardver által támasztott korlátokat nem számítva, mert azt feltételezzük, hogy a hardver sebessége megfelelő a megkívánt méréssei pontossághoz.)
    Mutasd a teljes hozzászólást!
  • Vakapád!

    Azt kell, hogy mondjam, azzal az emberkével értek egyet, aki a Pascal-t javasolta DOS alatt.
    Annál is inkább, mivel a Windows nem olyan multitaskos oprendszer, mint a UNIX. Egyáltalán nem alkalmas multitasking oprendszer mérési feladatra, ha ilyen pontosságú mérés szükséges.
    A mai PC-k képesek kell, hogy legyenek egy ilyen szintű feladat elvégzéséhez. DOS alatt ténylek a felhasználóé a gép, nem kell várni semmire sem.

    Egyébként én a kijelzést semmiképpen sem a képernyőn végezném, ugyanis nincs olyan olcsó, jó és gyors megoldás, amivel ezt összhangba lehetne hozni. Szerintem a LED-es megoldás lenne a legjobb, vagyis a program egy LED-et kapcsolna be és mérné a reakció időt! Ez szerintem fillérekből megoldható és egy egyszerű assembly programmal pedig milliomod másodperces pontossággal lehet mérni a reakció idő a gép "stopperével".
    Gondolom a számítógép azért kell, hogy a mért adatokat tárolja és esetleg statisztikát készítsen belőle, ugye?
    Nem tudom mennyire sürgős a dolog, de kb. egy hét leforgása alatt szerintem megoldható a hardver is és a szoftver is.
    Ha érdekel az ötlet, írj ide, utána levelezhetünk.
    Mutasd a teljes hozzászólást!
  • Sziasztok!
    Van egy SOS-es problémám Delphi-ben:
    Azt kellene lekérdeznem, hogy egy progi fut-e a gépen vagy sem. De: a progi nem mint alkalmazás fut, hanem mint folyamat!!! Win9x+WinNT+Win2000+WinXP alatt kell, hogy működjön.

    Előre is köszi az ötleteket.
    Mutasd a teljes hozzászólást!
  • Hi!
    - Nagyon leredukálódott ez az eszmecsere. Ha (akár egy új topickban) kicsit konkrétabban vázolnád a feladatot, annak az általatok vélt megoldását, illetve hol akadtatok még el, talán konkrétabb segítséget kapnál.
    - Mivel most időm a legkevesebb, meg most otthon használható gépem sincs, így konkrét programmal pillanatnyilag nem tudok szolgálni.
    - Még egy ötlet: ha tényleg képeket kellene megjeleníteni, esetleg a prg. indulásakor ezeket nem lehetne egyből memóriába tölteni?
    Mutasd a teljes hozzászólást!
  • Érdekel a dolog ha meg tudod oldani Pascalban ezt a 3 szög megjelenítést. ))))

    - milyen 3 szöget? Én adott méretű tetszőleges (BMP) kép megjelenítéséről beszéltem (ettől persze még tetszőleges 3 szög is megjeleníthető :). Windows alatt lehet JPG, meg talán más is.
    Mutasd a teljes hozzászólást!
  • win alatti idozitgeteshez talan ez segithet:

    http://www.codeguru.com/system/CreatingAHigh.html
    Mutasd a teljes hozzászólást!
  • Tehát a megjelen? kép hatására megnyomvan a gombot mindkét rendszer megmérte sa reakcióid?t és sajna azt kell, hogy mondjam 20-50 ms különbség volt a windowsos progi és a küls? mér? között a különbség a windows javára., Magyarán ennyivel lasabb volt a windows

    - milyen windows, milyen beállításokkal? Egy megfelelően kialakított (lebutított) w95, esetleg w98 rendszernek elvileg képes kellene lenni a feladat megoldására. A monitorhoz nem igazán tudok hozzászólni, de szerintem egyéb (led) kijelzők tehetetlensége pontatlanabb végeredményt adhat. A külső mérőt nem tudjátok a gépre kötni?
    Mutasd a teljes hozzászólást!
  • Sziasztok!!
    Egy kissé bajban vagyok, mert szorít a határidő!!
    Ha tudtok segíteni sürgősen írjatok a halder01@freemail.hu-ra vagy ide!
    A probléma a következő: a vezérlő karaktereket be bírom olvasni ki bírom írni, de nem bírom összehasonlítani(linux alatt)!!!!!
    pl. írok egy rövid példa progit
    #include <ncurses.h>

    int main(void)
    {
    int ch;
    initscr();
    raw();
    keypad(stdscr, TRUE);
    printw("%c\\\\\\\\\\\\\\\\n", KEY_F(3));
    ch=getch(); /*ctrl+k karakter, ennek a kódja a KEY_F(3)*/
    printw("%c\\\\\\\\\\\\\\\\n", ch);
    if (ch==KEY_F(3))
    printw("all ok! %c\\\\\\\\\\\\\\\\n", ch);
    refresh();
    getch();
    endwin();
    return 0;
    }
    próbáljátok ki, nem fogja összehasonlítani a két karaktert!!!! de miért nem, holott mindkettő ugyanazzz!!! Légyszi segítsetek!!!
    halder01
    Mutasd a teljes hozzászólást!
  • szia!

    a baj valojaban nem a windowsal, hanem a PC-vel mint olyannal van a ti esetetekben. ui a pc-t nem ilyen specifikus feladatokra terveztek, hanem altalanos feladatmegoldo rendszernek. esetetekben a pc leheteosegeinek nagyon nagy reszet nem hasznaljatok ki. celszerunek latszik a celeszkoz kifejlesztese az adott feladatra.
    feltetlenul szuksegetek van szamitogepre a reakcioido meresehez? miert nem jo az alltalad emlitett kutyu?

    ozy
    Mutasd a teljes hozzászólást!
  • HI

    Köszi a választ.

    Van egy külső reakcióidőmérő kütyünk ami csak hang ill. fényjelet tud adni (egy led világít. Ennek a nyomógomját összekötöttük a windowsos program nyomógomjával és a mérnök srác összhangba hozta a külső mérő és a windowsos program jelét. Tehát a megjelenő kép hatására megnyomvan a gombot mindkét rendszer megmérte sa reakcióidőt és sajna azt kell, hogy mondjam 20-50 ms különbség volt a windowsos progi és a külső mérő között a különbség a windows javára., Magyarán ennyivel lasabb volt a windows Úgyhogy sajna azt kell mondanom a windows alkalmatlan bármilyen normális feladat megoldására aminél pontos idők kellenek. (jól van nem akarom szapulni mert helyettem sokan megteszik úgy is).

    Tudom a profi rendszerek drágák de hát szegény ember vízzel akar főzni. Hidd el én lennék a legboldogabb ha vehetnék egy normális rendszert.
    Ezért a minimálisra csökkentve az időbeli eltéréseket a lehető legolcsóbban akarom kihozni a rendszert.
    Ha nem megy akkor nem megy de végig akarom járni minden oldalról az ügyet.

    Ha tudsz segíts benne vagy esetleg ajánlj valakit.

    Köszi szépen
    vakapád
    Mutasd a teljes hozzászólást!
  • HI Vakapád vagyok!

    Köszi a gyors választ.
    Érdekel a dolog ha meg tudod oldani Pascalban ezt a 3 szög megjelenítést. ))))
    A kamerát jó ötletnek tartom de egy ilyen tudású horrrrribilis összegbe kerül( annyi pénz nincs. Sajna a 10 ms sok idő majdnem 10 %-a a teljes reakcióidőnek. ((
    Válaszolhatsz az emilemre is és akkor rövidre zárjuk a dolgot.vakapad@ttk.pte.hu

    A monitor képfrissítési frekvenciájáról tudsz valami megoldást??? Vagy tudsz valakit aki tud segíteni??

    ha az adott könyvet tovább olvasgatod, akkor olyat is találhatsz benne, hogy az emberi szem elég érzékeny a _hirtelen_ változásra is.

    Ennél lemaradtam milyen könyvet?

    Valóban érzékeny az emberi szem a hirtelen mozdulatokra de csak ha látjja a mozdulatot. A mi problémánk az, hogy max 10 ms-ig még nem is látja a jelet mivel a képfrissítés még zajlik és csak a következő frissítésnél fogja meglátni és addig legroszabb esetben 10 ms eltelik. ((

    Írgyááá
    Vakapád
    Mutasd a teljes hozzászólást!
  • -
    szemmel látható ideig rajzolja az ábrát
    mentsd el a képe(ke)t, azt betöltve talán kicsit gyorsabban kirajzolja! :)
    -
    Minden érdekel.
    DOS alatt meg tudnám oldani (én nagyjából a pascal nyelvet ismerem). Fix méretű és felbontású BMP képeket kell tárolni, majd megjelenítéskor lekérdezni a pontos időt, várni az első billentyű leütésére, lekérni a pontos időt, majd az idők különbségét megjeleníteni :) Ennyit esetleg ASM-ben is meg lehet írni emberi idő alatt :)
    A DOS azért jó ilyenkor, mert ott tied az egész gép (itt főleg a portokra gondolok), és minden rád (felhasználóra) vár. Amúgy egy XT laptophoz (csak 2 720kb-os floppy egysége volt, winch. semmi) anno olyan megoldás volt, hogy egy célhardver (startpisztoly + célfotó) volt az egyik soros porthoz hozzákötve, és ezzel mérték a futók teljesítményét. :) A prg. pascalban volt megírva, azt mondták, elég pontosan mér (hogy versenybíróság elfogadta-e, azt nem tudom, de ifjúsági versenyekre hordták -- ezért kellett laptop)
    -
    a vizsgált személy azt nem látja még
    ha az adott könyvet tovább olvasgatod, akkor olyat is találhatsz benne, hogy az emberi szem elég érzékeny a _hirtelen_ változásra is. Szerintem a gyakorlatban nincs jelentősége ekkora hibának (itt konkrétan a korengedményes vezetői PÁV vizsgámra gondolok, olyan lassú volt a katódsugár, hogy már a 3. új foltnál jártunk, amikor az 1. folt végleg elhalványult :)
    -
    Ez egy tudományos kisérletsorozathoz kellene
    javasolnék olyan eszközöket (leginkább kamerá(ka)t), amelyekkel az említett hibahatár szerintetek mérhető, és megállapítható. Én pillanatnyilag nem tudok olyan kameráról, amellyel ekkora különbség mérhető lenne. Ha én kapnám a feladatot (ez nem felajánlás, csak hangosan gondolkodom :), akkor szerelnék a monitorra legalább 1 kamerát (ez veszi a delikvenst), a win.-os mérő program pedig szinkronban működne a felvett képpel, valamint egy ezektől független (leginkább) önálló kamera venné profilból a monitor képét, +a delikvenst (a hibahatárok utólagos megállapításához). Nem mondom, hogy az utólagos kiértékelés helyzete egyszerű lenne, de legalább ennyivel talán biztosítható lenne. Ez csak egy (az első :) ötletem, de ki kellene próbálni, mennyire működőképes! (Ezt természetesen bármely más ötletre is értem.)
    Mutasd a teljes hozzászólást!
  • A Windows lelkivilágával és a grafikával kapcsolatban a Win32 sorozatunkat (Windows API - Cikkek - Prog.Hu) tudom ajánlani. Érdemes átolvasni (és ha még marad kérdés az után feltenni).

    Ezeket az időket egyébként (nem a kirajzolásra, hanem a billentyűfeldolgozásra) egyébként én túlzónak tartom, bár azzal tisztában kell lenni, hogy a Windows nem RTOS, azaz nincsenek garantált válaszidők a hívásokra, és így a rendszer megfelelő terhelése esetén tetszőleges nagyra nyúlhatnak a válaszidők. Ennek ellenére nem ez a jellemző, és nem érdemes ilyen iszonyúan nagy válaszidőkkel számolni.

    A QNX egyébként pontosan ugyanolyan többfeladatos OS, mint a Win, Linux, OS/2, stb., csak éppen előbb RTOS-nak hívja magát (egyesek szerint nem az), míg utóbbiak nem azok.

    Ha egyébként annyira pontos mérés kell, akkor a helyedben nem PC-s rendszerrel próbálkoznék, mert az nem erre lett kitalálva (sem a hardver, sem a szoftver). Persze a spéci rendszereknek meg is van az ára, de hát te dönheted el, hogy a pontosság a fontos, vagy az olcsóság.

    Egyébként a konkrét feladatra szerintem a DOS neked jobb lenne, mint a Windows, mert a Windows szinte semmi olyasmit nem nyújt, amit a DOS-ban ne lehetne közel azonos erőfeszítések révén megcsinálni (grafika, billentyűkezelés, időmérés). És ott biztosan kevesebb a pontosságot rontó tényező működik.
    Mutasd a teljes hozzászólást!
  • Sziasztok guruk )

    Szóval:
    Reakció idő mérő programot készítünk Visual Basic 6.0-ban (mert ehhez értünk csak (((.
    Úgy látszi ez a baj.....
    A lényege az, hogy a képernyőn az általunk basicben megírt program egy kitöltött
    (egyszínű pl. sárga) 3-szöget rajzol ki. Amikor a háromszög megjelenik a vizsgált személynek meg kell nyomnia egy gombot (ami a joystick portra van kötve). A program a háromszög megjelenése és a gomb lenyomása között eltelt időt megméri
    milisecundumban (ms) és eltárolja. Majd eltűnik a kép és bizonyos idő után (véletlenszerűen) újra megjelenik a 3-szög megint gombnyomás eltárolás...stb. Ez folytatódik a programban előre beállított ideig. Ez eddig egyszerűnek tűnhet.

    Az első probléma:

    a kitöltött 3-szög rajzolását eddig csak tangens fügvénnyel tudtuk megoldani, magyarán
    különböző hosszúságú vonalak egymás utáni rajzolása révén tudtunk kitöltött alakzatot
    kirajzolni. Ez jelentős ideig történik még az 1 GHz-es celeronommal és 512 MB ram-ommal
    is szemmel látható ideig rajzolja az ábrát. A feltételezésünk szerint mivel az emberi szem
    25/kép/másodperces felbontású ezért legalább 10-50 ms-ig rajzolja az ábrát. Egy normál
    reakció idő kb: 110-180 ms között van és ha ezt összevetjük a 10-50 ms-al akkor ez így
    elfogadhatatlan érték. KÉRDÉS: Lehet-e más módon rajzolni egyszínű (kitöltött) 3-szöget,
    hogy gyorsabban rajzolja ki a képernyőre?

    A második probléma már egy kicsit komplikáltabb:

    a windows multitask üzemmódban működik, a vizsgált személy észlelése után megnyomott
    gomb jelének "meg kell várnia", hogy a windows az éppen futó taskot(kat) felfüggessze és
    (a program foghassa a jelet) akkor ez pontatlanná teszi a mérést. Állítólag ez akár 20 ms is
    lehet ami megint csak nem elfogadható. Az "állítólag" szó informatikus barátaim
    véleményét tükrözi akik nem tudtak ebben a kérdésben segíteni.......
    Mit lehet tenni, hogyan lehetne kiküszöbölni ezt a problémát. Tudomásom szerint a
    windows, Linux, OS/2, Unix mind mind multitaskos rendszer és csak két olyan oprendszert
    ismerek ami nem: Qnix (de ez horibilis pénzbe kerül), a másik az MS-Dos. Az msdos alá
    meg tudomásom szerint a quick basik létezik (basicben). Hát hogy is mondjam azzal mit
    lehet csinálni.....((
    Szóval van megoldás??? És ha igen akkor mi az??? Minden érdekel.

    A harmadik talán legnehezebb probléma:

    ha veszünk egy monitort aminek 100 Hz a függőleges képfrissítési frekvenciája akkor két
    kép között 10 ms idő telik el. Ha a 3-szög megjelenése éppen a képfrissítés utáni pillanatra
    esik akkor kb 10 ms múlva fog csak megjellenni, de a program ezt a 10 ms-ot is beleveszi
    a reakcióidőbe mert"ő" azt nem tudja, hogy a vizsgált személy azt nem látja még 10 ms-ig
    (de ez nem minden esetben 10 ms mert ha így lenne akkor egyszerűen levonnánk a reakcióidőből). Lehet ez 0-10ms -ig terjedő idő csak mi egzaktan nem tudjuk megmondani mikor mennyi!!!! Így nem is tudjuk levonni (milyen? miknek? milye? eset forog fenn).
    Szóval hogyan lehetne a programnak azt megmondani, hogy a képfrissítési jel (trigger
    JEL) mikor jön? Magyarán miként lehetne összhangba hozni a 3-szög megjelenését és a
    képfrissítési frekvenciát, hogy kiküszöböljük ezt a hibát.

    Ha az összes hibát összeadjuk ami felléphet a reakció idő mérő program és a windows ill. a
    monitor miatt akkor átlagot számolva kb: 40 ms adódik...........
    Ez meg nem elfogadható, messze nem 5%-os hibahatár.
    A reakció időt nagyon sok tényező befolyásolja ezért kellene a lehető legpontossabban
    mérnünk. Ugyanis fáradási reakció időt is akarunk mérni, magyarán futás után mennyire
    változik ez az idő. És ha már a normál esetben is nagy hibával kell számolnunk akkor mi
    lesz a fáradás alkalmával????????? Honnan tudjuk, hogy amit látunk az fáradás vagy
    éppen minden összejött és 40-50 ms-al több időt mért a program az előbb felvázolt 3 ok
    miatt??????

    Tud valaki ebben segíteni? ISMERTEK olyan embert aki mondjuk rendszerszintű programozáshoz ért és meg tudja oldani ezeket a problémákat? Ez egy tudományos kisérletsorozathoz kellene és nemzetközi lapban akarnánk publikálni és ott ugye fontos az egzakt mérés!
    Különben Biológus vagyok és élettani kutatásokkal foglalkozunk. Ezért keresek olyan
    embnereket akik értenek az ilyen dolgokhoz.
    Kérem ha tudnak segítsenek vagy ajánljanak olyan embert aki segíteni tud.
    Természetesen nem ingyen!!!!!



    Tisztelettel és köszönettel:

    Bánvölgyi Tamás
    vakapad@ttk.pte.hu
    Mutasd a teljes hozzászólást!
  • Egy olyan javascript kellene nekem, ami egy dobókocka szimulátor. Egy hatoldalú, egyszerű kockát kéne szimulálnia. Megnyomom a gombot, erre bead egy számot 1 és 6 között véletlenszerűen.. E mellé pedig megjelenik egy kép (1.jpg, 2.jpg,...,6.jpg), ami a kocka megfelelő oldalát mutatja. Ezt én elkészitem, de az kéne, hogyha pl. hatost dobok, akkor a 6.jpg jelenjen meg, ha négyest, a 4.jpg. KÉRLEK, SEGITS!
    Egy hamarosan (fél, egy év vagy soha :)) megjelenő laphoz kellene.
    E-mailen vedd fel velem a kapcsolatot: sizo@skizo.hu.
    Köszönöm!
    Mutasd a teljes hozzászólást!
  • a régi és az új azonosítók excel táblában vannak

    - szerintem excelből mentsd el
    Szöveg (tabulátorral tagolt)
    sima text-ként, ahol a létrejött 2 oszlop elé beírsz egy REN (átnevezés) utasítást (vagy inkább excelben már így készíted elő a 3 mentendő oszlopot). Tehát egy sornak vhogy így kellene kinéznie:
    REN REGI.JPG UJ.JPG
    . Ennek végeztével a TXT file-t átnevezed .BAT kiterjesztésűre, és futtatod DOS ablakból.
    - persze programot is lehet rá írni, csak talán ez 1xübb :)
    Mutasd a teljes hozzászólást!
  • Sziasztok kellene egy kis segítség.
    van egy csomó kép sorszámozva(katalogus)
    és azak az számok megváltoztak.
    azaz át kellene nevezni a képeket a régiazonosító.jpg -ről az újazonosító.jpg -re

    a régi és az új azonosítók excel táblában vannak
    az egyik oszlopben a régi a másikban az új.

    Kellene egy kis segítség melyik nyelven lehetne megírni és ha esetleg ha valaki tud megoldást
    vagy egy programot ami megcsinálja. hálás leszek
    Mutasd a teljes hozzászólást!
  • Köszönöm szépen a gyors segítséget, ezzel már működik.

    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd