Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

• Zapomniane hasło?
• Poproś o członkostwo

1. • 1: CommentAuthorilmenit
   • CommentTime20 Jul 2012 13:07 zmieniony

    
   @larek
   GUI mega wypaśne! Znalazłem mały błąd - jeżeli w katalogu Generator znajdują się jakieś pliki output.*, to GUI przy "Create Executable File" zawsze tworzy plik wykonywalny z tych w katalogu Generator.
   
   "Create Executable File" można zmienić na "Create executable file".
   
   No i czy pisałem, że GUI jest mega wypaśne teraz? ;) Nawet ja, miłośnik command-line będę go pewnie używał, bo teraz testowanie parametrów preprocessu jest teraz znacznie szybsze :)
   
   Aha, znalazłem też błąd u mnie - użycie /dither=knoll jednocześnie z /preprocess powoduje zwiechę programu.
2. • 2: CommentAuthorilmenit
   • CommentTime20 Jul 2012 13:07

    
   @jhusak
   ->link<-
   
   .NET mimo wielu wad ma jednak tą zaletę, że tworzy w nim się programy cholernie szybko, szczególnie mające GUI. Bez porównania szybciej niż w wieloplatformowych QT, GTK+ czy WxWidgets.
3. • 3:
      
     CommentAuthorDracon
   • CommentTime20 Jul 2012 13:07

    
   Fajnie, ze autor Altirry zoptymalizowal program, ale czy przewidziane bedzie "dopalenie" programu przez przeniesienie obliczen na OpenCl? To idealne zastosowania do wykorzystania drzemiacych rezerw wspolczesnych kart graficznych... no i zdeko szybciej powinno byc. :)
   Pytam z pozycji uzytkownika.
4. • 4:
      
     CommentAuthormgr_inz_rafal
   • CommentTime20 Jul 2012 13:07

    
   GUI powinno pójść na Linuxie przy pomocy Mono.
5. • 5:
      
     CommentAuthorjhusak
   • CommentTime20 Jul 2012 13:07

    
   No i na osX też jest mono, ale sorki, 100 MB, aby uruchomić gui?
   FreePascal jest lepszy :) I szybszy :)
   
   @ilmenit, skompilowałem pod osX, ale bez allegro, więc mam tylko znaczki na konsoli - ale działa :)
6. • 6: CommentAuthorilmenit
   • CommentTime20 Jul 2012 13:07

    
   @Dracon
   Do dowolnego zrównoleglenia wykoniania większość programu trzeba by przepisać. A ja mam teraz chęć bardziej na dokończenie innych rozgrzebanych projektów... :)
7. • 7:
      
     CommentAuthorjhusak
   • CommentTime20 Jul 2012 14:07

    
   Pod freepascal też się szybciutko tworzy aplikacje :) Podejrzewam, że nawet szybciej w prostych przypadkach :) Takie mam wrażenie :)
   
   Np. pod net MUSISZ wiedzieć, kiedy co jaki wątek robi. Jeśli się pomylisz, wali ci LOSOWO wyjątkami (95% czasu nie wali, ale raz na jakiś czas...)
   
   To wg mnie dyskwalifikuje narzędzie, jako "środowisko do pisania dużych aplikacji". Co z tego, że szybko, skoro testowanie gdzie jeszcze ktoś nie obsłużył wyjątku zajmuje wieczność?. Oczywiście, warstwy, architektura, itp może pomóc, ale problemu nie rozwiąże.
   
   I to "invoke" - to wygląda na jakiś straszny wytrych do czegoś, co można zrobić wprost... Tak jakby ktoś tego nie przewidział w fazie projektowej a potem co drugie wywołanie to przekazanie metody do wykonania...
   
   Pod freepascal nie zauważyłem takiej dysfunkcji. Działa i już. Czyli można :)
