atarionline.pl His Dark Majesty - Forum Atarum

Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

  • :
  • :

Vanilla 1.1.4 jest produktem Lussumo. Więcej informacji: Dokumentacja, Forum.

    • 1: CommentAuthorilmenit
    • CommentTime30 Jun 2009
     
    Hej,

    Informowałem już na atari area, ale wrzucę info i tutaj.

    Jakiś czas temu pisałem, że pracuję nad 8bitowym RPGiem ("Mini-Crawl", który ostatecznie stał się "Wiedźminem") . Projekt w wolnych chwilach powstaje, ale gra nie jest tak grywalna, jak bym chciał...
    Dlatego czekając na inspirację tymczasowo go wstrzymałem i prezentuję wersję roboczą innej gry, którą piszę na małe Atari.
    "His Dark Majesty" to gra pisana w C (CC65+asm). Jest to turowa strategia taktyczna typu "Advance Wars", czyli dwie strony konfliktu wyrzynają się na mapie 2D.

    Co jest zrobione? Zrobiony jest właściwie cały "silnik" i większość sztucznej inteligencji. Przy ocenie sytuacji przez AI nie uwzględniane są jedynie specjalne cechy jednostek (typu "first strike"). Do dodania są również jednostki specjalne np. magowie. Aktualnie pracuję nad innymi rodzajami wygranych np. zabicie specjalnej jednostki, przetrwanie ileś tur itp. co wzbogaci kampanię, a musi być uwzględnione przez AI.

    Demo to plik wykonywalny dla Windows, który działa w trybie tekstowym. Docelowo chciałbym mieć jednak grafikę w stylu: ->link<-
    A może jeszcze ładniejszą (VBXE)? :)

    Binarki przekompilowane ze sterowaniem myszką oraz klawiaturą (dla poczucia tego, jak by sterowanie wyglądało z joystickiem) wrzuciłem na ->link<-

    Podobnie jak w przypadku Wiedźmina - szukam chętnych do współtworzenia. Mogę zająć się silnikiem gry, ale na pewno przydałaby się osoba znająca się na programowaniu grafiki czy dźwięku.

    Widząc zamiłowanie do tworzenia plansz do Robbo w najnowszej wersji dodałem edytor map. Dzięki temu każdy może zostać współautorem gry, zaś najciekawsze mapy dołączę do kampanii.
    • 2:
       
      CommentAuthorKaz
    • CommentTime30 Jun 2009
     
    Mam pytanie: czy moglbys ta mniej skomplikowana wersje "Wiedzmina" wypuscic pod pierwotna nazwa? Taka powiedzmy beta-wersja "Wiedzmina", do zapoznania sie ze swiatem. Przyznam, ze chodzi mi o to, zeby wykorzystac projekt graficzny, ktory wymyslilem - zarowno do ekranu tytulowego jak i do gry. Wiesz, zaden autor nie lubi, gdy jego praca idzie na marne :)

    Jezeli chodzi o "His Dark Majesty" to wyglada to na sporo roboty (mowie o grafice). Czy na Atari ma to byc tryb kolorowy (5 kolorow)? Czy szacowales juz zajetosc pamieci na malym Atari, zeby bylo wiadomo, ile tej grafiki moze sie zmiescic?
    • 3: CommentAuthormarok
    • CommentTime30 Jun 2009
     
    ilmenit: jesli zadna profesjonalna pomoc sie nie znajdzie, to oferuje sie na ograniczonego wiedza konsultanta nizszej rangi w dziedzinie "programowania grafiki czy dźwięku" i drobnego pomocnika.

    Wyobrazam sobie ze moglbym pomoc troche w kodzie maszynowym i posiadam ogolna (ale raczej na niskim poziomie) orientacje w dziedzinie specyfiki atari (chodzi mi tutaj o programowanie antic'a i pokey'a).

    Tylko jak napisalem, pewnie przydalby sie ktos z wiekszym doswiadczeniem, wiedza i sprawniejszy (intelektualnie ;). Dlatego ta moja oferta jest dosc asekuracyjna.
    • 4: CommentAuthorilmenit
    • CommentTime30 Jun 2009
     
    @Kaz
    Na wypuszczenie pierwotnej wersji gry szanse są małe. Mam co prawda stare źródła, ale przy pracy nad Wiedźminem bardzo dużo zmieniłem i zoptymalizowałem. Przerabianie zaś nowych do starego projektu byłoby stratą czasu, jeżeli by to miała pozostać beta.
    Projektując HDM (tytuł roboczy) mogłem wybrać dowolny "motyw" - sci-fi, 2 wojna światowa, mitologia, średniowiecze albo też świat fantasy. Właśnie pamięć o Twoim rysunku spowodowała, że wybrałem świat fantasy i taki tytuł. Nadawałby się na ekran tytułowy :)
    @marok
    Byłbyś w stanie zrobić GUI mapy w stylu gry Shiloh? ( ->link<- ).
    W przypadku okna tekstowego na dole pozostaje 160*160 pikseli na mapę. Podobnie jak w Shilohu można użyć kafelków kwadratowych 8*16. Maksymalną liczbę kafelków grafiki określiłbym na 32.
    • 5:
       
      CommentAuthorKaz
    • CommentTime30 Jun 2009
     
    To nie bardzo rozumiem, szczerze powiedziawszy. "Dungeon Crawl Mini" po rozbudowaniu zamienil sie w "Wiedzmina", z kolei piszesz, ze chcesz moj obrazek do "Dungeon..." zastosowac do gry "His Dark Majesty" (tytul fajny, mnie sie podoba). Czyli, ze "Wiedzmin" to bedzie cos innego, a mam kontynuowac prace graficzne do "His Dark Majesty"? :)

    Tylko, ze "HDM", jak napisales, ma byc kolorowy, wiec obrazek tytulowy bedzie troche taki nie-za-bardzo-zgrany z reszta. Chyba, ze to tez ma byc na Atari tryb hi-res, ale z podkolorowaniem duszkami?

    Czy ograniczenie do 32 kafelkow wymuszone jest dostepna pamiecia czy kwestia ilosci znakow w wierszu?
    • 6: CommentAuthormarok
    • CommentTime1 Jul 2009
     
    ilmenit: Nie wiem czy bym potrafil wykonac to o co mnie zapytales.
    Zastanowilo mnie jednak, czy nie chcialbys zaakceptowac, a wczesniej rozwazyc, koncepcji grafiki przystosowanej do wykorzystania tzw. efektu 460 linii, o ile to byloby rzeczywiscie mozliwe do uzyskania i zastosowania.
    Na forum atariarea przetoczyla sie niedawno temu dyskusja na temat takiego softwarowego wywolania niejako podwojonej rozdzielczosci w pionie. Przyznaje ze sam slabo zorientowalem sie we wszelkich aspektach tej nowej techniki programowego poszerzenia mozliwosci graficznych atari, ale wydalo mi sie wlasciwe zasygnalizowac Tobie ze takie cos realnie zaistnialo (o ile sam nie zwrociles na to uwagi).
    Sam bowiem dales wyraz pewnej otwartosci na nowe rozwiazania w tym wzgledzie, sugerujac, ze mozliwe jest przystosowanie grafiki gry do VBXE.
    Ta technika o ktorej wspominam nie koliduje z VBXE, a moze w jakims stopniu ja zastepowac czy uzupelniac.
    • 7: CommentAuthorilmenit
    • CommentTime1 Jul 2009
     
    @Kaz
    Tak, grafika w HDM będzie kolorowa. Nie widzę jednak powodu, dlaczego obrazek tytułowy nie miałby być czarno-biały. Jest bardzo klimatyczny, a pasuje znacznie bardziej niż do Wiedźmina.
    32 kafelki to przewidywane dwadzieścia kilka jednostek i kilka rodzajów terenu.
    @marok
    Czemu nie :) Byłaby to pierwsza gra, wykorzystująca ten tryb. Ale żeby go użyć musiałbym mieć pewność, że na prawdziwym Atari nie mruga (może ktoś potwierdzić?) Jeżeli jest tak dobrze jak w testowym buildzie Atari++, to jestem za.
    • 8:
       
      CommentAuthorKaz
    • CommentTime1 Jul 2009
     
    Ilmenit - no to let's go :)
    • 9: CommentAuthorilmenit
    • CommentTime2 Jul 2009 zmieniony
     
    Ponieważ 480i mruga i na dłuższą metę do gry się nie nadaje, zastosowałem gr. 12. Dla tego trybu narysowałem podstawowy zestaw kafelków w Font Mejkerze i proszę o komentarz, czy jest czytelny. Dla chętnych do obejrzenia/poprawienia jest tutaj ->link<-

    W gr. 12 używam też konsoli tekstowej i muszę dynamicznie zmienić zestaw fontów na standardowy. Nigdy nie bawiłem się display-listami - czy mógłby ktoś rzucić przykład kodu, który coś takiego robi?
    • 10:
       
      CommentAuthorKaz
    • CommentTime2 Jul 2009
     
    Rzuc okiem na "Komputer" numer 8/1986, ktory wczoraj dolaczony zostal do biblioteki - tam jest artykul Krzysztofa Bednarka pod tytulem "Atari Display List". Moze pomoze.
    • 11: CommentAuthormarok
    • CommentTime2 Jul 2009
     
    Ilmenit: Moim zdaniem czytelne na tyle ile moze byc w takim trybie. Ale grafika bardzo staranna.

    Krotko na temat 480i. Szczerze mowiac zobaczylem to jak to wyglada po raz pierwszy na emulatorze dopiero po tym jak napisalem o tym trybie w tym watku. Spodziewalem sie stabilniejszego obrazu, a to co zobaczylem takze mnie rozczarowalo. Przepraszam za wpuszczenie w tzw. maliny.

    Z dlistami pewnie ktos kompetentniejszy jasniej i precyzyjniej to opisze, ale moge powiedziec juz teraz, ze mozna to zrobic poprzez wywolanie przerwania dlist.
    Standardowo przerwanie dlist jest nieuzywane i wylaczone przez system. Aby go uzyc trzeba zaladowac do rejestru DMACTL ($D400) wartosc #$C0 (najstarszy bit odpowiada wlasnie przerwaniu dlist, a bit 6. przerwaniu VBLANK), normalnie do DMACTL wpisuje sie wartosc #$40 (oznacza tylko wlaczony VBLANK). Pamietac trzeba jednak ze VBLANK zapisuje do tego rejestru wartosc pobrana z tzw. rejestru cienia $22f (o ile przerwania maskowalne nie sa wylaczone). Inaczej mowiac odtwarza wartosc rejestru kazdorazowo po zakonczeniu kreslenia obrazu.

    Aby uzyskac to o co pytasz trzeba do wektora (slowa) pod adresem $200 wpisac (BE) adres procedury realizujacej przerwanie dlist oraz ustawic najstarszy bit w rozkazie antic'a generujacym linie grafiki od ktorej ma zaczac sie zmiana lub chyba lepiej w rozkazie generujacym linie wczesniejsza (moze to byc rozkaz generujacy pusta linie).
    Wiec jesli generujesz linie $0c grafiki to jesli ten rozkaz ma wywolac przerwanie dlisty musisz go zamienic na $8c, itd.

    W Twoim wypadku (na teraz) prawdopodobnie wystarczy cos takiego:

    inicjacja przerwania dlist
    lda <dlist
    sta $200
    lda >dlist
    sta $201
    lda #$c0
    sta $22f


    przerwanie dlist
    dlist
    pha
    lda >adres_zestawu_fontow ;$e0 (?)
    sta $d409
    pla
    rti
    • 12: CommentAuthorilmenit
    • CommentTime6 Jul 2009 zmieniony
     
    Dzięki marok, działa ->link<-
    (zamiast do $22f zapisałem $C0 do $D40E).
    Teraz czas na scrollowanie mapy :)
    • 13: CommentAuthormarok
    • CommentTime6 Jul 2009 zmieniony
     
    Przesuwac mape (pole gry jak rozumiem) mozna plynnie i skosowo (o dlugosc znaku).
    Ten pierwszy sposob wymaga ustawienia bitow (5 i 4) rozkazow dlisty generujacych linie graficzne oraz zapisywania wartosci przesuniecia w pikselach zawartosci tych linii od stanu normalnego (bez przesuniecia) do specjalistycznych rejestow antic'a ($d404 i 5).

    Tu sa dwa linki z ktorych skorzystalem, aby sie nie pomylic podajac szczegoly:
    ->link<-
    ->link<-

    Tym pierwszym sposobem mozna przesunac sie w obrebie jednego znaku w prawo i dol.

    Aby przesunac sie w liczbie znakow, trzeba manipulowac adresami zapisanymi w dlist.
    Jesli wiec pole gry ma byc scrollowane, to kazdy rozkaz dlisty generujacy linie takiej grafiki powinien ustawiac nowa wartosc adresu (poniewaz potencjalnie linia mapy moze wyswietlac dane pobierane z calego obszaru przypisanej jej pamieci - wiekszego niz jednoczesnie jest w stanie wyswietlic, powoduje to ze dostep do tego adresu jest niezbedny), od ktorego bedzie pobieral dane do wyswietlenia.

    Jesli np. mapa ma obejmowac 64 znaki w poziomie, a jednoczesnie wyswietlanych moze ich byc jedynie 16, to mozliwe ustawienie takiego adresu jest na 48 (64-16) sposobow.

    Wszystie adresy w dlist musza byc o tyle samo przesuniete w poziomie i pionie od swojego minima, aby przesuniecie calej mapy bylo spojne.

    Przykladowa dlist:
    dlist b($70,$70,$70),b($44),a(linia)
    linia1 equ *-2
    dta b($44),a(linia+64),[..]b($44),a(linia+19*64),b($41),a(dlist)

    Jak zmieniac adresy dla tej dlist (linia = $xx00+%xx00 0000):

    ldx #20*3
    loop lda linia1-3,x
    ora przesuniecie ; <0,63-16>
    sta linia1-3,x
    dex
    dex
    dex
    bne loop

    • 14: CommentAuthorilmenit
    • CommentTime6 Jul 2009
     
    Nie tak prosto :) Będzie musiało być inaczej, ponieważ mapa i jej wizualizacja nie są sobie równoważne.
    Jeden obiekt na mapie jest reprezentowany przez 2x2 znaki (w gr. 12), więc będę potrzebował niezależnego okna wypełnianego odpowiednimi znakami podczas "przesuwu". Dodatkowo to okno będzie musiało być większe o 2 znaki, aby wykorzystać HSCROLL i VSCROLL. Na przykład dla scrolla w prawo-dół:
    XXXX12
    XXXX12
    XXXX12
    111112
    222222

    Nie wiem, czy z przygotowaniem tego okna zmieszczę się w VBLANK, więc chyba od razu zrobię buforowanie... Czyli kod się bardzo komplikuje.
    Albo mogę też olać zajętość pamięci i trzymać w niej całą mapę 2x2. To by znacznie uprościło sprawę i mógłbym użyć metody, którą podałeś.
    Dla mapy 40x20 (800 bajtów) zabrałoby to dodatkowo 3kb. Hm...
    Chyba pierwszą wersję zrobię właśnie w ten sposób...
    • 15: CommentAuthormarok
    • CommentTime7 Jul 2009
     
    Istotnie zle przemyslalem wlasciwosci mapy i wizualnej prezentacji jej fragmentu.
    Ten sposob na prezentacje mapy ktory podalem (malo wyszukany) ma jeszcze ta zasadnicza wade, ze nie nadaje sie przy koniecznosci nakladania na siebie map jednostek i terenu.

    Przypomnialem sobie pewien tekst w TA, ktory traktuje o trybie 4 antic'a i sposobie prezentacji przy jego pomocy znakow o podwojonej szerokosci i dlugosci.
    Znalazlem go i wklejam caly fragment:

    "Na pewno niejeden z czytelników zastanawiał się, w jaki sposób uzyskać dużą ilość grafiki na ekranie. Do tworzenia jej najlepiej użyć trybu $04 ANTIC'a, ze względu na dostępną ilość kolorów, rozdzielczość i ilość potrzebnej pamięci. Normalnie w tym trybie mamy do dyspozycji 128 znaków o wymiarach 4*8 punktów, lecz na pewno każdy zauważył, że w większości gier wydanych przez L.K.Avalon elementy graficzne są dwukrotnie szersze i wyższe (najlepiej widać to chyba na przykładzie ROBBO). Efekt taki możemy uzyskać używając dwóch zestawów znaków naprzemiennie włączanych w każdej linii ekranu oraz wyświetlając w dwóch sąsiednich liniach takie same dane. Pierwszy zestaw powinien zawierać definicje górnych, a drugi dolnych połówek znaków. Dla lepszego zrozumienia proszę się przyjrzeć, jak zrobione to jest w naszym przykładzie. Wyjaśniłem już podwójną wysokość, natomiast podwójną szerokość uzyskuje się po prostu przez wyświetlenie obok siebie dwóch sąsiednich znaków (np. 0 i 1). Używając tej metody mamy do dyspozycji 64 znaki o wymiarach 8*16 punktów."
    zrodlo: ->link<-

    Nawet jesli zapotrzebowanie na liczbe znakow jest mniejsze, to najprawdopodobniej znacznie latwiej bedzie zaprojektowac kod nanoszacy dane z map do pamieci ekranu (wizualizacje).
    • 16: CommentAuthorilmenit
    • CommentTime7 Jul 2009
     
    Bardzo dobry pomysł z dwoma zestawami znaków :)
    Aktualnie potrzebuję i wykorzystuję 32 znaki, czyli ile jest dostępne w pojedynczym zestawie. Ale kto wie, jeżeli pamięci wystarczy, to może dodam jednostki specjalne. Chciałbym, żeby całość chodziła w 64kb.
    • 17: CommentAuthorilmenit
    • CommentTime7 Jul 2009 zmieniony
     
    Skompilowałem w końcu wersję dla Atari, choć jeszcze bez GUI. Na razie gra przebiega w sposób niewidoczny (komputer vs komputer), zaś na konsolę wypisywane są jedynie komunikaty co się dzieje.
    Ta kompilacja miała na celu sprawdzenie szybkości i wielkości pliku wynikowego. Wielkość - jest całkiem nieźle, bo 19kb.
    Gorzej z szybkością - AI pojedynczej jednostki zabiera od 3 do 10 sekund, co przy 30 jednostkach komputera daje około 2-3 minuty na turę.
    Nie różni się to od czasu, który poświęca gracz na przesunięcie swoich jednostek, ale warto by obliczenia przyspieszyć.
    A przyspieszyć da radę bardzo, co widzę po użyciu mojego profilera - gorąco polecam piszącym w CC65.

    Dla lubiących oglądać pojawiające się komunikaty: ->link<-

    EDIT:
    Przygotowałem też drugie demo. Display list w gr.0 jest ustawiony na początek danych mapy gry. Dzięki temu widać co robią jednostki poszczególnych graczy. Wszystkie jednostki gracza tu wyglądają tak samo, ponieważ na mapie mają taki sam ustawiony bit.
    ->link<-
    Tu już widać, że silnik działający pod Windows i na Atari zachowują się identycznie.
    • 18: CommentAuthorilmenit
    • CommentTime9 Jul 2009 zmieniony
     
    Spamowania wątku ciąg dalszy, czyli nocny progress :)
    Przygotowałem małe demo z wizualizacją. Scrollowania jeszcze brak, podobnie jak optymalizacji. Dlatego też demo najlepiej uruchomić w emulatorze na Full speed ;)
    ->link<-
    • 19:
       
      CommentAuthorKaz
    • CommentTime9 Jul 2009
     
    Robi wrazenie! Czy graficznie tak ma byc, ze postacie sa w czarnych kwadratach czy ten element gry mozna zasugerowac inny?
    • 20: CommentAuthorilmenit
    • CommentTime9 Jul 2009 zmieniony
     
    Jak najbardziej można zasugerować inny. Kafelki robiłem "na szybko", bo potrzebowałem czegoś do wyświetlenia :)
    W powyższym archiwum znajdują się pliki dla Font Makera ( ->link<- )
    Docelowo będę wykorzystywał dwa zestawy znaków, ponieważ muszę jakoś oznaczyć jednostki, które się już ruszyły. Planem było pokryć je szachownicą czarnych pikseli.

    Po powrocie wracam do pracy nad GUI, czyli scrollowanie, obsługa joy'a, kursor zapewne P-M oraz podświetlanie możliwych miejsc, na które można się ruszyć/zaatakować (też pewnie P-M).
    W innym trybie lub z inną paletą planuję też dodać poniżej i ponad polem walki paski ozdabiające, w stylu złoto-niebieskich z Dune 2:

    Ale i tak najlepiej, gdyby wziął to na siebie jakiś grafik... :)

    Rano wyjeżdżam na kilka dni i wracam w niedzielę wieczorem, tak więc proszę o wybaczenie długiego nieodpisywania.
    • 21:
       
      CommentAuthorKaz
    • CommentTime10 Jul 2009
     
    Mam nadzieje ze okreslenie "W stylu" nie oznacza "takie same" - bo te paski sa troche... hmmm.... :)

    Pytania odnosnie pliku z demem gry:
    1. Czy powierzchnia jest zawsze zolta? Czy sa tez inne rodzaje (i kolory) tla?
    2. Co symbolizuja te parasolki?
    • 22: CommentAuthorirwin
    • CommentTime12 Jul 2009
     
    odp.2 to nie parasolki a łuki/kusze i symbolizują zapewne łuczników/kuszników.
    • 23:
       
      CommentAuthorKaz
    • CommentTime12 Jul 2009
     
    Tez tak mysle, ale inne rodzaje wojsk sa oznaczone ludzikami, wiec wole sie upewnic.
    • 24: CommentAuthorilmenit
    • CommentTime12 Jul 2009
     
    I już jestem.
    1. Zawsze zółta, choć paleta może zostać zmodyfikowana, jeżeli potencjalny grafik uzna, że dobierze ładniejszą.
    2. Parasolki jak słusznie zauważył irwin reprezentują kuszników. Nie udało mi się zrobić ich lepszej reprezentacji, a zacząłem początkowo właśnie od takich symboli.

    Paski - znaczy tandetne? :) Może trochę... :)
    • 25:
       
      CommentAuthorKaz
    • CommentTime12 Jul 2009
     
    Nie, ze tandetne, ale nie pasujace, oczywiscie moim zdaniem, do takiej gry. Bo niby co reprezentuja? :)
    • 26: CommentAuthorilmenit
    • CommentTime12 Jul 2009
     
    Nic, ozdoba jedynie, która uczyni małokolorowy ekran bardziej kolorowym. Taki niecny plan miałem, ale chyba to rzeczywiście bez sensu :)
    • 27:
       
      CommentAuthorKaz
    • CommentTime12 Jul 2009
     
    Tak, ale takie wzorki przynosza (mi) skojarzenia raczej z bizantyzmem, przepychem, a nie surowoscia, drapieznoscia czy ciemnoscia, ktorej wymaga gra "His Dark Majesty" :). W kazdym razie to tylko taka drobna uwaga.

    Mam za to inne pytanie: czy przewidujesz wykorzystanie na ekranie duszkow?
    • 28: CommentAuthorilmenit
    • CommentTime12 Jul 2009
     
    Tak, jako kursor i do podświetlenia możliwych pół dla ruchu lub ataku.
    • 29: CommentAuthorilmenit
    • CommentTime12 Jul 2009
     
    Jeszcze odpowiadając na poprzednie pytanie odnośnie żółtości terenu: to był przykład kafelków zrobionych przeze mnie, czyli kogoś o minimalnych uzdolnieniach graficznych.
    Jeżeli grafika ładniej by wyglądała na czarnym tle, jak jest w większości gier turowych na Atari, to nie mam nic przeciwko temu.
    • 30:
       
      CommentAuthorKaz
    • CommentTime13 Jul 2009
     
    Hmm... ciekawy pomysl. Juz wczesniej bawilem sie tymi elementami, ktore zrobiles, ale zobacze tez warianty z czarnym tlem.

    Wracajac do tematu duszkow - wynika z tego, ze nie zuzyjesz wszystkich. Mozna by wiec pomyslec o przykryciu prawej i lewej ramki duszkami (jak w "Robbo"), tak by jeszcze jeden niezalezny kolor byl dostepny dla pola gry. W ten sposob mamy wszystkie 5 kolorow do dyspozycji, a ramka moze byc w innym kolorze (np. czarnym).
    • 31: CommentAuthorilmenit
    • CommentTime13 Jul 2009
     
    Jak to liczysz? Duszek ma 8 punktów. Przy poczwórnej szerokości daje to 32 punkty. Ekran ma 160/32=5 duszków do podświetlenia całego.
    Właściwie to i tak muszę użyć narrow playfield, bo będę potrzebował oprócz podświetlenia całego ekranu piątego duszka na kursor, aby był widoczny przy podświetleniu.
    • 32:
       
      CommentAuthorKaz
    • CommentTime13 Jul 2009 zmieniony
     
    Nie chodzi o podswietlanie ekranu z gra, tylko ramki po jego prawej i lewej stronie (dwa duszki poczwornej szerokosci). Dzieki temu wszystkie 5 kolorow w ekranie gry sa niezalezne od kolorow ramki. Optycznie zyskujesz jeden dodatkowy kolor - kolor ramki inny niz wszystkie pozostale na ekranie. W ten sposob masz np. 5 odcieni koloru pola gry, a ramke czarna.

    Zostaja Ci dwa duszki i cztery pociski.
    • 33: CommentAuthorilmenit
    • CommentTime13 Jul 2009 zmieniony
     
    Ok, rozumiem. Właśnie programuję duszki i niestety będę potrzebował je wszystkie.
    Sprawdziłem jednak jak ekran przy zastosowaniu ramki niebieskiej:

    Nie wygląda źle, a może ze względu na podświetlanie duszkami trzeba będzie tak pozostawić...
    Duszki fajna sprawa. Już widzę, że wykorzystam je też do zrobienia "efektów" w grze, takich jak ataki np. atak maga jako uderzenie pioruna, atak łucznika czy kusznika jako wystrzelenie pocisku. Mogłoby to przypominać efekty czarów z gry Feud.
    BTW, dzięki prostej optymalizacji udało mi się przyspieszyć silnik o około 35%. Tura komputera trwa teraz znacznie krócej.
    • 34: CommentAuthormarok
    • CommentTime13 Jul 2009
     
    W sprawie plynnego scrollingu.

    Napisalo mi sie nieprawde w kwestii scrollingu uzyskiwanego droga wykorzystywania specjalnych rejestrow HSCROLL i VSCROLL Antic'a.

    Sprawdzilem pod emulatorem jak to sie ma do rzeczywistosci i wydaje mi sie, ze:

    Tylko mlodszy nibble wartosci wstawianej do obu rejestrow ma znaczenie.

    Zapis w HSCROLL okresla o ile jednostek (liczonych w cyklach koloru, ktory odpowiada 1 pikselowi 15-ki czy 4-ki lub dwum 8-ki) ma zostac opoznione, tak to interpretuje, odwzorowanie zawartosci pamieci w stosunku do adresu przypadajacego na dana linie graficzna (podanego wprost w dlist lub automatycznie naliczonego). Objawia sie to przesunieciem interpretacji graficznej w lewo.
    Przy czym im wieksza wartosc zapisana do tego rejestru tym mniejsza liczba jednostek tego opoznienia (od 1 dla wartosci xf do 16, czyli 4 znakow w trybie znakowym, dla x0).
    Wyglada wiec na to, ze w kazdej sytuacji co najmniej 1 cykl koloru jest niewidoczny na ekranie z zakresu odwzorowywanej pamieci w danej linii.

    Znaczenie wpisu w VSCROLL rozni sie i jest bardziej skomplikowane. Wyroznilbym dwa zakresy wartosci: od x0 do x7 i od x8 do xf. Dla pierwszego z nich wartosc zapisana do rejestru okresla opoznienie w odwzorowaniu zawartosci pamieci liczona w calych liniach grafiki. Czyli cala zawartosc wyswietlanej grafiki przesuwa sie w gore. W odroznieniu od siostrzanego rejestru, ten okresla opoznienie tym wieksze im wieksza jest wartosc zapisana do tego rejestru, a dodatkowo wartosc najnizsza opoznienia (x0) oznacza jego brak.
    Drugi zakres od x8 do xf oznacza, ze wyswietlana grafika przesunieta jest w dol w zakresie od 1 (xf) do 8 (x8) linii. Efektem ubocznym jest powtorzenie odwzorowania na samej gorze ekranu tej samej pamieci odpowiadajacej liczbie linii przesuniecia w dol. Przy czym pierwsze dwie linie sa niewidoczne.

    Obok tego, wazne jest to, ze ustawienie bitu 4 (+$10) w rozkazie dlist generujacym linie grafiki powoduje iz adres naliczany automatycznie dla kolejnej wyswietlanej linii grafiki (kiedy nie jest on podawany wprost) jest o 8 bajtow wiekszy niz bez ustawienia tego bitu. Tym samym ostatnie 4 bajty przypadajace na linie grafiki, przy automatycznym naliczaniu adresu dla kolejnej, nie sa odwzorowywane przy kazdym z mozliwych wariantow wpisu do rejestru HSCROLL.

    Opis ten moze nie jest specjalnie czytelny, ale mam nadzieje, ze dla kogos kto sie wglebia w temat moze okazac sie nieco pomocny. W kazdym razie wypadalo mi skorygowac wczesniejsze wlasne twierdzenia. Mam nadzieje, ze zawarte w powyzszym opisie sa zasadniczo oddajace wiernie rzeczywisty stan rzeczy.
    • 35: CommentAuthorilmenit
    • CommentTime17 Jul 2009
     
    Na razie siedzę nad rozbudową silnika i płynny scroll czeka w kolejce.
    Marok, może masz ochotę napisać kilka procedurek w ASMie do obsługi duszków? Nic skomplikowanego, a pomoc znacznie przyspieszy tworzenie :)
    • 36: CommentAuthormarok
    • CommentTime17 Jul 2009
     
    Nigdy sie duszkami nie zajmowalem, ale moge poprobowac. To konkretnie co te procedurki maja robic?
    • 37: CommentAuthorilmenit
    • CommentTime19 Jul 2009
     
    W najprostszej postaci chodzi o przepisanie do ASMa poniższej procedurki:
    byte highlight_mask[4]={0xC0,0x30, 0xC, 0x3};
    void highlight_map(byte x,byte y)
    {
    register word i;
    register byte line;
    // Choose the proper sprite (PMBASE = &sprites)
    i=x/4;
    i*=0x80;
    // 0x200 - first sprite
    i+=0x200;
    i+=16; // top of the map on the screen
    i+=y*8;
    for (line=0;line<8;++line)
    POKE(&sprites+i+line,PEEK(&sprites+i)|highlight_mask[x%4]);
    }
    • 38: CommentAuthormarok
    • CommentTime19 Jul 2009
     
    Nie wiem czy wlasciwie rozszyfrowuje ten kod w C.
    Ponizej pierwsza proba zapisania powyzszego w asmie. Nie sprawdzalem czy dziala.

    i	equ $80

    lda x
    :2 lsr @
    sta i
    lda y
    :3 asl @
    adc i
    adc #16+7
    tay
    lda x
    and #3
    tax
    lda highlight_mask,x
    sta spr+1
    ldx #7
    spr lda #$c0
    ora sprites+$200,y
    sta sprites+$200,y
    dey
    dex
    bpl spr

    • 39: CommentAuthormono
    • CommentTime20 Jul 2009 zmieniony
     
    Zdaje się, że brakuje jeszcze i*=0x80.
    Można też zabazować na tym, że pełny chunk 2x8 ma identyczną zawartość i skrócić pętlę.
    Jeśli x=[0..4*4-1] (bo zdaje się wykorzystujesz tylko playery) i y=[0..16-1] (bo zdaje się masz podwójną rozdzielczość) to kod może wyglądać tak:
    ;.X=x, .Y=y, spr=Z
    txa
    lsr @
    lsr @
    lsr @
    pha
    php
    tya
    asl @
    asl @
    asl @
    adc #16
    plp
    bcc *+4
    adc #$80-1
    sta spr
    pla
    adc #>sprities+$200
    sta spr+1
    txa
    and #%11
    tax
    lda highlight_mask,x
    ldy #8-1
    ora (spr),y
    mark equ *
    sta (spr),y
    dey
    bpl mark

    Jeśli zajdzie potrzeba wykorzystania również missiles (traktujemy je tylko logicznie, jako 5 playera - nie musisz go łączyć w 5 playera), to kod zmieni się tylko nieznacznie w jednym miejscu (x=[0..4*5-1]):
    adc #>sprities+$180

    Pozycje sprajtów muszą być oczywiście odpowiednio ustawione.

    Edit: Można jeszcze uprościć fragment
    php
    tya
    asl @
    asl @
    asl @
    adc #16
    plp
    bcc *+4
    adc #$80-1

    zastępując go
    tya
    bcc *+4
    ora #%10000
    asl @
    asl @
    asl @
    adc #16

    oszczędność leży w php/plp, które jest niepotrzebne (zakładając, że y=[0..15]).
    Mamy więc ostatecznie:
    ;.X=x, .Y=y, spr=Z
    txa
    lsr @
    lsr @
    lsr @
    pha
    tya
    bcc *+4
    ora #%10000
    asl @
    asl @
    asl @
    adc #16
    sta spr
    pla
    adc #>sprities+$200
    sta spr+1
    txa
    and #%11
    tax
    lda highlight_mask,x
    ldy #8-1
    ora (spr),y
    sta (spr),y
    dey
    bpl *-3
    • 40: CommentAuthormarok
    • CommentTime20 Jul 2009 zmieniony
     
    "Zdaje się, że brakuje jeszcze i*=0x80."
    Istotnie. Zle doczytalem w opisie jezyka C znaczenie podobnych zapisow. Stad moje "i equ $80" (traktowane jako rownowaznik wskaznika). A cala procka nie dziala tak jak powinna. Zle obchodzi sie z rezultatem dzialania x/4.

    "Można też zabazować na tym, że pełny chunk 2x8 ma identyczną zawartość i skrócić pętlę."
    Tutaj duze brawa za spostrzegawczosc i zdrowy rozsadek. Zaimplementowanie tego bardzo rzecz przyspiesza.

    Nie jestem pewien czy wersja procedury ponizej dziala juz poprawnie, ale jesli tak, to moze warta jest rozwazenia (alternatywa dla zaproponowanej przez mono).

    lda >sprites+$200/2
    sta spr+1
    lda x
    and #18
    asl @
    ora y
    :3 asl @
    rol spr+1
    adc #16
    sta spr
    lda x
    and #3
    tax
    lda highlight_mask,x
    ldy #7
    ora (spr),y
    lspr
    sta (spr),y
    dey
    bpl lspr

    EDIT: usunalem zbedna instrukcje tax
    • 41: CommentAuthormono
    • CommentTime20 Jul 2009 zmieniony
     
    Jeśli chciałbyś dalej optymalizować w kierunku zmaksymalizowania prędkości można adres pmg oraz maski stablicować. Gdybyś miał współrzędną x w młodszej połówce rejestru .Y na wejściu a współrzędną y w starszej, wtedy mielibyśmy kod:
    ;.Y=yx, spr=Z
    lda lspr,y
    sta spr
    lda hspr,y
    sta spr+1
    lda mask,y
    ldy #8-1
    ora (spr),y
    sta (spr),y
    dey
    bpl *-3

    Potrzebujesz mieć tutaj jednak 3 strony tablic, które wyglądają tak:
    mask equ *
    dta b($c0,$30,$c,3)
    dta b($c0,$30,$c,3)
    ...
    lspr equ *
    dta l(sprities+$210,sprities+$210,sprities+$210,sprities+$210) ;x=0..3, y=0
    dta l(sprities+$290,sprities+$290,sprities+$290,sprities+$290) ;x=4..7, y=0
    ...
    dta l(sprities+$218,sprities+$218,sprities+$218,sprities+$218) ;x=0..3, y=1
    ...
    hspr equ *
    dta h(sprities+$210,sprities+$210,sprities+$210,sprities+$210) ;x=0..3, y=0

    Znacznik .CF i rejestr .X jest nieużywany.
    Współrzędne mogą być zamienione miejscami w rejestrze .X - trzeba wtedy tylko zmodyfikować odpowiednio tablice.
    Wersja dla x=[0..19] może wyglądać tak:
    ;.Y=yx (x - bity 1..4), .CF=x - bit 0, spr=Z
    lda lspr,y
    sta spr
    lda hspr,y
    sta spr+1
    tya
    rol @
    tay
    lda mask,y
    ldy #8-1
    ora (spr),y
    sta (spr),y
    dey
    bpl *-3
    ...
    mask equ *
    dta b($c0,$30,$c,3)
    ...
    lspr equ *
    :2 dta l(sprities+$190) ;x=0..3, y=0
    :2 dta l(sprities+$210) ;x=4..7, y=0
    :2 dta l(sprities+$290) ;x=8..11, y=0
    :2 dta l(sprities+$310) ;x=12..15, y=0
    :2 dta l(sprities+$390) ;x=16..19, y=0
    :6 dta b(?) ;6 bajtów nieistotnych
    :2 dta l(sprities+$198) ;x=0..3, y=1
    ...
    hspr equ *
    :2 dta h(sprities+$190) ;x=0..3, y=0
    :2 dta h(sprities+$210) ;x=4..7, y=0
    :2 dta h(sprities+$290) ;x=8..11, y=0
    :2 dta h(sprities+$310) ;x=12..15, y=0
    :2 dta h(sprities+$390) ;x=16..19, y=0
    :6 dta b(?) ;6 bajtów nieistotnych
    :2 dta h(sprities+$198) ;x=0..3, y=1
    ...

    Nieco szybsza wersja (ale wymagająca dodatkowej strony z drugą wersją tablicy z maską) np tak:
    ;.Y=yx (x - bity 1..4), .CF=x - bit 0, spr=Z
    lda lspr,y
    sta spr
    lda hspr,y
    sta spr+1
    bcs v2
    lda mask,y
    ldy #8-1
    ora (spr),y
    sta (spr),y
    dey
    bpl *-3
    ...
    v2 equ *
    lda mask2,y
    ldy #8-1
    ora (spr),y
    sta (spr),y
    dey
    bpl *-3
    ...
    mask equ *
    dta b($c0,$c)
    ...
    mask2 equ *
    dta b($30,3)
    ...

    Lub też nieco wolniej, ale zwięźlej:
    ;.Y=yx (x - bity 1..4), .CF=x - bit 0, spr=Z
    lda lspr,y
    sta spr
    lda hspr,y
    sta spr+1
    lda mask,y
    bcc *+5
    lda mask2,y
    ldy #8-1
    ora (spr),y
    sta (spr),y
    dey
    bpl *-3
    ...

    IMHO jest to jednak często przesada :) i zupełnie wystarczyłby wolniejszy wariant.
    Marok pokazał bardzo dobrą procedurę. Liczę, że nie obrazi się jeśli nieco ją zmodyfikuję ;):
    lda x
    and #$18
    asl @
    ora y
    adc #2
    :3 asl @
    sta spr
    lda >(sprites+$200)/2
    rol @
    sta spr+1
    lda x
    and #3
    tay
    lda highlight_mask,y
    ldy #7
    ora (spr),y
    sta (spr),y
    dey
    bpl *-3

    Tutaj z kolei .X jest nieużywany.

    Edit: Przyszedł mi do głowy pewien trick jeszcze związany z tablicami masek. Jeśli umieścimy je w pamięci tak, że tablica dla x parzystych będzie pod adresem strony parzystym np. $8000, a dla x nieparzystych będzie zaraz za nią pod adresem nieparzystym np. $8100 to kod może wyglądać tak:
    ;.Y=yx (x - bity 1..4), .CF=x - bit 0, spr=Z
    rol maskh
    lda lspr,y
    sta spr
    lda hspr,y
    sta spr+1
    lda mask/2,y
    maskh equ *-1
    ldy #8-1
    ora (spr),y
    sta (spr),y
    dey
    bpl *-3
    lsr maskh

    Taki styl programowania wymaga jednak kodu w RAM - w wersjach na cartridge ta technika odpada :)
    Jeśli procedura zostanie umieszczona dodatkowo na stronie zerowej dostajemy rol/lsr trwające po 5 (a nie 6) cykli. Można też wtedy zaoszczędzić parę cykli na trybie adresowania w pętli (też 5 a nie 6 na sta):
    ;.Y=yx (x - bity 1..4), .CF=x - bit 0, spr=Z
    highlight_map equ *
    rol maskh
    lda lspr,y
    sta spr
    lda hspr,y
    sta spr+1
    lda mask/2,y
    maskh equ *-1
    ldy #8-1
    ora (spr),y
    spr equ *+1
    sta $ffff,y ;adres zostanie nadpisany
    dey
    bpl *-4
    lsr maskh
    rts
    • 42: CommentAuthormarok
    • CommentTime20 Jul 2009
     
    mono: Ta modyfikacja trafiona w punkt. Dobre.
    • 43: CommentAuthorilmenit
    • CommentTime20 Jul 2009
     
    Dzięki za pomysły - z któregoś skorzystam :)
    Dalsze optymalizacje kodu nie będą potrzebne - i tak najprostsza procedurka w ASM będzie działała 3-4 razy szybciej niż powyższa w C, co już będzie wystarczające :)
    Ale fajnie, że są chętni pomóć!
    Kończę właśnie Atarową wersję GUI i może jeszcze w tym tygodniu powstanie podstawowa, grywalna wersja na Atari. Wtedy też Wasze umiejętności bardzo się przydadzą, bo według profilera 3 procedury od AI zajmują 80% czasu wykonania i właśnie je będzie trzeba przepisać na ASM, a przynajmniej przepisać kilka linijek z nich.
    • 44: CommentAuthormarok
    • CommentTime20 Jul 2009
     
    ilmenit: Proponuje procedure z postu mono.
    lda x
    and #$18
    asl @
    ora y
    adc #2
    :3 asl @
    ...
    • 45: CommentAuthorilmenit
    • CommentTime21 Jul 2009
     
    Nocny progress:
    - dwa zestawy fontów (co linię zmieniane w dli)
    - podświetlanie duszkami (wciąż w C)
    - mocno usprawniony silnik (zbalansowane jednostki, zbalansowane zasady walki, leczenie w chatkach, obsługa szarży w kawalerii, obsługa wybuchających pocisków)
    - więcej rodzaju terenu
    - więcej rodzajów jednostek
    - wciąż brak sterowania przez gracza
    - demo po raz kolejny to AI vs AI
    - wciąż wolne (krytyczne kawałki będzie trzeba przepisać na ASM).
    • 46:
       
      CommentAuthorsikor
    • CommentTime21 Jul 2009
     
    ładne, ładne...
    • 47: CommentAuthormono
    • CommentTime22 Jul 2009 zmieniony
     
    @ilmenit: Zapodaj te kawałki na forum. Wydaje mi się, że na zasadzie competition są większe szanse na kolektywne wypracowanie optymalnego rozwiązania :)
    • 48: CommentAuthorilmenit
    • CommentTime22 Jul 2009
     
    Na pewno na forum zapodam, ale jeszcze nie jest na to czas :) Za dużo zmieniam i poprawiam w samym silniku.
    • 49: CommentAuthorilmenit
    • CommentTime22 Jul 2009
     
    Blogowania ciąg dalszy ;)
    Zrobiłem prawie całe GUI wraz z animacjami ataku:



    Następne będzie sterowanie przez gracza (banał) i dołączenie wszystkich map kampanii do jednego pliku wykonywalnego (tu będę musiał wymyślić jakiś sprytny algorytm kompresji map i położenia jednostek).
    AI wciaż ma kilka błędów, ale chyba już wiem o co chodzi...
    • 50: CommentAuthormono
    • CommentTime22 Jul 2009
     
    Pokazałbyś te mapy? Nawet w postaci symbolicznej typu kropka-kreska (np. jak w Robbo czy Heartlight).