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:
      
     CommentAuthortdc
   • CommentTime15 Jan 2012 zmieniony

    
   W tę środę 18 stycznia na Politechnice Warszawskiej odbędzie się wykład o programowaniu multimediów na małym Atari. Konkretne zagadnienia będą demonstrowane na przykładach konkretnych demek.
   
   Wykład skierowany gównie do młodych ludzi, którzy nie znają dostatecznie dobrze małego Atari, ale programować potrafią doskonale.
   
   
   Info:
   Spotkanie KNTG Polygon, środa 18 stycznia, sala 108, godz. 19:00
   adres: Wydział Elektroniki i Technik Informacyjnych ul. Nowowiejska 15/19 00-665 Warszawa
2. • 2: CommentAuthorYolk (xmgatz)
   • CommentTime15 Jan 2012

    
   Czy wykład będzie nagrywany i udostępniony potem na youtube albo innym podobny portalu?
3. • 3:
      
     CommentAuthortdc
   • CommentTime15 Jan 2012 zmieniony

    
   Nic nie wiadomo na ten temat. Takie spotkania odbywają się co tydzień w atmosferze dość nieformalnej (a teraz nieco podchodzącej już pod Global Game Jam), więc pewnie nikt o rejestracji nie myśli.
   Ale wstęp jest wolny.
   
   
   ps. wykład trwa około 2 godzin.
4. • 4: CommentAuthornosty
   • CommentTime15 Jan 2012

    
   O dzizus... To wlasciwie tak jakby na Wydziale Mechanicznym zrobic wyklad pt. "Przygotowanie Forda T do jazdy w trudnych warunkach pogodowych" :D
   Nie wroze duzej frekfencji ;)
5. • 5:
      
     CommentAuthortdc
   • CommentTime15 Jan 2012

    
   Nie jest tak źle, obecni są już wyedukowani odnośnie Atari, więc wiedzą czego się spodziewać. A frekwencja zwykle jest na spotkaniach mała bo to kółko naukowe, więc rzeszy tam nigdy nie było;)
   
   Poza tym szczegóły techniczne Atari są naprawdę bardzo interesujące dla osób, które są w takim stopniu zainteresowane informatyką aby uczęszczać na takie koło. Już wielokrotnie na różnych targach i innych imprezach wspólnie sprawdzaliśmy zainteresowanie tematami Atari i zwykle było ok, sam pamiętasz;)
6. • 6:
      
     CommentAuthorKaz
   • CommentTime16 Jan 2012

    
   Nosty - gdybym byl studentem mechaniki to z dzika przyjemnoscia zobaczyl, jak dziala i wyglada Ford T. Teraz takiej prostoty nie uswiadczysz...
7. • 7:
      
     CommentAuthortdc
   • CommentTime20 Jan 2012 zmieniony

    
   Na wykładzie można było zobaczyć demka: C-Drug oraz produkcję Our 5oftów, Kuby Husaka i innych;)
   
   Sala była pełna studentów, byli też licealiści oraz dwóch przedstawicieli Atarowców. Młodzi ludzie raczej się nie nudzili i zadawali wiele szczegółowych i konkretnych pytań. Przykładowo co spowodowało że Probe zabrał się za kodowanie na Atari;) To dla młodych ludzi bliski temat, bo widać im to do głowy nie przyszło:P
8. • 8:
      
     CommentAuthorDracon
   • CommentTime20 Jan 2012 zmieniony

    
   TeDeC,
   a mozesz to rozwinac, bo nie pamietam juz np. powodow dlaczego Pr0be zaczal kodowac na 8-bitach w XXI w. a Stryker (rocznik '83) wciaz bawi sie w maloatarowska elektronike... ;)
   
   Co mowisz o tym spragnionym tych wiadomosci studentom?
9. • 9: CommentAuthorjakubd
   • CommentTime20 Jan 2012

    
   Asz, kurcze - jakbym wiedział, to bym wpadł z kamerą i nagrał dla potomnych :)
