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: CommentAuthormono
   • CommentTime12 Jan 2011 zmieniony

    
   Bo z podłączonym joyem NIGDY takich wartości nie będziesz miał.
   Bity kierunków są ZEROWANE kiedy joystick jest w danym położeniu.
   Tak więc odpowiednie wartości to:
   nic = 15
   góra = 15-1
   dół = 15-2
   lewo = 15-4
   prawo = 15-8
   Przedtem jednak warto byłoby zapewnić to, żeby joysticki były do odczytu, a więc ustalić ich kierunek w PACTL($D302) odpowiednio do tego co w ->link<- :
   BYTE PACTL = $D302
   
   PACTL = $38 ;ustawia PORTA jako rejestr kierunku
   PORTA = 0 ;wszystkie linie na wejście
   PACTL = $3c ;ustawia PORTA jako rejestr danych
   
   Dolne bity PORTA to joy0, górne to joy1 więc trzeba by odczyt zamaskować:
   
   BYTE JOY0, JOY1
   JOY0 = PORTA & $0F
   JOY1 = (PORTA LSR 4) & $0F
   
   i dopiero porównywać z wartościami podanymi wyżej.
   
   Jeśli nie potrzebujesz czytać stanu joysticków częściej, niż 50x na sekundę to polecam skorzystanie z rejestrów-cienii:
   
   BYTE JSTICK0 = $278
   BYTE JSTICK1 = $279
   
   tam znajdują się wartości już zamaskowane (tylko 4 młodsze bity - OS zajmuje się odczytem danych z PORTA, maskowaniem i zapisem do cienii na przerwaniu VBLKD) i problem z kierunkami itd z głowy.
2. • 2:
      
     CommentAuthorinsert
   • CommentTime12 Jan 2011

    
   dzieki :) wlasnie skorzystalem z cieni i dziala :)
3. • 3:
      
     CommentAuthorinsert
   • CommentTime18 Jan 2011

    
   ok, mam problem banalny, chce napisac program, ktory steruje literka "A" po ekranie w trybie tekstowym gr.0,
   
   problem polega na tym ze podczas rysowania i kasowania znaku co jakis czas znak pojawia mi sie tez w "dziwnych" wspolrzednych (x=0, y dobre)
   
   pomocy, co robie nie tak? i dlaczego tak mruga? (robie synchro do vbi)
   
   moj program:
   
   ;----------------------------------
   PROC WVBI()
   BYTE rtclk=$14,u
   u=rtclk
   DO
   UNTIL rtclk#u
   OD
   RETURN
   ;----------------------------------
   PROC DRAWCHAR(BYTE X,Y,ZNAK)
   CARD EKR=88
   WVBI()
   POKE(EKR+X+20*Y,ZNAK)
   RETURN
   ;----------------------------------
   PROC CLRCHAR(BYTE X,Y)
   CARD EKR=88
   WVBI()
   POKE(EKR+X+20*Y,0)
   RETURN
   ;----------------------------------
   
   PROC MAIN()
   
   BYTE KEY=764
   BYTE XGR,YGR,XMAX,XMIN,YMAX,YMIN
   
   KEY=255
   
   XMIN=0
   YMIN=0
   XMAX=35
   YMAX=34
   
   XGR=21
   YGR=0
   
   GRAPHICS(0)
   DRAWCHAR(21,YGR,33)
   
   ;-----------------
   
   WHILE KEY=255 DO
   
   IF VStick(0)=0 THEN
   ;NIC NIE ROB
   FI
   
   IF VStick(0)=1 THEN
   IF YGR<YMAX THEN
   CLRCHAR(XGR,YGR)
   YGR=YGR+1
   DRAWCHAR(21,YGR,33)
   FI
   IF YGR>=YMAX THEN
   FI
   FI
   
   IF VStick(0)=-1 THEN
   IF YGR>YMIN THEN
   CLRCHAR(XGR,YGR)
   YGR=YGR-1
   DRAWCHAR(21,YGR,33)
   FI
   IF YGR<=YMIN THEN
   FI
   FI
   
   OD
   
   KEY=255
   GRAPHICS(0)
   
   RETURN
4. • 4: CommentAuthorrudla
   • CommentTime19 Jan 2011

    
   If I remeber correctly, one line of GR0 has 40 bytes, so you should multiply by 40, not by 20 in DRAWCHAR, CLRCHAR.
