Amaurote izometr 3d na c64

[at0mic__]

@NES

na C128 sie da 50fps, bo poza dolna linia ekranu mozna przelaczyc na 2MHz
i wszystko w tablice powstawiac.
Oddzielnie mapy dla plaskich oddzielnie dla wystajacych obiektow,
nie trzeba niczego wtedy wyliczac tylko zagladac do tablic i czytac co teraz zrobic.

Na C64 bedzie super jak 25fps bedzie mozliwe.
Temat mnie dreczy bo na atarionline.pl jest rozmowa o tym ze na C64 to jest bardzo trudne do zrobienia, moze nawet niemozliwe - nawet w to uwierzylem a teraz chce sprawdzic.

Karateka na C64 chodzi polowe wolniej niz na Atari, The Great Escape chodzi dwa razy wolniej niz na ZX Spectrum a wszystko dlatego ze tam sa robione sprajty programowo i C64 ma za wolny zegarek do przepisywania pamieci. Poza tym ZX Spectrum ma rejestry 16bitowe i relokowalny stos wiec mozna sobie ustawic wierzcholek stosu na bufor i pobierac ze stosu wpisujac tam gdzie trzeba. Operacje przesuwania bitow i obcinanie maski obiektu na AND tez jest 2 razy szybsze na 16bit rejestrach.

Na razie chce to zrobic chocby jako demo.
Pozniej zobaczymy.

Jednego jestem pewien - osoba ktora to zrobi przejdzie do historii  
MASTERTRONIC - tego nie dalo rady zrobic w izometrii 3d, moze ktos jednak da rade, jesli to jest mozliwe...

Dobra, daje sobie tydzien na myslenie - potem kodowanie.

Czy jest cos lepszego do robienia muzyki niz VoiceTracker 2.0?
_________________
At0mic

[kotrobot__]

Nie wiem czy sie przyda - zobacz tu:
http://noname.c64.org/csdb/release/?id=99722
_________________
W oparach cyny...

[at0mic__]

no niezle, facet pisal to pol roku :-<

komentarz mnie rozbroil, bo coz ze wolno chodzi:

\"Most C64-freaks are old... so slow is not so bad, eh?\"
_________________
At0mic

[nes__]

_________________
\"A ile zrobisz pompek ?\" (c) 2o11 eLban

[BagoZonde]

Czesc! David Whittaker odpowiedzialny jest za muzyke w Amaurote wiec juz na starcie powiem Ci, ze to dobry wybor sprobowac z ta gra . Rzut izometryczny, ok, zakasam rekawy. Nie chce popelnic jakiegos fopa, nie zastanawialem sie nad tym dlugo ale ja to widze tak:

1. Calosc grafiki tylko w znakach w HIRES, zastanawiam sie takze czy to sie zmiesci ale musi. Gra zajmuje caly ekran wiec masakra. Dolna czesc i gorna jest stala wiec zastanawiam sie czy starczyloby czasu na przepisywanie tego kawalka przy rysowaniu ekranu. Moze na poczatek dobrze by bylo sprobowac z kilkoma grafikami zeby zrobic czysty silnik. Jezeli okaze sie, ze np: brakuje tych znakow to trudno, wykorzystaloby sie ten silniczek do jakiejs podobnej gry nieco uproszczonej .

2. Pajaczek, muchy i wystrzelona kulka rysowane by byly na zasadzie: kazdy obiekt w nastepnej ramce chyba, ze da rade od razu je narysowac na raz. Bo wydaje mi sie, ze najlepiej by bylo nalozyc dwie maski - tu juz troche pamieci trzeba by poswiecic. Pierwsza maska na samej gorze czyli czesc panelu, ktory wchodzi na plansze a pod spodem druga maska od obiektow na planszy. Moze latwiej by bylo przy wyrysowaniu planszy nawet te dwie maski jeszcze gdzies laczyc w taka temporary maske zeby przy wykonywaniu ruchu nie bylo odwolania do dwoch miejsc w pamieci gdy obiekty sa na brzegach widocznej czesci planszy - no i byloby odwolanie do jednego miejsca w pamieci gdyby bylo to pole bez tej maski panelu.

Mysle, ze na poczatek dobrze by bylo to przecwiczyc na jakims szablonie, wzorcu czy jak go tam zwal. Moge sprobowac cos takiego napisac, jest to swietne wyzwanie.

P.S. jestem poczatkujacym koderem wiec sorry za terminologie, ale jestem w stanie to zrobic. Pytanie tylko czy nie bedzie to kod dla kogos z refleksem szachisty . A noz widelec!

[bimber__]

                   

BagoZonde napisal:

Gra zajmuje caly ekran wiec masakra.

jesli ma to byc konwersja 1:1 z zx to niekoniecznie (rozdzielczosc spectrum = 256x192)

[BagoZonde]

