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: CommentAuthorEagle
   • CommentTime15 Mar 2011 19:03 zmieniony

    
   Nie mam bladego pojęcia o Action! ale myślę że chyba ma możliwość operowania Hex.
   Wtedy wszystko jest prostsze.
   Display list zaczynamy przeważnie od pustych lini czyli $70
   Potem trzeba załadować dane ekranu czyli dla trybu 4-antica to będzie 4+$40 ($40 czyli ustawienie 6 bitu włączającego LMS) czyli $44
   potem zależnie od ilości lini potrzebnych
   4 - jedna linia w trybie 4
   4
   4
   ...
   ...
   ...
   i na końcu JVB czyli $41 potem adres poczatku DisplayListy (czyli DLIST który ty wpisałeś w POKE)
   Jak chesz użyć DLI to dodajesz tylko do danej lini $80 np. masz 4 tryb plus LMS i DLI to wtedy 4+$40+$80 i masz $c4
   więcej masz tutaj
   ->link<-
   
   W systemie dziesiętnym to ja tylko piwo w sklepie kupuje ;)
   Warto się Hexa nauczyć, uprości Ci to życie w przyszłości.
2. • 2:
      
     CommentAuthorxeen
   • CommentTime15 Mar 2011 20:03

    
   pewnie już to widziałeś, ale tutaj idea DL jest prosto wytłumaczona.
   
   ->link<-
   
   co do DLI:
   dwa bardzo proste przykłady, wprowadzenie:
   ->link<-
   
   optymalizacja (czyli więcej zmian w jednej linii) - polecam ten wątek (widzę, że już założyłeś własny:)
   ->link<-
3. • 3:
      
     CommentAuthorinsert
   • CommentTime15 Mar 2011 20:03

    
   o kurcze, dzieki Panowie, odezwe sie niebawem jak to przetrawie :)
4. • 4:
      
     CommentAuthorinsert
   • CommentTime15 Mar 2011 20:03

    
   z tego linku i opisu: ->link<-
   
   nie rozumiem tego:
   
   112 Address of the first line of screen data
   158 158 * 256 + 112 = 40560
   
   co to jest za liczba 158, skad? tak samo jak liczby 112 i 256?
   
   oraz ta sama sytuacja z tym:
   
   88 Address of display list itself
   158 158 * 256 + 88 = 40536
   (return to the top of this list)
5. • 5: CommentAuthorEagle
   • CommentTime15 Mar 2011 20:03 zmieniony

    
   Jest tam linie wczesniej
   >71 GR.2 with LMS instruction added
   czyli tryb 2 plus LMS - czyli zaladowanie adresu danych ekranu
   wiec potem trzeba podać młodszy i starszy bajt
   zeby obliczyc adres mnozymy starszy przez 256 i dodajemy potem mlodszy i mamy adres.
   W hexa z oczywistych powodow nic nie trzeba tak obliczac bo wtedy jest wszystko jasne i czytelne.
   Jak mamy np.
   $44 - tryb 4 plus LMS
   $90 - młodszy bajt
   $a0 - starszy bajt
   czyli adres ekranu mamy $a090 (zamieniamy tylko kolejnośc)
6. • 6:
      
     CommentAuthorinsert
   • CommentTime15 Mar 2011 21:03

    
   ok pytanie typowo actionowe:
   mam taki kod:
   
   BYTE ARRAY DLIST =$9000
   
   byte array dlist1 =
   [
   $70 $70 $70
   $44 $00 $81
   4 4 4 4 4 4 4 4 4 4 4 4
   4 4 4 4 4 4 4 4 4 4 4
   $41 $00 $90
   ]
   
   BYTE KEY=764
   
   dlist=dlist1
   
   POKEC(560,DLIST)
   
   jako ze nie moge na raz zadeklarowac tablicy zawierajacej display liste i wskazujacej jej miejsce w pamieci robie to wlasnie w taki sposob, czy da sie to zrobic inaczej?
