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:
      
     CommentAuthorlaoo
   • CommentTime14 Apr 2021

    
   Jak zobaczyłem ten obrazek TDC to przypomniała mi się pchełka jaką Roland napisał w latach 90-tych. Tu są same pociski.

   • GALACTIC.xex
2. • 2:
      
     CommentAuthorCyprian
   • CommentTime14 Apr 2021

    
   fajna 'zamieć śnieżna'
3. • 3: CommentAuthormono
   • CommentTime14 Apr 2021 zmieniony

    
   W kwestii tych 128 znaków, to co prawda nie wiem co Atari myślało i planowało, ale można wyciągnąć parę wniosków i trochę sobie pogdybać.
   Znaków w generatorze może być 128 (tryby ANTIC-a 2,3,4,5 czyli GR.0,12,13) lub 64 (tryby ANTIC 6,7 czyli GR.1,2). Ponieważ do opisania znaku trzeba wtedy odpowiednio 7 lub 6 bitów, to te zbywające 1 lub 2 bity w kodzie znaku W PAMIĘCI EKRANU można wykorzystać do opisania koloru (tryby kolorowe ANTIC 4,5,6,7) lub sposobu wyświetlania (ANTIC 2,3) jak inverse, tłumienie czy odwracanie w pionie (konfigurowane globalnie rejestrem CHACT).
   Zaleta jest taka, że ciągle operujemy na bajcie pobranym z pamięci ekranu i nie potrzebujemy DODATKOWO pobierać danych z pamięci kolorów jak ma to miejsce w C=.
   Realizowana w ten sposób jest mapa kolorów, choć bardzo uproszczona i pewnie konstruktorom o to chodziło, żeby nie trzeba było pobierać dodatkowych danych z pamięci.
   Co ciekawe w C= pamięć koloru jest osobnym chipem na płycie i jest adresowana jako obszar rejestrów I/O VIC-a, więc może on sobie w dowolnej chwili z niej pobierać co chce bez zabierania cykli na magistrali procesora. Podobnie robi to też VBXE.
   
   Edit: Pamięć kolorów w C= jest 4-bitowa i pozwala na wybór jednej z 8 lub 16 barw (zależnie od trybu), podczas gdy w Atari mamy 1 lub 2 bity (zależnie od trybu), czyli 2 lub 4 kolory do wyboru w obrębie pojedynczego znaku.
4. • 4:
      
     CommentAuthorshanti77
   • CommentTime14 Apr 2021

    
   @Cyprian ale jeśli weźmiemy pod uwagę jedynie obszar ramki w którym wyświetlany jest obraz to prędkość cpu będzie porównywalna.
5. • 5:
      
     CommentAuthorCyprian
   • CommentTime14 Apr 2021 zmieniony

    

   mono:

   Co ciekawe w C= pamięć koloru jest osobnym chipem na płycie i jest adresowana jako obszar rejestrów I/O VIC-a, więc może on sobie w dowolnej chwili z niej pobierać co chce bez zabierania cykli na magistrali procesora. Podobnie robi to też VBXE.

   
   ciekawostką jest to że jest to kostka dość drogiej pamięci SRAM,
   
   Swoją drogą to mogli to też rozwiązać jakoś lepiej, np wrzucić tam pamięć ekranu znakowego, dzięki czemu uniknęli by badlines.
   
   
   

   mono:

   Pamięć kolorów w C= jest 4-bitowa i pozwala na wybór jednej z 8 lub 16 barw (zależnie od trybu), podczas gdy w Atari mamy 1 lub 2 bity (zależnie od trybu), czyli 2 lub 4 kolory do wyboru w obrębie pojedynczego znaku.

   
   z tym że jest to tylko kolor tła
6. • 6: CommentAuthormono
   • CommentTime14 Apr 2021 zmieniony

    

   Cyprian:

   (...)np wrzucić tam pamięć ekranu znakowego, dzięki czemu uniknęli by badlines.

   Pamięć ekranu musiałaby być 8-bit a więc droższa.
   

   Cyprian:

   (...)z tym że jest to tylko kolor tła

   Identycznie jak w Atari - w trybach hires kolor tła, w trybie multicolor kolor pikseli %11.
7. • 7:
      
     CommentAuthorCyprian
   • CommentTime14 Apr 2021

    
   @shanti77
   @mono
   ok
   
   swoją drogą gdzieś czytałem że ten SRAM został dodany tylko dlatego że Tramiel miał w magazynie sporo niesprzedanych kości.
8. • 8: CommentAuthorbruno_j
   • CommentTime14 Apr 2021

    
   @Cyprian raz, że pewnie mieli zapas bo pakowali to do VIC-20, dwa że MOS klepał te pamięci w dowolnej ilości.
9. • 9: CommentAuthoritguyinaction
   • CommentTime14 Apr 2021

    
   @Cyprian, bardzo fajny test wydajności. Przejrzałem i powiem, że pokrywa się z moimi oczekiwaniami. Dodatkowo dużą zaletą jest napisanie w asemblerze, bo jak wiadomo z jakością i szybkością interpreterów różnie bywało. Czy kod tego testu jest gdzieś dostępny, bo nigdzie go nie widzę w wątkach?
10. • 10:
       
      CommentAuthorCyprian
    • CommentTime14 Apr 2021

     
    @itguyinaction
    jest tutaj:
    
    Plik zip: ->link<-
    
    Listing asma: ->link<-
11. • 11:
       
      CommentAuthorRastan
    • CommentTime14 Apr 2021

     
    Dobra robota Cyprian. Dzięki!
12. • 12:
       
      CommentAuthortdc
    • CommentTime14 Apr 2021

     

    Rastan:

    To jest nieprawda.
    Procesor Atari jest szybszy, ale nie dwa razy.

    
    Ok, nie dwa razy, to było świadome, że zaokrąglam bez wchodzenia w szczegóły. Ale na całe szczęście fajne testy przedstawił Cyprian;)
    
    Przyjmijmy, że faktyczna wydajność CPU w Atari to około 1,32-1,65 szybszy niż w C=64.
    
    

    Rastan:

    (w zależności od tego ile "zabiera" VIC - w opinii koderów commodorowskich max. 10%)

    
    Czyli należy pamiętać, że 10% na C= to odpowiednio 13,2% - 16,5% dla kodera Atarowskiego;)
    
    

    Rastan:

    Bez znaczenia jest to kto wynalazł duszki. Są one na Atari kiepskie.

    
    To Twoje zdanie.
    
    Ja powiem, że w zależności do czego. Przykładowo to co robi pchełka Rolanda, którą zaprezentował laoo - to raczej duszki Atari są bez porównania lepsze;))
    
    

    Rastan:

    Taaaa, na pewno wiesz co oni "chcieli". Zrobili 128 znaków w zestawie, po to, żeby 1 bit przeznaczyć na "miganie inwersem...". Eh... ;-)

    
    Czyli sugerujesz że zrobili, właśnie dlatego że tak bardzo, bardzo nie chcieli;))) Czyli w Atari pracowali masochiści, robiący to czego z pewnością nie chcą;)))
    
    

    Rastan:

    Czekam na nowy tryb graficzny ze "sprzętową" mapą kolorów. Mam nadzieję, że nie będzie to klops taki jak "nowy tryb graficzny" z 1920 kolorów. ;-)

    
    Oj jaki Ty się złośliwy zrobiłeś;))
    Powinieneś zrobić sobie odwyk od C= może humor powróci;)))
    
    
    

    Cyprian:

    Jakiś czas temu zrobiłem test no i w tym samym trybie Hires (320x200!) Atari ma 132,54% mocy C64

    
    O! Dzięki za test. Nie ma to jak rozmawiać o konkretach;)
    
    

    laoo:

    Jak zobaczyłem ten obrazek TDC to przypomniała mi się pchełka jaką Roland napisał w latach 90-tych. Tu są same pociski.

    
    Rewelacja!;) Strasznie mi się to podoba!;)
    
    Ale tam chyba są "tylko" 3 pociski?
    
    

    mono:

    Zaleta jest taka, że ciągle operujemy na bajcie pobranym z pamięci ekranu i nie potrzebujemy DODATKOWO pobierać danych z pamięci kolorów jak ma to miejsce w C=.

    
    Dokładnie tak to widzę.
    
    Ogólnie fajna analiza Mono - dzięki. Nigdy nie widziałem na żadnym forum takiej analizy, zwykle wszyscy piszą/mówią że na C= i ZX jest mapa kolorów a na Atari jej brakuje...