5. • 5:
      
     CommentAuthortdc
   • CommentTime19 Jan 2011 zmieniony

    
   Nie wczytywałem się specjalnie w ten kod, ale jest tu błąd tej materii, że procedurę WVBI() wywołujesz zarówno w DRAWCHAR() oraz CLRCHAR() co oznacza, że możesz tylko jedną z tych operacji wykonać w ciągu trwania jednej ramki (zwykle zależy nam na większej ilości;). Skoro kasujesz w jednej ramce a w drugiej rysujesz to masz miganie.
   
   Poza tym nie podobają mi się takie procedury:
   

   PROC DRAWCHAR(BYTE X,Y,ZNAK) 
   CARD EKR=88 
   WVBI() 
   POKE(EKR+X+20*Y,ZNAK) 
   RETURN
   

   
   To jest poprawne jeśli chodzi o proceduralne programowanie, jednak do poprawnego proceduralnego programowania służy np. Pascal. Action! to język który powstał do programowania grafiki, gier itp. więc nie starajmy się tutaj programować zgodnie z konwencjami i innymi zbędnymi rzeczami. Starajmy się programować jak w asm, czyli tak aby procesor robił max mało niepotrzebnych rzeczy a sprawnie robił to co istotne, czyli tu rysowanie znaku.
   
   Co ta procedura robi:
   1. pobiera parametry
   2. deklaruje zmienną Card (po co za każdym wywołaniem procedury ?)
   3. skok do WVBI() - tak zbędny że błędny ( :D )
   4. wyznacza adres (powolne)
   5. skok do procedury POKE (powolny jeśli chodzi o demka lub szybkie gry)
   6. powrót
   
   Odnośnie punktu 2, to trzeba sobie zadeklarować zmienną globalną. Zmienne globalne są nielubiane przez różnych wykładowców (teoretyków) uczących np. Pascala itp. jednak w programowaniu gier itp. zmienne globalne to podstawowe, szybkie narzędzie. O tym że tego typu rzeczy uczą w szkołach, jest fajny tekst w demku Joyride;)
   
   Dlatego nie tworzenie zbyt poprawnych strukturalnych programów w Action! to dobra ogólna zasada, w końcu to ma działać (jak pascal nigdy nie działał), a nie wyglądać.
   
   Czyli jeśli chodzi o tę procedurę to należy ją skonstruować tak, aby nie wykonywała przy rysowaniu aż 6 operacji.
6. • 6:
      
     CommentAuthorjhusak
   • CommentTime19 Jan 2011 zmieniony

    
   Z mojej strony 3 grosze:
   
   IF VStick(0)=0 THEN
   ;NIC NIE ROB
   FI
   ---
   IF YGR>=YMAX THEN
   FI
   ---
   IF YGR<=YMIN THEN
   FI
   
   Ja uważam to za stratę czasu, spowolnienie programu i stratę pamięci na program pisząc kod, który mówi, czego komputer ma NIE ROBIĆ i kiedy.
   
   Program to zestaw instrukcji mówiący, co komputer MA ROBIĆ.
   
   Czyli:
   
   WHILE KEY=255 DO
   
   s=stick(0)
   
   if s<>0 THEN
   
   CLRCHAR(XGR,YGR)
   
   IF s=1 AND YGR<YMAX THEN
   YGR==+1
   FI
   
   IF s=-1 AND YGR>YMIN THEN
   YGR==-1
   FI
   
   DRAWCHAR(21,YGR,33)
   FI
   
   OD
   
   Kod nie jest funkcjonalnie identyczny, bo zawsze próbuje zmazywać i rysować jeśli jest przechylony joystick, ale ma mniej powtórzeń (ilość kodu) i jest przejrzystszy. Oczywistym jest fakt, że czytając joystick wiele razy możemy otrzymać wiele RÓŻNYCH odpowiedzi (co może prowadzić do trudnych w wykryciu błędów) pomijając fakt, że odczyt joysticka to funkcja biblioteczna, zajmuje czas i wymaga cartridge.
   
   Ogólna uwaga. Najpierw badamy (i tylko badamy) sytuację, a potem wykonujemy (i tylko wykonujemy) odpowiednie kroki. Są wyjątki, ale od takiego stanu należy wychodzić. Upraszcza to testowanie i ułatwia rozumienie kodu (po kilku tygodniach np.).
   
   Jeszcze raz. Nigdy nie pisz kodu, który nic nie robi. Zostaw to innym :)
   
   No i jeszcze jedno: clrchar(x,y) === drawchar(x,y,0)
   W kodzie masz 2 oddzielne procedury do tego? Redundancja.