7. • 7:
      
     CommentAuthorjhusak
   • CommentTime16 Mar 2011 02:03 zmieniony

    
   A to działa? Wg mnie nie.
   ;To deklaruje tablicę bajtów pod adresem $9000, jasne:
   BYTE ARRAY DLIST =$9000
   
   ;To deklaruje tablicę w bieżącym nurcie programu, jasne:
   byte array dlist1 =
   [
   $70 $70 $70
   $44 $00 $81
   4 4 4 4 4 4 4 4 4 4 4 4
   4 4 4 4 4 4 4 4 4 4 4
   ; tu jest domniemany reload licznika pamięci ekranu spod adresu $9000?
   $41 $00 $90
   ]
   
   ; obsolete
   BYTE KEY=764
   
   Pod pamięć ekranu wpisujemy adres display listy?
   dlist=dlist1
   
   Pod wektor display listy wpisujemy pamięć ekranu?
   POKEC(560,DLIST)
   
   Nie ma szans.
   
   EDIT:
   Tzn. ma, zgodnie z uwagą w następnym poście, że DLIST jest uaktualniane co przerwanie pionowe. Jednak jest to błąd, który ujawni się jak tylko wyłączysz przerwania np. na dostęp do ramu pod romem :)
8. • 8:
      
     CommentAuthorjhusak
   • CommentTime16 Mar 2011 02:03

    
   W skrócie powinno być schematycznie tak:
   gdzieś w kodzie jest display lista, display lista nie może przekraczać swoim ciałem bloku 4KB (czyli zaczynać w jednym a kończyć w drugim)
   
   card SDLSTL=560
   
   SDLSTL=ta właśnie lista.
   
   A display lista ma 2 rozkazy odwołujące się do adresów (lub 3, jeśli pamięć ekranu przekracza bloki 4KB):
   Pierwszy rozkaz to ustawienie licznika pamięci ekranu, ew drugi.
   Na końcu jest pętla - "skok" do początku dl".
   
   Czyli:
   
   Wg mojej pamięci:
   zawartość SDLSTL jest kopiowana do DLIST ($D402) podczas pionowego przerwania. Jeśli to wyłączyć można stworzyć dwie alternatywne Display listy, przełączać się pomiędzy nimi i uzyskiwać tryb interlace bez zaangażowania procesora i pisania kodu. Kodu wymagają zmiany w rejestrach kolorów oraz np. zmiana trybu GTIA.
   
   Twój kod jest równoznaczny (hm, teraz to on powinien działać) z:
   
   BYTE ARRAY screen =$8100 ; przyda się później
   
   byte array dlist1 =
   [
   $70 $70 $70
   $44 $00 $81 ; tutaj jest ładowanie adresu ekranu
   4 4 4 4 4 4 4 4 4 4 4 4
   4 4 4 4 4 4 4 4 4 4 4
   $41 $00 $00 ; skok, który i tak jest przeładowywany podczas VBLANK
   ]
   
   POKEC(560,dlist1) ; lepiej SDLSTL=dlist1
   
   Napisałem $00 $00 w skoku do początku DL, bo nie widzę łatwego sposobu na zrobienie tego podczas kompilacji. Powinno to być ustawione na adres DL w pierwszych instrukcjach programu.
9. • 9:
      
     CommentAuthorjhusak
   • CommentTime16 Mar 2011 02:03

    
   Filozofia Action:
   
   Składnia programu i konstrukcje przystosowane do JEDNOPRZEBIEGOWEJ kompilacji, czyli właściwie translacja na kod maszynowy + proste elementy optymalizacji kodu.
   
   Każda instrukcja jest tak zaprojektowana.
   
   Minusy: nie można np. używać adresów zmiennych we właśnie tworzonym przez kompilator kodzie.
   
   Co innego jeśli chodzi o definicje (DEFINE), one mogą być użyte podczas kompilacji, o ile to, do czego się rozwijają, nie jest dynamiczne (tzn może być obliczone podczas kompilacji)
   
   Patrz na to jak na tłumaczenie książki :)
   
   W Action! nie jest możliwe skakanie po pamięci z generowanym kodem, musiałby to wszystko pamiętać i zapisywać potem z odpowiednimi nagłówkami dosa. Kod jest odzwierciedleniem źródła właściwie 1:1, stąd użyłem słowa "translacja"
