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

• Zapomniane hasło?
• Poproś o członkostwo

1. • 1:
      
     CommentAuthorjhusak
   • CommentTime3 Mar 2013 zmieniony

    
   Ja mam 100% pewność, ze względu na rozdzielczość. Tło ma szerokie piksle, a ninja wąskie.
   
   Mamy kilka wersji tej gry, m. in C64 i ZX Spectrum. Różne podejścia.
   Na Atari możliwe oba :)
   
   Uwzględniając możliwości Atari:
   - tryb graficzny typu C64 - na generatorach znaków, 32 bajty szerokości
   - hardsprites
   
   Lub siłowe:
   - tryb graficzny Spectrum + wszystko software (to xxl przepisze w tydzień :)
   
   Jeśli o mnie chodzi, to ja obstawałbym przy trybie 32 znaki w wierszu zmieniane co 4 linie - robi się tryb graficzny jak w c64, poza tym mamy 5 kolorów, ekran i tak wąski jest.
   
   Linii jest 18, więc to 5 zestawów znaków. Poza tym na planszy jest max jeden przeciwnik, co by się zgadzało z ograniczeniami sprajtów na C64 (3 na postać oraz 2 na dodatkowe przeszkadzajki/broń), spoko da się to zaimplementować na atarowskich sprajtach + maski, gdy wchodzi za murek.
   
   Spokojnie można użyć sprajtów atarowskich o szerokości 12 (kalka z C64)
   
   Rozkminienie sposobu generowania plansz to nie jest jakieś tam duże aj waj, od tego trzeba zacząć. Obiekty na siebie zachodzą, zakrywają się, itp, stąd pobranie już wygenerowanego efektu IMHO mija się z ideą kodowania na 8-bit.
   
   Wtedy dopiero gra będzie wyglądać dobrze i bez jakichś tam ograniczeń. typu pamięć, grafika czy sprajty. I będzie ją prościej napisać, bo nie będzie walki ze sprzętem.
2. • 2: CommentAuthorbrx
   • CommentTime3 Mar 2013

    
   @Gonzo: Jeśli dobrze zrozumiałem to używasz na planszę (pole gry) 9 zestawów znaków i co dwie linie znakowe zmieniasz zestaw znaków? To w sumie coś podobnego do mojej "Małej Księżniczki" ;)
   
   Czyli praktycznie ten tryb może pracować jako 5-kolorowy tryb graficzny. To daje 9 kb zajętości pamięci jako pamięć obrazu, ale większą swobodę, sporo wolnych znaków na duszki i grafika poziomu wcale nie musi tyle zajmować, bo albo kompresja danych, albo np. składanie obrazu z kafelków (np. 255 sztuk pseudoznaków 4*8 - 2 kb surowych danych) plus 64*18 danych obrazu. Jeśli zestaw tych 255 kafelków będzie stały dla wielu plansz, to rozmiar planszy to niewiele ponad kilobajt bez kompresji. Pomijając oczywiście inne potrzebne dane.
   
   Dalej o zgrozo nie kojarzę skąd te wściekłe 31 kilobajtów na obrazek, chyba że wliczasz w to kod, procedury DLI, muzykę i dane softsprajtów, które - jak sam zauważyłem - są bardzo pamięciożerne :/
3. • 3: CommentAuthorxxl
   • CommentTime3 Mar 2013

    
   portowanie last ninja dobrze by bylo zaczac od sprawdzenia silnika generujacego levele (moze tez mechaniki gry), ta gra dziala z dobra predkoscia na apple2 gdzie nie ma sprzetowych spritow i procesor jest wolniejszy oraz z powodzeniem miesci sie na acorn electron lub bbc micro gdzie pamieci jest tylko 32kb na cala gre.
4. • 4:
      
     CommentAuthorjhusak
   • CommentTime3 Mar 2013

    
   Przecież na C64 masz doskonale pokazany sposób generowania leveli :)
   Na spectrum plansza generuje się ... moment.
   
   Generalnie ta gra mi wygląda na prostą dość, a bardzo efektowną; różnorodność plansz powala.
5. • 5:
      
     CommentAuthormiker
   • CommentTime5 Mar 2013

    
   Na formatwar.net gość podesłał linka do czegoś takiego: ->link<-
   
   Może warto się i tym zainteresować. :)
6. • 6: CommentAuthortebe
   • CommentTime5 Mar 2013

    
   no i tak powinno się zaczynać tworzyć grę, od stworzenia środowiska, edytora itp. etc.