7. • 7:
      
     CommentAuthorinsert
   • CommentTime19 Jan 2011

    
   ojej, dzieki wszystkim :)
8. • 8:
      
     CommentAuthorjhusak
   • CommentTime19 Jan 2011

    
   Mantra:
   Zawsze chętnie pomagamy.
   Zawsze chętnie pomagamy.
   Zawsze chętnie pomagamy.
   Zawsze chętnie pomagamy.
   Zawsze chętnie pomagamy.
   Zawsze chętnie pomagamy.
   Zawsze chętnie pomagamy.
   ...
9. • 9:
      
     CommentAuthorjhusak
   • CommentTime19 Jan 2011

    
   I jeszcze jedno. @tdc, pozwolisz, że się z Tobą niezupełnie zgodzę.
   
   Tworzenie zmiennych globalnych jest uzasadnione, jeśli te zmienne są LOGICZNIE globalne. W przypadku screen=88 właśnie tak jest (i w przypadku wszystkich pozostałych rejestrów oraz ich cieni)
   
   W przypadku zmiennych używanych tylko w programie (i nie wychodzących poza niego) jest inaczej, tzn nie chciał byś, aby system operacyjny grzebał w Twojej zmiennej, bo jest ona super globalna (w całym systemie ją widać) Podobnie jest z procedurami - jeśli coś w niej jest logicznie lokalne, to tak ma być i już. Nie ma sensu (z punktu widzenia kodowania, testowania i debugowania błędów tak powstałych):
   - reużycie zmiennych (z wyjątkiem stosowania w tym samym poziomie zagłębienia kodu)
   - nadużywanie zmiennych globalnych
   - nadużywanie zmiennych w ogóle.
   
   Oczywiście często stajemy przed problemem braku miejsca w słowniku (napisałem killka dużych gier w Action i nigdy mi się to nie zdarzyło) - wtedy stosujemy optymalizację, o jakiej piszesz. NIE WCZEŚNIEJ!
   
   A i tak należy wówczas się zastanowić, czy nie rozbić programu na części - oddzielnie czołówka, oddzielnie kod gry, oddzielnie intro/outro. Te rzeczy nie powinny być na raz w pamięci, bo miejsce w pamięci jest cenne (chyba, że nie jest ;)
   
   Wtedy okazuje się, że Action! działa bez zastrzeżeń i nie ma błędów... To znaczy ja nie natrafiłem na błędy :)
10. • 10:
       
      CommentAuthorjhusak
    • CommentTime19 Jan 2011 zmieniony

     
    @insert. Najważniejsza zasada programowania: DRY.
    
    Don't Repeat Yourself.
    
    To ustawia myślenie i eliminuje złe rozwiązania.
    
    Jeśli po tym wszystkim się powtarzasz, robisz to z pełną świadomością i to znaczy, że tak jest jednak lepiej/szybciej/taniej w DANYM przypadku.
11. • 11:
       
      CommentAuthorinsert
    • CommentTime19 Jan 2011

     
    ale mam pytanie, przeciez w Action nie ma zmiennych globalnych i konstrukcji IF costam AND costam THEN... jest tylko IF costam THEN ... , jesli sie myle to prosze o przyklad uzycia zmiennej globalnej etc
12. • 12: CommentAuthorw1k
    • CommentTime19 Jan 2011 zmieniony

     
    Here is a some little programs which i retype from czech atari magazines. but DEMO.ACT doesnt work, i dont know why.. game pacman.act is nice :)

    • act.zip
13. • 13:
       
      CommentAuthorjhusak
    • CommentTime20 Jan 2011

     
    ->link<-
    
    tutaj masz i zmienne globalne, i AND w IFie.
    
    Nie jest to dobry kod, pisany na początku mojej edukacji, ale jako przykład się nada (np. nadużywanie POKE - zapomnij, to funkcja biblioteczna, twój przykład ze screen=88 jest wzorcowy)
    
    Polecam też analizę BNF - opis języka, po lewej symbol, po prawej na co się przekłada. Czyli EXPR to nie tylko a<b ale też EXPR AND EXPR.
14. • 14:
       
      CommentAuthorinsert
    • CommentTime20 Jan 2011

     
    dzieki :)
