Newsgroup: it.comp.hardware.video-3d
Titolo: E questa?!?!? Da directx a opengl con un converter!!!

http://www.theinquirer.net/default.aspx?article=35742
"AMD SUBSIDIARY ATI has released open source source software that converts 
the Windows DirectX 9 Application Programming Interface (API)into Open GL.
According to MacWorld, the move could mean that Apple users could seriously 
dip their toes into the world of gaming.
The HLSL2GLSL code works on the Mac OSX and translates Vole's High Level 
Shader Language (HLSL) into the OpenGL equivalent GLSL.
The move means that programmers who are struggling to make games work on the 
Mac OSX by using their own libraries will have something more solid to work 
from. It could also lead to the development of more games being available on 
Linux, something that has kept the operating system away from the home 
desktop market"
E' incredibile quanto la fusione ati-amd stia producendo beneficio 
all'intero mondo informatico!!!!
-- 
-------------------------------
SimBus82 --> 
www.simbus82.altervista.org
 --> Hi-Tech Content Inside
------------------------------- 

 all'intero mondo informatico!!!!
Se fosse vero sarebbe una vera e propria rivoluzione, ma credo che M$ 
farà di tutto perchè questa cosa non vada mai in porto, poichè 
segnerebbe la fine del suo monopolio....


forse non hai ben letto...o forse non sai l'inglese...
"AMD SUBSIDIARY ATI has released open source source software "
1- ha già rilasciato
2- opensource, ms non può fare niente


 Shader Language (HLSL) into the OpenGL equivalent GLSL.
the inquirer a volte mi stupisce per gli errori madornali di comprensione 
l'HLSL è il linguaggio di programmazione ad alto livello ( può girare codice 
precompilato negli shaders) dei fragment (programmi per gli shaders)
un wrapper o una ricompilazione non son niente di che, e sopratutto non è 
che l'infinitesima parte di un engine 3d, ricordo ai meno esperti che i 
fragment servono per lavorare sul colore di un pixel, o su un vertice, un 
engine è ben altra cosa, quindi non significa mica che all'improvviso ciò 
che gira come dx sarà possibile vederlo sotto ogl
no dico, la epic son due anni a giugno che cerca di far andare il motore ue3 
già pronto da anni sotto d3d, sotto ogl, parliamo di signori sviluppatori eh
come potete aver capito una cosa del genere non lo so


ok ma con questo strumento (probabilmente legato anche all'hardware 
utilizzato) altro non fa che facilitare alcune transizioni dal d3d 
all'opengl...ed essendo opensource e trattando un tema molto delicato, mi sa 
che avrà un futuro e un reale utilizzo...


BS82 ha scritto:

A dir la verità non avevo letto l'articolo, ma mi ero rimesso al tuo 
breve riassunto :-P , ma in sostanza non dice molto di più di quello che 
hai detto tu. L'articolo di MacWorld ( 
http://www.macworld.com/news/2006/11/10/hlsl2glsl/index.php
 ) è molto 
più interessante, poichè pone l'accento su un concetto fondamentale: 
esistono già versioni a pagamento di suddetto programma, e a quanto pare 
alle software house è fregato ben poco.
Ma d'altra parte, perchè prendersi in giro? Lo sappiamo benissimo che 
fare un porting non è una cosa troppo impegnativa per le software house, 
ma farlo per accontentare l'1% (o forse meno....) degli utenti 
porterebbe benefici pressochè impercettibili. Quando (e se) questo 1% 
diventerà 20%, allora le software house cominceranno a porsi il problema.

