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

• Zapomniane hasło?
• Poproś o członkostwo

1. • 1:
      
     CommentAuthorpancio
   • CommentTime6 Jan 2024 21:01

    
   Zaczynamy... :-)
2. • 2:
      
     CommentAuthorKaz
   • CommentTime7 Jan 2024 19:01

    
   Wszystkie pytania padały na Last Party, a odpowiedzi są na głównej stronie, więc pewnie za dużo dyskusji tu ostatecznie nie będzie. Ale Tebe i Laoo podrzucili ciekawe pomysły, jak zaprezentować jeszcze inaczej ten tryb, to może skorzystamy (dzięki!).
   
   Dla potomności, filmik z demka, który przez przypadek włączyliśmy dzisiaj o 16:30 zamiast wczoraj po kompotach:
   
   

   
   
   I link do nowinki: ->link<-
3. • 3: CommentAuthortebe
   • CommentTime7 Jan 2024 22:01

    
   gdzie kod źródłowy z przykładem ?
4. • 4: CommentAuthormono
   • CommentTime7 Jan 2024 22:01 zmieniony

    
   @tebe: Proszę uprzejmie.
   
   W archiwum są pliki:
   - Kaz_Lew.g2f - plik źródłowy od Kaza
   oryginalne wyeksportowane przez g2f:
   - Kaz_Lew.asm - kod w asm
   - Kaz_Lew.fad - efekt
   - Kaz_Lew.fnt - fonty
   - Kaz_Lew.h - definicje dla asm
   - Kaz_Lew.pmf - coś
   - Kaz_Lew.png - screenshot
   - Kaz_Lew.scr - ekran
   - Kaz_Lew.xex - binarka z eksportu z g2f skompilowana madsem
   i moje:
   - Kaz_Lew.asx - mój zmodyfikowany asm
   - Kaz_Lew.lst - listing z kompilacji madsem mojego asma
   - Kaz_Lew.obx - mój wynikowy plik wykonywalny
   
   Kompiluje się to za pomocą:
   

   mads Kaz_Lew.asx

   
   
   Można sobie porównać źródła asm z asx jakimś Meld'em żeby zobaczyć co jest zmodyfikowane. W zasadzie niewiele, ale do realizacji efektu zrobiłem
   

   sta WSYNC
   bit $x0   ;ZPG
   

   
   z komórkami $00=$00, $10=$10, $20=$20, itd. aż do $F0=$F0, bo dzięki temu na magistrali mi się pojawia:
   

   $24 - BIT.Z
   $x0 - adres
   $x0 - wartość spod adresu $x0
   

   
   po czym wykonuje się następny rozkaz co jest szybsze w porównaniu z BIT $x0x0 o cykl a zrobi to samo, czyli utrzyma $x0 przez dwa cykle na magistrali.
   
   Zaaplikowany jest też patch na 240-liniowy hires z adresowaniem DMACTL przy etykietach "sync" i "_240".
   
   "NMI" jest przeniesione z końca pliku do góry, a na końcu pliku jest dodana procedura "updategraphics" która aktualizuje argumenty instrukcji BIT na podstawie zawartości 48 znaku w wierszu - generując kod asm z g2f możesz to od razu uzupełnić na podstawie zestawu znaków.
   
   I w "main" jest dodana pętla fill wypełniająca bajty na ZPG - niepotrzebna kiedy używa się BIT $x0x0.
   
   Wyjaśnienia wymaga jeszcze dlaczego w oryginalnym asm mamy w DL tryb $04 a nie $02 skoro przecież obrazek jest w hiresie. Kaz pisał o tym w artykule - G2F w trybie hires wyświetla 239 linii skanningowych i używa tricku z podniesieniem ostatniego wiersza o 1 linię w górę. Wtedy w ostatniej linii ekranu wyświetlana jest pusta linia (JVB) i ekran nie zrywa synchronizacji. No ale zestaw znaków jest zepsuty, bo treść grafiki musi być przesunięta o linię w dół.
   W trybie multicolor ekran nie zrywa synchronizacji przy 240 liniach skanningowych dlatego przed eksportem do asm zmieniamy wszystkie wiersze z hiresu na multicolor i zestaw znaków jest poprawny, dzięki czemu mogę wtedy już poprawnie wyświetlić ostatni wiersz ekranu w hiresie :) Bo u mnie DL jest oczywiście z trybem $02.

   • Kaz_Lew.zip
