Menů principale
 Notizie
 Grafica
 Forum
 Links
 Retro Trailer
 Recensioni
 Modelli Amiga
 Storia Amiga
 Retro-Gamers
 Lista Utenti
 Contatti
 Policy sito
Ricerca Google

Login

Nick


Password


31 Gennaio 2020 Postato da: AMG_Novice_Usr
Risoluzioni video, palette, Denise e ... HAM
Buonasera,
ho una domandina di cultura generale sul mondo Amiga:

ho letto che su Amiga (questo è un discorso molto generale, non so scendere in dettagli e distinguere fra OCS, ECS, AGA, e le rispettive Denise) il sistema riesce a stampare a video un certo sub-set di colori, ad esempio 16 colori (è solo un esempio), attinti da un super-set di 4096 colori (quindi una palette completa a 12 bit).

Se aumento la risoluzione, passando per esempio da 320 x 256 a 640 x 512, il sistema non è più in grado di stampare un massimo di 16 colori per ciascun pixel, ma al massimo ne può stampare 8 (è solo un esempio).

Ecco, vorrei capire anzitutto il motivo di questa cosa.

Io, che possiedo una quantità di nozioni tendente a zero, provo a fare un ragionamento a spanne/a buon senso … ditemi e, soprattutto, correggetemi:

mettiamoci sotto le ipotesi più semplificative possibili, per non appesantire inutilmente la discussione e centrare subito il cuore di tutto.

Le ipotesi sono:
1 – possiamo trascurare l’overscan, e tutto ciò che ne consegue, quindi non preoccupiamoci dei front e back porch sia lungo H che lungo V, facciamo finta che le tempistiche di scansione del pennello elettronico all’interno dei front e back porches sia trascurabili … contano solo le tempistiche dei pixels visibili, quindi tutto si svolge dentro il canvas visibile;
2 – nessun interlacciamento, quindi abbiamo 50 schermi al secondo di frame-refresh;
3 – il frame-rate deve sempre essere costante, pari a 50Hz (quindi ogni 20ms abbiamo un frame), a prescindere dalla risoluzione: che sia 320 x 256 oppure 640 x 512, il frame-rate rimane sempre 50Hz.

Bene, detto ciò, ecco l’idea che mi sono fatto:

con una risoluzione bassa, ovvero 320 x 256, abbiamo N pixels di cui il pennello elettronico, insieme al clock che dalla porta RGB-DB23 va verso il CRT, si deve occupare: il pennello elettronico deve sedersi su ciascuno di questi N pixels, qualcuno deve “generare” (Denise? Vero?) le 3 tensioni analogiche RGB sui 3 piedini RGB analog della porta RGB-DB23, questo durante un dot-clock-periodo, poi abbiamo un altro dot-clock-periodo, durante il quale queste 3 RGB-tensioni devono spegnersi (immagino che vadano a GND tutte e 3 … o no?), per poi riaccendersi con la configurazione propria di questo pixel successivo, per poi essere latchate, ecc … ecc … (correggete le inesattezze … ce ne saranno tante!).
Diciamo che il tempo che il pennello elettronico può dedicare ad ogni pixel è circa 20ms/N.

In questi 20ms/N, Denise deve:

1) accedere, tramite uno dei 25 canali DMA messi a disposizione da FatAgnus, alla corrente locazione di chip-ram nella quale è scritto il pixel corrente appunto, quello che sta per essere stampato su CRT (magari detto così è forviante, direi che Denise non accede, forse è il canale DMA di FatAgnus ad accedere, come “source” avrà la locazione del pixel attuale in chip-ram, come “destination” avrà l’opportuno registro dentro Denise);
2) dare in pasto la parola RGBxyz (RGB444? RGB565? La palette di 4096 colori suggerirebbe RGB444 …) ai 3 DAC interni a Denise;
3) dare il tempo ai DAC di generare stabilmente le tensioni cromatiche;
4) chissà cos’altro ...