8. • 8:
      
     CommentAuthorlarek
   • CommentTime20 Jul 2012 14:07 zmieniony

    
   I nastał ten czas!
   
   Dzięki Ilmenitowi, który poświęcił mi sporo swojego cennego czasu i przewrócił wygląd GUI do góry nogami (za co mu serdecznie dziękuję) nowa wersja jest już gotowa.
   
   Zapewne nie wszystko jest idealne, ale z pewnością wystarczy, żeby pobawić się RastaConverterem i jego nowymi opcjami.
   
   Dla przypomnienia dodam, że plik RCGUI.exe należy wypakować do katalogu, w którym znajduje się RastaConverter.exe. Do tego samego katalogu wrzucamy pliki z grafiką do konwersji.
   
   Miłej zabawy :)

   • RCGUI (0.0.1.7).7z
9. • 9:
      
     CommentAuthorKaz
   • CommentTime20 Jul 2012 19:07

    
   Dziekuje panowie za nowe GUI!
   
   Pytanie: dlaczego defaultowo w okienku preprocess jest ustawiony "color distance: ciede", a okienku convertion jest "color distance: yuv"? Czy to tak ma byc?
   
   Pytanie drugie: czy konieczne jest to za kazdym razem wyskakujace okienko, ktore nas informuje, co przetwarzamy? Zwalnia to dzialanie :)
   
   Pytanie trzecie: czy znacznie spadla szybkosc dzialania RC beta 5.1 w stosunku do beta4? Bo ja mam takie wrazenie, ze wszystko przebiega znacznie wolniej. Byc moze to u mnie cos nie halo, wiec wole zapytac.
10. • 10:
       
      CommentAuthorlarek
    • CommentTime20 Jul 2012 19:07 zmieniony

     
    Odpowiedź: fragment help.txt
    /distance=Color distance function
    Default: yuv
    /predistance=Color distance function for preprocess
    Default: ciede
    
    Odpowiedź druga: nie, nie jest konieczne, ale możemy zobaczyć z jakimi dokładnie parametrami będzie wywołany RastaConverter. To tylko jedno kliknięcie, więc zbytnio nie zwolni działania.
    
    Odpowiedź trzecia: z tego co się orientuję (czyli niewiele) został w Beta5 wprowadzony w miejsce starego jakiś nowy algorytm. Ponoć z początku działa wolniej, ale za to później daje lepsze efekty. Czy jakoś tak ;)
11. • 11: CommentAuthorilmenit
    • CommentTime20 Jul 2012 20:07

     
    "Pytanie: dlaczego defaultowo w okienku preprocess jest ustawiony "color distance: ciede", a okienku convertion jest "color distance: yuv"? Czy to tak ma byc?"
    
    Tak. Odległość kolorow Ciede2000 daje w większości przypadków znacznie lepsze efekty przy tworzeniu obrazka docelowego niż YUV czy Euclid. Wadą jest to, że jest wolny. Preproces obrazka jest robiony raz, więc tam może być wolniej.
    
    "Pytanie trzecie: czy znacznie spadla szybkosc dzialania RC beta 5.1 w stosunku do beta4? Bo ja mam takie wrazenie, ze wszystko przebiega znacznie wolniej. Byc moze to u mnie cos nie halo, wiec wole zapytac."
    
    Może wydawać się, że jest wolniej, bo zmniejszyłem częstotliwosć odświeżania wygenerowanego obrazka.
    Ale najlepiej sprawdź jakie masz Rate w obydwu wersjach i daj znać. Najlepiej gdy odpalisz to na tym samym obrazku z parametrami:
    /predistance=yuv /s=1 /init=random
    Zobacz też w której wersji szybciej maleje Normalized Distance.
12. • 12: CommentAuthorwieczor
    • CommentTime20 Jul 2012 23:07

     
    Wiecie oczywiście że jak program nie jest wielowątkowy to możecie sobie rozkładać :) Po prostu będzie pracować po trochu na każdym rdzeniu chwilę tu, potem tu... Plus jest taki że pozostałe programy będą miały więcej swobody. Ale równolegle pracować nie będą, bo nie ma takiej fizycznej możliwości, jeśli algorytm jest sekwencyjny. Tylko podział na niezależne zadania daje prawdziwy dopał, ale wtedy nic nie trzeba ustawiać - Windows automatycznie rozkładają thready po poszczególnych rdzeniach