5. • 5:
      
     CommentAuthorKaz
   • CommentTime8 Jan 2024 08:01

    

   Mono:

   Kaz pisał o tym w artykule - G2F w trybie hires wyświetla 239 linii skanningowych i używa tricku z podniesieniem ostatniego wiersza o 1 linię w górę. Wtedy w ostatniej linii ekranu wyświetlana jest pusta linia (JVB) i ekran nie zrywa synchronizacji. No ale zestaw znaków jest zepsuty, bo treść grafiki musi być przesunięta o linię w dół.

   
   
   TeBe - poprosimy o aktualizację G2F, żeby program takich bezecnych rzeczy z fontami nie robił :). Albo robił, ale jako opcję wyłączalną. No i poprosimy o implementację poprawki Rybagsa (wyświetlanie 240 linii).
6. • 6: CommentAuthortebe
   • CommentTime8 Jan 2024 11:01

    
   nikt o tym nie wie i nikt się nie dowie, bo zawsze najwięcej jest ignorantów :P
7. • 7:
      
     CommentAuthorgienekp
   • CommentTime8 Jan 2024 16:01 zmieniony

    
   To żeby mi się nie pomerdało.
   
   W BASICowym GR.9/GR.10/GR.11 mam 89 pikseli (prostokątów) w poziomie (356/4).
   Śmieci pojawią się na ostatnim? Czy wcześniej?
   
   Zakładając, że nie chcę nic tam malować tylko żeby było 0, to na którym pikselu trzeba hamować CPU?
   
   NTSC coś tu nowego wnosi?
8. • 8: CommentAuthormono
   • CommentTime8 Jan 2024 17:01 zmieniony

    
   NTSC ani SECAM nie testowaliśmy - tylko PAL, ale choć ANTIC jest inny, to podział linii jest taki sam na 114 cykli - trzeba by sprawdzić.
   
   Śmieci w trybach GTIA pojawią się na ostatnim pikselu. A CPU ma podstawić dane tak samo jak w hiresie, bo z tym różnicy nie ma ani w hires, ani w multicolor, ani w GTIA. Choć warto byłoby zrobić też test z trybami w których piksel ma więcej linii ekranowych (GR.2-7, GR.13).
9. • 9: CommentAuthortebe
   • CommentTime8 Jan 2024 17:01

    

   sta WSYNC
   bit $x0   ;ZPG
   

   
   
   po WSYNC masz wrzucić na magistralę wartości $00 i tak co linię, czyli na całej wysokości obrazka CPU zajęty jest wbijaniem zer
   
   po 106 cyklu w linii, linia liczy 114 cykli
   
   ->link<-
   
   PAL / NTSC różni się liczbą wyświetlanych linii a nie ich długością
10. • 10:
       
      CommentAuthorgienekp
    • CommentTime8 Jan 2024 17:01

     
    Kumam!
    
    W LineConverterze jadę w Gr.9. Mam przez całą linię cykle policzone, bo zmieniam barwę, więc w zasadzie powinno mi się udać wstrzelić w magistralę bez WSYNC.
    
    Tak się jeszcze zastanawiam. Mam obraz ładnie poukładany w RAM. Ostatni piksel się nie wyświetla. Ale jakby było odpowiednio wcześniej LDA na ten piksel. To piksel powinien się pojawić, dokładnie ten, którego brakło i dokładnie z miejsca RAM gdzie to jest.
11. • 11: CommentAuthormono
    • CommentTime8 Jan 2024 18:01

     
    Tak. Musisz się jednak precyzyjnie docyklować. Weź pod uwagę jednocyklowy jitter o którym pisze phaeron na AtariAge ->link<- i z powodu którego wystawiam na magistralę wzór przez dwa cykle. Warto by sprawdzić jak zadziała ten INC WSYNC (pewnie dowolny RMW zadziała) a potem precyzyjne liczenie cykli. Ale powinno się udać.
