c64scene.pl

Witam.
Na fb można znaleźć portal poświęcony grafice C64
https://www.facebook.com/c64graphics/?h ... KYahHFVBeM

Jak dotąd chyba największy zbiór prac zgromadzony w jednym miejscu. Nie aktualizowana od dwóch miesięcy a autor nie daje znaku życia, ale mam nadzieję że jeszcze coś się ruszy. Trochę prac i artystów brakuje...
Jak ktoś woli z dysku, to paczka dostępna:
https://drive.google.com/open?id=1AK1Fd ... Xf9-3ruFEt

robienie takich kolekcji na FB to trochę słaby pomysł. głównie ze względu na możliwości "Browsowania" takiej kolekcji.
tutaj
http://artcity.bitfellas.org

i tutaj
http://c64pixels.com/main.php

panowie robili to lepiej, ale także chyba już odpuścili... szkoda, ale nadal, jak dla mnie, jak czegoś szukam to idę na artcity, c64pixels i csdb raczej niż na FB

Dzięki za linka do 'artcity'. Ponad 6000 prac! W sumie więcej niż reszta platform do kupy.
Pod względem grafiki, chyba portal ostateczny...

Jeszcze coś takiego było -

http://archive.is/GyGKI

@rebok, dzięki za paczkę! Od kilku lat chodzi mi po głowie zrobienie galerii WSZYSTKICH obrazków z compo/dem.
Jeśli tylko wpadnę na jakiś sensowny sposób jak takie przedsięwzięcie ogarnąć logistycznie...
Oczywiście obowiązkowo wszystkie obrazki muszą być w bezstratnym formacie - jpg odpada.

@isildur, szukając grafik pierwszy zbiór zrobiłem wykorzystując zasoby CSDb. Jednak mogłem wykorzystać jedynie prace zamieszczone w plikach .prg. Dlatego ściągnełem ten zbiór grafik zamieszczony na fb.
Carrion rzucił mi wyzwanie linkiem do "bitfellas artcity". Ponad 6k prac i to bogato stagowanych. Być może pokuszę się na kolejną paczkę... a tam już chyba same .png

z punktu widzenia c64 to najsensowniej robili to Veto i Enthusi na c64pixels.com
ale wygląda to na masę roboty i stąd pewnie nie jest to już aktualizowane.
ciekawe czy dało by się jakoś łatwo zrobić automat, który by przeglądał CSDB pod kontem nowych grafik i wstawiał je na c64pixels.com.
zdaje się że Jailbird kiedyś takie coś zaczął robić, ale nie pamiętam adresu.

Największy problem byłby wtedy, gdy w kilkudyskowym demie np. Offence, trzeba by zgrywać ręcznie shoty w wielu miejscach, a multiscreenowe obrazki, które dodatkowo trzeba by montować w PS dodatkowo wydłużyłyby cały proces.
Ew. można by stworzyć grupę w stylu HVSC... Hmmm w sumie ciekawe czego jest więcej obrazków, czy SID'ów

Po głowie chodzi mi też baza fontów...

carrion pisze:z punktu widzenia c64 to najsensowniej robili to Veto i Enthusi na c64pixels.com
ale wygląda to na masę roboty i stąd pewnie nie jest to już aktualizowane.
ciekawe czy dało by się jakoś łatwo zrobić automat, który by przeglądał CSDB pod kontem nowych grafik i wstawiał je na c64pixels.com.
zdaje się że Jailbird kiedyś takie coś zaczął robić, ale nie pamiętam adresu.

No było wyżej. The Pixelling Cow. KAPUTT.

isildur pisze: Po głowie chodzi mi też baza fontów...

tutaj jednak molgo by się okazać, że większość fontow niewiele różni się od siebie.
a tych najbardziej rozpoznawalnych jest 10, no może 50 sztuk...

Konwerter automat odpalający VICE i robiący screeny to imo właściwa droga, do tego dedykowana ekipa zrzucająca obrazy z dem.
Wersja dla orłów: sieć neuronowa analizująca klatki z dema i wykrywająca czy mamy na ekranie statyczny obrazek czy nudny napis 'loading'.

