1

Robie prostą gierke dla dziieciaków, niestety spora przerwa w programowaniu i brak wiekszych działań przy grafice dają się u mnie we znaki, postaram sie to w miare zrozumiale opisac, w grze na ekranie ma pojawic sie pewna ilosc takich samych obrazkow, zadaniem dla dzieciaka jest zwyczajnie policzyc i klepnac na klawiaturze, grafike sobie przygotowalem na koniec listingu, zwyczajnie jest wtkonana PRINTem a potem literami odpowoadajacymi danym kolorom, co do losowania jaka grafika ma byc nie widze problemu, natomiast nie wiem jak ugryzc temat zeby program wedrowal do odpowiedniej lini, pobieral z tamtad grafike, rysowal wylosowana ilosc razy to samo na ekranie w roznych moejscach, nie chce zeby ktos to za mnie zrobil, raczej chcialbym zeby mnie ktos naprowadzil na jakis dobry trop, ksiazka miguta raczej mi nie pomaga aczkolwiek bede probowal jeszcze, za wszelkie podpowiedzi, naprowadzenie, tytuly opisujace cos takie bede bardzo dzwieczny :)

2

Nie wiem czy dobrze zrozumiałem, ale jeśli miejsca z grafiką zorganizujesz sobie np. w liniach 10 (pierwsza grafika, po zakończeniu rysowania dajesz GOTO POWRÓT (lub RETURN jeśli użyjesz GOSUB), 20 (druga), itp., to taką konstrukcją możesz sobie losować obrazki:

A = INT(RND(0)*LICZBAGRAFIK)+1: A=A*10: GOTO / GOSUB A
Czy możecie wyjaśnić, Stirlitz, dlaczego wasz służbowy adres stirlitz@rsha.gov.de ma aliasa justas@gru.su?
Nie czytam PM. Proszę używać e-mail.

3

ja tam się za bardzo nie znam, ale musisz sobie ustalić w jakim trybie graficznym będzie pracował program, a następnie znaleźć gdzie znajduje się pamięć ekranu, jak to znajdziesz będziesz mógł pisać do tej pamięci POKE-ami, a sam wzorek grafiki do skopiowania najlepiej (o ile to BASIC) zapamiętać w linijkach DATA, odczyt z tych linijek o ile dobrze pamiętam to READ $A...

4

100 RESTORE LOS*1000              'zmienna LOS zawiera wylosowany numer grafiki (min.1)
110   .............               'tu jakaś procka do odczytu danych grafiki
120   .............                ' i wyświetlania jej na ekranie
130 GOTO 10         

1000 REM DANE GRAFIKI NR 1
1010 DATA x,x,x,x,x,x,x,x,x,x,x,x,x,x,x,x
1020 DATA x,x,x,x,x,x,x,x,x,x,x,x,x,x,x,x

2000 REM DANE GRAFIKI NR 2
2010 DATA x,x,x,x,x,x,x,x,x,x,x,x,x,x,x,x
2020 DATA x,x,x,x,x,x,x,x,x,x,x,x,x,x,x,x

3000 REM DANE GRAFIKI NR 3
3010....

5

tylko z DATA to będzie mały problem, ja już nie pamiętam, ale chyba nie ma możliwości odczytu danych z dowolnej linii, trzeba resetować licznik i odczytywać wszystko od początku po kolei...

6

Bezrobotny, masz rację. Nie znasz się. Larek dał RESTORE w przykładzie - proponuję sobie o tym poczytać, o ile potrafisz czytać. Migut wystarczy.

Sikor umarł...

7

Larek - a nie lepiej oprzeć to o:

ON los GOSUB linia1, linia2....

Przywiązanie numeru linii do zmiennej to zły zwyczaj (aczkolwiek oszczędza ram) ;) Wychodzi to szczególnie przy kompilacji :D

Inna rzecz, że proponuję przenieść się z tym programem pod Turbo Basic XL. Szybszy i o niebo wygodniejszy. No i skompilować to później można

Kontakt: pin@usdk.pl

8

@pin, zwykły Basic też można skomp(l)i(l/k)ować: Turbo Basic Compiler, MMG Basic Compiler, i  jeszcze jeden jakiś był ;P

Sikor umarł...

9

Pin napisał/a:

Larek - a nie lepiej oprzeć to o:

