AROS estende screen dragging a tutte le schede video

[paolone]

Da qualche giorno è possibile usare lo screen dragging su AROS con qualsiasi scheda video. La funzionalità, infatti, è stata estesa alla modalità VESA con ottimi risultati, e con l'unica limitazione che tutti gli schermi avranno in pratica la medesima risoluzione. Sul sito di Icaros Desktop è apparso un filmato che lo mostra in azione, anche se il tool con cui è stato catturato mostra degli scatti che, in realtà, non ci sono.

http://youtu.be/ka0HwsfNURw

[cdimauro]

Paolo, a naso, secondo te s'intravede la 1.0 all'orizzonte, oppure ci vorrà ancora molto tempo?

[nibiru]

Da qualche giorno è possibile usare lo screen dragging su AROS con qualsiasi scheda video. La funzionalità, infatti, è stata estesa alla modalità VESA con ottimi risultati, e con l'unica limitazione che tutti gli schermi avranno in pratica la medesima risoluzione. Sul sito di Icaros Desktop è apparso un filmato che lo mostra in azione, anche se il tool con cui è stato catturato mostra degli scatti che, in realtà, non ci sono.

http://youtu.be/ka0HwsfNURw

Ottimo! Sempre più vicino ai "concorrenti" Col piccolissimo vantaggio di non girare solo su hardware di 6 anni fa...

Ricordo un articolo dell'altro Paolone amighista (Canali) su Amiga Magazine, che con una delle prime VGA per Amiga (forse la Cybervision 64) commentava riguardo la possibilità di quel chip di simulare parzialmente le funzionalità Copper, potendo gestire almeno il cambio di risoluzione... chissà che non si riesca a fare una cosa simile.

[paolone]

@cesare:

Purtroppo per la cosiddetta '1.0' bisognerà ancora aggiungere la stampa, chiudere definitivamente i pochi problemi di compatibilità rimasti, passare attraverso le forche caudine del cambio di ABI (ormai in corso, ma sarà un processo che porterà via approssimativamente un annetto) e cose così, ma di certo il suo avvento è più vicino oggi di quanto non lo fosse 12 mesi fa. E, del resto, comincio a sospettare che la predizione Maya per il 1012 fosse questa...

@nibiru

Qui affrontiamo un discorso tecnico da cui non se ne esce più. In soldoni, le modalità VESA rappresentano una sorta di minimo comune denominatore che tutte le schede video offrono (a parte le peggiori in assoluto, ma me ne vengono in mente soltanto un paio), per garantire un MINIMO di interoperabilità fra sistemi operativi e metodi di programmazione diversi. Le funzionalità offerte dalle modalità VESA sono piuttosto limitate e non a caso Windows e Linux fanno figure piuttosto magre quando sono avviati in queste modalità. Su AROS il discorso è diverso perché per anni le abbiamo usate come unico, realistico sistema per ottenere un output di buona qualità senza dover scrivere driver dedicati, e ormai le conosciamo piuttosto bene. Uno dei limiti dell'implementazione attuale, tuttavia, è che AROS può avviarsi in una risoluzione VESA ma mantenere solo quella fino al reboot successivo. Se si cambia strada facendo, per esempio un programma cerca di aprirsi a schermo intero a 640x480 quando il workbench lavora a 1600x1200, accadrà semplicemente che il suo output occuperà l'angolo superiore sinistro dello schermo, lasciando nero o grigio tutto il resto. L'altra opzione sarebbe lo scaling delle immagini in tempo reale ma, non essendo le modalità VESA accelerate in alcun modo, peserebbe tutto sulla CPU, con grave danno per le prestazioni generali. Inutile dire che il gioco non varrebbe la proverbiale candela.

[nibiru]