12. • 12:
       
      CommentAuthorYosh
    • CommentTime8 Jan 2024 18:01 zmieniony

     
    To jest temat o pikselach po prawej stronie szerokiej ramki ?
    To jest opise w Altirra Hardware Reference Manual przynajmniej od 2018 roku
    
    "Virtual DMA cycles
    Playfield DMA cycles that would occur on cycle 106 or later are blocked by the hardware and do not occupy the
    bus or stop the 6502. However, ANTIC still reads the data bus and stores or interprets the data on those cycles.
    This usually results in 6502 bus activity being loaded as playfield data."
    
    

    
    

    
    
    Z kodu playera dla hashi playera
    
    lda #0 ; virtual antic reads 0
    
    Ktore notabene mono ogladal przy jakies okazji :D
    
    Pamietam jak podejmowalem decyzje ze w moim playerze bedzie 352 piksele szerokosi (np w bad apple - okolo 3:34 w video o playerze) + 4 czarne - wlasnie przez strategiczne lda #0 w odpowiednim miejscu zeby antic zalizal.
    
    Mialem nawet strumieniowac tam tez obraz, ale na moim telewizorze z tych 4 pikseli bylo widac dwa :D
    
    Dragons Lair nie ma 'syfu z prawej' bo nie wypada :) A teraz mi mowicie ze nikt nie widzial ? Myslalem, ze jak jest w Altirra HW to tak kazdy robi i juz
13. • 13:
       
      CommentAuthorYosh
    • CommentTime8 Jan 2024 18:01

     
    I dzieki pavros owi licznik zyc i punkty w dragon's lair sa poza playfieldem (na wiekszej niz 240 lini :)
    
    ->link<-
    
    To naprawde jest zrobione na plecach gigantow :)
14. • 14:
       
      CommentAuthorKaz
    • CommentTime8 Jan 2024 18:01

     
    Yosh, wręcz przeciwnie - Mono cały czas powtarza, że te informacje w manualu od Avery'ego Lee są powszechnie dostępne i znane koderom, nawet ten fragment zacytowany jest w artykule :)
    
    Tylko nikt nie wykorzystywał tego do wyświetlenia grafiki. Mogłeś być z tym pierwszy, a dałeś tam zera zamiast grafiki, szkoda! W obu Twoich wideo podpisy, że rozdziałka filmików to 352 na 239 pikseli, więc nie gniewaj się, że nikt z nas nie wiedział, że bawiłeś się magistralą:
    
    

    Yosh:

    Z Video: 352x239 (gr8) 50 FPS, timed directly into Antic.
15. • 15: CommentAuthormono
    • CommentTime8 Jan 2024 18:01

     
    No to co? Filmy w 356x240? U nas jest 356x240.
16. • 16: CommentAuthortebe
    • CommentTime8 Jan 2024 18:01

     
    ten pierwszy kto napisze że jest pierwszy, Yosha ubiegł Mono :)
17. • 17:
       
      CommentAuthorYosh
    • CommentTime8 Jan 2024 19:01 zmieniony

     
    Tak jak pisałem - zwlaszcza w trybie 256 kolorow 16 jasnosci/ 16 kolorow to jest JEDEN pixel z tej szyny luzem. Wiec 88 nie bylo duzo gorsze niz 89 (no napewnoe nie tak zle jak 80 :D)
    
    Mi wystarczyl tam niezasyfiony czarny.
    
    @Kaz, to nie jest tak - ja liczylem, ze tak szanowne techniczne grono zauwazy ze jest szeroka ramka (o ktorej trabilem) a nie ma syfow - to byl taki 'smaczek' i pare osob do mnie w 2018 podchodzilo pytac jak to jest ze tam nie ma krzakow.
    
    Wiec player wyswietla czyste 356 w lini - poprostu osatatnie 4,2,1 sa czarne :D
    
    Masz oczywiscie racje ze 352 brzmi jak "352 i syfy" a nie jak "352 i ladny czarny". Dla mnie po prostu bylo oczywistym ze nie mozna takiej kaszany komus pokazac jak sie robi cos w wide trybie.
18. • 18:
       
      CommentAuthorKaz
    • CommentTime8 Jan 2024 20:01 zmieniony

     
    Yosh - to prawda, w trybie GTIA to tylko jeden piksel szerzej, ale zawsze coś! Wielka szkoda, że zamiast wyświetlania grafiki ograniczyłeś się do generowania czarnego i jeszcze napisałeś w opisie "352 piksele" (+ "ładny czarny", ale ładny czarny to nie jest to samo co pełna kontrola nad pikselami grafiki). To może zmylić :)
    
    A dałbyś radę i miałbyś chęć zmodyfikować swój player, żeby tak jak u nas, wyświetlał tam grafikę, a nie czerń? Mielibyśmy na Twoim carcie również filmy szerokości 356 pikseli, a właściwie 89 zamiast 88? Czerń niestety nie jest osiągnięciem, bo jak już pisałem w artku, graficy już wcześniej potrafili uzyskiwać przykrycie tych śmieci duszkami.
    
    A szczerze powiedziawszy, to Twojego rozwiązania trochę nie rozumiem - po co tam podstawiać czarny zamiast grafiki, skoro i tak musi być wykonany program? Czy to wynika z trudności konwersji filmu do nieparzystej szerokości 89 pikseli czy jakaś inna przyczyna?