10. • 10: CommentAuthor0xF
    • CommentTime20 Jan 2012

     
    Fajna inicjatywa. Trzeba uświadamiać młodych ludzi, że nie potrzeba gigabajtów i gigaherców, żeby zaprogramować coś działającego szybko i płynnie. Niestety braki w wiedzy tzw. specjalistów IT są tu ogromne.
11. • 11:
       
      CommentAuthortdc
    • CommentTime21 Jan 2012

     
    @Dracon
    Nie mam pojęcia i też mnie to interesuje. Myślę że najlepszym rozwiązaniem jest aby spytał się o to Kaz i zamieścił odpowiedz na głównej;)
    
    
    @0xF
    Tak braki są ogromne, bo uczelnie tego nie uczą. A z tego co widzę studenci, którzy się tym zajmują to wcześniej się sami tego nauczyli.
12. • 12: CommentAuthorat0mic
    • CommentTime25 Feb 2012

     
    apropos programowania na małym Atari:
    
    jak spadają kamienie w Boulder Dash z 1984 roku?
    
    tzn ja wiem że są przepisywane zawartości widocznej mapy ekranu tekstowego jeśli pod kamieniem jest puste pole (cztery fonty), ale jak to jest sprawdzane dla wszystkich kamieni w całej mapie i w każdej ramce, bo przecież kamienie lecą nawet jeśli są poza widocznym wycinkiem ekranu na którym jest Rockford...
    
    Ta gra jest piękna!
13. • 13:
       
      CommentAuthortdc
    • CommentTime25 Feb 2012

     
    Jeśli sprawdzisz jeden z tych czterech fontów to czterokrotnie przyspieszysz algorytm, a działać będzie tak samo dobrze.
    
    Sprawdzenie choćby 20 takich ifów na ramkę nie stanowi problemu dla 6502.
    
    Dla mnie istotnym problemem jest to jak zaczynają spadać wszystkie niezbędne kamienie bo to można rozwiązać na wiele sposobów. A odpowiedzią jest zerknięcie do kodu, jakie ostatnio zrobił Kuba odnośnie gry Amaurote. Jest ktoś chętny?;)
14. • 14: CommentAuthorat0mic
    • CommentTime25 Feb 2012

     
    w pierwszej planszy jest 121 kamieni ;)
    
    za słabo się znam na matrixie kodu atari, nie widzę gdzie są ekrany tekstowe gdzie charset itp.
    
    Ciekawi mnie to jednak bardzo i poszukuję (może jest) jakiś program do podglądania P/M, fontów, grafiki, wycinania muzyki itp.
    
    Czy motylki i diamenty są animowane przez zamianę fontów na ekranie tekstowym z kolejnymi klatkami czy dynamicznie zmieniany jest generator znaków?
15. • 15: CommentAuthorsolo/ng
    • CommentTime26 Feb 2012

     
    @at0mic: najbanalniej to np:
    
    plansza zapewne trzymana jest w 1 znakowych tokenach (zamist 2x2 znaki).
    
    nastepnie takie dane planszy przelatujemy linia po linii szykajac znaku "kamien"
    
    jak znalezlismy robimy dodatkowe sprawdzenie czy pod tym znakiem jest puste pole. Jezeli tak - przesuwamy kamien o 1 w dol.
    
    Skanowanie robimy od dolu do gory mapy.
    
    kiedys sobie napisalem takie cos, bo pisalem swojego boulder dasha for fun ;o
    
    Mozna byloby to rozbudowac, aby sprawdzac sprytniej, kwestia, ze nie ma po co bo w 1 ramce sie wyrabia wszystko na luzie
16. • 16:
       
      CommentAuthortdc
    • CommentTime26 Feb 2012

     
    Czyli niezawodny brute-force;)
