Visualizza post

Questa sezione ti permette di visualizzare tutti i post inviati da questo utente. N.B: puoi vedere solo i post relativi alle aree dove hai l'accesso.


Post - raistlin77it

Pagine: 1 [2] 3 4 ... 15
16
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 :)

17
leggendo una delle varie discussioni su EAB,mi è venuta voglia
di aprire questo topic, così per sfizio :)

in che anno avete comprato il primo pc? (inteso come personal computer)
e quanto lo avete pagato?


io mi ricordo il natale dell'88 non ricevetti nessun regalo perchè tutti i miei parenti
si erano uniti nel regalarmi il c64+datasette.

mi ricordo ancora i primi 2 giochi per c64,un clone di defender , comprato originale in inglese, col manuale in inglese, ma qualche frase tradotta da mio padre, e oink! un gioco stranissimo con un maiale come protagonista.

mi ricordo solo che l'anno dopo comprai con le paghette + i soldi del compleanno un floppy per c64 allo strabiliante costo di 270.000 lire !!!!!!!!!!!!!!!!!! ( e non era nemmeno quello commodore originale )

un dissanguamento, però cavolo col turbo loader e i giochi pirata in due minuti giocavo, mentre prima, per il solo bubble bobble, lanciavo il gioco, andavo a pranzo e finito di pranzare era appena partito lo schermo di avvio ;) , giocavo 4 partite e poi via con i compiti :):)

le vostre esperienze?


18
AmigaOS 1.0 - 3.x / Re:Il retrolaboratiorio di EAB
« il: 12 Gennaio 2016, 22:12:10 »
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 :)


Citazione
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

19
AmigaOS 1.0 - 3.x / Re:Il retrolaboratiorio di EAB
« il: 10 Gennaio 2016, 14:32:54 »
si ma non puoi paragonare chi i igiochi li faceva di mestiere, con chi lo fa per hobby.
ad esempio solid gold o i porting da nes di asman sono fatti bene
tales of gorluth mi pare bello.

non  tutti sono manfed trenz. la scena si stà muovendo,l'importante è quello

20
AmigaOS 1.0 - 3.x / Re:Il retrolaboratiorio di EAB
« il: 07 Gennaio 2016, 02:13:26 »
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 :)


21
Ok a proposito di programmazione io sto ragionando ancora a livello Spectrum 48k e BASIC, quando il linguaggio era cosi leeeeento che non conveniva controllare tutti gli elementi sullo schermo ma solo alcuni (magari avrebbe ancora senso facendo uin platform); mi sono immaginato un pseudocodice del genere per come implementare il double buffering in quel tetris:

Codice: [Seleziona]
initialize bitmap 0  and 1

a var that points the bitmap id
id=0
first cycle

write on 0
show 0
id+=1
write on 1
show 1
id = 0
write on 0
etc.

si si l'idea è quella :)

22
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) 

23
eh no :)

devi disegnare prima su una bitmap e poi sull'altra, perchè sennò che double-buffer sarebbe ?

anche perchè se disegni sempre su una bitmap, l'altra sarebbe vuota ;)

l'idea del double-buffering è proprio che mentre mostri una cosa, ne disegni un'altra dall'altra parte, in modo che non vedi il "flickering" del ridisegno, sennò non avrebbe senso :)


24
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 ;)

25
non c'è uno strumento di color reduction? se si, puoi provare a fare Color Reduction / Color Quantization prima dell'esportazione.
no no, anche se hai un'immagine a 4 colori la iff la salva in 256 (è comunque un programma vecchio) :)

26
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 :)

27
C'è anche un programma abbastanza vecchietto ma ancora efficace di Ulead che può farlo, mi pare sia Ulead proto espresso 2.0

c'è anche paint shop pro 7 per win che salva in iff (sempre e solo a 256 colori). E' un po' vecchiotto, ma io lo uso lo stesso e mi dà molte soddisfazioni (poi ritocco la .iff in PPaint)

28
Film - SerieTV - Anime - Documentari. / Re:Telefilm Capitan Power
« il: 11 Maggio 2015, 01:28:50 »
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

29
io mi sono preso Pillars of Eternity
è veramente spettacolare :)

http://eternity.obsidian.net/

30
AmigaOS 4.x / Re:bancarotta lampo per Hyperion entertainment
« il: 03 Aprile 2015, 07:52:46 »
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.


Pagine: 1 [2] 3 4 ... 15