Wiadomość wysłana przez: at0mic__ w 02 Grudnia 2011, 14:10
Moj pierwszy komputer to Atari 800xl a komputer na ktorym pisalem w assemblerze to Commodore64 (obecnie c128 - choc czesciej uzywam emulatora VICE)
Pomysl jest taki.
Na pewno znacie izometryczna gre Amaurote na ZX SPECTRUM - jest powalajaca IMO. Na Atari tez to niezle wyszlo chos troche wolno chodzi, natomiast C64 ma wersje widziana zgory \"pajaczka\" totalnie odbiegajaca od oryginalu i wedlug mnie o niebo gorsza. Czy Mastertronic nie dalo rady zrobic tego na c64?
A moze sprobujemy ?
Chocby jako demo...
Przepisywanie pamieci nic tu nie da - trzeba bedzie zrobic to jakims trikiem. I na pewno HIRES sie nie sprawdzi trzeba bedzie na tekstowym ekranie chyba robic z z kolejnymi fontami ustawionymi pionowo. Plastry miodu na sprite\'ach bo inaczej trzeba maske AND zeby obcinac grafike planszy...
zalaczam link do Amaurote ZX Spectrum http://youtu.be/xvnt2gAk3fw
Zapraszam do dyskusji.
Wiadomość wysłana przez: nes__ w 02 Grudnia 2011, 14:25
Wiadomość wysłana przez: at0mic__ w 02 Grudnia 2011, 14:38
![\"Wink\"](\"images/smiles/icon_wink.gif\"){kind=icon}
Wiadomość wysłana przez: bimber__ w 02 Grudnia 2011, 15:07
![\"Smile\"](\"images/smiles/icon_smile.gif\"){kind=icon}
mam sentyment do obu tych gier, bede mocno kibicowal.
Wiadomość wysłana przez: kotrobot__ w 02 Grudnia 2011, 16:27
I tak caly czas czekam na:
http://www.youtube.com/watch?v=OKuwl3sA3cE
Wiadomość wysłana przez: nes__ w 02 Grudnia 2011, 17:53
btw. ja tez bede mocno kibicowal powstawaniu tej gry, jakkolwiek mi sie ona nie podoba
Wiadomość wysłana przez: SUDi__ w 02 Grudnia 2011, 19:24
Wiadomość wysłana przez: kotrobot__ w 02 Grudnia 2011, 19:58
Wiadomość wysłana przez: at0mic__ w 03 Grudnia 2011, 14:40
chce ja zrobic na generatorze znakow. 256 fontow zapisywanych real-time ale nie kazdy tylko te ktore maja sie pojawic przy kazdym przesunieciu ekranu o 8px tzn jak juz bedzie wiadomo ze pajak idzie w lewo gora to mozna zaczac przepisywac grafike.
mam problem polegajacy na przelozeniu mapy 1x1 liniowo uozonej w pamieci (logincznie kolumny w rzedzie - najpierw y potem x - fonty pionowo abc itd.) gdzie bedzie wyliczana kolizja i mozliwosci ruchu pajaka i pszczol na mape z klockow 2x2 w izometrycznym ukladzie gdzie kazdy klocek 2x2 jest w osi y nizej o 1 (czyli 8x8) i trzeba to jeszcze przyciac do 18x12 fontow (pierwotnie myslalem o takim polu widzenia planszy ale to jeszcze nie jest pewne).
Problemem jest albo zegar procka albo pamiec dlatego najpierw musze zdobyc calosc grafik zeby zobaczyc ile to zajmuje... To wyznaczy czy mozna mape isometryczna uzupelnic pustymi polami do postaci prostokatnej zeby moc ja scrolowac w pionie i poziomie.
a dlaczego tak?
bo chce tego izometra zrobic scrollowanego z $d016 i $d011
zrezygnowac z \"plastrow miodu\" , pajaczka dac na srodek a krawedzie scrolla zmaskowac rozciagnietym czarnym sprajtem.
- moze ekran bedzie 16x16 fontow - tego jeszcze nie wiem - widoczne i tak byloby tylko 15x15 bo przy scrollowaniu trzeba maskowac skrajne fonty zeby nie skakalo.
potrzebuje tylko narzedzia do wyciagniecia grafiki z Atari albo ZX Spectrum albo ludzi ktorzy sa oblatani w temacie i chcieliby pomoc.
Siedze z zeszytem i rysuje rozne mechanizmy, siedze i knuje...
64kB to nie duzo a i 16Kb na grafike sprjtow, mape koloru i generatory fontow + grafika pod plansza to niezbyt wiele.
Rozwazam katy nachylenia izometrii zeby jak najmniej pamieci zamazac i czy hires czy multi - co jest wazne z uwagi na to ze pajaczka chce zrobic na sprajtach i w hires tlo jest przezroczyste wiec trzba maske pod spodem z czarnych sprajtow robic co podwaja liczbe sprajtow na ekranie i kulki ani pszczoly nie beda juz mogly byc na sprajtach skoro pajaczek zajmie ich 8 szt...
Jesli by sie inaczej udalo to zrobic to:
Zamiast nakladac grafike na siebie pomyslalem ze mozna te elementy tla ktora zaslonia pajaczka narysowac na sprajtach w Hires (czarny jako maska i na nim bialy z grafika.
Na razie nic - tylko dumam - rysuje, zona sie mnie pyta co tam kresle...
zarysowalem juz sporo papieru i na razie nic nie rusze chyba bez grafiki.potrzebuje pomocy:
1. gif animowany pajaczka albo nawet png albo gif poszczegolnych klatek - moze byc binarka
2. mapy miast z Amaurote najlepiej w izometrii tak zeby klocki zrobic do plansz.
3. kogos z doswiadczeniem w programowaniu sztucznej inteligencji - chodzi o zaprogramowanie ruchu pszczol.
Czy ktos z Was uzywa KickAssemblera ?
a ze smieszniejszych rzeczy to: http://gok-wiazowna.pl/tmp/ew55/ew55/ew55.html
ojciec dziecka ktory nudzil sie na szkoleniu z obslugi komputera narysowal odrecznie na kartce papieru wycofany w 1995r. pociag EW55.
Ja go tylko troche poruszylem i jedzie
w nowszej wersji bedzie horyzont i trakcja
a moze stacje i drzewa
zobaczymy - zona mowi o kluczu zurawi - tego nie obiecuje
Wiadomość wysłana przez: Cobra of Samar w 03 Grudnia 2011, 18:44
| at0mic napisal: |
| Czy ktos z Was uzywa KickAssemblera ? |
Napisz do Zieloka lub Nitro, mnie w tej kwestii dal pare wskazowek.
Wiadomość wysłana przez: nes__ w 03 Grudnia 2011, 19:16
Z filmu wyglada ze jest robione jakies przepisywanie grafiki w rejonie ruszajacego sie obiektu tylko, bo 1) sypie sie to o calego fonta dalej nieraz, 2) widac ze procesor nie wyrabia i zlozonosc ruchu zalezy od ilosci grafiki do przerysowania
Rzeklbym nawet, ze na Atari sie ewidentnie sypie kolejnosc innych elementow, jak postac miedzy nie wchodzi. Czyli sa przerysowywane obiekty w miejscu gdzie jest postac, moze przerzucane na sprajty czesciowo albo cos. Biorac pod uwage ze to powoli chodzi (ile to ma, 10fps ?), mozna rozne triki zastosowac.
Obejrzyj dokladnie 10 nastepnych sekund od tego momentu:
http://www.youtube.com/watch?v=KM6tY3yQY_0&feature=player_detailpage#t=126s
Widac jak sie przeslanianie kaszani na 2:10 mniej wiecej.
Wydaje mi sie ze to jako bitmapa powinno byc, albo 2-3 zestawy fontow, i przerysowywane bajty w tym rejonie gdzie jest postac.
Czyli:
1) wszystkie obiekty bys musial miec jako osobne
2) napisac procedurke do rysowania obiektow na planszy zgodnie z mapa, z tych obiektow, i nia rysowac calosc przy wejsciu na dany ekran
3) w trakcie ruchu przerysowywac fragmenty w ktorych jest ruch, najlepiej by to bylo zoptymalizowac tylko do obszaru w ktorym jest postac (a nie cale obiekty), czyli procedurka by musiala wiedziec z czego sie sklada obraz w danym obszarze, i odrysowac to zgodnie z kolejnoscia
Wiadomość wysłana przez: at0mic__ w 03 Grudnia 2011, 21:00
- nie wiem czy to mozliwe jest ale chce sprawdzic. Najwyzej nie wyjdzie... Ale jak wyjdzie ?...
Wiadomość wysłana przez: nes__ w 03 Grudnia 2011, 21:08
Wiadomość wysłana przez: Nitro__ w 03 Grudnia 2011, 23:28
Wiadomość wysłana przez: nes__ w 04 Grudnia 2011, 18:10
| at0mic napisal: |
| i dlatego wrzucilem temat zeby sie iluzjonisci pozastanawiali czy to sie da zrobic. |
Nie da to sie tylko podobno porobic w stringi
Z 50fps to by bylo wyzwanie, a bez 50fps sie na pewno da.
Wiadomość wysłana przez: at0mic__ w 04 Grudnia 2011, 18:29
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 :P
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
Wiadomość wysłana przez: kotrobot__ w 04 Grudnia 2011, 19:00
http://noname.c64.org/csdb/release/?id=99722
_________________
W oparach cyny...
Wiadomość wysłana przez: at0mic__ w 04 Grudnia 2011, 21:27
komentarz mnie rozbroil, bo coz ze wolno chodzi:
\"Most C64-freaks are old... so slow is not so bad, eh?\"
![\"Very](\"images/smiles/icon_biggrin.gif\"){kind=icon}
_________________
At0mic
Wiadomość wysłana przez: nes__ w 09 Grudnia 2011, 12:09
_________________
\"A ile zrobisz pompek ?\" (c) 2o11 eLban
Wiadomość wysłana przez: BagoZonde w 15 Grudnia 2011, 11:31
. 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!
Wiadomość wysłana przez: bimber__ w 15 Grudnia 2011, 20:16
| BagoZonde napisal: |
| Gra zajmuje caly ekran wiec masakra. |
jesli ma to byc konwersja 1:1 z zx to niekoniecznie (rozdzielczosc spectrum = 256x192)
Wiadomość wysłana przez: BagoZonde w 16 Grudnia 2011, 18:55
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
.
Wiadomość wysłana przez: BagoZonde w 05 Stycznia 2012, 17:43
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
![\"Razz\"](\"images/smiles/icon_razz.gif\"){kind=icon}
.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: | | ![\"\"](\"images/icon_clip.gif\"){kind=icon} Pobierz | |
| :Nazwa zalacznika: | :AMAUROTE.rar | ||
| :Rozmiar: | :16.28 KB | ||
| :Pobran: | :Plik sciagnieto 41 raz(y) |
Wiadomość wysłana przez: Kisiel w 05 Stycznia 2012, 19:40
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...\"
Wiadomość wysłana przez: BagoZonde w 05 Stycznia 2012, 20:15
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
.
Wiadomość wysłana przez: BagoZonde w 05 Stycznia 2012, 20:35
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.
Wiadomość wysłana przez: Nitro__ w 05 Stycznia 2012, 23:30
Wiadomość wysłana przez: Skull w 06 Stycznia 2012, 09:33
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...
Wiadomość wysłana przez: nes__ w 08 Stycznia 2012, 16:02
_________________
\"A ile zrobisz pompek ?\" (c) 2o11 eLban
Wiadomość wysłana przez: BagoZonde w 09 Stycznia 2012, 12:38
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).
Wiadomość wysłana przez: nes__ w 05 Lutego 2012, 19:22
Wtedy sie okazuje, ze plan dzialania nie wystarcza.
Wiadomość wysłana przez: BagoZonde w 05 Lutego 2012, 20:17
.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.
Wiadomość wysłana przez: Skull w 06 Lutego 2012, 08:51
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.
Wiadomość wysłana przez: BagoZonde w 06 Lutego 2012, 09:12
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.
Wiadomość wysłana przez: Skull w 06 Lutego 2012, 11:35
Wiadomość wysłana przez: BagoZonde w 06 Lutego 2012, 11:42
. 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.
Wiadomość wysłana przez: Skull w 06 Lutego 2012, 11:55
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.
Wiadomość wysłana przez: nes__ w 07 Lutego 2012, 09:38
| 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\"
Wiadomość wysłana przez: BagoZonde w 07 Lutego 2012, 09:53
.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.
Wiadomość wysłana przez: brush__ w 10 Lutego 2012, 10:59
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
Wiadomość wysłana przez: BagoZonde w 29 Kwietnia 2012, 21:25
Wiadomość wysłana przez: BagoZonde w 29 Kwietnia 2012, 21:28
Wiadomość wysłana przez: Kisiel w 29 Kwietnia 2012, 21:37
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.
Wiadomość wysłana przez: BagoZonde w 29 Kwietnia 2012, 23:28
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.
Wiadomość wysłana przez: Kisiel w 29 Kwietnia 2012, 23:47
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;)
Wiadomość wysłana przez: BagoZonde w 30 Kwietnia 2012, 00:06
Co do SMART to powiem Ci tak: przez to, że chcę żeby był specyficzny - powstało to subforum, na którym chciałem i nadal będę chciał zbierać opinie na różne pomysły. Realizuję w tym właśnie jeden pomysł, który sprawił, że gra nabrała rumieńca. Ale też tym samym powiązanie tego wszystkiego w jedną całość stało się zadaniem złożonym. A z tym SMART-em jest tak, że właśnie przez ambicję i dodawanie nowych ficzersów (których w wersji bejzikowej nie było), zrobił się z tego SMAR stąd ten poślizg. Postanowiłem zrobić coś krótszego w międzyczasie i tyla ;).
Wiadomość wysłana przez: Kisiel w 30 Kwietnia 2012, 01:37
![\"\"](\"http://www.c64power.com/forum/img/smilies/grin.gif\" "\\"\\"")
Rok dla projektów hard to nie jest tak krótko, ale czasem jest to bardzo krótko .... powodzenia.
1.05.2013 deadline ... pasuje ?
Wiadomość wysłana przez: BagoZonde w 30 Kwietnia 2012, 09:01
Kisiel:
powodzeniaDzięki, przyda się.
Wiadomość wysłana przez: Skull w 01 Maja 2012, 09:27
, ale bardziej prawidłowa jest HSP (a znowu linecrunch to co innego, tu chodzi o przesuw w pionie- Linecrunch - Vertical Screen Positioning (znów skrót VSP)).
Tu masz przykład kodu HSP (przesuw poziomy):
http://codebase64.org/doku.php?id=base:horizontal_screen_positioning_hsp
a tu linecrunch (pionowy):
http://codebase64.org/doku.php?id=base:linecrunch
do scrolla w arma.. można połączyć oba te efekty.
i zaglądaj częściej pod ten adres codebase64.org (a przynajmniej powinieneś od dawna) bo jest tam dużo tego czego ciągle szukasz.
co do pisania gier, to żmudna robota, ja już też wymiękam, i zamiast kończenia bombermana - napisałem ostatnio to (piątek) :
http://noname.c64.org/csdb/release/?id=108298
a na pierniku dodałem w polskiej wersji:
http://noname.c64.org/csdb/release/?id=108415
Wiadomość wysłana przez: BagoZonde w 09 Maja 2012, 23:43
. Jak na razie skontaktowałem się z kolesiem z Niemiec, który podziela mój entuzjazm, wysłał mi trochę kodu, który zmajstrował więc będziemy to analizować . Jednym słowem super .
Wiadomość wysłana przez: StaryMarabut w 10 Maja 2012, 00:00
Zobaczę na emu jak to lata.
Wiadomość wysłana przez: Skull w 10 Maja 2012, 12:37
http://codebase64.org/doku.php?id=base:agsp_any_given_screen_position
czyli to czego szukamy, i z ciekawości przykleiłem sobie do edytora, kilka poprawek na compilator który używam i dołączam wynik w pliku
http://c64power.com/forum/uploads/files/agsp_.zip
możesz sobie sprawdzić jak to działa - scrollowanie joystickiem, dodałem też źródłówkę.
ale już widać pierwsze mankamenty:
- trzeba odpowiednio dopisywać grafikę, bo nie pojawia się ona dokładnie w miejscu którym wychodzi, ale to kwestia kodu
- wszystko ma jednak ograniczony zasięg (ok 2x2 bitmapy), nie znam amaurote ale to może być za mało.
szkoda - bo jak widać sam scroll zajmuje niewiele (widać to po kolorach rastra).
Wiadomość wysłana przez: Kisiel w 10 Maja 2012, 12:46
Wiadomość wysłana przez: BagoZonde w 20 Maja 2012, 01:06
Widziałeś to Skull? To nie Ty zrobiłeś to video? ;)
http://www.youtube.com/watch?v=rHhNgvF1Kho&feature=youtu.be
Wiadomość wysłana przez: Skull w 21 Maja 2012, 08:35
Wiadomość wysłana przez: BagoZonde w 21 Maja 2012, 10:54
No właśnie, fajnie ;). Będziesz temat kontynuował? Oczywiście temat Bombermana mam nadzieję, że zawiesiłeś na chwilę ;).
Dzięki za VSP, będę to obczajał na dniach.
Wiadomość wysłana przez: Skull w 23 Maja 2012, 09:47