13. • 13:
       
      CommentAuthorRastan
    • CommentTime14 Apr 2021 zmieniony

     

    tdc:

    Ok, nie dwa razy, to było świadome, że zaokrąglam bez wchodzenia w szczegóły. Ale na całe szczęście fajne testy przedstawił Cyprian;)
    
    Przyjmijmy, że faktyczna wydajność CPU w Atari to około 1,32-1,65 szybszy niż w C=64.

    
    
    Cyprian wykazał, że Atari jest szybsze o ok. 30%, ale weź również na to poprawkę Shantiego. Trzeba by również zasięgnąć opinii koderów C-64 ile dokładnie "zabiera" Vic-2.
    
    Dwa razy szybszy to jednak za duże zaokrąglenie.
    Prze-fanbojowałeś. :-)
    
    Co do duszków, to niech każdy ma swoją opinię i tyle. Ja uważam, że duszki C-64 są o wiele potężniejsze niż te w Atari.
    
    

    tdc:

    Oj jaki Ty się złośliwy zrobiłeś;))
    Powinieneś zrobić sobie odwyk od C= może humor powróci;)))

    
    
    Już nie pamiętam kiedy włączałem Commodore. Teraz u mnie na stoliku stoi Atari ST i XE. :-)
    
    Co do jednego masz jednak rację. Atari ma mapę kolorów, wprawdzie mini, ale ma. Pomijam tutaj oczywiście to co odkrył ostatnio mono i za co należy mu się szacunek.
    
    Jest tekstowy tryb 5 kolorowy w którym piąty kolor można "regulować" za pomocą bitu inversji. Wiem, że nie jest to taka mapa jak na C-64 czy C-16 gdzie rezerwowany jest na nią obszar pamięci, ale jest.
    Symulację mapy można również uzyskać w inny sposób. Pokazaliśmy to w Monty on the Run, a obecnie pracujemy nad ulepszeniem tej techniki. Chodzi o wykorzystanie spritów i umiejętne ich nałożenie. Warstwy spritów w niektórych miejscach całkiem nieźle oddają mapę kolorów.
14. • 14: CommentAuthormono
    • CommentTime14 Apr 2021 zmieniony

     

    Rastan:

    Co do duszków, to niech każdy ma swoją opinię i tyle. Ja uważam, że duszki C-64 są o wiele potężniejsze niż te w Atari.

    
    Ja też tak uważam, a to ponieważ:
    
    1. Mogą być hiresowe - w Atari niewykonalne.
    2. Mogą być 3-kolorowe (multicolor) - w Atari są tylko jednokolorowe, chyba że użyje się nakładania sprajtów/priorytetu 0, no ale mamy wtedy zajęte 2 sprajty a nie 1.
    3. Pozycjonują się co do piksela hires (nieważne czy są hires czy multicolor) - w Atari niewykonalne.
    4. Znikają na ramce, chyba że się ją otworzy - w Atari trzeba ustawić szeroki ekran i maskować treścią obrazu o ile sprajt leży pod grafiką, bo jeśli nie to trzeba modyfikować treść sprajta o ile jest pojedynczej szerokości - jeśli nie, to niewykonalne.
    5. Mają rozmiar 24x21 (hires), lub 12x21 (multicolor) - w Atari tylko 8x256 lub 2x256.
    6. Mają rejestry do pozycji Y - w Atari trzeba przepisywać pamięć.
    7. Treść sprajta zmienia się wybierając nr klatki sprajta $00-$FF w obrębie 16KB banku VIC - w Atari trzeba przepisać pamięć, lub zmienić adres bazowy PMG lub bank pamięci rozszerzonej (czyli dla wszystkich sprajtów).
    8. Nie mają poczwórnej szerokości, a tylko pojedynczą i podwójną - w Atari są pojedyncza, podwójna i poczwórna.
    9. Wysokość sprajta może być podwójna - na Atari można ustalić tryb dwuliniowy, ale dla wszystkich sprajtów naraz.
    10. Priorytety sprajtów ustawia się osobno dla każdego - w Atari naraz dla wszystkich.
    
    Więc jakoś tak łatwiej się nimi operuje a w zasadzie bezproblemowo można osiągnąć to samo co na Atari.
    
    Edit: Jeszcze 10.
    
    Edit 2: Nie wiem, jak z kolizjami sprzętowymi :)
15. • 15:
       
      CommentAuthorRastan
    • CommentTime14 Apr 2021

     
    Dzięki mono, że to zebrałeś i wypunktowałeś.
16. • 16: CommentAuthormono
    • CommentTime14 Apr 2021 zmieniony

     

    Rastan:

    Pomijam tutaj oczywiście to co odkrył ostatnio mono i za co należy mu się szacunek.

    Dzięki, ale jeśli masz na myśli nakładanie sprajtów z priorytetem 0 i możliwość uzyskania 23 kolorów w linii to nie jest to moje odkrycie, bo MPG czyli MaPa i PG a także Jose Pereira stosują te tricki w grach od wielu lat. Ja to tylko zebrałem a i to cytując to co opisał Jose w wątku na AtariAge.
17. • 17: CommentAuthortebe
    • CommentTime14 Apr 2021

     
    "lepsza" mapa kolorów została zaprezentowana w demie Reharden, autorem jest Sandor Teli
    
    do dem powinna być dołączana instrukcja wyjaśniająca zajebistość kolejnych efektów, inaczej potrafią przejść bez echa aż ktoś ponownie je odkryje
18. • 18:
       
      CommentAuthordely
    • CommentTime14 Apr 2021

     
    Pozwolę sobie dopisać do listy kol. mono:
    
    11. Rejestry pozycji są R/W, czyli można sobie sobie zrobić INC/DEC POZYCJA żeby poruszyć duszkiem. Na Atari trzeba pozycję trzymać w pamięci, zwiększać ją lub zmniejszać i potem dopiero zapisać do rejestru (na dodatek tylko poziomego).
    12. Kolizje mogą wyzwalać IRQ.
