atarionline.pl Prawdziwa walka Atari kontra Commodore - 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.

    • 1: CommentAuthorsolo/ng
    • CommentTime17 Apr 2021 zmieniony
     
    C64 ma o lige lepsze sprity. o czym w ogole tutaj dyskutowac

    skrol co pixel - jak na a8 jak chcesz plynny wolny skroll hires - musisz uzywac 2 zestawow znakow z przesunieciem o pixel (taki scroll jest na poczatku w Forsaken Love).

    pisanie, ze posiadanie opcji co pixel jest gorsze niz brak tej opcji to jakis trolling;)
    • 2:
       
      CommentAuthorPecus
    • CommentTime17 Apr 2021 zmieniony
     
    Spoko. Tedec jest znany ze ślepej wiary w wyższość wszystkiego co atarowskie i zawsze znajdzie jakieś argumenty, które (przynajmniej jemu) uzasadnią tę tezę :P

    Mając tego świadomość, czytam zawsze jego teksty ze szczerym uśmiechem ;)
    • 3:
       
      CommentAuthorcrrn
    • CommentTime17 Apr 2021
     
    Bocianu napisał
    "Idealnie obrazuje to ilość gier i konwersji z arcade na C64 vs Atari. Co Ty za głupoty opowiadasz Tomek?"
    Pecus napisał:
    "Mając tego świadomość, czytam zawsze jego teksty ze szczerym uśmiechem"

    No więc tym razem to już nie jest nawet śmieszne tylko straszne...
    To co przeczytałem w tym długim wywodzie o skrolowaniu to są takie brednie jakich nie widziałem do tej pory.
    Sorry Tomek tego się nie da inaczej nazwać, a naprawdę szukałem jakiegoś właściwego słowa.

    Sporo rzeczy już koledzy wyżej napisali a które ciałem napisać/wkleić... Dość wspomnieć o grach z arcade. Zerknij sobie Tomku na YT na takie tytuły z C64
    Armalyte, RType, Katakis, Enforcer, IO, X-Out, Turrican1,2 itd itp... nie dość że scroll to jeszcze grafika używa mapy kolorów (kolejna, wg Ciebie rzecz nie do zrobienia bo przecież też trzeba przepisywać) a na dodatek ma parallax w hiresie. (Swoją drogą to akurat najprostsza rzecz)

    I wcześniejszego i obecnego komentarza nie pisałem aby Cię obrażać. Przy wcześniejszym śmiałem się bo wyszło na jaw że paru rzeczy o c64 nie wiesz (jakie dwa zapisy aby zmienić pozycję?), ale tutaj klapki na oczach przysłaniają Ci zdroworozsądkowe interpretowanie faktów. Z takim tekstem jak ten Twój powyżej nie da się dyskutować. Jest to dość smutne bo pisujesz książki o gamedevie. Książkę mam. Jeszcze nie przeczytałem. Teraz będę się bał tam zajrzeć.
    • 4: CommentAuthortebe
    • CommentTime17 Apr 2021 zmieniony
     
    ejjj, ale on tylko chciał nas sprowokować do szczerej merytorycznej dyskusji ;)

    solo/ng nie wiedziałem że w Forsaken Love jest taki skroll o 1 pixel HiRes, dlaczego teraz się o tym dowiaduję?
    • 5:
       
      CommentAuthortdc
    • CommentTime17 Apr 2021 zmieniony
     

    Cyprian:

    @tdc fajna nuta w tym "Patrol in the Space", ciekawe w jakim trakerze zrobiona.
    gra też ciekawa

    Tak muza naprawdę ma w sobie coś fajowego - Michał zaskoczył mnie tak świeżym podejściem. Autorem jest Michał "Caruso" Brzezicki i muzykę zrobił w fajowym RMT.

    Rastan:

    @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. :-)

    No tak... ale o tym właśnie tutaj rozmawiamy;)

    Czyli:

    Rastan:

    ż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 :-)

    Ja właśnie o tym mówię, że w grach na C=64 właśnie tak się robi, bo inaczej postacie poruszają się zbyt wolno. Tymczasem na atari się robi zwiększenie co 1 i też jest ok.

    Rastan:

    Po prostu sprity C-64 są bardziej elastyczne.

    Tak, jednak jak tutaj wykazałem jest to okupione wieloma mankamentami i też wykazałem że ma to bardzo konkretne powody, czyli dylematy przed jakimi stali konstruktorzy tego komputera.

    Rastan:

    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.

    Nie, podkreślam o czym rozmawiamy:

    tdc:

    Przypominam, że rozmawiamy o kwestii animowania sprajtów w C=64 o 1 piksel w hiresie co ramkę.


    tdc:

    W żadnej strzelance tego typu nie ma żadnej potrzeby poruszania się sprajta co 1 piksel hires bo będzie to za wolno.

    Wspominałem o animowaniu tła tylko na marginesie i nie napisałem nic co mogłoby Ciebie zaskoczyć:

    tdc:

    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.


    Rastan:

    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.

    O! Bardzo fajny przykład - dzięki, że jednak Ty w odróżnieniu od obrażających mnie tutaj ludzi potrafisz podać przykład fajny i adekwatny do opisywanych tutaj zagadnień.

    Dlatego Rastan: tak, z całą pewnością tak.
    Tylko tak jak już pisałem rozmawialiśmy tutaj o animowaniu sprajtów - dlaczego? Dlatego, że często trzeba zmieniać ich pozycję w trakcie trwania linii rastra i wtedy ustawianie dwóch a nie jednego bajta ma duże znaczenie.

    A co do tła z paralaksą jak piszesz, to wiele fajowych gier na Atari z paralaksą pokazuje, że Atari doskonale sobie z tym efektem radzi. Ostatnio była jakaś nowa gra która miała paralaksę na pół ekranu - nie pamiętam tytułu.
    Może ktoś zapodać link do tej gry?
    Z góry dziękuję.


    bocianu:

    Idealnie obrazuje to ilość gier i konwersji z arcade na C64 vs Atari. Co Ty za głupoty opowiadasz Tomek?

    Rozumiem, że trudne jest dla Ciebie odnoszenie się do faktów i konkretów np. zdarzeń z historii tych firm, wolisz w to miejsce mnie bez sensu obrażać...
    Ale spróbujmy...
    Wyśpij się, skup się, może się uda:

    Jak to jest możliwe, że gdy firma Atari była u szczytu swojej potęgi to konwertowano na Atari wszystkie hity z automatów arcade, np. Defender, Pac-Man, Space Invaders, Moon Patrol itp. itd.
    Natomiast, gdy firma Atari zaczęła Warnerowi zbywać, a następnie została sprzedana Jackowi Tramielowi - wtedy przestała konwertować, tymczasem w firmie Commodore konwertowano nadal...
    ...bo firma ta nie zbywała nikomu i nie zmieniała właścicieli (przypominam, jak Tramiel miał wejść do siedziby Atari to jeden z pracowników powiedział w radiowęźle "uwaga nadchodzą wojska imperium";)) )
    Crrn nawet wylicza te tytuły, które w tym okresie powstawały na C=64.

    Dlatego skup się, konwersje nie były robione bo po przejęciu Atari przez Tramiela, to realizowano priorytety Tramiela a nie te jakie miało Atari jeszcze w latach 70.

    Wyjaśnię to jeszcze jaśniej: gdy firma zmienia właściciela, ma ogromne zwolnienia pracowników wcześniej zatrudnionych to nie ma się co dziwić, że zaprzestano na jakiś czas (lub całkowicie) konwersji gier z arcade.

    Jak tego nie zrozumiesz, to już nic się nie da poradzić...


    Warto podać jeden z niewielu dowodów na to, że Atari pozamiatałoby gdyby jednak firma miała inne losy. Przykładem tego jest wypłynięcie prototypu gry Commando dla Atari, gra ta mażdży tym jak można grę arcade w tym późniejszym czasie zrobić na Atari, żadna wersja Commando na C=64 nie może skoczyć tej atarowej, nawet pomimo posiadania tak wspaniałych sprajtów - jak tu piszecie:P

    tebe:

    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

    Racja - celne spostrzeżenie.

    O czym to świadczy?
    Z jednej strony, że jednak da się przesunąć obraz na Atari co 1 pixel hires. Z drugiej że skoro się tego nie używa to znaczy że jest to nieprzydatne lub też że można się bez tego obejść.
    Nie spotkałem się z lamentami w rozmowach kogokolwiek, że muszę skorzystać ze zjawiska DGT (Pavrosa) bo inaczej tego nie zrobię.

    solo/ng:

    C64 ma o lige lepsze sprity. o czym w ogole tutaj dyskutowac

    Pragnę podkreślić, że od tego zacząłem moje wywody, więc przypominam:

    tdc:

    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(...)

    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.


    solo/ng:

    skrol co pixel - jak na a8 jak chcesz plynny wolny skroll hires - musisz uzywac 2 zestawow znakow z przesunieciem o pixel (taki scroll jest na poczatku w Forsaken Love).


    Tak, dzięki za podanie kolejnego przykładu na to.
    Ja wcześniej podałem też inny przykład to demonstrujący.

    solo/ng:

    pisanie, ze posiadanie opcji co pixel jest gorsze niz brak tej opcji to jakis trolling;)

    Wcale nie, bo ja twierdzę, że animowanie sprajtów jest bezsensowne co 1 piksel hires, i omawiamy to odnośnie gier.

    Natomiast Ty piszesz odnośnie nie sprajtów tylko scrollowania grafiki oraz w kontekście dem.
    A to jednak co innego.
    Przykładowo dlatego, że w demach przydaje się każdy ficzer jaki daje sprzęt;) Choćby był najbardziej nieprzydatny i niepraktyczny to w demku można z tego zrobić coś ciekawego;)
    Tak to widzę.

    tebe:

    ejjj, ale on tylko chciał nas sprowokować do szczerej merytorycznej dyskusji ;)

    Właśnie.
    Ruszcie szare komórki!;)))
    • 6:
       
      CommentAuthormiker
    • CommentTime17 Apr 2021
     
    Tomek, a po prawdzie - ile czasu zmarnowałeś na te dwa pełne bzdur posty, a co mógłbyś zrobić przez ten (już bezpowrotnie stracony) czas?

    "Nothing to see here, move along".
    • 7:
       
      CommentAuthortdc
    • CommentTime17 Apr 2021 zmieniony
     
    @bocianu
    @Pecus
    @crrn
    @miker

    Niestety Wasze komentarze są kompletnie niemerytoryczne, nie odwołują się do zagadnień o których piszę.
    A szkoda, bo podałem wiele faktów, wiele konkretnych mankamentów, odwołań historycznych, odwołań do innych komputerów i konsol z epoki. To konkrety i tu można się z nimi nie zgodzić, ale wyłącznie podając fakty - rozumiem że to trudne i wymagające. Np. wskazując że np. w Commodore zapis pozycji duszka jest 1 bajtowy mimo że ja pisze że jest dwu, albo że Apple miał sprzętowe duszki z większą ilością kolorów itp.

    Rzuciłem w tych postach bardzo konkretne fakty i ostre podsumowania tych faktów, sprawia Wam to poważne problemy percepcyjne, więc zebrałem je tutaj dla Was jeszcze raz - odnieście się do nich, jak je obalicie to będziecie mieli moralne prawo do tego aby określać mnie np.

    Pecus:

    czytam zawsze jego teksty ze szczerym uśmiechem ;)


    Dlatego tu macie zebrane podane przeze mnie fakty i oceny - do dzieła Panowie!

    1.

    tdc:

    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. (...)


    2.

    tdc:

    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 (...)


    3.

    tdc:

    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.


    4.

    tdc:

    (...)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...)


    5.

    tdc:

    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.


    6.

    tdc:

    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.


    7.

    tdc:

    Czyli na C=64 mielibyśmy pociski które poruszają się od 16 do 24 ramek wolniej... (to prawie pół sekundy)


    8.

    tdc:

    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.


    9.

    tdc:

    (na Atari nie istnieje taka potrzeba, aby stracić kilobajty kodu na wykonywanie jakiś dziwnych operacji kopiowania całej pamięci obrazu itp.)


    10.

    tdc:

    Dlatego w tym konkretnym przypadku animowanie tła gry nie co 2 pixele hires tylko co 1 oddala w czasie ten fatalny moment. (...) gdy przyspieszamy animowanie tła np. co 2 piksele na ramkę lub 4 pixele na ramkę (...) to coraz częściej zachodzi ten problem, czyli częściej tracimy wydajność ramki, która zajęta jest kopiowaniem tych danych.


    11.

    tdc:

    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.


    12.

    tdc:

    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...


    13.

    tdc:

    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ł??).


    14.

    tdc:

    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 !!!


    15.

    tdc:

    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


    16.

    tdc:

    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<-


    17.

    tdc:

    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...


    18.

    tdc:

    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).


    Macie tutaj 18 punktów, które dotyczą głównie Atari, ale też i Commodore. Jeśli coś tu się nie zgadza to proszę bardzo! Forum dla Was.


    Bo na razie wasze niemerytoryczne odpowiedzi traktuję jako pozbawione wartości.

    Ja tu nie piszę, że mam wrażenie, że coś jest lepsze ja podaję fakty np. kopiowanie ~500 bajtów dla 8 duszków w ramce - konkret, jeśli animowanie duszków w C=64 bez ich możliwości sprzętowego przemieszczania po Y nie wymagałoby kopiowania ~500 bajtów na ramkę to udowodnijcie to że się mylę itp.
    Macie 18 wyzwań dotyczących i Atari i C=.


    Natomiast Wy idziecie w swoich komentarzach jeszcze dalej:

    Nie dość, że nie potraficie odnieść się merytorycznie do tego o czym rozmawiamy, to jeszcze mnie obrażacie, oto przykład:

    bocianu:

    (...) Co Ty za głupoty opowiadasz Tomek?

    Bardzo słabo...

    A do tego np. tu

    crrn:

    jakie dwa zapisy aby zmienić pozycję?

    Zaprzecza jakoby w C=64 potrzeba było dokonywać dwóch zapisów do poprawnej zmiany pozycji duszka.
    Rozumiem, że to że jesteś ze sceny Commodore'owskiej zwalnia Ciebie z tego aby się na Commodore znać, ale podkreślam, że aby poprawnie ustawić współrzędną duszka w C=64 potrzeba wykonać dwa zapisy czyli 2*LDA i 2*STA, w momencie gdy w Atari robimy to 1*LDA i 1*STA.

    Takie są fakty i żebyś czarodziejsko skakał z tym uśmiechem na ustach i gotował w wielkim kotle uszy komarów, nogi konika morskiego, oddechy trupa to nie ugotujesz dostatecznie mocnego wywaru abym uwierzył, że jest inaczej;))
    • 8:
       
      CommentAuthorPecus
    • CommentTime17 Apr 2021 zmieniony
     
    Pomijając resztę bzdur.......

    tdc:

    Dlatego, że często trzeba zmieniać ich pozycję w trakcie trwania linii rastra i wtedy ustawianie dwóch a nie jednego bajta ma duże znaczenie.


    Widzisz, na Atari trzeba zmieniać pozycję w trakcie trwania rastra bardzo często - bo nie ma innego wyjścia.
    A na c64 najczęściej nie trzeba i tyle na temat jednej z wielu bzdur.


    I nikt nie ma tutaj zamiaru Cie obrażać (tak myślę ;) ) sam jednak pokazujesz pewnego rodzaju zacietrzewienie i niechęć do uznania faktów.

    Zrób na Atari płynny przesuw sprita w poziomie z szybkościa dużą, bo np. 3 piksele hires na ramkę, albo 5, albo 7, albo 9 - tak bez szarpanego ruchu....
    • 9: CommentAuthortebe
    • CommentTime17 Apr 2021 zmieniony
     
    przykład programiku w MP (Mad Pascal) realizujący ruch X:Y ducha na C64

    ->link<-

    sprowadza się to do 4-5 x POKE

    - włączenie wybranego ducha
    - wskazanie dla niego bloku pamięci
    - ustawienie koloru
    - ustawienie pozycji X
    - ustawienie pozycji Y
    • 10:
       
      CommentAuthorRastan
    • CommentTime17 Apr 2021 zmieniony
     

    tdc:

    Ja właśnie o tym mówię, że w grach na C=64 właśnie tak się robi, bo inaczej postacie poruszają się zbyt wolno. Tymczasem na atari się robi zwiększenie co 1 i też jest ok.


    Tomaszu, nie przekonałeś mnie. Po prostu uważam, że mając do dyspozycji ruch o 1 i/lub o 2 pixele mam więcej możliwości niż ruch tylko o 2 pixele. Strzelaniny to tylko jeden typ gier. Można sobie wyobrazić grę komnatową lub przygodową, gdzie ruch obiektu o 1 piksel (może i wolny) będzie jak najbardziej wskazany.

    miker:

    Tomek, a po prawdzie - ile czasu zmarnowałeś na te dwa pełne bzdur posty, a co mógłbyś zrobić przez ten (już bezpowrotnie stracony) czas?


    Generalnie dobrze pisze Miker.
    Ile rzeczy byłbyś w stanie zrobić zamiast pisać ogromne eleboraty, które i tak nikogo tutaj nie przekonają, a jeśli przekonają to tylko beginerów, którzy po przejściu na bardziej zaawansowany poziom zderzą się z rzeczywistością. ;-)
    • 11:
       
      CommentAuthortdc
    • CommentTime17 Apr 2021
     

    Rastan:

    Można sobie wyobrazić grę komnatową lub przygodową, gdzie ruch obiektu o 1 piksel (może i wolny) będzie jak najbardziej wskazany.

    Coś mi się zdaje że powtarzasz moje słowa:

    tdc:

    (...) 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.


    Rastan:

    Ile rzeczy byłbyś w stanie zrobić zamiast pisać ogromne eleboraty

    Spokojna głowa, już niebawem zobaczycie co obecnie robiłem;)

    Rastan:

    pisać ogromne eleboraty, które i tak nikogo tutaj nie przekonają

    I w tym problem, dlaczego na stronce o Atari ludzie są przekonani o tym, że Atari jest gorsze...
    Coś tu jest baaardzo nie tak...

    ...i w takich sytuacjach masz rację - naprawdę nie da się nikogo przekonać.
    Jednak mam nadzieję, że ktoś kto nie miał takich przekonań wcześniej (co potwierdza psychologia, że tylko wtedy możliwe jest sensowne rozpatrzenie danej kwestii, bo nie zmieniamy tego co już w głowie się ustaliło itp.) będzie mógł szerzej patrzeć na te zagadnienia.
    A pozostałych osób, nie przekonam mam co do tego pełną jasność. Ilość wyzwisk pod moim adresem pokazuje, że ci ludzie już dotarli do granic swoich możliwości, bo przemoc pojawia się wtedy gdy argumentów już brakuje - rodzą się wtedy ostre emocje.

    Dlatego nie spodziewam się aby ktokolwiek z nich odniósł się do choćby 10 punktów.

    ...Choć w takim wypadku wartość ich wypowiedzi by znacząco wzrosła.

    Rastan:

    a jeśli przekonają to tylko beginerów, którzy po przejściu na bardziej zaawansowany poziom zderzą się ze ścianą. ;-)

    Czyli Ty już nie jesteś tym beginerem?? To zapraszam do zmierzenia się z 18 punktami;)
    • 12:
       
      CommentAuthorbocianu
    • CommentTime17 Apr 2021
     
    Rozumiem, że trudne jest dla Ciebie odnoszenie się do faktów i konkretów np. zdarzeń z historii tych firm, wolisz w to miejsce mnie bez sensu obrażać...


    Tomku, zupełnie nie miałem na celu moim komentarzem Cię obrazić.
    Miałem po prostu nadzieję, że się opamiętasz w swoim fantazjowaniu i naginaniu faktów.
    • 13:
       
      CommentAuthorRastan
    • CommentTime17 Apr 2021 zmieniony
     

    tdc:

    Coś mi się zdaje że powtarzasz moje słowa:


    Zgadza się. :-) Cieszę się, że jesteś w stanie dostrzec możliwości zastosowania ruchu obiektu o 1 pixel.

    tdc:

    Spokojna głowa, już niebawem zobaczycie co obecnie robiłem;)


    Bez żadnej złośliwości - osobiście nie mogę się doczekać. :-)

    tdc:

    I w tym problem, dlaczego na stronce o Atari ludzie są przekonani o tym, że Atari jest gorsze...
    Coś tu jest baaardzo nie tak...


    Tomaszu, ale nikt nie napisał, że Atari jest gorsze. Po prostu w kwestii spritów jest gorsze. Ma inne rzeczy, które są lepsze, jak np. wspomniany przez Ciebie i innych szybszy procesor, czy też większa paleta kolorów. Do jednych rzeczy nadaje się lepiej do innych gorzej niż C-64 i to jest sedno sprawy. A Ty byś chciał żeby Atari nadawało się do wszystkiego najlepiej. Nieładnie tak ... :-)

    tdc:

    Ilość wyzwisk pod moim adresem pokazuje, że ci ludzie już dotarli do granic swoich możliwości, bo przemoc pojawia się wtedy gdy argumentów już brakuje - rodzą się wtedy ostre emocje.


    Spokojnie, Tomaszu, przesadzasz. Nikt Ciebie tutaj nie wyzywa. Myślę, że jesteś przewrażliwiony na tym punkcie.

    tdc:

    Czyli Ty już nie jesteś tym beginerem?? To zapraszam do zmierzenia się z 18 punktami;)


    Niestety ja jeszcze jestem beginerem, ale mam już całkiem blisko do przekroczenia granicy. :-) Ale nawet gdybym był zaawansowanym userem, wolałby poświęcić ten czas na coś innego niż mierzenie się z tymi punktami. :-)

    bocianu:

    Miałem po prostu nadzieję, że się opamiętasz w swoim fantazjowaniu i naginaniu faktów.


    Właśnie, o to chodzi. Po prostu, czasami ponosi Ciebie młodzieńcza fantazja Tomaszu, ot i co. :-)
    • 14: CommentAuthoradi
    • CommentTime17 Apr 2021
     
    Poświęcanie czasu na coś innego niż mierzenie się z argumentami strony przeciwnej to zwyczajne poddanie się w dyskusji.
    Szkoda, że zabrakło odwagi, żeby to przyznać wprost.
    • 15: CommentAuthoradi
    • CommentTime17 Apr 2021
     
    Powiększanie rejestru o 2 jest droższe (więcej cykli) niż powiększanie o 1.
    • 16: CommentAuthorrosomak
    • CommentTime17 Apr 2021
     
    Panowie, dajmy się wykazać TDCowi, nie ze wszystkim co pisze TDC się zgadzam, ale ciężko nie zauważyć, że na Atari powstają coraz lepsze produkcje które wg wiedzy sprzed paru lat nie miały prawa powstać. Atari ma ograniczenia, C64 też, tyle, że na C64 jest znacznie więcej koderów którzy te ograniczenia rozbroili, ten sam proces ma miejsce jeśli chodzi o A8, prawdopodobnie nie będziemy mieć nigdy tak fajnych spritow jak comoda ale ZX czy Amstrad nie ma ich w ogóle, i to nie przeszkadza robić świetne profil na te platformy
    • 17:
       
      CommentAuthorPecus
    • CommentTime17 Apr 2021 zmieniony
     

    adi:

    Powiększanie rejestru o 2 jest droższe (więcej cykli) niż powiększanie o 1


    I masz racje, ale jakie to ma znaczenie jeśli robisz to raz na ramkę? Może mieć to znaczenie jeśli musisz multiplikować sprajty. Chodzi o to, że w atari często trzeba je w ten sposób multiplikować, bo jeśli chcesz mieć kolorowe, to masz je 2 (słownie dwa), a na C64 w większości przypadków nie musisz tego robić wcale, bo sprajtów masz 8.
    Tedec pisze tu wyłacznie o pozycji posiomej sprajta, a teraz porównaj ile cykli zajmie przesunięcie sprajta w pionie o 1 piksel (takiego o wysokości 20 pikseli ;) ), a ile to samo zajmie na C64.

    To właśnie pokazuje, że Tedec dobiera krytaria tak, by pasowały mu pod z góry przyjętą tezę, a i tak często są nie trafione.
    • 18:
       
      CommentAuthorRastan
    • CommentTime17 Apr 2021 zmieniony
     

    adi:

    Poświęcanie czasu na coś innego niż mierzenie się z argumentami strony przeciwnej to zwyczajne poddanie się w dyskusji.
    Szkoda, że zabrakło odwagi, żeby to przyznać wprost.


    Dla mnie to po prostu zwyczajna strata czasu.
    Ale dziękuję za ten post. Utwierdził mnie w przekonaniu, że moje poprzednie stwierdzenie:

    Rastan:

    ... a jeśli przekonają to tylko beginerów, którzy po przejściu na bardziej zaawansowany poziom zderzą się z rzeczywistością. ;-)


    jest jak najbardziej prawdziwe.
    Zdaje mi się, że jeszcze nie przeszedłeś na bardziej zaawansowany poziom. ;-)
    • 19: CommentAuthoradi
    • CommentTime18 Apr 2021
     
    To przedstaw proszę swoje argumenty z poziomu bardziej zaawansowanego.
    Przecież Tdc właśnie to Ci proponuje.
    • 20:
       
      CommentAuthordely
    • CommentTime18 Apr 2021
     

    adi:

    Powiększanie rejestru o 2 jest droższe (więcej cykli) niż powiększanie o 1.


    Generalnie tak, ale w tym konkretnym przypadku nie ma to znaczenia, ponieważ na C64 rejestry pozycji sprajtów są R/W i przyjmując najlepszy możliwy scenariusz dla Atari, czyli że pozycja X jest trzymana na stronie zerowej (a musi gdzieś być w pamięci, ponieważ nie da się jej odczytać z rejestru sprzętowego) to wychodzi tyle samo :)

    C64 - zwiększenie pozycji o dwa piksele hires / jeden lores
    inc $d000 ; {6}
    inc $d000 ; {6}
    ; {12} RAZEM

    Atari - zwiększenie pozycji o jeden lores:
    inc 80 ; {5}
    lda 80 ; {3}
    sta $d000 ; {4}
    ; {12} RAZEM


    I tyle samo będzie zawsze, dopóki pozycja X <= 255. Dodatkowo to co pisał Pecuś. Poruszanie w osi Y na Atari to przepisywanie tylu bajtów pamięci, ile ma wysokości duszek. Nawet nie ma co porównywać, bo na C64 wystarczy jedno INC
    • 21:
       
      CommentAuthorRastan
    • CommentTime18 Apr 2021 zmieniony
     

    adi:

    To przedstaw proszę swoje argumenty z poziomu bardziej zaawansowanego. Przecież Tdc właśnie to Ci proponuje.


    Czytałeś wogóle te 18 punktów? Niektóre są tak sformuowane, że trudno się do nich odnieść. Czasami są to opinie Tomka na jakiś temat, np. pkt. 5 - "Naprawdę mi się to podoba i ma sens praktyczny.". OK. A teraz ja napiszę, że mi się nie podoba, albo napiszę, że również mi się podoba. No i co z tego? Czasami są to od dawien dawna znane fakty.

    Nawet jak zgodzę się ze wszystkimi punktami, to co to zmieni? Czy nagle koderzy zaczną kodować super gry, z dziesiątkami kolorowych spritów na ekranie, paralaktycznymi skrolami co 1 piksel?
    Nie.

    No właśnie ...

    Dlatego szkoda mi na to czasu.
    • 22: CommentAuthoradi
    • CommentTime18 Apr 2021
     
    Jeśli trafi się koder, któremu jeszcze chce się coś napisać na Atari, to trzeba go po rękach całować, a nie zapewniać mu krytykę ad personam.
    W czasach świetności Atari taki człowiek jak Tdc w Ameryce byłby milionerem.
    Teraz się stara coś stworzyć to po co mu skrzydła podcinać.
    Choć osobiście jestem zdania, że tworzenie kodu na Atari to starta czasu.
    Jedyną zapłatą jest satysfakcja, a ta jak widać też nie jest gwarantowana, nawet na forum Atari.
    • 23:
       
      CommentAuthorbocianu
    • CommentTime18 Apr 2021
     
    Jeśli trafi się koder, któremu jeszcze chce się coś napisać na Atari, to trzeba go po rękach całować, a nie zapewniać mu krytykę ad personam.


    Zapraszamy do całowania. Mogę podrzucić parę adresów ;)

    Teraz się stara coś stworzyć to po co mu skrzydła podcinać.
    Choć osobiście jestem zdania, że tworzenie kodu na Atari to starta czasu.


    Doskonały fikołek logiczny :)
    Ale abstrachując, to co jest podcinaniem skrzydeł w/g Ciebie? Konfrontowanie konfabulacji z faktami? Lepiej niech sobie opowiada kocopoły, bo mu motywacja spadnie?

    Jedyną zapłatą jest satysfakcja, a ta jak widać też nie jest gwarantowana, nawet na forum Atari.


    Satysfakcja, to zadowolenie z czegoś co się samemu zrobiło, a tego Tomkowi akurat nie brakuje :)

    W regulaminie forum tez nie było podpunktu:
    *satysfakcja gwarantowana, albo zwrot straconego czasu ;)
  1.  
    K..... nie sądziłem, że mój skromnie zaczęty temat, będzie najgorętszym tematem na tym forum od kilkunastu dni. Już prawie nie nadążam czytać postów w tym wątku... :P To tak trochę off-topic. :P
    • 25: CommentAuthorkski
    • CommentTime18 Apr 2021
     
    Z jednej strony czytam te może fachowe wywody o błędach w architekturze C64, problemach ze scrolem tła, problemach z wydajnością.
    Nie znam się, więc nie mówię że są błędne.

    Z drugiej jednak strony włączam na yt Turrican II, Sam Journey, których autorzy najwyraźniej nie wiedzieli o tych problemach, i szczęka opada.
  2.  
    @kski, i to jest słyszna uwaga! Szczęka opada!
    • 27:
       
      CommentAuthorPecus
    • CommentTime18 Apr 2021 zmieniony
     

    adi:

    Jeśli trafi się koder, któremu jeszcze chce się coś napisać na Atari

    No tak Tedecowi "chce się" tak napisać coś na atari od lat 80-tych ubiegłego wieku ;)
    Mamy ciągle jedną i ciągle nieukończoną grę :) (i różne jej wariacje, także nie ukończone)

    I od razu uprzedzę teksty w stylu: "A ty Pecuś co napisałeś?", które tylko odwracają uwagę od głównego wątku.
    Otóż, napisałem na atari (i sprzęty okołoatarowskie) w swoim życiu to co umiałem dobrze napisać i tyle. Znam swoje ograniczenia i nie przeskoczę umiejętności wielu innych koderów, z powodu tego, że nie jest to moja jedyna pasja/zajęcie itp.
    I ja nie ignoruję rzeczywistości mnie otaczającej i wiedzy innych - lepszych ode mnie - koderów.

    Nie kreuję także siebie na ikonę polskiego gamedevu i nie piszę o tym ksiązek.
    Przyznam, że nie zacząłem czytać wspomnianej książki głównie dlatego, że jako uczestnik (może nie jakiś znaczący) tamtych wydarzeń obawiam się, że zobaczę tam zupełnie odmienny obraz rzeczywistości niż ten, który widziałem. Nie chcę się denerwować, po co....?

    A wracając do jednego punktu (ciągle tego samego ;) wskazanego przez Tedeca.

    Jak widać postawił on tezę którą oparł o założenie, że porówujemy tylko POZIOMY ruch JEDNOKOLOROWEGO sprajta o szerokości max. 8 pikseli.
    A nawet na przykładowym filmiku "sprajt" (w cudzym słowiu, bo wszyscy wiemy, że to nie sprajt sprzętowy) jest wielokolorowy. A w tego typu grach raczej przydają się kolorowe sprajty szersze niż 8 pikseli i poruszające się także w pionie.
    I co wtedy?
    Na Atari możemy mieć sprzętowo 1 (słowinie jeden) taki obiekt bo trzeba połączyć dwa multikolorowe sprajty, czyli wszystkie 4. A wtedy do przesuwania w poziomie trzeba ruszyć 4 rejestry (na C64 - ciągle jeden), co jak pokazał Dely wcale nie jest na Atari szybsze.
    Nawet zakładając dwukrotnie większą prędkość komputera, Atari zrobi to dwa razy wolniej.
    A gdzie przesuw pionowy?
    A gdzie pozostałe 7 sprajtów (tak tak na C64 ogarniamy to jednym i zostaje na 7, a na atari nie mamy już nic do dyspozycji).

    Czyli jak większośc punktów Tedeca, kulą w płot i bez sensu.

    A do tego elaboraty na wiele stron mające dowieść, że taki był zamysł projektantów, atari, że że to lepiej przemyślane niż gdzieś indziej.

    Ech... ja też jak byłem piękny i młody myślałem, że w wielkich firmach pracują poważni inżynierowie w garniturach, dyskutujący ze sobą i nieomylni.
    Ale kiedy sam wszedłem do ich grona okazało się, że zachowują się jak dzieci ;) - czyli tak jak my wszyscy. Zajmują się głównie "łataniem dziur" albo kombinowaniem jak tu coś zrobić, żeby jak najmniej się narobić i maksymalnie wykorzystać to co już jest gotowe.
    I to robili inżynierowie Atari, sklecili jakoś powiązanie GTIA z ANTICem w taki sposób by nie trzeba było jak w A2600 budować sprajta "ręcznie" linia po linii, a resztę zostawili jak było. I wyszło co wyszło.
    Nie ma tu żadnego specjalnego ukłonu w stronę programistów, a w stronę programistów gier w szczególności.
    • 28: CommentAuthorrosomak
    • CommentTime18 Apr 2021
     
    Może jestem ślepy, ale co w turricanie2 jest tak cudnego poza dynamiką? Bo takiej dynamiki na a8 chyba poza Albertem i czymś tam jeszcze nie kojarzę, a sam couple, taki inny nasz crownland, w beznadziejnych kolorach, dość mdły, zakładam, że zrobienie crownland to sztuka na a8 a sam couple nie wymagał aż takiego nakładu pracy, a może CL robili 2-3 programistów a SC 20-30?
    • 29:
       
      CommentAuthorcrrn
    • CommentTime18 Apr 2021 zmieniony
     
    Pecus
    ...a w tym wszystkim mnie zadziwia jeszcze to że te osądy są pisane bardzo autorytarnie. "Tak uważam, to tak jest". W tym tonie właśnie zabolało mnie szczególnie jedno zdanie:
    "[...]w commodore też wszystko jest pomyślane w oparciu o linie rastra, tyle, że twórcy tego komputera nie wiedzieli o tym[...]"
    Gwarantuję Ci Tomku że wiedzieli Bardzo Dużo o projektowaniu układów video. A takie stwierdzenie to jest daleko idąca ignorancja. W zasadzie do podciągnięcia pod trolling.

    @rosomak
    Sam couple? Jakieś Freudowskie przejęzycznie? Sam Coupé mocnym 8-bitowcem był/jest.

    Jeśli natomiast chodzi Ci o Sam's Journey to tak jak w Turricanie scroll jest tam w 8-kierunkach. Zawiera mapy kolorów. Grafikę w hires i w multi a do tego multiplexer sprit'ów. Według TDC ograniczenia C64 nie pozwalają zrobić tego tak dynamicznie. Przytoczę taki fragment z TDC'a:

    "
    [..]
    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
    [...]"

    Sam's Journey tworzyło 3-4 twórców. Podobnie Turricana. Przy czym kod i grafikę zrobił do tej pory niedościgniony dla mnie wzór Manfred Trenz.
    • 30: CommentAuthorrosomak
    • CommentTime18 Apr 2021 zmieniony
     
    Oczywiście chodzi o SJ, przyjrzę się raz jeszcze bo tak na szybko zauważyłem scrolling i blade kolorki, grafika niezłą ale kolory slabe
    A tak poza tym zgodzę się z przedmówcą co do podejścia firm czy informatyków, najprostsza droga jest najlepsza, projekt A8 jak na 79 i pojęcie w tamtym czasie o rynku, potrzebach i kierunku rozwoju zapewne był genialny, było dobrze więc po co się przemęczać, pewnie nikt nie zdawał sobie sprawy jak niewiele trzeba poprawić po 3 latach by ten sam projekt plus poprawki spowodował ogromną różnicę mozliwosi dla odbiorcy i programistów
    • 31:
       
      CommentAuthorDracon
    • CommentTime18 Apr 2021 zmieniony
     
    A to znacie?
    ->link<-
    ... ciekawe kiedy ktoś napisze o ataroscenie... ;)
    • 32: CommentAuthorbruno_j
    • CommentTime19 Apr 2021
     
    @rosomak w SJ kolory są takie jakie fabryka dała. Jak tłumaczył kiedyś jeden z twórców VIC-II silnik duchów zabrał tyle miejsca na chipie, że na wybór kolorów z większej palety już miejsca nie starczyło. Zgodnie z zasadą "jest dobrze więc po co się przemęczać" ustawili na sztywno 16 kolorów i stwierdzili, że im się podoba jak jest.
    • 33: CommentAuthorJosé Pereira
    • CommentTime19 Apr 2021 zmieniony
     
    Ok. Here's a maximum on hi-res modes:


    The PMGs are one(s) over the other just to be easy and quick for me to obtain the multicolour but can be all on same scanline(s) so you can count the colours and the maximum is on hi-res 20 instead of 23.
    PF1 is dark red (22) and PF2 is pink (2C) while BAK borders is black (00);
    -> LEFT:
    P0 violet (58) on borders / over PF0 dark violet (42) / over PF2 still same violet (48);
    P1 blue (98) on borders / over PF0 dark blue (82) / over PF2 still same blue (88);
    Multicolour then (D8) / (D2) / (D8)
    -> MIDDLE: 5th Player 4Missiles so taking PF3 colour that white (0E) that'll give darkest gray (02) over PF1 and the same white (0E) over PF2;
    -> RIGHT:
    P2 and P3: gives the previously explained 3cpolours if some part is over border(s).
    SO PLEASE NOTICE THAT THIS WAY YOU CAN CREATE A TOTALLY DIFFERENT CCOLOUR OVER BORDERS.
    Can have some use if we think on a new concept game...
    • 34: CommentAuthorJosé Pereira
    • CommentTime19 Apr 2021 zmieniony
     
    Oops. The .png image isn't the correct one.
    The .g2f and .xex are similar to what I wrote though the P0->P3 colour values are different to what I wrote but gives the a similar effect.
    Already out of the computer where I did it so will post all tomorrow...
    Sorry.
    • 35: CommentAuthorJosé Pereira
    • CommentTime20 Apr 2021 zmieniony
     
    So here's it with the higher number of colours I can get. I'm counting 29 if I'm not mistaken.
    With some time (some different wide to various Players,...) is possible to have these all at vthe same scanline though we must then push the head really hard to get what all them will be usefull for something...
  3.  
    • 37: CommentAuthorCyprian
    • CommentTime20 Apr 2021 zmieniony
     
    is it possible to get more colors with only one sprite and e.g char mode?
    • 38: CommentAuthorJosé Pereira
    • CommentTime20 Apr 2021 zmieniony
     
    The problem is that in G2F it doesn't show them properly in hi-res (like sides borders and some of the PMGs).
    It would be good that @Tebe fix it so that we don't need to constanstly save .xex to see in emulator or on a real Machine. Thanks.
  4.  
    @Cyprian in hi-res is the same be in char or bitmap modes regarding colours.
    • 40: CommentAuthoradi
    • CommentTime21 Apr 2021 zmieniony
     
    Zacytuję 3 zdania z dokumentacji Godot, bo bardzo mi przemawiają:

    "Godot Engine is a feature-packed, cross-platform game engine to create 2D and 3D games from a unified interface. It provides a comprehensive set of common tools, so users can focus on making games without having to reinvent the wheel. Games can be exported in one click to a number of platforms, including the major desktop platforms (Linux, macOS, Windows) as well as mobile (Android, iOS) and web-based (HTML5) platforms."

    Zwłaszcza, że to nowowynalezione koło w przypadku Atari i C64 jest mniej okrągłe.
    • 41:
       
      CommentAuthorbocianu
    • CommentTime21 Apr 2021
     
    @adi: a co Godot ma wspólnego z tematem? Albo ogólnie z Atari? Bo nie rozumiem nawiązania.
    • 42: CommentAuthorilmenit
    • CommentTime21 Apr 2021
     
    adi pomylił fora ;) przeszedł tu ewangelizować, że pisanie na Atari nie ma sensu i to robiący powinni się przesiąść na Godota, Unity czy jakiś inny współczesny engine.
    • 43:
       
      CommentAuthorbocianu
    • CommentTime21 Apr 2021 zmieniony
     
    Nie wróże wielkich sukcesów koledze :)
    Oczywiście na polu przekonywania.
    Bo w Godocie, to jak najbardziej.
    • 44: CommentAuthoradi
    • CommentTime21 Apr 2021
     
    Bo jak widzę, jak ludzie się męczą, żeby wyważyć otwarte drzwi, to korci mnie, żeby napisać coś takiego jak wyżej.
    Choć korci minie równolegle, żeby napisać jaką nową grę na mój komputerek oparty na stm32f103.
    A tam mam tylko 128x96 pikseli. Choć pisze się w C++.
    Jak widać człowiek jest pełen sprzeczności.
    • 45:
       
      CommentAuthorbocianu
    • CommentTime21 Apr 2021
     
    Ale kto się męczy z wyważaniem czegokolwiek? Nadinterpretujesz. To właśnie jest największa frajda pokonywać ograniczenia sprzętu i robić rzeczy o których konstruktorom się nie śniło.
    • 46: CommentAuthorPecet
    • CommentTime21 Apr 2021
     
    w takich warunkach wychodzi kreatywność ludzi. Na A8 nie ma scrolla co pixel hires? Zrób kilka zestawów znaków, odpowiednio je podmieniaj i jak nie ma, jak jest.
    Ja jestem pełen podziwu odnośnie tego, co ludzie potrafią wyczarować na takim sprzęcie. Do tego często jak już wiesz, jak to jest zrobione, to wydaje się to wręcz oczywiste i zastanawiasz się jakim cudem nikt na to nie wpadł wcześniej;)
    • 47: CommentAuthorsolo/ng
    • CommentTime22 Apr 2021 zmieniony
     
    @adi - o czym ty w ogole pierdzielisz LOL. "dzieki" za informacje o Godot - moze jeszcze o love2d, corona engine, GameMakerStudio? W kazdym plynie sie obracam (lacznie z godotem). Mozemy dodac tez UE4! Jaki to ma zwiazek z tematem?

    Kompletnie nie rozumiesz koncepcji robienia gier na stare maszynki; jak sa zawody Strongmanow to wbijasz i zaczynasz krzyczec "buuu co za bezsens" i przyjezdzadz dzwigiem, ktory uniesie 2 tony? Tak wlasnie odpaliles tutaj Mesjasza.

    Bocianu klepie kod dla satelit w kosmosie, wciaga ciebie na kazda mozliwa strone, a wyskakujesz z "po co pisanie w retro, wystarczy dzwig". oklaski.

    @tdc
    jeszcze raz - przesuwanie o pixel, a nie o dwa to "lepsze"? jakie ty gry napisales, aby miec w ogole o tym pojecie? pierwszy z brzegu R-Type:
    ->link<-

    przesuwanie obiektow w grach to nie "o tutaj wiecej o jedno lda", bo przesuwa sie objekt o zadana predkosc, zwykle zmiennoprzecinkowa (ze znakiem), ktora czesto jest <1, dopiero po tym zaczyna sie render. Przyklad z TimePilota:

    X - object number in OL list
    .proc objectVelocityMovement
    clc
    lda ol.tab.posXL,x
    adc ol.tab.velXL,x
    sta ol.tab.posXL,x
    lda ol.tab.posXH,x
    adc ol.tab.velXH,x
    sta ol.tab.posXH,x

    lda ol.tab.posYL,x
    adc ol.tab.velYL,x
    sta ol.tab.posYL,x
    lda ol.tab.posYH,x
    adc ol.tab.velYH,x
    sta ol.tab.posYH,x
    rts
    .endp ; objectVelocityMovement



    Atari ma swoje plusy, komoda ma swoje. Przestan pisac jakies kocopaly o spritach, wrzucajac jeszcze jakies "18 punktow challenge" - LOL. Mozemy zrobic jeden challenge, odpale na c64 paralaxowe tlo (takie full) z 30+ przeciwnikami 24x21 i powalczysz w druga strone. Moge tez jak ktos z c64 wyskoczy z czyms ciekawym "nie do zrobienia" zrobic challenge w druga strone i byc moze komoda zmieknie.

    Komoda jest ogolnie lepsza maszynka do robienia gier (co jest nie dziwne, jest nowsza i byla pod to robiona), ale na a8 na okolo, troche po mekach i uzywajac innych rzeczy da sie tez zrobic mega rzeczy. W przyszlosci i takie, gdzie na c64 bylby problem. Czas pokaze, jakies przecieki mam.

    Inna sprawa, ze poza wyjatkami, slabo to komodziarze wykorzystuja, a kilku rzeczy po stronie Atari tez nie przeskocza.

    Jest wielu mega koderow robiacych gry na i tylko z naszego podworka Atari jak KK, Tede, Koala, Dely, Ilmenit, Konop, Bocianu, Shanti, Mariusz, Madrafi i wielu innych (chocby kski ostatnio) - i ty potem wyjezdasz z takimi pierdolami jak "18 challenge / sprity ownz" - co oni maja sobie pomyslec? Ty chcesz ich uczyc co mozna/co dobre do uzycia na atari xl/xe? Bitch please.
    [dodajac, ze Konop jest poza nasza skalą:]

    Atarka jest zajebista maszynką, ale moze skonczmy z bzdurami i jak cos jest do napisania to niech ktos z Agendy opowie dlaczego ta planeta z 3:37 i tlo horyzontu z 4:03 jest takie zajebiste i na C64 nigdy tego nie zrobia. Moga uzyc wszystkie sprity ~.-

    odchodzac od gier - przy demach w teorii C64 kleka do miecza i zawsze bedzie klecac jezeli chodzi power/opcje/tryby. Jednoczesnie polecam obejrzec demo EON na A500. design+muzyka+fx na ta maszyne - cos pieknego. A najlepszym resesansem top-level dem na Atari jest Agenda i Lamers. Top poziom, za co ch*j im w dupe [:], bo lekko nie ma, a cos odpalic chcemy;).

    ***

    TDC - Black Rescue. - 8/10 na Wapniaku ode mnie. zaskoczonko design, gfx, plynnosc, wykonanie. Wersja final when?
    • 48:
       
      CommentAuthortdc
    • CommentTime22 Apr 2021 zmieniony
     

    miker:

    Tomek, a po prawdzie - ile czasu zmarnowałeś na te dwa pełne bzdur posty, a co mógłbyś zrobić przez ten (już bezpowrotnie stracony) czas?

    "Nothing to see here, move along".

    Rastan:

    Ile rzeczy byłbyś w stanie zrobić zamiast pisać ogromne eleboraty

    Rastan:

    Bez żadnej złośliwości - osobiście nie mogę się doczekać. :-)

    Więc proszę bardzo:
    ->link<-


    ps. solo - dziękuję - również w imieniu autora grafiki do czołówki gry Black Rescue;)
    • 49: CommentAuthorilmenit
    • CommentTime22 Apr 2021
     
    @solo/ng - Miałem napisać coś podobnego, ale mnie ubiegłeś.
    TDC ma - niestety - skłonności do silnego ubarwiania na granicy bajkopisania lub trollowania. Jest to szczególnie rzucające się w oczy, gdy próbuje być ekspertem od Atari dającym prelekcje i piszącym książki. Niestety, zbyt często fakty miesza z własnymi opiniami i dopowiedzeniami.
    • 50: CommentAuthoradi
    • CommentTime22 Apr 2021
     
    @solo/ng - Przekonałeś mnie, żeby zostawić "Strongmanów" z ich ciężarami :).