7. • 7: CommentAuthorGonzo
   • CommentTime5 Mar 2013

    
   jak na razie zgadzam się z jednym - żeby w ogóle myśleć o gierce tego typu, to dobrze jest mieć najpierw dpowiednie narzędzia, i ten warunek jest spełniony :) jeśli chodzi o pozostałe uwagi, to niestety, ale nie da się z nich skorzystać. nie chcę się powtarzać dlaczego. wystarczy spojżeć na takie gierki jak space harrier czy bomb jake - dało się? dało, ale każda zajmuje mnóstwo pamięci i czy kiedyś było to możliwe? nie. to, że firmy omijały akurat a8 z jakiegoś nieznanego powodu to mit, powodem było to, że nie było możliwości zrobić porządnej gierki z głównego nurtu na nasz komputerek w tamtych czasach. i jak się dzisiaj na to patrzy z odpowiedniej perspektywy to może nawet lepiej, że tak się stało, z wielu powodów.
   moje podejście do ln2 nie jest żadnym portem czy konwersją, tylko raczej próbą odpowiedzi czy to w ogóle jest możliwe na a8, i jak na razie nie widzę przeszkód nie do przejścia, a dokąd to zaprowadzi to zobaczymy. w każdym razie, dobrze, że nie ma portu z appla, bbc czy spectrum, i nie mam zamiaru tego komentować.
8. • 8: CommentAuthorwieczor
   • CommentTime5 Mar 2013

    
   Tu nie ma żadnych mitów, firmy omijały A8 z bardzo dobrze znanych powodów - ekonomiczno-marketingowych. Firma Atari w tym momencie promowała już ST a na rynku 8 bitów dominował commodore oraz spectrum, bo tani.
   
   Współczesne konwersje zajmują dodatkową pamięć bo jest to wygodne a autorzy nie muszą się już szczypać. Space Harrier dla odmiany ma ambicję konwersji z wyzszej platformy. I tyle. Pokazano przykłady przeczące tezie - nie da się. Nie padły żadne argumenty o niedostatkach sprzętowych stockowego Atari, wrecz przeciwnie te gry powstaly na maszyny slabsze pod wieloma wzgledami.
   
   Odpowiedz na pytanie czy LN2 jest mozliwe na Atari jest trywialna i brzmi tak. A konwersja moze powstac rownie dobrze ze spectrum ze wzgledu na podejscie, z grafika z commodore ze wzgledu na mozliwosci. A to ze jeszcze nie powstala to prawdopodobnie efekt tego, ze to kupa roboty ktora nie ma nic wspolnego z badaniem mozliwosci rysunkowych.
9. • 9:
      
     CommentAuthorjhusak
   • CommentTime6 Mar 2013

    
   [quote=Gonzo]
   jeśli chodzi o pozostałe uwagi, to niestety, ale nie da się z nich skorzystać.
   [gonzo]
   Jeśli chodzi o moje - możliwości sprzętowe Atari idealnie odpowiadają tej grze, chodzi głównie o duchy i tryb znakowy jako graficzny. Wyjątek to tzw długa broń przekraczająca szerokością 8 piksli, ale i to da się obejść. Jeśli się z tym nie zgadzasz, to znaczy, że znalazłeś swoje podejście, na którym się zafiksowałeś i wówczas moje nijak Ci nie pasuje, za to grze jak najbardziej :D
10. • 10: CommentAuthorwieczor
    • CommentTime6 Mar 2013 zmieniony

     
    To jest jedno podejście, a drugie to tryb graficzny i sprite programowy - ekrany się nie skrolują i są statyczne. Na ekranie poza ninją nie ma nigdy więcej niż jeden poruszający się obiekt - przeciwnik etc. Przypadek? Nie sądzę :) Ja uważam że Atari spokojnie sobie poradzi z "ręcznym" nanoszeniem postaci, tym bardziej że płynności ruchów tu specjalnie nie ma. I też raczej nie przypadkowo. Na C64 wykorzystano sprite'y bo są i bardzo dobrze, ale gra chodzi też na sprzęcie gdzie ich nie ma i daje radę.
    
    Oczywiście jeśli się da atarowskie sprite'y wykorzystać (a z uwagi na małą ilość obiektów prawdopodobnie tak) to robi się to jeszcze prostsze (przy użyciu odpowiednigo algorytmu, zwracam uwagę że jest kilka planów a ninja i jego przeciwnicy mogą się częściowo chować za obiektami z przodu :)
    
    Zresztą wystarczy zobaczyć:
    
    

    
    
    Działa? Działa :) Zero sprite'ów :)
11. • 11:
       
      CommentAuthorjhusak
    • CommentTime6 Mar 2013

     
    A ja dałbym głowę, że pod emulatorem xxl-a gdyby obsługiwał on 64 kB (co jest trudne ze względu na obszar D000-D7ff) gra działałaby niewiele wolniej. Bo co to jest przepisać te wszystkie dwa obiekty na ekran :)
12. • 12: CommentAuthorwieczor
    • CommentTime6 Mar 2013

     

    jhusak:

    Bo co to jest przepisać te wszystkie dwa obiekty na ekran :)

    
    
    That's my point :) Gra ma dość prostą wizualizację z paroma sprytnymi trickami (zwrócił ktoś uwagę że na spectrum maluje planszę tak szybko że tego nie widać? C64 ma wolny procesor). Tak naprawdę to logika gry wymaga inteligentnego zaplanowania - żaden rocket science, ale chyba są pomieszczenia gdzie są dwa poziomy i można się wspinać - ogólnie ładne drzewko case'ów do obsłużenia.
    
    Także tak naprawdę dużo żmudnej roboty - no, ale może ktoś się zmotywuje.