Bene, se adesso abbiamo una alta definizione, supponiamo di 640 x 512, vuol dire che abbiamo 4 volte i pixels di prima, quindi il pennello può stare seduto su ciascun pixel per un tempo pari a circa 20ms/4N.
Dato che il pennello deve sbrigarsi su ogni pixel, forse alcune operazioni, che consentirebbero di produrre 16 colori presi dalla palette di 4096, devono essere svolte in modo diverso, più asciutto, da qui la possibilità di produrre meno colori (es: 8, 4 … non so).

Vorrei sapere come stanno davvero le cose …

Ultimo punto:

mi sembra di aver capito (magari anche qui sbaglio) che esiste una tecnica inventata da Jay Miner, chiamata HAM, ovvero Hold and Modify, grazie alla quale è possibile (non so a che definizioni, o se a tutte le definizioni) attingere a tutta la palette di 4096 colori, per ciascun pixel, forse con qualche limitazione (il pixel k+1-esimo non può avere un colore del tutto scorrelato dal colore del pixel k-esimo). È giusto? Questa limitazione forse è figlia del concetto di “mantieni e modifica”? Ma cosa viene mantenuto e soltanto modificato? Le 3 RGB-tensioni non vengono spente nel passaggio da un pixel al successivo, subiscono solo un mascheramento dentro Denise, quindi una modifica? Cosa sono esattamente HAM6, HAM8 ecc … ?

Grazie in anticipo a chi vorrà illuminarmi/illuminarci 😊


Commenti: 12  Aggiungi  - Leggi

Indice: forum / Richieste di Aiuto


Post inviati: 1588

Visulizza profilo Messaggio Personale
79.37.211.*** Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0
Commento 1
majinga 31 Gennaio 2020    20:27:25
Troppo complicato per me, magari aspetta qualche programmatore amiga, loro sicuramente te lo spiegano meglio.

Ma in genere lemoria video è fissa. Se aumenti la risoluzione aumenti il numero di pixel di cui devi salvare le informazioni, e quindi te ne resta di meno per cose come i colori.

Anche sull'HAM, qualcuno ti risponderà meglio di me. Ma ricordo di aver letto qualcosa a riguardo.
Miner aveva in mente un normale segnale video NTSC, dove si hanno due segnali, la luminanza, che indica quanto il pixel deve essere brillante, e la crominanza che indica il colore, in un segnale video del genere, basta variare nel tempo il solo parametro cambiare colore al pixel.
In un segnale RGB invece devi cambiare l'intensità di tutti e tre i colori per generare il colore che desideri, quindi devi modificare tre valori, uno per il rosso uno per il verde e uno per il blu.
Almeno questa è la parte che ricordo io. Magari faccio anche confusione.
La differenza è proprio nell'hardware che genera il segnale video, e come lo genera.

Ci sono trucchi abbastanza bizzarri sulle schede video di una volta, i computer inizialmente lavoravano tutti basandosi su segnali video abbastanza standard.
Se ti fai una ricerca sulle vecchie schede CGA è incredibile cosa riuscivano a tirare fuori sfruttando il modo in cui venivano interpretati e mescolati i colori nello standard NTSC.

AfAOne

Post inviati: 5887

Visulizza profilo Messaggio Personale
95.238.251.*** Mozilla/5.0 (Windows NT 6.1; rv:72.0) Gecko/20100101 Firefox/72.0
Commento 2
AfAOne 31 Gennaio 2020    20:58:05
Anche io non sono molto ferrato su questo argomento e potrei sbagliare, QUI ci sono delle interessanti info sull'argomento

Immagine AROS One x86/68k
- AfA One - AfA One PPC - Amilator AfA One - Amithlon AfA One - WinUAE OS 4.1


Pegasus RyuSei Ken

Post inviati: 10185

