Storia di un programmatore / 3
Formule matematiche, "sprite" e musica
Alla fine degli anni '80 ero all'ultimo anno delle scuole elementari e i miei genitori, intuendo che l'informatica mi appassionava molto, mi compravano non solo un numero imprecisato di riviste con cassette di videogiochi, ma anche un corso di BASIC che veniva venduto in edicola, con uscite mensili. Si trattava del "Video BASIC MSX" della Jackson, un corso di 20 puntate, realizzato con grande cura. Ogni uscita aveva un fascicolo, di una trentina di pagine, e una cassetta che conteneva lezioni interattive e alcuni test. In fondo alla cassetta era anche presente un videogioco: una sorta di premio per lo studente che aveva seguito la lezione, anche se in realtà era possibile lanciarlo direttamente.
Imparai molte cose, alcune ovviamente in maniera (molto) imprecisa, e per un paio d'anni cercai di scrivere qualche programma con il mio MSX. Ero un adolescente nella norma, di certo non un genio, perciò non riuscii a combinare granché, a parte scrivere piccoli programmi che eseguivano semplici calcoli matematici. Alcuni di questi, in seguito, li stampai e li tenni per molto tempo, anche se poi gran parte è andata inevitabilmente persa. Il mio obiettivo era quello di creare una sorta di menu da cui era possibile richiamare alcuni programmi che avevo scritto, ed in un certo senso ci riuscii qualche anno più tardi con il PC IBM, anche se in quell'occasione riscrissi tutto daccapo, migliorando decisamente il risultato finale.
Sarebbe stato bello creare un videogioco tutto mio, e dunque cominciai a muovere qualche passo in quella direzione: con qualche difficoltà, creai e feci muovere sullo schermo uno sprite, che non ha nulla a che fare con la famosa bevanda, ma è una piccola immagine che può essere fatta muovere sullo schermo, mentre lo sfondo resta fermo, come ad esempio il Pacman e i fantasmini che lo inseguono, o che scappano da lui quando il Pacman mangia la pillola più grande. La creazione di uno sprite è l'equivalente informatico del procedimento che porta ad un mosaico: per prima cosa, bisogna fare un disegno su carta della figura che si vuole creare, dopodiché è necessario "scomporlo" in minuscoli quadratini della stessa dimensione, annerendo quelli che compongono la figura. In questo modo si può ottenere una sequenza di 0 e 1 che va a definire lo sprite, che può essere così mosso sullo schermo con opportune istruzioni.
Inoltre, trovavo gli spartiti, che avevo appena imparato a leggere, sul libro di musica delle scuole medie, e mi appassionavo a tradurre le musiche nel sotto-linguaggio musicale del MSX-BASIC per vedere come suonavano: l'altoparlante del computer emetteva dei suoni che somigliavano vagamente a quelli di un pianoforte elettrico.
Certo che da qui a creare un videogioco ne mancava tantissima di strada: in particolare avrei dovuto capire come fare muovere le figure sullo schermo mentre la musica suonava in sottofondo, senza trascurare l'interazione in tempo reale con il joystick, in modo da permettere al giocatore di fare le sue mosse. Però da qualche parte bisognava pur sempre cominciare. Di certo, una delle cose che avrei dovuto capire era come organizzare il codice in maniera più rigorosa, dividendo il programma principale dalle procedure: cosa abbastanza difficile con il BASIC, in cui ci sono le subroutine, che sono delle procedure "particolari".
Le subroutine del BASIC
Un'altra delle cose che faticavo a capire - ce ne erano tante - era perché c'erano due istruzioni che sembravano praticamente identiche: GOTO e GOSUB. Si tratta, in effetti, di due istruzioni di salto, ma la differenza sostanziale è che GOTO effettua un salto senza tenere traccia del punto di partenza, mentre GOSUB (che sta per "Go to subroutine") serve a richiamare una subroutine, virtualmente da qualunque riga del programma, e quindi tiene traccia del punto di partenza del salto, e permette di fare ritorno all'istruzione immediatamente successiva, una volta che la routine è terminata con l'istruzione RETURN.
Tutte queste cose le avrei capite soltanto più tardi, quando cominciai a scrivere programmi in linguaggi più evoluti e strutturati, come il Pascal, dove le procedure sono implementate in una forma decisamente più rigorosa, al contrario delle subroutine del BASIC, che sono un po' raffazzonate, e usano solo variabili globali, non locali alla procedura. Di fatto, le subroutine del BASIC sono un caso molto particolare di procedura, che sarebbe possibile implementare obtorto collo anche con altri linguaggi di programmazione, ma solo se non ci sono proprio altre alternative percorribili.
Credo di non aver mai scritto una subroutine in BASIC, perlomeno non in modo corretto: magari usavo un GOSUB, ma non ho mai scritto il corrispondente RETURN da nessuna parte. Questo era solo dei tanti esempi che mi fecero comprendere, in realtà molto più avanti nel tempo, che anche se ci sono due cose che, all'apparenza, sembrano simili, devono per forza avere ognuna una loro peculiarità di cui tenere conto, perché altrimenti non ci sarebbe stata la necessità di avere due oggetti distinti. E questo, in senso lato, non vale solo nella programmazione: in generale, nella vita, bisogna considerare le singolarità di ogni persona e di ogni situazione, ed evitare di mettere delle etichette e dare un giudizio affrettato. Tornando però al punto di vista prettamente informatico, ne consegue che il programmatore deve approfondire il più possibile la sintassi e i casi d'uso di ogni istruzione, funzione o comando, leggendo tutta la documentazione che trova, che si spera sempre sia stata scritta in maniera chiara e completa, anche se purtroppo non sempre è così.
Diciamo che, tra esperimenti vari, la mia esperienza con il BASIC del MSX si fermò qui. All'inizio degli anni '90 sarei passato a un PC IBM, con molti più strumenti software a disposizione. Ma questa è un'altra storia.
(continua)



Commenti
Posta un commento