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: CommentAuthorGonzo
   • CommentTime7 Dec 2009

    
   Super Robin Hood, hmm... Wydaje mi się, że genialny silnik Tebe jest stworzony dla tej gierki, nie wiem, może się mylę, ale z tego co udało mi się zrobić to widać, że to poprostu działa. Niedawno zrobiłem screen tytułowy i to było trochę za mało, więc podmieniłem grafikę w SSE, ale obsługa postaci, przeciwników, przedmiotów etc. jest raczej poza moim zasięgiem. Gra jest w zasadzie bardzo podobna do Bomb Jake'a...
   
   

   • srh.xex
2. • 2: CommentAuthormono
   • CommentTime7 Dec 2009

    
   Fajne. Robin jest złożony z dwóch sprajtów (na górze czasem mu głowę ucina)?
3. • 3: CommentAuthorGonzo
   • CommentTime7 Dec 2009

    
   mono - tak, nie zmieniałem nic w kodzie sterującym sprite'ami, podmieniłem tylko samą grafikę i z tego to wynika. SSE obsługuje 11 duchów 12x24, więc wypas jest, wszystko tu da się zrobić.
4. • 4: CommentAuthorGonzo
   • CommentTime16 Dec 2009

    
   
   
   Trochę za szybko przełączają się klatki animacji, a ja nie wiem na razie jak to zmienić, najlepiej jest zmniejszyć prędkość emulatora do 30% :(

   • srh2.xex
5. • 5: CommentAuthormac
   • CommentTime16 Dec 2009

    
   cokolwiek to jest, wygląda SUPER!
6. • 6: CommentAuthorvega
   • CommentTime16 Dec 2009 zmieniony

    
   Fajne:)
   
   Ogólnie dzięki "SSE autorstwa TEBE" każda gra z C64 (do 8 sprite'ów 12x21) jest do przeniesienia....przy większej ich liczbie zastosowany silnik jest już za wolny.
   
   Ale i tak do większości gierek wystarczyłby spokojnie:)
7. • 7: CommentAuthorirwin
   • CommentTime19 Dec 2009

    
   @Gozno - Znakomicie Ci to wyszło!! Produkujesz tyle mockup'ów że pewnie wygrasz w nadchodzącym konkursie - bo jestem pewien że wystartujesz. ;)
8. • 8: CommentAuthormac
   • CommentTime20 Dec 2009

    
   Mam nadzieję, że to się nie skończy tylko na mockupie.
9. • 9: CommentAuthorbob_er
   • CommentTime20 Dec 2009

    
   z ciekawosci:
   ile (kilo)bajtow oraz linii ekranu zajmuje obsluga jednego sprite'a?
10. • 10: CommentAuthortebe
    • CommentTime20 Dec 2009

     
    w paczce z mads-em jest ten silnik i parę innych, m.in. NG który zająłby znacznie mniej miejsca i jest prostszy w obsłudze bo wszelkie operacje przesunięć realizuje programowo, nie wymaga rozpisanych klatek animacji spritów
    
    do takiej gry, gdzie nie ma dużo przeszkadzajek to lepszy wybór niż silnik z Bomb Jack-a
11. • 11: CommentAuthorGonzo
    • CommentTime22 Dec 2009

     
    mac - też mam taką nadzieję ;) scroll jest gotowy (chociaż nie do końca, bo na razie nie pasuje do silnika), sprite'ty też (prawie), tylko trzeba to pożenić, i tu zaczynają się schodki :(
    
    
    
    tebe - ciekawe czy dało by się połączyć SSE ze scroll'em
    
    scroll sterowany jest joyem - left right sped up speed down (oczywiście planszę tytułową trzeba popchnąć anykey'em)

    • srh_level1_scroll_PLUS.xex
12. • 12: CommentAuthorvega
    • CommentTime23 Dec 2009

     
    Ze scroll'em można jak najbardziej ale trzeba samemu modyfikować współrzędne sprite'ów uwzględniając scroll.
    
    Chyba, że tebe zrobi silnik SSE+:P
    
    Trzeba też wziąć pod uwagę czy wystarczy nam znaków do wyświetlenia SPRITE'ów + grafiki tła. W sumie mamy tutaj ograniczenie do 128 znaków (każdy sprite 8x24 zabiera nam 4 znaki).
13. • 13: CommentAuthortebe
    • CommentTime23 Dec 2009

     
    mam pomysł na scrolla poziomego, bez ograniczenia co do treści i ilości scrollowanych danych, tyle że tylko scroll w prawo, potrzeba tylko napisać kilka dodatkowych programów które spreparują odpowiednio dane dla takiego scrolla
14. • 14:
       
      CommentAuthorKaz
    • CommentTime23 Dec 2009

     
    Scroll w prawo? Ty chyba jestes jakims arabskim ekstremista :P
15. • 15: CommentAuthortebe
    • CommentTime24 Dec 2009

     
    :) znaczy się w lewo, jak Giana Sisters