Racja bimber, ale bazujac na wersji na Atari (ZX nie sprawdzalem, ale to chyba kalka??), mamy 28x17 pol co daje 476 znakow. Wycialem jedno pole - taki szyb choc moze to byc jakas bateria sloneczna, whatever. Prawdopodobnie nie zrobilem pikselowego offseta w poziomie czy w pionie ale to wyjdzie w praniu. Mniejsza z tym. Jedno pole skladac sie moze maksymalnie z 4x2 roznych znakow co daje 8. Z tego co widac, pozostaje tylko opcja zrobienia pol na zasadzie \"sasiadow\". Czyli jezeli po lewej ma byc drugi szyb, to mamy w pierwszym rzedzie np: ABCD a jezeli po lewej ma byc droga to GHCD. CD jest wspolne dla obu bo jest to prawa czesc. Dochodzi do tego wiele kombinacji z budynkami, ale musi sie to jakos zmiescic w znakach.

 Taka gra Fairlight - jak sie jej przypatrzylem - nie zawiera wielu roznorodnych elementow na jednej planszy - jest tam czysto. Amaurote jest bardzo bogaty.

No i do tego dochodza zarezerwowane znaki wszystkich postaci.

Sztachne sobie prosty silniczek na tej zasadzie.

BTW: Gralem troche w wersje na C64 zeby odswiezyc pamiec, straszna nuda. Nie umywa sie do wersji z Atari, zreszta wystarczy popatrzec na AI owadow co wprowadza niezla monotonie nie mowiac o rozmiarach plansz, ktore jakos wydaja mi sie o wiele wieksze ale nie jestem znawca tematu .

[BagoZonde]

Ok, w zalaczniku przesylam pierwsza wersje silnika izometrycznego: execute i zrodlo (w 64tass). Wymyslilem dzialanie silnika bez zadnych pomocy i wglebiania sie w temat wiec albo wywazalem otwarte drzwi albo napisalem glupi algorytm ale potraktowalem to jako wyzwanie wiec ciiii:). Mimo wszystko dziala w miare szybko. Jest w stanie wyrysowac plansze w czasie okolo 2 ramek wiec spokojnie mozna sobie podzielic rysowanie planszy na dwie ramki po polowie co nie wplynie na odtwarzanie muzyki, sterowania czy AI.

Od razu zaznaczam, ze:

Jestem raczkujacym programista wiec chetnie wyslucham wszelkich opinii na temat \"niuansow\" w tym kodzie choc jest to \"kod wyrzygany\" - zmieniany sto razy w ferworze pracy nad silnikiem, na tym etapie ma po prostu to dzialac . Nie optymalizowalem kodu, nie speedowalem zadnej z czesci ze wzgledu na to, iz na tym etapie jedynie probowalem wprowadzic swoja idee. Wszelka optymalizacje wykonam oczywiscie na koncu . Jest tam na przyklad jedna brzydka petla (2x wykonywana) z uzyciem zmiennej LINE2 (ktorej nazwe tez w sumie musze zmienic), tego momentu nie unrollowalem na razie.

Gwoli wyjasnienia:

Bitmape bitmap.png tworze na Amidze i konwertuje do znakow ASCII swoim sprawdzonym programem . Podobnie z tablicami. Bitmapa czytana jest jako 16 kwadratow (kazdy po 8 pikseli oczywiscie) w poziomie.

Wymyslilem sobie metode \"sasiadow\" zapisana w nybble, lewy nybble to aktualne pole a nastepny nybble to pole sasiadujace (Amaurote-neighbours.png). Tym sposobem tworzone sa znaki dla wszystkich mozliwosci a potem dana wartosc, np: 01 dla szukanego lewego sasiada to znaki 22 i 23. Zakrecone troche, ale przyspiesza znacznie wyswietlanie.
Wyswietlana jest linijka po linijce po dwa znaki. I co najwazniejsze: dodanie nastepnych obiektow nie wplynie na predkosc wyswietlania wcale.

Nie wiem czy dobra droga podazam, bo jezeli pojawi sie wiecej rodzajow pol i dla kazdego narysowac bede musial wszystkie mozliwosci to moze tych znakow zabraknac. Ale wydaje mi sie, ze dzieki temu bardzo szybko sie to wyswietla, wiec jezeli Amaurote bedzie niemozliwe do konwersji w ten sposob, zawsze pozostanie mi silnik dlatego nie liczylem czy starczy znakow - jak starczy to ok. Innej metody nie jestem w stanie wymyslic.
Obiekty \"wystajace\" ponad ziemie to kolejny etap, wszystko wlasnie chcialem wyrysowac bez modyfikacji charsetow na gotowym zestawie, wiec zastanawiam sie jak to rozwiazac dla tak roznorodnej ilosci pol. Mysle, ze wszystkie muchy, naszego \"pajaka\" moga byc tylko sprite\'ami z nakladana maska zaslaniajacych elementow.

Wiec to na tyle, rozgryzlem izometrie w ten sposob - jezeli ktos znalazlby jakies udogodnienie badz tez zaproponowal inne rozwiazanie - byloby super. Wyzwanie jest spore .

Co do obslugi mozna klawiszami kursora przesuwac sie po polach na ograniczonym obszarze.

