Entombed è un gioco per Atari 2600 che nessuno sa come è stato programmato

[Redazione di Hardware Upg]

Link alla notizia: https://gaming.hwupgrade.it/news/vid...ato_90168.html

Esistono dei veri e propri "archeologi" digitali che studiano le tecniche di sviluppo dei vecchi giochi per le console Atari mirate a eludere gli stringenti limiti degli hardware di allora. Uno in particolare ha richiesto degli studi molto approfonditi...

Click sul link per visualizzare la notizia.

[astaroth2]

4kbytes si e no di codice da esaminare. Ammazza! Avrebbero messo in ginocchio anche denuvo questi qui.

[LORENZ0]

"Lo ha creato mentre era ubriaco e il suo cervello in panne. Quando è tornato sobrio non si ricordava più come aveva fatto" ha detto Sidley alla BBC."

Vi sta pigliando per i fondelli, #sapevatelo
(e fa bene!)

[hrossi]

Originariamente inviato da LORENZ0

"Lo ha creato mentre era ubriaco e il suo cervello in panne. Quando è tornato sobrio non si ricordava più come aveva fatto" ha detto Sidley alla BBC."

Vi sta pigliando per i fondelli, #sapevatelo
(e fa bene!)

giustissimo, altrimenti risalire al programmatore sarebbe stato semplicissimo, invece anche questa informazione è andata persa tra i fumi della perculata

[mail9000it]

Sono così tanti anni che nessuno fa ottimizzazione nello sviluppo che si è perfino persa conoscenza del concetto (per non parlare delle tecniche) e occorre studiarsi il software di 30 anni fa.

Il triste è che lo vedo anche con il software applicativo, non c'è la minima attenzione alle prestazioni. Esempio lampante: due select consecutive su due tabelle diverse invece di utilizzare una join per avere i due valori con una sola select.

Imbarazzante.

[supertigrotto]

È quello che sostengo da anni,i vecchi programmatori erano più bravi e creativi di quelli moderni,dovevano scervellarsi per far funzionare bene un programma con pochi kb.
Con i tempi moderni e le potenze messe a disposizione,il programma risulta veloce anche se programmato con i piedi.

[Saturn]

Originariamente inviato da astaroth2

4kbytes si e no di codice da esaminare. Ammazza! Avrebbero messo in ginocchio anche denuvo questi qui.

[jepessen]

Originariamente inviato da supertigrotto

È quello che sostengo da anni,i vecchi programmatori erano più bravi e creativi di quelli moderni,dovevano scervellarsi per far funzionare bene un programma con pochi kb.
Con i tempi moderni e le potenze messe a disposizione,il programma risulta veloce anche se programmato con i piedi.

Quindi se non programmano in assembler sono degli sfigati? Se gli architetti non progettano una casa sistemando ogni singolo mattone invece di utilizzare un CAD apposito e' pure uno sfigato? E magari se sei un ingegnere elettronico se non metti tu ogni singolo transistor il circuito fa cagare... Ogni generazione utilizza i tool piu' avanzati di cui dispone, esattamente quale sarebbe il problema?

[jepessen]

Originariamente inviato da mally

peccato che qui > https://en.wikipedia.org/wiki/Entombed_(Atari_2600) ci sia la spiegazione di come funziona il sistema di generazione del labirinto

Esattamente come dice l'articolo, la pagina wiki dice che viene utilizzata una look-up table, ma come hanno fatto a generarla e perche' funziona sempre ancora non e' chiaro. Esattamente cosa dice di diverso questa pagina?

[jepessen]

Originariamente inviato da mally

poi la storia non ha alcun senso, anche scrivendo codice sotto stato di alterazione il sorgente resta, non è che si trasforma magicamente in compilato e non si puo' piu' leggerlo...

Per prima cosa, i sorgenti non sono disponibili, hanno analizzato direttamente il binario. In seconda battuta, i giochi si programmavano in assembler, quindi non e' che era molto diverso dal codice binario, a parte i commenti che potevano chiarire un po' di cose, ovviamente solamente se c'erano.

[Giuss]

Se stai lavorando a un programma in C e vai a fare il debug di una parte direttamente in assembler ci sta, può capitare.

Interpretare da zero un programma non scritto da te e dissassemblato dal linguaggio macchina secondo me può essere ben più problematico.

[!fazz]

Originariamente inviato da mally

l'assembler non è binario e nell'automazione industriale capita di controllare cosa ha combinato il compilatore C. Un firmwareista con buona competenza non ha grossi problemi a spiegarti come funziona l'algoritmo...

non è binario ma spesso cè una correlazione 1-1 tra codice assembler e codice binario tanto che si può passare da uno all'altro con un semplice libro dei vari opcode, ovviamente su cpu relativamente semplici, l'ho fatto mille volte su z80 e 8086 e se l'algoritmo non è più che semplice ti assicuro che non è facile capire cosa fa partedo solo dall'assembler, soprattutto se il codice viene ottimizzato da un buon compilatore tipo iar