@nibiru
Qui affrontiamo un discorso tecnico da cui non se ne esce più. In soldoni, le modalità VESA rappresentano una sorta di minimo comune denominatore che tutte le schede video offrono (a parte le peggiori in assoluto, ....

Inutile dire che mi scuso perché non l'ho scritto, ma ovviamente non stavo pensando al driver VESA... stavo pensando che magari più in là, quando (e se) si avrà tempo, si potrebbe cercare di simulare il copper, ma se non è stato ancora fatto, suppongo che non si possa fare se non su alcune (strane) schede di un tempo. E/O che il gioco non valga la candela, neppure con le modalità video accelerate.

Ricordo che Canali parlò di un chip in grado di temporizzarsi e quindi simulare (alcune del)le funzionalità del Copper.

Riguardo alla Vesa, credevo che avesse una (seppur minima) accelerazione 2d... e invece si limita a settare una risoluzione e una profondità di bit. Ricordo che agli albori le VGA avevano pure una modalità bitplane... se non ricordo male limitata a 16 colori.

Comunque già poter simulare il dragging, mi sembra un signor risultato. Adesso si dovrebbero indirizzare la maggior parte degli sforzi sul SMP, perché ormai le CPU spingono sul parallelo, ed è finita l'epoca dei MHZ.

[cdimauro]

@Paolo: grazie della informazioni.

Inutile dire che mi scuso perché non l'ho scritto, ma ovviamente non stavo pensando al driver VESA... stavo pensando che magari più in là, quando (e se) si avrà tempo, si potrebbe cercare di simulare il copper, ma se non è stato ancora fatto, suppongo che non si possa fare se non su alcune (strane) schede di un tempo. E/O che il gioco non valga la candela, neppure con le modalità video accelerate.

Servirebbe una scheda video in grado di generare interrupt a una determinata riga video, ma, se presente, si tratta di una funzionalità non standard. Quindi servirebbe scrivere driver appositi per queste schede, cioè un bagno di sangue.

Ricordo che Canali parlò di un chip in grado di temporizzarsi e quindi simulare (alcune del)le funzionalità del Copper.

Sì, si può già fare utilizzando uno dei timer presenti nel chip, programmandolo in modo da farlo scattare approssimativamente quando la scheda video ha finito di disegnare la riga di raster precedente a quella in cui c'è il cambio di schermo.

E' una tecnica utilizzata parecchi anni fa, quando i programmatori PC cercavano di simulare il raggiungimento del vertical retrace (di Amiga & co.) per aggiornare la grafica in modo smooth (senza "sfarfallii")

C'è un bel lavoro dietro, perché non è semplice e raggiungere la fine di una determinata riga richiede una maggior precisione del timer e un certo sbattimento.

In ogni caso non si può cambiare risoluzione. Al limite si visualizzerebbe una porzione dello schermo. Per "cambiare risoluzione" si dovrebbe utilizzare una scheda video che ha zoom orizzontale e verticale in hardware, come le mitiche Tseng ET4000 (se non ricordo male), ma anche qui andiamo sul campo delle singole schede che implementano queste funzionalità e, cosa peggiore, ognuno a modo loro.

Meglio lasciare l'implementazione attuale.

Riguardo alla Vesa, credevo che avesse una (seppur minima) accelerazione 2d... e invece si limita a settare una risoluzione e una profondità di bit.

C'è uno standard, il VBE/AF, che lo prevede, ma non tutti i produttori lo implementano nelle loro schede e/o forniscono tutte le funzionalità previste di accelerazione hardware.

Qui almeno c'è uno standard dietro e il guadagno, a naso, dovrebbe essere consistente, ma richiederebbe la scrittura di un apposito driver, il VBE/AF, per le schede che lo supportano. Ma ci dev'essere qualcuno che lo scrive, appunto.

Ricordo che agli albori le VGA avevano pure una modalità bitplane... se non ricordo male limitata a 16 colori.

Ereditata dalle EGA. Sì, c'era, ma era macchinoso lavorarci a livello di singolo pixel. Invece per blocchi di 8 pixel era abbastanza veloce.

Inutile dire che si preferiva il classico "mode 13" della VGA (320x200 a 256 colori) che risultava di gran lunga più semplice da utilizzare, e con molti più colori.

In realtà per quest'ultima era possibile far ricorso ai cosiddetti "ModeX", che utilizzavano i 4 bitplane in modo da sfruttare tutta la memoria video (256KB anziché i 64KB del mode 13) per ottenere:
- schermi a risoluzione più elevata (tipo la classica 320x240 usata da Doom, ma si poteva arrivare fino a 400x300, se non ricordo male);
- frame buffer addizionali (double / triple buffering);
- spazio in cui inserire grafica (sprite/bob).

Comunque già poter simulare il dragging, mi sembra un signor risultato. Adesso si dovrebbero indirizzare la maggior parte degli sforzi sul SMP, perché ormai le CPU spingono sul parallelo, ed è finita l'epoca dei MHZ.

Non so se ci stanno lavorando, ma alcuni del team di AROS c'hanno già pensato.

Ma, a mio avviso, bisogna prima arrivare alla versione 1.0 con le API/ABI complete. Dopo si può pensare a lavorare per aggiornare il s.o. aggiungendo quello che gli manca (protezione della memoria, resource tracking, SMP).

[paolone]

@cesare

La direzione attuale è approfittare del cambio di ABI (già in corso) per infilare in AROS tutte le modifiche che romperanno per forza la compatibilità con il software già compilato.

[cdimauro]

Mi sembra un'ottima: meglio adesso che non siamo ancora alla 1.0, che dopo.

Al momento cambiare ABI ha senso (le API sono già "finalizzate", visto che parliamo di AmigaOS 3.1) se ci sono cambiamenti migliorativi. Anzi, è auspicabile, per costruire una piattaforma più solida e/o efficiente.

[Zorro]

Sempre più da tenere d'occhio il nostro caro vecchio AROS...

[matriosk]

Presumo che il problema delle risoluzione potrebbe essere risolto "texturizzando" l'output degli applicativi che aprono schermi separati.

[TheKaneB]

Presumo che il problema delle risoluzione potrebbe essere risolto "texturizzando" l'output degli applicativi che aprono schermi separati.

Si, si potrebbe fare, ma bisognerebbe prima implementare il compositing :-)