BS82 wrote:
Direct3D si appoggia su OGL, da quel che so io. Utilizza solo una parte 
delle funzionalità delle librerie OGL (difatti tutto quello che si può fare 
in D3D si può fare anche in OGL), mano a mano che si va avanti le D3D 
integrano nuove funzioni OGL. Il vantaggio delle librerie MS è che sono 
capaci di far funzionare sulla CPU quello che non è supportato in hardware 
(salvo diverse scelte tecniche dovute a pesantezza o complicatezza eccessiva 
dell'effetto), mentre OGL si appoggia esclusivamente all'hardware grafico.
Alla fine bindare un motore grafico a OGL o a D3D non è difficile. E' 
questione di riscriversi delle librerie.
Mi pare che la patch di AMD sia tutto sommato realizzabile anche senza aver 
necessità di funzionare da emulatore.
-- 
Danilo Pianini
"DanySK"
www.alientech.it
 

DanySK ha scritto:

Hai colto nel segno. Per programmatori abituati a ben altre difficoltà 
un porting è una passeggiata. Il vero problema è un altro, cioè il fatto 
che M$ stia facendo di tutto per imporre DirectX come unico standard di 
sviluppo per i videogiochi. Prendiamo ad esempio World of Warcraft: 
esiste sia una versione per Windows, sia una per MacOS. Dato che MacOS e 
Linux sono Unix based, fare un porting sarebbe costato poca fatica, ma 
non è stato fatto. E se non è per una questione di marketing, non vedo 
per quale altro motivo la Blizzard avrebbe dovuto agire in questo modo....

all'intero mondo informatico!!!!
vedrai che tempo una settimana e salta fuori una nuova versione delle
dx indispensabile per tutti i nuovi giochi e curiosamente
incompatibile con il tool...
in pratica e' il motivo per cui wine/cedega e simili stanno facendo la
corsa della regina rossa (devi correre sempre piu' in fretta se vuoi
rimanere nello stesso posto) da anni.
-- 
    (iao!!oai)                                    (ICQ: 10860566)
    //.aurizio
[WARNING!: togliete _nessuno_ per rispondere]
    Coloro che sono disposti a farsi togliere alcune liberta' 
essenziali per ottenere un piccolo, temporaneo senso di sicurezza
non meritano ne liberta' ne sicurezza. [B. Franklin]


"Tradurre" un intero motore grafico per essere sfruttata da un api all'altra
comunque non è proprio un goco da ragazzi...
Ciao

Lorenz wrote:
|| Diciamo che anche OGL può appoggiarsi pesantemente alla cpu... vedi
|| ad esempio tutti gli applicativi professionali 3D i quali pur essendo
|| programmati in OGL si appoggiano molto alla cpu di sistema per le
|| fasi di rendering.
E' diverso Lorenz. In quel caso il motore grafico funziona solo in caso di 
preview, la fase di rendering è una fase puramente algoritmica dove viene 
interessata la CPU non via OGL ma semplicemente facendo delle operazioni di 
calcolo su mesh - particelle - luci etc.
|| "Tradurre" un intero motore grafico per essere sfruttata da un api
|| all'altra comunque non è proprio un goco da ragazzi...
Questo è il punto: tradurre un intero motore grafico è una perdita di tempo 
assurda: è sufficiente scrivere delle librerie per interfacciarlo all'API 
che si vuole utilizzare. Un motore grafico scritto ingegneristicamente bene 
può tranquillamente essere in grado di funzionare su entrambe le piattaforme 
con una differenza di prestazioni minima (SS2 ad esempio). Non ho mai 
programmato un motore grafico in C, ma in Java sono riuscito pure io a fare 
spezzoni di codice funzionanti sia sotto LWJGL che sotto JOGL (poi ho 
scartato quest'ultimo perché più lento e macchinoso).


DanySK wrote:
|| motore grafico in C
Ovviamente intendevo C++, non credo sia possibile arrivare ai livelli a cui 
siamo senza un layer d'astrazione ad oggetti...


 con una differenza di prestazioni minima (SS2 ad esempio).
Cos'è SS2, System Shock 2? Comunque la fai un pò semplice...come ha detto
anche NeuralNoise, ad esempio l'Unreal3 Engine è soggetto da tempo ad un
lavoro che faccia in modo di "traghettarlo" da direct 3d a OGL... e questo
lavoro ancora non l'hanno completato. Come vedi quindi  non son tutte rose e
fiori, specie con engine 3D discretamente complessi ;-)


Alcuni vorrebbero programmare engine grafici ancora in Assembler...:))


Già... son proprio dei benefattori. LOL ;D

Lorenz wrote:
|| Alcuni vorrebbero programmare engine grafici ancora in
|| Assembler...:))
Mi viene male al solo pensiero... :D