[LORENZ0]

Originariamente inviato da jepessen

Quindi se non programmano in assembler sono degli sfigati? Se gli architetti non progettano una casa sistemando ogni singolo mattone invece di utilizzare un CAD apposito e' pure uno sfigato? E magari se sei un ingegnere elettronico se non metti tu ogni singolo transistor il circuito fa cagare... Ogni generazione utilizza i tool piu' avanzati di cui dispone, esattamente quale sarebbe il problema?

Non ha colto assolutamente il succo del discorso. L'utente di prima ritengo intendesse dire che, 30-40 anni fa, erano OBBLIGATI a scervellarsi e OTTIMIZZARE le righe di codice per una serie di evidenti fattori quali le potentze in gioco e le memorie. Oggi, invece, si "crogiolano spesso sugli allori" in forza del fatto che tanto le CPU/GPU sono di una potenza "disumana" e che lo spazio abbonda. Tolte quelle due basi (ottimizzazione e linearità), va tutto a ramengo. Ciò non toglie che, anche oggi, saltino fuori ottimi giochi/software, ma spesso e volentieri essi non sono ottimizzati e lineari perchè..e qui torniamo al mio discorso iniziale. Il tutto è indipendente dal fatto di usare transistor o schede elettroniche oppure un CAD digitale in luogo del tecnigrafo: conta la mentalità e la voglia di ottimizzare risorse, codice e tutto il resto...
Come al solito, torniamo sempre al solito nodo: quando si era OBBLIGATI perchè o si faceva così o non si riusciva, era normale avere una certa logica di lavoro, oggi, avendo maggior libertà, non si attribuisce la giusta importanza a certe cose, vuoi per pigrizia, vuoi per comodità, vuoi perchè è tutto più veloce (nel senso che ciò che esce oggi, domani è già vecchio), vuoi perchè è tutto focalizzato al guadagno, ai soldi e c'è sempre qualcuno alla dirigenza che non ne capisce una mazza di ciò che sta dirigendo ed attribuisce ordini "ad minchiam".
Se io sono nostalgico? Assolutamente sì! E ritengo si lavorasse meglio un tempo (in tutti i settori), fermo restando che la tecnologia raggiunta oggi è un qualcosa di meraviglioso.

[GaryMitchell]

Originariamente inviato da jepessen

Per prima cosa, i sorgenti non sono disponibili, hanno analizzato direttamente il binario. In seconda battuta, i giochi si programmavano in assembler, quindi non e' che era molto diverso dal codice binario, a parte i commenti che potevano chiarire un po' di cose, ovviamente solamente se c'erano.

Assembly.

L'assembler non e' un linguaggio e' un compilatore.

[biffuz]

Originariamente inviato da jepessen

Quindi se non programmano in assembler sono degli sfigati? Se gli architetti non progettano una casa sistemando ogni singolo mattone invece di utilizzare un CAD apposito e' pure uno sfigato? E magari se sei un ingegnere elettronico se non metti tu ogni singolo transistor il circuito fa cagare... Ogni generazione utilizza i tool piu' avanzati di cui dispone, esattamente quale sarebbe il problema?

Per fare un esempio in termini architettonici, è come se un architetto costruisse un palazzo di dieci piani ma con spazi abitabili pari a quelli di un bilocale, solo perché oggi costruire costa meno rispetto all'800.

[davide3112]

Originariamente inviato da mally

peccato che qui > https://en.wikipedia.org/wiki/Entombed_(Atari_2600) ci sia la spiegazione di come funziona il sistema di generazione del labirinto