13. • 13:
       
      CommentAuthorjhusak
    • CommentTime21 Jul 2012 00:07

     
    Jest cała gałąź wiedzy informatycznej zajmująca się algorytmami współbieżnymi i równoległymi :) I nie wszystkie algorytmy dają się łatwo i prosto przetłumaczyć na wersję zrównolegloną.
    
    

    Tylko podział na niezależne zadania daje prawdziwy dopał

    
    
    No właśnie, a sposób przetwarzania RC nie jest łatwo podzielić na niezależne zadania IMO. Skórka za wyprawkę :) Jeśli by zrobić wsadowe przetwarzanie, to wtedy OK. Ale jeden obrazek?
14. • 14: CommentAuthorGonzo
    • CommentTime21 Jul 2012 00:07

     
    jhusak - ja tak sobie myślałem, żeby przygotować paczkę ze 100 000 obrazków i dopiero wtedy uruchomić agenta :)
15. • 15: CommentAuthornosty
    • CommentTime21 Jul 2012 00:07

     
    Przepraszam jesli znow wykaze sie brakiem wiedzy w temacie, ale przyszedl mi do glowy banalny pomysl, upraszczajac: a gdyby podzielic obrazek poziomo na dwie czesci i potraktowac je jak dwa osobne obrazki 320x120 i zapuscic na dwoch rdzeniach iteracje dla kazdej czesci osobno na dwoch "kopiach programu", a potem zlozyc do kupy dodajac jedno przerwanie DLI "na spawie"?
16. • 16:
       
      CommentAuthorjhusak
    • CommentTime21 Jul 2012 01:07 zmieniony

     
    Nie ma przerwań DLI w RC. A jakby były, to i tak nie zdążysz przerzucić:
    - kolorów grafiki
    - kolorów sprajtów
    - pozycji sprajtów
    - rozmiaru sprajtów
    
    Jak zajrzysz w kod wygenerowanego obrazka to się zdziwisz, jak ilmenit potrafi robić coś, co dla zwykłego śmiertelnika (jak ja) jest co najmniej niewykonalne :P I kolory nie przeskakują... nawet o pixel...
    
    Na początku obrazka jest słynne:
    

    sta WSYNC
    sta WSYNC
    

    
    
    a następnie potok kodu BEZ ŻADNYCH wsynców i innych synchonizatorów (przynajmniej tak było w wersjach pierwszych :)
    WSZYSTKO AUTOMATYCZNIE WYCYKLOWANE CO DO PIKSLA!
    
    A'propos piksla, pixla, piksela, pixela...
    

    qbahusak®:

    Piks, Ela
    Straciłaś przyjaciela...
    
17. • 17: CommentAuthornosty
    • CommentTime21 Jul 2012 01:07

     
    No to naprawde kopara mi teraz opadla :) Do tej pory myslalem ze algorytm ktory potrafi tak poskladac obrazek to AI ;)
    Mimo to moze daloby sie rozbic robote na 2 lub wiecej czesci, w sposob jaki zaproponowalem, a te czesci moglby sie jakos "dogadac" co do styku (np gorna czesc zostawialaby kilkadziesiat taktow do ustawienia rejrstrow kolorow i sprajtow dla dolnej). Nawet gdyby moglo to zaowocowac jedną linia gorszej jakosci...
