atarionline.pl Środowisko ASM na Atari 8bit - 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: CommentAuthorwjakobczyk
    • CommentTime28 Feb 2020 zmieniony
     
    Witam,

    Zastanawiam się nad porobieniem czegoś, w zasadzie to byłby powrót po 30 latach :)
    Doradźcie jakie w XXI w. :) jest najlepsze środowisko pracy? Znalazłem coś tutaj i w sieci ale sprzed 10+ lat, mogło się coś zmienić w kwestii narzędzi.
    Z ciekawości - są zapaleńcy co pracują natywnie? To też mogłoby być ciekawe doświadczenie :D
    • 2:
       
      CommentAuthorbocianu
    • CommentTime28 Feb 2020
     
    polecam!

    ->link<-
    • 3: CommentAuthorpirx
    • CommentTime28 Feb 2020
     
    Są natywni zapaleńcy, prawd. najlepszy jest MAE ->link<- ale ludzie też walczą z MAC/65 itp. Jak nostalgia, to na całego.

    Ale do nowoczesnego developingu WUDSN jest NAJ NAJ NAJ lepszy, normalnie zrywa laczki. Plus support prosto od firmy Peter Dell.
    • 4: CommentAuthorwjakobczyk
    • CommentTime28 Feb 2020
     
    Oj nie lubię Eclipse, no ale trzeba będzie się pogodzić :)
    • 5: CommentAuthorilmenit
    • CommentTime28 Feb 2020
     
    Potwierdzam, do ASMa WUDSN jest niezastąpiony. Nawet umożliwia wstawianie breakpointów do kodu z poziomu edytora oraz konfiguruje Altirrę tak, że wczytuje kod źródłowy i można debugować bezpośrednio na tekstowej formie a nie skompilowanej. Rewelacja.
    • 6:
       
      CommentAuthorbocianu
    • CommentTime28 Feb 2020
     
    Ja też miałem opory, bo nie przepadam za eclipse, ale ta wersja jest tak skrojona, że nic lepszego i wygodniejszego nie znajdziesz.
    • 7:
       
      CommentAuthorshanti77
    • CommentTime28 Feb 2020
     
    Mi wystarcza Notepad++, kompilacja plikiem .bat z linii poleceń.
    • 8: CommentAuthorgorgh
    • CommentTime28 Feb 2020
     
    ja podobnie jak shanti88 ( ;) ) korzystam z notepada++ dla assemblerów wszystkich procesorów, na których koduję
    • 9: CommentAuthorgorgh
    • CommentTime28 Feb 2020
     
    aha chciałem jeszcze dodać, że notepad++ ma kolorowanie składni 6502/z80/0x86/6809
  1.  
    + dla Notepad++
    • 11: CommentAuthorwjakobczyk
    • CommentTime2 Mar 2020
     
    Do kolorowania składni są też pluginy do VSCode które bym preferował, więc to nie problem.
    Najbardziej interesuje mnie kwestia debuggowania, czy bezpośrednio w Altirra jest to wygodne? A może da się połączyć przez gdb, co byłoby optymalnym rozwiązaniem.
    • 12: CommentAuthorzbyti
    • CommentTime3 Mar 2020 zmieniony
     
    N I E A K T Y W N Y
    Też się złamałem i zainstalowałem, oczywiście ciemny motyw ustawiony ;)



    Czy ktoś (dla ciemnego motywu) może ma lepsze kolorowanie dla kodu? Jakąś Draculę czy coś podobnego ma lub może polecić?
    • 13: CommentAuthorjelcynek
    • CommentTime5 Mar 2020 zmieniony
     
    Bardzo polecam customowy assembler od KK z Altair, czyli K65. Co go wyróżnia to składnia bardziej zbliżona do uproszczonego C, mądry linker który sam nam poupycha dane w pamięci jeśli chcemy, sporo dodatkowych narzędzi typu evaluator (możemy np. sobie wypełnić tablicę danymi z równania arytmetycznego, bądź kroków pętli for i jest to obliczane statycznie), wczytywanie plików .bmp jako bajty (interpretując piksel czarny jako 1 i biały jako 0 (albo odwrotnie)).

    Od początku swojej przygody z programowaniem Atari VCS używałem tego i kodowanie w nim jest naprawdę szybkie. Problemem może być skromna dokumentacja. Czasami wygodnie miec bezpośredni kontakt do autora :)

    Teraz robię pierwsze kroki w programowaniu Atari XL/XE i streamuje to na YT (tutaj zapis jeśli ktoś chcę zobaczyć jak się K65 prezentuje:



    A poza assemblerem to uzywam na maksa elastyczne środowisko, czyli Visual Studio Code jako edytor i Makefile (odpowiednik wyżej wspomnianego notepad++ z plikiem .bat) do budowania od razu z komendą uruchamiającą w Altirrze. Jeśli ktoś byłby zainteresowany to mam swój template projektu z makefilem pod windows (trzeba dociągnąć make), ale Krzysiek w swoim projekcie ma przykładowe templateki pod Visual Studio.

    Aha, jest plugin do VS Code do kolorowania składni K65 :)

    Adres do K65:
    Wiki + download: ->link<-
    Źródła: ->link<-
    • 14: CommentAuthorzbyti
    • CommentTime5 Mar 2020 zmieniony
     
    N I E A K T Y W N Y
    @jelcynek wpis w samą porę :]

    To jak VCS to może warto przeczytać ->link<- zdaje się, że wersja elektroniczna jest do zdobycia za free.

    @jelcynek to zaczynam naukę wraz z Tobą ;)
    • 15: CommentAuthorzbyti
    • CommentTime5 Mar 2020 zmieniony
     
    N I E A K T Y W N Y
    Ja na start przerobiłem sobie 6502js (w załączniku) i mam zamiar przelecieć znane większości Easy 6502 ->link<-



    Może przepiszę na html z użyciem 6502js kurs ASM z symulatorem, którego nie widzę na AOL a znajduje się na 2 dyskietkach.

    Jeszcze z użyciem 6502js Przeczytam książkę Ruszczyca.

    Dopiero wtedy mam zamiar wejść na A8.

    Ale filmik jak to się robi obejrzę od razu. :]
    • 16: CommentAuthorjelcynek
    • CommentTime5 Mar 2020
     
    @zbyti Bardzo polecam tą książkę. Sam się z niej uczyłem. Jest bardzo zwięzła, ale też jest naprawdę w niej wszystko co drzemie w VCS (w gruncie rzeczy to prosta platforma). Być może temat audio jest odrobinę po macoszemu potraktowany, ale poza tym to jest to VCS w pigułce :)
    • 17:
       
      CommentAuthorKaz
    • CommentTime5 Mar 2020
     
    O właśnie, miałem wrzucić wtorkowy filmik Jelcynka, ale widzę, że sam to zrobił :)

    Jelcynek - a czy da się ustawić możliwość odtwarzania na innych stronach? Czy są jakieś przeciwskazania?
    • 18: CommentAuthorjelcynek
    • CommentTime5 Mar 2020
     
    Nie ma przeciwwskazań, a nawet są wskazania bo przecież zależy mi by jak najwięcej osób to zobaczyło :) Po prostu jestem gapa i jadę na domyślnych opcjach jutuba. Już włączyłem!
    • 19:
       
      CommentAuthorKaz
    • CommentTime5 Mar 2020 zmieniony
     
    Dzięki! :D

    PS. Jakbyś nagrywał kolejne odcinki z Atari to proszę daj znać, wrzucimy premierę tego samego dnia na główną stronę, większa oglądaność :)
    • 20: CommentAuthorjelcynek
    • CommentTime5 Mar 2020
     
    Super! Będę streamował kolejne części co wtorek o 21:00, ale się przypomnę jeszcze bliżej wtorku.
    • 21: CommentAuthorzbyti
    • CommentTime5 Mar 2020 zmieniony
     
    N I E A K T Y W N Y
    @jelcynek bardzo fajny materiał, chyba sam spróbuję :D

    Dziś zacząłem jeden ze swoich benchmarków przepisywać w MADS ;) Zrobiłem displaylistę dla gr8 z przełączeniem po spacji do tekstowego etc.

    Mówię: fajnie :D teraz tylko wyrysować szachownicę :D ale odpadłem bo nie umiałem zrobić:

    Indirect addressing - uses an absolute address to look up another address.

    Znalazłem tylko w changelogu, że w którejś wersji to wypadło z MADS ;)

    Także spróbuję się z K65, wygląda, na bardziej ogarnialny dla początkującego.
    • 22: CommentAuthorzbyti
    • CommentTime6 Mar 2020 zmieniony
     
    N I E A K T Y W N Y
    Dodam tylko, że linuksiarze najlepiej zrobią instalując K65 jak wykonają poniższe:

    - pobiorą wersję dla windows aby mieć strukturę plików
    - pobiorą kod z repo i skompilują
    - pliki w bin struktury windows zastąpią tymi, które po kompilacji wylądują w out.

    Oczywiście do poprawy zostaną jeszcze ścieżki w plikach: makefile i files.lst i wszystko działa :]

    Dla wygody podrzucam kompilacją dla 64-bit linuxa.
    • 23: CommentAuthortebe
    • CommentTime6 Mar 2020
     
    Quick Assembler jest dla początkującego, żaden tryb adresowania nie wypadł z Mad-Assemblera, musisz zwolnić żeby więcej zobaczyć
    • 24: CommentAuthorzbyti
    • CommentTime6 Mar 2020 zmieniony
     
    N I E A K T Y W N Y
    @tebe

    1. nie chciałem deprecjonować Twojego narzędzia. To oczywiste, że jest najlepsze na rynku. Każdy wymiatacz tutaj (i nie tylko) z niego korzysta.

    2. Co do tego, że muszę zwolnić to prawda ;)

    Przysiągł bym, że wczoraj czytałem (znów późno w nocy) na stronie mads ->link<- w historii, że coś co mnie interesowało wyleciało.

    WUDS krzyczał mi przy jmp ($adres)

    org $2000


    lda #<loop
    sta $e0
    lda #>loop
    sta $e1

    loop inx
    stx $d01a
    jmp ($e0) ;dereferences to loop

    Dziś ani nie mogę odszukać tego co wczoraj (wydaje mi się) przeczytałem, a powyższy prosty kod kompiluje się i działa bez zająknięcia.

    Do tego z adresowaniem wszystko jest tak jak piszesz:

    - rozszerzona składnia makro rozkazu MWA o możliwość użycia adresowania pośredniego strony zerowej postindeksowanego Y, np.:

    mwa ($80),y $a000,x
    mwa $bc40,y ($f0),y
    mwa ($80),y ($82),y

    Może normalnie bym racjonalizował, dlaczego mogło mi nie działać i jak to się stało, że czytałem coś czego teraz nie ma...

    No więc jedyne racjonalne wyjaśnienie jest takie, że muszę zacząć wątpić w swoje zmysły :]
    • 25: CommentAuthorzbyti
    • CommentTime6 Mar 2020 zmieniony
     
    N I E A K T Y W N Y
    @tebe
    Obiecuję, że następnym razem, zanim napiszę, że coś nie działa odczekam minimum jeden dzień, zwłaszcza w sytuacji gdzie stawiam pierwsze kroki.

    Kod (taki "na brudno" sobie na razie wymodziłem), którego wczoraj nijak nie mogłem uruchomić dziś poszedł od pierwszego kopa.

    schess1	= $3000
    schess2 = $4000
    stext = $5000
    RTCLOCK = $14

    org $2000

    mwa #dl8 $230 ;Set Display List pointer

    mva #0 RTCLOCK

    lda #<schess1
    sta $e0
    lda #>schess1
    STA $e1

    lda #$ff
    ldx #0
    ldy #0
    loop sta ($e0),y
    iny
    bne loop
    inx
    inc $e1
    cpx #$1f
    bne loop

    mva RTCLOCK stext

    mva #$ff $2fc
    anykey cmp $2fc
    beq anykey

    mwa #dl2 $230 ;Set Display List pointer

    jmp * ;End


    .local dl8
    .byte $70,$70 ;2x8 empty scanlines
    .byte $4f,a(schess1)
    :94 .byte $0f
    .byte $4f,a(schess2)
    :92 .byte $0f
    .byte $41,a(dl8) ;Wait VBL, jump DL
    .endl

    .local dl2
    .byte $70,$70 ;2x8 empty scanlines
    .byte $42,a(stext)
    .byte $02
    .byte $41,a(dl2) ;Wait VBL, jump DL
    .endl

    Oczywiście to mój pierwszy kod w MADS na A8 w życiu, więc nie chodzi o to czy jest dobry, ale, że działa :D a wczoraj WUDSN nie mogłem zmusić do kompilacji i nie mogłem dojść dlaczego.

    EDIT: tak nawiasem (przypadkiem) powyższy kod chyba jest benchmarkiem opisanym w artykule o Action! ->link<- :D

    Although I love standards, I don't like the Sieve. It's not easy for beginners to understand, it takes too long (in BASIC, anyway), and it doesn't test the Atari under real-world conditions, with lots of 6502 processor time being "stolen" by Antic for video DMA. I wanted a benchmark that anybody could appreciate, operating under the kind of DMA conditions an Atari program is likely to find itself up against.

    Back in Issue 11, I devised a little program that fills a GRAPHICS 24 screen with color, one byte (eight pixels) at a time. It was used to compare a couple of BASIC compilers at the time, but it's equally valid in any run-time environment. My definitive BASIC implementation of this test appears in Listing 5. Screen Fill, as the program shall henceforth be known, executes in 4.025 jiffies or about 67 seconds on a 48K 800. (Again, improvements are possible, but for the sake of clarity let's stick to Listing 5.) I'll be using Screen-Fill in conjunction with the Sieve to judge the performance of every new language I review from now on. So let it be written; so let it be done.

    Listing 5.

    10 REM * SCREEN-FILL BENCHMARK
    11 GRAPHICS 24
    12 POKE 19,0:POKE 20,0
    13 SCREEN=PEEK(88)+256*PEEK(89)
    14 FOR I=0 TO 31
    15 FOR J=0 TO 239
    16 POKE SCREEN+J,255
    17 NEXT J
    18 SCREEN=SCREEN+240
    19 NEXT I
    20 TIME=PEEK(20)+256*PEEK(19)
    21 GRAPHICS 0
    22 PRINT TIME;" JIFFIES"

    Listing 7.

    BYTE RTCLOCK=20, ; addr of sys timer
    SAVMSCL=88, ; lsb of screen addr
    SAVMSCH=89, ; msb

    I,J,TIME ; declare variables

    CARD SCREEN

    PROC BENCH()

    GRAPHICS(24)
    RTCLOCK=0

    SCREEN=SAVMSCL+256*SAVMSCH

    FOR I=0 TO 31
    DO
    FOR J=0 TO 239
    DO
    POKE(SCREEN+J,255)
    OD
    SCREEN==+240
    OD

    TIME=RTCLOCK

    GRAPHICS(0)
    PRINTF("%E %U JIFFIES",TIME)

    RETURN
    • 26: CommentAuthorxxl
    • CommentTime6 Mar 2020 zmieniony
     
    ldx $00


    tu jest blad. dalej nie czytalem


    taka konstrukcja:
    lda #<schess1
    w mads moze dziala ale w ktoryms asemblerze nie (nie jestem pewny czy na atari). zwlaszcza gdy argumentem jest jakies wyrazenie

    lepiej przyzwyczajac sie do:
    lda #.lo(schess1)
    • 27: CommentAuthorzbyti
    • CommentTime6 Mar 2020 zmieniony
     
    N I E A K T Y W N Y
    faktycznie ldx#0 z rozpędu postawiłem dolara bez hasza, miej litość nade mną :D

    dzięki za podpowiedź, instrukcja do MADS to dla mnie aktualnie spora lektura na którą nie mam dość czasu. Bazowałem na ten moment na wideo-kursie Petera Della.
    • 28: CommentAuthorxxl
    • CommentTime6 Mar 2020
     
    to sa tylko podpowiedzi.

    ldy #$00 i lda #$ff wyjmij za petle - zawsze trosze szybciej
    poza tym ... adresowanie (zp),y jest wolniejsze od absolute,y wiec ta petla moze byc sporo szybsza...
    • 29: CommentAuthorzbyti
    • CommentTime6 Mar 2020 zmieniony
     
    N I E A K T Y W N Y
    thx :] oczywiście zastosuję część teraz a resztę uwag później.

    Tego K65 jeszcze dotknę, właśnie on wygląda mi na duchowego spadkobiercę Action! chociaż wiem, ze to inny poziom ale składnia jakaś taka ludzka :]

    Ale to wszystko po "obiedzie: ;)

    EDIT: edytowałem kod więc uwagi @xxl nie były z czapy chociaż teraz może nie być wiadomo o czym pisał ;)
    • 30: CommentAuthorsolo/ng
    • CommentTime6 Mar 2020 zmieniony
     
    skoro chcesz optymalizacje, to zamiact inx, zrob z dex, odpadnie ci jeden rozkaz:

    ldx #$1f
    ldy #0
    loop sta ($e0),y
    iny
    bne loop
    inc $e1
    dex
    bpl loop


    ogolnie to jezeli cos nie jest w main loopie tylko jakas inicjalizacja to mozesz spokojnie zwykle olewac takie "optymalizacje"- do pewnej granicy rozsadku oczywiscie. zwykle kluczowych miejscach robi sie optymalizacje/rozwija kod itd.
    • 31: CommentAuthorxxl
    • CommentTime6 Mar 2020 zmieniony
     
    to jeszcze tak i z 7500 cykli szybciej ;-)

    loop	        sta schess1,y
    iny
    bne loop
    inc loop+2


    azeby bylo powtarzalnie to mozna jeszcze do reg x ladowac .hi(schess1)+$1f ... jest miejsce na optymalizacje...

    ====
    albo nawet 8160 cykli szybciej... dobrze licze?
    • 32: CommentAuthorzbyti
    • CommentTime6 Mar 2020 zmieniony
     
    N I E A K T Y W N Y
    @solo/ng słuszna uwaga. Teraz rozumiem dlaczego w CC65 w pętlach FOR @antrykot pozamieniał ++i na --i :]

    @xxl sprawdzę tę sztuczkę, dzięki :]

    Optymalizacje jakie Panowie tu podają są bardziej zrozumiałe niż obszerna wiedza jak się zachowuje dany kompilator i dlaczego trzeba w danym języku pisać tak a nie inaczej by było szybciej ;) Widać ASM nie tylko w szybkości ma zaletę ale także w uniwersalności optymalizacji kodu.
    • 33: CommentAuthorxxl
    • CommentTime6 Mar 2020
     
    dobrym pomslem na optymalizacje jest takze przyjrzenie sie czy petle nie wychodza na granicy strony ;-) skoki bxx na granicy strony zabieraja 1 cykl wiecej
    • 34: CommentAuthorzbyti
    • CommentTime6 Mar 2020
     
    N I E A K T Y W N Y
    @xxl spróbuję zastosować większość rad jak zrobię bench z szachownicą, ale to już w innym wątku.

    Dzięki za hinty.
    • 35: CommentAuthortebe
    • CommentTime6 Mar 2020
     
    rozkaz 'jmp ($ff)' jest wyjątkowy bo ujawnia błąd 6502, to była jedna z ostatnich poprawek
    • 36: CommentAuthorilmenit
    • CommentTime6 Mar 2020
     
    @solo/ng słuszna uwaga. Teraz rozumiem dlaczego w CC65 w pętlach FOR @antrykot pozamieniął ++i na --i


    Znajomość procka 6502 bardzo pomaga pisać efektywny kod w językach "wyższego poziomu" jak C czy Pascal na tę platformę (co to strona strona pamięci, co procesor może adresować, jak jest szybkość dostępu do stałych lub do zmiennych, jaka jest cena indirect access itd.)
    • 37:
       
      CommentAuthorcrrn
    • CommentTime6 Mar 2020
     
    @ilmenit
    Wtrącę swoje 3 grosze, bo jak już ktoś zna te wszystkie "strony, adresacje, itp" to po prostu lepiej pisać w asm. :)
    mam w ogóle takie wrażenie że asm jest jakoś demonizowany, ale jak wspomniał ten kolega na filmie (jelcynek?) w obecnych czasach to na prawdę nie powinna być magia.
    assembler jest na serio łatwy. załapać trzeba tylko kilka kluczowych zasad.

    a sam wątek bardzo fajny sam kilka z polecanych tutaj przez was narzędzi przejrzałem - dla porównania. na C64 (sorry za mały offtop) bardzo popularny jest ostatnio kick assembler (kickass) który dodaje masę funkcji znanych z języków wysokiego poziomu. nie wiem czy nada się do pisania dla atari, ale serdecznie polecam. niektóre elementy w K65 widzę są niemal identyczne w KickAssie. a to w tym momencie bardzo dojrzały "kompilator" (wiem - powinienem napisać assembler)
    • 38: CommentAuthorzbyti
    • CommentTime6 Mar 2020 zmieniony
     
    N I E A K T Y W N Y
    @ilmenit masz rację. Prawie każdy z was mówił przy tej czy innej okazji, że jak będzie coś kluczowego dla szybkości działania programu to robicie wstawkę w ASM.

    Nie znając ASM jestem tej możliwości pozbawiony.

    Dlatego ostatecznie zacznę naukę od ASM etc. a jak już się nauczę w miarę podstaw to wrócę to języków wysokiego poziomu wyposarzony jednak w asa w rękawie ;D

    Także, mówi się trudno, zaczynam mozolną naukę 6502 i mapy pamięci A8.

    Jakie są dostępne języki na A8 z grubsza obadałem czas dowiedzieć się co się dzieje pod spodem ;)

    @crrn zdążyłeś się wstrzelić zanim skończyłem pisać. Dla jednych łatwy dla drugich nie - sprawdzę jak to jest ze mną ;) Mi się marzą szachy. Silnik w ASM - dlaczego nie, ale GUI? Ten fragment programu już wolę w Mad Pascalu lub CC65, po co rzeźbić niepotrzebnie?
    • 39: CommentAuthorwjakobczyk
    • CommentTime7 Mar 2020 zmieniony
     
    To k65 wyglada bardzo ciekawie.
    Robilem ostatnio proby z cc65 ale generowany kod jest tragicznie slaby, nie wiem czy do czegokolwiek to sie nada. Ktos uzywal w realnych projektach?
    • 40: CommentAuthorwjakobczyk
    • CommentTime7 Mar 2020
     
    Da sie z k65 debugowac w Altirra z kodem zrodlowym, albo chociaz symbolami zaladowanymi?
    • 41: CommentAuthortebe
    • CommentTime7 Mar 2020
     
    a użyłeś optymalizacji dla CC65

    cl65 -t atari -Osir -Cl --listing fname.c.lst --add-source -o fname.c.xex fname.c
    • 42: CommentAuthorwjakobczyk
    • CommentTime7 Mar 2020
     
    Tak, oczywiście włączałem optymalizację.
    Tzn. ja to rozumiem, 3 rejestry nie dają dużego pola do popisu dla kompilatora :)
    • 43: CommentAuthorilmenit
    • CommentTime7 Mar 2020 zmieniony
     
    crrn:
    Wtrącę swoje 3 grosze, bo jak już ktoś zna te wszystkie "strony, adresacje, itp" to po prostu lepiej pisać w asm


    Ja znam asm całkiem dobrze, ale większość moich projektów to 95%+ C i 5% Asm. Powód? Mam ograniczony czas na hobby, więc największą zaletą jest szybkość pisania. Pisanie w C jest około 4-5 razy szybsze niż w Asm. Nawiasem mówiąc pisanie w C++ jest dla mnie ze 2 razy szybsze niż w C (gdzie jest brak podstawowych struktur danych, iteratorów, obsługi pamięci, operacji na stringach, polimorfizmu itd.) a w C# jeszcze około 2 razy szybsze niż w C++.
    Biorąc pod uwagę, że aktualny projekt robię już około 4-5 miesięcy, gdybym miał go robić w czystym Asm, to przy moim wolnym czasie by to trwało 1,5 roku i bym się pewnie "projektowo wypalił" i nigdy go nie dokończył.
    Największą zaletą pisania logiki gry w C jest to, że gdy mam oddzieloną warstwę prezentacji, grę mogę pisać w Visual Studio IDE, które ma rewelacyjny debugger, nawigację w kodzie, refactoring itd. oraz bezpośrednio z edytora poziomów "grać w grę", a potem ten sam kod główny działa identycznie na Atari. To jest niezastąpione :)
    • 44: CommentAuthorjelcynek
    • CommentTime7 Mar 2020
     
    Największą zaletą pisania logiki gry w C jest to, że gdy mam oddzieloną warstwę prezentacji, grę mogę pisać w Visual Studio IDE, które ma rewelacyjny debugger, nawigację w kodzie, refactoring itd. oraz bezpośrednio z edytora poziomów "grać w grę", a potem ten sam kod główny działa identycznie na Atari. To jest niezastąpione :)


    ilmenit czy mógłbyś opisać jak takie środowisko jest skonfigurowane? Ewentualnie pokazać jakiś przykładowy projekt. Brzmi to interesująco.
    • 45: CommentAuthorilmenit
    • CommentTime7 Mar 2020 zmieniony
     
    @jelcynek - po release nowej gry udostępnię ją na Githubie. Ogólnie to nic odkrywczego. Mam projekt w Visual Studio pisany w C z wykorzystaniem biblioteki Allegro 5 (mógłaby być też np. SDL). Zaletą tej biblioteki jest to, że jest "niskopoziomowa", to nie framework jak Unity czy Unreal, więc pętla gry może być taka sama na wszystkie platformy.
    Kod mam podzielony na dwie główne części: wspólne i zależne od platformy (common i platforms). Przykładowo struktura katalogów może dla takiego projektu wyglądać tak:
    - [common]
    --- main.c
    --- main.h
    --- level.c
    --- level.h
    --- system.h
    --- input.h
    --- gfx.h
    --- sfx.h
    - [platforms]
    --- [atari]
    ------ system.c
    ------ input.c
    ------ gfx.c
    ------ sfx.c
    --- [allegro]
    ------ system.c
    ------ input.c
    ------ gfx.c
    ------ sfx.c

    Pliki C dla poszczególnych platform zawierają implementacje funkcji z odpowiednich nagłówków, typu:
    draw_screen() w gfx.c implementuje funkcję definiowaną w gfx.h
    get_player_action() implementuje funkcję z input.h
    play_music() implementuje funkcję z sfx.h
    itd.

    Przykładowa struktura gry w main.c może wyglądać tak:

    // include common headers
    #include "level.h"
    // include headers of platform dependent functions
    #include "system.h"
    #include "input.h"
    #include "gfx.h"
    #include "sfx.h"

    int main(void)
    {
    byte action;
    init_system(); // tu inicjalizacja konkretnej platformy np. stworzenie okna Allegro lub ekranu DLI na Atari.
    for(;;)
    {
    load_level(); // common function to load level
    play_music(MUSIC_TRACK_1); // call function in sfx.c
    while(!level_complete)
    {
    draw_screen(); // call function in input.c (or even .ASM)
    action = get_player_action(); // call function in input.c
    if (action == ACTION_MOVE)
    {
    perform_move(); // common game logic
    play_sound(SFX_MOVE); // call function in sfx.c
    }
    }

    }
    }

    W zależności od platformy są różne skrypty budujące, kompilujące i linkujące odpowiednie pliki C z wybranych katalogów. I tyle, nic skomplikowanego.
    • 46: CommentAuthorjelcynek
    • CommentTime8 Mar 2020
     
    Jeśli dobrze rozumiem, odseparowałeś logikę od rysowania. Czyli wymieniasz "renderer" (sdl i allegro znam jako tako, więc rozumie na jakim poziomie abstrakcji pracują) i testujesz grę na PC, a potem kompilujesz dla ATari. GDzie funkcje rysujące są inne i odpala się to samo na Atari. Dobrze rozumiem?

    Ciekawe. Chciałbym to zobaczyć w akcji. Bo w mojej głowie to nie może się udać, a Ty to jednak robisz. Daj znać jak będziesz udostępniać kod.
    • 47:
       
      CommentAuthorjhusak
    • CommentTime8 Mar 2020
     
    @jelcynek, ilmenit znany jest z tego, że robi rzeczy, które nie mają prawa działać na Atari.