Profesjonalne myszki - rozmowy, opinie, porady

[kkNd!]

@ kkNd!

heh zostałeś wielokrotnie ostrzegany :) a teraz masz babo placek ;)

 

no wtopa ;D o ile obowiazkowa czystosc podkladki mozna po prostu przyjac do wiadomosci i przetrzec ja raz na tydzien to z tym wylaczaniem sie jest totalna porazka... nie chce mi sie odsylac myszki do serwisu, bo zapewne dostane ja z powrotem za 2-3 miesiace, mozliwe, ze w takim samym stanie, bo dzieje sie to losowo raz na dwa, trzy tygodnie... tylko raz sie wywalila 3x w ciagu jednego dnia

[aerial]

Zeby zakonczyc ten spor, musisz dokladnie uzasadnic dlaczego widac to co widac na screenach :wink:

[Kyle]

Zeby zakonczyc ten spor, musisz dokladnie uzasadnic dlaczego widac to co widac na screenach :wink:

 

No to właśnie uzasadniłem ... mamy rząd pikseli (pionowy) który na screenie jest w ~100% zapalony kolorem pionowej ściany (lewa krawędź ma ~100% kolor ściany będącej po prawej stronie) ... {to jest część górna obrazu który wkleiłem}

 

... niżej {teraz w części dolnej obrazu} mamy zrzut po przesunięciu celownika i ten sam rząd pikseli nadal jest zapalony ale w innym stopniu (widać jakby lekkie odbicie).

 

Gdyby ruch był był co piksel lub więcej to zupełnie nie powinno być moim zdaniem zabarwienia tą ścianą po przesunięciu w tym rzędzie pikseli ... tymczasem nadal coś tam jest.

 

{jeszcze gwoli ostatecznego wyjaśnienia odnośnie tego obrazu - tam są oczywiście 2 zrzuty jeden nad drugim, wyżej "brak przesunięcia" i niżej "po wykonaniu ruchu"}

 

Czerwona linia oddziela screen 1 (pozycja początkowa) i screen 2 (po przesunięciu) . Na zielono zaznaczyłem rząd pikseli który nadal po przesunięciu ma kolor ściany (na screenie 2 ledwie widoczny ale jednak, podczas gdy na screenie 1 kolor ściany jest w pełni wyraźny).

Cyfra z odległością do flagi jest myląca więc nie zwracać na nią uwagi!!! Punktem odniesienia jest żółty celownik!

Edytowane 7 Września 2010 przez Kyle

[aerial]

Mialem na mysli ze aux powinien wyjasnic przyczyne tego co widac na tych screenach i dlaczego sie z Toba nie zgadza.

[Kyle]

Mialem na mysli ze aux powinien wyjasnic przyczyne tego co widac na tych screenach i dlaczego sie z Toba nie zgadza.

 

Aha :oops: :oops: :oops:

[aerial]

Co do tego zjawiska, to moze jest to po prostu rezultat tego jak obraz jest wyswietlany przez silnik gry (antyaliasing)? Np. jezeli to co widac posrednio zalezy od stanu poprzedniej klatki, w zaleznosci z jakich barw/obiektow przesuwa sie celownik, mozemy zobaczyc rozne czesciowe zapalenia skrajnych pikseli. To wcale nie musi oznaczac ze nastopilo przesuniecie o mniej niz jeden piksel.

Pytanie gdybys kontynuowal ruch celownika, o kolejna minimalna zmiane ktora wystapi na ekranie, jaki by byl rezultat? Celownik mialby ta sama pozycje ale krawedz bylaby rownie ostra jak na pierwszym screenie?

Edytowane 7 Września 2010 przez aerial

[Kyle]

Antyaliasing metodą supersamplingu nie bazuje na kolejnych klatkach (właściwie tutaj akurat był 8x multisampling ... ale on też nie działa na kilku kolejnych klatkach). Z resztą to było tak że zrobiłem prtscreen, ruszyłem mysz ... i znowu zrobiłem prtscreen ... więc klatek to tam poleciało z kilkadziesiąt pomiędzy tymi zrzutami.

 