19. • 19:
       
      CommentAuthorYosh
    • CommentTime8 Jan 2024 23:01

     
    To może najpierw część techniczna.
    
    89ty piksel (bo tak mi się o nim łatwiej mówi niż "ostatnie cztery") jest czytany przez Antica ale nie adresowany. A skoro nie jest adresowany prez Antica, to hasa tam 6502, a jak hasa tam 6502 to na szynie danych są dane z RAMu (albo do RAMu)
    
    Co oznacza, że "wiec, że coś się dzieje" - nie mogę cartem swoim wymusić danej na szynie danych bo będzie się siłować z tym co chce wystawić CPU (przy zapisie) albo to co RAM (przy odczycie)
    
    w 88 pikselach po prostu czyta Antic a 6502 stoi - to znaczy, że moge z carta podkładać dane i z nikim o nic nie walcze.
    
    89 nie jest pikselem Antica, on jest pikselem CPU.
    
    Od tego miejsca są dwie drogi:
    - samemu ciagać za HALT - ale on jest na ECI, ale to nie jest czyste, ale... ale... no daaaaaaaasieeee
    - bez HALT tez się da, skoro linia ekranu jest w dostępach poszatkowana z grubsza na
    
    CACACACACACACACA (Cpu Antic)
    
    To aktualnie w liniach CPU leci kod który ręcznie czyta d5xx
    
    lda d500
    ldx d500
    
    CACACAxACACACAxACA
    
    x to 6502 adresujace d5, a to oznacza ze RAM się nie wcina, a to oznacza ze moj cart wystawia 31k 8bit mono audio (2 razy na linie 8 bitowy sampl), taki sam trik dało by się dla 89 piksla
    
    Będę na Lost to pogadamy przy piwku :D
    
    Czy czarny nie jest osiągnięciem ? Troche jednak jest - syf także da się pokryć duszkami (no gr.8 to z tego nie będzie..... ale inne tryby i owszem). No i mając czarny tam mogłem w dragon's lair wyświetlać 'hinty' dla gracza w polu gry (a nie tylko na dole) - czyli działa podkoloryzowanie
    
    

    (króciutka strzałeczka po prawej stronie ekranu)
    
    A wiadomo, marzenia to się miało na
    

    
    więc nałożone duszki jak znalazł :D
    
    Troche pytałeś innym razem, offtopowe detale sa tu
    ->link<-
    
    Dla mnie najważniejszy TERAZ to:
    "44 bytes per line (wide screen, I can't find how wide screen with SIDE 2), on my TV i see 87 pixels (almost all) - and if you have 80, the 8 more are noticeable (mostly - it fills MY whole screen:P)"
    
    A to oznacza, że spiesząc się na SV2018 brak syfu był good enough :):)
20. • 20:
       
      CommentAuthorKaz
    • CommentTime8 Jan 2024 23:01

     
    O, fajne! dzięki Yosh. A piwko wiadomo, będziemy testować różne smaki :D
21. • 21:
       
      CommentAuthorYosh
    • CommentTime8 Jan 2024 23:01

     
    Cieszę się oczywiście, że tak porządny art powstał - może jakieś przygodówki powstaną z duża grafiką.
    
    Ale dajcie mi trochę jadu posączyć - chce się poczuć jak prawdziwy Atarowiec! (średnio mi to wychodzi, bo ten jad ma bliżej do podtlenek azotu niż cyjanku)