13. • 13:
       
      CommentAuthorRastan
    • CommentTime7 Mar 2013 zmieniony

     
    Co do tego, że da się zrobić Last Ninja na Atari nie mam wątpliwości. Wątpliwość mam co do tego jak to mogłoby wyglądać. Przecież jest nawet jakiś prototyp Shadow of the Beast. :) Na wersję taką jak na C-64 (mieszczącą się w 64kB lub nawet w 128kB) są małe szanse, ze względu na to, że tam sprity są w hi-resie + bardzo dużo kolorów na ekranie. Można pokusić się o port z ZXa lub BBC. Jeśli chodzi o ZXa to taki port nie będzie wyglądał lepiej - atari nie ma mapy kolorów. Niektóre obszary można by pokryć spritami, ale dokładnie takiego samego efektu (jak na filmie powyżej) się nie uzyska. Natomiast wersja na BBC odbiega graficznie od innych platform.
    Dobrze sugeruje XXL. Prace należałoby rozpocząć od analizy silnia graficznego. Zapewne w tej grze komnaty zapisywane są w postaci obiektów zbudowanych ze znaków, a nie tak jak podchodzi do tego Gonzo - każda plansza to pewien zestaw znaków. Podobny problem mieliśmy w Ricku. Pierwsza wersja nie uwzględniała makro-bloków i zajmowała bardzo dużo (nie zmieściłaby się w 64kB). Natomiast po zastosowaniu makro-bloków zajmuje kilka razy mniej pamięci.
    
    Wersja BBC:
    
14. • 14:
       
      CommentAuthorjhusak
    • CommentTime7 Mar 2013 zmieniony

     
    @wieczor, zwrócił w poście 4 :)
    
    A propos komnat/plansz - są trzy podejścia:
    - grafika (Conan, Goonies) - nie daje ograniczeń w aranżacji
    - znaki (np. Montezuma, Action Biker) - dają dowolność w układzie plansz, ale ogranicza i plansze są nierzadko "klockowate"
    - bloki (k na n znaków) - dają zysk w prostych planszach, w skomplikowanych bloki zajmują to, co się ukręca na planszach - tylko jeśli jest dużo plansz, > dajmy na to 30 (vicky, feud, star quake, inne polskie)
    - bloki o zmiennych wymiarach, jak to jest w LN i zapewne w SPYvs SPY - tam, gdzie jest dużo plansz.
    
    Dopiero ta czwarta metoda daje duże możliwości przy optymalnym wykorzystaniu pamięci - daje wolność tworzenia plansz jak w punkcie "znaki" i jest zgodna z zasadą "nie powtarzaj się".
    
    Ponadto w LN mamy nakładanie elementów z maskami poprzez "and mask or object", co dopełnia poczucia braku ograniczeń.
    
    Ponieważ tych obiektów trochę jest i każdy zajmuje trochę pamięci, kompresja na tym poziomie musi być "online", obiekty rozkompresowywane są przed narysowaniem włącznie z maskami, nakładane, a następnie zapominane. Dlatego na C64 to tak widocznie wolno działa.
    
    I dlatego też trzeba używać edytorów, bo ręcznie się człowiek pogubi.
    
    I właśnie dlatego to powinno być w trybie znakowym 32 znaki szerokości jako graficznym, aby uzyskać 5 kolor oraz korzystniejszy dla kompresji układ bajtów.
15. • 15:
       
      CommentAuthorjhusak
    • CommentTime7 Mar 2013 zmieniony

     
    To już nie ma tajemnicy, kto robi Ricka D? Jakie są prognozy ukończenia?
    ---- edit
    jestem nie w kursie :)
16. • 16: CommentAuthorwieczor
    • CommentTime7 Mar 2013

     
    Kolorów jest duzo na Amidze czy ST , na c64 raptem kilka - fakt ze wiecej niz 4 - i sporo patternów. Sprite'y sprzetowe na commodore są koniecznoscia z uwagi na szybkosc procesora.
    
    Port nie musi - i nie moze czy nie powinien - stac sie dokladna kopia z ktorejkolwiek platformy, trzeba wykorzystac specyficzne wlasciwosci sprzetu. Ja proponuje niejako polaczenie obu podejsc, tzn sprite'y software'owe jak na spectrum ale tryb 160x200 w kolorach jak na commodore. Wtedy dodatkowo moza uzyc sprzetowych sprite'ow do dodania kolorow. Ilosc kolorow nie musi byc ta sama , z eksperymentow Gonza czy chociazby Jose Pereiro wynika ze jest ich dosc aby to dobrze przedstawic. A rozdzielczosc jest wystarczajaca na przedstawienie postaci i nie trzeba uciekac sie do hiresu - gra w tym trybie, naturalna dla spectrum - duzo by stracila - w przypadku atari zupelnie niepotrzebnie.
    
    Poza utrudnionym budowaniem sprite'ow softwareowych przeciw trybowi znakowemu przemawia jeszcze jedno - sposob konstrukcji pomieszczen. Rzut izometryczny powoduje, ze rozmieszczenie obiektow jest dosc swobodne, chociaz na pewno skwantyzowane, obiekty zawieraja elementy przezroczyste - brak koloru, mozna przemieszczac sie za nimi. Tu tryb tekstowy nie da nic, a operowanie nim, w przeciwienstwie do gier tilowanych 2d jak np. Rick, jest skrajnie trudne i moim zdaniem nie zda tu egzaminu.