17. • 17:
       
      CommentAuthorjhusak
    • CommentTime26 Feb 2012 zmieniony

     
    Panowie, a co jeśli spada kamień na kamień, a z boku nic nie ma? Robi się więcej możliwości :)
    
    Ale tak naprawdę, to Boulder dash działa w krokach ok 6/sekundę (tak z pamięci, jak to szybko chodzi) - czasami szybciej - być może jest to po prostu opóźnienie planszy? Jeśli tak, to wszystko tłumaczy.
    
    Algorytm, jak TDC napisał, przy czym na każde puste/wybuchowe miejsce pod spodem sprawdzane są 3 pola: ponad w górę, i jeśli spada, to alg. się kończy. podobnie kamień w lewo górę i w prawo górę, ale tutaj widzę symetrię, więc na pewno raz bierze lewy a raz prawy.
    I wygląda na to, że sprawdza jeden kamień za jednym razem a robi 3 razy.
    
    i to nie jest brute force :) To jest przeszukiwanie całego pola gry. Aczkolwiek można tak o tym myśleć, jednak takie podejście nazywa się często podejściem naiwnym. Podejście naiwne ma tutaj głębokie uzasadnienie - prostota gry i wymagania na prędkość są spełnione - to po co udziwniać?
    
    Swoją drogą BD to automat komórkowy :)
    
    I generalnie jest tak, jak solo/ng napisał z powyższym uzupełnieniem, ale z tą ramką bym nie szarżował. Jest jeszcze przepisanie planszy na obszar widoczny (ale to można sprytnie zrobić - tylko przemieszczenia)
    
    A policzmy z tą ramką: jest 1600 pól gry - 156 (ramka)
    
    i już adresowanie pola to najlepiej 4 cykle (indeksowane), porównanie to 2 cykle, niewykonanie skoku 2 cykle, zwiększenie indeksu to 2 cykle, skok to 3 cykle.
    
    Razem przy braku reakcji koszt jest najmniejszy - 12 cykli przy rozwiniętej pętli i braku skoku (adresowanie pośrednie strony zerowej postindeksowane) lub 13 cykli zwykła pętla.
    
    13 x 1500 = 19500 cykli. W ramce się wyrabia z palcem w nosie.
    Trzeba dodać jeszcze z setkę na zwiększanie starszego bajtu.
    
    Samo sprawdzenie się uda, ale na update planszy i logikę trzeba drugą ramkę albo 2 przeznaczyć, albo jeszcze więcej, jeśli przypadek pesymistyczny.
    
    I mamy taką prędkośc, jaką mamy w BD.
    
    Dla mnie majstersztykiem jest BD na a2600. Cart kosztuje 76 dolców :)
    MUSI mieć pamięć na carcie, przynajmniej te 2 kb.
18. • 18:
       
      CommentAuthortdc
    • CommentTime27 Feb 2012 zmieniony

     

    jhusak:

    Samo sprawdzenie się uda, ale na update planszy i logikę trzeba drugą ramkę albo 2 przeznaczyć, albo jeszcze więcej, jeśli przypadek pesymistyczny.

    
    Jeśli będziemy mieli dwa obszary na pamięć obrazu to zmiana obszaru może być zrealizowana zmianą adresów w DL, czyli zajmie to bardzo mało czasu.
    
    Co do logiki, to faktycznie w grze odbywa się znacznie więcej (zmiana w diamenty, lawa itp.), ale tak jak pisałeś skoro nie musi to działać w ramce to nie stanowi to problemu.
    
    Problem jest na np. ZX Spectrum, gdzie gra działa okropnie skokowo. Podobnie jest na C64 i Amstradzie.
    
    update:
    Aha przypomniał mi się jeszcze taki murek, przez który przelatują kamienie i zamieniają się w diamenty. Jeśli wpadający kamień nie pojawia się od razu za murkiem jako diament to wtedy trzeba jakoś pamiętać te kamienie, co może świadczyć o tym że to jednak jest jakoś inaczej zrealizowane (coś co umożliwia samoczynnie zrealizowanie czegoś takiego).