15. • 15: CommentAuthorw1k
    • CommentTime20 Jan 2011

     
    that BMUSIC.ACT is unable to compile on real atari :)
    error 13 or error 14
16. • 16:
       
      CommentAuthortdc
    • CommentTime20 Jan 2011 zmieniony

     

    jhusak:

    No i jeszcze jedno: clrchar(x,y) === drawchar(x,y,0)
    W kodzie masz 2 oddzielne procedury do tego? Redundancja.

    
    Nie strofujmy go aż tak bardzo, insert się dopiero uczy. Nie wiadomo jaki ma zamysł, niech sobie tworzy liczne procedurki ;) W każdym razie kod jest tak mały i edukacyjny, że to na razie nie ma znaczenia, niech sobie na razie pisze jak mu się podoba. A jak zacznie tworzyć coś większego np. jakąś grę to wtedy też się nas zapyta o rady;)
    
    

    jhusak:

    I jeszcze jedno. @tdc, pozwolisz, że się z Tobą niezupełnie zgodzę.

    
    Eeee tam. Gdzie się ze mną nie zgadzasz ? ;) Przecież napisałeś dokładnie to co chciałem tu przekazać, tyle że nie miałem czasu aby to wyłożyć ze szczegółami ;)
    
    

    jhusak:

    Oczywiście często stajemy przed problemem braku miejsca w słowniku (napisałem killka dużych gier w Action i nigdy mi się to nie zdarzyło) - wtedy stosujemy optymalizację, o jakiej piszesz. NIE WCZEŚNIEJ!
    

    
    No ja niestety obecnie przełączyłem się na reusing zmiennych. Po raz pierwszy (w pewnym zakresie) miało to miejsce w Tomcat. To jest nieco hardcorowe, ale ostatnio zbyt często Action! mi zgłaszał koniec tablicy symboli. W Tomcat też zastosowałem tablicę, zamiast kilkunastu zmiennych, które przechowują statusy np. muzyki itp., a to dlatego, że kod już jest duży (ilość zmiennych spora), a mam jeszcze wiele do zrobienia, więc już zacząłem się o to martwić.
    
    Tzn. (ogólnie, a nie tylko w Tomcat) moje podejście jest następujące, oszczędność tablicy symboli już na początku tworzenia dużego projektu to wyeliminowanie późniejszej refaktoryzacji, a im kod jest większy tym jest to bardziej pracochłonne i obarczone ew. błędami trudnymi do wykrycia.
    
    Bo niestety trzeba podkreślić, że w praktyce reusing zmiennych globalnych jest bardzo niebezpieczny, bo zmiana wartości zmiennej w innej części kodu (np. zaincludowanej z pliku), powoduje, że w innymi miejscu/ach kod nie działa i potem szukaj wiatru w polu...
    
    
    Moja rada jest dla wszystkich którzy mają ten problem, aby zrobić sobie zestaw np. 5 – 6 (więcej jeśli trzeba) zmiennych pomocniczych (sterujących pętlami itp.), które są zmiennymi globalnymi, następnie używać ich tylko w pojedynczych partiach pętli (ale w całym kodzie – czyli reusing).
    
    Mamy tutaj reausing, który jest dość bezpieczny, bo zawsze wiemy, że te zmienne nigdy nie mają wartości, która może na nie wpłynąć w innej części kodu bo dotyczą tylko danej/ych pętli.
    
    Dzięki temu nie prowadzi to do trudnych do odnalezienia błędów w kodzie (coś gdzieś zmienia wartość zmiennej i potem reusing powoduje że kod przestaje działać itp.).
    
    
    

    jhusak:

    Wtedy okazuje się, że Action! działa bez zastrzeżeń i nie ma błędów... To znaczy ja nie natrafiłem na błędy :)

    
    No ja dopiero staram się zgłębić temat błędów, już tylko jednej rzeczy nie wiem, reszta jest jasna. Właśnie mi przypomniałeś, że ja kiedyś napisałem artykuł o błędzie w Action! muszę go dokończyć (przygotować przykładowy kod) i opublikować ;)
17. • 17:
       
      CommentAuthortdc
    • CommentTime20 Jan 2011 zmieniony

     

    jhusak:

    Zawsze chętnie pomagamy.

    
    
    Niech Kaz zrobi taki baner odnośnie tego forum ;):):)
    
    
    

    w1k:

    that BMUSIC.ACT is unable to compile on real atari :)
    error 13 or error 14

    
    Have You cartridge ?
    Error 14 or 13 = out of memory.