10. • 10:
       
      CommentAuthorinsert
    • CommentTime16 Mar 2011 10:03

     
    o ja, hardcore, musze sie przez to przegryzc :/ dzieki Jakub
11. • 11:
       
      CommentAuthorinsert
    • CommentTime16 Mar 2011 10:03

     
    jako ze moj pierwszy kod dziala to postaram sie napisac co chcialem tym osiagnac, wiec:
    
    BYTE ARRAY DLIST =$9000
    
    deklaruje tablice pod adresem 9000 (dowolny adres byle byl wolny)
    
    byte array dlist1 =
    [
    $70 $70 $70
    $44 $00 $81
    4 4 4 4 4 4 4 4 4 4 4 4
    4 4 4 4 4 4 4 4 4 4 4
    $41 $00 $90 ($00 $90 to adres display listy)
    ]
    
    tutaj deklaruje tablice z rozkazami dla antic'a
    
    dlist=dlist1
    
    przepisuje zawartosc tablicy zawierajacej rozkazy anticowe do tablicy ktora mam pewnosc ze lezy pod konkretnym adresem
    
    POKEC(560,DLIST)
    
    wrzucam dane aby uruchomic display liste
    
    dlaczego tak robie: poniewaz display lista wymaga ode mnie okreslenia na koncu skoku do adresu jej poczatku, a w action nie moge na raz jak sam Jakubie napisales zadeklarowac tablicy i przypisac ja pod konkretny adres
    
    dlaczego mialo by to nie dzialac?
    
    Twoj listing ostatni tez dziala, ale zastanawiam sie czemu skoro skaczesz na koniec jak napisales pod $0000
12. • 12:
       
      CommentAuthorjhusak
    • CommentTime16 Mar 2011 21:03 zmieniony

     
    Bo ten skok jest potrzebny tylko, jak się wyłączy przerwanie pionowe. W p. p. rejestr - cień zostanie przepisany do DLIST podczas właśnie przerwania.
    
    Twój kod może działa, ale nie tak, jak chcesz. Jakbyś zdizasemblował, tobyś się za głowę zlapał.
    
    

    dlist=dlist1
    
    przepisuje zawartosc tablicy zawierajacej rozkazy anticowe do tablicy ktora mam pewnosc ze lezy pod konkretnym adresem
    

    
    
    Insert, pewność w informatyce nie istnieje. W programowaniu też.
    To znaczy istnieje, na 99%, na 90% albo na 50%.
    
    Test:
    
    1. Skompiluj twój kod
    2. przejdź do monitora
    3. wpisz ? DLIST
    4. uruchom program - R
    5. jak się skończy: ? DLIST
    
    I co Ty na to?
    Niespodzianka :)
    DLIST ma tę samą wartość co dlist1 :) Przepisałeś WSKAŹNIK.
    
    Aby naprawdę przepisać pamięć musisz użyć instrukcji moveblock.
    
    Action to porządny kompilator, JAK NA 16 KB PAMIĘCI (mem manager, kompilator, edytor, monitor, biblioteka standardowa (!)). Nie spodziewajmy się po nim zbyt wiele. To jest niestety tylko translator, prostszy niż BASIC.
13. • 13:
       
      CommentAuthorinsert
    • CommentTime16 Mar 2011 21:03 zmieniony

     
    aa, ok :) teraz widze ze mam jednak tak powaze braki w ogolnie zrozumieniu dzialania samego sprzetu ze az strach, czym to nadrobic najlepiej?
14. • 14:
       
      CommentAuthorjhusak
    • CommentTime16 Mar 2011 22:03 zmieniony

     
    małymi kroczkami. Ja bym się nie przejmował, tylko robił swoje :)
    Każdy taki szczegół wzbogaca Twoją wiedzę.
    
    Niestety, w programowaniu trzeba mieć pewność, że to, co robisz zadziała tak jak Ty chcesz, a nie jak chciałbyś, żeby zadziałało. Wtedy sukces. W p. p. frustracja.
    
    Teraz już wiesz, jak działają tablice, że można zmieniać ich adres :) chociaż nie polecam, chyba, że do jakichś trików.
    
    Kiedyś pisałem, że ja używałem Action jako MacroAssemblera. Pisze się szybko a i kod dość porządny. Jednak nie można, poza prostymi przypadkami, zaniedbać technicznej strony: kod w modułach (oddzielnie dla gry, oddzielnie dla czołówki, oddzielnie dla creditsów, czuwanie nad zajętoścą pamięci itp. itd.)
    Wspólne rzeczy do biblioteki. Grafika, muzyka, itp pod określone adresy binarnie. Niestety, trochę zabawy jest przy składaniu tego w kupę, ale przy pisaniu dużo łatwiej.
    
    Polecam też:
    set 14=adres
    set $491=adres
    jako kompilacja od podanego adresu (z pewnością zamaże edytor i być może dos :) - dlatego tylko z zewnętrznego pliku w monitorze.
    
    i jeszcze ? * , żeby się dowiedzieć, gdzie się skończył program.