Zrobię więcej klatek przy okazji (więcej ruchów) i wkleję.

Edytowane 7 Września 2010 przez Kyle

[aux]

Zeby zakonczyc ten spor, musisz dokladnie uzasadnic dlaczego widac to co widac na screenach :wink:

 

:ASD no błagam :))))) przecież ja nie napisze nic innego jak to co już napisałem wcześniej.

 

To że na jednym screenie krawędź obiektu kończy się zgodnie z rozdzielczością ekranu a na drugim nie, wynika z rzutu przestrzennego jak i tego, że odległości pomiędzy kątami widzenia nie pokrywają się liniowo z pikselami. W pierwszej pozycji patrzy się liniowo na krawędź i ona kończy się razem z siatką pikseli, w drugiej pozycji zmiana kąta z jakiego patrzy się na tą samą krawędź spowodowała, że została ona przesunięta w projekcji FOV względem osi obserwatora tak że krawędź wypada gdzieś po środku piksela.

 

Bardziej technicznie nie jestem w stanie togo wytłumaczyć.

[aerial]

Troche zle mnie zrozumiales. Chodzi mi o prezycje w prowadzeniu takiego sporu. Uczestnicy zarzucaja sie argumentami, ignorujac lub pomijajac przyklady jednej ze stron. Mogles w pierwszym poscie skupic sie dokladnie na przykladzie z ktorego wyszedl Kyle i na tej podstawie tlumaczyc swoj punkt widzenia. Duzo prosciej i szybciej :)

Twoja argumentacja ma sens, o ile te screeny sa zrobione w ten sposob ze: pierwszy screen, a potem losowo ruszona lekko mysz, i screen kolejny. Takie cos niczego nie udowadnia i masz racje.

Ja myslalem ze to co zaobserwowal Kyle to ze ma celownik na jakiejs pozycji, i moze delikatnie ruszac myszy, wykonujac wielokrotne przemieszczenie wskazujace ciagle ten sam piksel, ale zmieniaja sie tylko odcienie kursora (srodkowo najbardziej wyrazny piksel pozostaje w tym samym miejscu). To by oznaczalo ze mozna poruszac sie o tak male katy, ze jest kilka pozycji w obrębie jednego wyswietlanego piksela.

Ale jezeli to zwyczajnie losowy ruch, i czasem sie trafi na rozmyta krawedz, w pelni uzasadnia Twoja interpretacja.

[Kyle]

To nie był "losowy" ruch tylko przesunięcie minimalnie myszy w jedną stronę.

[Glymbol]

Dlaczego pozycji miałoby być tylko 628? To zależy od minimalnego kąta o jaki da się obrócić w grze, np. dla CS: 90 / 0,022 = 4090 pozycji na 90 stopni. Gra i tak przerysowuje wszystko co klatkę. To, że ruch jest mniejszy niż da się zauważyć nie znaczy, że go nie ma.

 

Poza tym, dla pełnego kąta wychodziłoby: 628 * 4 = 2512. Aux twierdzi, że każdy 1 CPI powoduje obrót o minimalny view-angle, idąc tym tokiem myślenia minimalna czułość w grze dla myszki 400 CPI byłaby: 2512 / 400 = 6,28 cala/360 czyli 15,95 cm/360. Jak wiemy z praktyki, jest to nieprawda.

Edytowane 7 Września 2010 przez Glymbol

[sliza]

Mam u siebie EC1 i EC2 jeśli macie jakieś prośby, jakieś zdjęcia itp. piszcie .

 

ja mam prosbe o jakas (mini co najmniej) recke tych myszek, spostrzezenia co do wygody ksztaltu etc, info jaki tam jest w koncu sensor i jakie jest (prawdziwe) max DPI? Co z tym lift distance (ile ^faktycznie^ wynosi) etc. Plus porownanie do innych myszek (np. DA 3G etc), jesli masz taka mozliwosc.

 

z gory dzieki!

 