ON los GOSUB linia1, linia2....

Przywiązanie numeru linii do zmiennej to zły zwyczaj (aczkolwiek oszczędza ram) ;)

Zależy. Przy rozwiązaniu ON ... GOSUB skoczysz do linia1 lub linia2 albo linia3 tudzież liniaX... i co dalej? W każdej z tych części należałoby umieścić kod wyświetlający grafikę. Po co? Przy RESTORE wskazujemy tylko skąd podprogram do wyświetlania grafiki ma pobierać dane. Przy mało skomplikowanym programie wystarczy.
Oczywiście chcąc kompilować kod takie rozwiązanie nie będzie dobre.

10

Można też dane grafiki umieścić w tablicy i odwoływać się do indexu w tablicy. Na pewno przyjaźniejsze dla kompilatora.

Coś w tym rodzaju:

10 DIM A$(19)
20 A$="1234567890ABCDEF"
30 PRINT A$(2,5)
"tatusiu zobacz, narysowałam tobie takie same coś jak na twojej koszulce" 
https://github.com/willyvmm/mouSTer
jmp $e477

11

larek napisał/a:

W każdej z tych części należałoby umieścić kod wyświetlający grafikę.

Przy "ON" niekoniecznie. Procka do rysowania może być jedna.

Kontakt: pin@usdk.pl

12

Co to trzymania grafy to raczej tablice odpadają bo:

  - całej grafy nie zmieszczę w jednej tablicy
  - jeśli bym doszedł jak umieścić jedną grafikę w kilku zmiennych to nie zmieszczę się z ilością tablic, 128 może być jak dobrze pamiętam.

Więc bardziej bym się kierował w READ/DATA, tyle że miałem na tyle przerwy że nawet Migut dla mnie jest ciemną magią, puki co studiuje różne listingi i próbuje sobie przypomnieć jak ten cały bajzel działa :)

13

Iron napisał/a:

Więc bardziej bym się kierował w READ/DATA, tyle że miałem na tyle przerwy że nawet Migut dla mnie jest ciemną magią

Bo BASIC jest trudny, zrób to w assemblerze :)

The problem is not the problem; the problem is your attitude about the problem

14

Wczytuj grafikę z pliku :D

"tatusiu zobacz, narysowałam tobie takie same coś jak na twojej koszulce" 
https://github.com/willyvmm/mouSTer
jmp $e477

15

90 GRAPHICS %0:POKE 82,%0:POKE 710,144:POKE 712,144:POKE 709,15:POKE 752,%1
100 DIM BUF$(9)
110 # L0:LOS=INT(RND(0)*4)+%1:X=INT(RND(0)*31):Y=INT(RND(0)*20)
120 ON LOS EXEC DTA1,DTA2,DTA3,DTA4
130 FOR A=%0 TO %3:READ BUF$:POSITION X,Y+A:? BUF$:NEXT A
140 GO# L0
999 ------------------------------
1000 PROC DTA1:RESTORE #L1:ENDPROC 
1010 # L1:DATA _________
1020 DATA |GRAFA 1|
1030 DATA |.......|
1040 DATA _________
1100 PROC DTA2:RESTORE #L2:ENDPROC 
1110 # L2:DATA _________
1120 DATA |GRAFA 2|
1130 DATA |.......|
1140 DATA _________
1200 PROC DTA3:RESTORE #L3:ENDPROC 
1210 # L3:DATA _________
1220 DATA |GRAFA 3|
1230 DATA |.......|
1240 DATA _________
1300 PROC DTA4:RESTORE #L4:ENDPROC 
1310 # L4:DATA _________
1320 DATA |GRAFA 4|
1330 DATA |.......|
1340 DATA _________

Napisane w TBXL. W Basic składnie GO# zastąp GOTO, EXEC / PROC / ENDPROC - GOSUB / linia / RETURN, wartości %0-%3 na 0-3.

@Willy - ładowanie grafiki z pliku pod Atari Basic :) - nie powiem, że się nie da ale z miejsca nie zastanawiając się nad niczym odpaliłbym Turbo Basic :D

Kontakt: pin@usdk.pl

16 Ostatnio edytowany przez willy (2013-04-08 18:51:19)

Z tym doczytywaniem grafiki z dysku to było raczej jako żart, ale wykonalny.