15. • 15:
       
      CommentAuthorjhusak
    • CommentTime16 Mar 2011 23:03 zmieniony

     
    A jeśli chcesz mieć wszystko pod kontrolą, to tylko assembler. Satysfakcja ze 100 bajtowego działającego kodu ogromna. Ale gry się nie da szybko napisać. Dzisiejsze narzędzia pozwalają stworzyć kod do gry w kilka dni.
    Gorzej z grafiką. Ale w assemblerze to są czasy 5-10 razy dłuższe!
    
    A, i z tym hexem trzeba się przestawić - to jest proste dość, a jakże ułatwia!
    
    $100 - 256 bajtów
    $1000 - 4 KB
    
    Adres na program $2000-$a000 wliczając pamięć ekranu i Action. Po wyjęciu carta $2000 - $c000. Przy założeniu, że nie używamy dosa, nawet $600 - $c000. A jeszcze jest pamięć pod SO.
16. • 16:
       
      CommentAuthorinsert
    • CommentTime16 Mar 2011 23:03

     
    dzieki Jakub, poki co zostane przy Action, jakos nie widze sie w klepaniu w assemblerze, mam jedynie drobne doswiadczenie w programowaniu w pascalu a najbardziej podobny na a8 jest wlasnie action, troche sie zalamalem ze tak duzo nie wiem ale moze jak piszesz malymi krokami do celu trafie :)
17. • 17:
       
      CommentAuthortdc
    • CommentTime17 Mar 2011 04:03 zmieniony

     
    Insert - nie poddawaj się !;)
    Ci którzy się tu teraz wymądrzają :P też tak kiedyś zaczynali (oczywiście ze mną na czele !:)
    
    Tyle że wtedy nie było netu, mądrych kolegów, książek – przy odrobinie szczęścia czasami było jakieś xero, ale literki w kolorze jasnoszarym, a treść napisana takim językiem, że autor i tłumacz również nie wiedzieli o co chodzi :P Zajmował się tym kiedyś niezrównany Klaudiusz Dybowski (red. nacz. C&A), jeśli dobrze pamiętam to znalazł w jakieś książce algorytm garbowania pamięci :D
    
    
    W mojej ocenie najcenniejsza w nauce programowania (i nie tylko programowania) jest bardzo duża siła woli, z mojego doświadczenia wynika, że odpadają właśnie nie ci za głupi, ale ci co się poddali za wcześnie.
    
    Dlatego posłuchaj dobrego kolegi Kuby i uruchom w swoim mózgu następujący program:
    

    10 pisz program w Action!
    20 control+shift+M
    30 c
    40 r
    50 powrót z programu
    60 e
    70 GOTO 10
    RUN
    

    
    
    

    insert:

    BYTE ARRAY DLIST =$9000

    
    Ponieważ dobrą zasadą jest KISS, to ja bym proponował zamiast zadręczać się na kolejnej stronie tego wątku: 1. zrobić sobie tablicę z wymarzonym DL 2. skopiować to moveblock lub pętlą pod dowolny adres 3. zapisać ten fragment pamięci do pliku, a potem już tylko go wczytywać (z źródła usunąć wszystkie zapisy tablicy itp.)
    
    Do tego możesz sobie jedynie zostawić plik z tą tablicą w Action! bo są spore szanse że jakieś drobne zmiany będą potrzebne w tym DL za jakiś czas (np. dodanie przerwań itp.).
    
    
    

    jhusak:

    Ale gry się nie da szybko napisać. Dzisiejsze narzędzia pozwalają stworzyć kod do gry w kilka dni.

    
    Eeee tam;) gra na GGJ powstała w 2 dni, a ludzie działający na pecetach (i innych) często nie zrobili gry, nawet pracując w wieloosobowych teamach. Popełniali wiele błędów, na różnych etapach, można oczywiście się spierać czy działając w pojedynkę by im to lepiej wyszło, jednak fakty są takie że sukces w 48 h nadal jest wyzwaniem. Wspomnijmy o teamie „Amiga rulez”, który również nie dotrwał do finału mimo że to co im już działało było bardzo fajne.
