Questa l'avevo gia' raccontata ma ve la ripeto. 

Gennaio 1985, per il mio complenno mi fu regalato un C16 con il joystick e una cartuccia (costo + 0 - $150.00).  Dopo neanche due settimane ho riportato indietro il tutto (il negozio si chiamava Montgomery Ward che adesso esiste solo in internet) e l'ho scambiato con un C64 biscotto, un lettore C1541 e un paio di dischetti.  In aggiunta ho speso circa $300.00. 

Il C64 ce l'ho ancora.

quanto costavano all'epoca rispetto ad oggi non c'è veramente paragone

Citazione da: raistlin77it - 07 Gennaio 2016, 02:13:26

l'impossibilità di usare un dual-playfield con bitplane a scelta ,col 500  od il 1200 ho hai 2 playfield di 3 e 3 o 4 e 4 e basta, non si possono creare ad esempio 2 playfield da 1 e 3 bitplanes.

questo mi spiega un sacco di cose che non riuscivo a razionalizzare E mi pare una castronata tremenda di Miner!

eh purtroppo è una limitazione dell'usaro ide bitplanes, per fare un dual playfield il foreground è ad esempio formato dai bitplanes pari ed il background dai dispari
una cosa che mi fa impazzire è che gli sprites hanno colori uguali a coppie e nel caso di uno schermo a 32 colori, i colori dal 16 al 32 vengono usati anche per gli sprites.
non si può quindi avere uno schermo di 32 colori e sprites con colori diversi dalla palette dello schermo.

per non parlare che se devi visualizzare 4 sprite identici ti giochi 4 colori della palette (perchè devi metterli doppi)

ho trovato di recente questo tutorial

I COLORI DEGLI SPRITE