Lorenz wrote:
|| Tutta la gestione delle primitive grafiche e della simulazione
|| dell'applicazione scenario è ad appannaggio del motore grafico...non
|| mi pare poca roba.
Ma è sempre la sola fase di preview nel lavoro di modellazione 3D. Dal 
momento in cui clicki su "Render" OpenGL può andare a prendersi un caffé.
|| Ma il tutto viene "gestito" sempre dal motore grafico interno
|| all'applicazione...la fase di rendering è solo la fase finale della
|| creazione della scena 3D.
Non ho mai visto il codice di un programma di modellazione 3D, ma dubito 
fortemente che passino per l'engine grafico nella fase di rendering finale 
(io intendo la generazione del/dei frames finali della scena). Sarebbe una 
fatica enorme IMHO. Se lo facessero peraltro si utilizzerebbe anche la 
potenza di calcolo della scheda grafica, cosa che attualmente non accade. 
Non è escluso che lo facciano in futuro (anzi...) ma è molto difficile da 
fare e comunque si rischia sempre di sbilanciare troppo il sistema.
|| Cos'è SS2, System Shock 2? Comunque la fai un pò semplice...come ha
Serious Sam 2. Funziona indifferentemente in OGL e D3D. E' il primo che m'è 
passato per la mente.
|| detto anche NeuralNoise, ad esempio l'Unreal3 Engine è soggetto da
|| tempo ad un lavoro che faccia in modo di "traghettarlo" da direct 3d
|| a OGL... e questo lavoro ancora non l'hanno completato. Come vedi
|| quindi  non son tutte rose e fiori, specie con engine 3D
|| discretamente complessi ;-)
Non so che approccio abbiano seguito con l'UE3, ma di norma se gli ing che 
ci lavorano hanno un attimo a mente la modularità del loro lavoro dovrebbero 
fare un motore che si interfaccia a delle librerie che si interfacciano ad 
una API. Questo è l'approccio che mi pare più sensato: in questo modo, il 
motore manda sempre le stesse chiamate, a seconda delle librerie che sono 
utilizzate poi queste vengono "spedite" ad OGL o D3D.
In ogni caso continuo a pensare che non sia da escludere la possibilità che 
si possa bindare D3D su OGL. Anzi.



Personalmente ho ancora qualche dubbio in proposito... almeno senza avere
nemmeno una certa perdita in prestazioni.
In ogni caso come si dice, chi vivrà vedrà...ma comunque credo che ormai
l'OGL in ambito gaming sia giunto ad un binario morto.


non intendevo questo.... (e cmq era legato al fatto delle novità che ati-amd 
sta sputando fuori...come il primo software serio per lo stream processing 
ad esempio...)


 ha scritto nel messaggio
news:ejg7fj$lon$1...@tdi.cu.mi.it...

Ma si, non vedi che avevo risposto in tono scherzoso? :)

 1- ha già rilasciato
http://sourceforge.net/projects/hlsl2glsl
-- 
I am the one hiding under your bed
Teeth ground sharp and eyes glowing red 

 
http://sourceforge.net/projects/hlsl2glsl
dovevi rispondere a lui non a me :D