19. • 19:
       
      CommentAuthorcrrn
    • CommentTime14 Apr 2021

     
    miałem zamiar odpowiedzieć TDCowi, ale już tutaj koledzy odpowiedzieli o sprajach C64 wystarczająco dużo.
    odniosę się tylko do jednej wypowiedzi TDCa odnośnie inwersji...
    inwersję na C64 nie robi się poprzez zmianę mapy kolorów. Znaki od 128 - wzwyż są w inwersji (zakładam że jak na Atari), ale na C64 po prostu jak nie chcesz ich w inwersji to zmieniasz na "normalne" - tzn edytujesz je jak chcesz. System nie nakazuje Ci aby to były znaki w inwersji. Ot taki wolny wybór dla programisty.
    
    Innego cytatu nie skomentuję. Wydrukuję go sobie chyba i powieszę nad biurkiem. Gdy najdzie mnie zły humor, to będę sobie czytał aby sobie go poprawić.
    
    Przytaczam:
    [,,]
    przesunięcie duszka na Atari to zmiana 1 bajtu a na C64 to 2 bajty - czyli przy tego typu trikach mamy dwa razy mniejsze możliwości. Dodatkowo CPU w Commodore jest dwa razy wolniejszy, więc razem na Atari w rozmnażaniu sprajtów można zrobić 4 krotnie więcej
    [..]
    
    Genialne! Dzięki TDC! popłakałem się jak to czytałem...
20. • 20: CommentAuthormono
    • CommentTime14 Apr 2021

     
    To ja jeszcze Tomkowi bym podpowiedział, że C64 ma 63 (PAL) lub 65 (NTSC) cykli CPU w linii a Atari ma 114 :)
21. • 21: CommentAuthortebe
    • CommentTime14 Apr 2021

     
    niewiedza buduje, wiedza rujnuje ;)
22. • 22: CommentAuthormono
    • CommentTime14 Apr 2021

     
    Ale mu tego nie podpowiem :)
    
    @tebe: Przecież ludzie w kółko powtarzają, że "nie wiedział że się nie da, przyszedł i zrobił", no to jak ma nie budować :)
23. • 23:
       
      CommentAuthorRastan
    • CommentTime14 Apr 2021 zmieniony

     

    mono:

    Dzięki, ale jeśli masz na myśli nakładanie sprajtów z priorytetem 0 i możliwość uzyskania 23 kolorów w linii to nie jest to moje odkrycie, bo MPG czyli MaPa i PG a także Jose Pereira stosują te tricki w grach od wielu lat. Ja to tylko zebrałem a i to cytując to co opisał Jose w wątku na AtariAge.

    
    
    Właśnie to miałem na myśli. :-)
    OK. Ale zebrałeś to i opisałeś więc dzięki Ci za to.
24. • 24: CommentAuthorZuluGula
    • CommentTime14 Apr 2021

     
    C64 moze kopac Bitcoin. Ciekawe jak szybko Atari mogłoby zrobić to samo? Mam kilkanascie komputerow Atari i moglbym je zaprząc do zarabiania na siebie.
25. • 25: CommentAuthoras...
    • CommentTime15 Apr 2021

     
    @ZuluGula,
    -kopanie, Synkowi zamówiłem rtx 3060ti msi (najcichszego pod "Choinkę";
    
    rtx 2060msi gaming z, sprzedałem na allegro w lutym i zarobiłem na tym (paranoja!).
    
    Nie gram w gry, oczywiście mam tam swój dysk z cp2077/wiedźmin, ale ostatnio już 2gi raz grałem w tym roku w cp2077 :P
26. • 26: CommentAuthormlc
    • CommentTime15 Apr 2021

     
    "To ja jeszcze Tomkowi bym podpowiedział, że C64 ma 63 (PAL) lub 65 (NTSC) cykli CPU w linii a Atari ma 114 :)"
    
    Nie wiem jak kogoś tu zacytować (?), ale rozumiem, że te cykle to jest ilość określająca ile cykli CPU zabiera narysowanie jednej linii ekranu? Czyli na C64 jest lepiej, bo narysowanie linii zabiera mniej cykli?
27. • 27: CommentAuthormono
    • CommentTime15 Apr 2021

     
    Ale linia trwa 64 us :)
28. • 28: CommentAuthoradi
    • CommentTime15 Apr 2021

     
    Dyskusja na temat wyższości Atari nad C64 czy vice versa ma charakter czysto akademicki.
    Obie platformy mają dziś wartość tylko muzealną.
    Prawdziwą wartością są kody gier stworzonych na te platformy przez prawie cztery dziesiątki lat.
    Umyślnie piszę o grach, bo użytki mają też wartość tylko muzealną.
    Na czym te kody są uruchamiane to rzecz obojętna.
    Dziś najtańszą i najlepszą platformą do tego jest PC z systemem Linux.
    Przy okazji można na nim korzystać z innych wspaniałych gier: Amiga i NES.
29. • 29: CommentAuthorJosé Pereira
    • CommentTime15 Apr 2021

     
    Other than images (like loading screens) only one released game is using Prior_0: ->link<- with MatoSimi.
    The in-game is build like this:
    -> backgrounds gfxs are always 2colours per line (then DLIs across the screen) and using BAK and PF3;
    -> PF0 and PF1 are middle light gray and white but not seen (will explain next...);
    -> PF2 is on hi-res and the sides vertical lines (here also not seen...);
    
    Because BAK changes down across the screen to have all screen high the same sides borders colours we did:
    -> left and right <- PM2 and PM3 (blue PMGs colour then Oring PF2 light gray gets the vertical light blue lines);
    
    Each floor type is in [2x2]chars each window so PM1 and PM2 quadruple width gets any colour from the 0->15 A8 hues then Orings to get the other 2colours:
    -> PM0/PM1 any colour in luminance0;
    -> PM0/PM1 Oring PF0: that above but gives the middle luminance;
    -> PM0/PM1 Oring PF1: that above but gives the light luminance;
    
    :thumbsup:
30. • 30: CommentAuthorJosé Pereira
    • CommentTime15 Apr 2021 zmieniony

     
    In hi-res is also possible to use Prior_0 (perhaps most people don't know...) but only difference is on PM2_2 and PMG_3 that will Oring luminance on PF2.
    PMG_0 and PMG_1 will not do anything different than if using Prior_1 (of course they allways take PF1 luminance whatever this is and not Oring it)
    If this would happen also be a strange thing because then PMG_2 and PMG_3 would be under PF2 as are on 2:1 ratio graphics/characters modes.
    From left to right PMG_0 -> 3 and on top shows Prior_0 and bottom Prior_1:

    • Prior_0 in hires.png
      
      
      
      
    • Prior_0 in hires.g2f
    • Prior_0 in hires.xex
31. • 31:
       
      CommentAuthortdc
    • CommentTime15 Apr 2021 zmieniony

     

    Rastan:

    Dwa razy szybszy to jednak za duże zaokrąglenie.

    
    Zasugerowałem się ilością MHZ;) Nie no żartuję, mówię że zrobiłem to umyślnie, znam Was i wiem że warto bo potem fajne i ciekawe rzeczy piszecie, a programy jakie tu zamieściliście to bardzo, bardzo fajne;)
    
    

    Rastan:

    Prze-fanbojowałeś. :-)

    
    Eee tam;) Ja sobie żartuję, ale co ciekawe zupełnie poważnie w świecie pecetów (w tamtym okresie i dziś) bardzo często mówiono że ilość MHz w CPU Intela to oznacza ogromną prędkość, całe firmy amerykańskie wciskały różnego rodzaju kity, publikowały testy wydajności w których udowadniali, że dany CPU jest dwa czy n razy szybszy od konkurencji, za pomocą testów tak dobranych aby procesor faktycznie był bardzo szybki, jednak w praktyce takiego kodu nie da się napisać w prawdziwym programie, który coś konkretnego robi.
    
    I co?
    I jakoś nikt nigdy nie wyzywał ich od prze-fanbojowanych - dlaczego???
    Oni kłamali w żywe oczy i zarabiali na tym grubą kasę - i co, jakoś nikt ich nie wyzywał.
    
    A ja na tym nie zarabiam tylko robię sobie żarty na forum.
    
    

    Rastan:

    Co do duszków, to niech każdy ma swoją opinię i tyle. Ja uważam, że duszki C-64 są o wiele potężniejsze niż te w Atari.

    
    Ja się z tym całkowicie zgadzam, duszki w niektórych funkcjach są bardzo praktyczne i fajne. Jednak zawsze podkreślam, że jest to okupione poważnymi kosztami, w tym np. ułomną ilością kolorów całego systemu graficznego, problemami wydajnościowymi, które nie istnieją na żadnym znanym mi komputerze, w tym na Atari.
    
    

    Rastan:

    Już nie pamiętam kiedy włączałem Commodore. Teraz u mnie na stoliku stoi Atari ST i XE. :-)

    
    Aaa...czyli to wina Atari - oook;)))))))))
    
    

    Rastan:

    Co do jednego masz jednak rację. Atari ma mapę kolorów, wprawdzie mini, ale ma.

    
    Tak, problem w tym, że możliwości Atari są tak ogromne, że mało kto prześledził je w całości (nawet z książki Atari BASIC! o zgrozo) więc nie jest tak łatwo powiedzieć, że Atari czegoś nie ma. Mapę kolorów ma zrealizowaną na więcej sposobów.
    
    Zakładam, że to właśnie propaganda ludzi od ZX i C=, wmówiła wielu osobom, że Atari jej nie posiada, że to ich domena.
    
    

    Rastan:

    Chodzi o wykorzystanie spritów i umiejętne ich nałożenie. Warstwy spritów w niektórych miejscach całkiem nieźle oddają mapę kolorów.

    
    Z całą pewnością, takie rzeczy robi się na Atari od dawien dawna;)
    
    Przypominam moje skromne demko z początku lat 90., gdzie sobie niezłe żarty z tego robiłem. Nie mogę teraz znaleźć tego pliku... ale był zaprezentowany jako wykopalisko na jakiś dawnych Głuchołazach na compo... gdzieś powinien być...
    
    
    

    Mono:

    Ja też tak uważam, a to ponieważ:

    
    No to dałeś - ale fajnie że opisałeś to wszystko chętnie się do tego ustosunkuję.
    
    Jednak co do lepszości należy pamiętać, że Atari było pierwsze a C=64 był kilka lat później, więc "lepszość" jest bezdyskusyjna, Commodore miało już doświadczenie (również od Atari) i zupełnie inną wiedzę o grach dostępnych na rynku więc wiedzieli w jakim kierunku warto iść. Choć przeczy temu bardzo skromna paleta kolorów... i duszków i wszystkiego...
    
    Więc to że "są o wiele potężniejsze niż te w Atari" - w mojej ocenie nie jest niczym co powinno nas dziwić, raczej w przeciwnym wypadku powinniśmy być zdziwieni, tak jak co do ilości kolorów w palecie i możliwej do wyświetlenia i na duszkach i na grafice.
    
    

    Mono:

    1. Mogą być hiresowe - w Atari niewykonalne.

    
    Wolne żarty, a widziałeś stareńkie demo The Top #3?;)
    ->link<-
    
    Na Atari coś jest niemożliwe?;) Wolne żarty!;)
    

    Mono:

    2. Mogą być 3-kolorowe (multicolor) - w Atari są tylko jednokolorowe, chyba że użyje się nakładania sprajtów/priorytetu 0, no ale mamy wtedy zajęte 2 sprajty a nie 1.

    
    Nie widzę w tym problemu, tym bardziej że jak wspomniałeś jest sporo możliwości osiągnięcia kolorowych spritesów.
    
    Należy zaznaczyć, że właśnie te opcje do wielokolorowych duszków na Atari są całkowicie NIESAMOWITE jak na jedyny omawiany tu komputer z lat 70. W tamtych czasach firmy Apple i Commodore np. PET pracowały nad najprostszym wyświetlaniem tekstu. O duszkach i kolorach nie było mowy.
    
    Podobnie było w grach arcade, na tym tle nie można mówić że duszki na Atari to jedynie PONG - to byłby PONG gdyby nie było możliwości łączenia kolorów duszków, a właściwie byłoby to naturalne w tamtych czasach.
    Tymczasem na Atari mamy przytłaczającą ilość możliwości kolorowania duszków w stosunku do dowolnego komputera nawet z lat 80. (Amiga ma tryb łączenia kolorów duszków i grafiki?) czy konsoli do gier.
    (z moich obserwacji dla uproszczenia prac inżynieryjnych Atari często bazowało na prostych rozwiązaniach np. POKEY, którego podstawowe możliwości pozwalają np. 8-bitowe sterowanie częstotliwością, które nie wystarcza, ale właśnie oni wychodzili z założenia, że wszystkie takie obiekty możemy zwielokrotnić i już jest ok. czyli kilka duszków, kilka POKEYów itp. tak to widzę, i jest to w mojej ocenie rozsądne podejście, szczególnie w pionierskich czasach, którymi były lata 70.).
    
    Dzięki temu, że twórcy Atari zadbali o tryby działania duszków wykraczające poza wszelkie możliwe osiągane w latach 70. przez dowolne sprzęty - dziś możemy mieć kolorowe gry, w tym wszystkie te z lat 80. i 90. gdzie duszki są bardzo kolorowe.
    
    Proszę, powieszajcie trochę psów na duszkach z C=64, że na Atari duszki mogą być w dowolnym z 128 kolorów a na C=64 nie mogą być nawet w 20 kolorach... Dlaczego nikt o tym nie mówi? Dlaczego milczycie o tym?
    Pomyślcie musi być jakaś równowaga, Atari ma słabe duszki, to porozmawiajmy o słabości duszków w C=64, mają swoje konkretne wady.
    
    Przypominam, że to stronka o Atari;)))
    

    Mono:

    2. Mogą być 3-kolorowe (multicolor) - w Atari są tylko jednokolorowe

    
    To warte podkreślenia, więc podkreślam:
    
    W takich rozważaniach nie można zapominać o fenomenalnym mechanizmie dostępnym tylko w Atari i Amidze czyli DLI. Więc w zamyśle duszki na Atari nigdy nie miały być jednokolorowe - można tak powiedzieć o każdym komputerze który nie ma DLI. Ale w Atari DLI powoduje, że właśnie w założeniu każdy duszek nawet jeśli jest jeden na ekranie to właśnie miał mieć tyle kolorów ile chcemy z bardzo bogatej palety.
    

    Mono:

    3. Pozycjonują się co do piksela hires (nieważne czy są hires czy multicolor) - w Atari niewykonalne.

    
    Jak już wspominałem to są wady. Po pierwsze trzeba ustawiać 2 bajty a nie 1 jak w Atari. Oba komputery prześcigają się w operacjach wykonywanych podczas procesu rysowania obrazu (to nie ZX Spectrum czy Pecet), więc różnica zapisania 2 bajtów a 1 to istotna różnica.
    Z resztą program GALACTIC.xex Rolanda - pokazuje to z całą krasą.
    
    Ok, to bierzcie popcorn;)) Zaczyna się:
    
    Podobnie jak z mapą kolorów ciągle słyszę, że na C=64 duszki działają jakby w wysokiej rozdzielczości, tymczasem na Atari nie ((nie ale mają inne zalety i przewagi)).
    
    Wyjaśnijmy sobie dobitnie: animowanie grafiki i obiektów co 1 piksel wysokiej rozdzielczości - jest kompletnie niepraktyczne
    ...nieprzydatne, bezsensowne.
    
    Mono, wyobraź sobie że kodujemy tę grę na C=64:
    ->link<-
    tak aby każda z animacji była co 1 piksel wysokiej rozdzielczości...
    
    Zapewniam Was, że efekt byłby druzgoczący. Gra kompletnie niegrywalna...
    
    To jest niepraktyczne i już.
    
    ...natomiast uprzedzając miłośników technologii C= jeśli na Atari chcemy aby jakaś animacja była co 1 piksel, to spokojnie można sobie z tym poradzić, mimo że faktycznie sprzęt (na całe szczęście byli w Atari praktyczni i sensowni ludzie) tego nie wspiera. Przykład "Revenge of Magnus" z 1989 roku - fajny przykład, bardzo go lubię;)
    ->link<-
    
    

    Mono:

    4. Znikają na ramce, chyba że się ją otworzy - w Atari trzeba ustawić szeroki ekran i maskować treścią obrazu o ile sprajt leży pod grafiką, bo jeśli nie to trzeba modyfikować treść sprajta o ile jest pojedynczej szerokości - jeśli nie, to niewykonalne.

    
    Zawsze patrzyłem na to jak na wadę, odkąd pamiętam, nie mogłem uwierzyć w to że na C=64 duszki nie mogą wychodzić po za ramkę, a koderzy lat 80/90 robili triki aby to stawało się możliwe...
    
    Po prostu tam gdzie mnie ktoś ogranicza i to tak ograniczoną ramką jak w C64 to bardzo nie podoba mi się to. Natomiast duszki które mogą być daleko poza widoczną częścią obrazu w Atari doskonale wpisują się w moje pojęcie wolności, które jest dla mnie fundamentem.
    
    Ogólnie co do Atari właśnie tak rozumiem wolność i Atari jako jedyny komputer spełnia to moje widzenie tego jak się programuje komputery.
    

    Mono:

    5. Mają rozmiar 24x21 (hires), lub 12x21 (multicolor) - w Atari tylko 8x256 lub 2x256.

    
    Tylko?? 21 linii i 256 linii to jest "tylko"???
    
    To bardzo stronnicze.
    
    Jak podkreślałem na warsztatach z Action! Atari jest tak pomyślane że wszystko musi się zgadzać w linii, więc nie ma innej możliwości jak duszki na całą długość obrazu (tak samo jak obraz nie ma przerw tylko istnieje na całej długości - to logiczne, głównie na Atari), bo wtedy np. sens istnienia DLI byłby niespójny z resztą sprzętu.
    (w commodore też wszystko jest pomyślane w oparciu o linie rastra, tyle że twórcy tego komputera nie wiedzieli o tym, lub niewystarczająco precyzyjnie zapoznali się z tym jak to jest przemyślane w Atari - że w Atari to ma sens i nie należy tego ruszać, chcieli to zepsuć i narobili sobie kłopotów nie znanych wcześniej w informatyce...)
    

    Mono:

    6. Mają rejestry do pozycji Y - w Atari trzeba przepisywać pamięć.

    
    Tu mógłbym strzelić dwa razy taki wykład jak cały ten post, więc ograniczę się tylko do tego co wcześniej podałem, że w grze Virus Invaders 2020 jest masa animowanych duszków co ramkę i to nie w asemblerze, więc nie widzę żadnego problemu - bo sugerować by to mogło że to generuje problemy, a jak widać w grach - nie generuje najmniejszych problemów w animowaniu dziesiątków interaktywnych obiektów w grach (w Action! można się pokusić o setki interaktywnych obiektów).
    
    Resztę rozważań, pozostawiam na nasze jakże fascynujące nocne rozprawki;)))
    

    Mono:

    7. Treść sprajta zmienia się wybierając nr klatki sprajta $00-$FF w obrębie 16KB banku VIC - w Atari trzeba przepisać pamięć, lub zmienić adres bazowy PMG lub bank pamięci rozszerzonej (czyli dla wszystkich sprajtów).

    
    Tak, to jest fajowe i nie tylko ze względu na wydajność, bo jest to realizowane sprzętowo, bardzo praktyczne w typowych grach z lat 80., ale dlatego że generuje to wiele bardzo ciekawych możliwości, które nie wynikają tak w prosty sposób z samej idei tych duszków (czyli np. atarowskie myślenie o budowie obrazu składającego się linii rastra, które podobnie ma miejsce u podstaw zaprojektowania C=64).
    Naprawdę mi się to podoba i ma sens praktyczny.
    
    Choć dobrze też, że wspomniałeś że są też commodore'owe wady tego rozwiązania - wady nieznane na Atari.
    
    Kiedyś rozmawiałem z Pavrosem, jak można w prosty sposób zrobić szczątkową taką funkcjonalność w Atari i udało się nam to wymyślić bardzo fajnie. Ale nie mogę o tym mówić bo wiąże się to z nieujawnionym jeszcze przez niego projektem.
    

    Mono:

    8. Nie mają poczwórnej szerokości, a tylko pojedynczą i podwójną - w Atari są pojedyncza, podwójna i poczwórna.

    
    To jakoś mnie szczególnie nie fascynuje, choć ze względu na to jak to zostało zaprojektowane na Atari, to ten brak bardzo by wiele rzeczy utrudniał, w tym np. te o których wspominał Rastan.
    

    Mono:

    10. Priorytety sprajtów ustawia się osobno dla każdego - w Atari naraz dla wszystkich.

    
    Taka drobna uwaga, jak należy rozumieć to co napisał Mono, że co prawda jest jeden rejestr za to odpowiedzialny, ale nie należy tego rozumieć tak, że nie da się duszkom lub grupom duszków nadawać różnych priorytetów - da się w ograniczonym zakresie w stosunku do tego gdy można takie nadawać każdemu duszkowi oddzielnie, ale jednak da się ustalać różne priorytety, różnym duszkom i prezentowałem to na przykładach z wyjaśnieniem na warsztacie z Action!
    
    

    Mono:

    Więc jakoś tak łatwiej się nimi operuje a w zasadzie bezproblemowo można osiągnąć to samo co na Atari.

    
    W szczególności dziesiątki kolorów;) jak to widzimy tutaj:
    ->link<-
    

    tebe:

    "lepsza" mapa kolorów została zaprezentowana w demie Reharden, autorem jest Sandor Teli
    
    do dem powinna być dołączana instrukcja wyjaśniająca zajebistość kolejnych efektów, inaczej potrafią przejść bez echa aż ktoś ponownie je odkryje

    
    Oj... racja, racja;)
    
    

    
    

    crrn:

    inwersję na C64 nie robi się poprzez zmianę mapy kolorów.

    
    Ale ja to pisałem nie o C64 ale o wszelkich komputerach i kompilatorach z epoki - że sobie tego nie wyobrażam i poza Action! nie spotkałem się z tym. Wszystkie języki programowania wtedy robiono sztampowo, na jedno kopyto, bez względu czy to ZX czy pecet czy Apple czy PDP.
    

    crrn:

    Genialne! Dzięki TDC! popłakałem się jak to czytałem...

    
    Jakoś niepotrzebnie się wyzłośliwiasz...
    Żartuję sobie, intryguję Was, ale dzięki temu ruszają się Wasze szare komórki i rozmowa staje się coraz ciekawsza, a przykłady programów jakie się tu pojawiają są też godne uwagi.
    Wyluzuj... tu świat Atari;)
    
    

    Mono:

    To ja jeszcze Tomkowi bym podpowiedział, że C64 ma 63 (PAL) lub 65 (NTSC) cykli CPU w linii a Atari ma 114 :)

    
    crrn - widzisz? Warto w takim towarzystwie pogadać;)
    
    Ja przynajmniej cenię konkrety;)
    
    

    ZuluGula:

    C64 moze kopac Bitcoin. Ciekawe jak szybko Atari mogłoby zrobić to samo? Mam kilkanascie komputerow Atari i moglbym je zaprząc do zarabiania na siebie.

    
    Na C=64 można obliczenia przenieść na CPU w stacji dysków;)))
    A w Atari pewnie da się coś wymyślić aby zajął się tym procesor ANTIC jako wsparcie;)))
    
    

    adi:

    Dyskusja na temat wyższości Atari nad C64 czy vice versa ma charakter czysto akademicki.

    
    Ooo.. nie, nie, nie i jeszcze raz nie;)
    
    Po pierwsze nie gadamy tu o wyższości lanego poniedziałku nad prima aprilisem.
    
    Po drugie tu piszą ludzie, którzy naprawdę kodują na Atari czy na C=.
    Co innego rozmowa praktyków, programistów a co innego przepychanki, co jest lepsze w czysto teoretycznych sporach.
    
    Wartość tej rozmowy i że nie jest czysto teoretyczna pokazują wszystkie linki do filmików i zamieszczone programy jakie wszyscy uczestnicy tu podali. Zapamiętaj, że program to konkret, wiąże się z nim cała inżynieryjna czy nawet hackerska wiedza, doświadczenie, tricki itp. Gdyby to był czysto teoretyczny problem, to nikt by nic nie zamieścił bo nie byłoby co... można by jedynie pogadać po próżnicy...
    
    Poza tym takie rozmowy wśród twórców, są bardzo ważne bo nasze mózgi działają i często to prowadzi do nowych programów, gier itp.
    
    Przykładowo mój mózg został rozgrzany twórczo przez Rolanda i choćby dziś coś bym takiego zakodował na Atari, bo naprawdę możliwości masa - można stworzyć coś kompletnie odmiennego od wszystkiego co widzieliśmy na Atari do tej pory!
    ...szkoda, że nie mam teraz czasu, zaraz siadam i zajmuję się obowiązkami...
    ...ale pewnego dnia... kto wie!
    

    adi:

    Dziś najtańszą i najlepszą platformą do tego jest PC z systemem Linux.
    

    
    To takie proste nie jest, bo używam Linuxa od lat 90. używam na nich emulatorów i działały one od dawna około dwa razy wolniej... Trudno mi to pisać bo jestem wielkim miłośnikiem linuxa, no ale takie są fakty...
    Nawet kiedyś przyznałem to publicznie na konferencji dotyczącej tych systemów i jakoś nikt na sali nie protestował:P a uczestnicy byli bardzo aktywni w zadawaniu pytań itp.
    

    José Pereira:

    In hi-res is also possible to use Prior_0 (perhaps most people don't know...)

    
    Oh! Thanks!;)
