Amaurote izometr 3d na c64

[nes__]

Wszystkie efekty na C64 sa teoretycznie \"do zrobienia\", dopoki sie ich nie sprobuje zrobic Wtedy sie okazuje, ze plan dzialania nie wystarcza.

[BagoZonde]

Tja, prowokujesz do dzialania .

Niedawno jak 3 dni temu bawilem sie w przelaczanie character setow. Bardzo teoretycznie wydaje mi sie, ze mozna to rozwiazac wlasnie w ten sposob jednak potrzebowalbym porady kolegow.

Pomyslalem, zeby wykorzystac wspaniala wlasciwosc rejestru $d018. 4 gorne bity kontroluja SCREEN MEMORY (16 dostepnych ekranow) a 4 dolne bity kontroluja CHARACTER SET (8 dostepnych dla banku 3).

Innymi slowy w trakcie przesuwania sie planszy re-definiowane by byly np: dwa rzedy znakow w 8 kompletach CHARACTER SET. Dzieki IRQ mozna by przelaczac CHARACTER SET co dwa rzedy. Na wyswietlanych polach mozna po kolei umiescic znaki ekranowe, ktore zmieniane by byly podczas przesuniecia planszy.

Dlaczego dwa rzedy znakow? Zauwazcie, ze w Amaurote jest 16 pol w pionie! Podzielmy to na ilosc dostepnych setow. Wyjdzie po 2 rzedy. Kazdy rzad ma w poziomie 28 pol wiec zdefiniowac mozna 56 znakow dla kazdego CHARACTER SET-u. Mozna tez zrobic po 4 rzedy na CHARACTER SET - wtedy re-definiowane bedzie 56*2=112 znakow a zmieniane beda tylko 4 sety, mniejsza z tym. Reszta znakow pozostaje na ruchoma animacje i te ramko-plastry miodu dookola.

SCREEN MEMORY mozna by wykorzystac jako double buffering: raz re-definiowane sa znaki na jednym screenie, a raz na drugim - dzieki czemu przy wyswietlaniu nowego ukladu planszy nastepuje natychmiastowe przejscie ze \"starych\" znakow na \"nowe\" - przez co nie bedzie oczywiscie widoczne to, ze te znaki modyfikujemy \"w locie\". Sprawa jasna.

Obecnie silniczek, ktory napisalem pobiera numer pola z mapy i wyswietla relatywnie dla niego odpowiednie znaki ekranowe. To jest metoda na sztywke, a gdyby zrobic wlasnie dynamiczne zmieniane znakow?

Beda wiec dwa pytania, pierwsze prowadzi do drugiego. Kto zna odpowiedz, niech napisze lub zamilknie na wieki:

1) Ile czasu zajmie re-definicja calej planszy? Plansza ma rozmiar 28 x 16 = 448 znakow - kazdy sklada sie z 8 bajtow wiec musimy zmienic wartosci 3584 bajtow (!!). Teraz wiec pytanie jak najszybciej je odczytac i wyswietlic, zeby przejscia te byly w miare plynne. Trzeba tu uwzglednic zmiane adresow do danego CHARACTER SET-u (zmienianego osiem lub cztery razy).

2) Czy daloby sie utworzyc mape zlozona juz z definicji znakow? Bedzie to w sumie ta sama mapa co dotychczas tylko 8 razy wieksza (kazdy wyglad znaku sklada sie z 8 bajtow). Odczytywane wartosci bylyby od razu tymi bajtami skladajacymi sie na znak: i w ten sposob za pomoca okna z danej pozycji bylyby od razu kopiowane do odpowiednich CHARACTER SET-ow.

Jezeli na pytanie 1) i 2) znajdzie sie rozwiazanie, ten silnik moge sprobowac napisac, jest prostszy niz dotychczasowo utworzony gdyz kopiowalby tylko dane wygladu znakow ekranowych, ktore przelaczane by byly przez zmiane CHARACTER SET-ow z racji tego, iz jeden set ma tych znakow 256 a chcemy wyswietlic plansze, ktora ma ich 448 a dochodza do tego znaki naszego pajaka, pociskow, much, plastrow miodu (ramek).