Visulizza profilo Messaggio Personale
87.1.250.*** Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36
Commento 3
Seiya 31 Gennaio 2020    21:07:57
Su Amiga si programma solitamente in dual o più playfield e questo porta a vedere su schermo meno colori, ma in realtà sono sempre quelli. Ad esempio su tu fai un gioco per A500 a 32 colori programmato in un solo playfield li vedi tutti. Ma se tu programmi in dual playfield i colori sono sempre 32, ma divisi tra ciascuno di essi.
C'erano discussioni in passato, ma anche recentemente del fatto che molti giochi DOS in VGA a 256 colori erano più colorati della versione AGA Amiga. Analizzando in dettaglio il software è venuto fuori che il gioco dos era programmao con 1 solo playfild, mentre su Amiga in dual playfield. I colori sono sempre 256 ma sembrano di meno perchè se il massimo è 256 e programmi in quel modo, puoi avere 100 colori nel primo playfield e 150 nel secondo, oppure 64 nel primo e di più nel secondo.


Amiga rispetto ai PC di allora era molto più facile programmare in questo modo e quindi solitamente si lavorava così. Ci vari casi, ma uno in particolare che mi viene in mente ora e in cui lo si nota: Soccer Kid

Post inviati: 7752

Visulizza profilo Messaggio Personale
37.161.250.*** Mozilla/5.0 (Linux; Android 7.0; HUAWEI VNS-L31) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Mobile Safari/537.36
Commento 4
DanyPPC 1 Febbraio 2020    06:49:49
La modalità HAM ti permette di avere i 4096 colori su schermo ma con un limite sulla sfumatura ogni 3 pixel orizzontali.
Il modo Half Bright ti consente di usare 64 colori ma con 32 che devono essere sfumature dimezzate dei primi 32.

Sommariamente questo dipende, come già ti hanno spiegato, dalla memoria dedicata alla grafica e dal numero di bitplane (6) disponibili com il chipset ECS.

A1200T OS3.9 BB4 PPC 240/060/256MB/BVision/IndivisionAGA MK2cr/BMon Switch/HD 80GB/DVD-RW/Drive 1,76Mb/Honey Bee CD32 Pad

A1200 OS3.9 BB4 ACA030/42/128MB/CF8GB/PCMCIA 4GB/PSX Adapter

A1200 OS3.1.4 030/50/64MB/CF16GB/PCMCIA 4GB/PSX Adapter

A1200 OS 3.1 2MB

A600 OS2.0 2MB/Gotek/Sega Pad

Pegasus RyuSei Ken

Post inviati: 10185

Visulizza profilo Messaggio Personale
87.1.250.*** Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36
Commento 5
Seiya 1 Febbraio 2020    11:11:48
ops, allora avevo capito male io.

utente amiga quadratico medio

Post inviati: 701