18. • 18: CommentAuthortebe
    • CommentTime21 Jul 2012 14:07

     
    postuluję o poprawkę do RC dotyczącą wartości jakie zapisuje do rejestrów koloru bitmapy i PMG w plikach wynikowych ASM
    
    Atari w trybach nie-GTIA ma 128 kolorów, tak że kolor $7c i $7d to ten sam kolor, jednak RC nie obcina najmłodszego bitu (AND #$FE)
    
    teraz gdy wczytam plik z RC do nowej wersji G2F kolory nie są jednolite, gdyby G2F wyświetlał tylko ten jedyny tryb nie byłoby problemu z obcięciem bitu, jednak G2F korzysta z pełnej palety 256 aby wyświetlać też tryby GTIA i VBXE
19. • 19:
       
      CommentAuthorKaz
    • CommentTime21 Jul 2012 22:07

     
    Larek, Ilmenit - bardzo dziekuje za odpowiedzi.
    
    

    Larek:

    Odpowiedź druga: nie, nie jest konieczne, ale możemy zobaczyć z jakimi dokładnie parametrami będzie wywołany RastaConverter. To tylko jedno kliknięcie, więc zbytnio nie zwolni działania.

    
    
    Spowalnia, bo przy wielu probach, wielu parametrach, klikam niepotrzebnie to okienko po kilkadziesiat razy. Niepotrzebnie, bo przeciez wiem, z jakimi parametrami bedzie wywolany RC, jako ze sam te parametry ustawialem.
    
    Wydaje mi sie, ze poprzednie rozwiazanie bylo znacznie lepsze: info pojawialo sie wczesniej i jak ktos chcial, to czytal, a jak nie to nie czytal :). Nic nie trzeba bylo klikac.
    
    

    Ilmenit:

    Tak. Odległość kolorow Ciede2000 daje w większości przypadków znacznie lepsze efekty przy tworzeniu obrazka docelowego niż YUV czy Euclid. Wadą jest to, że jest wolny. Preproces obrazka jest robiony raz, więc tam może być wolniej.

    
    
    Czy dobrze rozumiem, ze z tego wynika, ze przy domyslnych ustawieniach obrazek preprocessowy bedzie wygladal inaczej niz to, co rzeczywiscie osiagniemy na koncu? Czy nie lepiej w takim razie defaultowo dawac w obu przypadkach to samo? Kto zechce, to sobie ustawi szybsze/lepsze. A tak to moze byc mylace.
    
    

    Ilmenit:

    Może wydawać się, że jest wolniej, bo zmniejszyłem częstotliwosć odświeżania wygenerowanego obrazka.

    
    
    Wydawalo mi sie, wiec to musi byc to.
20. • 20: CommentAuthornosty
    • CommentTime22 Jul 2012 10:07

     
    Dzizus... wciagnelo mnie tak, ze przygotowuje chyba juz 8 obrazek kosztem kodowania gry ;)
    Niby "robi sie samo" godzinami, ale jakos trudno sie oderwac od eksperymentowania i patrzenia na postepy.
    
    Tak sobie pomyslalem a propos dyskusji nad uzyciem tego programu na compo i granicach zrzynania/plagiatu: wyobrazcie sobie sytuacje ze Ilmenit opracowal ten program po cichu. Odpowiednie ustawienia ditheringu i dobrze dobrany obrazek zrodlowy, powodują ze wynik moze wygladac jak starannie recznie wypikselowane arcydzielo. W wersji 5 juz praktycznie nie ma "problemu poziomych linii".
    Przeciez Ilmenit uzywajac tego programu wygralby wiekszosc konkursow i zostal okrzykniety wschodzącą gwiazdą grafiki Atari ;)
21. • 21:
       
      CommentAuthorlarek
    • CommentTime22 Jul 2012 11:07 zmieniony

     

    Kaz:

    Spowalnia, bo przy wielu probach, wielu parametrach, klikam niepotrzebnie to okienko po kilkadziesiat razy. Niepotrzebnie, bo przeciez wiem, z jakimi parametrami bedzie wywolany RC, jako ze sam te parametry ustawialem.

    
    Jak to niepotrzebnie?! Spróbuj nie kliknąć! ;))
    
    Ale dobrze, usunę to potwierdzenie. Mam do zrobienie kilka poprawek, np. wyłączyć rozszerzalność okna, ale również może uda się wprowadzić wybieranie grafiki z dowolnego katalogu (info od Grega w komentarzu pod nowinką), więc i mogę poprawić szybkość pracy :)
    
    PS.
    A może ktoś miałby ochotę zaprojektować ładną ikonkę dla programu?