18. • 18:
       
      CommentAuthorKaz
    • CommentTime19 Mar 2011 12:03

     
    Nie wiem, czy to sie przyda do nauki programowania i pisania gier przygodowych, ale Asal swego czasu rozebral na czynniki pierwsze gre "Spellbound", opisal kod, lokacje, przedmioty, itd. Mozna zapoznac sie z tym tutaj:
    
    ->link<-
19. • 19:
       
      CommentAuthortdc
    • CommentTime19 Mar 2011 18:03

     
    Ciekawe to opracowanie Spellbounda.
20. • 20:
       
      CommentAuthorjhusak
    • CommentTime21 Mar 2011 12:03

     

    tdc:

    Ponieważ dobrą zasadą jest KISS
    

    
    
    Popieram. Często ją stosuję :)
21. • 21: CommentAuthordhor
    • CommentTime21 Mar 2011 13:03

     
    @insert
    
    To nie rób skomplikowanej gry - zrób jakąś przygodówkę point'n'click. Takich na atari nie ma za wiele.
22. • 22:
       
      CommentAuthorinsert
    • CommentTime21 Mar 2011 15:03

     
    po kilkugodzinnym boju z Konopem podczas forevera powaznie zastanawiam sie nad sensem daleszej nauki action :/ bycmoze gre sprobuje jednak pisac w c
23. • 23:
       
      CommentAuthorjhusak
    • CommentTime21 Mar 2011 21:03

     
    Zawsze C toć standard jest.
    
    Ponieważ jest cross-compiler cc65, na pewno kod będzie lepszy/krótszy/etc. Chyba, że używa się skomplikowanych instrukcji.
    
    Ja często sprawdzam co mi kompilator wypluwa, w ten sposób uczę się optymalniej kodować podeń. Tak jest z atalanem, było i z Action!, jest i z C pod atmegę.
    
    Dotyczy wyłącznie 8bit - na 32 nie zamierzam sprawdzać jakości kodu :)
    
    
    Kwestia, czy chcesz kodować w Action!, czy kodować :)
24. • 24: CommentAuthorxxl
    • CommentTime21 Mar 2011 21:03

     
    :-) insert ale nauka action! nie poszla w las, dzieki niej doszedles do prawidlowego wniosku :-)
25. • 25:
       
      CommentAuthorinsert
    • CommentTime21 Mar 2011 23:03

     
    oczywiscie nie ma czego zalowac, po prostu wyszlo na jaw ze w action nie zrealizuje dokladnie tego co planowalem :/
26. • 26:
       
      CommentAuthortdc
    • CommentTime22 Mar 2011 08:03

     

    xxl:

    :-) insert ale nauka action! nie poszla w las, dzieki niej doszedles do prawidlowego wniosku :-)

    
    Chciałeś powiedzieć że uległ kilkugodzinnej indoktrynacji ;):)
    
    
    A tak poważnie insert to, na razie uczyłeś się tego co i pod C będziesz się musiał dalej uczyć (tyle że od nowa). Mam namyśli to że poznałeś np. jak korzystać z fontów, dl itp.
27. • 27:
       
      CommentAuthorjhusak
    • CommentTime22 Mar 2011 14:03

     
    tdc ma rację.
    C nie jest łatwiejszy, niż Action!.