17. • 17:
       
      CommentAuthorRastan
    • CommentTime7 Mar 2013 zmieniony

     
    jhusak: tajemnica rozwiała się już dawno temu (na party Grzybsoniada 2012) :). Prace są na razie w toku. Grafik ma ostatnio dużo pracy i nie może się poświęcić projektowi w 100%.
    
    wieczor: takim podejściem zrobiłbyś coś takiego jak na BBC tylko podkolorowane spritami. Żeby to wyglądało lepiej musiałby grafikę poprawić grafik. Wtedy mogłoby to wyglądać porównywalnie do wersji C-64 ale nie sądzę że lepiej.
    Myślę, też że podkolorowanie spritami nie byłoby takie proste, trzeba by dokładnie przeanalizować jakie elementy można podkolorować jakie nie. To wiązało by się z dużym nakładem pracy, a w konsekwencji ze zwiększonym zapotrzebowaniem na pamięć przez engine gry.
    Wszystko łatwo się ustala teoretycznie, jak przychodzi do kodowania cała teoria idzie w łeb ponieważ pojawiają się nieprzewidziane trudności. Jak to kiedyś ktoś powiedział: różnica między wiedzieć jak coś zrobić, a fizycznie to zrobić jest po prostu ogromna.
    a'propos kolorów na C64 to w niektórych komnatach jest ich 16.
18. • 18:
       
      CommentAuthorjhusak
    • CommentTime7 Mar 2013 zmieniony

     
    Na C64 na dzieńdobry maluje się tło - miejsca, po których chodzimy oraz te po których nie chodzimy. To mogłyby sprajty hw załatwić.
    
    Przy czym moja propozycja rozwiązania trybu graficznego pozwala na stosowanie sprajtów programowych bez wyrzeczeń :) tak jak w grafice.
    
    Tak, jak przedmówcy, nie wyobrażam sobie, jak zrobić tę grę w trybie znakowym. Do Amaurote jest jej znacznie bliżej.
19. • 19: CommentAuthorxxl
    • CommentTime7 Mar 2013

     
    tryb tekstowy w grach izometrycznych jest mozliwy. atarowcy przyzwyczajeni sa do tego ze jesli slysza "tryb tekstowy" to mysla, ze grafike uklada sie z fontow... bardzo dobrym rozwiazaniem jest polozenie fontow na ekranie w kolejnosci a generator znakow traktowac jak pamiec graficzna. ten sposob swietnie sie sprawdza, nie ma ograniczen co do ilosci uzytych tilesow... np. w knight lore to jest wykorzystane. daje tez mozliwosc uzywania dodatkowego koloru i nie jest wcale taki wolny, nowy hobgoblin2 dzwiga 8 spritow bez spowolnien, ekran jest wlasnie tak zbudowany fonty polozone w kolejnosci, jesli trafi sie zapis do pamieci ekranu to jest to zpis dotyczacy koloru (inverse fonta).
20. • 20: CommentAuthorwieczor
    • CommentTime7 Mar 2013

     
    @xxl: racja, tylko że w Knight Lore mamy do czynienia z nieco inną sytuacją. Tutaj mamy dużą postać gracza, plus ew. dużą postać przeciwnika, a tło jest dość złożone i jakoś trzeba to nanosić. W przypadku trybu znakowego może być to trudne dość ew. skutkować namnożeniem dodatkowych znaków z elementami bohatera:
    
    @Rastan: tak, grafikę trzeba obrobić, z tym że mówimy o obrobieniu poszczególnych elementów. Wersja na BBC działa chyba najlepiej, chociaż nie wygląda. Tylko że nie mała ilość kolorów jest problemem a to jakie one są :) CGA :) My mamy trochę większe możliwości w tym zakresie.
21. • 21:
       
      CommentAuthorjhusak
    • CommentTime7 Mar 2013 zmieniony

     
    @wieczor, właśnie, że sytuacja jest niemal identyczna, a ja właśnie proponuję to, co xxl wyraził inaczej.
    

    xxl:

    bardzo dobrym rozwiazaniem jest polozenie fontow na ekranie w kolejnosci a generator znakow traktowac jak pamiec graficzna.
    

    
    No właśnie tak ma C64, czy to są znaki, czy grafika, wsio ryba. Na c64 nie ma trybu graficznego "liniowego"
    
    Śmiem twierdzić, że port z BBC - micro jest łatwy do zrobienia. Gra ma 6 leveli A i 6 leveli B, ładnie w pliczkach pozapisywane :)
