Új hozzászólás Aktív témák

• #2956 Teasüti nagyúr tvamos #2954

  Új Válasz 2016-05-22 08:27:19 #2956

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Teasüti

  nagyúr

  válasz tvamos #2954 üzenetére

  Én értem, hogy ovis. De ha csak egyetlen feladat fut a procin...
  Timer-nél lesz némi overhead, amivel nehéz számolni.
  Nekem legalábbis.
  Jelenleg azzal kísérletezek, hogy setup()-ban lemérem minden függvény idejét és ezekkel korrigálom a delay-t. Így faszán be lehet lőni az fps-t.

  Frame vezérlésű animációt egy ovis is leprogramoz, nekem meg nulla tapasztalatom van, a nyelvvel is csak ismerkedek.
  A timer vezérlésű animációt még nem tudom, hogy lehetne összerakni. PC-s 3D grafikából merítettem ihletet, ott a motor teljes kapacitással fut és a megjelenítés van időzítve.
  Nálam ez úgy nézne ki, hogy a led library meghívása lenne időzítve a program végén, míg a renderelés lefut minden ciklusban.

  De nekem ez a megközelítés nem tetszik.

  Ha meg a teljes futószalagot időzítem, akkor meg tudni kéne belépés előtt, hogy mennyi idő alatt fog lefutni, mert azzal az értékkel kell korrigálni a timer-t.
  De időt mérni csak a végén tudok...
  Szóval jelenleg még a tervezőasztalon sem tisztult ki a kép.

  Vmi olyasmin filózok, hogy az animáció sebességét függetleníteni kéne az fps-től ÉS a megjelenítés frekvenciájától is. Vagyis ha a teljesítmény skálázná a következő képkocka offset-jét. Pl. egy colorwheel esetén a függvény felbontását növelném két képkocka között, ha gyorsul a sebesség. Vagyis ha egy másodperc alatt ki tud tolni magából 60 fps-t a vas, akkor 100% mintavételezés volna, 120 fps-nél 200% mintavételezés a függvényen.
  De az egyenletes megjelenítéshez itt is ismernem kéne a futószalag idejét belépés előtt.

Új hozzászólás Aktív témák