22. • 22: CommentAuthortebe
    • CommentTime9 Jan 2024 01:01

     
    ->link<-
    
    w którym miejscu czytając ten opis z 2018-11-19 można wywnioskować że zostały wyłączone śmieci pojawiające się z prawej strony ekranu?
    
    dla twórcy może być coś oczywistą oczywistością, ale jaką ma pewność że jakikolwiek widz odbierze to w ten sam sposób?
    
    proszę pisać wstępy oznajmiające przełomowe osiągnięcia, serio, piszcie w pliku readme, co zostało osiągnięte...
    
    przecież prototyp ma tylko twórca, jedyny dowód to prezentacja na SV i film na youtube, co z tego można wywnioskować
    
    jak z grafikami Rocky-ego które on rozumie co jest "pod spodem" ale inni widzą tylko kolor i układ pikseli, ale nie technikalia które za tym stoją, też mu mówię żeby przed zaprezentowaniem takiej grafiki wstawił ekran z opisem co i jak zostało osiągnięte
23. • 23: CommentAuthorRocky
    • CommentTime9 Jan 2024 10:01

     
    Już śpieszę z wyjaśnieniem, co zaistniało w obrazku last_robbo..
    
    Sam obrazek powstał na party więc o artyzmie nie było mowy.
    Jest w nim przełączanie palet w ten sposób, że udało mi się uzyskać czarne ramki (prawa, lewa) bez użycia spritów..
    Sprity maskują jedynie górny łuk oraz odpowiadają za robocika po środku..

    • last_robbo.jpg
      
      
      
      
24. • 24: CommentAuthorRocky
    • CommentTime9 Jan 2024 10:01

     
    A co do śmieci na prawej ramce, to są tylko jak się używa szerokiego ekranu, co ma swoje konsekwencje w postaci ograniczenia liczby zmian w linii..
    W praktyce więcej zyskamy ograniczając się do 40 bajtów..
    
    Choć sama technika oraz możliwość użycia 240 linii jest ciekawa i fajnie by było móc z tego skorzystać np. z poziomu g2f.
25. • 25:
       
      CommentAuthorkoala
    • CommentTime9 Jan 2024 10:01

     
    To ja jeszcze może napiszę o mojej walce z tymi artefaktami. W AlleyDogu w wersji afterparty (na projektorze na Lostcie było to bardzo widać więc się za to zabrałem). Tam mamy na obrazkach często szeroki tryb w antic mode 4. Trik polega na tym aby ustawić wartość $0b w rejestrze hscrolla + modyfikacja dlisty o włączenie hscrolla + przesunięcie ekranu o +3bajty. Proste ale działa :)
    
    ps: Mono, Yosh, Kaz dzięki Wam za wyjaśnienia, ja nie wiedziałem sąd się te śmieci biorą i jak to można okiełznać w inny sposób niż albo ten hscroll (albo sprajty). Dobra robota chłopaki!
26. • 26: CommentAuthortebe
    • CommentTime9 Jan 2024 10:01

     
    H/VSCROLL jako rozwiązanie, skoro działa to po co to zmieniać :)
    
    Kaz czepia się VSCROLL-a w G2F, a właśnie w ten sposób został rozwiązany problem 240 linii, poprzez przesunięcie obrazu o linię w górę (w trybie HiRes)
    
    rozwiązanie HSCROLL (+3 bajty) będzie miało tą zaletę że nie trzeba marnować CPU na ustawianie odpowiedniej wartości w każdej kolejnej linii obrazu
    
    taniej jest użyć HSCROLL, albo czarny pocisk maskujący niż poświecić 100% czasu CPU aby wstawić zera
27. • 27: CommentAuthormono
    • CommentTime9 Jan 2024 11:01 zmieniony

     
    Tak. HSCROL to świetny pomysł i do wykorzystania np w grach - sztuczka z podkładaniem bajtu na magistralę to już raczej średnio. Dzięki @koala!
    
    Tym bardziej, że szeroki ekran i tak zabiera 48 bajtów na linię - tyle samo co włączony HSCROL.
    
    Edit: Sprawdziłem - $0B ustawia śmiecia na 4px (tak jak tryb bez HSCROL), a $0A tylko minimalizuje "śmiecia" do 2 px hires. @koala: Jak udało Ci się schować śmiecia w ten sposób?
28. • 28:
       
      CommentAuthorkoala
    • CommentTime9 Jan 2024 12:01

     
    @mono - tak dokładnie jest 48 na linię i się nie zwiększy
    
    aha: zapomniałem dodać że grafikę z tego co pamiętam to także wtedy można przesunąć chyba o 1/2 pixele bo się tracą, ale to już szczegół :P
29. • 29:
       
      CommentAuthorMq
    • CommentTime9 Jan 2024 12:01

     
    Fajne rzeczy opowiadacie:-) Dzięki wszystkim za wiedzę w tym temacie i pomysły omijania problemów.
