Dzięki za bardzo pozytywny feedback! Na pewno pomaga motywować do dalszej pracy :).
Premiera gry niestety nieprędko. Wprawdzie engine i mechanika gry są zrobione, ale teraz sporo czasu będzie kosztować praca nad mapami i ogólnie gameplay. Do designu map podeszliśmy raczej ambitnie i teraz każda mapa wymaga conajmniej 10 godzin pracy, a jeszcze trochę map brakuje...
Jeśli chodzi o mechanikę gry to jest ona bardzo rozbudowana - najlepiej zapytać Świętego, bo bardzo ostro walczył żeby zmieścić kod logiki gry w pamięci i w ramce :). Nie wszystkie "atrakcje" są w trailerze pokazane. Jeśli mam być nieskromny to chyba żadna gra tego typu na Atari nie miała tak bogatej mechaniki jaką będzie mieć Cosmic Hero 2. Gra może na to nie wygląda, ale napisanie tej gry wymagało absolutnie topowych umiejętności koderskich.
I co niedowiarki? Zawsze mówiłem, że na Atari da się zrobić gry jakościowo dorównujące C64 a nawet lepsze, bo Atari to lepszy komputer od Komodorka, z całym szacunkiem oczywiście dla chlebaczka. :-) Jeśli gra jest dopracowana do perfekcji to Atari zawsze będzie górą. Żal mi troszkę braci komodorowców, że będą musieli przełknąć tak gorzką pigułkę, no ale może niezdecydowani zapiszą się do klanu Atari w końcu. :-D A właśnie, przewiduje się wersję na C64? Gratulacje Pazur i dla całej ekipy. Czekam cierpliwie na wersję produkcyjną. :-)
Są przymiarki do wersji C64, ale jeszcze nie wiemy jak to będzie.
Gra jest zaprojektowana wybitnie pod Atari. Wykorzystuje mocne strony Ataryny, takie jak szybsze CPU, display listę czy szerszą paletę dostępnych kolorów i unika słabszych stron, np. nie wymaga wielu sprite'ów. Tam chyba nawet pewne ograniczenia POKEY'a pomagają, bo muzyka chodzi 2x ramkę (zauważalnie lepsza jakość). Dlatego ciężko to przełożyć na C64. Święty robi naprawdę kosmiczne tricki żeby wyświetlić planszę na pełnym ekranie i jeszcze mieć czas na obsługę całej logiki gry w 50fps. Z tego co wiem, tych tricków nie da się zastosować wprost na C64. Gra jest tak dopchana, że np. wersja NTSC nie wchodzi w grę, bo po prostu nie wyrobi :).
@Pazur: drobna uwaga - poza Polską zdecydowana większość ludzi jak widzi w tytule filmiku słowo "Atari" bez kontekstu, to rozumie, że chodzi o konsolę Atari 2600. A szczegółowe opisy filmików często nie są czytane. Jeżeli nie dopiszecie w tytule "8-bit", to będą się powtarzały pytania, co to za platforma :)
Pojawiły się pytania na profilu AtariOnline na Facebooku dotyczące strony wizualnej - udzielone tam odpowiedzi w skrócie są takie: w grze jest standardowe 5 kolorów + sprajty, a dodatkowa obróbka (w tym efekt poświaty przy białym kolorze) została dodana w filmiku, aby przypominało to obraz CRT.
Na tym filmiku to jest obraz crt :) gratulacje Zelax :)Wspaniała robota :)Wysyłajcie koniecznie na fuji cup :)Foster muzycznie pozamiatał :) graficznie super PAzur :) no i wiadomo kto kodował, Święty (jak on się rozkręci w pisaniu gier ,to będzie masakra ) :)
Skoro zostałem wywołany do tablicy to napisze trochę konkretów: - gra ze względu na odświeżanie obiektów i kamery działa co ramkę czyli 50 fps - realny gameplay to 21x14 kafelków (1 kafelek to 2x2 znaki) co daje viewport 160x224 z pełnym scrollem - z racji że ekran odswieżamy co ramkę to jest on rysowany cały co ramkę również (opracowałem ciekawy sposób rysowania ekranu bez używania klasycznego bufora) , używamy trybu tzw Avalonu czyli linia powtarzana 2x ale zmiana generatora znaków co linię znakową , używamy również tablic kafelków dzięki temu znaki możemy dowolnie miksować w matrycy, również używając 5 koloru - chłopek jest rysowany na 4 spritach , odświeżany co ramkę oraz jest clipping przy ruchu kamery - kamera ma możliwość targetowania dowolnego celu na mapie - gra używa specjalnego silnika animacji obiektów - bardzo duża część obiektów jest animowana - w grze mamy 32 ruchome obiekty , z dowolną allokacją i deallokacją ma mapie i niezależnie obsługiwane z możliwością interakcji pomiędzy obiektami , obiekty są obsługiwane cały czas niezależnie od ich widoczności dzięki czemu np lasery mogą się poruszać po całej mapie , każdy obiekt ma swoją logikę - mapy mogą być 64 x 64 bądź większe, używamy 2 layerów oraz dodatkowej parallaxy w celu wyświetlania gwiazdek wolniej poruszających się niż kamera - mamy dynamiczny system nakłądania cieni obiektów na dolnym layerze (podłogi) - muzyka to LZSS grany 2x ramkę co przy tak wyżyłowanych założeniach było nielada wyzwaniem, na maszynach z Stereo używa systemu pseudo stereo znanego z Rewnida 2 - sama gra wymaga 64kb ramu ale raczej ze względu na płynność gameplaya oraz rozbudowaną muzykę i grafikę będzie w wersji CART - bardzo rozbudowana logika gry - przewody i przepływ energii , możliwy przepływ zarówno od obiektu jak i do obiektu, 2 rodzaje laserów i ich promienii , trackery (zderzaki) , bariery , platformy do przenoszenia obiektów , pola siłowe , obiekty można włączać i wyłączać oraz wiele innych - sama logika jest 3x bardziej rozbudowana niż w doomie ... musi też się wyrabiać co ramkę
Mimo że gra nie wygląda na tak zaawansowaną to musiałem ją napisać w sposób mocno demoscenowy żeby wszystko udało się upchać zarówno w pamięci jak i czasowo....
MatGuru, ale Atari umie tylko w 50FPS, nie umie inaczej wcale, ani szybciej, ani wolniej :-)
Panowie, gratulacje, bardzo dobrze się to zapowiada i z tego co pisze Święty, to wydaje się, że macie już na prawdę bardzo dużo, więc jest szansa na grę w rozsądnym czasie:-)
Święty, bardzo jestem ciekaw tych rozwiązań związanych z "layerami". Np. dynamiczny silnik cieni itp. Jak się spotkamy na jakimś zlocie, to na pewno Cię pomęczę o więcej szczegółów, bo na forum to zdaję sobie sprawę że ciężko to wszystko opisywać. Ale dzięki za tego długiego posta opisowego, dużo fajnych rzeczy tam napisałeś.
Święty, pięknie dziękuję za podzieleniem się informacjami technicznymi. Z chęcią poznałbym więcej szczegółów na ten temat. :D
Co do samej gry, to jestem pod wrażeniem oprawy audiowizualnej. W kwestii grywalności to również zapowiada się wyśmienicie. Czuję, że gra będzie hitem tego roku. :)
Przy okazji chciałbym pogratulować zwycięztwa w konkursie organizowanym przez Zero Page Homebrew. Brawo, w pełni zasłużone.
Mogę się podzielić pewnymi szczegółami ale na razie nie wszystkim, bo pewne smaczki dopiero chcę opublikować po ukazaniu się gry lub dema gry ;) Tak czy tak - np silnik animacji znakowej jest zbudowany z dwóch części - pierwsza to coś jak sheluder, który jeśli są rzeczy co się animują co 12 ramek, to rozdziela animację na sewencje tak że jeden obiekt animuje się w 1 ramce z 12 , drugi w 3 itp - tak są rozdzielane potoki żeby sama animacja była dość stabilna czasowo itp , tak samo jak rozdzielam animacje na potok ramek parzystych i nieparzystych, sheluder ustawia danej klatce i obiektowi flagę że chce go animować a procedura menagera sprawdza czy w danym moenecie obiekt ma byc i co wązne może być animowany i kasuje flagę animacji jeśli ją obsłuży, w przeciwnym wypadku przenosi jej obsługę na kolejną ramkę, to taki bezpiecznik że gdyby np coś zabrało za dużo czasu to lepiej coś animować ramkę później niż silnik gry miałby się wykrzaczyć,obecnie ten mechanizm jest tylko bezpiecznikiem.
Kolejna rzecz to sam bohater ma rozpętlony kod rysujący a kasowana jest tylko ta część sprita która się nie pokrywa miedzy kolejnymi etapami ruchu , w przypadku braku zmiany pozycji Y jest tylko sprite nadpisywany.
Ostatnia kwestia to brak klasycznego bufora ekranu - kolejne linie znaków 2x2 są rysowane na przerwaniach DLI pomiędzy zmianami generatorów znaków co 8 linii , na zasadzie: DLI -> linia1 - generator 1 - rysuję pół linii 2 DLI -> linia1 - generator 2 - dorysowuję kolejne pół linii 2 DLI -> linia2 - generator 1 - rysuje pół linii 1 DLI -> linia2 - generator 2 - rysuję kolejne pół linii 1 DLI -> linia1 - generator 1 - rysuję pół linii 2 .... i tak do końca ekranu , tam jeszcze jest kilka trików ale o tym może kiedyś indziej ... Same DLI są docyklowane ze względu na HSCROLL i VSCROLL i niuanse czasowe Antica ;) Zatem na vblanku tylko muszę przygotować 1 bądź 2 linie w buforze Procedury rysujące są na tyle szybkie i rozpętlone że w pozostałym czasie (pętla główna) odpalam dekoder LZSS (któy też jest dopalony i rozpętlony na potrzeby Rewinda2 ) i gram do "bufora" a rejestry pokeya są tylko aktualizowane w odpowiednich miejscach
święty: łał :) Ale znając Ciebie (z produkcji jakie robisz) - to za chwilę to co napisałeś to będzie pikuś przed tym co wymyślisz za tydzień. Trzymam kciuki za doprowadzenie gierki do "początku".
w trybach znakowych są wiersze, "linia" jest tutaj myląca, bo wiersz to 8 linii
można tworzyć obraz liniami na podstawie zestawów znakowych np. Twistery na znakach tak można realizować, ale to oznacza zawsze spore zapotrzebowanie na pamięć
@Święty ja też robię tak, że animuję różne obiekty w różnych ramkach, buduję sobie takie cykle, np. gra zamyka się w 3 ramkach, to w ramce 1 animuję coś tam, w ramce 2 coś tam innego, w ramce 3 coś jeszcze innego. Dodatkowo np. co 7 ramek animuję coś tam, co 15 ramek coś tam itp. Te liczniki ramek robię często takie właśnie nieparzyste, bo wtedy cała gra nie sprawia wrażenia synchronicznego poruszania się wszelkich animacji. Tak samo rozdzielam wszelkie inne procedury rysowania, logiki gry itp. Z tym że obciążam te wszystkie ramki równomiernie i robię to ręcznie. Ręcznie, tzn. cały czas sprawdzając w Altirra Performance Analyzer ile zajmują poszczególne vblanki.
Bardzo podoba mi się Twój pomysł, że zrobiłeś procedurę, która sama układa kolejkę do animacji. W ten sposób możesz animować bardzo dużo elementów, kosztem jedynie tego że niektóre animacje mogą zwalniać w przypadku zbyt dużej ich liczby, ale odbywa się to bez szkody w postaci spowolnienia samej rozgrywki, albo popsucia jakkolwiek płynności gameplayu. Nie wspomnę już o całkowitym wysypaniu się programu przez zabraknięcie miejsca w ramce i rozjechaniu się czegoś przez to.
Wg mnie to jest super rozwiązanie. Nie trzeba się przejmować tym, że nie wiadomo co się nie zmieści w ramce i spowoduje jakieś niewiadome efekty uboczne. Gra zawsze zadziała poprawnie, a najwyżej w skrajnym przypadku same animacje spowolnią.