Per definire i colori degli sprite bisogna usare gli stessi registri colore
usati dai bitplanes, in quanto l'Amiga ha solo 32 registri colore.
I progettisti hanno pensato di far assumere agli sprites i colori dal
16 al 31, per cui se le figure non sono a 32 colori, ossia a 5 bitplanes, gli
sprites possono avere colori diversi dalle figure. Altrimenti gli sprites
avranno 16 colori in comune con la figura a 32 colori sottostante
....
Per quanto riguarda invece i colori (e anche altre proprieta`
degli sprite che vedremo successivamente, come per. es. le collisioni) gli
sprite non sono totalmente indipendenti ma sono accoppiati a due a due. Ci sono
dunque 4 coppie di due sprite: Sprite0+Sprite1, Sprite2+Sprite3,
Sprite4+Sprite5, ed infine Sprite6+Sprite7.
.....
Per i colori, bisogna tenere conto del fatto che gli sprite di una coppia
hanno i colori in comune, ossia ogni coppia di sprite ha la sua
palette (tavolozza) diversa da quella delle altre coppie.
Sappiamo che i 3 colori dello sprite 0 sono definibili coi registri COLOR17,
COLOR18 e COLOR19. Questi 3 colori valgono anche per lo sprite "fratello",
ossia lo sprite 1.
Ogni coppia ha una palette colori diversa perche' sono disponibili i registri
colore dal 16 al 31, ossia 16 registri.
Considerando che ogni sprite ha 4 colori (di cui 1 trasparente), servirebbero
8*4=32 registri, quando ne sono rimasti solo 16.
Dunque, avendo 8 sprites con 4 colori ciascuno ecco da quali registi le coppie
di sprite prendono i colori:


      Sprite   Valore binario   Registro di colore:
      ------   --------------   ------------------
Coppia 1:   0 o 1      00   Non Usato perche' trasparente
            01   Color17 - $dff1a2
            10   Color18 - $dff1a4
            11   Color19 - $dff1a6

Coppia 2:   2 o 3      00   Non Usato perche' trasparente
            01   Color21 - $dff1aa
            10   Color22 - $dff1ac
            11   Color23 - $dff1ae

Coppia 3:   4 o 5      00   Non Usato perche' trasparente
            01   Color25 - $dff1b2
            10   Color26 - $dff1b4
            11   Color27 - $dff1b6

Coppia 4:   6 o 7      00   Non Usato perche' trasparente
            01   Color29 - $dff1ba
            10   Color30 - $dff1bc
            11   Color31 - $dff1be

secondo me è perchè è veramente difficile programmare l'amiga.

per fare cose semplici la curva iniziale è ripidissima.

anche col blitz bisogna  quasi sempre passare a parti in assembler per fare qualcosa di leggermente diverso dal visualizzare un' immagine/2 bob in croce.

inoltre ci sono scelte che per per lo sviluppo vg non vanno proprio bene e fanno tribolare (anche se sono comode per un s.o.)


ecco quello che mi viene in mente così alla rinfusa :

come ad esempio l'impossibilità di avere una modalità charset/tileset come in tutte le console degli anni '80/'2000 (pure il c64 ce l'ha ed è di una comodità estrema)

il numero irrisorio di sprite : solo 8
ogni sprite ha solo 4 colori, a meno chè non si uniscano 2 sprite per averne 1 da 16, dimezzando il numero degli sprites

l'immagine degli prites poi va scritta appositamente quindi serve tempo per trasferire i dati, non si può semplicemente dare un puntatore alla struttura dati

la palette degli sprite che non è a parte, ma fa parte dei colori dello schermo
inoltre i colori sono assegnati a 2 sprite alla volta, perciò se voglio 4 sprite identici devo avere il doppio dei colori uguali per avere ad esempio 4 sprite colorati identicamente


l'impossibilità di usare un dual-playfield con bitplane a scelta ,col 500  od il 1200 ho hai 2 playfield di 3 e 3 o 4 e 4 e basta, non si possono creare ad esempio 2 playfield da 1 e 3 bitplanes.

se si usano schermi non standard , cioè con + di 320 pixels, parte degli sprites diventano inutilizzabili.

per non parlare di scrolling verticale , che per risparmiare banda e memoria, bisogna resettare i puntatori ai vari bitplanes in mezzo allo schermo, con conseguenti calcoli vari (oltre che l'indirizzamento dei bitplanes nonostante sia a 32 bit bisogna farlo 16 bit alla volta)

un'altra cosa che mi è capitata, dovendo convertire un'immagine è che molti colori erano sbagliati e questo perche ? perchè la palette del 500  ha un masimo di 4096 colri, vuol dire solo 4 bit per canale e quindi da 0 a 15, e perciò 255,240,2 diventa 15,15,0 ma anche 240,240,14 diventa 15,15,0.Da qui la differenza di colori tra l'immagine su pc e la stessa su amiga.

insomma per realizzare qualcosina che sia + di pacman ci vuole molto tempo ed un buono studio dell'hardware. non è immediato come possa sembrare, anzi spesso è un bordello

per rafforzare l'importanza del double buffering, viene usato tutt'ora , è uno degli "ABC" della programmazione 

i vari SDL_Flip o glSwapBuffers sono il pane quotidiano di chi programma qualsiasi cosa coinvolga la grafica.

Fidati, una volta imparato ad usarlo non ne farai più a meno ( che sia blitzbasic, opengl,sdl, freebasic, etceteramila linguaggi che coinvolgono un qualsiasi tipo di disegno grafico che viene aggiornato in tempo reale  ), è proprio la "base" minima per poter lavorare (addirittura ora spesso si usano 3 buffer al posto di 2 per dare una sensazione + fluida al gioco/animazione) 

Guarda, in realtà è una stupidata, ed è una tecnica che va bene per qualsiasi gioco
Ora ti spiego.

Prima di tutto ti crei 2 bitmap identici.

Visto che l'amiga non è molto veloce nel disegnare la grafica, devi ridurre il più possibile le cose da disegnare a schermo ogni 50 secondi.

perciò come prima cosa disegni su tutti e 2 i bitmap quelle parti dello schermo del gioco che di sicuro non cambiano mai, come ad esempiol'area di gioco, la parte col prossimo pezzo, la scritta score etc etc.

Ti ho fatto un mockup con immagini prese da internet



una volta che hai i 2 bitmap uguali, mostri l'uno e disegni sull'altro

con questo codice

 Buffer 0,16384
 Buffer 1,16384
 bm.b=0


---------------- loop ---------------
 DisplayBitMap 0,bm,0,0

 bm=1-bm
 UnBuffer bm
 Use BitMap bm

 Gosub logica_del_gioco
 Gosub disegna_qualcosa
------------- end loop -------------

Allora cosa succede, prima di tutto ti crei 2 buffer (rispettivamente lo zero e l'uno) dove il blitz andrà a salvare la parte del bitmap che andrai a coprire con quello che disegnerai, in modo poi da poter cancellare le modifice e tornare al bitmap originale .

Dopodichè ti crei una variabile bm che indica il bitmap che vuoi mostrare ( da notare che 1-bm oscilla tra 0 e 1 e quindi a turno ti mostra la bitmap 0 o 1)

nel loop:

al momento 0 :
- mostri la bitmap bm ( in questo caso la zero) -----> DisplayBitMap 0,bm,0,0
- cambi la bitmap sulla quale disegni                -----> bm=1-bm (quindi sulla bitmap 1 )
- cancelli tutte le cose disegnate precedentemente nel buffer -------> UnBuffer bm (quindi sul buffer 1 anche se non abbiamo disegnato ancora niente perchè siamo al momento zero)
- usi la nuova bitmap (la 1 per disegnare ) ----->  Use BitMap bm
- vai alla routine di logica e poi a quella di disegno

al momento 1 :
- mostri la bitmap bm ( ora è diventato uno ) -----> DisplayBitMap 0,bm,0,0
- cambi la bitmap sulla quale disegni                -----> bm=1-bm (quindi ora sulla bitmap zero )
- cancelli tutte le cose disegnate precedentemente nel buffer -------> UnBuffer bm (quindi sul buffer 0 )
- usi la nuova bitmap (la zero per disegnare ) ----->  Use BitMap bm
- vai alla routine di logica e poi a quella di disegno

al momento 2 :

- mostri la bitmap bm ( ora la zero ) -----> DisplayBitMap 0,bm,0,0
- cambi la bitmap sulla quale disegni                -----> bm=1-bm (quindi ora sulla bitmap uno  )
- cancelli tutte le cose disegnate precedentemente nel buffer -------> UnBuffer bm (quindi sul buffer 1 perchè poi ci andrai a disegnare e ti serve lo schermo pulito dalle mosse precedenti )
- usi la nuova bitmap (ora la uno per disegnare ) ----->  Use BitMap bm
- vai alla routine di logica e poi a quella di disegno


e così all'infinito

in pratica, mentre mostri una schermata in quella nascosta prima cancelli le modifiche precedenti, poi ridisegni le modifiche attuali.





Edit: nell'immagine naturalmente la parte sinistra è quella che si vede a schermo, mentre la destra è la parte nascosta


spero di essermi spiegato  abbastanza bene ^^', al massimo chiedi

Edit 2 : ci saranno poi altri problemi da risolvere + in là, perchè ad esempio i pezzi che cadono sul fondo, non dovresti ridisegnarli sempre, ma solo quelli in movimento
ma prima vedi se funziona il doublebuffer

256 colori sono comunque tanti. Su Amiga solitamente si andava dai 4 ai 32 colori generalmente, per occupare meno memoria.

per quello poi passo l'iff a ppaint , perchè PSP salva solo  a 256 colori

come no! io me lo ricordo,, vendevano anche dei pupazzi che in qualche modo reagivano alla puntata e potevi sparare o venire distrutto dalla puntata del telefilm (almeno così mi ricordo la pubblicità, ora cerco se la trovo )

ho trovato un link interessante

http://docmanhattan.blogspot.it/2011/06/capitan-power-e-i-combattenti-del.html

Gli utili si calcolano senza iva, per cui quando vengono tassati ti portano via un bel fettone.
Semplicemente la tassazione potrebbero farla al 10% sugli utili ora siamo sul
40% poi varia per alcuni fattori di quote tra i soci che non ho ancora capito precisamente.
Anche l'imprenditore di lavoro su quello che vende paga l'Iva del 22% allo stato.
Per non farti derubare dallo stato sugli utili tutti cercano di non farli spendendo per l'azienda.
Pr questo motivo esistono le macchine aziendali, telefonini, computer, ecc...

ops si hai ragione, avevo capito male io,pensavo ti riferissi all'iva sul prodotto venduto.