22. • 22: CommentAuthornosty
    • CommentTime22 Jul 2012 11:07

     
    Proszę o potrzebną poprawke do RC: klawisz PAUSE/CONTINUE.
    Ja wiem ze jest opcja /continue, ale po jej uzyciu za kazdym razem program generuje od poczatku obrazek docelowy, co trwa kilkanascie minut, a dopiero potem kontynuuje iteracje.
    A czasami potrzeba jest przerwac program na chwile zeby zrobic cos obciazajacego na komputerze, bo RC zabierac 100% mocy procesora.
    Nie wiem jak to wszystko dziala programowo, ale to chyba jest prosta sprawa?
    Z gory dzieki.
23. • 23:
       
      CommentAuthorjhusak
    • CommentTime22 Jul 2012 14:07

     
    Przecież @nosty wystarczy label ze statusem na dole :)
24. • 24:
       
      CommentAuthorvoy
    • CommentTime22 Jul 2012 16:07

     
    Melduję o błędzie w RC: na Windows 7 x64 SP1 po wybraniu opcji /continue program generuje obrazek docelowy (u mnie to kwestia kilkunastu sekund), na chwilę wyświetla się ilość poprzednich iteracji, po czym następuje zwis i meldunek "Program RastaConcerter.exe przestał działać."
    
    Z innej beczki: udało mi się uruchomić menedżer zadań na prawach administratora i podnieść priorytet RastaConvertera na "Wysoki". Niestety, w dalszym ciągu wykorzystuje tylko 25% zasobów procesora. :(
25. • 25:
       
      CommentAuthorlarek
    • CommentTime22 Jul 2012 16:07

     
    Tak strzelam - czy w międzyczasie nie zmieniłeś żadnego pliku output*.*?
    U mnie /continue wznawia pracę bez problemów, a mam również W7x64 SP1.
26. • 26:
       
      CommentAuthorvoy
    • CommentTime22 Jul 2012 17:07

     
    Nie, wszystkie pliki mają wczorajszą datę i dziś nie były niczym otwierane. Nie pomaga kasowanie plików output.png-src.png i output.png-dst.png, które tworzone są na początku pracy programu.
27. • 27:
       
      CommentAuthormgr_inz_rafal
    • CommentTime22 Jul 2012 18:07

     

    voy:

    udało mi się uruchomić menedżer zadań na prawach administratora i podnieść priorytet RastaConvertera na "Wysoki". Niestety, w dalszym ciągu wykorzystuje tylko 25% zasobów procesora. :(

    Jeśli program jest jednowątkowy (a tak domniemuję z wcześniejszej dyskusji), to nie uzyskasz więcej. "Tylko" 25% wynika z tego, że pewnie masz 4 rdzenie. Gdybyś miał stary, jednordzeniowy procek, to miałbyś zużycie na poziomie 100%.
28. • 28:
       
      CommentAuthorlarek
    • CommentTime22 Jul 2012 18:07

     

    mgr_inz_rafał:

    (...)"Tylko" 25% wynika z tego, że pewnie masz 4 rdzenie.

    
    
    Czyli jeden rdzeń pracuje na 100%, ale procesor jako całość na 25%. Tak?
    Pytam, bo się nie znam, więc się nie śmiać ;)
29. • 29:
       
      CommentAuthorvoy
    • CommentTime22 Jul 2012 18:07 zmieniony

     
    Zgadza się. :) Choć być może dokładnie tak nie jest - procesor tak rozkłada wykonywanie tego zadania pomiędzy rdzenie, by łącznie zużywały 25% zasobów. Na upartego programami typu CPU Control, SMP SeeSaw Pro albo Process Lasso można na sztywno przypisać go do konkretnego, pojedynczego rdzenia, ale i tak będzie użyta taka część procentowa procka, ile ma rdzeni.
    
    Ech, dopóki RastaConverter nie będzie wielowątkowy, można pomarzyć o wykorzystaniu całego "pałera" CPU, zwłaszcza wielordzeniowego. :) Chodzi mi o przyspieszenie obliczeń.
30. • 30:
       
      CommentAuthorKaz
    • CommentTime22 Jul 2012 18:07

     
    Ja z kolei wolalbym, zeby ustawic nizszy priorytet dla RC. Jak widze, jedni chca wiekszy, inni mniejszy. Czy daloby sie tak zrobic, zeby wysokosc priorytetu byla ustalana w RCGUI zamiast grzebania w zasobniku Windowsa?