16. • 16:
       
      CommentAuthormiker
    • CommentTime24 Dec 2009

     
    Hehhe, a już myślałem, że to w ten oto sposób "Twoja stara przeszła Super Mario Bros w prawo". ;D
17. • 17:
       
      CommentAuthorTheFender
    • CommentTime24 Dec 2009

     
    Turbodymomen zawstydził Mario. Przeszedł poziom idąc w lewo.
    ........ .... . . .
    Miker> ale przecież w Mario idzie się w prawo :)
    (ekran się scrolluje w lewo ;)
    ............. . . .
18. • 18: CommentAuthorGonzo
    • CommentTime25 Jan 2013 zmieniony

     
    
    
    ln2 wg mnie powinno pójść na tym silniku :)
    
    tebe - są tu jakieś haki? (te makra i różnego rodzaju uproszczenia są dosyć skomplikowane jak dla mnie, i nie za bardzo wszystko rozumiem :)
    
    a na obrazku mamy sześć duszków programowych na tle znakowym w pięciu kolorach - wypas, i na dodatek muzę rmt (miker) oraz sterowanie joy'em :) ja już czuję ten klimat :)

    • ln2_CharEngine_1xBuf_test.xex
19. • 19: CommentAuthorbrx
    • CommentTime25 Jan 2013

     
    A na emulatorze Altirra działa Ci to poprawnie, czy tylko u mnie coś "nie teges"?
20. • 20: CommentAuthorBluki
    • CommentTime25 Jan 2013

     
    Nie tylko na Altirze, na A800Win PLus jest jeszcze gorzej.
21. • 21: CommentAuthorGonzo
    • CommentTime25 Jan 2013 zmieniony

     
    hmm, u mnie na a800win działa ok, a na alirce też działa ok po wyłączeniu fast boot (firmware)
22. • 22: CommentAuthortebe
    • CommentTime26 Jan 2013

     
    może plik przy uploadzie został uszkodzony, bo słychać tylko jakieś "pierdy"
    
    pewnie są makra .MACRO i struktury .STRUCT aby było to modyfikowalne i łatwe do rozbudowy
    
    szlifuj warsztat Gonzo, przecież nauczyłeś się sporo nowych rzeczy od czasu swoich pierwszych wprawek, makra nie są takie straszne, struktury też zrozumiesz gdy zauważysz ich zalety w organizacji i dostępie do danych
23. • 23: CommentAuthorGonzo
    • CommentTime26 Jan 2013

     
    chyba rzeczywiście jest coś nie tak - wrzucam jeszcze raz

    • ln2_CharEngine_1xBuf_test2.xex
24. • 24: CommentAuthorGonzo
    • CommentTime26 Jan 2013

     
    ok. - wrzuciłem i otworzyłem z aol. wszystko działa jak trzeba, ktoś może potwierdzić?
25. • 25: CommentAuthorxxl
    • CommentTime26 Jan 2013

     
    u mnie obydwie wersje dzialaja. przepraszam.
26. • 26: CommentAuthorbrx
    • CommentTime26 Jan 2013

     
    Coś chyba mam. Altirra 2.20.
    
    Demonstracja zadziała mi poprawnie tylko przy Firmware -> LLE Kernel (XL/XE Compatible).
    
    Przy użyciu moich atarowskich ROM-ów z dysku kaszani się muzyka. Przy testach z Altirrami ze skasowanymi ustawieniami jakby ma też znaczenie ten FastBoot, z włączonym może być czarny ekran prócz jasnych fragmentów duszka... W każdym razie nic z tego nie rozumiem i nie wiem jak to zinterpretować :)
    
    Bardzo mnie zdziwiły mnie też logi z ładowania (debugger Altirry) czyli cała seria komunikatów "EXE: Jumping to 0414". Wie może ktoś przy okazji co to znaczy?