30. • 30:
       
      CommentAuthorYosh
    • CommentTime9 Jan 2024 13:01

     
    @koala: to ja mam takie samo pytanie jak mono - jak to dokładnie działa ?
31. • 31:
       
      CommentAuthorkoala
    • CommentTime9 Jan 2024 13:01 zmieniony

     
    @mono - a sprawdzałeś to dla trybu 4 antica? Panowie nie wiem jak to dokładnie działa (może hscroll zabiera więcej czasu?) :) ale u nas zadziałało! (założyłem że jak to obsługuje Altirra i to samo na real Atari to tam magii nie ma)
    screeen z syfkami: ->link<-
    po "fixie": ->link<-
32. • 32:
       
      CommentAuthorYosh
    • CommentTime9 Jan 2024 13:01

     
    a co do @Rocky obrazków to prawda. Jest takie szumne demo na CGA w wielu kolorach po kompozycie. I tam dla laika to jest pierdoła, ale goście zrobili plansze opisującą dlaczego to jest zajebiste.
    
    U nas sa te notki autora i wymagania przed pokazaniem, warto tam by bylo czasem rzucic co nie co technikali (chyba ze cos duzego, to i plansze w gr.0 mozna by poczytac)
33. • 33: CommentAuthortebe
    • CommentTime9 Jan 2024 13:01

     
    może jakaś nazwa na taki tryb z ekranem szerokim (wide) bez śmieci
    
    X WIDE, EXTRA WIDE, SUPER WIDE, EXTREME WIDE
    
    coś jak z trybem Konopa (9+), Fox-a(9++)
    
    i umieścić informację o tym w Atariki, jak ktoś odkryje znowu "koło" od nowa, dowie się jak to "koło" nazwać
    
    ->link<-
34. • 34:
       
      CommentAuthorkoala
    • CommentTime9 Jan 2024 13:01 zmieniony

     
    @mono - wysłałem Ci maila
    
    jeszcze z rzeczy dziwnych i dziwniejszych: w CrazyCat (tej dziwnej platformówce) aby uzyskać fullscreen (tryb szeroki, 240 linii, scrolle poziome i pionowe, sprajty), to aby nie zrywało synchronizacji musiałem 2 razy podciągać (ostatnie 2 wiersze) vscrollem obraz do góry, a nie tylko ostatni wiersz. Sorry jak to offtop :)
35. • 35:
       
      CommentAuthorYosh
    • CommentTime9 Jan 2024 14:01 zmieniony

     
    Ja tylko dodam, ze WSYNC mi sie nie przydał - to strata czasu procesora. Wydaje się to działać na idealnie wymierzonym lda #kolor
    (na altirze dziala, u mnie dziala, na party 2018 dzialalo) - oczywiscie rozkaz nie ma znaczenia, ma znaczenie co jest na busie.
    
    wiec ktos moglby nawet 'zoptymalizowac kod' czyli np zrobic lda 0, 0 jako adres poszlo by jako 'czarny' na ekran, a wartosc z komorki 0 do akumaltora jako zwykly kod.
    
    Moj player robi *raz* synca ekranu i 6502 (no i carta) i potem player idzie cykl w cykl.
    
    W sumie to tak się o tym kapłem - poniewaz moj kod robi to samo w kazdej lini cykl w cykl to pattern po prawej byl bardzo powarzalny (co sklonilo mnie do wczytania sie w manual altirry ze to jakos tam jest przewidywalnie)
36. • 36: CommentAuthormono
    • CommentTime9 Jan 2024 15:01

     
    @Yosh: Tak.
    
    @koala: Eliminację śmieci sprawdzałem w hires/multicolor/gtia w trybach gfx/txt, ale już HSCROL tylko dla hiresu gfx/txt - wieczorem sprawdzę dla multicolor i gtia. Ciekawe co się pokaże :)