31. • 31:
       
      CommentAuthorlarek
    • CommentTime22 Jul 2012 20:07 zmieniony

     

    Kaz:

    Czy daloby sie tak zrobic, zeby wysokosc priorytetu byla ustalana w RCGUI (...)

    
    Ja się dziwię, że całe to GUI mi działa, a Ty mi tu wymyślasz jeszcze jakieś priorytety :P
32. • 32:
       
      CommentAuthormgr_inz_rafal
    • CommentTime22 Jul 2012 20:07

     
    Najlepiej zostawić priorytet "Normalny" i pozwolić działać systemowi operacyjnemu - on świetnie daje sobie radę :)
33. • 33:
       
      CommentAuthorDracon
    • CommentTime22 Jul 2012 20:07

     
    Fajnie, ze program pokazuje jaki docelowo bedzie obrazek po wybraniu parametrow, ale czy moglby tez podac orientacyjny czas potrzebny do osiagniecia w/w finalu?
    Nie bijcie, jesli cos przoczylem... :)
34. • 34: CommentAuthornosty
    • CommentTime23 Jul 2012 00:07

     
    "Przecież @nosty wystarczy label ze statusem na dole :) "
    
    Jakub, a bardziej dla opornych? :P
35. • 35:
       
      CommentAuthorjhusak
    • CommentTime23 Jul 2012 01:07

     
    Label to taki obiekt gui - tekst :)
    A status zamiast pisać w okienku, umieszczasz w tym labelku bezinwazyjnie. Oczywiście to larek umieszcza :)
36. • 36:
       
      CommentAuthorlarek
    • CommentTime23 Jul 2012 08:07

     
    @jhusak, to teraz dla jeszcze bardziej opornych ;)
    Ale o co chodzi? Co nam da umieszczenie tekstu (jakiego?) w label i jak to się ma do możliwości stopowania RC przez GUI? Ja jestem prosty człowiek i do mnie trzeba prosto mówić ;)
37. • 37: CommentAuthornosty
    • CommentTime23 Jul 2012 09:07

     
    Jakub, Larek - to jakies nieporozumienie. Ja nie chce nic od GUI bo nie uzywam (sorry Larek ale nie udalo mi sie).
    Chce zeby w samym RC byl skrot klawiaturowy np shift+p (analogicznie jak Shift+s do zapisu), ktory zatrzymalby na chwile dzialanie programu, a po ponownym nacisnieciu wznowil.
    Chodzi mi o chwilowe zwolnienie zasobow procesora, kiedy musze cos zrobic szybko na kompie.
    Opcja /continue sie tu nie nadaje bo znow musze 15min czekac na wygenerowanie obrazka docelowego.
38. • 38:
       
      CommentAuthorlarek
    • CommentTime23 Jul 2012 09:07

     
    Nosty, całkowicie Ciebie rozumiem. Moje pytanie było do Kuby, bo to jego całkowicie nie rozumiem :)
39. • 39:
       
      CommentAuthorxeen
    • CommentTime23 Jul 2012 09:07

     
    moim zdaniem można też ewentualnie i przy okazji dorobić, przy opcji continue, po prostu brak kalkulacji tego obrazka docelowego ponownie.
