atarionline.pl Mad Pascal - nowe wersje - problemy - 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:
       
      CommentAuthorMq
    • CommentTime17 Feb 2021 zmieniony
     
    Nie znalazłem adekwatnego wątku, więc zakładam nowy.

    Tebe opublikował właśnie informację o nowej wersji MP, która ma poprawki w detekcji PAL/NTSC i w modułach odgrywających muzyczki.

    Mam problem taki, że po wrzuceniu tej nowej wersji dostaję błędy przy kompilacji na etapie dołączania resource'ów. Mam w grze dużo resource z binariami, dołącza mi się kilkanaście z nich, a przy kolejnym obojętnie jakim dostaję komunikat ERROR overlap memory.

    Jak podejść do tematu, bo nie wiem o co chodzi?
    Mam coś takiego z kompilatora:

    RCDATA 'apl_data\map_forest1.apl' MAP_FOREST1 0 0 0 0 0 0 0 0
    resource.asm (453) ERROR: Overlap memory
    Writing listing file...


    Edit: aha, przejście robię z wersji 1.6.4 tej, która jest jako ostatni release wystawiona (z października bodajże). Oczywiście na tej wersji wszystko mi działa poprawnie.
    • 2: CommentAuthortebe
    • CommentTime17 Feb 2021 zmieniony
     
    plik base\atari\resource.asm

    makro RCDATA

    .macro	RCDATA (nam, lab)

    len = .filesize(%%1)

    ift main.%%lab+len >= $c000

    ift main.%%lab>=CODEORIGIN && main.%%lab<PROGRAMSTACK
    ert 'Overlap memory'
    eif

    org RESORIGIN

    mcpy jsr sys.off

    memcpy #data #main.%%lab #len

    jmp sys.on

    data ins %%1

    .print '$R RCDATA ',main.%%lab,'..',main.%%lab+len-1," %%1"

    ini mcpy
    els
    ift main.%%lab>=CODEORIGIN && main.%%lab<PROGRAMSTACK
    ert 'Overlap memory'
    eif

    org main.%%lab

    ins %%1

    .print '$R RCDATA ',main.%%lab,'..',*-1," %%1"
    eif
    .endm


    adres który podajesz MAP_FOREST1 mieści się w zakresie [CODEORIGIN..PROGRAMSTACK]
    • 3: CommentAuthorpin
    • CommentTime18 Feb 2021
     
    @TeBe - jeśli masz Rapidusa to sprawdź dlaczego niektóre programy w MadP. bez wyraźnej przyczyny wieszają się na DracOS + Rapidus. Przykład - Weather dla Fujinet by Bocianu. Oglądałem to źródło, ale nie widzę przyczyny. Zmienisz OS na XL OS, 816 aktywne, banki fast dopalone - i na zwykłym OS nie ma problemu.
    • 4:
       
      CommentAuthorMq
    • CommentTime18 Feb 2021 zmieniony
     
    Ale jakie to są konkretnie adresy? Moje rcdata, które tu się wywalają, są lokowane w przestrzeni powyżej $6000 do $7000 z kawałkiem. To jest przestrzeń nieużywana przez nic, normalna pamięć, we wcześniejszej wersji MP działało wszystko dobrze...
    Kod z danymi kończy mi się gdzieś na $5000 z kawałkiem.

    Edit: dobra, podłubałem trochę sam w poszukiwaniu o co chodzi z tymi adresami.
    W pliku wygenerowanym przez kompilator *.a65 znalazłem co następuje:

    CODEORIGIN = $2000

    VARDATASIZE = 10033

    PROGRAMSTACK = DATAORIGIN+VARDATASIZE

    Czyli wynika z tego, że PROGRAMSTACK = $4731

    A ja ładuję resource tak jak pisałem między $6000 a $7000...

    Edit2: pogrzebałem jeszcze bardziej i coś jest nie tak z tymi danymi data. 10033 bajtów, to jest masa danych. Skompilowałem program bez moich rcdata i okazało się, że kompilator podaje, że dane kończą się aż na $7311
    Problem dotyczy jednak faktu, że ja tam nie mam tylu danych, a w pliku a65 widzę jakieś masę danych wypełnionych zerami. To nie są moje dane:-)
    Skompilowany program zajmuje o około 9k więcej niż ten sam program skompilowany Mad Pascalem w wersji 1.6.4

    Ten sam program kompilowany w nowym MP
    ZPAGE: $0080..$00D7
    RTLIB: $22D0..$2397
    SYSTEM: $23D8..$2433
    B_SYSTEM: $2434..$24FD
    APLIB: $24FE..$262D
    MISC: $262E..$265D
    RMT: $265E..$2798
    CODE: $2000..$4B6B
    DATA: $4BE0..$7311
    Writing listing file...
    Writing object file...
    18424 lines of source assembled in 9 pass
    29590 bytes written to the object file


    A tu ten sam w 1.6.4 (dokładnie tyle mam danych w programie, to jest trochę zmiennych, trochę małych tablic, trochę stringów, trochę pointerów, bo dane graficzne itp są ładowane jako resource, więc tu takich w ogóle nie mam):
    ZPAGE: $0080..$00D7
    RTLIB: $22D0..$23B4
    SYSTEM: $23F5..$248D
    B_SYSTEM: $248E..$2573
    APLIB: $2574..$26B9
    RMT: $26BA..$27ED
    CODE: $2000..$4B8B
    DATA: $4B8C..$4FBC
    Writing listing file...
    Writing object file...
    17804 lines of source assembled in 10 pass
    20489 bytes written to the object file


    Poprawnie w starym MP mam tak:
    VARDATASIZE = 1072

    I siedzą tam faktycznie moje dane w pliku a65. Natomiast w nowej wersji moje dane też są, ale są rozstrzelone i pomiędzy nimi jest cała masa (9k) zerowych danych.
    • 5: CommentAuthortebe
    • CommentTime18 Feb 2021 zmieniony
     
    a nie masz przypadkiem na końcu *.a65 obszaru ".local @RESOURCE", zaraz po etykiecie "IOCB@COPY" mógłby wystąpić

    a może masz tablice typu STRING, w starej wersji MP były alokowane tylko wskaźniki, w obecnej alokowana jest też pamięć dla stringów

    czyli w starej wersji array [0..255] of string alokuje 512 bajtów na wskaźniki, w aktualnej wersji będzie to 512+65536 bajtów, w nowej wersji należy zmienić typ na POINTER albo ^STRING, albo konkretnie zmniejszyć rozmiar do np. STRING[31]
    • 6:
       
      CommentAuthorMq
    • CommentTime18 Feb 2021 zmieniony
     
    Pierwsza rzecz (.local...) odpada, sprawdziłem.

    Natomiast tak, mam tablice stringów.

    Dodałem ^STRING do wszystkich tablic stringów i rozmiary zrobiły mi się takie jak miałem w starej wersji MP 1.6.4
    Po tym zabiegu skompilowało się wszystko bez błędów i program ma taki rozmiar jak mieć powinien.

    A co to jest ^STRING ? W sensie co robi znak ^ przed typem.

    Natomiast po skompilowaniu kodu gry w nowej wersji mam problemy z jeszcze innymi rzeczami, ale to już sobie posprawdzam. Po pierwsze gdzieś się coś nie tak przelicza w jakichś matematycznych obliczeniach, bo mi w animacjach znaków nie te znaki wskakują. Po drugie gra przestała się wyrabiać w ramkach NTSC i się zawiesza, ale to będzie trzeba skrupulatnie krok po kroku wszystko sprawdzić w czym tkwi problem.
    • 7: CommentAuthortebe
    • CommentTime18 Feb 2021
     
    ^string, wskaźnik do STRING
    • 8:
       
      CommentAuthorMq
    • CommentTime18 Feb 2021 zmieniony
     
    Aha. Fakt.

    @tebe, wyedytowałem w tym czasie powyższy post zanim odpisałeś, zerknij jeszcze co napisałem.

    Co do string, czy mogę wobec tego robić bez przeciwwskazań tak:
    infoTxt : array[0..3] of ^string = (
    'Dom Czarownika'~,
    'Stary pien'~,
    'Zlamane drzewo'~,
    'Jaskinia pajakow'~
    );

    Czy lepiej jakoś inaczej te teksty przechowywać bardziej optymalnie?

    Edit: jeszcze zmienić trzeba nawet przy takiej konstrukcji z:
    dialogTxt : array [0..0] of ^string;

    na:
    dialogTxt : array [0..0] of string;


    Mam u siebie takie coś, że dialogi między postaciami zapisane są w tablicach stringów. Jest jedna wspólna procedura dla wszystkich dialogów, a jak się rozmawia z daną postacią, to po prostu zmienia się tylko ten sam wskaźnik do różnych tablic.
    Powyższa konstrukcja array[0..0] czyli tablica zero-elementowa jest de facto wskaźnikiem tylko, ale w przypadku typu string alokuje też pamięć, więc trzeba też używać wtedy ^string
    • 9:
       
      CommentAuthorMq
    • CommentTime18 Feb 2021 zmieniony
     
    Sorry, że post jeden pod drugim, ale trochę inny sub-temat, więc piszę osobno. Przetestowałem nową wersję MP pod kątem detekcji GTIA/ANTIC w bibliotece playera RMT. W mojej grze elegancko to działa, muzyczki grają poprawnie we wszystkich systemach pod Altirrą: PAL/NTSC/SECAM/PAL60/NTSC50

    Znaki, o których pisałem wcześniej, że mi się źle animują, już tez namierzyłem gdzie leży problem. Nie działa poprawnie w nowej wersji taka konstrukcja:
    const
    scradr = $E000;

    var
    tablicaA : array [0..3] of byte;
    tablicaB : array [0..3] of byte;

    tablicaA[1]:=0;

    tablicaB[tablicaA[1]]:=Peek(scradr);
    tablicaB[tablicaA[1]]:=tablicaB[tablicaA[1]] and %10000000 or %01100010;


    Powyższe nie działa - daje zły wynik ta linia z and i or ostatecznie. Dawało poprawny wynik w wersji 1.6.4

    Za to zadziała w nowej wersji poniższe złożone w jedną linię:
    tablicaB[tablicaA[1]]:=Peek(scradr) and %10000000 or %01100010;


    Ja sobie w kodzie poprawiłem to po prostu i jest wszystko ok, ale nie wiem czy błąd jest mój w myśleniu, czy kompilatora w działaniu. Sprawdź sobie może te rzeczy.

    Została mi ostatnia sprawa: minimalnie dłużej mi zabiera czas w ramkach gra, i czasami (rzadko) zawiesza się w NTSC, bo coś nie wyrabia, ale nie wiem co dokładnie. Ja kod ciągle optymalizuję, więc to mi się pewnie naprawi samo za jakiś czas:-) Więcej problemów nie zauważyłem.
    • 10: CommentAuthortebe
    • CommentTime18 Feb 2021
     
    jeśli tablica jest predefiniowana to nic nie zmieniać, tylko dla tablic które nie mają zdefiniowanych wartości pól

    inna zmiana jaka zaszła w nowym MP, to odwołania do tablic, w poprzedniej wersji obcinał index do BYTE jeśli rozmiar tablicy nie przekraczał 256 bajtów, w nowej wersji potrafi zaadresować do 512 bajtów, więc należy obliczenia rzutować do typu BYTE, np.

    tab_sin: array [0..255] of byte;

    a := tab_sin[x+32];


    powinno być
    a := tab_sin[byte(x+32)];
    • 11:
       
      CommentAuthorMq
    • CommentTime18 Feb 2021
     
    Ok, a jak nie zrobisz rzutowania na byte, to co, będzie robił obliczenia domyślnie na wordzie?
    • 12:
       
      CommentAuthorpirx
    • CommentTime18 Feb 2021
     
    <quote>a := tab_sin[byte(x+32)];</quote>

    aj waj, to b. nie ten teges, skoro `tab_sin` jest 8-bit, to komplikator powinien jednak obliczać bajty :[
    • 13: CommentAuthortebe
    • CommentTime18 Feb 2021 zmieniony
     
    FPC też tak działa, pozwala wyjść poza granicę, KickC też

    tutaj przykład wykorzystania tego

    ->link<-

    tak, domyślnie obliczenia na WORD-zie
    • 14:
       
      CommentAuthorMq
    • CommentTime18 Feb 2021
     
    Nie rozumiem... Znaczy rozumiem o co chodzi, ale nie rozumiem jak nad tym panować poprawnie od strony Mad Pascala, nie zagłębiając się w assemblera. Dotychczas wystarczyło mi, że starałem się używać wszędzie gdzie się dało zmiennych typu byte, wartości są przewidywalne, więc wiadomo czego użyć i to wystarczyło, żeby generowany kod był optymalny. A teraz co, nawet jak będę operował tylko na bajtach, to i tak kompilator może mi robić obliczenia na wordach i generować tym samym nieoptymalny kod?
    • 15: CommentAuthortebe
    • CommentTime19 Feb 2021 zmieniony
     
    to dotyczy tylko tablic max 256 bajtowych i obliczania indeksu do takich tablic

    jeśli miałbyś tablicę array [0..7] of byte, z wartościami HSCROLL, które chcesz czytać powtarzalnie 0..7, 0..7, 0..7

    to nie zapiszesz
    h:=tab[i];

    z nadzieją że kompilator wstawi Tobie 'and #7' tylko zapiszesz
    h:=tab[i and 7];


    tak samo w przypadku tablic array [0..255] jeśli wynik obliczeń przekracza 256 kompilator nie decyduje za użytkownika, tylko użytkownik świadomie

    a:=tab[byte(i+32)];

    jest równoznaczne dla 'and #255'
    a:=tab[(i+32) and 255];
    • 16: CommentAuthorilmenit
    • CommentTime19 Feb 2021 zmieniony
     
    @Tebe - FPC jest dla kompów, które nie mają adresowania poprzez strony pamięci i tam taka konstrukcja nie ma wpływu na szybkość. Proponowałbym kod dla tablic generować przez adresowanie "tab,y" lub "tab,x" gdy indeks tablicy jest typu BYTE. Zawsze można taki indeks przekonwertować do WORD(i) i indykować tym, że chcemy pisać bo 16bitowej przestrzeni adresowej.
    Pisanie poza zakres tablicy jest ogólnie średnio bezpieczne... Pascal ma wskaźniki, które są z założenia 16bitowe i niebezpieczne, więc proponowałbym takie operacje pozostawić na nich.
    W aktualnym rozwiązaniu o ile dajesz lepszą "ręczną kontrolę" nad generowanym kodem, to przenosisz kwestie optymalizacji kodu z kompilatora na użytkownika, co jest mało przyjazne.

    EDIT:
    Sprawdziłem jak działa KickC (najnowsza v0.8.5 BETA, więc może mieć błędy) i on wymaga indeksu 16bit (lub rzutowania do unsigned int) aby generować kod wychodzący poza zakres tablicy:

    unsigned char index;
    unsigned char array_small[128];
    unsigned char array_big[512];

    void main() {
    // small array, index by byte
    for (index=0;index<sizeof(array_small);++index)
    {
    array_small[index] = 1;
    }
    // big array, index by byte
    for (index=0;index<sizeof(array_big);++index)
    {
    array_big[index] = 2;
    }
    }

    generuje:
    main: {
    ldx #0
    // small array, index by byte
    __b1:
    cpx #$80*SIZEOF_BYTE
    bcc __b2
    ldx #0
    // big array, index by byte
    __b4:
    lda #2
    sta array_big,x
    inx
    jmp __b4
    __b2:
    lda #1
    sta array_small,x
    inx
    jmp __b1
    }


    Dla indeksu 16bitowego:
    unsigned char index;
    unsigned char array[128];

    void main() {
    // big array, index by byte
    for (index=0;index<sizeof(array);++index)
    {
    array[((unsigned int)index)+1024] = 1;
    }
    }

    generuje
    main: {
    .label __2 = $80
    .label __4 = $80
    ldx #0
    // big array, index by byte
    __b1:
    cpx #$80*SIZEOF_BYTE
    bcc __b2
    rts
    __b2:
    txa
    sta.z __2
    lda #0
    sta.z __2+1
    clc
    lda.z __4
    adc #<array+$400
    sta.z __4
    lda.z __4+1
    adc #>array+$400
    sta.z __4+1
    lda #1
    ldy #0
    sta (__4),y
    inx
    jmp __b1
    }
    • 17: CommentAuthortebe
    • CommentTime19 Feb 2021 zmieniony
     
    jeśli indeks jest typu BYTE to pozostaje BYTE, to o czym pisałem dotyczy tablic nie przekraczających 256 bajtów i operacji zwiększenia indeksu [index+????] a nie [index]

    zwiększenie indeksu o stałą wartość ale max typu BYTE

    tab[i + 100] := 1;
    ldy I
    lda #$01
    sta adr.AR+$64,y
    • 18: CommentAuthorilmenit
    • CommentTime19 Feb 2021
     
    dzięki za wyjaśnienie, w takim razie to według mnie jest poprawne zachowanie w nowej wersji.

    Jeszcze sprawdziłem dla KickC:
    unsigned char index;
    unsigned char array[128];

    void main() {
    // fill second part of the array
    for (index=0;index<64;++index)
    {
    array[index+64] = 1;
    }
    }

    generuje:
    .segment Code
    main: {
    ldx #0
    // fill second part of the array
    __b1:
    cpx #$40
    bcc __b2
    rts
    __b2:
    lda #1
    sta array+$40,x
    inx
    jmp __b1
    }
    • 19: CommentAuthortebe
    • CommentTime20 Feb 2021
     
    naprawione w nowej wersji MP

    const
    scradr = $E000;

    var
    tablicaA : array [0..3] of byte;
    tablicaB : array [0..3] of byte;

    tablicaA[1]:=0;

    tablicaB[tablicaA[1]]:=Peek(scradr);
    tablicaB[tablicaA[1]]:=tablicaB[tablicaA[1]] and %10000000 or %01100010;
    • 20:
       
      CommentAuthorMq
    • CommentTime20 Feb 2021
     
    Czyli co, to był jakiś błąd?

    Czy teraz będą działać obie wersje moich równań, które przedstawiłem?
    Pytam, bo nie uśmiecha mi się za każdym razem przy nowej wersji sprawdzać każdej matematyki czy działa poprawnie czy niepoprawnie i ciągle dostosowywać programu...
    • 21: CommentAuthortebe
    • CommentTime20 Feb 2021
     
    tak, jedna z optymalizacji wymagała podania dodatkowych warunków granicznych
    • 22:
       
      CommentAuthorMq
    • CommentTime20 Feb 2021
     
    @tebe, a czy Ty gdzieś prowadzisz w jakimś jednym miejscu jakieś zestawienie zmian które robisz? Gdzieś to się da obserwować, żeby wiedzieć co przynoszą nowe wersje i co konkretnie zmieniają?
    Bo na tą chwilę, to trafiam tylko w takich przypadkowych wątkach jak ten na takie info, a przecież może tu zajrzeć przypadkiem mała ilość ludzi...
  1.  
    Tu na końcu strony:
    ->link<-
    • 24:
       
      CommentAuthorMq
    • CommentTime20 Feb 2021
     
    No właśnie że nie. Tam jest tylko opis do wersji 1.6.3. Ostatnia "oficjalna" to była 1.6.4, a obecnie mamy wersję 1.6.5, przy czym wersji 1.6.5 było już kilka i one mają dodatkowo w nawiasie datę publikacji, tak więc obecnie mamy wersję 1.6.5 (2021-02-20)
  2.  
    A to przepraszam, mało używam MP. Myślałem, że update jest na bieżąco.
    • 26:
       
      CommentAuthorMq
    • CommentTime20 Feb 2021
     
    @tebe, wrzuciłem sobie tą aktualną wersję i wygląda na to, że u mnie wszystko jest ok. Niemniej jednak przydało by się dokumentowanie zmian, bo są one na tyle istotne, że przesiadka na wyższą wersję w trakcie tworzenia jakiejś produkcji staje się frustrująca.
    Warto by też, żeby pojawiały się jakieś "oficjalne" release'y, które są już sprawdzone, przetestowane i potwierdzone przez chociaż kilka osób że działają dobrze (bez większych, istotniejszych błędów).
    • 27: CommentAuthortebe
    • CommentTime20 Feb 2021
     
    aktualna wersja jest na githubie
    • 28:
       
      CommentAuthorpirx
    • CommentTime20 Feb 2021
     
    @Mq ależ to Ty właśnie jesteś tą osobą, która sprawdza ;)
    To nie jest jakaś złośliwość, po prostu userów MP ma troszkę mniej, niż taki Python :]
    Jakąś metodą by było rozwinięcie test suite, tak jak to robił mgr.inż. w swoim komplikatorze ABC. Mrówcza robota.
    • 29:
       
      CommentAuthorMq
    • CommentTime20 Feb 2021
     
    No dobra, rozumiem. Wiem że użytkowników MP jest garstka, więc samo się to wszystko nie przetestuje. Wiem też, że jest na githubie, ale po prostu mi się rozchodzi o to, że w dokumentacji jest opis do 1.6.3, na githubie jest w release's 1.6.3 i 1.6.4, jest też changelog, ale w nim nie ma opisów wszystkich zmian. Wersja 1.6.5 jest wielokrotnie podawana i ciągle zmieniana, a nie zmienia się jej numerek. Informacja o tym że coś tam zmienione pojawia się w losowych miejscach w różnych wątkach, na różnych forach. Nie jestem w stanie za tym nadążać, więc jak mam działającą w stopniu wystarczającym dla mnie wersję to takiej używam i nie podnoszę u siebie do nowszych, bo obawiam się, że mi coś innego przestanie działać. Z tego wynika, że nawet jak znajdę jakiś błąd w działaniu, to nie wiem czy to wina starszej wersji, czy moja, czy co. Z kolei jak zgłoszę, to tebe mi powie żebym podniósł wersję, a to mi się nie uda. Ja oczywiście doceniam bardzo Mad Pascala, doceniam tebe za bardzo wielki kawał roboty, ale ja akurat pracuję nad dużą grą i mam tam już prawie 10tys linii kodu generowanego w assemblerze, nie jestem nawet w stanie tego wszystkiego analizować. Testy to sobie można robić na krótkich programikach, ale ja piszę tylko tą grę, nie robię żadnych innych programików w tej chwili, więc eksperymenty z takim długim kodem nie wychodzą mi już na tym etapie na dobre.

    No ale ok, na razie podniosłem się do tej obecnej wersji z dzisiaj i będę optymalizował wszystko sobie pod nią, jak bym coś zauważył, to będę dawał znać.
    Jak będę robił kolejne projekty, to będę sięgał po wersję aktualną na dany moment, żeby iść do przodu.
    • 30: CommentAuthortebe
    • CommentTime20 Feb 2021 zmieniony
     
    testy są przeprowadzane na dużej ilości napisanych przez użytkowników programów, zapisuję sobie wersje plików *.a65 z rozszerzeniem 'OK' i przy nowych kompilacjach sprawdzam czy się różnią, widzę wtedy czy nowe zmiany działają poprawnie

    jest dużo drobnych zmian, często polegających na dopisaniu jednego dodatkowego warunku

    historia zmian dla 1.6.4 i wcześniejszych jest dostępna cały czas ->link<-

    w obecnej 1.6.5 aktualnie to:

    - przepisana obsługa CASE OF
    - przepisana optymalizacja kodu dla tablic nie przekraczających 256 bajtów
    - optymalizacja dla warunków '>', '<='
    - dodana nowa platforma, Commodore C4 Plus
    - dodane alokowanie pamięci dla tablic typu STRING (do tej pory tylko wskaźnik był odkładany czyli działało to jak 'array of ^string')
    - unit GRAPHICS: procedure Font(charset: pointer);
    - unit STRINGUTILS
    - unit MISC, RMT, CMC, MPT: DetectAntic
    - unit SYSTEM poprawiony z uwzględnieniem platform ATARI, C64, C4Plus
    • 31:
       
      CommentAuthorMq
    • CommentTime21 Feb 2021
     
    Dzięki tebe za wyjaśnienia i opis zmian.

    W każdym razie, ja jak mam czas grzebać w programowaniu, to bardziej skupiam się na grzebaniu w grze niż na testach Mad Pascala. Mad Pascal to dla mnie tylko i aż narzędzie - super świetne, bez wątpliwości i zastrzeżeń, bo z niczego innego już dziś bym nie chciał, ani nie mam potrzeby korzystać. No ale jako tester samego Mad Pascala, to ja się sprawdzę raczej w niedużym tylko stopniu, bo tak jak mówię, skupiam się na optymalizacjach w grze i dopasowywaniu jej do istniejącego Mad Pascala, a nie na tym żeby dopieszczać Mad Pascala. Niemniej jednak postaram się pomagać wrzucając chociaż od czasu do czasu jakieś zastrzeżenia, czy pytania, przy okazji których może się coś tam zawsze znajdzie do poprawy.
    • 32: CommentAuthorkski
    • CommentTime21 Feb 2021
     
    Nie da się robić tylu optymalizacji i zmian ile wykonuje Tebe ustrzegając się jednocześnie jakichkolwiek problemów. Codzienne życie programisty. No i niestety nie ma tajemniczych testerów, to my nimi jesteśmy.
    Też doświadczyłem nie kompilującego się programu po ściągnięciu nowej wersji, ale zawsze z powodu drobiazgów. Zauważyłem też że pewne (nieliczne!) problemy które wcześniej musiałem obchodzić w nowej wersji "same" znikały.
    Gdyby nie Mad Pascal Albert nie wyglądałby tak jak wygląda (tj. wyglądałby nawet jeszcze gorzej niż wygląda), gdybym miał robić wszystko w czystym asemblerze od samego początku nie starczyłoby sił.
    Tak więc Tebe dzięki za całą Twoją pracę.
    Oczywiście fajnie będzie jak nowe wersje Mad Pascala będą kompilowały stare programy bez problemu. Pomożemy.
    • 33:
       
      CommentAuthormgr_inz_rafal
    • CommentTime21 Feb 2021 zmieniony
     

    kski:

    Nie da się robić tylu optymalizacji i zmian ile wykonuje Tebe ustrzegając się jednocześnie jakichkolwiek problemów.


    Eee tam, wystarczy ogarnąć testy regresyjne. Jak wspomniał pirx, robiłem tak przy pracach nad komplikatorem BASIC. Inaczej robiąc nowe funkcje na pewno rozwaliłbym coś, co wcześniej działało.

    No ale... Prowadzimy tutaj działania hobbystyczne, a nie zawodowe i nikt nie będzie od Tebego wymagał niezawodności jak w NASA, zwłaszcza, że i tak świadczy on support na wysokim poziomie :)

    Poza tym, ja tylko zaczynam pisać kompilatory, a Tebe swoje kończy, więc proszę przypadkiem nie odbierać tego wpisu jako pouczanie :)
    • 34: CommentAuthortebe
    • CommentTime21 Feb 2021 zmieniony
     
    tak, użytkownicy i programy przez nich napisane są w dużej części testerami, bo zwracają uwagę na szczegóły które przeoczyłem, są źródłem nowych optymalizacji

    benchmarki Zbytiego i ich wersje dla różnych kompilatorów KickC, CC65, Millfork były powodem wielu zmian w MP, źródłem nowych pomysłów, m.in. taki test 'x > y' szybciej zostanie wykonany na 6502 jeśli zapiszemy go 'y < x' (obecna wersja MP sama dokonuje takiej zamiany)

    wszystkie gry Bocianu są bez przerwy kompilowane i testowane, skompilujcie PacMad-a obecną i starą wersją MP :)
    • 35: CommentAuthorilmenit
    • CommentTime21 Feb 2021
     
    Problem ze zmianami w nowych wersjach dotyczy wszystkich środowisk kompilacji czy to na duże platformy (Unity tu jest mistrzem niekompatybilności), czy też na małe (spróbujcie skompilować nowym CC65 jakiś stary projekt mający własną konfigurację dla linkera).

    Podstawowa zasada - przy większym projekcie to "jak działa, to nie ruszaj środowiska, chyba, że masz dużo wolnego czasu na debugowanie" ;-)
    Trzeba zawsze zważyć, czy te np. 5% poprawionej wydajności jest warte czasu zainwestowanego w przesiadkę na nowszą wersję, gdy nie poprawia ona jakiś krytycznych błędów.

    Tebe robi i tak niesamowitą robotę z MadPascalem, biorąc pod uwagę, że to projekt (prawie) jednoosobowy.
    • 36:
       
      CommentAuthorsun
    • CommentTime21 Feb 2021
     
    Mój soft też najlepiej testuje klient, takie życie :) Tebe - naprawdę kawał roboty i to dobrej :)
    I tak, stosuję się na razie do tego co pisze Ilmenit, czyli jak działa to nie ruszam środowiska ;)
    • 37:
       
      CommentAuthorMq
    • CommentTime22 Feb 2021
     
    Dokładnie, ja też stosuję zasadę, że nie ruszam środowiska w trakcie dużego projektu. Jednak akurat tutaj skusiło mnie lepsze rozpoznawanie PAL/NTSC, co wydało się bardzo istotne w świetle dyskusji na temat Alberta na atariage. Wcześniej już wsadziłem masę roboty, żeby Dude chodził na NTSC, ale jak się teraz okazało, że jeszcze są kombinacje różnych Anticów i GTIA, to całość była by i tak niedobrze zrobiona, stąd przejście na nową wersję opłaciło się, bo teraz gra działa mi na tych wszystkich kombinowanych konfigach sprzętowych. Co prawda okupione to jest na razie jakąś tam pracą z poprawkami rzeczy, które wcześniej działały dobrze, ale i tak warto mi to zrobić. W pisaniu gry optymalizacje stanowią dla mnie największą frajdę, więc skoro muszę to robić teraz jeszcze raz, to tym fajniej:-) Jedyne co, to nauczyłem się, że nie będę już więcej z góry pisał o przewidywanych terminach publikacji gier:-) Termin publikacji: nieznany:-)
    • 38:
       
      CommentAuthorcrrn
    • CommentTime22 Feb 2021
     
    Hej.
    Nie chcę zakładać nowego wątku i myślę że się nie obrazicie jak napiszę że...
    mamy pierwsze projekty w Mad Pascalu dla Commodore +4.

    Zrobiłem mini filmik i tekst na naszym portalu.
    Dzięki Tebe za to super narzędzie - MEGA robota!

    ->link<-
    • 39:
       
      CommentAuthorsun
    • CommentTime22 Feb 2021
     
    @Mq: dokładnie, termin będzie jak będzie i nie wcześniej :)
    • 40:
       
      CommentAuthorMq
    • CommentTime22 Feb 2021
     
    Ani na pewno też nie później:-)