32. • 32:
       
      CommentAuthortdc
    • CommentTime15 Apr 2021

     
    O! Znalazłem to demko pt. "ANTIC"
    ->link<-
    
    Ha! Dzięki chłopaki (i dziewcznyny?) z demozoo!
    Nawet ja tego programu nie mogłem u siebie nigdzie znaleźć...:P
33. • 33: CommentAuthoradi
    • CommentTime16 Apr 2021 zmieniony

     
    Najpiękniejszy post, jaki w życiu widziałem :).
    Mówię zupełnie serio. Spokojnie nadaje się na artykuł na pierwszą stronę AtariOnline. Brawo!!!
    Nie wypada mi dyskutować :).
    
    Choć chętnie bym pobronił Linux-a.
    Też używam go od lat 90-tych.
    Teraz Ubuntu to cadillac w porównaniu z małym fiatem Fedorą z tamtych lat.
    Wszystko co potrzeba jest w zasięgu ręki, a właściwie linuxowego repozytorium.
    Ale to nie to forum.
    
    Jeszcze raz brawo Tdc.
34. • 34:
       
      CommentAuthorpirx
    • CommentTime16 Apr 2021

     
    tak, to kurna pomóż mi odpalić WUDSN na ubunciaku, chyba już wszystkiego *) próbowałem i klops.
    
    
    
    *) oczywiście nie wszystkiego
