atarionline.pl Wielokolorowy hiRes - Forum Atarum

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

  • :
  • :

Vanilla 1.1.4 jest produktem Lussumo. Więcej informacji: Dokumentacja, Forum.

5. Gry / Games  »   Wielokolorowy hiRes

W dół

Od 1 do 26 z 26

  1.  
  1.  
    Nie będzie to chyba dużym zaskoczeniem kiedy powiem że tryb hiRes na małe Atari sprawia zawód. Szczególnie na tle innych 8-bitowych komputerków z tamtych czasów.

    Wszyscy chyba przyzwyczailiśmy się do gier w trybie hiRes, które albo było czarno-białe, albo kolorowo-białe.

    To co ostatnio staje się łatwe dzięki G2F i co już udało nam się dostrzec w kilku produkcjach (Jet Set Willy 2007, Knight Lore, Night Shade, itp.) daje nadzieję na zmiany.

    Czy udałoby się podkolorować stare gry hiRes na Atari, żeby wyglądały lepiej? Albo przeportować gry hiRes których do tej pory nie doczekaliśmy na A8?

    Nie chcę, żeby mój post zabrzmiał jak typowy "no to weźmy się i zróbcie", ale niestety nie mam na tyle dużej wiedzy żeby jakoś bardzo pomóc. Jakiś czas temu zabrałem się za dorabianie obrazków do gier, które wczytują się zanim wczytuje się gra właściwa. Tutaj dwa przykłady: StarQuake i Blinky's Scary School:




    Jose Pereira już od jakiegoś czasu zmaga się z tematem. Oto linki do tematów związanych ze StarQuake: ->link<- oraz Saboteur i serią Monty: ->link<-

    Musicie przyznać że wygląda to bajecznie:





    • 2: CommentAuthorwieczor
    • CommentTime10 Sep 2012
     
    No dobrze fajnie to wyglada (Jet Set Willy 2007 uzywa VBXE nota bene wiec to zupelnie inna bajka) ale jak jest z uzywalnoscia w samej grze? Bo pokolorowac statyczny obrazek to jedno (nawet lepiej, vide RastaConverter) a zrobic dynamiczny playfield to zupelnie inna sprawa. Rozmieszczenie sprite'ow i uklad DLI zalezy od specyficznej zawartosci danego screenu, w grze jednak trzeba podejsc systemowo chociazby dla swobody konstrukcji tegoz. Ok sprite'y mozna w calosci poswiecic na kolorowanie - malkontentom wspominajacym ze c64 ma lepsze i czegos nie da sie na atari przypominam ze inne kompy czesto nie maja sprite'ow w ogole i kultowe gry jak The Last Ninja na zx spectrum sa. No ale co dalej? Jak z grubsza pokolorowac hires to kazdy wie - moim zdaniem to lekko podejscie od du... od zlej strony. Musi powstac gra jej mechanizmy i do tego trzeba dobrac w miare mozliwosci odpowiedni sposob kolorowania.

    Skupianie sie na grafice w poczatkowej fazie jest efektowne ale konczy sie porazka, vide ten MK, po prostu albo cala para idzie w gwizdek, albo opracowany efekt nie przystaje do realiow gry. Dlatego chetnie bym poznal od kuchni Manic Minera bo wyglada na to ze tu sie udalo.
    • 3: CommentAuthorilmenit
    • CommentTime10 Sep 2012 zmieniony
     
    Czy udałoby się podkolorować stare gry hiRes na Atari, żeby wyglądały lepiej? Albo przeportować gry hiRes których do tej pory nie doczekaliśmy na A8?


    Tak.

    Czyli to jednak post typu "no to weźmy się i zróbcie" ;-)

    niestety nie mam na tyle dużej wiedzy żeby jakoś bardzo pomóc


    Do żadnego z projektów, które robiłem na Atari, nie miałem zaczynając wiedzy. Źródła wiedzy są jednak bardzo dobre i bez problemu można je znaleźć.
  4.  
    No dobra. Załóżmy że chciałbym podkolorować duszkami StarQuake'a. Można do tego podejść stopniowo, to znaczy:
    * zacząć od lepszego pokolorowania głównego bohatera (obecnie postać obsłużona jest na jednokolorowym sprajcie)
    * następnie pokolorować "przeszkadzajki"
    * być może zaatakować status bar
    To nie wymaga redesign'u całej gry. Wymagać będzie wpięcia się w kod w miejsce gdzie obliczane są współrzędne obiektów ruchomych i potem w procedurę rysującą. Ale najpierw trzeba dokonać de-asemblacji kodu.

    Tutaj jest pierwszy zaciach i pierwsze miejsce gdzie "nie wiem co dalej". :-) To tak żeby uzmysłowić wielkość problemu.
    • 5: CommentAuthorilmenit
    • CommentTime10 Sep 2012
     
    • 6: CommentAuthornosty
    • CommentTime10 Sep 2012 zmieniony
     
    @ilmenit, to ja mam pytanie zwiazane z tematem: czy mozna by lekko przerobic RastaConvertera tak, zeby wczytał kolorowy obrazek 320x200, RC by tego obrazka wogole nie ruszal (w sensie danych bitowych), a jedyne nad czym by pracowal to zmiany rejestrow kolorow i parametrow duszkow.
    Wynikiem pracy oprocz wynikowego obrazka, bylby "wsad" w postaci kodu, ktory moglbym wstawic do gry, a ktory wykonywalby mi te wszystkie zmiany kolorow podkolorowujac tryb hi-res.

    Tak wiem, ze:
    -nadawaloby to sie tylko do obrazkow statycznych,
    -zabieraloby caly czas procesora podczas rysowania obrazu,
    -wynikowy obrazek roznilby sie od wprowadzonego.

    Ale są to poswiecenia na ktore jestem gotów :)


    I prosba o podzielenie sie wiedzą: z tego co sie wyczytalem, RC nie wykonuje operacji w DLI kazdej linii ale wykonuje jeden wielki blok kodu od pierwszej linii do ostatniej, zwany "programem kernela". Dlaczego?
    Wydawaloby sie ze naturalne synchronizowanie sie z kazdą linia za pomocą DLI jest latwiejsze.
    Z drugiej srony probowalem kiedys multiplikowac duszki w poziomie w trybie graficznym, wywolując procedure zmiany pozycji w DLI kazdej linii, tak zeby ta zmiana wypadala w srodku linii i nie dzialalo to tak jak sie spodziewalem. Juz nie pamietam szczegolow, musialbym do tego wrocic, ale nie dzialalo.

    I jak RC radzi sobie z przerwami w pracy 6502 wywolywanymi przez Antic?
    • 7: CommentAuthorilmenit
    • CommentTime10 Sep 2012 zmieniony
     
    @ilmenit, to ja mam pytanie zwiazane z tematem: czy mozna by lekko przerobic RastaConvertera tak, zeby wczytał kolorowy obrazek 320x200, RC by tego obrazka wogole nie ruszal (w sensie danych bitowych), a jedyne nad czym by pracowal to zmiany rejestrow kolorow i parametrow duszkow.


    Można przerobić. Źródła są na GitHubie.

    I prosba o podzielenie sie wiedzą: z tego co sie wyczytalem, RC nie wykonuje operacji w DLI kazdej linii ale wykonuje jeden wielki blok kodu od pierwszej linii do ostatniej, zwany "programem kernela". Dlaczego?


    Wywołanie przerwania DLI zżera czas procesora, czyli można wykonać mniej zmian rejestrów na ekranie.

    Z drugiej srony probowalem kiedys multiplikowac duszki w poziomie w trybie graficznym, wywolując procedure zmiany pozycji w DLI kazdej linii, tak zeby ta zmiana wypadala w srodku linii i nie dzialalo to tak jak sie spodziewalem. Juz nie pamietam szczegolow, musialbym do tego wrocic, ale nie dzialalo.


    Trzeba to synchronizować co do cyklu procesora.
    W RC też wciąż nie zawsze działa. Atari zachowuje się dosyć nieoczekiwanie w sytuacji, gdy zmieniasz pozycję duszka np. na taką, że duszek w nowej pozycji zachodzi na poprzednią pozycję. W grach nie powinno to być widoczne, ale jest widoczne gdy staramy się emulować zachowanie Atari co do cyklu koloru.

    I jak RC radzi sobie z przerwami w pracy 6502 wywolywanymi przez Antic?


    Uwzględnia to, ile Antic zabiera czasu.
  8.  
    Ech, wydawało mi się że jakoś się prześlizgnę, ale wygląda na to, że trzeba będzie się jednak nauczyć asemblera 6502.
    • 9: CommentAuthorbob_er
    • CommentTime11 Sep 2012
     
    głowa do góry - wszystko jest dla ludzi... :)
    • 10:
       
      CommentAuthorRastan
    • CommentTime11 Sep 2012
     
    @xmgatz: oprócz asemblera ważna jest jeszcze mapa pamięci atari. jeśli tego nie znasz to przed Tobą bardzo długa i kręta droga.
  11.  
    @Rastan: Wcale nie taka długa, mapa pamięci to raptem 267 stron PDFa :)
    • 12: CommentAuthorbob_er
    • CommentTime12 Sep 2012
     
    to go pocieszyles :)
    a tak na powaznie - istotne sa rozdzialy o rejestrach sprzetowych, i ogolnie jakie obszary pamieci sa do uzycia. chyba, ze gra romu nie wylacza...
    • 13: CommentAuthornosty
    • CommentTime12 Sep 2012 zmieniony
     
    ja uwazam ze przy zerowej wiedzy o asemblerze i bebechach Atari lepiej sie zaczac uczyc piszac swoje proste programiki niz od reverse egineeringu wielkich skomplikowanych gier. W taki sposob mozna sie tylko zestresowac, wpasc w kompleksy i rzucic wszysto w diably :P

    Dopiero majac opanowane podstawy i dobrze sie czujac w temacie, probowac badac czy poprawiac czyjs kod.

    Ja jak ogladam zrodla produkcji na Atari to czuje sie mocno zagubiony, a to są opisane zrodla! o deasemblacji binarki nawet nie wspominam...

    Inna sprawa ze asm daje niesamowite poczucie kontroli czy wrecz "władzy" nad maszyną. Wiesz co i jak sie wykona co do bajtu i cyklu zegara! To bardzo przyjemne.
  14.  
    Nie jest tak źle. W asemblerach (różnych) pisałem już wcześniej. Wprawdzie to było ponad 15 lat temu (potem wiele lat Java, a teraz to już tylko mam długi palec do pokazywania), ale zasadniczo i pobieżnie to wiem w czym rzecz.

    To co zostaje do nauczenia to konstrukcja samego 6502 (rejestry, adresacja), mnemoniki i działanie rozkazów, oraz "flaki" komputera, czyli mapa pamięci właśnie.

    Problem to oczywiście brak czasu. Ostatnio spędziłem kilka wieczorów wpasowując SIO2SD w obudowę od XC12 i mam wyrzuty sumienia, że rodzina cierpi kosztem mojego hobby. Kwestia terapeutyczna ma w tej dyskusji małe znaczenie. :-)
  15.  

    xmgatz:

    Ostatnio spędziłem kilka wieczorów wpasowując SIO2SD w obudowę od XC12 i mam wyrzuty sumienia, że rodzina cierpi kosztem mojego hobby.
    Zatem czas najwyższy ograniczyć ilość snu na dobę i dłubać w Atari nocą :)
    • 16: CommentAuthorcobra_c64
    • CommentTime12 Sep 2012 zmieniony
     
    Fakt, na atarynce kolorowy hires to ogromny ból. Może uda wam się wam w końcu pokonać tę barierę. Byłoby fajnie spróbować popixelować w nowym hiresie;)

    Nie zapominajmy, że obrazki dwu czy czterokolorowe też mają swój klimat.
    • 17: CommentAuthornosty
    • CommentTime12 Sep 2012 zmieniony
     
    niestety, ze bez ingerencji lutownica w Atarke (zgin! przepadni!) pewnych barier sie nie przeskoczy. Myslalem o tym zeby na "Tomku" generowac dynamicznie program kernela, ktory zarzadzalby zmianami kolorow i ustawianiem duszkow, umozliwiajac animacje kolorowych obiektow w hi-res. Nikt chyba tego jeszcze nie zrobil.

    Wiem ze jest to mozliwe, ale co z tego, skoro nie przeskoczy sie takich barier, jak to ze obiekty nie moglyby zmieniac kolorow czesciej niz np co 12 cykli koloru (jesli dobrze licze), albo ze nie da sie precyzyjnie okreslic miejsca zmiany (co do cyklu koloru). Jeszcze Antic sie wcina...
    Takie rzeczy powoduja ze programista nie ma pelniej swobody w tworzeniu gry a efekt koncowy moze byc pelen artefaktow.
    • 18:
       
      CommentAuthormentos
    • CommentTime14 Sep 2012 zmieniony
     
    Sorry, że się wtrącam, ale jednak ciemna magia dla mnie to zagadnienie. Mam jednak pytanie na które prosiłbym Was o odpowiedź, ale bez gdybania co by gdyby i tak no wiecie, po "polsku"!. A mianowicie. Co sprawiało, że na Commodorka powstały gry w HiRes i to kolorowe, płynne i grywalne? W czym rzecz że na Atarynę nie? Czy w gorszym procesorze graficznym? Bo przecież CPU ten sam a nawet szybszy w Atari. A jednak C64 wypada nie tylko muzycznie, ale i o niebo lepiej także graficznie. Tak obiektywnie patrząc, i nie chodzi mi o niezrozumiałę dla mnie podniety demami, które akurat jak dla mnie obnażają kiepskie kolory C64. To mówiłem ja, Atarombek ;-), zakochany w mej (a właściwie mych) Atarynach i pięknych kolorkach H.E.R.O., ale także uwielbiających me Komody :D Zawsze im zazdrościłem tej fajniejszej grafiki.
    • 19: CommentAuthorxxl
    • CommentTime14 Sep 2012
     
    po pierwsze: c64 nie ma procesora graficznego. po drugie: c64 ma pamiec atrybutow.
    • 20: CommentAuthorBluki
    • CommentTime14 Sep 2012
     
    Atari 400/800 pojawiło się w 1979 roku i było rewelacją wówczas. C64 ponad dwa lata później. Przy projektowaniu C64 przeanalizowano dokładnie słabe i mocne strony Atari. Niemal trzy lata to znaczna różnica w postępie technologicznym i kosztach tej technologii.
    Atari, jako komputer domowy, z założenia miało być podłączane do TV. Kolorowa grafika w rozdzielczości 320x192, w dodatku w NTSC, bez monitora, nie miała wówczas (1979) sensu.
    Warto pamiętać, że C64 posiada specjalizowany układ dźwiękowy, właściwie procesor, Atari nie, a mimo to nie da się jednoznacznie uznać przewagi SID-a.

    ...ale i o niebo lepiej także graficznie.

    Nieprawda.
    Jednak nie będę rozwijał tego, bo już napisano na ten temat megabajty tekstów, również na Atarionline. Wystarczy, aby wyrobić sobie chociaż w miarę przyzwoitą opinię. Jeśli jednak ktoś uważa, że zupę grzybową robi się z truskawek, to jego sprawa.
  21.  
    OK, a gdzie można dowiedzieć się więcej o tej "pamięci atrybutów"?
    • 22: CommentAuthorxxl
    • CommentTime15 Sep 2012
     
    • 23:
       
      CommentAuthormentos
    • CommentTime15 Sep 2012
     
    xxl- prosiłem po polsku a ty po chińsku? Normalnie marketing inżyniera ;-). Ale Bluki na szczęście umie wyjaśnić po ludzku za co piknie dziękuję. Szkoda że w Atari XL który wychodził przecież rok po C64 nie poprawili grafiki względem C64 na tej samej zasadzie co w C64 względem 400/800. Pewnie za mało było czasu. Ale czemu tego wypuszczając XE nie zrobili? Za późno bo ST już wchodziło?
    • 24: CommentAuthorxxl
    • CommentTime15 Sep 2012 zmieniony
     
    > Szkoda że w Atari XL który wychodził przecież rok po C64 nie poprawili grafiki względem C64 na tej samej zasadzie co w C64 względem 400/800.

    roznica miedzy atari 400 (1979) a atari xl/xe jest taka jak roznica miedzy c64 i c64G (1989) zapytuje wiec dlaczego w c64G nie poprawili grafiki wzgledem amigi ktora wyszala cztery lata wczesniej w 1985 :D
    mentos musisz sie bardziej postarac. ;-)
    • 25: CommentAuthortebe
    • CommentTime15 Sep 2012
     
    i znowu trzeba to napisać, Mentos, Atari prowadziło inną politykę niż C64, im zależało na wstecznej kompatybilności, programy które napisano na Atari 400 działały na XE/XL co najwyżej mógł wyjść problem z OS-em jeśli jakiś program zamiast do wektorów odwoływał się bezpośrednio do procedur zawartych w OS-ie, albo zbyt małą ilością pamięci

    Atari zachowało pierwotną konstrukcję sprzętu, wszelkie zmiany dotyczyły ilości pamięci, dodatkowego kontrolera zarządzającą pamięcią (130xe), zmiany starszego układu na nowszy w sensie procesu produkcji czy opłacalności produkcji, doprowadzeniu układu do wersji finalnej CTIA -> GTIA, oraz designu obudowy która to była zależna od linii produktów

    C64 z kolei nie pieścił się z użytkownikami którzy zakupili jego sprzęt, nie miał oporów by nowa linia ich komputerów nie była wstecz kompatybilna, czyli jeśli ktoś zakupił sprzęt przed erą C64 na pewno nie mógł już uruchomić programów z C64, potem C+4 itp. były kolejnymi produktami które stanowiły oddzielne gałęzie

    nową linią produktów Atari która zerwała z XE/XL była dopiero seria ST, XEGS to nadal rodzinka XE/XL
    • 26: CommentAuthorbruno_j
    • CommentTime15 Sep 2012 zmieniony
     
    @tebe raczej politykę niewprowadzania zmian, za wyjątkiem tych które przynosiły obniżenie kosztów produkcji. A już szczytem głupoty było naciskanie na 16kb jako maksymalne zapotrzebowanie na pamięć (oczywiście w imię zachowania zgodności). GTIA nie zaliczałbym do udoskonaleń. Po prostu w pewnym momencie zaczęto montować chipa z pełną funkcjonalnością. Wsteczna kompatybilność nie wyklucza postępu.

Od 1 do 26 z 26

  1.