[AmigaCori]

Presumo che il problema delle risoluzione potrebbe essere risolto "texturizzando" l'output degli applicativi che aprono schermi separati.

OT
Benvenuto nel forum
/OT

[matriosk]

@AmigaCori:
Grazie!
Sono iscritto da anni ad AmigaPage.it e come li, qui trovo una comunità attiva ed interessante.

@TheKaneB:
Si... dovrebbe essere fattibile... pur essendo limitato il range di schede video, le ati e le nvidia (soprattutto quest'ultime) sono ben supportate e Gallium3D è già ben integrato...
Il compositing non dovrebbe essere difficile da implementare...
Cmq, da anni riverso molte speranze su AROS.
E' davvero l'unica alternativa di vedere AmigaOS su macchine attuali e potenti... anche se ci sono tante cose da fare (molte giustamente ereditate proprio da AOS3.1 da cui proviene):
- Migliore gestione della memoria protetta e reale integrazione con gli applicativi
- Migliore gestione dell'allocazione di memoria
- Resource tracking (attualmente parziale)
- Memoria Virtuale (anche se relativo)
- Supporto SMP
- ecc.

Per il resto è davvero un bel progetto e non finirò mai di stupirmi come sviluppatori non pagati e così capaci siano arrivati a tanto... potenza della passione... cioè la vera anima di AmigaOS.
Ci sono aziende che nello stesso tempo non hanno neanche finito un ipotetico framework in Java e lo hanno venduto guadagnando moltissimi soldi...
Chissà cosa sarebbero riusciti a fare gli sviluppatori di AROS se avessero vissuto della loro passione...