Ogólnie temat grafik scenowych jest chyba trudny patrząc po ilości upadłych przedsięwzięć :/

@isildur a czemu nie isc po prostu tropem hvsc?
Tzn. uzywac formatu natywnego? Ew natywny + preview w png?
Do tego tyko ustalic standardy (np. wszystkie multiki w .koa) i ew ogarnac ze jak format jakis z czapy trickiwy to trzeba zrobic exe
A potem strukture folderow etc dokladnie ala hvsc.
Dodatkowo poniewaz formaty c64 nie maja miejsca na metadane trzeba wymyslec prosty format np w json i do kazdego pliku np yyy.koa powinien byc plik yyy.inf a w. Im ten json z autorem, rokiem, tytulem, nazwa formatu i co tam jeszcze.
Ustawiasz to jako strukture folderow, robisz repozytorium na githubie i pozwalasz ludziom konteybuowac via pull requesty.

Koncepcja i toole nie sa wyzwaniem. Raczej potem ogrom pracy ale moze jak sie to rozlozy na wiele osob to spoko.
Jak potrzebujesz wsparcia w tym co wyzej napisalem, pisz.

^^ Lata temu coś takiego zacząłem robić. Była strona z PNG, bylo archiwum z oryginalnymi formatami, były narzędzia do automatycznego wyciągania grafiki i konwersji, nie było tylko metadanych. Zapał się skończył.

Ps. Standardów metadanych jest od metra do tego.

@Nitro, @Brush, super, że z perspektywy codera nie wygląda to na aż tak bardzo skomplikowane zadanie. Problemem oczywiście jest czas.
Co do tagowania, to myślę, że robienie tego w json może nieco bardziej skomplikować całość. Byłbym za tym, żeby na końcu każdego pliku np. kla dopisywać metadane, podobnie jak np. w mp3. Trzeba by dodać na końcu pliku jakiś znacznik, że plik jest otagowany i w prostej formie:
1. autor/grupa
2. rok
3. z jakiej produkcji/compo
Myślę, że niewiele więcej potrzeba niż w prostych opisach muzyczek zazwyczaj pod $1020.
Jakiś czas temu na Samarowym czacie pojawiła się podobna idea, ale dotycząca tagowania .d64 - muszę Slajerka tu ściągnąć

Edit:
Dopisałem sobie 20 bajtów do kla i np. RecoilWin na dzień dobry ma problem z pokazaniem obrazka, ale myślę, że to kwestia skontaktowania się z autorem. (btw najlepsza przeglądarka większości 8-bit obrazków, polecam!)

Pozostaje jeszcze pytanie, czy baza miałaby zawierać wszystkie obrazki bez wyjątku, czy tylko takie z oceną powyżej 50/100?

Wg.mnie .koa .fli etc - ustandaryzowane formaty to błędna droga bo tego zwyczajnie u nas nie ma. Są exeki robiące różne rzeczy, jasne, większość wyświetla standardowe formaty jak multi czy hires ale ładuje dane w różne miejsca. Dalej dochodzą 'rodzynki' czyli rzeczy na borderach, podkolorowywanie różnorakimi metodami etc.
Finalnie mamy mega oryginały jak obrazki trzyekranowe które doczytują dane z dysku.
Dlatego wg. mnie formaty powinny być dwa - prg oraz d64, generalnie to co autor dał bez modyfikacji o ile to możliwe. Przykłady
a)Praca oddana na compo na dyskietce, wystawiona na csdb jako d64 - nie wyodrębniamy prg[o ile obrazek ładuje się jako pierwszy plik] bo być może zawiera ona ładny katalog z notką albo working stages.
b)Zbiorczy dysk z pracami z compo - tu rozdzialamy na pojedyncze prg ale dobrze by było mieć referencję do oryginalnego d64.
Wizja wypasu do którego można dojść: zrzut katalogu, wybieramy plik i odpala nam się VICE w przeglądarce - rzecz istniejąca od paru lat:
http://vice.janicek.co/c64/
Puryści mogą się popatrzyć na decruncher etc...

