Dzięki za za kontynuację. Zapowiada się super tutorial.
Jak na razie nie mam pytań bo tylko przeczytałem, jutro usiądę do komputerka, to może coś przyjdzie :)

A czy interpreterowi robi różnicę czy podaje się liczby dziesiętne czy w heksie? Czy on to musi przeliczać i ma to jakiś wpływ na szybkość działania kodu? Oczywiście mówię tylko o interpreterze, bo wiadomo, że kompilator na pewno i tak to ujednolici.

Nigdy tego nie testowałem, ale tu adekwatny wynik 10000 pustych powtórzeń...
http://www.atari.org.pl/forum/viewtopic.php?id=15894 - edycja, nie dodałem wcześniej linku...

Wcale nie banał, dobrze, że zwróciłeś uwagę na coś, czego nie opisałem - pewne rzeczy z czasem sają się tak oczywiste, że człowiekowi się wydaje, że każdy wie... Co do bload - wczytujesz tylko raz, dopóki nie wyłączysz komputera - działa, bo dane są. Ale fakt, trzeba wczytać. Tylko... Te dane potem łatwo dołączymy do wersji plikowej.
Linia 150 - instrukja "jeżeli" (if), czyli instrukcja warunkowa. Tutaj w wersji krótkiej (stąd słowo kluczowe THEN), która nam mówi: jeżeli jest spełniony warunek (u nas nierówność) to coś zrób - w naszym przypadku oczywiście są to klawisze konsoli, więc czekamy na jakieś działanie odpowiedniego klawisza.
Dzięki lopez za uwagi, bo chociaż wiem, że ktoś coś z tym robi ;) Jak dam radę - to do przyszłej niedzieli część trzecia.
==================
Jeszcze pytanie - w części trzeciej zrobić (ubogą jeszcze, niefunkcjonalną) wersję file (czyli działającą spod DOSa), aby pokazać jak to się robi - czy to zostawić na koniec? Bo może ktoś chce zrobić inną grę, a zasada jest ogólna. Proszę o uwagi w komentarzach.

Na koniec niewątpliwie. Dobra, trzecia część będzie głównie o robieniu wersji file - w międzyczasie przed czwartą częścią będę miał chwilkę na scenariusz i poszukanie grafik do konwersji.

Ja też obserwuję ;)
I może od czasu do czasu coś się odezwę... jeśli Sikor pozwoli :p

Jak już piszemy program w Turbo Basicu XL, to uważam, że szkoda byłoby nie korzystać z jego dobrodziejstw.
Kod:

150 IF PEEK(53279)<>6 THEN 150

można zastąpić:

150 WHILE PEEK(53279)<>6:WEND

Efekt działania taki sam, ale ten wygląd! ;)

W celach edukacyjnych należy wyjaśnić: pętla WHILE - WEND będzie się wykonywać dopóki warunek będzie spełniony. Oczywiście instrukcje WHILE i WEND nie muszą być w jednej linii, mogą być rozdzielone blokiem innego kodu, wówczas cały ten blok będzie wykonywany dopóki warunek będzie spełniony. Warunek jest sprawdzany na początku, więc może dojść do sytuacji, że instrukcje w bloku nigdy nie zostaną wykonane.

I jeszcze taka uwaga - brak obniżenia RAMTOP i ochrony przez to danych w programie może się zemścić, gdy stworzymy naprawdę długi program. Do nauki programowania jest to faktycznie zbyteczne i może wprowadzić tylko zamieszanie w głowach młodych programistów, ale jak już zaczniecie bawić się w tworzenie bardzo obszernych programów, to przypomnijcie sobie o czymś takim, jak RAMTOP.

A czy można zapisać tą samą linię w postaci:

150 WHILE NOT (PEEK(53279)=6):WEND

?

Nie znam Turbo BASIC-a XL, więc może coś poznam. Lubię poznawać nowe rzeczy, oczywiste.

Zmienia czas wykonania operacji

Też o tym myślałem trochę. Nie znając TB XL, ciekawi mnie, czy taki zapis działa w tym języku programowania.

Jeśli działa, to teraz można się zastanowić, jak procesor wykona instrukcję z <> i tę drugą z NOT.

Jeśli <> procesor robi tylko jednym CMP, to wyjdzie szybciej chyba.

Jeśli procesor robi <> na dwóch CMP, to wyjdzie dużo wolniej, niż z NOT, oczywiste.

Instrukcja z NOT to tylko porównanie komórki pamięci z liczbą (=), a potem negacja - dwie proste instrukcje CPU.

Natomiast <> może być być może robione aż na dwóch CMP, bardzo długo wykonujących się. Hmm... ciekawe bardzo dość.

Trzeba by uczciwie zapisać obie instrukcje w asemblerze i będzie widać.

to do kolekcji:

150 REPEAT:UNTIL PEEK(53279)=6

Bez negacji, tylko znak równości

150 ON PEEK(53279)<>6 GOTO 150

Mamy goto, ale działanie dokładnie takie samo

150 #START:ON PEEK(53279)<>6 GO# START

Podobnie
Panowie, mówimy o grze paragrafowej. Ułamki sekund tu nic nie znaczą. Ciekawe za to, jak z zajętością kodu w wynikowym programie. To było jako przykłąd, abyśmy wykorzystali klawisze konsoli. Każdy przykład można przepisać z negacją lub bez, można zaoszczędzić na kilku cyklach, ale nie o to tu chodzi. Nie gmatwajmy kodu. Przykładów robiących to samo można by pewnie podać jeszcze z dziesięć, tylko po co? Nie mnóżmy niepotrzebnie bytów, jak poznamy zasadę działania - każdy sobie znajdzie najlepszą dla niego metodę, jak myślę. Póki co zatrzymała nas obsługa klawiszy konsoli.

Jasne, że nie ma sensu porównywać takich ułamków sekund dla gry paragrafowej. Wspomniałem o tym i zapytałem dlatego, że wybiegam trochę w przyszłość i już myślę do czego by można użyć TBXL następnym razem. Dlatego zainteresował mnie temat takich drobiazgów w sensie jak robi to kompilator. Bardzo dziękuję Willy za rzeczowe wyjaśnienie - właśnie konkretnie chodziło mi o interpretację <> vs !=, którego w Basicu bardzo mi brakuje, bo jestem przyzwyczajony do używania != od lat w pracy zawodowej w językach znienawidzonych komputerów pece. Sikor, nie rozwijaj takich wątków - krótkie pytanie, krótka odpowiedź, w międzyczasie, w oczekiwaniu na kolejny odcinek tutoriala.

No, jak się z Atari Basic przesiadałem na pecety dawno temu, to też mi jakoś brakowało tego <>, a != było dziwnym tworem:-) Teraz mam odwrotnie:-)