35. • 35: CommentAuthormono
    • CommentTime16 Apr 2021

     
    Mój Boże, co ja zrobiłem...
    
    @José Pereira: It's interesting. Do you know why only the luminance of PM2 is ORing? By the moment I was in hope I could have full Spectrum (huh) of colours for this issue: ->link<-
36. • 36: CommentAuthoradi
    • CommentTime16 Apr 2021

     
    Z tego co pobieżnie przejrzałem: WUDSN to plugin do Eclipse.
    Eclispe nie stanowi dla Linux-a problemu.
    Problem stanową MADS i Altira, które nie mają wersji Linux-owych.
    Altira chodzi pod Linuxem przez Wine.
    MADS jako produkt prostszy też powinien chodzić.
    
    Czyli Wine, na tym Eclipse, plugin i reszta.
37. • 37:
       
      CommentAuthorpirx
    • CommentTime16 Apr 2021

     
    no nie zadziałało
38. • 38:
       
      CommentAuthorCyprian
    • CommentTime16 Apr 2021 zmieniony

     

    itguyinaction:

    Swoją drogą znacie jakieś fajne gry/dema pokazujące dobrze możliwości C64 i Atari w zakresie spritów (co można na maksa wyciągnąć)?

    
    
    Tutaj fajny opis duszków C64 na przykładzie gry Great Giana Sisters:
    codetapper.com/c64/games/great-giana-sisters/
39. • 39: CommentAuthortebe
    • CommentTime16 Apr 2021

     
    ? mads ? można skompilować dla Linuxa, FPC (Free Pascal Compiler) jest dostępny na wiele platform
40. • 40: CommentAuthorbob_er
    • CommentTime16 Apr 2021

     
    MADSa skompilować można, potwierdzam.
41. • 41: CommentAuthorbob_er
    • CommentTime16 Apr 2021

     
    @TDC: rozwiń proszę część o "bezsensowności i niepraktyczności" scrollowania co 1 piksel w hiresie.
42. • 42: CommentAuthorJosé Pereira
    • CommentTime16 Apr 2021 zmieniony

     
    In hi-res only PMG2&3 will Oring and is, of course, PF2.
    More than what I showed yesterday it's also possible to Oring also colours (like yesterday top one is Prior_0 and bottom Prior_1, left to right PMG0->PMG1):
    
    
    
    So here you see that PMG2 blue colour 8 Oring brown colour1 turned into colour9 and like yesterday also Oring luminosity turned into cyan (luminance E).
    The other, PMG3 green colour12 turned into grenn13 and also Oring luminosityE.
    As allways the PMGs0&1 doesn't have any impact in using them with Prior0.

    • Prior_0 in hires _PMG2&3 also Oring in PF2 colour.png
      
      
      
      
    • Prior_0 in hires _PMG2&3 also Oring in PF2 colour.g2f
    • Prior_0 in hires _PMG2&3 also Oring in PF2 colour.xex
43. • 43: CommentAuthorJosé Pereira
    • CommentTime16 Apr 2021 zmieniony

     
    Following this and Oring or not colour PF2, here's and example of it just Oring luminosity (but as todays previous can also Oring hue) you can get 3colours of PMG2&3 but again not from PMG0&1 that still has the same 2.
    I have the idea to create something back then using this, like for aexample a panel sides for a tetris,...:

    • Prior_0 and borders.png
      
      
      
      
    • Prior_0 and borders.g2f
    • Prior_0 and borders.xex
