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 - cdimauro

Pagine: [1] 2 3 ... 270
1
Linguaggi - Programmazione. / Re:filesystem, bovini, e non
« il: 27 Febbraio 2015, 19:16:03 »
Diciamo che se / quando avrò tempo, e nessun altro c'avrà già pensato, avrei una mezza idea di brevettare il tutto.

2
Per un Tetris abbiamo discusso anche troppo. Troppissimo! ;D

Buttati e cominciare a scrivere codice: schermo unico, niente dual-playfield, e niente tile.

3
Linguaggi - Programmazione. / Re:filesystem, bovini, e non
« il: 27 Febbraio 2015, 18:38:01 »
Ricordo perfettamente com'è realizzata la struttura in questione. Non è niente di quelle che hai elencato finora, ma posso dirti che non ha sicuramente la complessità di un B*Tree (o di un B-Tree in generale), ma è un po' più complicato di una bitmap.

Però non mi sono mai posto il problema di farla crescere come file; se dovessi riprendere in mano la cosa, devo pensarci, perché può essere una gran comodità. Altrimenti tocca preallocare un po' di roba, come al solito.

4
Linguaggi - Programmazione. / Re:filesystem, bovini, e non
« il: 27 Febbraio 2015, 17:43:02 »
Ci stavo lavorando, ma poi ho abbandonato. Avevo definito su carta la struttura dei blocchi relativi a directory e file. Mentre a mente avevo elaborato un certo meccanismo per quanto riguarda l'allocazione e deallocazione dei blocchi.

5
Non c'è nessun quinto bitplane se hai intenzione di usare il dual-playfield: nei hai 4 (16 colori) per lo schermo dello sfondo, e altrettanti (ma 15 colori) per quello davanti. A questi si aggiungono poi gli sprite, che normalmente condividono la stessa palette del secondo schermo (davanti), ma che si possono "spostare" in altre zone della palette dei 256 colori. Questo per l'AGA.
Per l'ECS hai 3 bitplane per ogni schermo, quindi 8 + 7 colori, mentre gli sprite hanno una palette a sé stante.

Comunque dovresti definire intanto che tipo di gioco vuoi utilizzare (e da questo si capisce pure se deve andare a 50 oppure a 25Hz), e valutare se è il caso di usare il dual playfield, perché la qualità visiva si riduce drasticamente. Devi anche definire se vuoi realizzare un gioco per ECS o per AGA.

Fissati questi elementi, si può capire quanto spazio sarà a disposizione, e di conseguenza fare le prime valutazioni sul numero di tile, la loro dimensione, numero di colori, ecc.

6
Linguaggi - Programmazione. / Re:filesystem, bovini, e non
« il: 27 Febbraio 2015, 05:29:32 »
E' un casino. La soluzione migliore dovrebbe essere quella che le applicazioni supportino direttamente il concetto di metadata, per cui dovresti poter allegare un file a una mail, e l'applicazione automaticamente codifica anche i suoi metadati SE ce ne sono. E viceversa quando si riceve la mail. Però valli a convincere gli sviluppatori, che è già tanto se supportino il concetto di MIME...

7
Dipende da quanto dev'essere grande la mappa. Per USA Racing occupavano 128K e lo schermo virtuale era di 8192x65536 pixel, usando 1 byte (unsigned: 0..255) per ogni tile.

Per cui Simone non dovrebbe avere alcun problema ad adottare una soluzione simile. Anzi, la mappa DEVE essere più ridotta, altrimenti il giocatore impiegherà una vita per visitarne interamente una, e a lui ne servirebbero 100 per disegnarla.

A ogni tile sarà poi possibile associare una tabellina con gli attributi per definirne le caratteristiche (libera, bloccata, parzialmente bloccata, ecc.).

8
Linguaggi - Programmazione. / Re:filesystem, bovini, e non
« il: 26 Febbraio 2015, 20:51:50 »
Sì, ma il problema di cui parlano è generale, per tutti i filesystem che consentano l'uso di metadati per i file. Anche BFS ne sarebbe affetto. Immagina di mandare un file che sta su BFS via mail, come nell'esempio citato: i metadati si perderebbero ugualmente.