37. • 37:
       
      CommentAuthorKaz
    • CommentTime9 Jan 2024 16:01

     

    koala:

    To ja jeszcze może napiszę o mojej walce z tymi artefaktami.

    
    
    Super! O to chodzi proszę szanownych panów, niech wiedza i doświadczenie krąży, żeby poziom wszystkich prac się podnosił, "a ludziom żyło się dostatniej"! Dziękuję wszystkim wypowiadającym się w technicznych tematach graficznych, to miód na moje serce :)
    
    

    koala:

    ps: Mono, Yosh, Kaz dzięki Wam za wyjaśnienia, ja nie wiedziałem sąd się te śmieci biorą i jak to można okiełznać w inny sposób niż albo ten hscroll (albo sprajty).

    
    
    I wzajemnie! Fajnie, że się podzieliłeś swoimi sposobami, bo jak widać, do tematu można podejść na różne sposoby. Ja dotychczas wykorzystywałem tylko duszki, dobrze dowiedzieć się coś nowego.
    
    

    TeBe:

    Kaz czepia się VSCROLL-a w G2F, a właśnie w ten sposób został rozwiązany problem 240 linii, poprzez przesunięcie obrazu o linię w górę (w trybie HiRes)

    
    
    To wiemy, jak to działa, ale że nie dałeś nam wolności wyboru, to przez Ciebie płaczemy po nocach do poduszki :D
    
    

    TeBe:

    taniej jest użyć HSCROLL, albo czarny pocisk maskujący niż poświecić 100% czasu CPU aby wstawić zera

    
    
    Jeśli tylko przykryć śmieci to tak, ale żeby porysować to nie. Nie zawsze jest też możliwe, żeby skorzystać z duszka (patrz wyżej).
    
    

    Yosh:

    U nas sa te notki autora i wymagania przed pokazaniem, warto tam by bylo czasem rzucic co nie co technikali (chyba ze cos duzego, to i plansze w gr.0 mozna by poczytac)

    
    
    To prawda! Od lat próbuję do tego przekonać organizatorów party, żeby przed pracą można było dwa zdania wyjaśnienia technikaliów powiedzieć albo przeczytać plik txt z opisem specyfikacji, bo przecież niektóre dema czy grafiki są wybitne nie przez tematykę, ale technikalia, których nie widać i nie każdy rozumie. Dopiero raz się udało :)
    
    

    TeBe:

    jak z grafikami Rocky-ego które on rozumie co jest "pod spodem" ale inni widzą tylko kolor i układ pikseli, ale nie technikalia które za tym stoją, też mu mówię żeby przed zaprezentowaniem takiej grafiki wstawił ekran z opisem co i jak zostało osiągnięte

    
    
    Pełna zgoda, dlatego co zlot molestuję Rocky'ego, żeby pisał artki wyjaśniające, a najlepiej przychodził na zooma opowiedzieć co i jak. Ja obserwuję jego pracę oraz pomysły od lat i kibicuję!
    
    

    Rocky:

    A co do śmieci na prawej ramce, to są tylko jak się używa szerokiego ekranu, co ma swoje konsekwencje w postaci ograniczenia liczby zmian w linii.. W praktyce więcej zyskamy ograniczając się do 40 bajtów..

    
    
    A jeszcze więcej zyskamy w 32 bajtach, tylko to nie ma nic do rzeczy. Poza tym - ciekawostka - rysunki z błędami raportowanymi przez G2F - dalej mogą być poprawne! O ile pamiętam, TeBe postawił granicę z zapasem, więc mimo WARNINGS i ERRORS, grafika może być ok. Tak jest właśnie w obrazku Irwina, który przypomniałem w artku - tam jest 37 ostrzeżeń, 29 błędów :)

    • warnings_errors.jpg
      
      
      
      
38. • 38:
       
      CommentAuthorkoala
    • CommentTime10 Jan 2024 12:01

     
    Errata: jednak pamięć mi splatała figla, i w AlleyDog nie mamy trybu $4 antica a $e - czyli zwykły gr.15. Przepraszam za wprowadzenie w błąd
39. • 39:
       
      CommentAuthorgienekp
    • CommentTime10 Jan 2024 19:01

     
    Rozumiem, że 356 to jest pole graficzne. Czyli Gr.15 da mi 178 pikseli.
    Skoro da się przykrywać graczem śmietnik, to czy można gracza (dokładnie dwóch) dać troszkę dalej? I kolejnych dwóch z lewej strony.
    
    I uzyskać 4 kolorowy obraz 194x240 (matematyczny odpowiednik gr.8 to 388x240)?
    
    Bo jak tak, no to jednak 388 to nie blef.
40. • 40:
       
      CommentAuthormaly_swd
    • CommentTime10 Jan 2024 20:01

     
    Gienekp: Po prawej już nie ma chyba miejsca aby więcej duchów wciskać.
