Creative ALchemy Project: EAX anche su Windows Vista

>>>
Attualmente la procedura per mettersi al riparo dal rendering software dei flussi audio consiste nel copiare due file nella cartella di ogni gioco. Tali file hanno il compito di "tradurre" le richieste Direct3D in OpenAL, in modo tale da poter godere di tutte le "vecchie" funzionalità, pur senza una compstibilità diretta del titolo alle librerie OpenAL.
>>>

Mi ricorda il sistema per poter sfruttare le schede video Voodoo con i giochi non compatibili nativamente con le librerie Glide.



Scusami ma rimanere ottimista con la Microsoft è da ingenui.


Non mi intendo di audio ma non penso che l'Auidy 2 lo supporti, essendo uscita "tanto" tempo fa.


A chi segue l'informatica con più precisione di me, ma Microsoft sta "abbandonando" i suoi vecchi standard, criticati da tutti per la loro pessima qualità? Si parla da tempo se il Direct 3D verrà abbandonato completamente a favole dell'Open GL. Adesso questo OpenAL.
Un'altra cosa, le cpu cisc che una volta andavano bene con un certo tipo di computer si stanno "trasformando" sempre più in risc perchè come sono fatti i computer oggi, i risc vanno meglio (prendete la mia frase per quella che è, non voglio essere corretto al 100%; chi la sa bene può spiegarlo meglio di me).
Mi sembra propio che i personal computer siano nati storti, con la tecnologia "peggiore" (forse la più economia) da supprotare su quelle che c'erano sul mercato. Oggi piano piano cercando di radrizzarsi.

Stai scherzando vero?

Troj@on wrote:
"Per il momento sto vista è davvero inutile...poi il tempo deciderà..."

Una delle poche cose interessanti (se funziona) di Vista è proprio il suo essere HAL-indipendente...

Ciao
Stefano

sicuro ?

sapevo che l' hal era presente in nt dalle origini e che tra l'altro da nt4 fosse stato reso bypassabile dal drv video (per avere maggori prestazioni). o almeno riportano le cose in questo modo anche alcuni testi di s.o.
forse in win2000 hanno aggiunto un hal per i chip audio che prima non c'era lo hanno fatto espandendo il modulo perl'acc. grafica anziché in un modulo apparte ?

cmq, quali sono state le ragioni tecniche che mettendo mano agli hal hanno fatto sparire il supporto agli effetti elaborati in hw (eax comprese) via ds3d e addirittura fatto preferire una libreria di terzi per questo ?
(te lo chiedo xché sembri ferrato sull'argomento )
hanno per caso semplicemente "segato" qualcosa e poi reintrodotto il supp. hw "dalla finestra" nel modo più semplice e rapido possibile ?

'spetta... un hal introduce (almeno in teoria, fino ad un certo livello di dettaglio) "indipendenza" dall'hw per gli strati superiori... essere "hal-indipendente" che vuol dire ?

@MenageZero

L'HAL c'era già con NT ma solo per determinate periferiche. I driver video e quelli audio erano dentro al kernel come Linux oggi perchè al tempo si pensava che fare un kernel enorme con tutti i driver dentro portasse benefici alle prestazioni, ed in effetti è vero perchè il codice viene eseguito più velocemente.
Poi però si è scoperto che se un driver è scritto male ed è in kernel mode crasha l'intero sistema. Ma non si poteva riscrivere tutto da zero perdendo la compatibilità così il concetto di HAL di NT è stato esteso e si è arrivati al plug & play di Win2000 che aveva ancora i driver in kernel mode ma con uno strato software in mezzo a cercare di ottimizzare le chiamate tra l'hardware da un lato e il kernel dall'altro.

Oggi con Vista si è scoperto che questo approccio rallenta notevolmente lo sviluppo della grafica 3D perchè non permette di accedere con celerità alle risorse hardware della gpu processando meno poligoni al secondo e non solo, infatti le texture processate non possono superare una certa qualità visiva pena il rallentamento del motore 3d.Per questo motivo è stato deciso di rimuovere l'HAL software che era stato esteso con Win2000 riscirvendo la maggior parte dei driver in user mode con il .net framework e usando al minimo il kernel mode.
Purtroppo questa descisione elimina il supporto eax, che però è garantito da una serie di librerie, OpenAL, che sfruttando lo user mode riabilitano l'audio accelerato in hardware. Ma per poter rendere compatibile una scheda audio con queste librerie bisogna che i driver le supportino e la Creative per non stare a riscrivere tutti i driver ha creato l'Alchemy Project che traduce ogni istruzione vecchia nelle nuove compatibili OpenAl ma al costo enorme di risorse di cpu e memoria, funziona come un emulatore.
Secondo me le nuove schede audio Creative, che saranno PCI express, avranno i driver OpenAl nativi.

veramente si dice proprio il contrario , almeno nella programmazione di vg sono le ogl destinate all'abbandono (già in atto sostanzialmente), specie dopo le dx10, e pare cmq che in genere gli sviluppatori del settore abbiano invece una opinone molto positiva delle dx (nonché dei tool di sviluppo by ms), almeno nelle vers, più recenti
(lo stesso Carmack, autore di quello che forse rimarrà l'ultimo "pezzo da 90" tra gli engine3d scritti con ogl, in una recente intervista ha dischiarato che le dx9 sono le migliori api con cui ha mai lavorato)
poi, ancor più per quanto appena detto, questa apparente "adozione" delle openal, ha sorpreso anche me...


qui evito di dare una mia opinione xché sostanzialmente non ho capito cosa volevi dire
dico solo che cmq le arch. x86 (ma prob. no solo quelle) se agli albori erano "cisc per definizione", non sono più nettamente classificabili secondo i concetti tradizionali di cisc e risc da molti anni, sono più una sorta di "ibrido" forse

Speriamo, così magari le si potrà usare sotto linux

@Motosauro

Sono molto convinto di questo, perchè ora come ora non hanno alternative. Non possono rilasciare una nuova scheda che funziona con un "traduttore" di codice. Una sorta di emulatore JIT (Just In Time).

Sul fatto che funzionino anche su Linux non lo so, tecnicamente sarebbe possibile dato che i driver sarebbero scritti in .net e su Linux gira Mono. Bisogna vedere cosa pensano di fare alla Creative.

In aggiunta a quello che ha scritto mauriziofa posso aggiungere che gia da tempo la microsoft ha messo in stato di "deprecated" alcune API delle directx, le principali sono le DirectInput e DirectSound e DirectPlay , solo parzialmente le DirectShow.

Questo perche la MS ha trovato nuove tecnologie che ritiene migliori per sostituirle, nel caso del DirectInput sta migrando a XInput (nato dall'esperienza con l'xbox). Il DirectPlay verra sostituito dall'Xbox Live, il DirectShow verra passato ai "Media Foundation".

nel caso che ci interessa cioè il DirectSound è in migrazione al sistema utilizzato dall'xbox cioè il XACT.

quindi è probabile che essendo queste tecnologie in fase di dismissione vengano tolte da componenti fondamentali come HAL e kernel per poter cambiarle con altre senza dover stravolgere il sistama durante il suo periodo di vita.

AGGIUNTA

mi sono scordato un particolare non banale, in vista la microsoft vuole poter controllare in maniera centrale i flussi audio per poter essere sicura che contenuti protetti DRM o canali HDMI siano bloccati in caso non siano di origine lecita, per fare cio deve far im modo che il controllo del tutto passi per un componente unico e centrale come il kernel, quindi togliere le vecchie tecnologie "legacy" è anche una questione strategica per il futuro.