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 16:02 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 16:02
       
      polecam!

      ->link<-
      • 3:
         
        CommentAuthorpirx
      • CommentTime28 Feb 2020 17:02
       
      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 20:02
       
      Oj nie lubię Eclipse, no ale trzeba będzie się pogodzić :)
      • 5: CommentAuthorilmenit
      • CommentTime28 Feb 2020 20:02
       
      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 21:02
       
      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 22:02
       
      Mi wystarcza Notepad++, kompilacja plikiem .bat z linii poleceń.
      • 8: CommentAuthorgorgh
      • CommentTime28 Feb 2020 22:02
       
      ja podobnie jak shanti88 ( ;) ) korzystam z notepada++ dla assemblerów wszystkich procesorów, na których koduję
      • 9: CommentAuthorgorgh
      • CommentTime28 Feb 2020 22:02
       
      aha chciałem jeszcze dodać, że notepad++ ma kolorowanie składni 6502/z80/0x86/6809
    1.  
      + dla Notepad++
    2.  
      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 16:03 zmieniony
       
      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 08:03 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 10:03 zmieniony
       
      @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 10:03 zmieniony
       
      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 10:03
       
      @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 10:03
       
      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 11:03
       
      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 13:03 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 14:03
       
      Super! Będę streamował kolejne części co wtorek o 21:00, ale się przypomnę jeszcze bliżej wtorku.
      • 21: CommentAuthorzbyti
      • CommentTime5 Mar 2020 23:03 zmieniony
       
      @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 00:03 zmieniony
       
      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 07:03
       
      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 11:03 zmieniony
       
      @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 11:03 zmieniony
       
      @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 12:03 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 12:03 zmieniony
       
      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 12:03
       
      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 12:03 zmieniony
       
      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 13:03 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 13:03 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 14:03 zmieniony
       
      @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 14:03
       
      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 15:03
       
      @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 15:03
       
      rozkaz 'jmp ($ff)' jest wyjątkowy bo ujawnia błąd 6502, to była jedna z ostatnich poprawek
      • 36: CommentAuthorilmenit
      • CommentTime6 Mar 2020 15:03
       
      @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 15:03
       
      @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 15:03 zmieniony
       
      @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 11:03 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?
    3.  
      Da sie z k65 debugowac w Altirra z kodem zrodlowym, albo chociaz symbolami zaladowanymi?
      • 41: CommentAuthortebe
      • CommentTime7 Mar 2020 12:03
       
      a użyłeś optymalizacji dla CC65

      cl65 -t atari -Osir -Cl --listing fname.c.lst --add-source -o fname.c.xex fname.c
    4.  
      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 12:03 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 19:03
       
      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 21:03 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 13:03
       
      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 15:03
       
      @jelcynek, ilmenit znany jest z tego, że robi rzeczy, które nie mają prawa działać na Atari.