41. • 41:
       
      CommentAuthorjhusak
    • CommentTime10 Jan 2024 20:01 zmieniony

     
    @gienekp
    Za wikipedią:
    

    The Atari 2600 hardware was based on the MOS Technology 6507 chip, offering a maximum resolution of 160 x 192 pixels
    

    
    Więc tak można powiedzieć - 388 :)
    Albo lepiej:
    Niemal 400!
    
    Z resztą dla A2600 to 160 x 192 też jest z nie wiadomo skąd, bo sprajty mogą być i dłuższe, i szerzej, niż to 160.
42. • 42:
       
      CommentAuthorDracon
    • CommentTime11 Jan 2024 09:01

     
    Czy można liczyć na gietuefa z obsługą tak "powiększonej" powierzchni ekranu w hires??? Tudzież innego narządzia do tej nowości? ;o
43. • 43: CommentAuthortebe
    • CommentTime11 Jan 2024 10:01

     
    przełącz się na GED+, albo GED-, albo PGR i sobie wyedytuj, linia po lini, bajt po bajcie
44. • 44:
       
      CommentAuthorjhusak
    • CommentTime11 Jan 2024 12:01 zmieniony

     
    @Dracon, tebe Ci poleca znany portal dla koderów hxxps://zrob.se :)
45. • 45:
       
      CommentAuthorDracon
    • CommentTime12 Jan 2024 23:01

     
    Tebe nie zawiódł, na 99% spodziewałem się takiej a innej jego odpowiedzi... :> :D :P
46. • 46:
       
      CommentAuthorKaz
    • CommentTime13 Jan 2024 16:01

     
    Dracon - ależ G2F obsługuje całą powierzchnię, o której mowa w naszym demku! Możesz spokojnie stawiać tam piksele, rysować - gdyby to nie było możliwe to nie zrobilibyśmy demka. Jedyne czego nie robi G2F to nie zapisuje poprawnie takiego obrazka, bo wymagałoby to wygenerowania programu dla kążdej linii. Czy możliwe jest, żeby G2F to robił samodzielnie, a nie trzeba było robić ręcznie? Nie wiem, bo może to nie jest trywialne do zrobienia i rozumiem, że dla kilku takich obrazków TeBemu się nie będzie chciało :)
47. • 47: CommentAuthortebe
    • CommentTime13 Jan 2024 17:01

     
    Dracon swój ostatni obrazek w G2F popełnił ~2015 roku, zdecydowanie nie jest grupą docelową
48. • 48:
       
      CommentAuthorDracon
    • CommentTime13 Jan 2024 20:01 zmieniony

     
    Tebe, masz nieświeże informacje albo za rzadko zaglądasz do Atariki i tutaj:
    
    
    :D
    No ale skoro "nie jestem targetem" to może faktycznie nie warto dalej bawić się G2F, nawet po jakiejś tam przerwie. :)))
49. • 49:
       
      CommentAuthorgienekp
    • CommentTime13 Jan 2024 20:01 zmieniony

     
    Jak w zasadzie zbudować listę dla ANTICa dla trybu 0E (Gr.15)?
    
    Dane w pamięci są zorganizowane jakby było 384/2 pikseli czyli 48 bajtów. 48*240 to 11520bajtów. No to limit 12-bitowy ANTICa dwa razy łamiemy. To da się to tak wcelować, żeby obraz w pamięci był bez cieć?
    
    Robię tak, ale mam jedną linię ściętą
    

    DIV1    = 85
    DIV2    = 85
    antic   dta $4E,<pic,>pic
            :+(DIV1-1) dta $0e
            dta $4E,<(pic+DIV1*48),>(pic+DIV1*48)
            :+(DIV2-1) dta $0e
            dta $4E,<(pic+(DIV1+DIV2)*48),>(pic+(DIV1+DIV2)*48)
            :+(240-DIV1-DIV2) dta $0e			
            dta $41,<antic,>antic
    
50. • 50:
       
      CommentAuthorjhusak
    • CommentTime13 Jan 2024 21:01 zmieniony

     
    Jak chcesz to zrobić? 4096/48=83 i 1/3 czyli 16 reszty.
    
    Musisz przeładować i ominąć dziurę 16 bajtów przynajmniej raz, za drugim skokiem; bo pierwszy skok możesz ustawić dokładnie na granicy 4kB, zaczynając pamięć obrazu od 16 bajtu w ramach bloku 4kB.