Mam tylko problem w wyswietlaniu pozycji x i y w postaci decymalnej.
W include/print_screen.asm probowalem z:

                   

Kod:

lda #0 ldx map_x jmp $bdcd

ale zawiesza mi przerwania chyba. Po rozwinieciu tego co kryje sie pod $BDCD okazalo sie, ze \"przeszkadza\" JMP $AB1E. Nie drazylem tematu bo dowiedzialem sie o tym prostym przeksztalcaniu hex2dec godzine temu i nie chcialem zwlekac z tym kodem wiec HEEEELP!!

To chyba wszystko na razie, temat otwarty chyba, zobaczymy. Mam nadzieje, ze nie dalem plamy z tym moim kodowaniem .

Nie wiem do konca jak nalozyc na to sprite\'y skoro czarny jest przezroczystym (nie odseparuje sprite\'a od planszy na czarnym tyle) no i jeszcze dochodza te \"ramki\" z bokow, moze najlepiej z czegos po prostu zrezygnowac. Ktos umialby zamiescic w kodzie player z muzyka z gry?

BTW. Wersja Amaurote na ZX Spectrum jest nieco bogatsza niz ta na Atari wiec warto sie na niej skupic .

No i wszystkiego najlepszego Commodore 64! Rok w rok obchodzimy te same urodziny .

Edit: poprawilem te wyswietlanie koordynat w pliku i jeszcze raz wrzucilem zalacznik, zeby nie robic nastepnej wersji archiwum.   

   

                                                                                                

AMAUROTE.rar
:Opis:		Pobierz
:Nazwa zalacznika:	:AMAUROTE.rar
:Rozmiar:	:16.28 KB
:Pobran:	:Plik sciagnieto 41 raz(y)

   

[Kisiel]

jmp bcd?
Kurwa czemu jmp gdzie to ma wrocic?
_________________
\"... taka choroba. Zreszta obrazki, ktore robisz tez cos o tym mowia.
Proponuje odwrocic proporcje, zamiast byc 100% scenowym trollem, skup sie bardziej na poprawieniu warsztatu...\"

[BagoZonde]

Haha, rzeczywiscie. Podlapalem na lemonie64, ze jest jmp i pomyslalem: no moze cos tam na stack odklada i w programie testowym zadzialalo dobrze, ale teraz juz wiem, ze dlatego, ze robilem jsr do funkcji \"PRINT_SHIT\" i powrot nastepowal przez rts, ale nie ten z funkcji \"PRINT_SHIT\" tylko ten z bdcd .

Dzieki kisiel, uznaj to za moja chwilowa niepoczytalnosc, sie spieszylem .

[BagoZonde]

@Skull
Nie nie, kisiel wylal poprawna diagnoze. Testowalem to na czyms takim dla przykladu:


                   

Kod:

MAIN_PRG jsr PRINT_SHIT jmp MAIN_PRG PRINT_SHIT jmp $bdcd rts :do tego rts-a w ogole nie dochodzilo

Lamerstwo pierwsza klasa ale dzialalo w tamtym przypadku, w przypadku kodu do Amaurote juz nie . W sumie dzieki jmp $bdcd nie trzeba wpisywac potem rts po powrocie - wszystko zalezy od tego skad i jak skaczemy .

Mniejsza zreszta o te wyswietlanie koordynat.

[Nitro__]

O tej godzinie pozwole sobie tylko pogratulowac

[Skull]

e no nie do konca,
bo wciales tylko wycinek z podprocedury - w pierwszej chwili mogloby sie wydawac ze skaczesz tam z glownej czesci programu - stad ten zawiech, a tak wcale nie bylo.
ten jmp powodowal tylko za wczesny powrot z jedenej z procedur - zwis wcale nie nastepowal w romie - jakby sugerowaly te twoje 3 linijki kodu.
_________________
Bo pecet to zwykly banan...

[nes__]

Ogladnalem. Czekam na chociaz jedna nie-plaska figure  
_________________
\"A ile zrobisz pompek ?\" (c) 2o11 eLban

[BagoZonde]

@nes
Tak . Samo zrobienie przestrzennych obiektow jest latwe bazujac na tym silniku - w rzeczywistosci nadal sa to \"plaskie\" obrazki. Problem tylko w tym, czy starczy znakow, gdyz wchodza tutaj rozne kombinacje kazdego pola z kazdym. Redefinicja na przyklad 64 znakow (dla dwoch rzedow po 32 znaki) co 16 rasterlinii odpada. Naiwnie probowalem to rozwiazac w ten sposob - wyswietlilem na ekranie te znaki, ustawilem kilka przerwan IRQ ale w tak krotkim czasie procesor zdazy skopiowac pod $E800+ zaledwie max 10 znakow (uzylem unrolled: lda chars1: sta $e800: lda chars1+1: sta $e800+1 itd.).

Nie macie pojecia jak to jest rozwiazane w Fairlight, The Great Escape czy Nosferatu? Patrzylem pobieznie w kod Nightshade, ale nie wiele tam znalazlem (ekran jest pod $C000 z tego co mi sie wydaje).