22. • 22: CommentAuthorwieczor
    • CommentTime7 Mar 2013 zmieniony

     
    A to nie jest to samo podejście (w sensie użycia generatora znaków jako pamięci graficznej) co użyte przez Gonza? I fonty w generatorze się kończą, ilość generatorów do użycia na ekranie eliminuje sensowność tego rozwiązania? (oczywiście jeśli nie zakładamy użycia rozszerzonej pamięci).
    
    Zastanawiam się po prostu co, poza tym jednym dodatkowym kolorem, daje nam tu tryb znakowy. Tu nie ma jak wykorzystać powtarzalności, bo pamięć ekranu jest jedna, nie przewija się , równie dobrze można to wszystko ustawić przy przechodzeniu z planszy na planszę na ekranie graficznym - oczywiście z zapamiętanych wzorców, ale trochę innych niż znaki.
    
    W knight lore tło masz czarne, w związku z tym tych znaków nie ma aż tak dużo. Chyba że coś mi umyka więc poprosiłbym o wyjaśnienie na świnkach i jabłuszkach :)
23. • 23: CommentAuthormgah
    • CommentTime7 Mar 2013

     
    Należy rozpocząć pracę od deasemblacji wersji z C64 i wyodrębnić silnik graficzny gry oraz logikę. Dopiero znając sposób tworzenia grafiki na C64 można się zastanowić nad stworzeniem ekwiwalentu na Atari. Gra pomimo efektownego wyglądu nie wydaje się być skomplikowana i zrobienie wersji na Atari to tylko kwestia silnej motywacji i rozwiązania problemu finansowego. Nie wyobrażam sobie aby ktoś się w to zaangażował i jednocześnie rzucił wszystkie inne zajęcia. Ponieważ istnieje małe prawdopodobieństwo aby potencjalny twórca gry nagle wygrał w totka proponuję utworzyć fundusz rekompensacyjny dla osoby która się zaangażuje w stworzenie tej gry jak i innych. Bez finansów gry nie będzie.
24. • 24: CommentAuthorwieczor
    • CommentTime7 Mar 2013

     

    mgah:

    Należy rozpocząć pracę od deasemblacji wersji z C64 i wyodrębnić silnik graficzny gry oraz logikę. Dopiero znając sposób tworzenia grafiki na C64 można się zastanowić nad stworzeniem ekwiwalentu na Atari.

    
    
    Silnik graficzny z C64 się nie przyda, gdyż z oczywistych względów na Atari będzie musiał się oprzeć na innych założeniach. Prędzej ten z BBC czy Spectrum. Zripować z C64 celem dalszej obróbki można grafikę. Co do logiki, jak najbardziej.
    
    

    mgah:

    Nie wyobrażam sobie aby ktoś się w to zaangażował i jednocześnie rzucił wszystkie inne zajęcia.

    
    
    Nikt nie mówi o rzuceniu wszystkich innych zajęć. To co robimy to hobby i ten czas na to poświęcamy.
    
    

    mgah:

    Bez finansów gry nie będzie.

    
    
    Będzie, będzie tylko w odpowiednio długim czasie. W rozwiązanie finansowe nie wierzę, gdyż nie jest to rynek na którym można zarobić tyle, żeby się z tego utrzymać. Dodatkowo taki opłacony twórca byłby pod presją. Pomijając tych, którzy tworzeniem gier zajmują się zawodowo i po prostu wiedzą, co powinni zrobić nie tracąc czasu na eksperymenty, niewielu mogłoby temu podołać
25. • 25: CommentAuthorxxl
    • CommentTime7 Mar 2013

     
    > A to nie jest to samo podejście (w sensie użycia generatora znaków jako pamięci graficznej) co użyte przez Gonza?
    
    zupelnie inne. tam pamiec ekranu wyglada przykladowo:
    1,2,3,6,9,10,1,0,0....
    ja mowie:
    0,1,2,3,4,5,6,7,8...
    
    > I fonty w generatorze się kończą,
    
    nie ma to znaczenia
26. • 26: CommentAuthorwieczor
    • CommentTime7 Mar 2013

     
    Teraz kumam. Czyli lecimy znakami po kolei zmieniając generator na DLI jak się skończy, a rysujemy po prostu w obszarze tych generatorów. Dzięki temu operujemy jak w trybie graficznym, pamięci zajmuje to z grubsza tyle samo (plus jakieś grosze na samą pamięć ekranu), a mamy dodatkowy kolor. Dobre rozwiązanie.
27. • 27:
       
      CommentAuthorRastan
    • CommentTime7 Mar 2013 zmieniony

     
    @wieczor: dodatkowy kolor naprawdę dużo daje. dobry grafik jest w stanie wyciągnąć wiele z 5-kolorów.