Ciezko jest to napisac, latwiej narysowac a jeszcze prosciej o tym pogadac na zywca, ale mam nadzieje, ze jest to na tyle banalna metoda, ze zlapaliscie o co mi chodzi. Tylko czy ja dobrze lapie, ze to moze sie w miare szybko wyrysowac - nie potrafie sobie jeszcze odpowiedziec na to pytanie, brak doswiadczenia mi na to nie pozwala ale bede probowal jakby co.

[Skull]

Chyba jednak nie ogaraniam tego co piszesz. Czy Ty nadal walczysz ze scrollowaniem planszy, czy z czyms innym?

Te gry ktore wymieniles, dzialaja tylko na operacjach na bitmapie (nie wiem czy wogole uzywaja sprites i scrolla), bo kod byl zywcem dostosowywany z zx spectrum, tam nie ma sprites.

Mimo wszystko przy konwersji tej gry - rowniez bym postawil na zabawe na bitmapie, tyle ze wzbogacona warstwa ze sprites, a przesuwem na hsp/vsp. Okno gry nie jest duze.
Oczywiscie, problem do rozwiazania to ten: priorytet wyswietlania punktow, - bo tak wlasnie tworzymy grafike trojwymiaru,  postac bohatera i przeciwnikow - raz przed przeszkoda raz za, a dochodzi jeszcze nakladanie sie przeciwnikow z bohaterem, pociski, czyli beda potrzebne tablice maskujace, uwzgledniajace cechy sprites.

Ale moze lepiej w trybie tekstowym.

[BagoZonde]

Mysle o trybie tekstowym tylko. I tak jak w Amaurote nie mysle o zadnym scrollu - tylko o rysowaniu ekranu podczas przesuniecia (po przejsciu pajaka do krawedzi zostaje przesuniety ekran tak, ze pajak znajduje sie znowu na srodku). Jezeli scroll bylby mozliwy to super, ale mysle, ze C64 nie wyrobi aby to bylo plynne.

I chodzi mi o to, zeby w trakcie tego przesuniecia w locie kopiowac bajty prosto z bitmapy (o taka mape mi chodzilo) do odpowiednich znakow ekranowych, np: idac od 0 dojdziemy dla dwoch rzedow do 55 znaku - mamy wiec 56 znakow dla kazdego character setu a potem przelaczamy na nastepny character set i znow definiowane jest kolejne 0-55 znakow ekranowych. A dlatego przelaczane character sety za pomoca IRQ bo w jednym character secie nie zmiescimy calej planszy, ktorej rozmiar to 28 x 16 = 448 znakow. W tym kontekscie te okno jest duze .

Oczywiscie do tego musi jeszcze istniec mapa (taka jak obecnie w moim kodzie) sluzaca do detekcji czy na dane pole mozna wejsc, czy mozna \"te pole zniszczyc\" pociskiem, etc.

[Skull]

czyli jak rozumiem - teraz Twoim problemem jest buforowanie ekranu?

[BagoZonde]

Skull, ten problem nazywa sie brakiem doswiadczenia . Nie chce wywazac otwartych drzwi wiec mam tylko pytanie czy to moze byc w miare szybkie? Jezeli tak, napisze do tego spokojnie kod, ktory potem ktos doswiadczony i tak pewnie bedzie mogl przyspieszyc . Pomysl wydaje mi sie dobry wiec po prostu czy jest sens sie tym babrac? Napisze sobie do tego jakis edytor, zeby mi bitmape szybko generowalo.

[Skull]