28. • 28: CommentAuthorxxl
    • CommentTime22 Mar 2011 14:03

     
    ale za to:
    1. c ma dzialajacy kompilator,
    2. kroskomiler,
    nie mowie ze action! jest zly, mozna sobie popykac ale jesli masz wiekszy projekt to lepiej zastanowic sie nad wyborem odpowiedniego narzedzia, chyba ze lubisz skupiac sie na sposobie rozwiazywania problemow z kompilacja.
29. • 29:
       
      CommentAuthorinsert
    • CommentTime22 Mar 2011 15:03

     
    wedlug mnie c jest duzo trudniejszy od action, ale nic na to nie poradze po prostu action sie nie nadaje do wszystkiego
30. • 30: CommentAuthorBluki
    • CommentTime22 Mar 2011 16:03

     
    A Forth? Powstało przecież kilka gier.
31. • 31:
       
      CommentAuthorinsert
    • CommentTime22 Mar 2011 16:03

     
    nie chce juz ryzykowac kolejnych paru miesiecy sleczenia nad jakims jezykiem aby na koniec okazalo sie ze cos jest albo niewykonalne ale dziala "przypadkiem" :)
32. • 32:
       
      CommentAuthortdc
    • CommentTime22 Mar 2011 16:03 zmieniony

     

    xxl:

    1. c ma dzialajacy kompilator,

    
    a w Action! kompilator nie działa ? Ja nic o tym nie wiem.
    
    

    xxl:

    jesli masz wiekszy projekt to lepiej zastanowic sie nad wyborem odpowiedniego narzedzia

    
    Po pierwsze inserta kiedyś pytałem o to dlaczego Action! i co chce w nim robić, ale nie chciał o tym mówić, stwierdził że będzie pisał prostą grę i do wszystkiego wystarczy Action! Bardziej był zainteresowany praktycznymi problemami jak coś wczytać, zapisać niż tak fundamentalnymi kwestiami.
    Dlatego być może tak szybko udało się Konopowi przekonać inserata lub może właśnie nastąpiło tu jakieś nieporozumienie itp.
    
    Po drugie ja też odradzam Action! do dużych rzeczy, jednak insert nie chciał słyszeć np. o asm i nietrudno go zrozumieć, w asm pisze się ciężko i dłużej. Ja jestem zwolennikiem asm jednak w tym wypadku dla inserta zdecydowanie lepszy będzie jakiś kompilator.
    
    

    insert:

    wedlug mnie c jest duzo trudniejszy od action

    
    Jeśli się masz C uczyć to jest duuużo trudniejszy, ma znacznie bardziej skomplikowaną składnię, błędy w kodzie będą znacznie trudniejsze do odnalezienia. No i optymalizacja kodu to jest najwyższa liga, w Action! można coś zoptymalizować po prostych zmianach kodu, w C zmiany mogą być trudne do zrozumienia dla osoby uczącej się i mogą też prowadzić do wielu błędów, które uniemożliwią ukończenie programu (w końcu mało kto będzie chciał Tobie pomóc znaleźć błąd w kodzie który ma np. 30 kb).
    
    Zaletą C jest to, że ma większe możliwości, jest ciekawszy (choć to pewnie nie jest dla Ciebie zaletą), masz w nim wiele fajnych rzeczy np. wielowymiarowe tablice o które pytałeś itp.
    
    

    insert:

    ale nic na to nie poradze po prostu action sie nie nadaje do wszystkiego

    
    Action! nie jest językiem idealnym, ale z drugiej strony nie znam rzeczy do której Action! się nie nadaje. Kuba pisał demka, muzykę w Action! powstało w nim parę gier – trudno o lepsze argumenty.
    
    Tak w imię edukacji: insert co takiego chcesz zrobić do czego Action! się nie nadaje. Jeśli ten wątek ma być pomocny dla osób chcących tworzyć gry, to warto abyś to w tym momencie ujawnił. No i co Tobie naopowiadał Konop na ten temat, nie musisz ujawniać wszystkiego ale to co najistotniejsze.
    
    
    Rada:
    Insert, ja odradzam zmiany zapodawane choćby w dobrej wierze i z dobrymi argumentami, jeśli ktoś już jest w trakcie pracy/nauki. Zmiany narzędzi albo typu programu (np. z gry zręcznościowej na strategiczną itp.) to pierwszy krok do porażki. Na takie decyzje to można sobie przeznaczyć max 1% do 5% czasu na początku projektu a potem należy się już tego trzymać, choć oczywiście Ty się tego tak bardzo trzymać nie musisz, masz czas i nas kolegów którzy Tobie pomogą (choć nie wiem czy Konop może pomagać tak często w C) więc sam zdecyduj.
    
    Jednak żelazną zasadą powinno być niezmienianie fundamentalnych kwestii w zbyt bardzo zaawansowanym etapie prac. Czasami dla dobra całego projektu lepiej trzymać się niewłaściwie lub błędnie przyjętych ram niż doprowadzić do fiaska całości. Przykładowo nikt się nie pyta jakie decyzje były niewłaściwe w starcrafcie czy w crysis – ludzie cieszą się że można fajnie pograć. Czyli cieszą się że można pograć w grę ze złymi założeniami, niż nie pograć w kod który wciąż ewoluował do lepszej wersji.
    
    Następny projekt po nabraniu doświadczenia itp. można lepiej przemyśleć i może on być pod każdym względem lepszy. Możesz też potem dla nas na AOL napisać artykuł o tym co jak zrobiłeś, jakie masz doświadczenia i co chcesz zmienić itp.