44. • 44: CommentAuthorJosé Pereira
    • CommentTime16 Apr 2021

     
    Have to inspect next week. seems luminances are two also on 0 and 1 different...
45. • 45:
       
      CommentAuthortdc
    • CommentTime17 Apr 2021

     

    adi:

    Najpiękniejszy post, jaki w życiu widziałem :).
    Mówię zupełnie serio. Spokojnie nadaje się na artykuł na pierwszą stronę AtariOnline. Brawo!!!

    
    A dziękuję bardzo;) Bardzo mi miło;)
    
    

    adi:

    Choć chętnie bym pobronił Linux-a.
    Też używam go od lat 90-tych.
    Teraz Ubuntu to cadillac w porównaniu z małym fiatem Fedorą z tamtych lat.

    
    No to widzę, że obaj mamy podobne doświadczenia.
    Ja pamiętam że w dystrybucjach Red Hat było wiele różnych systemów okienkowych, każdy inaczej się zachowywał, można było sobie z nich korzystać - dziś kwestia nieznana np. na Ubuntu...
    
    Co do Linuxa to wielokrotnie ratował mnie z opałów, naprawdę nie wyobrażam sobie aby pecet miał Windowsa i nie miał równocześnie linuxa. Windows jest tak awaryjny, że nie ma wyjścia, trzeba mieć możliwość ratunku gdy Windows uparcie twierdzi, że "wie" lepiej.
    
    

    adi:

    Wszystko co potrzeba jest w zasięgu ręki, a właściwie linuxowego repozytorium.

    
    Tak to był ogromny skok jakościowy;)
46. • 46:
       
      CommentAuthortdc
    • CommentTime17 Apr 2021 zmieniony

     

    bob_er:

    @TDC: rozwiń proszę część o "bezsensowności i niepraktyczności" scrollowania co 1 piksel w hiresie.

    
    Proszę bardzo;)
    
    Przypominam, że rozmawiamy o kwestii animowania sprajtów w C=64 o 1 piksel w hiresie co ramkę.
    
    Dlatego zaproponowałem przykład gry:
    ->link<-
    tutaj macie ją na YT (to dla tych co nie mają teraz możliwości odpalenia tego na Atari):
    

    
    Z tym że proszę się nie sugerować YT, bo wygląda ta gra fatalnie (animacja co 2 klatkę!), tu mamy wszystkie animacje w ramce na Atari, więc trzeba to jednak oglądać na real Atari. Zamieszczam YT jedynie poglądowo aby było wiadomo o jakiego typu poruszanie się obiektów chodzi.
    
    Czyli robimy identyczną grę na C=64, tak aby wszystkie animowane obiekty były co 1 piksel w hiresie.
    
    Postać gracza jeśli dobrze pamiętam to co ramkę porusza się co 2 pixele w poziomie i co 4 piksele w pionie.
    Jeśli zrobilibyśmy ją na C=64 animowaną co 1 piksel - to poruszałaby się 4 krotnie wolniej...
    ...co zabija grywalność tej gry.
    
    Następnie spowalniamy przeciwników, którzy najwolniej poruszają się w tej grze co 1 pixel (ten atarowy), ale też wielu porusza się kilkukrotnie szybciej. Czyli w najlepszym przypadku duszek poruszałby się 2 razy wolniej.
    ...co zabiłoby grywalnośc tej gry jeszcze dobitniej...
    
    To samo dotyczy pocisków przeciwników, bonusów itp. Zwróćcie uwagę na to, że szybkość poruszania się pocisków przeciwników jest bardzo powolna (tylko na początku rozgrywki!), czas nim pocisk przeleci z prawa na lewo to ~5 sekund. Ale na C=64 byłoby jeszcze wolniej...
    
    Drastyczne spowolnienie przeciwników daje jeszcze jeden efekt, mianowicie przeciwnicy potrafią zaskoczyć gracza, cofając się - podkreślał to ktoś kiedyś na forum, że jest to bardzo fajne. Jednak element zaskoczenia jest jedynie gdy animacja jest taka jak na Atari, jeśli ją bardzo spowolnimy na C=64 to cała zabawa pryska...
    
    Do tego pozostaje kwestia pocisków gracza. Zbierając zielonego bonusa, pociski gracza dostają powerupy. Jest wiele poziomów (8 lub 9), w tym na najwyższych pociski jeszcze bardziej przyspieszają. Nie pamiętam w tej chwili ale pociski mogą się poruszać co 8,9,10,11 lub 12 pixeli (tych atarowych). Nie pamiętam ale coś w tych zakresach - z pewnością przyspieszają i z pewnością poruszają się szybciej niż 8.
    
    Czyli na C=64 mielibyśmy pociski które poruszają się od 16 do 24 ramek wolniej... (to prawie pół sekundy)
    
    Na koniec możemy dodać jeszcze animowanie grafiki.
    Gwiazdy animują się obecnie w odpowiednich - moim zdaniem - prędkościach, tak aby zachować odpowiednie wrażenie prędkości lotu pojazdem. Jeśli te gwiazdy spowolnimy na C=64 to efekt prędkości poruszania się będzie bardzo spowolniony, czyli wszystko się będzie ślimaczyć - straci ten efekt.
    To samo z grafiką stalaktytów i stalagmitów, ta animacja odbywa się bardzo szybko jak na gry 8-bitowe, bo aż co 4 piksele (atarowe), dzięki takiej dużej prędkości, mamy fajne wrażenie, że obiekt jest bliżej i przez to animuje się szybciej, a pojazdowi gracza daje poczucie że leci bardzo, bardzo szybko (w stosunku do innych gier na Atari).
    
    Jeśli spowolnimy animowanie się tej grafiki na C=64 do 1 piksela to w czasie jednej ramki Atari przesuwa grafikę o 4 piksele, a na C=64 co 1 i to o połówkę tego na Atari. Czyli Atari w 1 ramce przesuwa grafikę, a C=64 potrzebuje na to 8 ramek, czyli bardzo duże spowolnienie.
    To kompletnie psuje efekt.
    
    Podkreślam, że spowalnianie kolejnych typów animowanych obiektów, to kolejne kroki spowalniania gry (te spowolnienia się sumują), bo przykładowo jeśli ślamazarnie porusza się postać gracza, a przeciwnicy nie to jeszcze jest ok, jest trudniej. Ale jak spowolnimy przeciwników to wrażenie spowolnienia się potęguje, a spowalniając kolejne obiekty jak pociski, gwiazdy w tyle itp. wykonujemy kolejne kroki spowalniające rozgrywkę i wrażenie prędkości lotu...
    To bardzo ważne elementy.
    
    Ostatecznie otrzymalibyśmy grę, która wyglądałaby jak bardzo spowolnionym tempie. Zatytułować taką grę moglibyśmy muchy w smole.
    
    Czyli kompletnie przeciwieństwo tego co mamy na Atari.
    
    W żadnej strzelance tego typu nie ma żadnej potrzeby poruszania się sprajta co 1 piksel hires bo będzie to za wolno.
    Jeśli poruszamy postacią gracza to postać ta nim przeleci pole gry od góry do dołu lub do/z lewa z/do prawa upłynie bardzo dużo czasu - o wiele za dużo.
    
    
    Teraz zupełnie teoretycznie może zajść taka potrzeba, że jakiś obiekt moglibyśmy animować co 1 pixel hires, coś takiego miałby sens jedynie w grach bardzo statycznych, bardzo powolnych, jakiś przygodówkach niezręcznościowych, jakiś point&click itp.
    Jednak jak dowodzi doświadczenie gier z Atari czy np. Amstrada CPC (tych w niższej rozdzielczości), kompletnie nie ma takiej potrzeby, a osiągane efekty są w 100% zadowalające.
    
    
    Na koniec jest jeszcze jedna bardzo ważna kwestia. Bardzo przydatne na C=64 jest to, gdy animujemy tło gry co 1 piksel hires. Jest to animacja bardzo powolna, czyli całkowicie tracimy efekt szybkości poruszania się gracza. Jednak nie musi mieć to takiego znaczenia. Tło faktycznie może sobie się poruszać wolno.
    I tu pojawia się pewna istotna kwestia: warto na C=64 poruszać tło wolno, gdyż wynika to z poważnego błędu konstrukcyjnego tego komputera. Mianowicie, gdy kończy się zakres działania scrolla sprzętowego zachodzi potrzeba przepisania całej grafiki tła do nowego miejsca, to musi być zrealizowane z pełną wydajnością CPU i tak się składa, że przy triku rozwinięcia pętli się to wyrabia, kosztem kilobajtów RAMu straconego na ten najszybszy możliwy kod kopiujący.
    (na Atari nie istnieje taka potrzeba, aby stracić kilobajty kodu na wykonywanie jakiś dziwnych operacji kopiowania całej pamięci obrazu itp.)
    
    To poważny błąd konstrukcyjny, więc Jack Tramiel miał rację, że C=64 jest komputerem do edukowania dzieciaków a nie do gier:P;)
    
    Dlatego w tym konkretnym przypadku animowanie tła gry nie co 2 pixele hires tylko co 1 oddala w czasie ten fatalny moment. Należy to rozumieć tak, że gdy przyspieszamy animowanie tła np. co 2 piksele na ramkę lub 4 pixele na ramkę (to już lepiej będzie wyglądało - jeśli chodzi o wrażenie prędkości mijanej grafiki, względem postaci gracza) - to coraz częściej zachodzi ten problem, czyli częściej tracimy wydajność ramki, która zajęta jest kopiowaniem tych danych.
    Straty wydajności są wtedy tak ogromne, że można to porównać do krojenia, ćwiartowania CPU w C=64 na duże fragmenty... a przekonywano mnie tutaj, że CPU w tym komputerze to takie zbliżone wydajnościowo do Atari... jak widać twórcy tego komputera zrobili wszystko, aby tak nie było.
    Czyli prędkość poruszania się stalaktytów i stalagmitów z Atari przeniesiona na C=64 jest właśnie tym już bardzo kłopotliwym przypadkiem, którego oni muszą unikać jak ognia.
    
    Jednak podkreślam, że ta chęć animowania tła gry w C=64 co 1 piksel hires, nie jest spowodowana doznaniami estetycznymi, ale fatalną organizacją sprzętu nieprzystosowanego do scrollowania zawartości obrazu - oni się tak wydajnościowo ratują, bo nie mają wyjścia...
    
    Podkreślę, że w tak skonstruowanym sprzęcie możliwość animowania duszków również po Y (w odróżnieniu od Atari) lub automatycznym zmienianiu klatki animacji (a nie ręcznym jak w Atari) staje się jeszcze ważniejsze - więc z dużym prawdopodobieństwem dodano w C=64 te możliwości sprzętowo tylko dlatego, aby zminimalizować kuriozalny mankament straty wydajności ramki przy scrollowaniu całego ekranu (to ważne! dlaczego nikt z Was tego nie podkreślił??).
    Czyli gdyby C=64 nie potrafił zmieniać pozycji Y sprzętowo (wymagałoby to przekopiowania ~500 bajtów tych 8 sprajtów na każdą ramkę, czyli zarżnęłoby to znacząco CPU) oraz klatki animacji sprajta, to w tej ramce, w której trzeba wykonać tę karkołomną pętlę kopiującą całą zawartość grafiki - wszystkie sprajty by się zatrzymywały !!! Wyobrażacie sobie to??
    Więc teraz cała gra w C=64 też się zatrzymuje, ale wspomniane możliwości sprajtów - markują ten problem i nie jest on widoczny dla gracza - jak dla mnie jaja jak berety!;)
    
    Na Atari wszystkie te problemy nie istnieją. Natomiast scrollowanie grafiki można realizować na wiele różnorodnych sposobów, czyli właściwie każdy może zrobić co chce.
    Przykładowo w niekonwencjonalny sposób zrobiłem taką animację całego ekranu w tej grze:
    ->link<-
    

    
    Tu w Action! całkowita zajętość CPU z animowaniem płynnym całej zawartości ekranu, wraz z procedurą generującą teren w zadanych parametrach na bieżąco - zajmuje ~10% czasu ramki, czyli tyle co nic.
    Dla C=64 to miazga, tym bardziej że oni te kopiowania nie robią w kompilatorach takich jak Action!, tylko robią w asemblerze, którego wydajność nie starcza, więc trzeba rozwinąć pętlę, aby się całość wyrobiła...
    
    Na Atari w tej grze w te pozostałe 90% mocy CPU (w każdej ramce!) można dodać dowolnie skomplikowane rzeczy, np. animowanie świata 3D z demka Numen albo na środku ekranu animować ogromny obiekt 3D, z cieniowaniem i teksturami;) (np. na duszkach aby widać było wszystkie elementy równocześnie).
    Pewnie kiedyś rozwinę tę grę i dodam do niej dodatkowe elementy, które w jakiś sposób - jeszcze nie wiem jaki - wykorzystają tę wolną moc obliczeniową;)
    
    Czy taka odpowiedź Ciebie satysfakcjonuje?;)
