Przygotowałem kilka obrazków miksowanego trybu 15 i 11 (bez interlace). Oceńcie proszę, czy taka grafika jest wystarczająco czytelna do gry RPG. Załączam też pliki wykonywalne (paleta Laoo.act) oraz narzędzie, które pozwala testować różnie miksowane tryby.
Calkiem niezle wygladaja te eksperymenty... :) Jak jest zapotrzebowaniem na pamiec (pewnie dzieki zastosowaniu trybu "harmonijki" jest potrzebne 2x mniej?) ? Czy przewidujesz w tej technice jakies animacje?
Zapotrzebowanie na pamięć jest identyczne dla trybów 9, 10, 11 i 15 i nie zmienia się gdy je naprzemiennie wyświetlamy. Na pełnoekranowy obrazek potrzeba ok. 8KB pamięci. Gdy w grze mają być przezroczyste obiekty, to konieczna jest oczywiście dodatkowo maska przezroczystości.
Z animacjami nie ma problemu a i pamięć przy wykorzystaniu np. carta MaxFlash pozwoli na zrobienie dowolnie złożonej graficznie gry.
Na małym ekranie wygląda świetnie. Robi wrażenie. Jednak na dużym ekranie, to niestety już tak dobrze nie jest. Mimo to sądzę, że śmiało można w tej grafice coś zrobić.
There is another possibility, a mode I call DIN ... mixing Gr. 8 with Gr. 15. It requires a display list change on each line, alternating with mode 8 and mode 15, plus a change of register 710 each line as well so that you can have that color available in 15, and have a solid background. should give you 8 colors at Gr. 8 resolution, plus another 8 if you include Gr. 8 artifacting. I did something similar, only using text mode (Gr. 0 + gr. 12) and flickering. if you are only using one screen, you could change the blank line instruction at the top of your display list every VBLANK, have it alternate between 7 and 8 lines. This will enable your scan lines to jump up and down and mix the colors.
You can also blend two Gr. 9 screens using a color change every scanline on 712, this will get you 256 duo-tone shades. Again, using the same trick to blend colors.
Dodałem do PicMixera tryb interaktywny, który w czasie rzeczywistym konwertuje grafikę dla wybranego okna. Aby go włączyć trzeba zamiast nazwy pliku do konwersji jako pierwszy parametr podać słowo window. Następnie klawiszem Shift wybieramy, które okno chcemy śledzić. Śledzimy oczywiście okno w programie graficznym, co pozwoli nam w czasie rzeczywistym podglądać jak wyglądać będzie grafika po konwersji.
... nie mówiłem, że HDM mi się nie podoba, NIE chodzi mi już nawet o poprawki związane z działaniem na dowolnym OS'ie, chodziło mi wyłącznie o ukończenie wersji PL tak, by była w całości wraz z intrem. Czy to jest "kilka osób, którym gra i tak się nie podoba"? ;) -
Jest to polska gra, gdzie wersja dla "za_granicy" jest pełna, a dla swoich "okrojona". Chyba, że wersja PL została ukończona a ja o tym nic nie wiem ;)-
Jest to polska gra, gdzie wersja dla "za_granicy" jest pełna, a dla swoich "okrojona"
Dla mnie "swoi", to miłośnicy małego Atari z całego świata. Nie planowałem wersji polskiej i jak widzę słusznie, bo zainteresowanie nią jest mierne. Tworząc kolejne gry wersji PL też robić nie będę i od razu zastrzegam, że nie będę poświęcał na jej przygotowanie czasu nawet, gdy ktoś przetłumaczy wszystkie teksty na PL. Za dużo roboty z modyfikacją fontów, z łamaniem tekstu, kompilacją, ewentualnymi przeróbkami grafiki, dopasowaniem rozmieszczenia elementów na ekranie do długości tekstu itd.
.. po pierwsze to zastanów się, dlaczego tak jest. Gra jest bardzo dobra, jednak w pierwotnej wersji potwornie męczy nieczytelny font (który sobie poprawiłem w 15 minut) a i użyty j. angielski nie należy z czego wiem do współcześnie używanych - jak dla mnie osobiście nie jest szczególnie zrozumiały. Czyli wydaje mi się, iż to jest mniej więcej tak, jak byś włochowi znającemu język polski podał do przeczytania ze zrozumieniem gwarę góralską. Tym bardziej trudne zadanie nie zachęcające do dalszego działania. Sukces gwarantowany :)
Co do problemów przy "spolszczeniu", to nie jest to problem jeśli kod jest pisany wcześniej właśnie z myślą o takiej właśnie modyfikacji. Font - problem żaden, na łamanie tekstu wystarczy zrobić uniwersalną prockę, a tekst nie koniecznie musi być w kompilowanym kodzie. Wystarczy w pliku zewnętrznym z którego dane też można doczytać. Ok, nie wtrącam się - to Twoja gra, zrób jak uważasz - może być nawet po chińsku, skoro rodaków masz w ogólnym poważaniu ... że tak sobie pozwolę napisać :)- no nic, z mojej strony w temacie to tyle.
Dodałem do PicMixera gr.8 oraz zmieniłem trochę sposób przekazywania parametrów. Dla testu mix gr.8 i gr.9 przygotowałem interactive.bat
Dajcie proszę znać, czy o to chodziło.
Jak tego użyć: 1. Otwieramy np. MS Painta i obrazek 320x240 pikseli. 2. Robimy zooma np. na 300 procent oraz pokazujemy miniaturkę. 3. Uruchamiamy interactive.bat i z kursorem myszki na oknie miniaturki naciskamy Shift.
Suggestion: For better mix of graphics 8 and 9, use floyd steinberg dither on Graphics 8. Also set PF1 to about 10. Here is an example I did using M0 (0+9) mode. Using 8+9 is better though because of less flicker.
Jakoś nie muszę robić zooma w Paincie, żeby najechanie lupą od razu odpowiednio łapało obraz, ale zachowanie PicMixera jest trochę dziwne. Tzn. próbuję otworzyć zrzut ekranu gry z emulatora (336x240) i mam ustawione /mode1=9 /mode2=8 (taka kolejność jest w Assembloids XE), a mimo to otrzymuję obraz jakby te parametry były zamienione, a u góry i po lewej stronie widać jakąś wąską ramkę.
Hmm... ta część u góry ma 3 linie wysokości i to ona bez wątpienia jest przyczyną zaburzenia parzystości/ nieparzystości wierszy właściwego obrazka.
Jeśli testowo zamienię te parametry, to pomijając ramkę jest w miarę dobrze, przy czym kolory hiresu muszą być mniej więcej takie same na całym obrazku, bo jeśli część jest zbyt jasna, to te ciemniejsze są pomijane. No ale to drobiazg.
Co dalej można zrobić z takim przechwyconym obrazkiem?
Kilka uwag. 1. PicMixer działa aktualnie tylko z 320x240. 2. Wąska ramka jest przez to, że w oknie edycji obrazka dodaje ją Paint. Dlatego proponowałem wykorzystać do tego miniaturkę. Dodatkowo będzie można wtedy powiększać i przesuwać główne okno edycji. 3. Odnośnie kolorów hiresu - w Waszej grze zmieniają się w różnych liniach? Aktualnie jest próg - jeżeli jasność piksela jest większa niż 50%, to pixel jest biały. Jeżeli mniej, to czarny. Parametrem można ustawić jasność maksymalną. Dodam też, aby można było ustawić też kolor tła na inny niż czarny. 4. Co można zrobić z tak przechwyconym obrazkiem to już zależy od programisty :) Ten tool tworzy wynikowo obrazek out.bmp oraz plik pic.bin zawierający pamięć ekranu dla tak przeplatanego trybu (uwaga: nie testowałem pamięci dla trybu 8, ale powinno być chyba OK).
"For better mix of graphics 8 and 9, use floyd steinberg dither on Graphics 8." - that would help with direct conversion. For Adam I prepared a version that should allow pixel-perfect editing.
wow!! dzięki. za darmo od razu sprawdziłęm mix 15 i 8 ;) nawet, nawet - aczkowliek potencjalnie najmniej kosztuje, ale efekt wstępnie gorszy od poprzednich.
"jeżeli jasność piksela jest większa niż 50%, to pixel jest biały. Jeżeli mnie, to czarny"
Podstawowy problem jest tutaj taki, że przy technice użytej w Assembloids XE piksele hiresowe muszą być w miarę ciemne, żeby efekt podświetlania PMG dobrze zadziałał (zerknij na niebieską twarz pokazaną w powiększeniu w zapowiedzi gry). No i efekt przepuszczenia przez PicMixer jest taki, że hires znika (poza miejscami, gdzie użyto PMG do uzyskania jasnych kolorów). Może jakiś parametr do ustawiania progu czerń/biel? :)
Czy cała grafika w hires jest podświetlona duszkiem, czy są jakieś obszary bez podświetlenia? Obrazek na stronie zapowiedzi był przeskalowany z filtrem rozmywającym, więc trudniej się to analizuje.
Grafika hires podświetlana jest fragmentami, w zależności od potrzeb (twarze, napisy SCORE czy FACE) i na tyle, na ile PMG pozwala :) Ale generalnie na głównym panelu gry prawie wszędzie mamy w hiresie szary kolor $04 i taki poziom jasności by mnie głównie interesował.
> Obrazek na stronie zapowiedzi był przeskalowany z filtrem rozmywającym Chodzi Ci o screenshot z "FACE" na środku? Ja tam nie widzę filtra rozmywającego...
Tak jak pisałem, teraz będę głównie pracował nad panelem (twarze można uznać za gotowe w 99%). Chodziło mi o obrabianie jego fragmentów, więc jeśli chciałbyś zerknąć jak wygląda hires w Assembloids XE, to sugeruję obejrzenie zrzutu ekranu z gry. A ten obrazek twarzy trzeba będzie podmienić na taki bez filtra tak w ogóle.
Dodałem właściwości, o które prosiliście. Zmienił się trochę sposób przekazywania parametrów w command line. Opis w help.txt. Obsługa gr.10 wciąż nie poprawiona. Znacznie prostsze by było, gdybym mógł dostać do testów obrazek z gry bez nałożonych duszków oraz taki z nałożonymi duszkami. Jak tak dalej pójdzie, to przez ten edytor nie wyrobię się z moją grą na Abbuc... ;)
To się cieszę :-) PicMixer jest na tyle banalny, że wprowadzanie do niego poprawek i ulepszeń nie zabiera dużo czasu. Zatem jakby co - piszczcie. Myślałem np. o możliwości zadefiniowania maski duszków (jako drugiego obrazka) i nanoszenia jej na obrazek wynikowy. Czy byłoby to przydatne? Jeżeli tak, to ponownie bym prosił o zrzut ekranu z duszkami, bez i samej maski duszków.
Hmmm. Dlaczego mi to nie działa? Win Xp. Rozpakowałem na C. Klikam w PicMixer, batch.bat - nic. Lub interactive.bat - wowóczas pokazuje się okno z wielkimi literami i nic.. Q to quit... Hmmm... Jak to uruchomić?
Batch.bat - nie generuje pliku wynikowego? Nazwa powinna być widoczna w pliku .bat Interactive - działa jak powinno. Uruchom np. Painta, najedź tam myszką i przytrzymaj klawisz shift.
Aha! Mam. Tylko kolory uciekły? Co robię nie tak? tzn. przed "shift" kolory w PMix są, potem brak? po drugie: dobra, zapisujemy ten pic w windows. jak po przedziergać na jakiąś formę a8? przez g2f, RastCov? ale można zrobić od razu w G2F? Co więc jest w pMix? 7+15? dzieki za wyrozumiałość.
Po "shift" program w czase rzeczywistym konwertuje do wybranego mixu trybów graficznych. Wygenerowany plik .bin zawiera zrzut pamięci ekranu dla wybranych trybów. Aby to wyświetlić potrzebny jest programista, który przygotuje odpowiednią display listę. Nie wiem, czy można to jakoś prosto wczytać do G2F. Może chłopaki od "Asembloids XE" wiedzą jak to zrobić.
@bartcom Generalnie PicMixer obsługuje wiele kombinacji trybów (nie tylko 7+15, o którym to przypadku piszesz) i do pliku .bin zapisuje obrazek skonwertowany do postaci binarnej - bardzo przydatnej dla programisty, ale do jej ręcznej, przyjaznej użytkownikowi obróbki nie istnieje chyba dobre narzędzie. I tyle.
Wygenerowany z PicMixera plik .bin można co prawda przemianować na plik .mic i w tej postaci wczytać do Graph2Fonta - przy czym trzeba zadbać o dopasowanie wymiarów obrazka (a w zasadzie jego szerokości) do jednej z szerokości akceptowalnych przez G2F (opcje Screen: narrow/ normal/ wide, czyli 32/ 40/ 48 bajtów), inaczej na ekranie wyjdzie zupełna sieczka.
Tyle że już w samym Graph2Foncie nie mamy możliwości zmiany trybu co druga linię (najwyżej co 8 linii) - w związku z tym jakakolwiek edycja jest utrudniona, bo nawet gdy ustawimy sobie odpowiednie kolory dla jednego z dwóch trybów (występującego w co drugiej linii), to w pozostałych liniach będą widoczne pozorne "śmieci".
Tak więc wczytać można, ale niewiele z tego wynika - dopóki nie napiszemy sobie programiku asemblerowego, który będzie odpowiednio ustawiał kolory i zmieniał tryby na podstawie pliku binarnego.
W sumie funkcjonalność wyprodukowania od razu pliczku XEX przez PicMixera byłaby bardzo mile widziana w kolejnych wersjach :) No chyba, że Tebe się ugnie i zrobi w Graph2Foncie obsługę ustawiania dla danego wiersza znaków mieszania trybów co drugą linię...
