Niezłe. Znając jednak Gonza obawiam się, że na tym się skończy. ;) Choć może będzie jeszcze jakaś mała poprawka. :) Niestety między paralaktycznym scrollem, a pełną działającą grą jest ogromna przestrzeń. Osobiście wątpię w powodzenie projektu, aczkolwiek trzymam kciuki. Jeśli się uda to możecie mnie zbiczować na najbliższym party. :) :) :)
No tak... Wprawka techniczna wprawką a jeśli chodzi o konwersję gry i engine, to pewnie musiałby sporo czerpać z kodu wersji C64 by się udało i nie pisać od nowa. Ale gdyby to się udało... :-)
Ale po co? Nie lepiej zrobic nowa gre z takim zaje... scrollem?
Jesli juz to podkrasc tylko grafe, ale scenariusz, mapy itp zrobic swoje...
Gonzo - mam podobe obawy co Rastan :/ Podziwiam Twoja pomyslowosc i zapal, ale mam wrazenie ze jak tylko cos Ci zaczyna banglac, juz myslisz o nowym projekcie ;) Robisz cos w rodzaju "proof of concept", inaczej mowiac pokazujesz jakie piekne MOGLIBYSMY miec gry na Atari :P
BTW. Co z Ghost'n Goblins? Zdaje sie ze tez jest na etapie scrolla ;)
Sam ostatnio przekonalem sie bolesnie, ze najgorsza czescia robienia gry (przynajmniej dla kodera) jest projektowanie leveli, testowanie, dopieszczanie szczegolow. Kiedy od strony kodowej 80% jest juz do wykonane i chcialoby sie ruszyc cos nowego, to do wydania gry brakuje jeszcze 80% pracy. I kupa :(
Przejrzałem na szybko. Moja lista mam nadzieje konstruktywnych uwag. Wyłącz w programie wychodzenie przez klawisz bo się wszystkim crash'uje gdy nie mają skonfigurowanego poprawnie joy'a. Przypuszczam że gdzieś to masz w części od playerki RMT.
Nie używa się tych samych rejestrów na stronie zerowej dla VBLK i DLI !!!!!!!!!!!!! Przecież to się powinno wywalać tak niemiłosiernie że szkoda gadać. Naprawdę jestem pełen podziwu że to działa. Na razie nic nie robisz poza przerwaniami to jakoś działa, ale jak coś zaczniesz to będzie klops. Użyj dla vblanka stosu a dla dli strony zerowej.
Już się chyba zorientowałem dlaczego Twoja procka jest wolniejsza pomimo węższego ekranu. Przepisujesz cały ekran w części paralaxu sklejając go z dwóch. Ale organizacja ekranu mnie zaskoczyła, dosyć karkołomna na potrzeby gry. Lokalizacja znaku na ekranie będzie delikatnie mówiąc trudne. Pięciokolorowa grafika też nie ułatwi Ci życia. Softwarowe sprity będą zmieniać kolory jak w Black Lampie. A już nie wspomnę o tym że przy tej palecie bordery będą na niebiesko chyba że zastosujesz wide screen ale wtedy już procek się na 100% nie wyrobi.
Generalnie dużo przed Tobą dużo pracy i jak napisał nosty to była najłatwiejsza i najprzyjemniejsza część. Nie staraj się na siłę trzymać oryginału. Niektórych rzeczy nie da się zrobić jak na c64 ale nie które da się lepiej na A8.
Gonzo, Eagle - moglibyscie podzielic sie poktoce wiedza jakiego algorytmu i z jakimi ograniczeniami uzywacie? Bo z tego co zrozumialem to Gonzo uzyl procedury Eagle przerabiajac ja na wlasne potrzeby?
Chcialbym zrobic sobie male cwieczenie z platformowki. Efekt uzyskany przez Gonza mnie oczarowal, a nie ma sensu wywazac otwartych drzwi, jesli mozecie podzielic sie wiedza.
Nie wiem gdzie doczytałeś że użył mojej procedury? :) Przynajmniej nic mi o tym nie wiadomo. Z tego co widzę zastosował całkiem inną technikę. I z tego co pisał konsultował się z Alexandrem który udzielał się poprzednio w tym wątku. A uzyskanie parallaxu jest tak banalne że myślę że nawet nie warto opisywać :D Dobra żartuję wyślę Ci potem na PW.
Przepraszam za pomylke! Chyba zasugerowalem sie tym ze doradzales w sprawie optymalizacji.
>A uzyskanie parallaxu jest tak banalne że myślę że nawet nie warto opisywać :D
W sumie tak. Idea jest jasna. Ale uzyskanie WYDAJNEGO paralaxu zeby sie wyrobil na Atari juz takie banalne nie jest ;) (przynajmniej dla poczatkujacego programisty). Dzieki z gory za opis.
@Gonzo jest tylu sceptykow bo lepiej dac sie milo zaskoczyc niz rozczarowac, a Ty jestes niezly w robieniu smaku na bardzo pozadane gry ;)
Ja nie chce kodu zrodlowego! Bo i tak go pewnie nie zrozumiem ;) Wystarczy mi 2 akapity opisujace algorytm i oraniczenia. Jak zaczne cos pisac to na pewno dopytam.
Jeśli się nie mylę, robisz ROL-a na kopii ekranu 2, następnie XOR-a, a na koniec korzystasz z DL-owego przesuwania w poziomie+licznik co 8px przesuw znakow w lewo - lub coś w ten deseń ? czy mi się wydaje, czy korzystasz także z kopiowania playera|missila celem przesłonięcia "sunących" krawędzi ekranu ?
@Gonzo - wyszlo mi z obliczen, ze jesli masz 12 wierszy paralaxa * 32 znaki to musisz przesuwac 3072 bajty co daje min. jakies 21500 taktow. Cholernie duzo. Co druga ramke? Mozna by te robote podzielic na dwie ramki, ale wtedy trzeba by miec podwojny bufor drugiego planu (i przepisywac ten bufor, ale to drobiazg). Krotko mowiac: ile % mocy procesora zabiera sama paralaxa?
Jest 9 wierszy razy 33 znaki. Czyli do przepisania jest 297 bajtów. Reszta odbywa się poprzez przełączanie odpowiednio przygotowanych generatorów znaków. W tym przypadku 12 generatorów. Żadnego rorowania xorowania itp. Szykuję szerszy opis całej techniki ale cierpliwości :)
Aaaaaaa Tego sie nie spodziewalem :) No ale to strasznie ograniczajace! Po prawej stronie znaku X drugiego planu moze stac tylko jeden konkretny znak Y. A dla kazdego znaku lezacego na lewej krawedzi obiektu trzeba stworzyc osobny znak "nieba" :) Zadziwiajace ze mimo tych ograniczen tak dobrze i naturalnie to wyglada w przykladzie Gonza!
Bo cała sztuka to nie jest zaprogramowanie parallaxu. To jest szczerze mówiąc najłatwiejsza część. Najtrudniejsze jest zaprojektowanie grafiki dla drugiego planu. Tam panują śmieszne zasady :) Gonzo miał o tyle uproszczoną sprawę że dysponował już zaprojektowaną grafiką z c64.
@gorgh - faktycznie, szcun ze to wymysliles. Ja to nawet przeczytalem, ale wtedy nie zaglebilem sie jeszcze w te gre tylko bylem pod wrazeniem efektu i pomyslalem ze cos tam krecisz nie na temat ;) No bo jak panie podmieniac predefiniowane zestawy, jak przeca widac ze trzeba przesuwac! ;))
czy mi się wydaje, że jedenym ograniczeniem jest szerokość elementu grafiki pierwszego planu: zawsze wielokrotność całego znaku ? i skąd 12 zestawów ? Co z sytuacją, kiedy chcemy stworzyć przejście z jednego planu (bg) na drugi ?
Aha, pierwszy plan musi byc wpasowany w znaki bo plany sa skladane z rodzielczoscia znaku a nie pixela. (w przykladzie Gonza zaobserwowalem na ktoryms tam znaku pierwszego planu pixel w kolorze nieba i nie przeswitywal przez niego drugi plan)
12 zestawow, bo jeden zestaw znakow starcza na 3 linie (3x 33 znakow = 99), paralaxa ma 9 wierszy co daje 3 zestawy, ale poniewaz szerokosc znaku to 4 pixele to trzeba przygotowac 4 wersje kazdego zestawu, z przesunieciem odpowiednio o 0,1,2,3 pixele. Czyli 3x4 = 12. Sporo pamieci. A tak naprawde gdyby chciec uzyc duszkow softwarowych to trzeba by uzyc 1 zestawu na 2 linie...
Nosty wydaje mi się, że i tak w tym momencie zostaje o wiele więcej czasu na "inne rzeczy" niż bawić się w locie z operacjami na na 99 liniach (#17)...
IMHO można tak skorelować prędkość pierwszego planu, by wystarczyło 6 zestawów znaków ("szybki przesuw").
> Sporo pamieci.
Parafrazująć: "64K ought to be enough for anybody" ? Stawiałbym na uznanie 320kB(compy) za wartość niezbędną :-) (to moje prywatne zdanie i proszę nie offtopować o tym akapicie w wątku, który dotyczy PARALAXu :P )
16 kB przełączanej pamięci powinno być wystarczające: 16 zestawów znaków: 32 linie po 1 zestawie co 2gą linię, przy "szybkim przesuwie" potrzeba by było 32kB, a z całą resztą spokojnie można się zmieścić w 128kB. Teoretyzuję oczywiście-czy jest to ktoś w stanie potwierdzić?
Sterowanie w Planet Attack: joystick dół=wznosi się jostick góra=opada joystick lewo=w głąb planety, z tym, że pojazd się nie skaluje i to kiepska iluzja joystick w prawo=statek bliżej gracza, uwaga jak wyżej Dla otarcia łez przygrywa nam Axel Foley.
Nowy przykład paralaksy na Atari, podesłany przez autora, który się tu udziela, ale na razie się do tego nie chce przyznawać, bo 1) mówi, że można to zrobić jeszcze lepiej, 2) nie będzie z tego gry, a zaraz znajdą się ludzie chcący od niego ciągnięcia tego projektu :D. No jeszcze nie ten czas i miejsce. Na razie więc tylko oglądamy i marzymy:
Jak to autor nie chce się przyznać? Przecież jest już kilka wątków na ten temat, które on sam założył: ->link<-->link<-
[To ten sam autor który robi Alberta w Mad Pascal-u: ->link<- Jest też m.in. o podkolorywaniu: ->link<-
Jak się okazuje dawno temu grałem w dwie jego gry ->link<- :)]
Trzymam kciuki za ukończenie, jeżeli do tego poruszanie się postaci będzie naturalne, a poziomy będą ciekawe, to te gry będą super nie tylko technicznie :)
Edit: W sumie nawet fajnie, że postać mija inne postacie mogłaby to być niekoniecznie bijatyka :)
@pecet: one nie drgają, po prostu przesuwają się wolniej a engine UT zrobił resztę i przez to ruch jest szarpany. Od pewnego czasu można zgrywać na UT filmy 50Hz i 60Hz, wtedy jest niemal to samo jak z danej platformy (jest jeszcze pewna utrata jakości wynikła z kompresji danych, ale w tym przypadku to jest pomijalne).
Oczywiście, dla 50Hz trzeba jeszcze mieć monitor i kartę które to obsługują i wtedy dopiero jest 1:1 jak na danej PAL platformie.