9
Linguaggi - Programmazione. / Re:filesystem, bovini, e non
« il: 26 Febbraio 2015, 20:42:17 »
E' senz'altro un bel filesystem, ma se ne dovessi implementare uno preferirei che fosse strutturato in maniera più semplice, e ovviamente con meno funzionalità.

Ai tempi dell'Amiga avevo iniziato a progettare la struttura delle directory e dei metadati, e avevo un'idea su come gestire l'allocazione e la deallocazione per velocizzare queste operazioni e ridurre la frammentazione, ma poi ho avuto altro da fare e ho lasciato perdere.

10
Linguaggi - Programmazione. / Re:filesystem, bovini, e non
« il: 26 Febbraio 2015, 20:27:46 »
Visto adesso:

Code license
New BSD License

:D

11
Linguaggi - Programmazione. / Re:filesystem, bovini, e non
« il: 26 Febbraio 2015, 20:24:03 »
@legacy: personalmente i progetti che ho pubblicato ho usato BSD, che è la più libera, e compatibile con praticamente qualunque altro progetto.

Poi dipende anche da cosa vuoi farci. Se vuoi farci soldi, rilascia il codice con doppia licenza GPLv3 e commerciale, così ti metti al riparo dagli avvoltoi e puoi farci business.

Vedi un po' tu cosa ti conviene fare.

12
Linguaggi - Programmazione. / Re:filesystem, bovini, e non
« il: 26 Febbraio 2015, 20:18:20 »
perche' NFS no ?
Più che un filesystem è un protocollo. Nella precedente azienda ho perso il conto di quanti casini abbiamo avuto a causa sua. :'(
Citazione
non ho capito che licenza, o meglio che problema c'e' ?
La GPL è virale, per cui ne limita la diffusione/adozione. Ormai da tempo c'è un generale rallentamento di questa tipologia di licenze proprio per questo motivo, e un'ascesa di quelle più permissive e commercial-friendly.

13
Linguaggi - Programmazione. / Re:filesystem, bovini, e non
« il: 26 Febbraio 2015, 20:12:22 »
NFS, però, non è un vero filesystem. :-\

Riguardo al Tiny Filesystem, peccato per la licenza.

14
Info su NSA - Annunci - Varie. / Re:Aggiornamento Server
« il: 26 Febbraio 2015, 16:34:13 »
Durante il periodo di downtime, vi fornirò notizie ed aggiornamenti tramite la pagina Facebook: https://www.facebook.com/pages/NonSoloAmiga
A me la pagina FB non funziona: mi dice "pagina non trovata". :-\

15
Desktop - All In One - Sistemi Fissi. / Re:Commodore C128D
« il: 25 Febbraio 2015, 19:15:54 »

Se gli ingegneri Commodore devono essere crocifissi, la giusta causa sarebbe rappresentata dal fatto che alle locazioni $FF00-$FF04 avevano mappato 5 registri dell'MMU, qualunque fosse le configurazione di memoria. Questo è SICURAMENTE fonte d'incompatibilità col Commodore 64, visto che in quell'area poteva essere mappata sia ROM (il Kernal) sia RAM, a seconda della configurazione selezionata.


Confermi se questo succede anche sul 128D.
Sì, l'hardware è lo stesso.
Citazione
Potrebbe trattarsi solo di un problema teorico che non si e' mai verificato in pratica. Nel senso che si dovrebbe individuare i titoli che effettivamente usavano quelle locazioni.
Esattamente. Se un gioco o applicazione utilizzava quelle locazioni, molto probabilmente non avrebbe funzionato o avrebbe bloccato il sistema (visto che l'MMU gestisce la mappatura della memoria).
Citazione
Da circa 2 anni e mezzo uso saltuariamente il C128D e finora non ho riscontrato nessun problema di compatibilita', sia con giochi che con applicazioni varie.
Beh, ci sono tantissimi giochi per Commodore 64, e non so quanti facciano specifico uso di quelle locazioni.

Pagine: [1] 2 3 ... 270