Finalnie format podglądu - zrzut ekranu po X sekundach z automatu[który przegląda CSDB, pobiera pliki i odpala VICE] w formacie PNG to pewnik, ale trzeba by ustalić szczegóły jak paleta oraz jak blendujemy obrazki interlace. To rzecz dla lubiących patrzeć na gołe piksele.

Obok tego powinniśmy mieć format 'raw' - zpaletyzowany zrzut całego ekranu z wartościami od 0 do 15 odpowiadającym kolorom w VIC-II. Nie trzeba wynajdywać koła na nowo, GIF się nada, dodatkowym plusem jest możliwość przechowywania kilku klatek w przypadku obrazów interlace.
Do czego nam on? Do wyświetlania obrazków przez emulator wszelakich artefaktów prawdziwego sprzętu[np color blending]:
http://www.colodore.com/
Wizja wypasu do którego można dojść: user strony ustawia sobie ustawienia pod siebie a następnie zamiast png wszystko wyświetlane jest przez colodore, nawet miniatury - mocy współczesne PC mają pod dostatkiem.

Finalnie struktura, znowu skomplikuje rzeczy ale od folderów i JSON'ów wolałbym relacyjną bazę danych co pozwoli zrobić zaawansowaną wyszukiwarkę oraz stronę.
Do prostych metadanych jak party rok autor etc dodałbym dowolną ilość tagów które userzy mogliby dodawać opisujących obraz np graffiti, black&white etc.

Okej, tak ja to widzę gdybym to ja podjął temat. Ale od razu mówię, że odpadam, przynajmniej w tym roku.

@Isildur modyfikowanie oryginalnego formatu ktory nie przewiduje metadanych to droga do problemow.
Albo trzeba wymyslec jakis metaformat (jak .sid) albo jednak lepiej oddzielny pliczek. Jesli chodzi o prostotr do dodawanie metadanych w pliku tekstowym jest o niebo wygodniejsze niz doklejanie ich binarnie do koali etc.


@nitro Pareto. 80% grafiki bedzie w standardowych formatach. Zapakowanie tego w .prg powoduje ze zadne automatyczne narzedzia do obrobki tego etc nie beda mialy zastosowania. Dodatkowo: masz racje ze baza lepsze do wyszukiwania etc ale zeby to dzialalo trzeba website, serwera i sie komplikuje zycie. Sukces hvsc pokazuje ze prostota wygrywa. Natomiast jak bedzie standard (albo metaformat albo plikow.inf) to napisac skrypt ktory to przeskanuje i wrzuci do bazt to trywiał.

OK
skoki się skończyły - mogę komentować

fajna dyskusja się wywiązała, ale ja bym zrobił mały krok w tył i zadał pytanie po co miało by to być robione?
Jak popatrzeć na HVSC to cel tej kolekcji można podzielić tak:
1. cel katalogu - poukładane alfabetycznie po autorach i łatwo (z wyjątkami) odnajdowane utwory/artyści które nas interesują
2. cel archiwizacyjny (historia muzyki SIDowej - niezależnie czy z dema/gry czy wydanej standalone np na compo)
3. cel łatwego odtwarzania na PC/Mac (dostępne playery)
4. cel łatwego odtwarzania na C64 gra to np SIDplay GRGa albo np U1541

jeśli HVGC milo by być analogią (a IMO powinno) to powinno realizować te cele.
tak więc:

ad 1) po prostu katalogi + proste metadane (autor, rok, copyright jak w SIDach, etc)
ad 2) trzeba niestety albo stety zacząć przegrzebywać wszystko, ale najpierw wyjaśniając co jest grafiką a co nie. (np czy całoekranowy obrazek w trybie znakowym jest czy nie?)
ad 3) PNG - nie bawl bym się w anim GIFy, Flashe i inne HTML5 aby np udawac interlace - c64pixels.com, a nawet pokazuje że prędzej czy później mija zapał i czas itp.
ad 4) tutaj takie moje słowo komentaża odnoście plików .prg (exe) a SIDów - mam wrażenie że niektóre SIDy (np kawłek LMana z Fantasmolytic) to po prostu ripy z pamięci odpowiednio dostosowane do formatu SIDPlaya. Nic nie stoi aby takie podejście zastosować z grafiką. Wtedy bez problemu całość uruchomi się na C64 - z otwartymi borderami, sprajtami, wieloekranowe, scrolowane, na znakach, na dziwnych trybach FLI, itp, itd...