18. • 18:
       
      CommentAuthorinsert
    • CommentTime20 Jan 2011

     
    u mnie pod emulatorem bmusic.act wcale sie nie laduje do edytora, nie wywala tez bledow :/
19. • 19:
       
      CommentAuthorjhusak
    • CommentTime20 Jan 2011 zmieniony

     
    @w1k It was written on REAL Atari, there were no emulators at all those times :))))))))))
    
    You will need the Action! cart, or Action! cart memdump on emulator.
    
    Orelse in case you have an Action! file version (there are two of them:) you can try to compile it from disk, it should work, do not load it into editor.
    
    The mentioned second file version of Action! does almost the magic the cartridge does. It leaves full 40 KB of mem for user by using mem under the SO. And even Bank Switching is done in hardware, so you can compile the source with the same speed as the cartridge does (this was the tricky part I suppose, to change all the jmp/jsr addresses by the same offset :)
    
    I do not remember the links unfortunately, I hope you can find it by your own:)
20. • 20:
       
      CommentAuthorjhusak
    • CommentTime20 Jan 2011

     
    Atarionline.pl. Here is The Help.
21. • 21: CommentAuthorw1k
    • CommentTime20 Jan 2011

     
    cartirdge action?:) maybe 1-5 cartridges of this language exists..
22. • 22: CommentAuthorw1k
    • CommentTime21 Jan 2011

     
    i have two questions :)
    
    how i can do this program faster?
    

    BYTE C,X,P
    PROC DEMO()
    GRAPHICS(11)
    P=0 C=0
    POKE (712,4)
    FOR X=0 TO 79
    DO
     COLOR=C PLOT(X,0) DRAWTO(X,191)
    P==+1
    IF P=5 THEN P=0
    FI
    C==+1
    OD
    RETURN
    

    
    
    and why this program doesnt work corretly? when i type 190, nothing do..
    

    BYTE A,B,C,I
    PROC DEMO()
    PRINT ("MAX 191.")
    INPUTS(A)
    GRAPHICS(8+16) SETCOLOR(2,0,0)
    B=(319-A)/2
    C=(191-A)/2
    COLOR=1
    FOR I=0 TO A STEP 5
    DO
    PLOT(I+B,C) DRAWTO(A+B,I+C)
    DRAWTO(A-I+B,A+C)
    DRAWTO(B,A-I+C) DRAWTO(I+B,C)
    OD
    RETURN
    
23. • 23: CommentAuthorilr
    • CommentTime21 Jan 2011

     
    In second example you should to use A=InputB() instead InputS(A)
24. • 24: CommentAuthorw1k
    • CommentTime21 Jan 2011 zmieniony

     
    @ilr thank you, its ok now.. but speed is 'too slow' like tbasic - i retype this programs from tbasic.
25. • 25: CommentAuthorilr
    • CommentTime21 Jan 2011 zmieniony

     
    Probably you must write own faster plot() and drawto() procedures.
26. • 26:
       
      CommentAuthortdc
    • CommentTime21 Jan 2011 zmieniony

     
    w1k: In the first example, you can draw only the first line, then copy it using Moveblock() to the all next.
    
    Another interesting solution is to copy the line with ANTIC.
27. • 27: CommentAuthorw1k
    • CommentTime21 Jan 2011

     
    @tdc can you try it for example?
28. • 28:
       
      CommentAuthorjhusak
    • CommentTime21 Jan 2011

     
    Drawto jest bardzo wolne. Można alg. Bresenhama rysować dużo szybciej, oraz trzeba napisać własny plot pod dany tryb graficzny (kilkanaście razy szybszy to taki prosto z palca ze stablicowanymi mnożeniami przez 40)/ Chociaż nie wiem, czy Drawto nie stosuje alg. Bresenhama.