Lorenz wrote:
|| Ati già sta/stava facendo degli esperimenti in proposito... con le
|| ultime Fire GL infatti avevano mostrato la possibilità di sfruttare
|| in parte la pipeline grafica durante la fase di rendering negli
|| applicativi professionali. E' solo questione di tempo perchè tale
|| processo passi maggiormente a carico della GPU di sistema. E sarebbe
|| anche ora ihmo, visto che i processori grafici sarebbero pure più
|| efficienti rispetto alle cpu general purpose per compiti del genere.
|| Darebbero un aiuto consistente.
Sicuramente darebbero una grossa mano, ma devono essere gli sviluppatori dei 
programmi di modellazione a supportare la cosa. Dovrebbero far passare 
attraverso l'engine alcune chiamate del rendering finale. Così ad occhio, 
non mi sembra molto semplice :P
|| Il primo e l'unico misà...;))  e un ogni caso l'U3E e altri recenti
|| engine sono abbastanza più complessi di quello che muove SS2.
Considera che pure io in una settimana di lavoro sono riuscito a fare un 
mini-motore in Java (renderizzava un cubo che ruota :P) che funzionava sia 
su JOGL che su LWJGL. Se ben progettato, bastano due librerie. E comunque 
sono diversi i giochi che offrono la possibilità di scegliere il renderer.
|| Beh, proponiti come programmatore alla Epic allora dato che hai le
|| idee così chiare...:)
Se mi prendono vado anche a piedi :D
In ogni caso parlavo di scelte progettuali, non di programmazione, quindi 
DEVONO assumermi direttamente come progettista :|
|| Tutto questo è facilmente fattibile in emulazione, tecnica usata
|| abbastanza anni fa quando i titoli OGL erano molto pià numerosi...
Con l'uso di librerie intermedie non si emula nulla. Va tutto in modo 
diretto. Se invece si scrive un wrapper ovviamente si va in emulazione e si 
spreca potenza.
|| un pò meno tramite chiamate dirette alle api.
Secondo me è l'inverso. Dipende come ho detto dalla metodologia di progetto 
e dagli obiettivi finali del motore, ma in genere scrivere un wrapper è 
molto più impegnativo che scrivere due librerie separate, specie se si 
conosce l'interfaccia che devono presentare al motore.
|| Personalmente ho ancora qualche dubbio in proposito... almeno senza
|| avere nemmeno una certa perdita in prestazioni.
Se lo fanno via sostituzione di librerie più che una perdita hanno una 
modificazione delle prestazioni dovuta al modo differente in cui D3D 
gestisce a basso livello delle chiamate rispetto a OGL.
Se lo fanno via wrapper ovviamente devono emulare D3D su OGL, come ogni 
emulazione avrà un certo impatto sulle prestazioni. E' inevitabile.
|| In ogni caso come si dice, chi vivrà vedrà...ma comunque credo che
|| ormai l'OGL in ambito gaming sia giunto ad un binario morto.
Io mi auguro il contrario... Specie in vista di una eventuale espansione del 
gaming verso sistemi Unix.


 non mi sembra molto semplice :P
Sempre più semplice che convertire un engine per essere supportato da due
api distinte...:)

Lorenz wrote:
|| Sempre più semplice che convertire un engine per essere supportato
|| da due api distinte...:)
Per la mia personale esperienza no. O meglio, se il progetto è stato fatto 
con in mente una certa modularità non è difficile, altrimenti ovviamente se 
si deve rimaneggiare tutto il motore è un problema enorme.


 Per la mia personale esperienza no.
Finchè si deve renderizzare solo un cubo ci credo...;D

Lorenz wrote:
|| Finchè si deve renderizzare solo un cubo ci credo...;D
Se vuoi ti passo il motore finito :P
E' stato realizzato in tre settimane da un team di tre persone (tra cui io 
ovviamente) in Java, quindi non è il massimo come prestazioni, ma di sicuro 
è capace di muovere un numero decente di cose (anche se non abbiamo avuto il 
tempo di implementare supporto a funzionalità avanzate): il modello che 
viene caricato di default è un carro armato da 270K poligoni.
Non sono (ci mancherebbe) un esperto in progettazioni e realizzazioni di 
engine grafici, ma ho comunque un'idea chiara di come ci si muove dal punto 
di vista ingegneristico. E se un progetto è ben fatto (ben modularizzato 
sarebbe meglio dire) sostituirne una parte non è difficilissimo.



L'Unreal 3 Engine ad esempio è un motore altamente "modulare" ma come vedi
dopo un paio d'anni che ci lavorano ancora non hanno effettuato il porting
alle OGL... evidentemente quindi qualche difficoltà  nel fare tutto ciò
esiste.

Lorenz wrote:
|| L'Unreal 3 Engine ad esempio č un motore altamente "modulare"
Lavori alla Epic? Mi assumi? ^_^
PS - Hai posta (~20MB)


 PS - Hai posta (~20MB)
Ancora non mi č arrivato nulla... ma non dirmi che mi vuoi mandare i vostri
lavori ;)

Lorenz wrote:
|| Ancora non mi č arrivato nulla... ma non dirmi che mi vuoi mandare i
|| vostri lavori ;)
E' il progetto che mi č valso 30L in Informatica L-B



Complimenti :))