toms navigator to zło. Zło i **** :D

... widzę las chętnych :D

Ehh, gdyby tak jeszcze na źródłowe zamieniał...

znaczy z sapa ma robic gierke z ktorej byl wyciagniety?
o jakie "zrodlowe" chozi?

Fox - Bez sensu totalnie. Mam 300 plików w czym do każdego dodane po kilka kilobajtów playera, konwersja kilkudziesięciu katalogów z danymi, oraz przerabianie do wykonywalnych plików wszystkich muzyczek i grafik? - danych prawie 50% więcej, a depaker jedynie wkurza powodując straty czasu potrzebne na rozpakowanie. Ma to znaczenie w przypadku szybkiego HDD, bo szybciej odczytasz niż rozpakujesz. Nawet flashpack jest 2x wolniejszy od dysku KMK/JŻ ;)-

... dobrym przykładem na to, iż pakowanie danych jest bez sensu (w przypadku HDD) jest format RIP. Ładowanie danych 0.2s, rozpakowanie - np. 5-7 sekund. Wiem oczywiście, że nie tyczy się to FP :P

Ostatnio edytowany przez Pin (2011-06-16 21:24:23)

... ;)- spokojnie, bo mam jeszcze jeden pomysł, który doprowadzi do tego, iż spod "teoretycznie" SDX można by było niezauważalnie dla użytkownika poprzez pewien ficzer doprowadzić do stanu w którym uruchamia się 99.9% plików, praktycznie prawie bez względu na to, gdzie program się ładuje, oraz jakiej pamięci dodatkowej używa :) ... a rozwiązanie istnieje i jest proste jak drut. Lub nawet jeszcze prostrze :D

Ostatnio edytowany przez Pin (2011-06-16 21:28:07)

Flaszka wypakowuje dane z prędkością około 30kB/s. Z dysku mam 70-80kB/s :)

Fox - tak czy inaczej chodzi mi o nawet przeróbę przerobienia niektórych istniejących "playerów", które można w ultraprosty sposób przystosować do pobierania nazwy pliku spod CP i tym sposobem zaprezentowania pracy / muzaka / grafiki / czegokolwiek. Jest to chyba słuszny kierunek rozwoju oprogramowania ukierunkowanego na całkiem niezły dyskowy system operacyjny. Tak sądzę przynajmniej ;)-

Ostatnio edytowany przez Pin (2011-06-16 21:41:04)

Hm, i czego to dowodzi?

Na przykład tego, że Pinokio wybiera sobie liczby jak politycy.
Żeby zmierzyć poprawnie, należałoby zacząć pomiar w momencie otwarcia do odczytu pierwszego pliku, tzn. playera w przypadku ładowania TMC lub właściwego pliku w przypadku XEX, i zakończyć w momencie rozpoczęcia odtwarzania. Z liczb, które podali koledzy, wynika jednak, że mierzenie tego jest bez sensu.
Zgodnie z liczbami 0xF-a, plik TMC ma średnio 6946 bajtów, czyli jego załadowanie na komputerze Pinokia (wg. liczb tegoż) trwać będzie ok. 1/10 sekundy, nie licząc czasu potrzebnego na jego znalezienie w katalogu. To znaczy trwałoby, gdyby nie konieczność załadowania również za każdym razem playera z osobnego pliku (pociągająca za sobą konieczność znalezienia go wcześniej w katalogu).
Natomiast odpowiedni plik XEX ma średnio 4871 bajtów, czyli ładuje się ok. 6/100 sekundy i rozpakowuje ok. 25/100 sekundy (spakowany TMC+player ma średnio nieco ponad 60% oryginalnego rozmiaru), nie wymagając załadowania dodatkowo playera.
Dlaczego bez sensu? Bo różnica 2/10 sekundy (przy optymistycznym, błędnym, niejawnie przemyconym tu przez Pinokia założeniu, że nawet mega jednobajtowych plików załaduje się w tym samym czasie, co jeden megabajtowy plik) nie daje się uchwycić ludzkiej percepcji w otoczeniu takich czasochłonnych operacji, jak wklepanie w klawiaturę nazwy pliku lub powrót do DOSu (ładowanie command processora) po zakończeniu odtwarzania. A jeśli będzie to 40%, jak szacuje Pinokio nieco później - to w liczbach bezwzględnych różnica już poniżej 1/10 sekundy.

Pinokio: wspomniane przez Ciebie w pierwszym poście TipView i Xunzip (tego drugiego domyślam się po "obsłudze archiwów ZIP") też są pakowane flashpackiem, i co, aż tak długo się wczytują?

Ostatnio edytowany przez epi (2011-06-17 00:15:35)

A mi nie chodzi o różnicę kilku części sekundy, tylko o to że bardzo lubię wgrywać pliki do playerów. Pliki wykonywalne też lubię, ale trochę mniej ;)

Rozumiem zatem, że wycofujesz się z tego, co napisałeś w poście #11?
Ponadto topic nie pasuje do "Fabryki", łamiąc punkty 2. i 3. "Zasad tego podforum".