40. • 40: CommentAuthorilmenit
    • CommentTime23 Jul 2012 09:07

     
    Odpowiedź zbiorcza, bo trochę się tego nazbierało przez weekend:
    "Mimo to moze daloby sie rozbic robote na 2 lub wiecej czesci, w sposob jaki zaproponowalem, a te czesci moglby sie jakos "dogadac" co do styku (np gorna czesc zostawialaby kilkadziesiat taktow do ustawienia rejrstrow kolorow i sprajtow dla dolnej). Nawet gdyby moglo to zaowocowac jedną linia gorszej jakosci.
    
    Niestety, to nie działa dobrze. To testowałem jako pierwsze razem z krzyżowaniem obrazków algorytmami genetycznymi.
    
    "Atari w trybach nie-GTIA ma 128 kolorów, tak że kolor $7c i $7d to ten sam kolor, jednak RC nie obcina najmłodszego bitu (AND #$FE)"
    
    Nie obcinał, bo nie było potrzeby... Planowałem i tak dorobić "czyszczenie" generowanego programu rasta, aby usunąć na koniec niepotrzebne instrukcje, pozostawione historycznie w procesie optymalizacji. Dorobię przy okazji obcinanie bitu.
    
    "Czy dobrze rozumiem, ze z tego wynika, ze przy domyslnych ustawieniach obrazek preprocessowy bedzie wygladal inaczej niz to, co rzeczywiscie osiagniemy na koncu?"
    
    Preproces dotyczy generowania obrazka docelowego, do którego dąży algorytm optymalizacji. Warto mieć go wygenerowanego jak najlepszej jakości. Zatem:
    /predistance=ciede - jest używany do uzyskania obrazka docelowego -dst
    /distance=yuv - jest używany w procesie optymalizacji, który na wejście dostaje obrazek -dst
    
    "Ja wiem ze jest opcja /continue, ale po jej uzyciu za kazdym razem program generuje od poczatku obrazek docelowy, co trwa kilkanascie minut, a dopiero potem kontynuuje iteracje."
    
    Planuję dodać aby /continue korzystało z wcześniej wygenerowanego obrazka. Będzie to przydatne dla bardzo wolnego Knoll Dithering.
    
    "A czasami potrzeba jest przerwac program na chwile zeby zrobic cos obciazajacego na komputerze, bo RC zabierac 100% mocy procesora."
    
    Task Managerem w systemie Windows służy do zmiany priorytetu procesu. Polecam jego lepszą wersję ->link<- która umożliwia całkowite zatrzymanie procesu.
    
    "Melduję o błędzie w RC: na Windows 7 x64 SP1 po wybraniu opcji /continue program generuje obrazek docelowy (u mnie to kwestia kilkunastu sekund), na chwilę wyświetla się ilość poprzednich iteracji, po czym następuje zwis i meldunek "Program RastaConcerter.exe przestał działać."
    
    Masz na pewno wersję Beta5.1? W dostępnej przez chwilę Beta 5.0 był taki błąd.
    
    "Fajnie, ze program pokazuje jaki docelowo bedzie obrazek po wybraniu parametrow, ale czy moglby tez podac orientacyjny czas potrzebny do osiagniecia w/w finalu?"
    
    Nie, bo najprawdopodobniej nigdy nie dojdzie do czegoś takiego jak final. Sam musisz zdecydować, kiedy przerwać program.
41. • 41:
       
      CommentAuthorlarek
    • CommentTime23 Jul 2012 12:07 zmieniony

     

    ilmenit:

    Preproces dotyczy generowania obrazka docelowego, do którego dąży algorytm optymalizacji. Warto mieć go wygenerowanego jak najlepszej jakości. Zatem:
    /predistance=ciede - jest używany do uzyskania obrazka docelowego -dst
    /distance=yuv - jest używany w procesie optymalizacji, który na wejście dostaje obrazek -dst

    
    
    A jak nie użyjemy /predistance, tylko od razu zaczniemy optymalizację, to obrazek -dst wg czego jest generowany?
42. • 42: CommentAuthorilmenit
    • CommentTime23 Jul 2012 12:07

     
    Według domyślnego parametru, czyli /predistance=ciede
43. • 43:
       
      CommentAuthorlarek
    • CommentTime23 Jul 2012 12:07 zmieniony

     
    I wszystko jasne :)
    Czyli RC - do wersji beta4 lub powyżej, gdy nie użyjemy /predistance - robi to po "cichu" i na sztywno z parametrem -ciede. Poprzez /predistance mamy na to już jakiś wpływ.
44. • 44: CommentAuthorilmenit
    • CommentTime23 Jul 2012 12:07

     
    Możliwość wyboru różnej odległości koloru jest dopiero od beta5. Wcześniej /distance ustawiał to samo zarówno dla preprocesu jak i optymalizacji.