28. • 28: CommentAuthorJosé Pereira
    • CommentTime7 Mar 2013

     
    Hi.
    You can use the C64 version to direct import the gfxs and not need to have like Gonzo all those screens that are Memory impossible (large cart?).
    
    
    
    For all these years studying LN and talking with some guys I realized some time ago how it's done on C64 and yes, the gfxs are like you could/would do on A8.
    
    C64 uses Bitmap Multicolour where you have (00) as the BACKGROUND Register colour (Black on all LNs) and then each car 4x8 has it's own colour possible on other Bit-pairs.
    From this 'Integrators' you can build levels and see how it really worked on the C64:
    ->link<-
    
    
    Each level has just small chars/tiles taht are exactly like soft sprites. Each object has it's 4 bit-pairs that draws each one begining with the Floor main colour then the walkways lines the the back tree then the rock above,...
    Each object is just a small nº that outside their shapes are 'transparent' exactly like any soft sprite routine.
    We just have to pick-up all those C64 small objects and see wich of them need to be changed some bit-pairs (like if we want to have a Green as (01) and it is (11) on C64...)
    
    
    This translated into A8 works like this:
    -> A8 must use ANTIC4 5colours if we really want to get the 'worth using' one more colour.
    -> 'Mimic Bitmap Mode' that would be Playing Area 0,1,2,3,4,... charsets
    -> Having those small objects in A8 bit-pairs then it's 6502 Assembly SAME ROUTINE as on C64 where:
    1st.)- Have the 'Mimic Bitmap screen' charsets all Black
    2nd.)- Draw all screen like C64 in 4colours/4bit-pairs by placing those objects/soft sprites from the back one untill the most in front gfx.
    3rd.)- Now you have the screen in 4colours you have for a 'table information' for each screen where is the 5th colour/char>=128 and if DLIs on some scanlines)
    4rd.)- Nowe that you have the screen in 5colours (and if needed some DLIs) then add PMGs data over some gfxs if needed.
    -> It's only the last thing when you put your players over the screen.
    
    
    The C64 screen, like our Bitmap Mode uses about 8KBs of RAM so if we use our ANTIC4 1,2,3,4,5,... charsets the we still use the same Memory as the C64.
    The C64 gfxs/small objects 'soft sprites like' data are exactly like ours bit-pairs and C64 Bitmap Mode it's exactly like a charmode with 4x8pixels each char so, again, the same Memory used.
    The C64 sprites shapes converted into A8 in 2x1 if almost the same size then the only thing that's more data is that we in soft sprites need to count for the shifting some more chars (here we can use those carts with more Memory).
    
    
    Only really different and where the coding guy need to do A8 specific it's on moving the guys because we have them as soft sprites (and probably one or two PMGs needed for the their Eyes, Hands, Clothes,...).
    The guys going over or behind some things isn't all that tricky because it depends on wich PRIOR Mode you're using, what those objects use some PMGs or not.
    This Masking can be done like ZX. You need to have 'another table' for each screen where you have those front of the Player(s) objects acting like a soft sprite:
    -> You are a Man and are walking over gfxs so you are always in front then your routine 'LDA/AND/OR/STA', now there's a moving guy that you go behind him it's the guy that does this 'LDA/AND/OR/STA' with you.
    BUT
    -> If the gfx in front of you then this object it's a soft sprite like any other soft sprite on screen (soft sprites are not necessarily moving things)
    LN masking Ninja on some gfxs it's just a soft sprite routine nothing 'out of this world' because you only have more the Enemy and only in some screens so there's plenty of C.P.U./cycles to achieve this.
    
    
    
    This is how C64 build and 'HOW TO?' if we ever want to have the game seriously and build exactly like it should be because building the game as a '@sum' of screens like a slideshow it's nothing special in my opinion. What, for me has LN it's music apart the clever way that they invernted to build the screens. If not this it's just a slideshow on a large Memory cart or just because we can put Emulators with large Memory.
    
    
    
    On those 'Integrators if I have the option to saave images I easilly transfer those objects to the A8 bit-pairs 4colours I think would fit on the A8 screen Map.
    The programmer job in LN is doing lots of 'LDA/AND/OR/STA' for 10,15,20,30,... small objects untill the creen design is complete (that's why it takes at least two or three seconds, at least, to complete all the screen building).
    
    
    
    
    
    
    Wow, what a long post.
    Hope you understand my point and Gonzo don't take my opinion of 'slideshow' as putting down your work but just because I really and always wanted LN on A8 but LN on A8 looking good, of course (and today we have better options) but doing the game like an old/Retro computer/in the past/original guys idea.
    Greatings.
    José Pereira.
29. • 29:
       
      CommentAuthorjhusak
    • CommentTime7 Mar 2013 zmieniony

     
    Co tu dużo gadać. Portowanie z BBC jest trywialne, jeśli chodzi o wolniejsze gry.
    
    Z ciekawostek, cały ekran BBC jest przepisywany na atarowski z konwersją w locie (taki double-buffering). Nie ma pozostałych rzeczy, bo one pewnie rysują się funkcjami, które wykomentowałem :)
    
    Niemniej, jeśli dodać obsługę joysticka, to będzie można w to grać.
    
    Jest to tylko pierwszy level. Przy aktualnej budowie gry, spokojnie po kompresji leveli zmieszczą się w pamięci wszystkie.
    
    Zajęło mi to 4 - 5 godzinek z rozkminianiem trybu graficznego :)
    
    jeśli by zrobić:
    
    - deasemblację (to jest 6 kb kodu)
    - konwersję grafiki, to jest trywialne
    - podmienić procedurę zapisu na ekran tak, aby dane były wrzucane pod zestawy znaków, które, jak wiadomo, nie dzielą się przez 40 :)
    - podrasować grafikę z C64 oraz dodać piąty kolor
    
    To będzie GIT.
    
    Ta gra jest niesamowicie przejrzyście napisana. Oddzielnie dane, oddzielnie kod (tzn w oddzielnych plikach)
    
    Podany xex działa tylko pod emulatorem, bo się ładuje pod $400.
    
    

    • ninja.xex
    • Screen shot 2013-03-07 at 22.41.38.png