29. • 29:
       
      CommentAuthorjhusak
    • CommentTime22 Jan 2011 zmieniony

     
    BYTE C,X,P
    PROC DEMO()
    GRAPHICS(11)
    P=0 C=0
    POKE (712,4)
    FOR X=0 TO 79
    DO
    COLOR=C PLOT(X,0) DRAWTO(X,191)
    P==+1
    IF P=5 THEN P=0
    FI
    C==+1
    OD
    RETURN
    

    
    
    shorter version:
    
    

    BYTE X
    PROC DEMO()
    GRAPHICS(11)
    POKE (712,4)
    FOR X=0 TO 79
    DO
    COLOR=X PLOT(X,0) DRAWTO(X,191)
    OD
    RETURN
    

    
    
    faster version (much) and should not use the cartridge library (hm. graphics(11) does.)
    
    

    BYTE X,Y,COL
    CARD SCREEN=88
    BYTE ARRAY COLS=[$01 $23 $45 $67 $89 $AB $CD $EF]
    BYTE ARRAY MEM=0
    CARD SCRIDX
    PROC DEMO()
    GRAPHICS(11)
    MEM(712)=4
    FOR X=0 TO 39
    DO
    COL=COLS(X AND 7)
    SCRIDX=SCREEN+X
    FOR Y=0 TO 191
    DO
    MEM(SCRIDX)=COL
    SCRIDX==+40
    OD
    OD
    RETURN
    
30. • 30: CommentAuthorgorgh
    • CommentTime22 Jan 2011

     
    lol, ale składnia
31. • 31:
       
      CommentAuthorjhusak
    • CommentTime22 Jan 2011

     
    nie tyle składnia, co triki stosowane powszechnie przy przyspieszaniu kodu.
    
    MEM=0 - zastępuje poki i peeki, nie używa library, jest dużo szybsze.
    
    Mamy tablicę bajtów, w kolejności rosnących kolorów, którą przepisujemy po prostu w pamięć ekranu.
    
    Wykorzystujemy specyfikę zadania.
    
    No i jeszcze wyciąganie przed najgłębszą pętlę obliczeń, które tam nie muszą być.
32. • 32: CommentAuthorgorgh
    • CommentTime22 Jan 2011 zmieniony

     
    mhm,
    proszę was zaangażujcie się lepiej w asm (edit) sorki,... w Ass :)
33. • 33:
       
      CommentAuthorjhusak
    • CommentTime22 Jan 2011

     
    Tam już byliśmy :) Wyszliśmy z tego.
34. • 34: CommentAuthorgorgh
    • CommentTime22 Jan 2011

     
    no może za ostro się wyraziłem
35. • 35:
       
      CommentAuthorjhusak
    • CommentTime23 Jan 2011

     
    Ja wiem... Może nie za ostro, po prostu twoja myśl była zbyt głęboka...
36. • 36:
       
      CommentAuthorjhusak
    • CommentTime23 Jan 2011

     
    A tak na poważnie, nie napisałbym tego kodu w asm w 3 minuty. Pomijam fakt. że tytuł topica to :Action! uczę się:.
37. • 37: CommentAuthorgorgh
    • CommentTime23 Jan 2011

     
    no fakt, ostatnio się wszystkiego czepiam, bez sensu troche
38. • 38:
       
      CommentAuthortdc
    • CommentTime23 Jan 2011

     

    jhusak:

    MEM=0 - zastępuje poki i peeki, nie używa library, jest dużo szybsze.

    
    he he, tak dobra rzecz, a do tego przypominają mi się stare czasy. Nie wiem czy pamiętasz ale jak kiedyś w czasach Mirage byłeś u mnie to właśnie pokazywałem Tobie testy wydajności, że to właśnie jest fajne i szybkie;)
39. • 39:
       
      CommentAuthortdc
    • CommentTime23 Jan 2011 zmieniony

     

    w1k:

    tdc can you try it for example?

    
    
    In first case, change line
    

    COLOR=C PLOT(X,0) DRAWTO(X,191)

    
    to
    

    COLOR=C PLOT(X,0)

    
    
    and add at the end:
    

    scri=screen+40
    for x=0 to 190 do
    moveblock(scri,screen,40)
    scri==+40
    od

    
    
    and add variables:
    

    card screen=88, scri

    
    This is quite fast
    
    The next and better solution is to combine solutions jhusak. Draw the first line of his way, then copy using moveblock ().
    
    
    in the second case, I suggest you try yourself
40. • 40:
       
      CommentAuthorjhusak
    • CommentTime24 Jan 2011 zmieniony

     
    @tdc, instead:
    

    scri=screen+40
    for x=0 to 190 do
    moveblock(scri,screen,40)
    scri==+40
    od
    

    
    
    try this:
    
    

    MOVEBLOCK(SCREEN+40,SCREEN,7640)
    

    
    
    The First Rule Of Programmer: DRY (Don't repeat Yourself) :)
    
    BTW, this is ugly hack, but it works always the same :) And few bytes are saved :) And this is so fast... The fastest solution.
    
    Anyway - this uses library.