47. • 47:
       
      CommentAuthorCyprian
    • CommentTime17 Apr 2021 zmieniony

     
    @tdc fajna nuta w tym "Patrol in the Space", ciekawe w jakim trakerze zrobiona.
    gra też ciekawa
48. • 48:
       
      CommentAuthorRastan
    • CommentTime17 Apr 2021 zmieniony

     
    @tdc: chodzi o to, że na C-64 możesz sobie zrobić animację co 1 pixel, ale możesz zrobić i co 2 pixele hi-resu - możesz po prostu do rejestrów sprzętowych duszków dodawać liczbę 2 :-). Na Atari, możesz TYLKO co 2 pixele, bo jak dodajesz 1 to i tak masz 2 piksele hiresu. Wynika to z dwu-pikslowej precyzji atarowskich duszków :-). I to jest sedno sprawy. :-)
    
    Po prostu sprity C-64 są bardziej elastyczne.
    
    Edit: podajesz jako przykład strzelanki i twierdzisz, że nie ma potrzeby skrolowania tła co 1 piksel. I może masz rację, gdy jest to główny skrol. Ale co jeśli np. w grze występuje paralaktyczny skrol i to "odległe" tło ma animować się wolno? I tutaj skrol co jeden piksel jest idealny.
49. • 49:
       
      CommentAuthorbocianu
    • CommentTime17 Apr 2021 zmieniony

     
    To poważny błąd konstrukcyjny, więc Jack Tramiel miał rację, że C=64 jest komputerem do edukowania dzieciaków a nie do gier:P;)

    
    
    Idealnie obrazuje to ilość gier i konwersji z arcade na C64 vs Atari. Co Ty za głupoty opowiadasz Tomek?
50. • 50: CommentAuthortebe
    • CommentTime17 Apr 2021

     
    to co próbował uzyskać Pavros poprzez suszarkę, czyli przesunięcie obrazu o pół cyklu koloru i mruganie takimi dwoma ekranami
    
    na C64 jest za darmo