33. • 33:
       
      CommentAuthorlarek
    • CommentTime22 Mar 2011 17:03

     

    tdc:

    a w Action! kompilator nie działa ? Ja nic o tym nie wiem.

    
    No, w końcu wszystko się wyjaśniło ;)
34. • 34:
       
      CommentAuthortdc
    • CommentTime23 Mar 2011 02:03

     
    ;)
    
    W Action! kompilator działa i to bardzo dobrze. Posiada parę błędów, ale który język ich nie posiada.
    
    Wszelkie głośne problemy z Action! wiążą się nie z samym kompilatorem, ale z kodem przez niego wygenerowanym, który następnie ma zostać przetworzony, wtedy mogą pojawiać się różne problemy, ale nie mają one związku z samym językiem skoro dany program w ramach carta Action! działa bez problemu (taki problem był np. w Space Travel).
35. • 35: CommentAuthorxxl
    • CommentTime23 Mar 2011 09:03 zmieniony

     
    jezyk i kompilator to dwie rozne sprawy, jesli jezyk ma 'bledy' mowimy o specyfice jezyka ale jesli kompilator tego jezyka 'nie robi' to mamy do czynienia z dupa blada.
    
    > Wszelkie głośne problemy z Action! wiążą się nie z samym kompilatorem, ale z kodem przez niego wygenerowanym, który następnie ma zostać przetworzony, wtedy mogą pojawiać się różne problemy, ale nie mają one związku z samym językiem
    
    jezyk jak jezyk... jesli kod generowany przez kompilator ma problemy to kompilator ma problemy a nie jezyk ;)
    
    okok. nie 'jade' po Action! - byl dobry jak na swoj czas, jesli ktos bedzie robil dokumentacje to moze jeszcze by sie przydalo napisac jak action przekazuje parametry (dobrze nie pamietam ale chyba od $a0 przechowuje dodatkowo ladujac do a,x,y kolejne do $a2) - przydaje sie czasem ;-)
36. • 36:
       
      CommentAuthorjhusak
    • CommentTime23 Mar 2011 22:03

     

    Bluki:

    A Forth? Powstało przecież kilka gier.
    

    
    
    what for(th)?
    
    Forth jest tak specyficzny, jak nic dokoła, wyłączając oczywiście maszyny stosowe. Krzywa trudności na początku odrzuciła niejednego, taka stroma. Przy czym ta krzywa pozornie nie jest stroma, dlatego wielu próbowało - dużo osób mi znajomych mówiło ciepłe słowa o Forth, ale nikt z nich nie zakodował w tym języku nic poważniejszego.
37. • 37: CommentAuthorBluki
    • CommentTime24 Mar 2011 01:03

     
    Czyli, jeśli dobrze zrozumiałem, są języki co najmniej o takich samych możliwościach jak Forth, ale łatwiejsze do opanowania.