ps (wspomnij jaka masz reke (wielkosc), i jaki rodzaj chwytu preferujesz (i czy mysz jest do niego wygodnia), i czy wygodniejsza/lepsza dla Ciebie jest EC1 czy EC2.

[aerial]

Minimalny kat zalezy od sensitivity i dpi, tak jak ten wykresik z poprzedniej strony podaje:

 

 

Z tych przykladow ktore tam sa podane, trzeba by miec bardzo niska rozdzielczosc, zeby doprowadzic do sytuacji ze ruszamy mysza a celujemy ciagle w ten sam wyswietlany piksel. Silnik gry odczytuje ruchy, ale my ich nie widzimy bo rozdzielczosc jest zbyt mala. Do tego trzebaby duzo dpi i jakiejs smiesznej rozdzielczosci w stylu 200x150.

 

Glowny moral z tego jest taki ze rozdzielczosc ekranu nie ma nic wspolnego z tym jak obliczane sa trafienia. Owszem w skrajnym przypadku moze znieksztalcic to co widac na ekranie, ale wszystkie obliczenia trafien sa niezalezne od rozdzielczosci.

[Glymbol]

Minimalny kat (w CS 1.6) zależy od m_yaw, m_pitch i sensitivity. CPI nie ma tu nic do rzeczy, większe powoduje tylko szybsze obracanie wokół osi.

[aerial]

Wlasnie to "tylko" ma takie znaczenie, ze zeby dojsc do tego minimalnego kata na niskim dpi, musialbys miec kuriozalnie niski sens. Tak jak na tym wykresie, te linie sie gdzies tam prawie spotkaja, daza do minimalnego kata jaki jest mozliwy (zalezny wlasnie od ustawien yaw i pitch). Przynajmniej ja tak to rozumiem.

[aux]

Dlaczego pozycji miałoby być tylko 628? To zależy od minimalnego kąta o jaki da się obrócić w grze, np. dla CS: 90 / 0,022 = 4090 pozycji na 90 stopni. Gra i tak przerysowuje wszystko co klatkę. To, że ruch jest mniejszy niż da się zauważyć nie znaczy, że go nie ma.

 

Jeśli bierzesz pod uwagę m_yaw/pitch, który mnoży my/mx i jest on w wartości 0.022 gra zmieni pozycje view-angle po 46 CPI. Byłoby naprawdę genialne gdyby za pomocą m_yaw/pich dało radę sterować precyzją z jaką celujemy, dlatego zapytałem developerów od q3 o dokładnie to samo i odpowiedz brzmiała, że ilość vew-angle jest zależna od rozdzielczości gry.

 

Jeśli masz jakieś źródło informacji, mówię tutaj o programistach pracujących na tym kodzie a nie forumowiczów takich jak ja czy ty, wywróci to całe moje spojrzenie, w którym utwierdzała mnie rzesza poważnych ludzi włączając to w również developerów, do góry nogami :D więc bardzo proszę o podanie linku gdzie mogę potwierdzić rzeczy o których mówisz.

 

Poza tym, dla pełnego kąta wychodziłoby: 628 * 4 = 2512. Aux twierdzi, że każdy 1 CPI powoduje obrót o minimalny view-angle, idąc tym tokiem myślenia minimalna czułość w grze dla myszki 400 CPI byłaby: 2512 / 400 = 6,28 cala/360 czyli 15,95 cm/360. Jak wiemy z praktyki, jest to nieprawda.

 

Nie wiem o jakiej praktyce ty mówisz, dlatego że ja mam zupełnie inną praktykę i pokrywa się ona w 100% z wyliczeniami które podałeś.

 

pwlj z pewnością może podać linki z ESReality z dokładnie wyjaśnionym wyliczeniem minimalnej wartości m_yaw/ptch dla konkretnej rozdzielczość i CPI myszki.

Edytowane 7 Września 2010 przez aux

[Glymbol]

W CS 1.6 minimalne m_pitch to 0.022, m_yaw można mieć niższe ale wtedy obrót w osiach będzie z różną prędkością, co się nie opłaca. Najlepiej pozostawić domyślne wartości 0.022 dla obu kątów. Ponieważ minimalne sensitivity to 1.0, to minimalnym kątem jest 0.022 stopnia.

 

Dla moich ustawień (CS 1.6):

Windows 6/11

CPI myszki ~400

m_yaw 0.022

m_pitch 0.022

sensitivity 1.8

zmierzyłem na podkładce cm/360, wychodzi około 51 cm.

 

Możliwości są dwie:

1. jest więcej pozycji niż 628 (dla 800 pikseli),

2. obrót nie następuje co 1 CPI, czyli to co napisałeś wyżej.

 

Ponadto, jeżeli gra wyliczałaby ilość pozycji na podstawie rozdzielczości, to przy takich samych ustawieniach m_yaw, m_pitch i sensitivity a różnych rozdzielczościach, rzeczywista odległość na podkładce powinna się zmieniać. Tymczasem pozostaje z grubsza taka sama niezależnie od rozdzielczości (dla 640 zmierzyłem 51 cm, dla 1400 - 52 cm).

Edytowane 7 Września 2010 przez Glymbol

[aux]

W CS 1.6 minimalne m_pitch to 0.022, m_yaw można mieć niższe ale wtedy obrót w osiach będzie z różną prędkością, co się nie opłaca. Najlepiej pozostawić domyślne wartości 0.022 dla obu kątów. Ponieważ minimalne sensitivity to 1.0, to minimalnym kątem jest 0.022 stopnia.

 

Stary :) dlaczego developer z którym rozmawiałem w takim układzie twierdzi że m_yaw i m_pitch jest to wartość o jaką zostają przemnożone my i mx (mouse inputs)

 