30. • 30: CommentAuthorxxl
    • CommentTime7 Mar 2013

     
    :-) wszystko jest mozliwe
31. • 31:
       
      CommentAuthorpirx
    • CommentTime7 Mar 2013

     
    no pięknie!!!
32. • 32: CommentAuthorGonzo
    • CommentTime7 Mar 2013

     
    jhusak - nie wiem za bardzo co to jest szok poporodowy, ale tak właśnie mniej więcej się czuję :) coś pięknego. wystarczyło 4-5 godzinek i już (nno prawie) jest last ninja? :) mniejsza o samą grę, ale mógłbyś skrobnąć parę słów na temat "portowanie gier"?
33. • 33: CommentAuthorkade
    • CommentTime7 Mar 2013

     
    Ja czegoś nie rozumiem... napisali tą gra na BBC Micro, a na miliard razy popularniejsze Atari sprzedawane do początku lat 90' już nie...
34. • 34:
       
      CommentAuthorjhusak
    • CommentTime7 Mar 2013 zmieniony

     
    @Gonzo. Otóż jest. Bo to, co pozostało, to:
    - dorobienie sterowania joystickiem
    - muzyka + efekty
    - dorobienie procedurki rysującej panel
    - ew. tuning grafiki.
    - konwersja trybu BBC na Atari w plikach (a nie online)
    
    Wszystko to można zrobić NIE DEASEMBLUJĄC gry.
    
    A po deasemblacji:
    - grafika do poprawienia
    - poprawa procedury rysującej na 5 kolorów (tu potrzebny grafik), i poprawka w kodzie aby ten piąty kolor się rysował :)
    - poprawa organizacji ekranu.
    
    UWAGA. Pełna logika gry jest przeniesiona 1:1, więc te powyższe rzeczy to tzw. kosmetyka na już działającym produkcie.
    
    Przy czym wersja BBC ma jakieś 20 kilka kilobajtów: kod z logiką, 1 level + grafika. Levele są doczytywane.
    
    ------------------------------
    
    Co do portowania:
    
    1. Bierzesz taką grę, aby pasowała do Atari trybem graficznym (np.160xileś)
    2. Wrzucasz pod te adresy, co w oryginale
    3. Wyrzucasz wszelkie jmp i jsr pod FFFx, dorabiasz własne lub nopujesz
    4. przerzucasz ekran BBC z konwersją w locie, to trwa ok. 2 ramek.
    
    Dorabiasz po prostu loader w madsie, co przygotuje podkład i podmieni kawałki kodu z punktu 3 i operacje dla punktu 4
    
    I masz taki efekt, jak ja. Ponadto xxl kiedyś robił konwersje w hiresie.
    
    Tak naprawdę, to emulator BBC nie jest trudno napisać :) na Atari, o ile nie korzysta z hardware stricte.
    
    Byłby kolejny emulator, a właściwie maszyna wirtualna.
35. • 35: CommentAuthorxxl
    • CommentTime7 Mar 2013

     
    BBC Micro i Acorn Electron byly w kazdej szkole w GB. To na ta maszyne wyszla gra ELITE :-)
36. • 36:
       
      CommentAuthorTenchi
    • CommentTime7 Mar 2013 zmieniony

     
    To prawda, zdarzały się maszyny które były szczególnie popularne w konkretnych miejscach świata - dla przykładu można podać chociażby MSX-a na którego był straszliwy boom w Hiszpanii, czy Segę Mark III (Master System) za którą ostro szaleli w Brazylii.
37. • 37: CommentAuthorkade
    • CommentTime7 Mar 2013

     
    Okej, mimo wszystko Atari, komputer sprzedawany na całym świecie. Coś poszło ewidentnie nie tak.
    
    Jhusak: jestem pod wrażeniem.
38. • 38:
       
      CommentAuthorjhusak
    • CommentTime8 Mar 2013 zmieniony

     
    :)
    
    Ten bbc micro ma pamięć taktowaną 4 MHz, co drugi cykl ma procek - 2MHz, a co drugi procek graficzny. I śmiga jak spectrum :)