tzn. jezeli przesuw ekranu ma byc o taki \"krok\" jak jest w orginale, to moze rzeczywiscie lepiej przepisywac na char-y odpowiedni fragment z calej mapy levelu (czasu na pewno starczy).
Ale bedzie to tylko rozwiazanie dla chodzenia po lokacji. Teraz trzeba bedzie pomyslec o przeszkodach/elementach wystajacych planszy. Tu z pomoca przychodza sprites - ale nie do konca, bo priorytet wyswietlania sprite jest bardzo prymitywny, albo zaslania tlo, albo tlo zaslania sprite, no i w przypadku gdy ma tylko czesciowo zaslonic robi sie problem.
Zeby porzadnie emulowac ten \"wymiar\" potrzebna bedzie zabawa w analize punktow do wyswietlenia - tu jest kilka wariantow i nie wiadomo ktory w rezulatacie bedzie korzystniejszy.
Zeby tego bylo malo, dochodza pociski i rozwalanie przeszkod.
Operowanie na charach, wyglada w tym przypadku beznadziejnie.

[nes__]

                   

BagoZonde napisal:

Skull, ten problem nazywa sie brakiem doswiadczenia

W sumie, to z tym problemem spotykaja sie wszyscy piszacy cos koderzy, ktorzy nie robia \"wycinanek\"

[BagoZonde]

No nic, sprobuje wiec to napisac na zasadzie kopiowania z gotowej bitmapy i podmiany odpowiednich CHARACTER SET-ow, zeby wyswietlic na ekranie taka ilosc znakow. Pomyslow nigdy mi nie brakuje .

Co do maskowania, nie bede robil zadnej kolejnosci rysowania, tj. najpierw podloga - potem pajak a potem zaslaniajacy go troche budynek.

Tak jak pisalem wczesniej: budynki mimo tego, ze sa w rzeczywistosci trojwymiarowe - zostana potraktowane jako plaski element planszy a maskowane beda wszystkie obiekty \"zywe\". Do tego potrzebna wiec bedzie druga bitmapa-maska, ktora zaslaniac bedzie tylko wtedy, gdy pozycja x i y bedzie za danym polem.

Duzo paprania bedzie i sporo miejsca to bedzie zajmowalo, ale czego sie nie robi dla predkosci dzialania.

[brush__]

Hej,

Moze sie nie znam ale proponuje:

1. Nie morduj sie z charsetami uzyj bitmape. Jeden to za malo, bedziesz mial zabawy wiecej i przepisywac duzo.
2. Jesli chcesz miec pajaczka na srodku ekranu i scrollowac bitmape za pomoca hsp/vsp (juz ktos proponowal). Jak to wyglada w praktyce zobacz tutaj: http://csdb.dk/release/?id=55080 Jak to skodowac to chyba juz tez sa jakies tutoriale.
3. Jesli nie chcesz scrollowac tylko przerysowywac ekran w momencie dojscia do krawedzi to tez bym sie nie przejmowal bo wiesz z pewnym wyprzedzeniem  do ktorej krawedzi zmierza pajaczek. Wiec mozesz ja wyrysowac kilka ramek wczesniej i po prostu przelaczyc tylko ekran jak juz pajaczek dojdzie. W najgorszym wypadku jak ktos zmieni zdanie tuz przy krawedzie ekranu i zacznie zawracac to ci sie \"zmarnuje\" to co narysowales, ale to zadna strata chyba.

Nie wiem dlaczego Atarowcy mysla, ze sie na c64 nie da

[BagoZonde]

Czy ktoś wyjaśnił by mi działanie VSP? Poczytałem co nieco, ale średnio to rozumiem. Mało tego na sieciuni. Jak to w ogóle działa, wiecie, ideologicznie jak to działa i praktycznie. Może Mythosa przejrzę, może tego Freda. Tam jest właśnie chyba line cruncher - co poznaję po tym, że jest górne menu. Tak naprawdę zebrałem pare informacji, poznałem też koleżkę z Niemiec, z którym wymieniamy się wiedzą i on ma "prawie" działające VSP więc nie potrzebuję gotowych rozwiązań, kawałka kodu. Chcę to po prostu zrozumieć . Myślałem, że w wykładziku Dekay z Cresta z 2011 to znajdę, ale chyba nic tam nie ma. Przewinąłem pobieżnie, teraz dopiero zacznę to oglądać od deski do deski. Przydałby się koleżka od kodowania, z którym można wyjść na większe piwo .

