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.
Cyprian:
@tdc fajna nuta w tym "Patrol in the Space", ciekawe w jakim trakerze zrobiona.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. :-)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 :-)Rastan:
Po prostu sprity C-64 są bardziej elastyczne.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.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.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.bocianu:
Idealnie obrazuje to ilość gier i konwersji z arcade na C64 vs Atari. Co Ty za głupoty opowiadasz Tomek?tebe:
to co próbował uzyskać Pavros poprzez suszarkę, czyli przesunięcie obrazu o pół cyklu koloru i mruganie takimi dwoma ekranamisolo/ng:
C64 ma o lige lepsze sprity. o czym w ogole tutaj dyskutowactdc:
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(...)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).solo/ng:
pisanie, ze posiadanie opcji co pixel jest gorsze niz brak tej opcji to jakis trolling;)tebe:
ejjj, ale on tylko chciał nas sprowokować do szczerej merytorycznej dyskusji ;)Pecus:
czytam zawsze jego teksty ze szczerym uśmiechem ;)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.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 (...)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.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.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).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.tdc:
Czyli na C=64 mielibyśmy pociski które poruszają się od 16 do 24 ramek wolniej... (to prawie pół sekundy)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.tdc:
(na Atari nie istnieje taka potrzeba, aby stracić kilobajty kodu na wykonywanie jakiś dziwnych operacji kopiowania całej pamięci obrazu itp.)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.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.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...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ł??).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 !!!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 graczatdc:
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.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.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).bocianu:
(...) Co Ty za głupoty opowiadasz Tomek?crrn:
jakie dwa zapisy aby zmienić pozycję?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.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.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?Rastan:
Można sobie wyobrazić grę komnatową lub przygodową, gdzie ruch obiektu o 1 piksel (może i wolny) będzie jak najbardziej wskazany.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 eleboratyRastan:
pisać ogromne eleboraty, które i tak nikogo tutaj nie przekonająRastan:
a jeśli przekonają to tylko beginerów, którzy po przejściu na bardziej zaawansowany poziom zderzą się ze ścianą. ;-)tdc:
Coś mi się zdaje że powtarzasz moje słowa:tdc:
Spokojna głowa, już niebawem zobaczycie co obecnie robiłem;)tdc:
I w tym problem, dlaczego na stronce o Atari ludzie są przekonani o tym, że Atari jest gorsze...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.tdc:
Czyli Ty już nie jesteś tym beginerem?? To zapraszam do zmierzenia się z 18 punktami;)bocianu:
Miałem po prostu nadzieję, że się opamiętasz w swoim fantazjowaniu i naginaniu faktów.adi:
Powiększanie rejestru o 2 jest droższe (więcej cykli) niż powiększanie o 1adi:
Poświęcanie czasu na coś innego niż mierzenie się z argumentami strony przeciwnej to zwyczajne poddanie się w dyskusji.Rastan:
... a jeśli przekonają to tylko beginerów, którzy po przejściu na bardziej zaawansowany poziom zderzą się z rzeczywistością. ;-)adi:
Powiększanie rejestru o 2 jest droższe (więcej cykli) niż powiększanie o 1.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
adi:
To przedstaw proszę swoje argumenty z poziomu bardziej zaawansowanego. Przecież Tdc właśnie to Ci proponuje.adi:
Jeśli trafi się koder, któremu jeszcze chce się coś napisać na AtariX - 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
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?Rastan:
Ile rzeczy byłbyś w stanie zrobić zamiast pisać ogromne eleboratyRastan:
Bez żadnej złośliwości - osobiście nie mogę się doczekać. :-)