27. • 27: CommentAuthorVidol
    • CommentTime27 Jan 2013

     
    xex ma konstrukcje:
    0400-045c
    2000-23ff
    init 0414
    .... i tak 20 razy
    wyglada to na przepisywanie zestawow znakow pod rom i stad te "jumping to 0414". Nie wiem tylko czemu jest to robione 20 razy.
    pozatym xex nie szanuje dosa i wczytuje sie pod $1000 co tez moze powodowac klopoty.
28. • 28: CommentAuthorxxl
    • CommentTime27 Jan 2013

     
    aaa, no to wiem dlaczego nie mam klopotu - nie uzywam DoS.
29. • 29: CommentAuthorGonzo
    • CommentTime29 Jan 2013

     
    
    
    mały kroczek do przodu - zawsze to chciałem zobaczyć na a8 :)
    
    na razie nie ma co narzekać, że coś tam, że nie chodzi pod dosem itp, to nie ten etap :)

    • ln2_CharEngine_1xBuf_test3.xex
30. • 30: CommentAuthorGonzo
    • CommentTime1 Feb 2013 zmieniony

     
    jest dobrze, co widać na obrazku :)
    
    
    
    można już pomyśleć o przełączaniu plansz, ale lepiej będzie jeśli najpierw rozmieści się duszki sprzętowe (pochodnie i przedmioty) - i tu jest mały problem z przerwaniami dli.
    
    tebe - hlp!
    plansza składa się z 18 wierszy
    co będzie lepsze:
    zostawić obecny program dli - wszelkie zmiany dotyczące zestawów znaków, kolorów czy duszków dokonywane są w każdym wierszu,
    czy napisać nowy - wtedy zmiany były by dokonywane tylko tam gdzie jest to potrzebne.

    • ln2_CharEngine_1xBuf_test4.xex
31. • 31: CommentAuthorGonzo
    • CommentTime8 Feb 2013 zmieniony

     
    na dzisiaj mam dwie wiadomości - jedna dobra druga niedobra
    najpierw dobra:
    level zmieści się bez kompresji na a8-130
    a teraz niedobra:
    pomimo, że plansze są statyczne to upierdliwość sięga granic, a wynika to głównie z tego, że atarka ma 128 znaków w zestawie :(
32. • 32:
       
      CommentAuthortdc
    • CommentTime9 Feb 2013

     
    Tak... 128 znaków to zmora wszystkich twórców, dlatego tak istotnej zmiany dokonali Avaloni swoim trybem, choć oczywiście każdy próbował to rozwiązać na swój sposób.
33. • 33: CommentAuthorwieczor
    • CommentTime9 Feb 2013

     
    A ile _róznych_ znaków jest naraz na planszy?
    
    Czy plansze sa budowane z bloków czy jak leci? Bo zastanawia mnie to 130... Na spectrum sie miesci w 48 :) Na Commodore w 64... A u nas zawsze musi byc "nowatorsko"? ;)
    
    To tylko pytania - no offence :)
34. • 34: CommentAuthorxxl
    • CommentTime9 Feb 2013

     
    hobgoblin, knight lore czy nightshade sa w trybie znakowym. w hobgoblinie jest 512 roznych fontow na raz na ekranie, w kn i ns po okolo 450. wszystkie te gry chodza na atari 65 xe bez przerobek o dodatkowa pamiec.
35. • 35: CommentAuthorwieczor
    • CommentTime9 Feb 2013

     
    Bo jest jeszcze kwestia jak sa przechowywane pomieszczenia - w LN wyraznie widac jak sie rysuja , sa zbudowane z wiekszych blokow a nie pojedynczych znakow. Bez tego trudno by to bylo pomiescic. Moze by tak jeszcze w oryginale pogrzebac?
36. • 36: CommentAuthorGonzo
    • CommentTime10 Feb 2013 zmieniony

     
    hmm, wszystko się zgadza, tylko, że na c64 wszystkie ruchome obiekty zrobione są na duszkach, a pozatym:
    - mappy krzyczy, że na obrazku jest 1388 znaków
    - engine zostawia tylko 76 znaków na grafikę
    
    
    
    trzeba to jeszcze trochę przetestować, być może jest jakiś sposób, żeby to zmieścić w 64kb, ale wątpię.
    
    to, że jest tu znacznie więcej znaków niż powinno być nie jest dziwne, bo te czarne kropeczki na c64 zrobione są na duszkach, i nie wpływają na ilość znaków.
