forum speccy.pl
ZX Spectrum => GRY => Wątek zaczęty przez: tooloud w 2019.05.21, 21:41:12
-
Tym, których nie było na tegorocznym Pixel Heaven 2019 i tym co nie dotrwali do 15tej w niedzielę wypada wrzucić informację, że ekipa związana ze speccy.pl w składzie Tygrys, Voyager i ja zrobiła w trakcie ok. 16 godzin grę przygodową z elementami wizualnymi (obrazki statyczne i ruchome czyli filmowe).
Całość "biega" na bardzo podstawowym ZX Spectrum, bo nawet na 48k, do posłuchania muzyki skomponowanej przez Voyagera wymagany jest AY (czyli modele 128k wzwyż albo zewnętrzne karty z AY), sekwencje wideo wymagają natomiast esxDOSa czyli divMMC czy divIDE jako interfejsu składującego i streamującego dane.
Grą wygraliśmy gamejam na Pixel Heaven 2019, kto był widział, (słychać było mało, bo technicy nie podłączyli nam dźwięku do kompa) kto nie widział musi albo zaspokoić chwilowo ciekawość oglądając filmik nagrany przeze mnie i opublikowany na fejsbukowej stronie speccy.pl:
https://www.facebook.com/speccypl/videos/333550740666865/ (https://www.facebook.com/speccypl/videos/333550740666865/)
Jesteśmy na etapie poprawiania paru rzeczy, jak skończymy to będzie dostępny gameplay na kanale YT speccy.pl.
-
16h i powstaje gra, nowoczesna i na ZXa. Zbieram szczękę z podłogi. A dla Waszej trójki gratulacje.
-
Fajny pomysł, fajne wykonanie, fajna muzyka!
No i zwycięstwo - gratulacje!
-
Gratulacje ! Zapowiada się niesamowicie. Nowa era gier na ZXa :D
-
Gratulacje!! W 16h?!! Mistrzowie.
-
Dokładnie. Podziwiam. Sam pisuję czasami coś w assemblerze i takie tempo to dla mnie jakieś szaleństwo :)
-
Takie tempo i jakie warunki. Tam nie było spokojnego zakątka, gdzie można by w spokoju się zaszyć.
-
Jacku, wszystko Tygrys napisał od zera w C - czyli Z88DK było grane.
-
Zauważyłem, że podczas odgrywania video pojawiają się losowe "śmieci" w postaci kwadratów. Czym to jest spowodowane? Nie widziałem tego na demkach wykorzystujących divideo.
PS. Gratulacje. Niezły crunch :)
-
Zauważyłem, że podczas odgrywania video pojawiają się losowe "śmieci" w postaci kwadratów. Czym to jest spowodowane?
Konwerter grafiki (dithering) robi jak widać czasami inwersję -> w kolorowej wersji tego nie widać bo zamiana ink<->paper to niweluje. Niestety przy konwersji do b&w taki 'kwiatek' się robi.
-
walczę teraz z takim torem: gfx bw z Photoshopa jako .pbm, skrypt przepisujący raw binary na zapis pamięci spectrumowej i będzie bez tego. Problem jest jak napisał Dalthon w konwerterach - to jest błąd interpretacji co jest tłem a co kolorem rysowanym.
-
Ja używałem img2zxspec (Java). Nie mogę tylko sobie przypomnieć jak dawałem radę z ładowaniem animowanego GIF jako pliku wejściowego. W każdym razie, ten konwerter potrafi wymusić jednolity kolor INK i PAPER. Możesz go nakarmić kolorowym AVI/MOV. Na wyjściu - plik .scr.
-
te artefakty są z niego właśnie - ale robi ich najmniej ;)
-
Tak, ale możesz WYMUSIĆ jeden kolor INK/PAPER. Wtedy nie powinno być artefaktów. Dzisiaj zrobię jeszcze test.
-
dokładnie tak robię, te artefakty są co ileś klatek, musiałbyś skonwertować na .scr ileś screenów (typu 150) i zapętlić to jako animację - jak załadujesz jeden ekran czy na ZX'a czy do ZX Paintbrusha to nie widzisz tego błędu, bo inwersja 8x8 jest niwelowana artybutem. Widać to dopiero jak pominiesz atrybuty i operujesz samą bitmapą 6k (w naszym przypadku 4k).
-
To nad czym teraz pracuję (testuję) to wyeliminowanie konwersji w img2zxspec. Zresztą - jakbyś wpadł do nas na gamejam zobaczyłbyś co ten program potrafi namieszać - gubi klatki, części klatek nie konwertuje (co prawda nie zmienia numeracji klatek/plików) - robiłem to na 2.01. Teraz skompilowałem 2.0.2 i sprawdzę czy coś się zmieniło. W preferencjach ustawione do trybu monochrome czarny ink, białe tło - ja serio używam tego programu od wczesnych wersji 1.x po prostu tych artefaktów z inwersją ink/paper i odwróceniem tego atrybutami nie widać jeżeli nie zrobisz większej ilości klatek, na jednej tego nie ma.
Druga rzecz - staram się teraz wyeliminować krok po kroku czy ma wpływ na to podanie mu gotowca cz-b bitmapy czy jednak jest to błąd przede wszystkim konwertera png/bmp/jpeg na spectrumowy zapis obrazu. Jest sporo zmiennych, nie uśmiecha mi się przeklikiwać ponad 2k klatek ręcznie, więc szukam rozwiązania, które zadziała i będzie na przyszłość.
Wsady - gif, klatki w png, bmp - efekt jest niestety ten sam. W pewnych kombinacjach bitmapy konwerter głupieje i można mu tylko zawęzić ilość informacji z wiadra wody do szklanki - być może to zadziała (na małej ilości klatek na razie sukces, ale niestety mam i 250 w jednej sekwencji i musi "pyknąć" w 100% dobrze wszystko).
Tygrys jak to Tygrys zrobił wszystko co miał do poprawienia i czeka aż ja skończę, a u mnie z czasem teraz słabo, klikam dzisiaj, potem dopiero niedziela - natomiast efekt końcowy ma być w 100% tym co miało być, a kompromisem w trzech pokoleniach.
-
Ok. Jasne. Ja go karmię już gotowymi klatkami cz-b z imageMagick... o cholera, teraz widzę, że IM potrafi zapisywać screeny ZX Spectrum bezpośrednio. Muszę to przetestować.
Widzę też, że XnView też potrafi zapisać ten format.
-
Taki delikatny offtopic.
Pod tym adresem https://dailly.blogspot.com/2017/07/esxdos-file-access.html (https://dailly.blogspot.com/2017/07/esxdos-file-access.html) jest o EsxDos i czytaniu/zapisywaniu plików spod ASMa. Post jest z 2017 roku. Czy to zadziała na 0.85 i 0.86 wersji EsxDosa? Czy sobie kartę / fejs rozwalę?
-
Zadziała. To podstawowe funkcje i zachowano kompatybilność wsteczną.
Trzeba tylko uważać, kiedy używać HL, a kiedy IX. To zależy od tego, czy aktywny jest Basic ROM, czy ESXDOS ROM.
-
Ok. Jasne. Ja go karmię już gotowymi klatkami cz-b z imageMagick... o cholera, teraz widzę, że IM potrafi zapisywać screeny ZX Spectrum bezpośrednio. Muszę to przetestować.
Widzę też, że XnView też potrafi zapisać ten format.
to czegoś nie rozumiem - z czego wnioskujesz, że ten program robi dobrze animację do formatu obrazu ZXa czyli pliki .scr?
img2zxspec potrafi zapisać gifa i ten gif wyświetla się prawidłowo, tylko - to nie jest obrazek do wyświetlania na ZXie. Seria klatek w .scr wali tymi błędami co wspomniałem - to są niestety błędy konwersji bitmapy korygowane atrybutami, czyli poprawianie tego to jest ręczna orka klatka po klatce i na bitmapie i na mapie artybutów - można próbować wyłapać to algorytmem oceniającym czy sądziadujące 8x8 są w odwrotnym ustawieniu bitmapy - ale to chyba nie obejmuje wszystkich kombinacji tego co dzieje się z obrazem i dalej będą jakieś problemy.
Jedyna szansa to konwerter 1:1 z raw'a bitmapy typu pbm na scr z pominięciem nagłówka pbm (bodajże 11 bajtów).
-
ZX Freeq, na filmiku z Timmim masz esxDOS 0.8.5, na 0.8.6 z Omni też działa.
-
... można próbować wyłapać to algorytmem oceniającym czy sądziadujące 8x8 są w odwrotnym ustawieniu bitmapy - ale to chyba nie obejmuje wszystkich kombinacji tego co dzieje się z obrazem i dalej będą jakieś problemy.
Chyba skuteczniej sprawdzać sąsiadujące atrybuty i ewentualnie odwracać pixele w całym 8x8.
-
Smoku a jak to się nazywa w XNView?
Bo widzę że potrafi konwertować do ponad 50 formatów, ale żaden z nich nie kojarzy mi się Spectrumowo.
-
Chyba skuteczniej sprawdzać sąsiadujące atrybuty i ewentualnie odwracać pixele w całym 8x8.
Chyba najprościej jest zrobić "poprawiacz" atrybutów. Robimy tablicę [0..255] w pamięci, z zawartością 0 lub 1, zależnie od tego, czy korespondujący bajt atrybutów wymaga zrobienia inwersji na pikselach, czy nie. Oceny dokonujemy na oko, ale tylko raz (można też automatycznie załatwić przypadki, gdy INK lub PAPER jest biały lub czarny, a resztę na oko, najlepiej na monitorze monochromatycznym).
Potem LOAD, pętla od 0 do 767, SAVE. I na wyjściu mamy obrazek, który może bezpiecznie "zgubić" atrybuty.
Kilka linii w basicu...
-
Offtop się zrobił, ale to oznacza że doceniacie prace nad grą, tak mniemam.
Konwerter dla toolauda napisałem w pół godziny, zatem ten temat jest zamknięty ;)
-
Dobra, kończąc offtop:
@ZbyniuR
https://www.xnview.com/en/xnview/#formats
Formaty o których mowa:
ZX Spectrum Snapshot.....................sna
ZX Spectrum standard screen..........scr
(EDIT: Dodałem info, że odpowiedź była do Zbynia)
-
ale co ma .sna do obrazu ZXa?
-
Konwerter dla toolauda napisałem w pół godziny ...
Jednak Maestro!
-
Pięknie to chodzi - mam wrażenie, że jest płynniej, ale to być może efekt lepszej konwersji gfx, niepogubionych klatek, lepiej kontrolowalnego ditheringu i wreszcie - konwersji 1:1 stworzonej bitmapy każdej klatki.
To siadam ogarnąć pozostałe rzeczy z mojej listy i podejrzewam, że na dniach będziemy mogli pokazać wersję po poprawkach.
-
Klaud, to prosty program był, pół godzinki to akurat.
Tooloud generuje poprawioną grafikę, pewnie jeszcze jakieś poprawki będą i będzie można pokazać 'odbugowaną' wersję z niedzieli ;-)
-
Sprawdziłem, może się kiedyś komuś przyda: XnView oraz XnConvert oraz ImageMagick potrafią jedynie odczytać format ZX Spectrum .scr. Nie potrafią zapisywać w tym formacie. EOT.