kategoria: Blitz
[#1] Tłumaczenie WhatIFF BlitzBasic2
Witam postanowiłem przetłumaczyć za pomocą Tłumacza (w końcu 21 wiek) google z poprawkami na Polski
Lekcje z MAGAZYNU Amigowego "WhatIFF"
Pisane przez osobę "Andy Vaisey"

Pierwsze wprowadzenie, opis instalacji BB2 i pomocniczych programów ukazały się W części WhatIFF 3.14

Jeśli gdzieś znajdziecie błędy to przepraszam, czytałem kilka razy, powinno być OK.
Pozdrawiam

Witamy w pierwszej części „Podstaw Blitz Basic”, w której mam nadzieję przedstawić
tym obecnym użytkownikom Amigi, tym, którzy wracają do świata Amigi po wielu
latach lub tym, którzy dopiero zaczynają przygodę z Amigą, programowanie przy użyciu raczej
wspaniałego Blitz Basic 2!

Dlaczego Blitz Basic 2, a nie asembler 68000? Chociaż asembler 68K jest
bardziej wydajny i prawdopodobnie zapewnia większą kontrolę niskiego poziomu nad Amigą, jest
szczerze mówiąc nieco trudniejszy do nauczenia. Blitz Basic 2 (dalej BB2) zapewnia
bardziej przyjazne użytkownikowi doświadczenie i łagodniejszą krzywą uczenia się. Umożliwia
tworzenie gier, dem lub prostych, przyjaznych dla systemu operacyjnego aplikacji Workbench z
łatwością! Nie daj się zwieść słowu basic w nazwie. Chociaż mało prawdopodobne jest, że napiszesz coś,
co będzie rywalizować z Uridium 2 lub Photogenics,
BB2 jest rzeczywiście bardzo potężny, prawdopodobnie potężniejszy niż większość ludzi
przypuszcza!

Zanim jednak zaczniesz programować, ważne jest, aby skonfigurować
środowisko, w którym możesz być kreatywny i wszystko jest pod ręką, plac zabaw
kodowania, jeśli wolisz. Nie ma nic gorszego niż rozpoczęcie projektu,
a następnie konieczność przerwania, ponieważ potrzebna aplikacja lub plik nie są zainstalowane
lub ich brakuje.

Ryzykując, że zabrzmię kontrowersyjnie, zdecydowanie zalecam, aby wszelkie
programowanie na maszyny retro odbywało się na nowoczesnym komputerze. Większość
osób, które znam, a które tworzą gry i dema na Amigę, Commodore64, Plus/4
i ZX Spectrum, używa metod cross-assembly. Oznacza to, że produkują kod,
grafikę i muzykę dla maszyny docelowej na swojej nowoczesnej maszynie, testują
regularnie przy użyciu emulatorów i na regularnych etapach przenoszą i testują
na rzeczywistym komputerze docelowym.

Jeśli to brzmi jak herezja, nie zapominaj, że pod koniec lat 80.
i w latach 90. większość deweloperów, zarówno dużych, jak i niezależnych,
korzystała z jakiegoś systemu cross-development. Ocean Software używało wewnętrznego systemu Atari ST do tworzenia dla szeregu maszyn 8- i 16-bitowych, podczas gdy
dwuosobowy Graftgold opracował własny system przy użyciu kilku komputerów OPUS PC, Avocet cross assembler i samodzielnie zbudowanych kabli! Istniał nawet komercyjny system
o nazwie PDS, który pozwalał deweloperom na używanie systemu opartego na PC do tworzenia dla
a następnie przenoszenia na szereg maszyn 8- i 16-bitowych.

Oczywiście, nie mówię, że nie powinieneś rozwijać natywnie, po prostu
korzystanie z nowoczesnego systemu cross-development może pozwolić ci być bardziej produktywnym.

Kiedy pracuję nad projektem Amiga lub C64, jeśli mam trochę wolnego czasu
w pracy lub jeśli jestem poza domem na krótkiej przerwie, mogę pobrać swój kod/grafikę/muzykę
na laptopa z usługi w chmurze, popracować nad nim, przetestować w emulatorze, a następnie
wgrać z powrotem do chmury. Znacznie łatwiejsze niż noszenie ze sobą mojego A1200 lub C64! Emulator pozwala również na małe oszustwa, takie jak wirtualne przyspieszenie
dyskietek, przeciąganie i upuszczanie plików między emulatorem
a komputerem hosta i tak dalej! Niesamowicie przydatne!

Czego używam do rozwijania na Amiga? Mam prawdziwy A1200 z OS3.1, kartą
1230/16Mb, dyskiem twardym CF 4Gb z Workbench3.1 i wewnętrznym napędem dyskietek Gotek (mój prawdziwy napęd dyskietek zepsuł się w zeszłym roku). Chociaż mogę trochę
podrasować lub wprowadzić drobne zmiany, ten system jest używany głównie do testowania. Właściwie rozwijam się, używając WinUAE na moim laptopie. Używając WinUAE lub innego
podobnego emulatora, możesz uruchomić wiele systemów Amiga. Mam dedykowaną,
tylko do rozwoju konfigurację, która jest prawie identyczna z moim prawdziwym systemem Amiga, ale uruchamiam również inne emulowane konfiguracje, aby przetestować mój kod
na jak największej liczbie różnych wersji Amigi, od standardowego KS1.3 1Mb A500, aż do KS3.2 32Mb A1200/040 i wszystkiego innego
po obu stronach i pomiędzy.

Na potrzeby tych samouczków zakładam, że masz podstawową
znajomość Amigi i będziesz używać systemu cross-development, takiego jak mój, ale jeśli rozwijasz natywnie, wszystko będzie w porządku,
musisz tylko pominąć część konfiguracji poniżej i/lub być przygotowanym na wykonanie
trochę więcej pracy, aby przenieść i zainstalować różne elementy oprogramowania na
swoim prawdziwym sprzęcie Amigi. Ostrzegam, jeśli używasz tylko 1Mb OS1.3 A500 na dyskietce, ty i BB2 prawdopodobnie będziecie mieć problemy!

Zakładam również, że będziesz rozwijać cały kod, grafikę i
dźwięk sam, tak jak ja. Oczywiście, możesz pracować w zespole, ale czasami, jako
główny programista, trudno jest sprawić, aby inni produkowali grafikę lub dźwięk
na czas i zgodnie ze specyfikacją, której potrzebujesz! Wiem, sam to przeżyłem!

Set-Up

Jak już wspomniano, sugerowałbym skonfigurowanie emulatora Amigi na wybranym przez siebie
nowoczesnym sprzęcie. Instalacja i konfiguracja emulatora wykracza poza zakres
tego samouczka, więc będziesz musiał zapoznać się z instrukcjami dla wybranego
emulatora, ale po uruchomieniu powinieneś utworzyć system Amigi przeznaczony
wyłącznie do rozwoju, podobny do poniższego:

* A1200 z OS3.1 i Workbench3.1
* Procesor 030.
* 1 GB szybkiej pamięci RAM.
* Dysk twardy (minimum 4 GB).

WAŻNA UWAGA: Aby uruchomić emulowaną Amigę, będziesz potrzebować ROM-ów Kickstart (układów, które zawierają oprogramowanie rozruchowe Amigi) i obrazów dyskietek Workbench. Są one łatwo dostępne online, choć nielegalnie, jeśli poszukasz,
ale nie możemy podać tutaj linku do pobrania, ponieważ nadal są chronione prawami autorskimi. Jeśli chcesz zrobić to legalnie, wymagane ROM-y i dyski
można skopiować z prawdziwego komputera za pomocą różnych programów, ale
najłatwiejszą drogą jest zakup pakietu Amiga Forever Plus:

https://bit.ly/whatiff-foreverplus

Dlaczego powyższy emulowany system? Tworzenie na OS3.1 A1200 z 68030
daje dobry kompromis między wydajnością i zgodnością zarówno ze
starszymi, mniej wydajnymi systemami, jak i dzisiejszymi, wydajniejszymi, ulepszonymi systemami.
Połącz to z faktem, że w emulatorze możesz użyć suwaka, aby
dać sobie absurdalną ilość szybkiej pamięci RAM, a otrzymasz
środowisko, które jest bardzo stabilne i niezawodne; BB2 będzie naprawdę bardzo szczęśliwym
językiem programowania!

Zalecałbym, aby wirtualny dysk twardy działał jako foldery/katalogi
na twoim systemie hosta, a nie hardfile, aby umożliwić proste operacje przeciągania i upuszczania. Zalecam również, aby te foldery na dysku twardym znajdowały się w folderze
/partycji, która jest automatycznie kopiowana zapasowo do usługi w chmurze. Moje foldery dyskowe System
(Workbench) i Work (programy i dane) znajdują się w moim folderze Dropbox, więc mój kod i pliki robocze są zawsze dostępne, gdziekolwiek jestem! To
oczywiście tylko moje preferencje, twoje wyniki mogą się różnić!

Ponownie, instalacja pełnego Workbench 3.1 na dysku twardym wykracza poza zakres
tego samouczka, ale jest wiele naprawdę dobrych artykułów online i filmów na YouTube, które wyjaśniają ten proces.

Gdy twoja wirtualna Amiga będzie gotowa, będziesz musiał zainstalować BB2. Chociaż
powinieneś używać przynajmniej wersji 2.1, istnieje edycja ultimate, która
zawiera wszystkie aktualizacje i zasoby, z edycją nowoczesnego podręcznika.

Pobierz tę wersję tutaj:

https://bit.ly/whatiff-bb2

Jest ona dostępna w pakiecie ZIP i po rozpakowaniu otrzymasz
archiwum Amiga LHA. Piękno korzystania z emulatora, takiego jak WinUAE
(lub podobnego), polega na tym, że archiwa LHA można montować jako napęd za pośrednictwem sekcji CD & Hard
drives! Będziesz mieć wówczas dostęp do archiwum jako drive
w samym Workbench i będziesz mógł kontynuować instalację BB2 na dysku twardym Amigi; po prostu postępuj zgodnie ze wszystkimi instrukcjami i pozwól mu zainstalować
wszystko! Jedyne, co musisz wybrać na początku, to miejsce, w którym chcesz zainstalować program (moja instalacja BB2 znajduje się na mojej partycji roboczej, oddzielnej od partycji systemowej zawierającej Workbench).

Po zainstalowaniu powinieneś mieć szufladę Blitz2, gdziekolwiek zdecydujesz się zainstalować BB2, a w tej szufladzie wiele plików i szuflad, w tym
plik programu o nazwie Blitz2, który jest edytorem z wbudowanym
kompilatorem używanym do wprowadzania i uruchamiania kodu. Spróbuj go uruchomić, aby upewnić się, że działa i poszperaj!

W późniejszym terminie możemy ulepszyć tę instalację BB2, dodając dodatkowe
biblioteki, które oferują dodatkowe polecenia i przydatne funkcje. Omówimy również nowsze wersje BB2 o nazwie AmiBlitz, dalszy
rozwój, częściowo przeprojektowaną i zmodernizowaną wersję bazy kodu open source BB2.

Jednak zanim zaczniemy kodować, musimy rozszerzyć nasze środowisko programistyczne o dodatkowe aplikacje do obsługi grafiki i muzyki.
Jeśli potrzebujesz sugestii, wszystko, co mogę zrobić, to powiedzieć, czego użyłem do stworzenia mojej
gry Amiga Spheroid, która dobrze działała z BB2:

Deluxe Paint:
do tworzenia i edycji bitmap i pędzli. Idealnie byłoby, gdybyś potrzebował przynajmniej
wersji 4 lub nowszej, przy czym wersja 5 jest najlepsza do grafiki AGA.

Personal Paint:
do tworzenia i edycji bitmap i pędzli. Późniejsze edycje oferują
możliwość importowania i zapisywania bardziej nowoczesnych formatów graficznych, takich jak pliki PNG.
Wersja 7.1c jest dostępna bezpłatnie na stronie internetowej:

https://www.ppaint.com
(przewiń na dół strony).

OctaMED:
do ładowania, zapisywania i edytowania plików trackerów muzycznych w formacie MED i MOD. Preferuję wersję 5, ale BB2 obsługuje odtwarzanie (z
dodatkowymi elementami sterującymi) tylko plików MED do wersji 3, więc rozważ to lub
pamiętaj, aby zapisać się na tę wersję, jeśli używasz nowszych wersji!

AudioMaster IV:
do przechwytywania, ładowania, zapisywania i edytowania próbek dźwiękowych. Jest dość stary
i wygląda raczej przestarzale w KS3.0 i nowszych, ale działa świetnie i jest dość
mocny.

Directory Opus (DOpus):
program menedżera plików do zarządzania plikami i szufladami. Bardzo przydatny do
przenoszenia plików między dyskietkami a dyskami twardymi.

VirusZ III:
jeśli pobierasz zasoby Amigi z Internetu, prawdopodobnie dobrym pomysłem jest, aby Twoja Amiga uruchomiła skaner/zabójcę wirusów! Pobierz jeden tutaj:

https://bit.ly/whatiff-virusz

ReOrg:
małe narzędzie do reorganizacji lub defragmentacji dysków rzeczywistych/wirtualnych.

Te programy i wiele innych można znaleźć na stronie Aminet:

https://aminet.net/

Po znalezieniu i zainstalowaniu wszystkich powyższych elementów powinieneś mieć całkiem
(bardzo) wydajny system programistyczny oparty na Amidze i BB2. Oczywiście, poprzednie
wydania WhatIFF? zawierały doskonałe artykuły i samouczki na temat
tworzenia muzyki przy użyciu OctaMED, pobierania i edytowania próbek i nie tylko, więc
powinieneś być z nimi częściowo na bieżąco! Jeśli nie, pobierz kilka poprzednich
wydań i zacznij czytać!

W kolejnej odsłonie Blitz Basic Basics zajmiemy się prawdziwym
kodowaniem, obiecuję! Nie zamierzam jednak marnować cennego miejsca na dysku i czasu
na wyjaśnianie wszystkich poszczególnych poleceń języka BB2. Wierzę, że
należy od razu rzucić się w wir nauki i uczyć się poprzez działanie, więc
będę dostarczać proste przykłady kodu, wyjaśniając, co ten kod robi i
może wyznaczę kilka prostych wyzwań do wykonania!

W międzyczasie, jeśli chcesz przejrzeć zestaw instrukcji BB2 w podręcznym
odniesieniu online, zajrzyj tutaj:

https://bit.ly/whatiff-bb2guide
5
[#2] Re: Tłumaczenie WhatIFF BlitzBasic2

@mwb113, post #1

Lekcja DRUGA , BB2 części WhatIFF 3.15

Jeśli gdzieś znajdziecie błędy to przepraszam, czytałem kilka razy, powinno być OK.
Pozdrawiam

Blitz Basic Basics Part 2: A Simple Demo - by: "Andy Vaisey"

Witamy w drugiej części Blitz Basic Basics, gdzie mam nadzieję, że nauczysz się
kodowania i tworzenia prostych dem i gier przy użyciu doskonałego języka programowania Blitz Basic
2 (BB2)!

Jeśli przeczytałeś i śledziłeś część 1, powinieneś teraz mieć proste środowisko
programistyczne na Amidze (prawdziwej lub emulowanej) gotowe do rozpoczęcia! W części 2
utworzymy bardzo proste demo, które ładuje się i uruchamia automatycznie,
wyświetla obraz bitmapowy podczas odtwarzania muzyki, a następnie wychodzi po naciśnięciu klawisza.

Należy pamiętać, że ten i przyszły kod są napisane w sposób ułatwiający
początkującym czytanie i zrozumienie. Będą sposoby, aby uczynić go
bardziej zwartym, szybszym i/lub lepszym, ale na tym etapie ważniejsze jest uruchomienie czegoś,
aby poczuć osiągnięcia! Choć nie ma w tym nic wymyślnego ani nie wygrywa się w konkursach, ta część Blitz Basic Basics pomoże ci nauczyć się:

= umożliwiać uruchamianie programu z Workbench
= używać szybkiego trybu BLITZ w BB2
= konfigurować wyświetlacz
= ładować obraz bitmapowy
= wyświetlać bitmapę na wyświetlaczu
= ładować muzykę
= odtwarzać muzykę
= obsługiwać naciśnięcie klawisza na klawiaturze
= kompilować i testować nasz kod
= tworzyć plik wykonywalny do rozprzestrzeniania swojego warez!

W szufladzie BBB P2 na dysku dołączonej do tego artykułu znajdziesz:

= program o nazwie BBB Demo 1
= plik kodu źródłowego Blitz2 o nazwie Demo1Code.bb2
= szufladę o nazwie data zawierającą pliki potrzebne do wersji demonstracyjnej

Przejdź dalej i uruchom plik BBB Demo 1. Po pewnym czasie ładowania na ekranie
powinno pojawić się logo WhatIFF? z odtwarzanym fragmentem muzyki saksofonowej (muzyka ta jest czymś, co napisałem w 1992 roku i jest to pierwszy raz, kiedy ktoś inny ją usłyszał, oprócz mnie!). Gdy już
masz dość tej ekstrawagancji (!), naciśnij spację na klawiaturze, aby wrócić do Workbench/
AmigaOS.

Zatem przyjrzyjmy się, jak powstała ta bardzo prosta demonstracja na jednym ekranie.
Załaduj edytor/kompilator BB2 na swojej Amidze (który powinieneś już
mieć zainstalowany), kliknij OkeeDokee w oknie powitalnym, a następnie wybierz Load
z menu Project. Znajdź i załaduj plik o nazwie DemoCode1.bb2 w
szufladzie BBB P2.

Pierwsze uwagi na temat głównego edytora/kompilatora wyświetlającego kod?

= Wszystko w wierszu po średniku to tylko tekst i nie jest uważane za
kod, który Amiga może uruchomić. Jest to podobne do starszych wersji BASIC-a,
w których mogłeś zobaczyć polecenie REM, skrót od Remark, które
są tylko komentarzami i notatkami. W efekcie, gdy kod jest kompilowany i uruchamiany,
te komentarze nie są używane i są pomijane w celu zaoszczędzenia pamięci.

= Niektóre słowa są wyróżnione innym kolorem. Te słowa to
instruction set, główne polecenia BB2. Reszta kodu jest
w innym kolorze, zwykle czarnym.

= Po prawej stronie znajduje się lista słów. Pomyśl o nich jako o
skrócie do różnych sekcji (podprogramów) kodu. Jeśli
klikniesz jedno z tych słów, edytor przeskoczy do tej sekcji w kodzie
i zobaczysz, że te słowa mają kropkę [.] na początku.
Zazwyczaj te skróty służą do wywoływania lub przechodzenia do dłuższych
podprogramów, ale w tym przykładzie użyłem ich więcej, abyś mógł
szybciej przeskakiwać po kodzie!

Co właściwie robi ten kod? Pierwsze dwa polecenia to:

NoCli
WBStartup

Polecenie NoCli zatrzymuje Amigę przed otwarciem domyślnego okna CLI podczas
testowania kodu w środowisku kodowania BB2. To polecenie jest ignorowane
podczas tworzenia w pełni funkcjonalnego i samoczynnie uruchamiającego się pliku po zakończeniu
rozwoju, ponieważ okno CLI nie zostanie wtedy otwarte.

Polecenie WBStartup jest bardzo ważne. Ponieważ Amiga ma przyjazny, wielozadaniowy system operacyjny, jest prawdopodobne, że w pewnym momencie użytkownik
Twojego programu będzie chciał uruchomić go z Workbench. Jeśli nie uwzględnisz tego polecenia, a użytkownik spróbuje uruchomić go z Workbench, Twój program
ulegnie awarii, prawdopodobnie zabierając ze sobą AmigaOS. Bezpieczniej jest uwzględnić to polecenie
niż nie!

Następnie w kodzie mamy sekcję constants:

.constants
#COPPER_MAIN = 0
#PALETTE_MAIN = 0
#BITMAP_MAIN = 0
#MODULE_MAIN = 0

Co to w ogóle za bzdura i czym w ogóle jest stała?!
Stała to wartość liczbowa, która NIGDY nie zmienia się podczas działania
programu i zwykle jest nazywana, aby ułatwić czytanie. W Blitz2
stałe są deklarowane za pomocą symbolu hash na początku. Więc gdziekolwiek w
resztach przykładu kodu widzisz #BITMAP_MAIN, BB2 wie, że wartość
jest równa zero i zawsze pozostaje zero. Oczywiście, możesz przypisać inną
wartość liczbową, ale ja używam zera, ponieważ używamy tylko jednej mapy bitowej, a
komputery zawsze zaczynają liczyć od zera! Gdybym użył drugiej mapy bitowej,
stała dla niej miałaby inną nazwę i byłaby równa jeden.

Po stałych ustawiłem kilka zmiennych (variables):

.variables
BWIDTH = 320 ; bitmap width
BHEIGHT = 256 ; bitmap height
BDEPTH = 5 ; bitmap colour depth


Co? Zmienne to słowne lub literowe reprezentacje wartości liczbowych, więc
gdziekolwiek w tym przykładzie kodu widzisz słowo BWIDTH, BB2 wie, że
wartość wynosi 320. W przeciwieństwie do stałych, zmienne można zmienić w dowolnym momencie,
wykonując na nich operację matematyczną lub po prostu nadając im nową wartość
za pomocą symbolu równości. Zauważ, że użyłem średnika na końcu
każdej linii, abym mógł dodać komentarz wyjaśniający, do czego odnosi się zmienna.

Kilka uwag, zanim przyjrzymy się bliżej kodowi. Być może zauważyłeś,
że użyłem wielkich liter w nazwach stałych i zmiennych. Nie jest to
absolutnie konieczne, ale wolę, aby wszystko wyglądało schludnie. Ponadto w BB2 nazwy zmiennych można ustawić jako określony typ z
sufiksem, dla dokładności. Na razie nie będziemy się tym martwić, ponieważ
BB2 chętnie przypisze type wewnętrznie, ale pojawi się to w przyszłych
artykułach i zostanie wtedy wyjaśnione. Na koniec przyznanie się: moje zmienne w
tym przykładzie mogłyby być w rzeczywistości stałymi, ponieważ nie ulegną
zmianie w tym kodzie, ale chciałem pokazać i opisać stałe i zmienne oraz
różnicę między nimi! No i masz!

Wracając do naszego przykładu kodu, mamy teraz:

.createbitmap
BitMap #BITMAP_MAIN,BWIDTH,BHEIGHT,BDEPTH

To polecenie BitMap tworzy obiekt lub wyświetlacz, na którym możemy wyświetlać
grafikę (całe obrazy, sprite'y, obiekty blitter itd.), a wszystko
po tym poleceniu mówi BB2, jak utworzyć obiekt. Informacje, których BB2
potrzebuje do utworzenia tego obiektu/wyświetlania to:

= a bitmap number to give the object
= the bitmap width
= the bitmap height
= the bitmap depth (number of colours)


W naszym przykładowym demo nadajemy mapie bitowej liczbę zero (stała
BITMAP_MAIN), szerokość wyświetlania 320 (zmienna BWIDTH), wysokość wyświetlania
256 (zmienna BHEIGHT) i głębokość wyświetlania 5 (zmienna
BDEPTH). Jeśli zastanawiasz się, dlaczego brzmię zawile i używam terminów
takich jak obiekt i wyświetlanie zamiast po prostu powiedzieć screen, to dlatego, że w
BB2 screen i powiązane polecenia odnoszą się do ekranu Workbench (Intuition),
na którym otwierasz okna, a to jest coś innego!

Moglibyśmy bezpośrednio zakodować na stałe te wartości liczbowe wraz z poleceniem
BitMap w następujący sposób:

BitMap 0,320,256,5

Ale piękno używania stałych i zmiennych polega na tym, że można używać łatwych do
zapamiętania słów na ładnej liście na początku kodu, które w razie potrzeby
zmiany można łatwo znaleźć i zmienić, zamiast przeszukiwać
kod w celu znalezienia bitu, który należy zmienić.

Ponadto, zaletą używania stałych i zmiennych jest to, że nie trzeba
pamiętać ani zapisywać, który numer odnosi się do którego zasobu. Na przykład,
wyobraź sobie, że tworzysz lub ładujesz pięć map bitowych. Każda mapa bitowa może mieć swój własny
numer. Zamiast zapamiętywać, która mapa bitowa ma jaki numer,
używając stałej, możesz przypisać opisową nazwę. W naszym przykładzie kodu,
bitmapa 0 jest nazywana BITMAP_MAIN, ponieważ jest to główna bitmapa, której używamy. Możesz
zrobić to samo z innymi danymi, takimi jak wyświetlacze miedzi, muzyka,
próbki dźwiękowe itd.

Kontynuując używanie tej logiki, możesz zobaczyć, że zrobiłem to samo dla
rozmiaru bitmapy, używając zmiennych ustawionych na początku. Jak już wspomniano, ponieważ
te wartości się nie zmienią, technicznie rzecz biorąc, mogłyby być stałymi.

Inna część konfiguracji wyświetlania obiektu bitmapy, która wymaga wyjaśnienia, to
depth, w efekcie liczba kolorów, które chcemy wyświetlić na wyświetlaczu bitmapy. W
naszym przykładzie jest ustawiona jako 5, co odpowiada 32-kolorowemu wyświetlaczowi. Jak to
działa? Wartość głębi do potęgi 2 daje liczbę kolorów,
jak poniżej:

Depth 1 = 2 colours
Depth 2 = 4 colours (2x2)
Depth 3 = 8 colours (2x2x2)
Depth 4 = 16 colours (2x2x2x2)
Depth 5 = 32 colours (2x2x2x2x2)
Depth 6 = 64 colours (2x2x2x2x2x2)

Następnie w kodzie ładujemy pewne zasoby (grafikę i muzykę):

.loadassets
LoadBitmap #BITMAP_MAIN,data/logo.iff
LoadPalette #PALETTE_MAIN,data/palette.col
LoadModule #MODULE_MAIN,data/music.mod


Większość tych poleceń powinna być dość oczywista!
Ładujemy ekran bitmapowy narysowany w pakiecie graficznym, paletę z tej
bitmapy zapisaną oddzielnie w tym pakiecie graficznym i moduł muzyczny
napisany w trackerze muzycznym. Jak widać, ponownie używamy naszych wcześniej
zadeklarowanych stałych, aby przypisać łatwe do zapamiętania nazwy tym załadowanym zasobom
zamiast używać numerów w całym kodzie! Wszystkie zasoby są ładowane
z szuflady o nazwie data, która MUSI znajdować się w tej samej szufladzie nadrzędnej
/disk co nasz plik kodu lub ostateczny plik wykonywalny, w przeciwnym razie ładowanie się nie powiedzie.

Następnie mamy polecenie wait:

VWait 250

To jest pionowe puste czekanie. Na starych ekranach CRT obraz jest rysowany przez
wiązkę elektronów poruszającą się z lewej do prawej, z góry na dół. Wszelkie zmiany wprowadzane
na ekranie podczas rysowania prawdopodobnie spowodują migotanie. Dlatego
warto poczekać, aż ekran zostanie narysowany, a wiązka zniknie
z ekranu przed wprowadzeniem jakichkolwiek zmian. Dzieje się jeszcze trochę, ale na razie
to wszystko, co musimy wiedzieć.

Jednak tym razem nie wprowadzamy żadnych zmian na
ekranie, ale używamy polecenia jako timer. 250 odpowiada około 5
sekundom (co 50 pionowych pustych miejsc to około sekundy). Powodem tego
oczekiwania jest to, że uzyskaliśmy dostęp do dysku w celu załadowania naszych zasobów i
musimy się upewnić, że dostęp do dysku został zakończony, zanim wydamy
jeszcze jakieś polecenia. Jeśli nasz kod będzie kontynuowany przed zakończeniem dostępu do dysku, ryzykujemy
awarią! WAŻNE!!! Po załadowaniu czegokolwiek w BB2, odczekaj co najmniej 5 sekund,
zanim zrobisz cokolwiek innego, zwłaszcza używając następnego polecenia, wyjaśnionego
poniżej:

Teraz wchodzimy w inny mode za pomocą następującego kodu:

.blitzmode
BLITZ
BlitzKeys On

Polecenie BLITZ wprowadza Twój program w tryb Blitz! Oznacza to, że system operacyjny Amigi
zostaje wyłączony, a Twój kod przejmuje teraz całą maszynę,
teraz masz pełną kontrolę nad wszystkimi tymi potężnymi układami scalonymi wewnątrz
Twojej Amigi! Oznacza to, że Twoja Amiga nie będzie już wykonywać wielu zadań jednocześnie ani
mieć dostępu do plików na dysku, ale zaletą trybu BLITZ jest to, że Twój
kod wykonuje się znacznie szybciej i masz dostęp do potężnych funkcji wyświetlania,
takich jak płynne przewijanie i podwójne pola gry!

Mimo że wyłączyliśmy system operacyjny, polecenie BlitzKeys On
nadal pozwala nam odczytać klawiaturę, aby sprawdzić, czy użytkownik nacisnął
klawisz.

Tryb BLITZ można tymczasowo zatrzymać, aby ponownie włączyć dostęp do dysku i funkcje wielozadaniowości, jeśli jest to konieczne. Zostanie to omówione w przyszłym artykule.

Teraz musimy faktycznie wyświetlić naszą wcześniej załadowaną mapę bitową:

.initcopperlist
InitCopList #COPPER_MAIN,44,256,$00005,8,32,0

.displayscreen
DisplayPalette #COPPER_MAIN,#PALETTE_MAIN
DisplayBitmap 0,#BITMAP_MAIN
CreateDisplay #COPPER_MAIN
Use BitMap #BITMAP_MAIN

Co to w ogóle jest?! BB2 został pierwotnie napisany przed pojawieniem się chipsetu
AGA Amiga, więc późniejsze wersje BB2 dodały nowe biblioteki dla poleceń CopList
, zastępując stare polecenia Slice, aby wykorzystać zalety
nowszego chipsetu Amiga AGA. Te polecenia CopList są w pełni zgodne
ze starszymi chipsetami i muszą być zainicjowane w kodzie tylko raz. Biblioteka
CopList służy do wyświetlania naszej grafiki.

Czym więc jest polecenie InitCopList? Tworzy ono wyświetlacz i
przydziela pamięć, w której możemy wyświetlić naszą mapę bitową na wyświetlaczu. Wszystkie liczby
po poleceniu odnoszą się do następujących parametrów (i tak, niektóre z tych
parametrów CopList mogłyby być stałymi!):

InitCopList CopList#,ypos,height,flags,sprites,colours,custom

CopList# to numer listy miedzi, której chcemy użyć. W
przykładowym kodzie używamy naszej stałej #COPPER_MAIN. Parametry ypos i height
definiują pionową sekcję ekranu, którą zajmie nasz wyświetlacz. W naszym przykładowym kodzie wyświetlacz znajduje się na 44, na samym szczycie
listy miedzi i ma 256 linii wysokości.

Parametr flags zawiera informacje o rozdzielczości ekranu i liczbie
kolorów. W tym przykładzie kodu mamy $00005, co odpowiada ekranowi o niskiej
rozdzielczości z 32 kolorami. W przyszłych artykułach ten parametr flags
zostanie dokładniej omówiony wraz z wyjaśnieniem, jak zmienić
rozdzielczość ekranu i liczbę kolorów.

Parametr sprites powinien zawsze wynosić 8, ponieważ jest to maksymalna liczba
spritów, jaką Amiga może wyświetlić. Parametr colours ustawia liczbę
kolorów na naszej liście miedzi, w naszym przypadku 32. Parametr custom
powinien być na razie ustawiony na 0.

Polecenie DisplayPalette kopiuje naszą poprzednio załadowaną paletę kolorów
(#PALETTE_MAIN) do zainicjowanej przez nas listy CopList (#COPPER_MAIN), a polecenie
DisplayBitmap mówi komputerowi, że chcemy użyć naszej listy CopList do
wyświetlenia naszej poprzednio załadowanej mapy bitowej (#BITMAP_MAIN).

Na koniec wydajemy polecenie CreateDisplay, aby skonfigurować nowy wyświetlacz ekranu
z biblioteką wyświetlania CopList i mówimy liście CopList, aby użyła naszej mapy bitowej
z Use Bitmap.

Uff! Już prawie gotowe! Następny w kodzie jest:

.playmusic
PlayModule #MODULE_MAIN

Mam nadzieję, że to nie wymaga wyjaśnień?! OK, to polecenie odtwarza nasz
wcześniej załadowany moduł muzyczny!

I na koniec mamy:

.mainloop
Repeat
VWait
Until RawStatus (#KEY_SPACE)
End

Większość programów, czy to proste demo, takie jak to, czy skomplikowana gra,
ma pętlę główną. Pętla główna to miejsce, w którym komputer otrzymuje polecenie
ciągłego wykonywania serii zadań. Na przykład w grze pętla główna
może przejść do serii podprogramów, które sprawdzają joystick,
aktualizują wyświetlacz, kontrolują animacje, odtwarzają efekty dźwiękowe, sprawdzają kolizje itd.

Nasza pętla główna zaczyna się tutaj od polecenia Repeat i kończy poleceniem Until. Pętla po prostu czeka na pionowy odstęp, aż
użytkownik naciśnie klawisz spacji na klawiaturze, co sprawdza polecenie RawStatus
i wbudowaną stałą #KEY_SPACE. Gdy użytkownik naciśnie spację,
kod wychodzi z pętli i napotyka polecenie End, które, co zabawne,
kończy demo i wraca do tego, co komputer robił przed uruchomieniem
demo. Zanim zapomnę, większość głównych pętli będzie miała gdzieś polecenie VWait, więc upewnij się, że wszystko działa płynnie, więc je
wstawiłem, mimo że nasza główna pętla tak naprawdę nic
obecnie nie robi!

To jest kod, ale jak go przetestować? Przejdź do menu Compiler i
wybierz Compile & Run, a demo powinno się uruchomić. Gdy będziesz mieć dość,
naciśnij spację, a demo powinno wyjść z powrotem do edytora BB2.

Bardziej odważni z was prawdopodobnie będą chcieli zacząć eksperymentować
z tym kodem i stanowczo mówię do dzieła! Nic nie przebije majstrowania
w kodzie innych ludzi. Dlaczego nie spróbować zastąpić mapy bitowej lub muzyki?
Dołączyłem dla ciebie inną mapę bitową i plik muzyczny do szuflady data ! Jeśli
nic innego, jeśli jesteś osobą zajmującą się grafiką lub muzyką, masz teraz
podstawę prostego systemu wyświetlania, aby wydawać własne grafiki i muzykę; koniec
z czekaniem na leniwego kodera lub używaniem paskudnego twórcy wersji demonstracyjnej, aby wyświetlić
twoją ciężką pracę!

Chociaż stworzyłem już samoczynnie uruchamiający się plik wykonywalny (BBB Demo 1), jeśli
wprowadzisz jakieś zmiany i będziesz chciał utworzyć nowy plik wykonywalny, istnieje opcja
w menu Compiler, aby to zrobić! Upewnij się tylko, że utworzysz plik wykonywalny w tej samej szufladzie/dysku nadrzędnym, co szuflada data!

W następnej części Blitz Basic Basics będziemy rozwijać ten prosty kod wyświetlania, wykorzystując ponownie niektóre polecenia, które już omówiliśmy, wprowadzając jednocześnie
więcej poleceń! Jako mała uwaga, moja muzyka saksofonowa w demie
jest odtwarzana w tempie nieco szybszym, do którego pierwotnie ją napisałem 30 lat temu. Ma to związek ze sposobem, w jaki BB2 odtwarza moduły muzyczne za pośrednictwem biblioteki, która
nalega na synchronizację za pomocą pionowego pustego zamiast CIA (układu scalonego wewnątrz
Amigi, który zajmuje się synchronizacją systemową). Zajmiemy się tym również w przyszłości, być może nawet instalując lepszą bibliotekę muzyczną do użytku BB2.

Do
5
[#3] Re: Tłumaczenie WhatIFF BlitzBasic2

@mwb113, post #1

Te wymagania spire podali. Ja go uruchamiam zarówno na Amidze 1200 z 020 i 8 MB Fast RAM, jak i na A600 z 030 i 64 MB Fast RAM. Na emulatorze również na 020 używam na codzień. Te wymagania to bardziej do AmiBlitz pasują.
1
[#4] Re: Tłumaczenie WhatIFF BlitzBasic2

@tukinem, post #3

Ja tylko tłumaczę, nic nie dodaje od siebie.
Jak bym dorwał książkę po polsku byłoby super.
Dobra już nie zaśmiecamy.
2
Na stronie www.PPA.pl, podobnie jak na wielu innych stronach internetowych, wykorzystywane są tzw. cookies (ciasteczka). Służą ona m.in. do tego, aby zalogować się na swoje konto, czy brać udział w ankietach. Ze względu na nowe regulacje prawne jesteśmy zobowiązani do poinformowania Cię o tym w wyraźniejszy niż dotychczas sposób. Dalsze korzystanie z naszej strony bez zmiany ustawień przeglądarki internetowej będzie oznaczać, że zgadzasz się na ich wykorzystywanie.
OK, rozumiem