37. • 37:
       
      CommentAuthorjhusak
    • CommentTime10 Feb 2013 zmieniony

     
    A czy ktoś rozpatrywał tryb graficzny? Co prawda jest tu 5 kolorów...
38. • 38: CommentAuthorGonzo
    • CommentTime10 Feb 2013 zmieniony

     
    w trybie grficznym wygląda to beznadziejnie :(
    
    
    
    pierwszy wiersz ma 157 znaków (pomijam inverse, bo akurat w tym przypadku liczba znaków zmieni się bardzo nieznacznie) - oznacza to, że trzeba by tu użyć min 3 zestawy znaków :(
39. • 39:
       
      CommentAuthorjhusak
    • CommentTime10 Feb 2013 zmieniony

     
    Jeśli używasz spritów hardwarowych, to mogiła, ale jeśli nie, to możesz ów piąty kolor dostać właśnie przy ich pomocy. I będzie wyglądać tak samo.
    
    Warte rozpatrzenia.
    
    Taki Amaurote nie wyglądał by tak, gdyby był w trybie znakowym. Plansze statyczne - bez scrolla i updejtu, - jak znalazł.
    
    W końcu Draconus jest w trybie graficznym i komu to przeszkadza?
    
    Poz tym obrazek jest niemal cały czarny.
40. • 40: CommentAuthorGonzo
    • CommentTime1 Mar 2013 zmieniony

     
    przejść cały level ln2 na a8 - bezcenne ):
    
    
    
    co prawda na razie jest to tylko slideshow, ale jest już blisko :)
    przy przełączaniu plansz trzeba trzymać się pewnych zasad - inaczej grafika będzie się kaszanić:
    - na polu gry nie może być żadnego duszka programowego
    - ninja nie może zbliżyć się na mniej niż jeden wiersz do dolnego panelu
    
    plansze zrobione są w trybie jgp9 i zajmują łącznie: 15(liczba plansz)x32(szerokość ekranu)x18(liczba wierszy)+9(liczba zestawów znaków na każdej planszy)x64(liczba znaków w każdym zestawie)x8(ilość bajtów w każdym znaku)x15(ilość plansz)=8640+69120=77760. wynika z tego, że całość powinna się zmieścić na a8/130.
    
    teraz potrzebne są tylko procki, które umieszczą/skopiują fonty do/z pamięci dodatkowej/podstawowej i zamiast slideshow będziemy mieli demko :)
    
    jhusak - kombinowanie z trybem graficznym chyba nie ma sensu skoro mamy gotowy silnik. dodanie do niego całej reszty będzie chyba prostsze, pozatym do dyspozycji pozostają duszki sprzętowe, na których chcę zrobić pochodnie i przedmioty.

    • ln2_sewers_slide.zip
41. • 41: CommentAuthors2325
    • CommentTime1 Mar 2013

     
    Jak na razie wygląda to moim zdaniem naprawdę dobrze - jak oficjalna wersja, a nie gra złożona w czasie wczytywania gry Ninja z magnetofonu. Główny bohater zdaje się mieć tylko jeden kolor, ale mimo tego raczej nie wygląda jak uciekinier z urządzenia Game & Watch.
42. • 42: CommentAuthorGonzo
    • CommentTime1 Mar 2013

     
    s2325 - ninja jest w jednym kolorze: glewo, gprawo, a w dwóch: dlewo,dprawo. jest tak samo jak na c64 (za wyjątkiem rozdziałki).
43. • 43: CommentAuthorVidol
    • CommentTime2 Mar 2013 zmieniony

     
    nie ma co sie podniecac, skonczy sie tak samo jak prince i pare innych. I tak bedzie dopoki Gonzo nie zmieni swojego podejscia.Zrypac grafe, wstawic w gotowy silnik i moze jakos to bedzie - nie tedy droga. Gry na atari maja i po 200 plansz i mieszcza sie w 64kb, a tu z 15 jest problemem.
    Tlumaczenie ze na c64 sie wszystko miesci bo maja wiecej sprajtow to tylko wygodna wymowka. Tam procedury rysuja plansze a nie gotowce zawalajace pamiec.
    Powiem tak: wiecej myslenia i procedurek mniej slideshow'a.
    PS. Jest jeszcze cos takiego jak kompresja danych(sa gotowe przyklady w madsie) - goraco polecam :)
