Chciałbym zwrócić uwagę tylko na pewną rzecz. Niektóre kody (np. 34 i 53 - nie doszukując się więcej), są oparte na jednym wspólnym liczniku i dzieleniu modulo. Co powoduje błąd w sekwencji w momencie tuż przed przekręceniem się licznika z powrotem do 0. Przy 16-bitach i dużej prędkości ruchu "animacji" jest to nie do wychwycenia. Aby tego efektu nie było konieczna byłaby metoda matematyczna z szukaniem najmniejszej wspólnej wielokrotności tak jak ktoś w jednym z kodów zastosował. Ew. zastosować 3 liczniki jak w zwycięskim kodzie.
Jest DOKŁADNIE tak jak mówisz ;) Bardzo dobry wniosek i uwaga. Ja na to zwrócę uwagę ale dopiero gdy będę realizował swój poradnik z tym modulo - bo to jest kwestia o której często się nie pamięta po prostu z tym dobraniem maksymalnej wartości. Oczywiście to nie jest zawsze krytyczne i w wielu zastosowaniach mało przeszkadza - ale tu w robalu na pewno po iluś tam jego obiegach da o sobie znać dla oka ;) jak się będzie patrzeć wciąż na robala ...
Nie wiem czy dobrze zrozumiałem. Ale w kodzie 68 jest sytuacja właśnie z trzema licznikami, tyle że ukrytymi w tablicy. Nie powiedziałem tego w swojej wiadomości, ale mi chodziło właśnie o takie zastosowanie trzech liczników które zerują się przy określonej wartości uznając to za poprawne. A zwracałem uwagę na licznik pojedynczy który "przekręca się" dopiero przy przekroczeniu jego maksymalnej wartości którą może zmieścić zmienna. Np 16 bit. Na pojedynczym liczniku również da się uzyskać efekt taki jak na trzech licznikach właśnie poprzez szukanie najmniejszej wspólnej wielokrotności, ale z pewnymi ograniczeniami ponieważ stosując taką wspólną wielokrotność łatwiej jest przekroczyć wartość maksymalną zmiennej licznika, a szczególnie gdy chcemy ustawić aby ruchy wykonywały się z opóźnieniem kilku sekund :)
Chciałbym zwrócić uwagę tylko na pewną rzecz. Niektóre kody (np. 34 i 53 - nie doszukując się więcej), są oparte na jednym wspólnym liczniku i dzieleniu modulo. Co powoduje błąd w sekwencji w momencie tuż przed przekręceniem się licznika z powrotem do 0.
OdpowiedzUsuńPrzy 16-bitach i dużej prędkości ruchu "animacji" jest to nie do wychwycenia. Aby tego efektu nie było konieczna byłaby metoda matematyczna z szukaniem najmniejszej wspólnej wielokrotności tak jak ktoś w jednym z kodów zastosował. Ew. zastosować 3 liczniki jak w zwycięskim kodzie.
Jest DOKŁADNIE tak jak mówisz ;) Bardzo dobry wniosek i uwaga. Ja na to zwrócę uwagę ale dopiero gdy będę realizował swój poradnik z tym modulo - bo to jest kwestia o której często się nie pamięta po prostu z tym dobraniem maksymalnej wartości. Oczywiście to nie jest zawsze krytyczne i w wielu zastosowaniach mało przeszkadza - ale tu w robalu na pewno po iluś tam jego obiegach da o sobie znać dla oka ;) jak się będzie patrzeć wciąż na robala ...
UsuńA prawdę mówić to gif z robalem na stronie konkursowej miał taki sam efekt - źle została obcięta sekwencja i następuje na nim co jakiś czas przeskok.
UsuńNo bo to tylko sekwencja GIF ;)
UsuńNie prawda ja za każdym razem kiedy licznik doliczy do danej wartości to go zeruje itd.(coś w stylu OCRx) Zresztą zobaczcie na kod nr68
OdpowiedzUsuńNie wiem czy dobrze zrozumiałem. Ale w kodzie 68 jest sytuacja właśnie z trzema licznikami, tyle że ukrytymi w tablicy.
UsuńNie powiedziałem tego w swojej wiadomości, ale mi chodziło właśnie o takie zastosowanie trzech liczników które zerują się przy określonej wartości uznając to za poprawne.
A zwracałem uwagę na licznik pojedynczy który "przekręca się" dopiero przy przekroczeniu jego maksymalnej wartości którą może zmieścić zmienna. Np 16 bit.
Na pojedynczym liczniku również da się uzyskać efekt taki jak na trzech licznikach właśnie poprzez szukanie najmniejszej wspólnej wielokrotności, ale z pewnymi ograniczeniami ponieważ stosując taką wspólną wielokrotność łatwiej jest przekroczyć wartość maksymalną zmiennej licznika, a szczególnie gdy chcemy ustawić aby ruchy wykonywały się z opóźnieniem kilku sekund :)
"wielowątkowość" na timerach
OdpowiedzUsuń