Visulizza profilo Messaggio Personale
79.51.61.*** Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko
Commento 6
AMG_Novice_Usr 1 Febbraio 2020    12:51:30
Ciao,
si, ho letto la spiegazione su HAM (HAM6 per OCS ed ECS, HAM8 per AGA) fornita da Wikipedia … il concetto del pixel di "base", lungo una certa linea
orizzontale, che imposti in questo modo (HAM6):
2 bit di controllo / 4 bit di dati-colore
Facciamo un esempio:
voglio colorare il primo pixel in alto a sinistra, quindi il primo pixel della prima riga.
Credo che sia Denise/Lisa a ricevere, tramite un canale DMA messo a disposizione da Agnus/Alice, un byte proveniente dal frame-buffer grafico,
che si trova in chip-ram … un byte siffatto:
binario: xx00/CCCC
xx = don't care;
00 = comando di "attingi ad uno dei 16 colori di base", in questo caso il colore è "CCCC";
CCCC = uno dei 16 colori di base.
Per cui abbiamo quel certo colore CCCC sul primo pixel: il pixel di base (che da inizio ad un segmento di una riga), a mio parere, ha una forza
ed una debolezza: la "forza" consiste nel decidere lo "stampo", la "linea guida" del segmento-sfumatura da lui iniziato, è lui a dare un primo
imprinting cromatico al segmento di linea (giusto?), però ha anche la "debolezza" rappresentata dal fatto che quel pixel può attingere ad una
tavolozza di soli 16 colori … è un pixel grezzo.
Adesso voglio colorare il pixel immediatamente contiguo, successivo al primo.
Denise riceve il byte:
xx01/BBBB
01 = è un comando che impone a Denise di lasciare, sul secondo pixel (il pixel dove attualmente si è spostato il pennello elettronico),
inalterate le componenti RG del colore "grezzo" del pixel precedente, e di modificare solo la componente blu, con un valore:
BBBB
Quindi il secondo pixel ha anche lui una forza ed una debolezza:
la forza è che possiamo attingere, su quel secondo pixel, ad una tavolozza di 256 colori … giusto? 16 x 16 … io se voglio sul secondo pixel una
particolare sfumatura di rosa, posso colorare il byte 1, in chip-ram, che ospita appunto il primo pixel, con uno dei 16 colori che "meglio avvia"
quel particolare rosa che ho in animo di ottenere sul secondo pixel (quindi il primo pixel è propedeutico per il secondo), e poi devo colorare il
byte 2, in chip-ram, contiguo come address al primo byte, con una particolare modifica blu del primo colore-pixel, quindi torna che sul secondo
pixel posso scegliere fra 256 colori? Fra 16 colori di base (primo pixel), ciascuno dei quali può essere sottoposto a 16 blu-sfumature diverse …
fanno 256 scelte possibili per il secondo pixel.
La debolezza è che se ho una necessità cromatica imperativa sul primo pixel, il secondo ne è schiavo (correlato al primo).
il rebus è che questo ragionamento porterebbe a contare più di 4096 colori …
Andiamo avanti:
ora passiamo al terzo pixel:
Denise riceve:
xx10/RRRR
quindi sul terzo pixel conserva le componenti GB, mentre cambia quella R, scegliendo fra 16 livelli di rosso … quindi partendo come previsione di scia
cromatica dal primo pixel, scia poi B-rettificata un po' sul secondo pixel, poi R-rettificata un po' sul terzo pixel, sul terzo pixel abbiamo
una scelta di 16 x 16 x 16 = 4096 colori.
Aspetta un attimo … io avrei detto di arrivare a 4096 al quarto pixel, ovvero:
xx00/ABCD - pixel base
xx01/ABCD - secondo pixel, prima sfumatura
xx10/ABCD - terzo pixel, seconda sfumatura
xx11/ABCD - quarto pixel, terza sfumatura
Invece arrivo a 4096 al terzo pixel, seguendo il mio ragionamento … devo aver travisato qualcosa … cosa?
Domanda:
le sfumature possono continuare?
Voglio dire:
dopo il quarto pixel, ormai i colori sono finiti, quindi propongo quelli che avrei già potuto avere nei pixel precedenti (la tavolozza potenziale è
terminata), però posso comunque andare avanti con le sfumature, quindi applicare altre RGB-sfumature, pixel dopo pixel, fino a fine riga …
è corretto?
Poi se voglio, ad un certo punto della riga, avere un salto cromatico drastico (l'immagine/il gioco ne ha bisogno), quindi non un gradiente, allora
è sufficiente stampare lì un pixel di base con il comando 00.
Ben gradite spiegazioni, rettifiche ... tutto ciò che illumini …







A500-Plus + A501 + switch meccanico per selezione Double-kickstart 1.3 v. 34.5 / 3.1 v. 40.63 /// A600, Rev. MB. 1.5, espansione in trap-door 1MB chip-ram, Kick-Cloanto 45.66, HDD interno a tracce da 2GB modello MK2104MAV by Toshiba su porta IDE: partizione DH1 con WB2.1 (default) + partizione DH2 con WB3.1 /// A500, Kick 1.3 v. 34.5, scheda espansione in trap-door da 512KB /// A600, espansione da 4MB-fast-ram innestata con zoccolo direttamente su 68K, Kick 2.05 v. 37.300, espansione di chip-ram in trap-door da 1MB, CF da 4GB su adattatore interno CF/IDE: partizione DH0 con CWB GAAE, partizione DH1 con WB2.1, partizione DH2 con WB1.3 /// A500, Rev. MB 6A, Kick 1.3 v. 34.5, A520-TV-RF-Modulator /// A500, PWR-LED ROSSO. Kick 1.2 v. 33.180 /// A500-Plus, PWR-LED ROSSO, Kick 2.04 v. 37.175, Driver DF1 esterno Savage DMF 322, A590 alimentato da alimentatore di CD32, con dentro espansione da 2MB di fast-ram + HDD SCSI Seagate ST32151N da 2GB - DH0 con WB 2.04 e DH1 con WB 1.2 /// A1200, 68EC020, Kick 3.0 v. 39.106, HDD a tracce Hitachi 40GB interno su porta IDE con installato CWB, espansione A1208 in trap-door da 8MB-fast-ram, PLipBox su porta parallela per collegamento via Ethernet a Internet /// Commodore 64 Assy NO. 250425 + floppy drive 5’’ 1/4 modello 1541

utente amiga quadratico medio

Post inviati: 701

Visulizza profilo Messaggio Personale
79.51.61.*** Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko
Commento 7
AMG_Novice_Usr 1 Febbraio 2020    13:07:03
Altra domandina:
cosa sono i playfields nel mondo Amiga? A cosa servono?
Ed i bitplane?
Ho letto qualcosa circa gli sprites, che possono essere larghi massimo 16 pixels, lunghi (alti) anche tutto lo schermo … massimo 8 sprites alla volta
contemporaneamente gestiti da … da chi? Da Denise? è questo chip che li produce? Perché a giro ho letto di sprites hardware … non ho capito.
Io credevo che ogni oggetto pixelliano (un'immagine), di qualunque tipo sia, sia appunto scritto nella parte grafica della chip-ram, ed un canale
DMA gestito da Agnus punti come sorgente all'indirizzo del primo byte/pixel di questa immagine, e che punti come destinazione ad un registro del
chip Denise. Ad ogni colpo di clock, il canale DMA by Agnus incrementa di 1 il puntatore all'immagine di sorgente in chip-ram, così da
scansionarla tutta.
Denise si ritrova in pancia, instante dopo istante (colpo di clock dopo colpo di clock), un byte/pixel diverso, quindi Denise non dovrebbe far altro che DAC-izzare le 3 tensioni analogiche RGB, muovere i segnali di sincronismo V,H e dot-clock diretti verso la porta RGB-DB23
… avete correzioni/dettagli da aggiungere a tutto ciò?
Altra domandina:
che differenza ci sarebbe fra uno sprite ed un blob?
Ultima domandina:
ho sentito parlare di un'invenzione rivoluzionaria per l'epoca (anni 80), ovvero un registro, interrogabile dal 68k, che contiene instante
per istante la posizione corrente (X,Y) del pennello elettronico. Questo registro, che può dare questo feedback così importante ai nostri
programmi che girano sul 68k, si trova all'interno di Denise?
Grazie!

A500-Plus + A501 + switch meccanico per selezione Double-kickstart 1.3 v. 34.5 / 3.1 v. 40.63 /// A600, Rev. MB. 1.5, espansione in trap-door 1MB chip-ram, Kick-Cloanto 45.66, HDD interno a tracce da 2GB modello MK2104MAV by Toshiba su porta IDE: partizione DH1 con WB2.1 (default) + partizione DH2 con WB3.1 /// A500, Kick 1.3 v. 34.5, scheda espansione in trap-door da 512KB /// A600, espansione da 4MB-fast-ram innestata con zoccolo direttamente su 68K, Kick 2.05 v. 37.300, espansione di chip-ram in trap-door da 1MB, CF da 4GB su adattatore interno CF/IDE: partizione DH0 con CWB GAAE, partizione DH1 con WB2.1, partizione DH2 con WB1.3 /// A500, Rev. MB 6A, Kick 1.3 v. 34.5, A520-TV-RF-Modulator /// A500, PWR-LED ROSSO. Kick 1.2 v. 33.180 /// A500-Plus, PWR-LED ROSSO, Kick 2.04 v. 37.175, Driver DF1 esterno Savage DMF 322, A590 alimentato da alimentatore di CD32, con dentro espansione da 2MB di fast-ram + HDD SCSI Seagate ST32151N da 2GB - DH0 con WB 2.04 e DH1 con WB 1.2 /// A1200, 68EC020, Kick 3.0 v. 39.106, HDD a tracce Hitachi 40GB interno su porta IDE con installato CWB, espansione A1208 in trap-door da 8MB-fast-ram, PLipBox su porta parallela per collegamento via Ethernet a Internet /// Commodore 64 Assy NO. 250425 + floppy drive 5’’ 1/4 modello 1541

AfAOne

Post inviati: 5887

Visulizza profilo Messaggio Personale
79.41.39.*** Mozilla/5.0 (Windows NT 6.1; rv:72.0) Gecko/20100101 Firefox/72.0
Commento 8
AfAOne 1 Febbraio 2020    13:10:35
Citazione

Altra domandina:
cosa sono i playfields nel mondo Amiga? A cosa servono?
Ed i bitplane?


Hai gia letto QUI (Bitplane) e QUI (Dual Playfield)

Commento modificato il 01/02/2020 alle ore 13:11:58


Immagine AROS One x86/68k
- AfA One - AfA One PPC - Amilator AfA One - Amithlon AfA One - WinUAE OS 4.1


Post inviati: 1588

Visulizza profilo Messaggio Personale
80.181.223.*** Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0
Commento 9
majinga 1 Febbraio 2020    13:46:54
Per gli sprite, il vantaggio di quelli hardware è che vengono gestiti in automatico, collisioni e tutto. Devi solo indicare dove vanno disegnati su schermo.
Il problema con le macchine vecchie è che il numero di sprite hardware è basso. Quindi occorre ricorrere a qualche trucchetto.
Un trucco è che una volta che lo sprite è stato disegnato a schermo, si può riutilizzare disegnandolo da un altra parte, semplicemente cambiando al volo il valore di dove deve essere disegnato.
E' una cosa che si vede spesso ad esempio negli sparatutto a scorrimento. E' il motivo per cui i nemici hanno spesso una formazione a freccia, perché è sempre lo stesso sprite, una volta finito di disegnarlo, si cambia al volo la posizione e l'hardware lo disegna di nuovo, in questo modo si ha l'impressione di avere più sprite di quelli che in realtà sarebbero gestibili.

Il cambio al volo di sprite è abbastanza comune, ed è il motivo per cui a volte quando ci sono troppi personaggi a schermo li vedi sfarfallare.

Pegasus RyuSei Ken

Post inviati: 10185

Visulizza profilo Messaggio Personale
87.1.250.*** Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36
Commento 10
Seiya 1 Febbraio 2020    20:21:24
@AMG_Novice_User?
Ma hai intenzione di realizzare un gioco per Amiga? per essere un novizio mi sembra che tu abbia già buone conoscenze di programmazione

utente amiga quadratico medio

Post inviati: 701

Visulizza profilo Messaggio Personale
79.51.61.*** Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko
Commento 11
AMG_Novice_Usr 2 Febbraio 2020    17:26:07
Citazione

Ma hai intenzione di realizzare un gioco per Amiga? per essere un novizio mi sembra che tu abbia già buone conoscenze di programmazione

Su Amiga non ho mai programmato veramente, per lavoro invece programmo in C e ASM piccoli microcontrollori (core: ARM e Cortex) per
applicazioni embedded in ambito di elettronica industriale. Per Amiga ho solo fatto qualche piccolo script in AmigaDOS, solo per imparare
qualche concetto basico (niente di semi-serio) ed un "giochino" in AmigaBASIC (se interessa, anche se non penso proprio, posso postare lo
script Basic, così potete farlo interpretare). Si tratta di una circonferenza che viene mossa sullo schermo dal mouse, e quando clicchi il tasto sinistro
dello stesso, la circonferenza in questione (che rappresenta la mia astronave) spara delle circonferenzine (diverso colore rispetto alla circonferenza
astronave, e raggio molto minore) che rappresentano i proiettili. Un possibile sviluppo potrebbe essere quello di creare delle circonferenze/avversari
che calano dall'alto dello schermo verso il basso, e se un mio proiettile intercetta un avversario, questo muore/sparisce dal monitor.

Una domanda:
qualcuno ha dei segmenti di codice, suppongo in Assembly (io ho AsmOne, come IDE/compilatore), da condividere … codice ed esempi molto semplici
che producano cose come bitplanes, sprites ed altri elementi grafici?

Grazie

p.s.
qualcuno ha esperienza di sviluppo di piccoli giochi, anche molto semplici, su Amiga? Qualche consiglio su linguaggi di programmazione adatti
a tale scopo, ambienti (IDE?) in cui si posso sviluppare semplici applicazioni … ogni informazione è stra-ben gradita!

A500-Plus + A501 + switch meccanico per selezione Double-kickstart 1.3 v. 34.5 / 3.1 v. 40.63 /// A600, Rev. MB. 1.5, espansione in trap-door 1MB chip-ram, Kick-Cloanto 45.66, HDD interno a tracce da 2GB modello MK2104MAV by Toshiba su porta IDE: partizione DH1 con WB2.1 (default) + partizione DH2 con WB3.1 /// A500, Kick 1.3 v. 34.5, scheda espansione in trap-door da 512KB /// A600, espansione da 4MB-fast-ram innestata con zoccolo direttamente su 68K, Kick 2.05 v. 37.300, espansione di chip-ram in trap-door da 1MB, CF da 4GB su adattatore interno CF/IDE: partizione DH0 con CWB GAAE, partizione DH1 con WB2.1, partizione DH2 con WB1.3 /// A500, Rev. MB 6A, Kick 1.3 v. 34.5, A520-TV-RF-Modulator /// A500, PWR-LED ROSSO. Kick 1.2 v. 33.180 /// A500-Plus, PWR-LED ROSSO, Kick 2.04 v. 37.175, Driver DF1 esterno Savage DMF 322, A590 alimentato da alimentatore di CD32, con dentro espansione da 2MB di fast-ram + HDD SCSI Seagate ST32151N da 2GB - DH0 con WB 2.04 e DH1 con WB 1.2 /// A1200, 68EC020, Kick 3.0 v. 39.106, HDD a tracce Hitachi 40GB interno su porta IDE con installato CWB, espansione A1208 in trap-door da 8MB-fast-ram, PLipBox su porta parallela per collegamento via Ethernet a Internet /// Commodore 64 Assy NO. 250425 + floppy drive 5’’ 1/4 modello 1541

AfAOne

Post inviati: 5887

Visulizza profilo Messaggio Personale
87.21.251.*** Mozilla/5.0 (Windows NT 6.1; rv:72.0) Gecko/20100101 Firefox/72.0
Commento 12
AfAOne 2 Febbraio 2020    19:47:13
Visto che ti piace la programmazione dai uno sguardo a questi link di linguaggi ancora attuali:

Per i Gicochi
https://trackerhero.wixsite.com/redpill

Applicazioni Games Multi OS
https://www.hollywood-mal.com/

Applicazioni
https://www.amiblitz.de/

Commento modificato il 02/02/2020 alle ore 19:47:51


Immagine AROS One x86/68k
- AfA One - AfA One PPC - Amilator AfA One - Amithlon AfA One - WinUAE OS 4.1



Utenti Online
Utenti registrati: 1206 dal 1 Gennaio 2006
di cui online: 2 registrati - zybex17 - sampedenawa -
51 non registrati

Benvenuto all'ultimo utente registrato: zulu

Buon Compleanno a Luillui - 

© Amigapage 1998 - 2007 - Sito italiano dedicato alla piattaforma Amiga ed evoluzioni varie.
Struttura del sito interamente ideata e realizzata da Marco Lovera e Alessandra Lovera - Tutto il materiale inserito all'interno del sito č dei rispettivi autori/creatori.
E' assolutamente vietata la riproduzione o la manipolazione di tutti i contenuti o parte di essi senza l'esplicito consenso degli amministratori e degli autori/creatori.

Eseguito in 0.18829083442688 secondi