@Brush, ok rozumiem, masz rację. Dopisywanie tagów do binarek rzeczywiście mogłoby być niewygodne.
Format podobny do .sid już lepiej, co od razu byłoby odpowiedzią na punkt 4 Carriona.
Żeby to było maksymalnie user friendly, mógłby to być po prostu zrzut .vsf, kosztem większego zajęcia dysku.

@Carrion,
@1 może, żeby zminimalizować bałagan w każdym folderze autora byłby jeden plik txt/inf/nfo z danymi do każdego obrazka i żeby bardziej to ułatwić każdy plik miałby w nazwie trzycyfrowy prefix (np. 001.).
@2 tu mogą być różne zdania, ale myślę, że cokolwiek na ekranie, co ma jakąś wartość hmmm powiedzmy artystyczną uznawane byłoby za obrazek.
@3 całkowicie się zgadzam, 8bit png i tyle. W przypadku interlace jedna klatka? Blending tylko skomplikuje i zniechęci.
@4 to co napisałem w odpowiedzi Brushowi, czyli imo VSF.

... Miał tu być długi post polemizujący z niektórymi postami ale generalnie jak pisałem na projekt się nie pisze więc to nie ma sensu wtłaczać mojej wizji na siłę.
A widzę następce c64pixels.com w którym główną innowacją byłaby jak największa automatyzacja dodawania grafik poprzez zaawansowany tool który osiągnąłby poziom dodawania z automatu 90% grafik. Ale i w innych sprawach jest pole do popisu używając współczesnego zaawansowania HTML5 / JS.
Jak widać po poście kmeg'a oraz thepixellingcow da się.
Po przyjeździe z X'a o ile prace byłyby wrzucone na CSDB w serwisie znaleźlibyśmy je wszystkie z opcją odpalenia slideshowu z opcjonalnie nałożonymi różnorakimi filtrami CRT.
Być może przed dostalibyśmy w przypadku bycia adminem prompt, że z 6tym entry jest problem i trzeba go manualnie dodać/sprawdzić.
Finalnie na dole strony znajdujemy guzik generujący ZIP'a z wszystkimi grafikami które oglądaliśmy w stylu HVSC aby można było je obejrzeć na realnym sprzęcie.

Wszystko generalnie cutting-edge, tak jak w demach.

Wy idziecie chyba raczej w stronę czegoś co jak najlepiej będzie przeglądać na C64 i tu zgoda, przyjmujemy odmienne priorytety - standaryzacja grafik do jednolitego formatu ma sens, do tego dedykowany viewer pozwalający to przeglądać, szybko przerzucać obrazki oraz wyświetlający metadane.

P.S carrion:Ostatnia wersja formatu SID to emulacja 3/4 C64.

Nitro pisze: P.S carrion:Ostatnia wersja formatu SID to emulacja 3/4 C64.

no więc właśnie... nie ma problemu aby tak było i z formatem "VIC".
bo cały Twój, skąd inąd fajny pomysł z automatyzacją weźmie w łeb gdy pojawią się sidebordery, double screeny, i inne nietypowe rzeczy których nie da się pokazać na 160(320)x200.
wracając do zagadnień które postawiłem wyżej, w tym momencie zaczynam mieć więcej pytań niż odpowiedzi. Bo na przykład: ekran ze smokiem w Dutch Breeze to będzie grafika czy nie? a jeśli tak, to jedno-ekranowo (który ekran?) czy wielo-ekranowa? (i gdzie wtedy umieścić smoka? - anim GIFy odpadają)
Tak wiem, teoretyzuję, ale HVGC (HVVC?) wydaje się być bardziej skomplikowane niż HVSC.