41. • 41:
       
      CommentAuthorjhusak
    • CommentTime24 Jan 2011

     
    Summary, the simplest solution is, as @tdc wrote:
    
    

    BYTE X
    CARD SCREEN=88
    PROC DEMO()
    GRAPHICS(11)
    POKE (712,4)
    FOR X=0 TO 79
    DO
    COLOR=X PLOT(X,0)
    OD
    MOVEBLOCK(SCREEN+40,SCREEN,7640)
    RETURN
    
42. • 42:
       
      CommentAuthortdc
    • CommentTime24 Jan 2011 zmieniony

     
    good, very good;)
    
    But it is a trick. In my opinion, first he should try to think about how work this loop, because he learning. let's we give him some space for his creativity. It's not a race to optimize the code, although this is most interesting;)
    
    And the first line should in your way, without plot().
43. • 43: CommentAuthorw1k
    • CommentTime24 Jan 2011

     
    nice, that was fast:)
44. • 44:
       
      CommentAuthorinsert
    • CommentTime4 Feb 2011

     
    no to kolejne boje, Tdc zainspirowal mnie do dzialania ;)
    
    probuje wczytac obrazek w formacie MIC i wyswietlic go poprawnie na ekranie, zgodnie z opisem z atariki ze ostatnie 4 bajty odpowiadaja wartosciom w cieniach rejestrow kolorow napisalem to co ponizej i niestety nie odczytuje mi barw z pliku :( co robie zle?
    
    PROC MAIN()
    
    CARD EKRAN=88
    
    CARD COL0=712
    CARD COL1=708
    CARD COL2=709
    CARD COL3=710
    
    GRAPHICS(15+16)
    WG("D1:TEST.MIC",EKRAN,7684,4,128)
    
    
    COL0=PEEKC(EKRAN+7681)
    COL1=PEEKC(EKRAN+7682)
    COL2=PEEKC(EKRAN+7683)
    COL3=PEEKC(EKRAN+7684)
    
    
    KEYPRESS()
    GRAPHICS(0)
    
    RETURN
45. • 45: CommentAuthorilr
    • CommentTime5 Feb 2011

     
    Wartości rejestrów kolorów są typu BYTE
46. • 46:
       
      CommentAuthorinsert
    • CommentTime5 Feb 2011

     
    zmiana na byte i peek zamiast peekc nie daje dalej rezultatow poprawnych, co jeszcze moze byc zle?
47. • 47:
       
      CommentAuthortdc
    • CommentTime5 Feb 2011 zmieniony

     

    insert:

    no to kolejne boje, Tdc zainspirowal mnie do dzialania ;)

    
    Ciekawe czym ? bo chyba nie wczorajszą awanturą na sztabie :D :D
    
    
    Problem z obrazkiem rozwiązany na privie.
48. • 48:
       
      CommentAuthorinsert
    • CommentTime5 Feb 2011 zmieniony

     
    zeby bylo edukacyjnie to powiem co TDC wylapal za blad, wystarczylo zmniejszyc adres skad pobierane sa dane kolorow o jeden bajt, czyli:
    
    COL0=PEEKC(EKRAN+7681-1)
    COL1=........ etc
    
    ps. blad polegal na tym ze dane obrazka zawieraja sie w 7679 bajtach, wiec od 7680 bajtu mamy pierwsza dana koloru
49. • 49:
       
      CommentAuthorlarek
    • CommentTime5 Feb 2011 zmieniony

     
    Nie wiem o co chodzi ;), ale dane obrazka zawierają się w 7680 bajtach (40 bajtów x 192 linie), więc od 7681 bajtu mamy dane koloru. Całość rozbija się o adresowanie, bo 7680-ty (ostatni) bajt grafiki leży w komórce EKRAN+7679, a nie EKRAN+7680, gdyż pierwszy bajt grafiki leży w komórce EKRAN+0, a nie EKRAN+1
    
    PS. Dla mnie ta grafika? :)
50. • 50:
       
      CommentAuthorinsert
    • CommentTime5 Feb 2011

     
    racja Larku, faktycznie :) a grafika... bu... no nie ma jeszcze, Larku pamietam i wierz mi ze wysle jak tylko bede zadowolony z tego co zrobilem :(