[BagoZonde]

FCUK! Myślałem, że piszę na c64scene.pl przez chwilę i zastanawiałem się, co się stało ze skórką?! Raf, to nie jest fajne... Tam zacząłem i tam chcę ten wątek skończyć, dozwolone to, żeby facet skończył, ale żeby w dwóch miejscach? To już rozwiązłość .

[Kisiel]

BagoZonde:

Tam zacząłem i tam chcę ten wątek skończyć, dozwolone to, żeby facet skończył, ale żeby w dwóch miejscach?

Skończ najpierw Meonlawel, masz założony jako jedyny swoje subforum, ja uważam że to jest niesprawiedliwe ale nie wyje o tym do Rafa. Po drugie nie Ty założyłeś wątek tylko Brush.

Poza tym nie musisz używać VSP, tylko spokojnie przepiszesz bitmapę co jest zrobione przez Wegiego w I love cube 100% bez użycia VSP.

[BagoZonde]

Meonlawel jest projektem długofalowym (cRPG) więc jego ukończenie zajmie mi sporo czasu. Amaurote zainteresowałem się ze względu na wyzwanie (at0mic rozpoczął wątek o Amaurote) i tak naprawdę VSP chciałbym zrealizować nie tylko w odniesieniu do Amaurote ale także do Meonlawela (patrz: Mythos z tym, że u mnie w hi-res). Cały czas podnoszę swój skill i nie ma nic w tym złego myślę. Od początku chciałem, żeby Meonlawel był scrollowany ale ze względu na ograniczenia techniczne (kiedyś jeszcze pisałem go w bejzolu) zrezygnowałem z tego pomysłu. Nie wiem zresztą czy w taki sposób go rozwiążę, bo przyzwyczaiłem się do screenowego przechodzenia ale chciałem spróbować. Ostatnio sporo rzeczy zresztą w odniesieniu do Meonlawela zrobiłem. Nie musiałem się zresztą Tobie tłumaczyć z tych rzeczy, wyluzuj. Nie pisałem też, że zacząłem tamten wątek, tylko, że TAM zacząłem.

Kisiel:

Skończ najpierw Meonlawel, masz założony jako jedyny swoje subforum, ja uważam że to jest niesprawiedliwe ale nie wyje o tym do Rafa.

No i oprócz mnie jest jeszcze Komoda na tym forum. Jeżeli uważasz, że istnienie subforum poświęconego Meonlawel jest niesprawiedliwe, to napisz o tym do Rafa, może nawet się okaże, że masz rację. Ja jestem mu za to wdzięczny ze względu na support.

[Kisiel]

Jakby mi to bardzo przeszkadzało to bym o to mu dupę truł.
To Ty piszesz o jakimś kończeniu... długo falowy projekt ciągnie się już od 2007r i jakoś mi to też nie przeszkadza bo nie interesuje się grami poza SCENARIO ...
.... ale IMO Ty nie kończysz tylko ciągle coś zaczynasz i lubisz jak się coś dzieje, stawiasz sobie coraz to wyższe poprzeczki a to nie ma końca
Jak chcesz coś osiągnąć to wyznacz sobie datę,
określ plan minimum,
zrealizuj go i w końcu coś skończysz !
Jak już masz coś skończone to realizuj następny plan, cel musi być SMART !!!
Specyficzny,
Mierzalny,
Ambitny,
Realny
Terminowy ... bodaj, szkolenie dawno było;)