44. • 44: CommentAuthorbrx
    • CommentTime2 Mar 2013

     
    Gonzo, ale coś poszło naprawdę nie tak... Demonstracja działa źle we wszystkich moich emulatorach (czarne prostokąty i zakłócenia), a co gorsza, naprawdę nie rozumiem dlaczego tak prosty program zajmuje aż pół megabajta danych...
45. • 45:
       
      CommentAuthorTheFender
    • CommentTime2 Mar 2013 zmieniony

     
    Gonzo czytałeś może, jak swego czasu goście z Ultimate poradzili sobie z wciśnięciem plansz Sabre Wulf do ZX Spectrum 48k ? Zapodział się niestety link, ale z tego co pamiętam to właśnie ostro pracowali na kompresją danych i ich dekompresją. Z tego co pamiętam (ale mogę się mylić tutaj) w pamięci trzymane były dane w postaci skompresowanej, zaś szybka dekompresja następowała w momencie wchodzenia na planszę.
    
    Pozatym, jak napisał Vidol - wygląda na to że omijasz swego rodzaju fundamenty pisania programów mających szanse na pomyślne zakończenie :) Czyli właśnie, zmień podejście. Wiele znanych produkcji od lat 80 do dzisiaj w momencie tworzenie wyglądało jak "idź stąd". Dlaczego? Ponieważ po pierwsze robienie grafiki jest czasochłonne, podobnie jak pisanie kodu zresztą. Dobry kod z kiepską grafą będzie działał, dobra grafa z kiepskim kodem - nie. Pozatym mniej grafiki to więcej wolnej pamięci, czyli większe pole manewru przy opracowywaniu kodu. Następny etap to optymalizacja a potem dopiero patrzymy ile zostało ramu i próbujemy tam upchać dane. Wydaje się to być oczywiste. Wybacz za teoretyczne wynurzenia ale pomimo tego że lubię te Twoje próby to z drugiej strony żal patrzeć jak, moim zdaniem marnujesz zapał i siły.
46. • 46: CommentAuthorVidol
    • CommentTime2 Mar 2013

     
    @brx: to ja ci powiem dlaczego.
    Kiedys Gonzo zamiescil 1 plansze ktora zajmowala ok 38kb.
    Teraz powtorzyl to 15 razy zmieniajac dane kazdej planszy i posklejal w jeden plik.Tak wiec po wcisnieciu spacji za kazdym razem wczytuje sie od nowa te 38 kb (kod+dane).
47. • 47: CommentAuthorGonzo
    • CommentTime2 Mar 2013 zmieniony

     
    hmm, dzięki za w miarę wyważone opinie :)
    
    gdyby to było wszystko takie proste i oczywiste, to może ktoś zna odpowiedź, dlaczego nie ma ln2 na a8?
    
    brx - wszystko jest tak jak trzeba, poprostu przełączasz plansze (a właściwie to ładujesz plik) w momencie kiedy duszki programowe są na polu gry (post 40). plik zajmuje tyle, bo to jest na razie tylko slideshow (post 40).
    
    Vidol - nie wiem czy ten projekcik będzie ukończony, ale napewno ma duże szanse.
    
    jeśli chodzi o to co piszesz na temat samego podejścia do tematu, to albo jesteś piątą kolumną z obozu c64, która chce storpedować projekt w zalążku ;) albo nie wszystko do końca rozumiesz i chuchasz na zimne, ale tak samo jak ja chciałbyś, żeby ta gierka (a przynajmniej chociaż jeden pełny level) powstała w końcu na a8 :) silnik tebe to górna półka jeśli chodzi o kodowanie na a8 i tutaj sprawdza się bardzo dobrze.
    
    jeśli chodzi o ograniczenia:
    - duszki sprzętowe na a8 są bezużyteczne (nno prawie)
    - w zestawie znaków mamy do dyspozycji tylko 76 znaków, a w trybie jgp9 (który tutaj zastosowałem) liczba znaków w zestawie nie przekracza 64.
    - grafika całego levelu nie "idzie" w trybie "niższym" niż jgp9
    - tryb jgp9 oznacza, że na każdym obrazku jest 9 zestawów znaków, a że obrazków jest 15, to wszystkich zestawów znaków jest 9x15=135 - tak, to prawda, i to nie jest śmieszne :)
    - wszystko powyżej dotyczy tylko pola gry, do tego trzeba dodać panel
    
    jeśli chodzi o sposób tworzenia grafiki to wg mnie nie jest możliwe użycie tzw. obiektów w taki sposób jak to jest na c64 z uwagi na ograniczenia a8, dlatego podejście musi być inne, i każde inne będzie skazane na niepowodzenie. na tą chwilę każdy obazek zajmuje ok 31kb.
    
    TheFender - o kompresji na razie nie myślę, bo w 64kb to się i tak nie zmieści, a na a8/130 zmieści się i bez kompresowania. nie wiem co rozumiesz przez "mniej grafiki"? nie wyobrażam sobie, żeby zabrać z oryginału chociaż jeden piksel, hmm... co do reszty to wyjaśniłem wyżej. nie ma mowy o tym, żeby było mniej grafiki, a że kod jest z najwyższej półki to musi pójść :)
    
    jeśli ktoś ma lepsze pomysły, to po to jest to forum, żeby je pokazać :)