39. • 39: CommentAuthorwieczor
    • CommentTime8 Mar 2013

     
    Hehe.... :) swiety graal sie odnalazł :) co do grafiki to fajnie by było zrobic to jak na commodore glownie chodzi o panele ,bo na bbc jest biednie troche no i ztuningowac obiekty , kolor i tintowanie ,tu juz pewnie trzeba by zdeasemblowac ale i tak do ostatecznego efektu trzeba by bylo. Ale lwia czesc roboty tzn logika gry jest, widac profesjonalisci to pisali. No w skrocie szczeka mi lekko opadła jak to zobaczyłem. Budżety się marzyły, tiaaa.... ;)
40. • 40: CommentAuthorAdam
    • CommentTime8 Mar 2013

     
    Brawo Kuba, rozumiem, że za tydzień będzie gotowa całość i to z Twoją muzyką napisaną w międzyczasie ;)
41. • 41:
       
      CommentAuthorJacques
    • CommentTime8 Mar 2013

     
    Ogień! :-) Ależ byłoby pięknie, trzymam kciuki :-)
42. • 42: CommentAuthorwieczor
    • CommentTime8 Mar 2013

     
    Spokojnie Panowie - jak już tak ładnie się zaczęło, warto poświęcić trochę czasu i zrobić dopracowaną wersję, niż coś na szybko :) Czekaliście 25 lat, możecie chyba zdobyć się jeszcze na odrobinę cierpliwości? ;) Pytanie brzmi - kto dokończy to co Kuba zaczął (chyba, że Kuba ma ochotę to zrobić? ;)
43. • 43: CommentAuthormono
    • CommentTime8 Mar 2013

     
    Imponujące :) Kuba mistrz.
44. • 44:
       
      CommentAuthorJacques
    • CommentTime8 Mar 2013

     
    wieczor ma rację, gdyby powstała taka mega konwersja (silnik z BBC Micro, grafika tuningowana na podstawie wersji C64) to byłoby to :-)
45. • 45:
       
      CommentAuthoradv
    • CommentTime8 Mar 2013

     
    @Wieczor - Nic dodać, nic ująć.
    @jhusak - co tu dużo gadać... You are the Master!
46. • 46: CommentAuthorvega
    • CommentTime8 Mar 2013 zmieniony

     
    Zdecydowanie to dobry kierunek, wersja z BBC + upgrade grafiki wzorowanej na C64 (PMG + DLI, a może nawet zmiany kolorów rastrze).
    
    Jakby ktoś to z deasemblował(żeby wiedzieć co gdzie jest) jeszcze to można by wspólnymi siłami to dopracować. Jakby coś ktoś poprawił to mógłby aktualną wersję zamieścić tutaj:)
47. • 47:
       
      CommentAuthormiker
    • CommentTime8 Mar 2013

     
    No to dodajmy jeszcze nieco klimaciku do temata... :)

    • lnin2_7m4.xex
48. • 48: CommentAuthorwieczor
    • CommentTime8 Mar 2013

     
    O właśnie konwersja kawałka poszła Ci nieźle, pora na resztę, to byłby znaczący krok naprzód. Można by też pomyśleć o stereo ale na zasadzie lewy kanał stanowi komplet, prawy rozszerza brzmienie/przestrzeń. Player RMT jest na tyle sympatyczny ze nawet wykrywać stereo nie trzeba, masz jeden pokey - slyszysz co trzeba, masz dwa - słyszysz lepiej ;)
49. • 49:
       
      CommentAuthormiker
    • CommentTime8 Mar 2013 zmieniony

     
    A ja akuarat traktuję stereo jako opcję/zło konieczne, często wystarczają mi 2-3 kanały (ostatni na FX-y, vide Jetboy, Bomb Jake, coś tam jeszcze chyba...).
    W kawałku z mojego poprzedniego posta jest użyty "tylko" synth i filtr 15kHz (no, może na chwilę jeszcze zegar 1,72MHz).
    Generalnie dobrym źródłem muzyczek jest strona vgmusic.com, tyle że trzeba się orientować w zapisie midi.
    Więcej grzechów nie pamiętam.
    
    A, Kuba, super robota, warto to dalej pociągnąć. 3mam kciuki! :)
50. • 50: CommentAuthorwieczor
    • CommentTime8 Mar 2013 zmieniony

     
    A ja stereo czyli dodatkowego POKEYa nie traktuję jako dodatkowych 4 kanałów bo to by było zło - tzw. pingpong czyli Amiga welcome to i konieczność robienia osobnej wersji mono i stereo. Wszystkie muzyczki piszę na jednego POKEYa a potem dodaje tracki na drugim, które używane są aby dodać przestrzeń ew. wzbogacić brzmienie. Dzięki temu jak masz jednego POKEYa muzyka brzmi dobrze, tak jak powinna, jak jest drugi, słyszysz "szerzej" trochę bogaciej, głębiej. Dzięki temu nie zmuszam nikogo do stereo a jednocześnie je wykorzystuję. Właśnie jako opcja.
    
    3-4 kanały też mi wystarczają, co nie znaczy że nie mógłbym na więcej ;) ale nie w trybie na sztywno zafiksowanym lewy-prawy :)
    
    Zauważyłem, że nie lubisz stereo :)