19. • 19: CommentAuthor0xF
    • CommentTime27 Feb 2012

     
    Analizowałem kod BD kilkanaście lat temu przy okazji konwersji na PC. Najczęściej spotykaną instrukcją jest tam JSR. :)
    
    Zgadza się, przeglądana jest cała plansza i animowane wszystkie elementy na niej. Jeśli kamień wpadnie w magiczny murek, a po drugiej stronie nie ma miejsca, to po prostu znika.
20. • 20: CommentAuthorat0mic
    • CommentTime27 Feb 2012 zmieniony

     
    @0xF
    
    czy plansza ma osobną mapę gdzie są sprawdzane zależności z mniejszych klocków i dopiero potem rysowana czy wszystko dzieje się bezpośrednio w planszy którą widac, a może są dwie plansze jedna wyświetlana a na drugiej są dokonywane zmiany i później zmieniane tak jak w grafice buforowanej 3d?
    
    @tdc
    nie zauważyłem różnicy w prędkości na a8 i c64.
    
    Różnica jest natomiast taka że ekran w BD na a8 jest szerszy niż w c64 o dwa kursory ale za to plansza tytułowa jest niższa o kursor niż ta w c64. Nie ma to jednak nic do grywalności ani płynności. Różnice są dostrzegalne tylko w kolorach.
    
    
    ________________________
    Boulder Dash na C=64
    
    
    Grafika w charsecie pod adresem $3000-$37ff
    Ekrany (podwójnie buforowany) 1ekran $0C00-$0FE7
    2ekran $2C00-$2FE7
    wszystko wyliczane w buforze który akurat nie jest wyświetlany.
    
    charset nie jest modyfikowany dla animowanych elementów takich jak:
    wybuch i pojawienie się rokforda
    tylko przepisywane są fonty o kolejnych wzorach klatek animacji.
    
    Charset jest modyfikowany dla animowanych:
    motylków,
    diamencików,
    lawy,
    murka (kiedy przerabia głazy na diamenty)
    neonowych kwadratów itp
    komnaty są skompresowane w pamięci do 6 bitowych rozmiarów które dekompresowane są na większe bloki 4 bajtowe.
    
    
    6 bitów to zdecydowanie za dużo jak na różne rodzaje paternów potrzebne do budowy jednej planszy więc nadmiarowe informacje mówią o tym ile razy występuje ten sam element po kolei.
    
    komnata A to zaledwie:
    
    

    01 14 0A 0F 0A 0B 0C 0D 0E 0C 0C 0C 0C 0C 96 6E
     46 28 1E 08 0B 09 D4 20 00 10 14 00 3C 32 09 00
     42 01 09 1E 02 42 09 10 1E 02 25 03 04 04 26 12
     FF

    
    komnata B to :
    
    

    02 14 14 32 03 00 01 57 58 0A 0C 09 0D 0A 96 6E
     46 46 46 0A 04 09 00 00 00 10 14 08 3C 32 09 02
     42 01 08 26 02 42 01 0F 26 02 42 08 03 14 04 42
     10 03 14 04 42 18 03 14 04 42 20 03 14 04 40 01
     05 26 02 40 01 0B 26 02 40 01 12 26 02 40 14 03
     14 04 25 12 15 04 12 16 FF

    
    pierwsza cyfra mówi o numerze komnaty dla 01-A, dla 02-B itd #$FF zawsze na końcu
    to udało mi się wydedukować poprzez dłubanie w pamięci zrzutu z emulatora VICE.
    
    

    niestety mimo tego odkrycia nie umiem narysować komnaty z jej skompresowanych danych, jednak przez wpisanie swoich warości plansza zmienia zawartość

    
    
    Kolejnym odkryciem są dwa kodowania na diamenty.
    Może po to że jak rockford "zbierze" ruchomy diament to ten go zabije i jest wybuch a jak wejdzie na nieruchomy to zliczane są punkty słychać charakterystyczny odgłos i diament znika.
    
    
    
    Jak to jest w Atari ?

    • C64BD.png
    • atariBD.png