48. • 48: CommentAuthorilmenit
    • CommentTime3 Mar 2013

     
    "nie wyobrażam sobie, żeby zabrać z oryginału chociaż jeden piksel" - według mnie lepiej zabrać więcej niż jeden piksel, ale projekt ukończyć...
    Niestety, też uważam, że podejście do tworzenia gry jest zupełnie z niewłaściwej strony. Jeżeli gra ma być wierna oryginałowi to trzeba zacząć od rozłożenia oryginału na czynniki piersze, przeanalizowanie każdego kawałka kodu i sprawdzenie, czy jest on do przełożenia na Atari.
49. • 49: CommentAuthorVidol
    • CommentTime3 Mar 2013 zmieniony

     
    Tak wydalo sie jestem rdzennym comodorowcem :P
    
    Widze Gonzo ze Ty ciagle swoje, jak mocher w kosciole:)
    
    "- tryb jgp9 oznacza, że na każdym obrazku jest 9 zestawów znaków, a że obrazków jest 15, to wszystkich zestawów znaków jest 9x15=135 - tak, to prawda, i to nie jest śmieszne :)" - ale te plansz sa dosyc "klockowe" i naprawde uwazam ze nie ma sensu trzymania calych leveli w pamieci i to tak jak pisal Ilmenit moze warto by bylo zajrzec do kodu na c64 i popatrzec na procki co i jak.
    
    Wzioles silnik Tebego i myslisz ze cudownie zalatwi on wszystko. Otoz nie, wyswietli Ci postacie, moze nawet wykryje kolizje ale nic pozatym. A gdzie logika gry,logika przeciwnikow, i 1000 innych (nie)potrzebnych pierdol?
    
    Wydaje mi sie ze uzycie tego silnika jest tu troche na wyrost. Zostal napisany dla uzyskania duzo szybkich obiektow na ekranie, natomiast w LN2 wiecej jak 2 postacie na ekranie to chyba nie ma. Duzo prostszy i mniej wymagajacy pamieciowo silniczek spokojnie by sobie poradzil. Zobacz taka np.Misje: 4przeciwnikow + 4pociski + dzialka + cos kolo 200 plansz i zmiescilo sie to na 64 kb. Jak widac da sie, trzeba tylko chciec :)
50. • 50: CommentAuthorwieczor
    • CommentTime3 Mar 2013

     

    Gonzo:

    dlaczego nie ma ln2 na a8?

    
    
    Bo producenci gier odpuścili sobie tę platformę. A dlaczego jest na spectrum? Pamięci jeszcze mniej, a sprite'ów sprzętowych w ogóle nie ma.
    
    

    Gonzo:

    jesteś piątą kolumną z obozu c64, która chce storpedować projekt w zalążku

    
    
    A może po prostu chciałby - jak i wielu innych - żeby, jeśli już jest robione, było zrobione jak należy? :)
    
    

    Gonzo:

    wg mnie nie jest możliwe użycie tzw. obiektów w taki sposób jak to jest na c64 z uwagi na ograniczenia a88, dlatego podejście musi być inne, i każde inne będzie skazane na niepowodzenie

    
    
    A które ograniczenia masz na myśli, bo ja ich jakoś nie widzę.
    
    Pytanie: kto ma 100% pewności, że w wersji na c64 do animacji bohatera zostały użyte sprzętowe sprite'y? Bo na innych platformach na pewno nie z uwagi na ich brak.