45. • 45:
       
      CommentAuthorvoy
    • CommentTime23 Jul 2012 17:07

     
    Dzięki za odpowiedź. Dla pewności pobrałem ze strony domowej najnowszą wersję RC - efekt identyczny: zwis programu. :(
46. • 46:
       
      CommentAuthorxeen
    • CommentTime24 Jul 2012 12:07

     
    wczoraj czytałem w jakimś tam Bajtku jak jeden z redaktorów pisał, że Atari owszem ma lepsze możliwości graficzne niż C64, ale znacznie trudniej te możliwości uzyskać / wydobyć. Kto by pomyślał, że do ich uzyskania będzie potrzebny komputer z 21 wieku o mocy obliczeniowej wielokrotnie razy silniejszej ;)
47. • 47: CommentAuthorGonzo
    • CommentTime24 Jul 2012 22:07 zmieniony

     
    xeen - wszystko co napisał ten redaktor to nieprawda, atarka ma zdecydowanie słabsze możliwości graficzne od c64 (poza dostępną ilością kolorów ofkoz), za to o wiele łatwiej można je wykorzystać :)
    
    co się tak wszyscy rozgadali, tyle postów, a obrazków jak na lekarstwo :)
    
    
    
    muza - nooly mono
    
    tebe - kiedy można się spodziewać najnowszego g2f? nie mogę się doczekać na pierwsze dziecko rc i g2f. wbrew temu co niektórzy piszą, że graficy staną się zbędni i takie tam, to myślę, że teraz mają poprostu o wiele większe pole do popisu, bo rc i g2f przejechały się jak walec po ograniczeniach jakie ma atarka i umożliwiają wreszcie w miarę swobodne tworzenie grafy na a8 (nie mówię tu o sobie, bo ja grafikiem nie jestem)

    • butterfly_rmt.xex
48. • 48: CommentAuthornosty
    • CommentTime25 Jul 2012 00:07

     
    @gonzo - sorry za dosadne slowa ale pieprzysz az glowa boli! Zarowno G2F, jak i tym bardziej RC byly pomyslane jako konwertery grafiki a nie narzedzia do rysowania.
    
    Pokaz mi prosze jak "w miare swobodnie tworzyc grafe" za pomocą RC: w miarę swobodnie wypikseluj motylkowi skrzydla zeby byly rowniejsze :P
    
    BTW obrazek bardzo dobry!
    Ja swoje na razie trzymam w szufladzie bo nie do konca jestem zadowolony z efektow.
49. • 49: CommentAuthorGonzo
    • CommentTime25 Jul 2012 00:07

     
    nosty - a kto ci każe pikslować w rc ?? (chociaż jest to możliwe), niczego takiego nie napisałem, jest dokładnie tak jak mówisz - chodziło mi o przeniesienie na a8 obrazka, który oczywiście trzeba przygotować na piecyku - rc odwala całą czarną robotę, a g2f dopieszcza końcowo :)
50. • 50:
       
      CommentAuthorDracon
    • CommentTime25 Jul 2012 00:07 zmieniony

     
    Pikslowac warto w tym:
    ->link<-
    ... jak zreszta czyni(l) Vidol i Piesiu. :)
    
    A tak z ciekawosci (pyt. do testerow RC) ile czasu trzymacie swoje PieCyki wlaczone do obliczen nad danym obrazkiem, slowem - kiedy konczy sie Wam cierpliwosc??? ;)
    
    
    

    ilmenit:

    Nie, bo najprawdopodobniej nigdy nie dojdzie do czegoś takiego jak final. Sam musisz zdecydować, kiedy przerwać program.

    
    
    Nie bardzo zrozumialem idee - skoro program po uruchomieniu dosc szybko pokazuje jak moze wygladac obrazek "docelowo" po ustawieniach (okienko z prawej strony), a teraz okazuje sie, ze to proces nieskonczonie dlugotrwaly, to czy jest sens cos takiego ujawniac (tzn. ten "finalny" obrazek), skoro proces jest dynamiczny ? Bo nie wiem czy dla dobrych efektow dac popracowac komputerowi 2 godziny, czy cala noc... ;]