esatto... quindi genera la stringa "data" per la rappresentazione grafica linea per linea in tempo reale (o quasi, data la velocità dei processori dell'epoca). Chi ha avuto i primi rudimenti di programmazione passando per il Basic si ricorderà questa tecnica. Direi che il problema è prorpio qui. Chi scrive codice al giorno d'oggi non si preoccupa più di tanto di ottimizzare o a studiare tecniche di parcheoinformatica... tanto le risorse di calcolo che mettono a disposizione le macchine attuali possono agevolmente sopperire.
Mi stupisce di più che "ricercatori" blasonati si siano trovati in difficoltà, e questo la dice lunga. Nel trentennio dal '70 al '90 i pionieri della programmazione moderna hanno dovuto fare i conti con risorse macchina risicatissime rispetto le attuali (gettando le basi dei principali linguaggi di programmazione attuali). Oggi hanno vita comoda. Peraltro parlando di giochi, ma non solo, gli engine grafici tutt'ora in voga si basano e sviluppano su algoritmi che hanno avuto origine 20 o 30 anni fa... il chè è tutto un dire.

[davide3112]

Originariamente inviato da jepessen

Quindi se non programmano in assembler sono degli sfigati? Se gli architetti non progettano una casa sistemando ogni singolo mattone invece di utilizzare un CAD apposito e' pure uno sfigato? E magari se sei un ingegnere elettronico se non metti tu ogni singolo transistor il circuito fa cagare... Ogni generazione utilizza i tool piu' avanzati di cui dispone, esattamente quale sarebbe il problema?

Programmano in assembly... assembler è il compilatore.
Non hai colto il ragionamento. Utilizzare i tools più avanzati è il mezzo, non il fine. Per progettare un palazzo utilizzi il CAD che è solo lo strumento, l'idea e l'ingegno sono esercizio dell'intelletto umano e sono loro a fare la differenza e portare il risultato all'eccellenza. Quello che succede aggigiorno è che spesso si trascura la "raffinazione" che solo l'ingegno umano, almeno per ora, può elaborare. la macchina è solo il mezzo... potentissimo, talmente potente che spinge l'uomo alla "pigrizia" se così vogliamo dire, accettando un risultato che troppo spesso non viene portato all'eccellenza. Poi si possono addurre un sacco di giustificazioni (rispetto di tempi, costi, specifiche, ecc, ecc...). In tal senso ci sono un sacco di esempi sotto gli occhi di tutti...

[gsorrentino]

La questione non è che non si è capito come funziona il programma.

La questione è che il programma usa un metodo basato su una tabella che non è chiaro come sia stata pensata.

Quando ero giovane ho fatto dei programmi assembler su Sinclair ZX80 che ero riuscito a riparare ed espandere da solo vedendo gli schemi elettrici.

Poi è arrivato lo Spectrum con i suoi colori ed un basic semplice.
Per capire le potenzialità creai una copia del poker che andava di moda nei bar a quei tempi. Il problema era che le immagini delle carte occupavano troppo, così creai un metodo per disegnarle con i mattoncini della grafica del testo e allo stesso tempo creai un sistema di verifica del punteggio delle carte che avevi sullo schermo.
Il sistema capiva qual'era la tua mano con solo 6 righe di codice.

A distanza di quasi 40 anni ho ritrovato il codice (lo avevo scritto a mano su un blocco) e pur leggendolo, non riesco a capire completamente l'intuizione di allora che mi permise di creare quelle righe che con soli 4 confronti erano in grado di dirti cosa avevi in mano (dalla semplice coppia alla scala reale).

[LMCH]

Originariamente inviato da gsorrentino

La questione non è che non si è capito come funziona il programma.

La questione è che il programma usa un metodo basato su una tabella che non è chiaro come sia stata pensata.

Ancora adesso in ambito embedded uso molto spesso le lookup table per rimpiazzare chiamate a funzioni o "foreste di if-then-else".

In questo caso è sufficiente analizzare come viene composto l'indice per selezionare di volta in volta un elemento della tabella.

In pratica, invece di fare una serie di confronti con successivi salti condizionali per decidere lo stato della prossima cella si compone un indice e si referenzia un valore precalcolato che corrisponde alla scelta finale che si raggiungerebbe facendo i confronti tra i valori che compongono l'indice.

Quello che probabilmente confonde i tipi che hanno analizzato il codice è che chi ha codificato la lookup table, aveva individuato i casi in cui certamente doveva esserci vuoto oppure muro, ma aveva poi lasciato "a scelta pseudo casuale" i casi in cui poteva andar bene sia vuoto che muro.

[TRF83]

Originariamente inviato da gsorrentino

La questione non è che non si è capito come funziona il programma.

La questione è che il programma usa un metodo basato su una tabella che non è chiaro come sia stata pensata.

Quando ero giovane ho fatto dei programmi assembler su Sinclair ZX80 che ero riuscito a riparare ed espandere da solo vedendo gli schemi elettrici.

Poi è arrivato lo Spectrum con i suoi colori ed un basic semplice.
Per capire le potenzialità creai una copia del poker che andava di moda nei bar a quei tempi. Il problema era che le immagini delle carte occupavano troppo, così creai un metodo per disegnarle con i mattoncini della grafica del testo e allo stesso tempo creai un sistema di verifica del punteggio delle carte che avevi sullo schermo.
Il sistema capiva qual'era la tua mano con solo 6 righe di codice.

A distanza di quasi 40 anni ho ritrovato il codice (lo avevo scritto a mano su un blocco) e pur leggendolo, non riesco a capire completamente l'intuizione di allora che mi permise di creare quelle righe che con soli 4 confronti erano in grado di dirti cosa avevi in mano (dalla semplice coppia alla scala reale).

Come accade sempre
"Quando ho scritto quel codice, solo io e Dio sapevamo come funzionasse.
Oggi lo sa solo Dio"