atarionline.pl Portowanie mojego symulatora lotu na Atari - 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.

4. Programowanie / Programming  »   Portowanie mojego symulatora lotu na Atari

W dół

Od 1 do 23 z 23

  1.  
    • 1: CommentAuthorRoeoender
    • CommentTime29 Dec 2023 zmieniony
     
    Dzień dobry,
    Kierowany podwójną nostalgią - do Atari 130XE, które mieliśmy z bratem od około 6 r.ż.
    oraz do programowania z okresu studiów (około 2003 r.) w C/Asm na... kalkulator graficzny Casio Algebra FX 2
    spróbowałem poznać jak takie "doroślejsze" niż BASIC programowanie wygląda na Atari.

    W dawnych czasach na Atari największe emocje rozpalały we mnie symulatory lotu - Fighter Pilot, F15 Strike Eagle, Tomahawk,
    stąd w 2003 na ww. kalkulator, na konkurs programistyczny stworzyłem kompletną grę/symulator "F-16 Falcon 2.0".
    Odkopałem i zmontowałem trochę archiwalnych nagrań przedstawiających tą grę działającą na kalkulatorze -

    ->link<-



    Kierowany kolejną porcją nostalgii do obecnej próby reimplementacji mojej gry na małe Atari wybrałem MAD Pascala - Borland Pascala używałem dużo w czasach liceum.

    MAD Pascal jest na prawdę wspaniały - dzięki bogatej bibliotece i przykładom ułatwia szybkie wdrożenie się.
    Wręcz trudno mi uwierzyć, że aż tak dobrze to działa.
    Np. stosuję dyrektywy BASICOFF i ROMOFF - trochę dziwię się, że pomimo tego nadal mogę używać funkcji bibliotecznych typu InitGraph, Writeln itp.
    Stąd prośba, testowałem na emulatorach - Altirze i Atari 800, niestety nie mam sprawnego rzeczywistego Atari,
    więc czy mógłby ktoś sprawdzić czy załączona, bardzo wczesna, ale już trochę funkcjonująca wersja (da się polatać) działa na prawdziwym sprzęcie?
    • 2:
       
      CommentAuthorpancio
    • CommentTime29 Dec 2023 zmieniony
     
    odpalić się odpaliło.. ale nie umiem latać :-) a pomysł super!

    edit.

    Już umiem latać! strasznie mi to przypomina Mercenary... zapowiada się super gierka :-)

    bez problemu odpalil sie pod SDX, na Atari 800XL
    • 3:
       
      CommentAuthorKaz
    • CommentTime29 Dec 2023
     
    Ha! Nareszcie! Od wielu lat wspominam, że jednym z typów gier, której żaden Polak na Atari nie zrobił, jest symulator lotu i że może ktoś by się w końcu podjął! A tu proszę - taaaaaaka niespodzianka! Dzięki Roeoender, ogromnie trzymam kciuki za rozwój projektu i jeśli tylko będę mógł coś pomóc to śmiało pisz.

    Testy na real Atari też u siebie zrobię. Nawet na kilku różnych modelach.
    • 4: CommentAuthorZenon
    • CommentTime29 Dec 2023
     
    Jak to było.... polski lotnik, jak trzeba, poleci na drzwiach od stodoły...
    Koniec roku a pomysły sypią się jak piasek w klepsydrze. Co jeszcze ludziki wygrzebią, pozostały dwa dni. Nie ma to i tamto, to musi być skończone. Swego czasu też latałem, na Atari oczywiście. Jedna z pierwszych gier to STEALTH, potem do oporu THE LAST STARFIGHTER.
    • 5:
       
      CommentAuthorPeri Noid
    • CommentTime29 Dec 2023
     
    Pozwoliłem sobie nagrać małą próbkę odpaloną na Atari z Rapidusem.

    Domyślam się, że dopałka nie była planowana ale i tak fajnie to wygląda - trochę zbyt responsywnie nawet, rzekłbym. Bardzo fajny projekt, oby tak dalej!
    • 6: CommentAuthorKonstantyn
    • CommentTime29 Dec 2023
     
    Fajna klimatyczna muzyczka, coś a`la "W starym kinie". :-) Może dałoby się zaimplementować do gierki? ;-)
    • 7: CommentAuthorpin
    • CommentTime30 Dec 2023
     
    w przyszłości o ile taka zaistnieje, to jak by to było synchronizowane do ramki i generowało tyle fps ile wyrobi Atari to by przynajmniej na dopałkach CPU było zajebiście, bo teraz to na dopałce demo jest zdecydowanie zbyt szybkie. @Peri Noid - daj wszystkie banki na "fast" i odpal to ;)
    • 8: CommentAuthorRoeoender
    • CommentTime30 Dec 2023
     
    Wow dziękuję za szybki i pozytywny odzew.

    Możliwość, dzięki Wam weryfikacji, że to działa na prawdziwym sprzęcie naprawdę dużo dla mnie znaczy,
    bo pozwala potwierdzić, że emulatory nie zwabiły mnie w jakieś maliny,
    z których potem trudno by się było wygrzebać.

    Sam jestem zdziwiony, że przez te wszystkie lata, o ile mi wiadomo,
    nikt nie pokusił się o stworzenie czegoś grywalnego z prawdziwym wireframe 3D.

    Dla mnie w tamtych czasach Tomahawk i F-15 (oraz oszałamiający "Behind Jaggi Lines" bo taką wersję miałem)
    były absolutnie genialne (nawet wówczas nie wiedziałem, że był na Atari też Flight simulator),
    ale niedawno jak zobaczyłem na YT przegląd symulatorów na C64 to szczęka mi opadła.
    Stealth Fighter to właściwie wierny port F-19 z Peceta,
    a Chuck Yeager AFT miał nawet wypełnianą polygonową grafikę.

    Pokazuje to wyraźnie, że na małym Atari jest "ziejąca" nisza, która nie została jakoś nigdy wypełniona,
    a przecież z powodu wolniejszego CPU ww. gry na C64 były właściwie turowe, na Atari pewnie chodziłyby lepiej.
    Może kiedyś jakiś uzdolniony porter gier jak np. p. Mariusz Wojcieszek (w końcu zrobił już port 3D - Total Eclipse)
    przeportują, któryś z topowych symulatorów z C64 - przynajmniej w zakresie lotu 3D.
    Widziałem W.I.P. portu Elite'a - szkoda, że temat niedokończony.

    Niemniej na razie zrobię co mogę by mój kod zaadoptować, przynajmniej do stanu podstawowej grywalności.
    Duże obawy mam względem pamięci - zaraz po zrobieniu 3D i podstawowego modelu lotu już raz mi się skończyła,
    potem była długa faza przerabiania z "eleganckiego pascala" na takiego mniej pamięciożernego,
    teraz trochę więcej nadziei dało włączenie ROMOFF, ale bez kolejnych czasochłonnych optymalizacji się nie obejdzie.

    W najbliższym czasie planuję zrobić przynajmeniej podstawowe strzelanie, a potem pewnie jakieś obrywanie.

    Faktycznie widzę z filmiku Peri Noid, że strasznie mruga ale takie tematy będę robił stosunkowo późno,
    bo niekoniecznie jestem przekonany, że pozostanę przy obecnym trybie graficznym i sposobie rysowania.

    Odnośnie muzyki - na razie bardzo oszczędam pamięć stąd coś więcej poza odgłosami byłoby robione też raczej na końcu,
    na razie w tle po prostu proponuję sobie puścić Danger Zone, oczywiście z kasety z decka Technicsa. ;)

    Ten Rapidus to jakiś demon szybkości :)
    Generalnie celuję w poczciwe "gołe" Atari,
    ale sam jestem ciekaw jak sobie poradzi z bardziej obciążającą wersją -
    w załączniku przesyłam zupełnie niesymulatorową wersję - ze swobodnie (6DOF) przesuwaną kamerą ('Drone cam')
    na ekranie tytułowym jest opisana klawiszologia.
    W tej wersji na raz jest obsługiwanych 7 obiektów 3D z dosyć dalekim trybem renderowania.

    Oczywiście cieszę się ze wszystkich nagrań - jakby, ktoś zrobił takie ujęcie,
    że faktycznie widać na nim F-16 Falcona lub załączoną wersję Drone na Atari na telewizorze/monitorze
    z prawdziwym joystickiem to byłaby dla mnie podróż prawdziwie sentymentalna 30+ lat wstecz :).
    • 9:
       
      CommentAuthorPeri Noid
    • CommentTime30 Dec 2023
     
    Na Rapidusie mruga bo nie synchronizujesz się z ramką i przy czyszczeniu czasami najwyraźniej Rapidus robi to zbyt szybko. Ale to nieistotne, najważniejsze jest to, że w ogóle robi i wyświetla. Pocieszę cię, że podobnie zachowuje się Mercenary i Solo Flight. Za to najgenialniej do Rapidusa dopasowuje się Rescue on Fractalus (Behind Jaggi Lines). I, zdaje się, The Eidolon (tego nie próbowałem). Zerknij na moje filmiki, nagrałem to i owo.

    Owszem, Rapidus to nisza. Ale miło by było, gdybyś tak to zrobił, żeby na dopałce to się skalowało. Bazowy sprzęt to wiadomo, podstawa. Natomiast rozszerzona pamięć teraz jest na tyle pospolity dodatkiem, że myślę, że spokojnie możesz celować w 128K (jeśli nie 320K). Zawsze to sporo więcej miejsca na assety.
    • 10: CommentAuthortebe
    • CommentTime30 Dec 2023 zmieniony
     
    ambitny projekt, gratuluję :)

    oprócz ROMOFF, pamięć można zyskać obniżając początkowy adres ładowania, który domyślnie jest ustawiony na $2000

    najniżej można zejść do ok. $980 (-code:980), ładować plik przez XBOOT, albo FoxDOS

    przenosząc kod z Borland Pascala, należy pamiętać że tam typ INTEGER był 16bit, w MP i FPC typ INTEGER to już 32bit, więc należy dokonać poprawki (BORLAND LONGINT -> INTEGER; BORLAND INTEGER -> SMALLINT)

    pilnowanie typów, jeśli jest taka możliwość schodzić do typów bez znaku, jak najmniejszego rozmiaru

    przyspieszyć rysowanie linii na pewno przyspieszy FASTGRAPH, mnożenie 8x8bit, 16x16bit przyspieszy FASTMUL ($f page), który można też umieścić pod ROM, oczywiście wszystkie przyspieszenia kosztem pamięci
    • 11:
       
      CommentAuthorjhusak
    • CommentTime30 Dec 2023
     
    Leć w grafikę 7, 160x96, szybka do rysowania w pionie a i pamięci mniej. Możesz też w 2 kolory, wtedy jest jeszcze szybciej. Można optymalizować linie prawie pionowe i prawie poziome.
    • 12: CommentAuthorRoeoender
    • CommentTime30 Dec 2023
     
    @tebe - ambitny projekt to Twój MAD Pascal - naprawdę czapki z głów za Twoje wieloletnie jego rozwijanie (przeczytałem cały, 34 stronicowy wątek na atariage i potem jeszcze ten z przykładami :) ) i danie masy przykładów w dystrybucji, chyba nie ma bardziej produktywnego i zapraszającego do kodowania środowiska dla Atari.

    Trochę się spodziewałem, że po wyłączeniu ROMU będę musiał używać bibliotek zamienników Bocianu - typu CRT_text itp a tu na razie jak widać wszystko działa.

    Co do typów - to tak jestem świadom, portuję z Watcom C (jak robiłem ten symulator na kalkulator w 2003 to przesiałem się na niego z Boland C 3.1 bo Watcom okazał się szybszy i potrafił dużo bardziej agresywnie obcinać nieużywany kod z biblioteki standardowej co okazało się zbawienne by wszystko pomieścić).
    Dzięki za hinta z obniżeniem adresu startu - faktycznie jak znowu trafię na limit to będzie deska ratunku.

    Fastgrapha używam od początku i z pomiarów rysowanie linii jest na tyle szybkie, że na razie nie jest priorytetem w optymalizacjach.
    Typy w samym silniku 3d już optymalizowałem i faktycznie odkrycie FASTmula było decydujące by dać wiarę, że jednak da się z tego zrobić coś szybszego niż pokaz sladjów, tak że FASTMUL już dawno siedzi pod ROMem, tak jak stablicowane sinusy, arcusy i sporo globalów (szkoda że nie da się prosto podać definicji tablicy pod absolutnym adresem i jej od razu zainicjalizować - aczkolwiek poradziłem sobie stosując resource'y RCASM tak że jest wystarczająco elegancko).

    Próbowałem też dostosować liczenie perspektywy tak by użyć stablicowanego dzielenia w zakresie 0-255 i faktycznie przyspieszyło to, ale kod miał jakiegoś buga i jednak potrzebuję większych wartości niż 255 - na razie nie chcę grzęznąć w detalach tak że wróciłem do zwykłego diva - priorytetem jest na razie portowanie funkcjonalności tak by osiągnąć grywalność. Przedwczesna optymalizacja itd - wiadomo.

    Przerobienie zmiennych na globale zamiast przekazywania argumentami do procedur i ograniczanie pointerów też wygląda, że znacznie przyczyniło się do odchudzenia generowango kodu asm.
    W samym asmie na razie zrobiłem właściwie tylko przesuwanie integera o dokładnie 8 bitów bo się dało szybciej.

    @jhusak na razie celowo nie wiążę się z żadnym trybem graficznym - stosuję po prostu Pascalowe line (z moim "frontedem" przycinania wystających poza ekran współrzędnych) i putpixel - InitGraph(6) - czyli 2 kolorowy "mode B" w 80 liniach reszta tekstowa - po implementacji najistotniejszych funkcjonalności dla grywalności, zależnie od ilości pozostałej pamięci i CPU wybiorę rozmiar pola widoku 3d i stosowany tryb. Fajnie by mieć kolory, ale tryb 7 przy stronicowaniu (też nie jest powiedziane że będzie inaczej) żre za dużo pamięci CPU.
    • 13: CommentAuthortebe
    • CommentTime30 Dec 2023 zmieniony
     
    ClipLine(x1,y1,x2,y2);

    rysuje linie z przycięciem, okno definiują zmienne WIN_LEFT, WIN_RIGHT, WIN_TOP, WIN_BOTTOM (są one ustawiane na domyślne wartości podczas InitGraph)

    ClipLine zamiast Line używa fLine (fast line)
  14.  
    quote:

    najniżej można zejść do ok. $980 (-code:980), ładować plik przez XBOOT, albo FoxDOS

    /quote

    ... or uDOS by Stefan Dorndorf (memlo $0938).

    ->link<-

    available for download with german and english instructions.
    • 15: CommentAuthorRoeoender
    • CommentTime31 Jan 2024 zmieniony
     
    Dzień dobry,
    Dla zainteresowanych trochę update'u na temat progresu projektu, trochę pytań i notatek.

    Wybrałem tryb 7 160x64 an obszar 3D, czyli 4 kolory, ze stronicowaniem
    jedną ze stron video po prostu umieściłem poniżej standardowego adresu ładowania $2000 minus rozmiar ekranu czyli $1600 beztrosko nadpisując cokolwiek by tam było,
    z czasem może zejdę jeszcze niżej (na razie jak zapycham pamięć to robię etap optymalizacji pod kątem rozmiaru z dobrym skutkiem).
    oraz 8 wierszy tekstowych na kokpit z przyrządami MFD, radar itp.

    Mam już zaimplementowane (poza tym co już było widać):
    * lockowanie celów naziemnych
    * pociski niekierowane
    * pociski kierowane powietrze-ziemia
    (w sumie wygląda na to, że większość symulatorów pod tym względem dość oszukuje i tylko pokazuje proste animacje na duszkach - u mnie pocisk na prawdę leci i zmienia trajektorię do celu,
    co prawda "po psiej krzywej" :) ale o ile pamiętam to wystarczało)
    * czołgi mogą się stopniowo poruszać - może będą misje typu zniszczyć zanim dotrą do X.
    * prosty radar celów naziemnych widoczny w kokpicie
    * skalowana mapa
    * dynamiczny mechanizm selekcji pobliskich obiektów - misja może zdefiniować 40 obiektów 3D (jak na koniec zostanie pamięci to może będzie więcej), a w czasie lotu co jakiś czas alogrytm na "short listę" przepisuje wskaźniki 16 będących w pobliżu samolotu.

    Oczywiście do zaimplementowania zostało jeszcze sporo podstawowych rzeczy:
    * Wrogie samoloty i ich pociski
    * Wrogie AAA
    * Decoye
    * Detekcja samolotu przez radary i odpalanie pocisków ziemia-powietrze
    * Może jak CPU pozwoli - bomby (CCIP)
    * Generator misji


    PYTANIE:
    1. Ze względu na limit ~64Kb dla kodu chcę, tak samo jak to zrobiłem na kalkulatorze grę podzielić na dwa programy
    W MAIN.XEX użytkownik dostałby logo MAD Pascala :), obrazki, wybrałby/wygenerował sobie misję, uzbrojenie, przejrzał mapę - wybory te zostałyby albo zapisane do pliku, albo umieszczone gdzieś w RAM gdzie nie zostanie to zczyszczone (tak bym wolał)
    i MAIN.XEX odpalałby drugi program FLIGHT.XEX, który implementowałby symulator lotu korzystający z ww. zainicjalizowanych danych,
    na koniec lotu FLIGHT.XEX oczywiście by też zainicjalizował jakieś podsumowujące lot dane i z powrotem odpalił MAIN.XEX.
    Zrobiłem przymiarkę i pięknie to mi zadziałało z XBIOS-em, jak dla mnie XBIOS tutaj idelanie pasuje bo daje mi kilka dodatkowych kilobajtów RAM i daje też API xBIOS_LOAD_FILE realizujące uruchomienie programu.
    Pytanie do specjalistów czy da się to zrobić jeszcze prościej? (zaznaczam kluczowe jest uzyskanie jak największej ilości dostępnej RAM, kosztem niskich adresów i możliwość uruchomienia programu z programu).

    Trochę z "pamiętnika developera":
    Generalnie pisze mi się wspaniale w MAD Pascalu + blibs, to jest zupełnie nowa jakość w porównaniu z tym przez co musieli przechodzić koderzy w "tamtych" czasach.
    Od razu dostaje się szybką funkcję rysowania linii, szybką matematykę, wyłąćzenie ROM-u próg wejścia został obniżony bardzo nisko - chwała!

    1. O ile pamiętam to Initgraph w fastgraph stosuje systemową inicjalizację trybu z display listą z adresem ekranu typu $bxxx co mi nie pasowało bo tam też chciałem mieć kod dlatego zrobiłem własną wersję,
    która po prostu inicjalizuje display listę wg moich ustawień, bez odwołań do systemu, natomiast wielkim zaskoczeniem było dla mnie, że otrzymywałem po prostu czarny ekran.
    Po kilku dniach walki okazało się, że gdy w resources.rc zasób wskazuje na adres pod ROM to DMA jest po cichu wyłączane, w pliku .lst widać:
    mva #0 sdmctl
        sta dmactl

    i już nie włączane z powrotem - wystarczyło zrobić:
    lda #$22
        sta sdmctl

    i zadziałało - niestety nigdzie nie znalazłem opisu tego dość zaskakującego zachowania - chyba przydałby się opis tego zachowania w dokumentacji.

    2. Nie wiem czy w MAD Pascalu da się jakoś porozkładać kod na segmenty? - np. by część kodu była od $2000, a część od $f000,
    jako obejścię tej kwestii robię tak, że wszystko co nie jest kodem upycham jak najwyżej pod ROMEM-em i robię to dość agresywnie - np. dość skanibalizowałem bibliotekę fastgraph,
    bo zauważyłem tam bardzo duże tablice pomocnicze rysowania linii:
    color_bits: array [0..$3ff] of byte;
    	lineLo, lineHi, div4: array [0..255] of byte;

    zmieniłem je tak by były pod konfigurowalnymi absolutnymi adresami (oczywiście pod ROMem),
    ponieważ korzystam też tylko z trybu 7 poupraszczałem też kod obcinająć trochę bajtów tu i tam.

    3. Nie wiem czy w MAD Pascalu jest jakiś mechanizm wymuszania by jakaś tablica była zaraz po innej tablicy lub po prostu pod następnym wolnym adresem po wskazanym adresie
    (znowu chodzi o umieszczanie zmiennych wysoko w pamięci),
    obchodzę to w mało elegancki sposób:
    g_fighter_conn_tab : array[0..2*FIGHTER_CONN_AMT-1] of Byte  absolute 
    	three_d_models_address
    	+ 3 * RenderCoordTypeSIZE * RUNWAY_VERT_AMT 	+ 2 * RUNWAY_CONN_AMT
    	+ 3 * RenderCoordTypeSIZE * GRND_EXPL_VERT_AMT	+ 2 * GRND_EXPL_CONN_AMT
    	+ 3 * RenderCoordTypeSIZE * TANK_VERT_AMT		+ 2 * TANK_CONN_AMT
    	+ 3 * RenderCoordTypeSIZE * FIGHTER_VERT_AMT;

    Czyli de facto na piechotę liczę gdzie wypada następny wolny adres.

    4. O ile pamiętam ClipLine dziwnie działał gdy cała linia była poza zakresem SetClipRect - zamiast nic rysować rysowała 1 piksel - dlatego używam swojej wersji, która de facto stosuje ten sam algorytm.
    Teraz jak już stosuję "skanibalizowaną" fastgraph to już i tak nie istotne.

    5. Czy jest jakiś limit na liczbę "uses"? Projekt obecnie składa się z 22 plików pas i ostatnio mam problem nawet z dodaniem "uses b_crt" - kompilacja zgłasza randomowe miejsce gdzieś w bibliotece standardowej, np.:
    D:\dev\atari\tools\Mad-Pascal-1.6.9\jlibs\system_atari.inc (237,4) Error: Syntax error, '.' expected but ';' found


    6. Trochę brakuje jednocześnie możliwości podania adresu tablicy i jej inicjalizacji, coś w stylu CRT_keycode: array [0..255] of char absolute $f000 = (...) obchodzę to stosując resources.rc z rcasm.

    7. Widzę, że b_crt też "beztrosko" rezerwuje sobie tablicę 256 znaków CRT_keycode bez możliwości podania adresu - możliwe że też skanibalizuję. :)

    Jeszcze raz podkreślam MAD Pascal jest fantastyczny i powyższe to tylko opis sposobów jak sobie radzę z ew. pytaniem czy da się to robić lepiej a nie jakieś uwagi.
    • 16:
       
      CommentAuthorKaz
    • CommentTime31 Jan 2024 zmieniony
     
    Fantastycznie! A szukając informacji o psiej krzywej dla samolotów, żeby się dowiedzieć więcej, jak to jest zrobione, znalazłem ciekawy materiał:




    PS. Pozwoliłem sobie dodać u Ciebie znaczniki [ code ] i [ /code ] co pozwala wyróżnić fragmenty programu i zwiększa czytelność.
    • 17:
       
      CommentAuthoramarok
    • CommentTime31 Jan 2024
     
    @Roeoender, rewelacja! Gratuluję pomysłu i chęci napisania symulatora lotu na małe Atari.

    Cieszę się, że wybrałeś MadPascala - witaj w klubie :).

    Sam wiem jaką to daje łatwość w tworzeniu oprogramowania. Zwłaszcza prototypowanie jest bardzo szybkie. Czasem trzeba przejrzeć plik lst i ręcznie optymalizować kod, ale nie jest to kłopotliwe. Czasem trzeba również napisać coś w assemblerze, ale bardzo ładnie komponuje się to z głównym kodem. MadPascal rządzi :)

    Ad1. Podział na poszczególne programy jest dobry tym bardziej jeśli chcesz, żeby gra działała na komputerze z 64kB RAM. Myślę, że czas oczekiwania na przeładowanie nie powinien być problemem jeśli nie będzie to występowało zbyt często.

    Ad2. Możliwość podziału kodu czy zmiennych na segmenty byłoby wspaniałą sprawą. Co jakiś czas pojawia się ten temat na forum i myślę, że warto o tym rozmawiać. Może wspólnie namówimy tebe do wprowadzenia takiej zmiany. Osobiście bardzo też tego potrzebuję :D

    Ad3. W kwestii dokładnego ułożenia danych też miewam podobny problem i sobie radzę w taki sam sposób jak Ty.

    Ad5. Ja już jakiś czas temu zrezygnowałem z używania wielu plików pas i zamiast nich używam plików inc. Przykładowo w moim ostatnim projekcie, grze platformowej, są 44 takie pliki i jeden główny plik pas z listą dyrektyw dołączających fragmenty kodu. Wcześniej zauważyłem, że jak miałem zmienne w plikach pas, które były używane wielokrotnie (drzewiasta struktura użyć plików pas) to takie zmienne były zwielokrotniane. Pewnie była to jakaś starsza wersja kompilatora albo ja coś robiłem nieprawidłowo. Tak czy inaczej pozostaję przy plikach inc a kolejność dyrektyw {$I} pozwala mi zgrubnie określić ułożenie kodu w pamięci co się czasem przydaje.

    Ad6. Robię dokładnie tak samo ja Ty czyli przez ładowanie zasobów.

    Trzymam kciuki za realizację projektu i życzę wytrwałości oraz motywacji do zakończenia projektu.
    • 18: CommentAuthortebe
    • CommentTime1 Feb 2024 zmieniony
     
    obecna wersja MP to 1.7.1, w pliku CHANGELOG są informacje o zmianach

    limit modułów UNITS ustawiony jest na 256

    uwagę bardziej należy zwrócić na tokens (unlimited), idents (limit 16384), blocks (limit 16384), types (limit 1024)

    65 lines compiled, 2.06 sec, 18397 tokens, 1180 idents, 203 blocks, 7 types

    przykład użycia 24 modułów

    ->link<-
    • 19: CommentAuthorRoeoender
    • CommentTime1 Feb 2024
     
    @Kaz dziękuję, podejrzałem jak się to tu robi i będę formatował.

    @amorak dziękuję za przeczytanie mojej przydługiej wiadomości i potwierdzenie, że te rozwiązania mają sens, a nie że gdzieś błądzę - wielkie dzięki!

    @tebe ściągnąłem 1.7.1 i mam ten sam błąd - niestety wygląda na to, że jednak trafiam na jakiś limit w uses (może wielokrotne uses z różnych unitów i ich zależności się naliczają?).

    Robię coś takiego, stan początkowy który działa ok, w jednym z podunitów:
    implementation
    	uses
    		global_vars,
    		globals, 
    		three_d_render,
    		math_sim;

    Ta wersja loguje:
    280 lines compiled, 17.69 sec, 33427 tokens, 2550 idents, 361 blocks, 14 types


    dodaję do listy b_crt (nota bene ten b_crt jest już pomyślnie użyty w innych podunitach więc o ile rozumiem tu nie powinno to wpłynąć na limit tokenów):

    implementation
    	uses
    		global_vars,
    		globals, 
    		three_d_render,
    		math_sim,
    		b_crt;


    Efekt:
    Mad Pascal Compiler version 1.7.1 [2024/01/30] for 6502
    Compiling falcon.pas
    D:\dev\atari\tools\Mad-Pascal-1.6.9\lib\system_atari.inc (237,4) Error: Syntax error, '.' expected but ';' found


    Ale teraz z listy usuwam np. "math_sim," a zostawiam b_crt:
    implementation
    	uses
    		global_vars,
    		globals, 
    		three_d_render,
    		b_crt;
    		// math_sim;

    i program się kompiluje poprawnie (oczywiście musiałem zakomentować kilka użyć funkcji z math_sim, ale to nie ma znaczenia).
    Taki eksperyment robiłem już kilka razy zawsze z takim skutkiem, że musiałem usunąć jakieś uses by dodać inny - zaczałęm stopniowo po prostu łączyć unity w większe - dzięki czemu pozbywałem się jednego uses i mogłęm dodać nowy, ale wolałbym dążyć dokładnie w drugą stronę - mieć dużo małych skoncentrowanych na jednym tasku unitów.
    • 20: CommentAuthortebe
    • CommentTime1 Feb 2024
     
    podeślij przykład takiego programu jeśli możesz, to ułatwi znalezienie błędu
    • 21: CommentAuthorRoeoender
    • CommentTime1 Feb 2024
     
    Ok w załączniku falcon_uses_diag20240201.zip - bardzo ogołociłem projekt z treści i nadal problem występuje - pozostawiłem oryginalny zakres uses w poszczególnych plikach, include'y itp.
    Kompilacja za pomocą compile_debug.bat.
    Powinien wystąpić błąd:
    Mad Pascal Compiler version 1.7.1 [2024/01/30] for 6502
    Compiling falcon.pas
    D:\dev\atari\tools\Mad-Pascal-1.6.9\lib\system_atari.inc (237,4) Error: Syntax error, '.' expected but ';' found

    Natomiast po zmianie w definitions.pas - usunięciu użycia b_crt w linii 14 powinno spowodować, że projekt się kompiluje.

    Dziękuję za diagnozowanie problemu.
    • 22: CommentAuthortebe
    • CommentTime1 Feb 2024 zmieniony
     
    pobieżnie sprawdziłem, rzeczywiście wyszedł poza zakres tablicy w której sprawdzał powiązane moduły, 256 to za mało

    okazuje się że do tablicy z modułami ładuje też wszystkie includy

    p.s.
    nowa, poprawiona wersja MP na githubie
    • 23: CommentAuthorRoeoender
    • CommentTime1 Feb 2024
     
    Super, na nowej wersji działa też pełny projekt. Drobna zmiana, a ma wielki wpływ na możliwość lepszego podziału kodu na moduły.
    Dziękuję za szybkie rozwiązanie.

Od 1 do 23 z 23

  1.