atarionline.pl ACTION! uczę się - Forum Atarum

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

  • :
  • :

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

    • 1: CommentAuthorEagle
    • CommentTime15 Mar 2011 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:
       
      CommentAuthorxeen
    • CommentTime15 Mar 2011
     
    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:
       
      CommentAuthorinsert
    • CommentTime15 Mar 2011
     
    o kurcze, dzieki Panowie, odezwe sie niebawem jak to przetrawie :)
    • 4:
       
      CommentAuthorinsert
    • CommentTime15 Mar 2011
     
    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: CommentAuthorEagle
    • CommentTime15 Mar 2011 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:
       
      CommentAuthorinsert
    • CommentTime15 Mar 2011
     
    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:
       
      CommentAuthorjhusak
    • CommentTime16 Mar 2011 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:
       
      CommentAuthorjhusak
    • CommentTime16 Mar 2011
     
    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:
       
      CommentAuthorjhusak
    • CommentTime16 Mar 2011
     
    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:
       
      CommentAuthorinsert
    • CommentTime16 Mar 2011
     
    o ja, hardcore, musze sie przez to przegryzc :/ dzieki Jakub
    • 11:
       
      CommentAuthorinsert
    • CommentTime16 Mar 2011
     
    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:
       
      CommentAuthorjhusak
    • CommentTime16 Mar 2011 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:
       
      CommentAuthorinsert
    • CommentTime16 Mar 2011 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:
       
      CommentAuthorjhusak
    • CommentTime16 Mar 2011 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:
       
      CommentAuthorjhusak
    • CommentTime16 Mar 2011 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:
       
      CommentAuthorinsert
    • CommentTime16 Mar 2011
     
    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:
       
      CommentAuthortdc
    • CommentTime17 Mar 2011 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:
       
      CommentAuthorKaz
    • CommentTime19 Mar 2011
     
    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:
       
      CommentAuthortdc
    • CommentTime19 Mar 2011
     
    Ciekawe to opracowanie Spellbounda.
    • 20:
       
      CommentAuthorjhusak
    • CommentTime21 Mar 2011
     

    tdc:

    Ponieważ dobrą zasadą jest KISS


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

    To nie rób skomplikowanej gry - zrób jakąś przygodówkę point'n'click. Takich na atari nie ma za wiele.
    • 22:
       
      CommentAuthorinsert
    • CommentTime21 Mar 2011
     
    po kilkugodzinnym boju z Konopem podczas forevera powaznie zastanawiam sie nad sensem daleszej nauki action :/ bycmoze gre sprobuje jednak pisac w c
    • 23:
       
      CommentAuthorjhusak
    • CommentTime21 Mar 2011
     
    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: CommentAuthorxxl
    • CommentTime21 Mar 2011
     
    :-) insert ale nauka action! nie poszla w las, dzieki niej doszedles do prawidlowego wniosku :-)
    • 25:
       
      CommentAuthorinsert
    • CommentTime21 Mar 2011
     
    oczywiscie nie ma czego zalowac, po prostu wyszlo na jaw ze w action nie zrealizuje dokladnie tego co planowalem :/
    • 26:
       
      CommentAuthortdc
    • CommentTime22 Mar 2011
     

    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:
       
      CommentAuthorjhusak
    • CommentTime22 Mar 2011
     
    tdc ma rację.
    C nie jest łatwiejszy, niż Action!.
    • 28: CommentAuthorxxl
    • CommentTime22 Mar 2011
     
    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:
       
      CommentAuthorinsert
    • CommentTime22 Mar 2011
     
    wedlug mnie c jest duzo trudniejszy od action, ale nic na to nie poradze po prostu action sie nie nadaje do wszystkiego
    • 30: CommentAuthorBluki
    • CommentTime22 Mar 2011
     
    A Forth? Powstało przecież kilka gier.
    • 31:
       
      CommentAuthorinsert
    • CommentTime22 Mar 2011
     
    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:
       
      CommentAuthortdc
    • CommentTime22 Mar 2011 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:
       
      CommentAuthorlarek
    • CommentTime22 Mar 2011
     

    tdc:

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

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

    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: CommentAuthorxxl
    • CommentTime23 Mar 2011 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:
       
      CommentAuthorjhusak
    • CommentTime23 Mar 2011
     

    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: CommentAuthorBluki
    • CommentTime24 Mar 2011
     
    Czyli, jeśli dobrze zrozumiałem, są języki co najmniej o takich samych możliwościach jak Forth, ale łatwiejsze do opanowania.
    • 38:
       
      CommentAuthorpirx
    • CommentTime24 Mar 2011
     
    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: CommentAuthorw1k
    • CommentTime24 Mar 2011
     
    input/output in action! - czech

    ->link<-
    • 40:
       
      CommentAuthorTheFender
    • CommentTime24 Mar 2011 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:
       
      CommentAuthortdc
    • CommentTime25 Mar 2011
     

    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: CommentAuthormrroman
    • CommentTime25 Mar 2011
     
    Ciekawostka. W Forth np napisano SynFile+

    ->link<-
    • 43: CommentAuthorw1k
    • CommentTime15 Oct 2011
     
    today arrived new 5'25 diskettes..
    i found interesting action!

    ACTION!HS (c) STORK
    today i save it as .ATR file
    • 44:
       
      CommentAuthorKaz
    • CommentTime15 Oct 2011
     
    w1k - place here this version, thanks.
    • 45: CommentAuthorw1k
    • CommentTime15 Oct 2011
     
    yes, tommorow i save it
    • 46: CommentAuthorw1k
    • CommentTime16 Oct 2011
     
    here is it :)
    • 47:
       
      CommentAuthortdc
    • CommentTime16 Oct 2011
     
    Thanks w1k
    • 48: CommentAuthorw1k
    • CommentTime17 Oct 2011
     
    its normal action! or modified? i dont know
    • 49:
       
      CommentAuthorKaz
    • CommentTime17 Oct 2011
     
    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:
       
      CommentAuthortdc
    • CommentTime17 Oct 2011
     
    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.