Jeszce raz proszę o konkretny artykuł człowieka wiedzącego co w kodzie piszczy :D Inaczej uznam że to o czym mówisz nie ma pokrycia z rzeczywistością :D

[Glymbol]

Zacznijmy od tego co to jest mx i my?

[aerial]

Chodzi chyba o slynny kod z cl_input.c z quakea :)

 

/*=================CL_MouseMove=================*/void CL_MouseMove( usercmd_t *cmd ) {float mx, my;float accelSensitivity;float rate;// allow mouse smoothingif ( m_filter->integer ) {mx = ( cl.mouseDx[0] + cl.mouseDx[1] ) * 0.5;my = ( cl.mouseDy[0] + cl.mouseDy[1] ) * 0.5;} else {mx = cl.mouseDx[cl.mouseIndex];my = cl.mouseDy[cl.mouseIndex];}cl.mouseIndex ^= 1;cl.mouseDx[cl.mouseIndex] = 0;cl.mouseDy[cl.mouseIndex] = 0;rate = sqrt( mx * mx + my * my ) / (float)frame_msec;accelSensitivity = cl_sensitivity->value + rate * cl_mouseAccel->value;// scale by FOVaccelSensitivity *= cl.cgameSensitivity;if ( rate && cl_showMouseRate->integer ) {Com_Printf( "%f : %f\n", rate, accelSensitivity );}mx *= accelSensitivity;my *= accelSensitivity;if (!mx && !my) {return;}// add mouse X/Y movement to cmdif ( in_strafe.active ) {cmd->rightmove = ClampChar( cmd->rightmove + m_side->value * mx );} else {cl.viewangles[YAW] -= m_yaw->value * mx;}if ( (in_mlooking || cl_freelook->integer) && !in_strafe.active ) {cl.viewangles[PITCH] += m_pitch->value * my;} else {cmd->forwardmove = ClampChar( cmd->forwardmove - m_forward->value * my );}}

I wniosek:

 

Angle(x) = yaw * x * (sens + ((x * accel) / frame_msec)

 

yaw := m_yaw albo m_pitch

sens := sensitivity value

accel := cl_mouseacceleration

frame_msec := 1 / com_maxfps

x := mouse input value (0 to 10 are normal above that are more or less extreme flicks (measured with cl_showmouserate in q3)

Edytowane 7 Września 2010 przez aerial

[Glymbol]

Wymyśliłem dowód na poparcie tego co napisałem. Jak na razie potwierdza się. Niestety trudno będzie go przedstawić ze względu na objętość, więc tylko opiszę na czym polega, a każdy może przeprowadzić test we własnym zakresie. Potrzebny będzie CS 1.6

 

Ustawienia:

1. szybkość kursora Windows 6/11, "precyzja" wyłączona, komenda startowa -noforcemparms

2. m_yaw 0.022, m_pitch 0.022, sensitivity 1.0

3. mp_roundtime 9

4. mysz z makrem pod którymś klawiszem, pozwalającym na przesunięcie kursora o 1 piksel w prawo przy kliknięciu

 

Procedura testowa:

1. ustawić się na jakąś wyraźną krawędź

2. kilknąć przyciskiem przesuwając się o najmniejszą możliwą wartość

3. zrobić screena

4. powtarzać 2-3 aż do momentu pełnego obrotu

5. sprawdzić ilość zapisanych screenów

 

Nie da rady zrobić tego w 9 minut (max długość rundy w CSie). Po sprawdzeniu, że każde kliknięcie rzeczywiście przesuwa obraz na ekranie (czyli ruch o 1 cpi zmienia kąt), zmodyfikowałem test. Zrobiłem makro z przesunięciem 100 px w prawo i sprawdziłem, robiąc screeny, ile razy trzeba wcisnąć przycisk, zanim nastąpi obrót o 360 stopni. Wyszło 164 screenów, przy czym ostatni był nieco dalej niż 360 stopni. Potwierdza to poprzednie wyliczenia: 360 / 0.022 = 16363, z testu jest 164 * 100 = 16400. Pasuje idealnie.

Edytowane 7 Września 2010 przez Glymbol

[aux]

To co mówisz ma zdecydowanie sens, i gdybym nie usłyszał od developera że to jest zależne od rozdzielczości z pewnością bym się pod tym co mówisz podpisał.

 

Jednakże jeśli ruch o jedną pozycję view-angle następuje po otrzymaniu konkretnej ilości CPI (np. 46), ilość kliknięć makra będzie w obu tezach identyczna niestety, więc nie pozwala to nam jednoznacznie stwierdzić czy odstępy pomiędzy view-angle są mniejsze jak piksele czy nie.

 

Dlatego też poprosiłem Ciebie o opinie programisty w świetle tego, że nie da rady udowodnić ani jednego ani drugiego punktu widzenia poprzez testy tego typu. Trzeba znać się na programowaniu a nie gdybać jak to ma teraz miejsce. Wszystkie informacje które chcielibyśmy wiedzieć są w kodzie źródłowym q2 tudzież q3 i bez pomocy osoby znającej się na programowaniu nigdy nie dojdziemy o co w tym chodzi.

[aerial]

Jak sie to czyta, to nasuwa sie jedno pytanie. Jezeli mamy jakas teze, ktorej nie mozemy udowodnic z poziomu uzytkownika, to czy jest w ogole sens o tym wiedziec? :)

 

zeby lepiej zrozumiec ten kod, mozna go uproscic:

 

cl.viewangles[YAW] -= m_yaw->value * mx;cl.viewangles[PITCH] += m_pitch->value * my;mx = mx *= accelSensitivity;my = my *= accelSensitivity;accelSensitivity = cl_sensitivity->value + rate * cl_mouseAccel->value;rate = sqrt( mx * mx + my * my ) / (float)frame_msec;cl.viewangles[YAW] -= m_yaw->value * (mx *= cl_sensitivity->value + (sqrt( mx * mx + my * my ) / (float)frame_msec) * cl_mouseAccel->value);cl.viewangles[PITCH] += m_pitch->value * (my *= cl_sensitivity->value + (sqrt( mx * mx + my * my ) / (float)frame_msec) * cl_mouseAccel->value);cl.viewangles[YAW] -= m_yaw * ((mx * sensitivity) + (sqrt( mx * mx + my * my ) / (float)frame_msec) * cl_mouseAccel)cl.viewangles[PITCH] += m_pitch * ((my * sensitivity) + (sqrt( mx * mx + my * my ) / (float)frame_msec) * cl_mouseAccel)

z tego co pamietam wartosc frame_msec jest brana w milisekundach (1000)

 

rate = R V / 1000

 

gdzie R to rozdzielczosc myszy (zakladajac ze jej x i y sa rowne), V to predkosc

 

skad to sie bierze:

 

rate = sqrt (mx^2 + my^2) / (1000 dt)

 

mx = Rx dX

my = Ry dY

 

Rx odpowiednie rozdzielczosci myszy dX dY fizyczny ruch myszy

 

rate = sqrt ( Rx^2 dX^2 + Ry^2 dY^2 ) / (1000 dt)

 

zakladajac ze Rx = Ry

 

rate = sqrt ( R^2 dX^2 + R^2 dY^2 ) / (1000 dt)

rate = R sqrt ( dX^2 + dY^2 ) / (1000 dt)

rate = R V / 1000

V := sqrt ( dX^2 + dY^2 ) / dt

Edytowane 8 Września 2010 przez aerial

[sliza]

czy wiadomo juz na 100%, jaki sensor jest w nowych myszkach Zowie Gear EC1/2 i jaka jest ich maksymalna, sprzetowa/nieinterpolowana rozdzielczosc DPI/CPI?

 

co w ogole sadzicie o tych myszkach - jest sens je kupowac; jak wyglada oplacalnosc ich zakupu na tle ich mozliwosci/mozliwosci konkurencji?

 

aktualnie mam DA 3G (1800 DPI) - warto sie przsiadac na Zowie? DA jest dla mnie ciut przyciezkawy i za duzy/srednio wygodny w uchwycie (mam dlonie raczej srednio/malej wielkosci z dosc krotkimi palcami) - zdaje sie, ze to mysz to palm gripa, a ja jednak preferuje clawa (mysz najwyzsza bardziej w srodkowym punkcie na osi dlugosci, a nie blizej przodu - sadze, ze bardziej odpowiadalby mi taki ksztalt jak w X-738 A4tech).

 

Czy EC1/2 sa generalnie do palm gripa, czy do clawa (i od czego to zalezy)?

[aerial]

Byly juz linki:

 

ESR - Hardware Forum

ESR - Hardware Forum

 

Podstawa to ksztalt myszy (o ile sensor nie dyskwalifikuje kompletnie jak w przypadku wielu myszy no-name). Te myszy wygladaja na typowy palm, podobny ksztalt do IE/DA.

Myszy do clawa sa krotkie i szerokie, tak ze nadgarstek lezy w calosci na podkladce, tak jak w przypadku np. G9/G9x.

[anika91]

tutaj są zdjęcia wnętrzności nowych myszek Zowie

 

http://www.armygroup.com.tw/shop/article.php?id=326

Edytowane 8 Września 2010 przez anika91

[hyper_2002]

No więc tak... miałem mało czasu i jeszcze w pełni nie bawiłem się nowymi Zowie ale tak..

 

Lift off distance według mojego pomiaru 1.54mm . Mysz do Palm gripa, podobna do IE 3.0 i DA . Rolka chodzi pewnie , nieco ociężale ale nie wieje tandetą . Co do akceleracji to jeszcze nic więcej nie powiem ale tak na szybko Paint:

 

 

Sensor podobno w 100% Avago 3060 .

 

i kilka zdjęć:

 

A tutaj odpowiedź od Zowie na pytanie dotyczące akceleracji/predykcji w ec1/ec2:

 

 

Hey Mohammed,

 

The question regarding mouse correction or prediction is very interesting, as there is no easy explanation. To give you the honest truth, it’s not about whether or not a mouse has prediction. It’s about the level of prediction it has, as all mice have some extent of prediction.

 

Most gamers today consider the mouse correction / prediction as a deed of pure evil which forces your mouse to make straight lines, even if you don’t want to. Our mice does not force you to do anything, so in terms of the general understanding of the gaming community, our mice does not have any mouse correction. Your movement is your own.

 

However, to continue the story, if there was no prediction at all in a mouse, you would only get lines that look like this:

 

http://img168.imageshack.us/img168/9431/52225695.png]http://img168.imageshack.us/img168/9431/52225695.png]http://img168.imageshack.us/img168/9431/52225695.png]http://img168.imageshack.us/img168/9431/52225695.png]http://img168.imageshack.us/img168/9431/52225695.png]http://img168.imageshack.us/img168/9431/52225695.png]http://img168.imageshack.us/img168/9431/52225695.png]http://img168.imageshack.us/img168/9431/52225695.png]http://img168.imageshack.us/img168/9431/52225695.png

 

Please note that this is even if you drag your mouse completely straight.

 

Why is this? Well, take a look at the surface of your mousepad. It doesn’t matter if it’s plastic, cloth or something else, but what you are looking at will most likely be textured. When running your fingers across your mousepad, you can feel that it is uneven.

 

To get a stable experience when using a mouse, the sensor should only track on the even points of the surface, but as this is somewhat impossible, the sensor uses prediction to even out the gap in-between fibers and particles, so your experience is stable. We believe that this is the only thing prediction should be used for, and have therefore limited the prediction to be as low as possible. The term “prediction or not” was born with some manufacturers overdoing the prediction.

 

To give you a better understanding, I have created these images for you:

With a 125 Hz mouse, the tracking will look as in this image, with the red arrows being prediction:

 

http://img198.imageshack.us/img198/8880/36496278.png

 

As you can see from this image, the gap the sensor needs to predict to go from point A to B is very high.

There are sensors which naturally consider the prediction to be as low as possible, but most of them have other problems. There are other ways to achieve a minimum prediction. We use the Avago 3060 sensor because it is the most stable sensor available. The Avago 3060 is an older sensor, yet it still delivers the best overall performance during extensive use, making it the optimal sensor for a competitive gaming mouse. The Avago 3060 would normally be considered to have prediction, but our 1000 Hz evens out the prediction and makes the gap it needs to predict much smaller.

 

Look at this picture:

As you can see in this picture, the EC-mice updates 6 times faster than a normal 125 Hz mouse.

 

So the final answer to the question is:

Yes, the EC-mice do have prediction, but only the minimum level required in order to have a functional mouse. In terms of how gamers currently interprets the term “prediction”, then the EC-series would not be considered to have prediction.

 

I hope our honesty will be appreciated in the community. Trying out the mice will truly show that we have taken all of these things into consideration, and that our mice allows for free movement.

 

Best regards,

 

Danny Ramkvist

Chief Marketing Officer

 

Edytowane 8 Września 2010 przez hyper_2002

[Glymbol]

co w ogole sadzicie o tych myszkach - jest sens je kupowac?

Wg mnie, nowe myszki Zowie są nieopłacalne. W A4Techach X-710BK, X-710BH, X-760H i AK-47 masz ten sam sensor, a 150zł dopłacasz za lepsze wykonanie (przewód, ślizgacze i materiały). Na twoim miejscu zostawiłbym DA.

[kkNd!]

Rozpisal sie tak, zeby nikogo nie zniechecic do tej myszki... bo ewidetnie widac, ze ma predykcje. A ze swojego doswiadczenia musze powiedziec, ze bez myszka jest duzo precyzyjniejsza ;)

 

btw to Tobie odpowiadal? :D

Edytowane 8 Września 2010 przez kkNd!

[sliza]

btw to Tobie odpowiadal? :D

 

"Hey Mohammed," - tia, to pewnie hyper ;)

 

===

 

co do nowych myszek ZG, to zastanawiam sie, czemu chociaz Avago 3080 tam nie wrzucili - przy tej cenie produktu koncowego.. dziwne to... chyba sobie kupie X-738K w takim razie... DA 3G idzie pod mlotek - chce ktos (patrz dzial Sprzedam)?

Edytowane 9 Września 2010 przez sliza