38. • 38:
       
      CommentAuthorpirx
    • CommentTime24 Mar 2011 08:03

     
    Zależy, co rozumiesz pod "takie same możliwości". Jeśli chodzi o zwięzłość kodu to na Atarce nic lepszego nie ma. Nawet w asemblerze trudno pobić Fortha (nie rozumiałem tego, póki nie popatrzyłem jak to działa). Ale też nie polecam, nie dałem rady się przebić. Roland Pantoła dał radę.
39. • 39: CommentAuthorw1k
    • CommentTime24 Mar 2011 18:03

     
    input/output in action! - czech
    
    ->link<-
40. • 40:
       
      CommentAuthorTheFender
    • CommentTime24 Mar 2011 18:03 zmieniony

     
    Ciekawostka - przeglądałem dokument z powyższego linku i na stronie 40 patrzę - a tu rysunek Piotra Kakieta z czasopisma Komputer :) to słynne "Panowie wybaczą, ale na temat komputeryzacji społeczeństwa wypowie się mój syn"
41. • 41:
       
      CommentAuthortdc
    • CommentTime25 Mar 2011 02:03

     

    xxl:

    jezyk i kompilator to dwie rozne sprawy

    
    Nie czepiajmy się tak drobiazgowo słówek, cały czas mówie o kodzie jaki generuje Action!.
    
    

    xxl:

    jezyk jak jezyk... jesli kod generowany przez kompilator ma problemy to kompilator ma problemy a nie jezyk ;)

    
    Chciałem wcześniej powiedzieć, że jeśli kod utworzony w tym języku działa dobrze (a najczęściej działa:P) to znaczy że jest ok. Natomiast problemy są gdy chce się ten kod potem dalej przetwarzać np. programem lib.com itp. jeśli po jego modyfikacjach coś nie działa to nie ma z tym nic wspólnego kompilator, tylko lib.com lub inne dostępne w necie rozwiązanie.
    
    

    xxl:

    jak action przekazuje parametry (dobrze nie pamietam ale chyba od $a0 przechowuje dodatkowo ladujac do a,x,y kolejne do $a2) - przydaje sie czasem ;-)

    
    Jakoś tak to jest.
    
    
    

    jhusak:

    dużo osób mi znajomych mówiło ciepłe słowa o Forth, ale nikt z nich nie zakodował w tym języku nic poważniejszego.

    
    Te czułości są fajne:
    

    dużo osób mi znajomych mówiło ciepłe słowa o Kasi, ale nikt z nich nie zakręcił znią nic poważniejszego

    
    :)
42. • 42: CommentAuthormrroman
    • CommentTime25 Mar 2011 07:03

     
    Ciekawostka. W Forth np napisano SynFile+
    
    ->link<-
43. • 43: CommentAuthorw1k
    • CommentTime15 Oct 2011 17:10

     
    today arrived new 5'25 diskettes..
    i found interesting action!
    
    ACTION!HS (c) STORK
    today i save it as .ATR file
44. • 44:
       
      CommentAuthorKaz
    • CommentTime15 Oct 2011 22:10

     
    w1k - place here this version, thanks.
45. • 45: CommentAuthorw1k
    • CommentTime15 Oct 2011 23:10

     
    yes, tommorow i save it
46. • 46: CommentAuthorw1k
    • CommentTime16 Oct 2011 10:10

     
    here is it :)

    • action.atr
47. • 47:
       
      CommentAuthortdc
    • CommentTime16 Oct 2011 22:10

     
    Thanks w1k
48. • 48: CommentAuthorw1k
    • CommentTime17 Oct 2011 10:10

     
    its normal action! or modified? i dont know
49. • 49:
       
      CommentAuthorKaz
    • CommentTime17 Oct 2011 12:10

     
    TDC - Ty najszybciej mozesz sprawdzic, co jest zmodyfikowane, bo praktykujesz pisanie w Action!. Sprawdz kilka typowych bugow i bedzie wiadomo czy warto sobie ta wersja zawracac glowe :)
50. • 50:
       
      CommentAuthortdc
    • CommentTime17 Oct 2011 16:10

     
    na pewno to uczynię, ale obecnie mam urwanie głowy. Może Kuba to sprawdzi ?
    
    Mnie interesuje pozostała zawartość tej dyskietki, może będzie na niej coś ciekawego.