A wracając do tematu:

Ile tej grafiki tam masz że nie mieści ci się w zmiennych ??

JEdna tablica może zawierać dane wielu grafik. MAx rozmiar tablicy to chyba ... nie pamiętam :D Ale sporo.

A faktycznie TBXL napewno się do tego bardziej nadaje.

edit:
Sprawdziłem empirycznie: 32767 bajtów/znaków

"tatusiu zobacz, narysowałam tobie takie same coś jak na twojej koszulce" 
https://github.com/willyvmm/mouSTer
jmp $e477

17

Iron napisał/a:

grafike sobie przygotowalem na koniec listingu, zwyczajnie jest wtkonana PRINTem a potem literami odpowoadajacymi danym kolorom

Do takiego zastosowania nie potrzeba najprawdopodobniej dużej ilości pamięci, jeśli grafa jest robiona na jednym zestawie fontów (tak mi się wydaje). Następną sprawą jest to, że w przykładzie który dołączyłem powyżej tablica ma objętość 9 bajtów ;)

Niech się lepiej autor zapytania konkretnie wypowie, czy taka konstrukcja rozwiązuje w jakikolwiek sposób problem.

Kontakt: pin@usdk.pl

18 Ostatnio edytowany przez Iron (2013-04-26 18:53:07)

Wrzucam listing jednej z grafik

13000 GRAPHICS 23:SETCOLOR 0,14,5:SETCOLOR 1,14,7:SETCOLOR 2,12,3
13010 ? #6;"     AAAAA"
13020 ? #6;"    ABBBBBA"
13030 ? #6;"    ABBABBA"
13040 ? #6;"   ABBABABBA"
13050 ? #6;"C  ABBABABBA"
13060 ? #6;" C ABBABBBBA"
13070 ? #6;" C ABBABBBBA"
13080 ? #6;" CCABBBAABBA"
13090 ? #6;"CCCABBBBBBBA"
13100 ? #6;"C CAABBBBBA"
13110 ? #6;"CCCCABBBBAA"
13120 ? #6;"CCCCCCCCCCC"
13130 ? #6;" CCCCCCCCCCC"
13140 ? #6;" CCCCCCCCCCC"
13150 GOTO 13150

Co do Atari czy Turbo Basic to wcale nie napinam sie na Atari, po prostu grafike tylko w nim robie, dalej jak bedzie trzeba uzyje TBXL :)

P.S. Dorzucam dla ciekawskich ATRa z moimi pracami i spadam studiowac Miguta, moze mi sie cos przypomni :)

Post's attachments

Grafik_do_gry.atr 179.64 kb, liczba pobrań: 6 (od 2013-04-26) 

Tylko zalogowani mogą pobierać załączniki.

19

Ooops...
Bardzo nieefektywny sposób na przechowywanie grafiki. Zamiast 2 bitów 1 pixel zajmuje 1 bajt.
Do tego wyświetlanie tak przechowanej grafiki jest wolne. Nawet bardzo :)

"tatusiu zobacz, narysowałam tobie takie same coś jak na twojej koszulce" 
https://github.com/willyvmm/mouSTer
jmp $e477

20

Iron, wyświetl ten obrazek printem, znajdź adres początku pamięci obrazu, zgraj go przez PEEK+PUT, ładuj przez GET bezpośrednio do pamięci i będziesz miał bezstratną kompresję x4, a jaki przyrost szybkości! :-) (nie zapomnij ominąć pustych miejsc na ekranie).

___
Press play on tape...

21 Ostatnio edytowany przez synthpopalooza (2013-05-03 02:05:39)

Don't know if this will help:

In Atari BASIC you can mess with the variable name table, and set a string to point to the screen memory (88+89*256) ... doing string assignments in the normal way, like S$(1,10)="XXX" will cause the data to be instantly POKE'd to the screen.  This can be a quick way to do blitter graphics or softsprites.

The article which shows this is here: http://www.atarimagazines.com/compute/i … k_poke.php

Best news:  This is done without using assembly!

You MUST make sure the string you use is the first string declared in the program, and you cannot use this in immediate mode or the Atari will crash.

Also, if you use revision A of BASIC (400/800) you cannot DIM the string to a multiple of 256, this triggers a lockup bug.  Add one to the value.