KDE per Windows? forse sì

[^-fidel-^]

Originariamente inviato da k0nt3

http://www.opengl.org/discussion_boa...;f=12;t=000001

se questo è vero l'antitrust deve intervenire!

Direi... Non per voler sempre sparare a zero su MS, ma se la vanno poroprio a cercare!

[Cimmo]

Originariamente inviato da ^-fidel-^

Sarebbe troppo bello pensare se MS avesse potuto usare dall'inizio OpenGl invece di reinventare tutto come al solito e creare directX?
Chiedo: era il solito problema di opportunita' (tecnica "abbraccia ed espandi") oppure un problema tecnico? Escludo un vantaggio economico diretto di MS, visto che le directX (come i corrispondenti tool di sviluppo) sono sempre state closed source ma gratis.

il discorso e': se directx c'e' solo per windows e tutti le usano, tutti quelli che giocano devono usare directx e quindi windows e quindi... concludi tu...

[k0nt3]

Originariamente inviato da Cimmo

il discorso e': se directx c'e' solo per windows e tutti le usano, tutti quelli che giocano devono usare directx e quindi windows e quindi... concludi tu...

ultravero!

[^-fidel-^]

Originariamente inviato da Cimmo

il discorso e': se directx c'e' solo per windows e tutti le usano, tutti quelli che giocano devono usare directx e quindi windows e quindi... concludi tu...

Beh e' lo stesso discorso che ho fatto parlando di 'fantainformatica' nel precedente post.
Evdentemente non sono il solo a pensarla cosi'.

Cmq, mi sa che stiamo andando lentamente in OT...

[Cimmo]

Originariamente inviato da ^-fidel-^

Questo mi persuade di piu' Pero' penso, non poteva MS entrare a far parte attivamente dello sviluppo di OpenGL? Perche' guardare sempre tutti come 'nemici'? Stiamo parlando in fondo di librerie gratuite...

ci sono consorzi che sono nati con lo scopo di mantenere librerie/specifiche/software gratuiti e multiplatform, non si fanno corrompere facilmente... o almeno non per pochi soldi

[k0nt3]

Originariamente inviato da ^-fidel-^

Cmq, mi sa che stiamo andando lentamente in OT...

si stiamo andando fuori.. ma non troppo, visto che le librerie QGL sono coinvolte in questa cosa e fanno parte delle QT su cui si basano le librerie di KDE! in un certo senso è un ostacolo a usare queste librerie (tra l'altro molto comode) in win! e poi tutti i programmi KDE che lavorano sul 3D sarebbero svantaggiati!

[jappilas]

Originariamente inviato da k0nt3

@jappilas:
dimenticavo... visto che siamo in tema (a giudicare dal titolo della discussione).. se usi le librerie QGL di QT hai esattamente lo stesso codice che può essere compilato senza il minimo sforzo sulle piattaforme supportate da QT!

questo perchè QGL si occuperanno proprio di attuare un' astrazione da ciò che sta sotto
comunque, non mi riferivo al fatto che le chiamate Opengl variassero da una piattaforma all' altra (cosa che di solito non sussiste -e meno male- a maggior ragione usando framework multipiattaforma di livello ancora più alto
)
mi riferivo alle peculiarità che di solito ogni piattaforma mantiene negli altri comparti che non siano quello grafico

Originariamente inviato da ^-fidel-^

Sarebbe troppo bello pensare se MS avesse potuto usare dall'inizio OpenGl invece di reinventare tutto come al solito e creare directX?
Chiedo: era il solito problema di opportunita' (tecnica "abbraccia ed espandi") oppure un problema tecnico? Escludo un vantaggio economico diretto di MS, visto che le directX (come i corrispondenti tool di sviluppo) sono sempre state closed source ma gratis.

qui bisognerebbe tornare indietro nel tempo, all' epoca in cui Microsoft avviava e portava avanti i progetti Talisman, poi defunto, e Farenheit , e pensare perchè nel secondo, MS e SGI abbiano per un perido collaborato per la realizzazione di un nuovo set di librerie e API per grafica 2D e 3D

[k0nt3]

Originariamente inviato da jappilas

questo perchè QGL si occuperanno proprio di attuare un' astrazione da ciò che sta sotto
comunque, non mi riferivo al fatto che le chiamate Opengl variassero da una piattaforma all' altra (cosa che di solito non sussiste -e meno male- a maggior ragione usando framework multipiattaforma di livello ancora più alto
)
mi riferivo alle peculiarità che di solito ogni piattaforma mantiene negli altri comparti che non siano quello grafico

senza dubbio è come dici per QGL.. ma dimentichi che OpenGL già astrae la piattaforma a differenza di DX! certo non è un'astrazione completa, ma rende estremamente più facile la costruzione di un framework multipiattaforma completo!

Originariamente inviato da jappilas

qui bisognerebbe tornare indietro nel tempo, all' epoca in cui Microsoft avviava e portava avanti i progetti Talisman, poi defunto, e Farenheit , e pensare perchè nel secondo, MS e SGI abbiano per un perido collaborato per la realizzazione di un nuovo set di librerie e API per grafica 2D e 3D

il problema è che OGL esisteva già! è stata MS a creare qualcosa di totalmente diverso! poteva sin dall'inizio cercare di facilitare un set di API sopra ogl e dx! penso che il progetto Farenheit sia stato solo un modo per dire: almeno ci abbiamo provato! ma non c'è mai stato un reale tentativo da parte MS! lo dimostra il fatto che dal 2003 non fa più parte dell'ARB!

[jappilas]

Originariamente inviato da k0nt3

http://www.opengl.org/discussion_boa...;f=12;t=000001

se questo è vero l'antitrust deve intervenire!

se ne è parlato anche qui, in svariati thread , riassumo le conclusioni :
il supporto a opengl che MS offrirà in Vista sarà anche migliore di quello attualmente offerto dalla stessa MS nell' attuale Win XP, in cui opengl di default gira interamente via SW a meno di installare un driver accelerato
di base, opengl in Vista subirà lo stesso trattamento riservato a DirectX 9 e precedenti, cioè esecuzione tramite "wrapper"
per avere accelerazione completa (come estensioni attivabili) e più efficiente si potrà ancora ricorrere a un driver (ICD) di terze parti (produttore dell' HW) come si fa già ora normalmente
quindi, l' antitrust non avrebbe ragione di intervenire

[k0nt3]

Originariamente inviato da jappilas

se ne è parlato anche qui, in svariati thread , riassumo le conclusioni :
il supporto a opengl che MS offrirà in Vista sarà anche migliore di quello attualmente offerto dalla stessa MS nell' attuaLE Win XP,
in cui opengl di default gira interamente via SW a meno di installare un driver accelerato
di base, opengl in Vista subirà lo stesso trattamento riservato a DirectX 9 e precedenti, cioè esecuzione tramite ""wrapper"
per avere accelerazione completa (come estensioni attivabili) e più efficiente si potrà ancora ricorrere a un driver (ICD) di terze parti (produttore dell' HW) come si fa già ora normalmente
quindi, l' antitrust non ha ragione di intervenire, anzi

devi leggere http://www.opengl.org/discussion_boa...;f=12;t=000001
pare che non sia esattamente come dici (sul driver ICD)!
ma poi chi non ha un driver con accelerazione3d per opengl oggigiorno? il problema è che domani non si potrà fare a quanto ho capito! e poi la storia che non supportano ogl2 puzza!

[k0nt3]

pensate a programmi fatti in QGL, oppure a Maya o anche a OpenOffice (che usa ogl)! le ripercussioni che ha questa cosa sono devastanti! l'antitrust avrà il suo da fare!

[k0nt3]

Originariamente inviato da k0nt3

pensate a programmi fatti in QGL, oppure a Maya o anche a OpenOffice (che usa ogl)! le ripercussioni che ha questa cosa sono devastanti! l'antitrust avrà il suo da fare!

mi autoquoto perchè leggendo si dice che solo l'intefaccia aero non va con i driver opengl! però se vuoi l'interfaccia aero al momento non puoi avere driver con accelerazione3d per opengl! comunque è una penalizzazione!

[jappilas]

Originariamente inviato da k0nt3

il problema è che OGL esisteva già! è stata MS a creare qualcosa di totalmente diverso! poteva sin dall'inizio cercare di facilitare un set di API sopra ogl e dx! penso che il progetto Farenheit sia stato solo un modo per dire: almeno ci abbiamo provato! ma non c'è mai stato un reale tentativo da parte MS! lo dimostra il fatto che dal 2003 non fa più parte dell'ARB!

all' epoca (13 anni fa uno più uno meno) c' era un OS da dotare di funzioni multimediali che affiancassero, le GDI per quanto concerne la grafica, e rimpiazzassero il vetusto wave mapper per la parte sonora, dando accesso "diretto" all' HW di competenza: probabilmente se una o l' altra funzione fosse stata in partenza, più evoluta (concepita in modo più moderno) di quello che era, la sua sostituzione sarebbe stata rinviata...
invece ricordo directX nascere come blocco compatto di librerie... e quando una sw house o un programmatore si trova a dover far uscire un' intera suite di librerie e api, la cosa più logica da fare è renderla consistente al proprio interno e con il sistema operativo (a maggior ragione se componenti di esse dovranno accedere direttamente alle periferiche), tanto più che gli ambiti a cui vanno a offrire supporto (ad es il sonoro o la gestione dell'input da joystick) non è coperto da specifici standard trasversali
ora, ci si rende conto che perchè la suite di librerie sia completa, mancano alcuni componenti: soprattutto manca quello relativa alla grafica tridimensionale, e di non avere sufficiente know how per crearla dal nullla, collaborare con una società rinomata proprio nella visualizzazione 3d e per aver creato la prima implementazione di una API che tutto il mondo (meglio, tutto il mondo della visualizzazione 3d professionale) ha poi preso come standard, era la mossa più logica da fare

[mjordan]

Originariamente inviato da ^-fidel-^

Sarebbe troppo bello pensare se MS avesse potuto usare dall'inizio OpenGl invece di reinventare tutto come al solito e creare directX?
Chiedo: era il solito problema di opportunita' (tecnica "abbraccia ed espandi") oppure un problema tecnico? Escludo un vantaggio economico diretto di MS, visto che le directX (come i corrispondenti tool di sviluppo) sono sempre state closed source ma gratis.

Guarda che Microsoft usava OpenGL prima di DirectX. Le DirectX sono state imposte solo da Windows NT in poi. E, tra le altre cose, non sono state neanche create da Microsoft, ma acquisite da una società che è stata comprata. Microsoft ne ha solo portato avanti lo sviluppo. Dall'introduzione di DirectX sotto Windows, Microsoft ha cessato di supportare (e distribuire) OpenGL sotto Windows.

[k0nt3]

Originariamente inviato da jappilas

ora, ci si rende conto che perchè la suite di librerie sia completa, mancano alcuni componenti: soprattutto manca quello relativa alla grafica tridimensionale, e di non avere sufficiente know how per crearla dal nullla, collaborare con una società rinomata proprio nella visualizzazione 3d e per aver creato la prima implementazione di una API che tutto il mondo (meglio, tutto il mondo della visualizzazione 3d professionale) ha poi preso come standard, era la mossa più logica da fare

avrebbero potuto fare questo partendo da opengl! perchè reinventare la ruota? e poi sta cosa di unificare le librerie è stata fatta più o meno recentemente da opengl.. ci sono openml, openal e openil se non sbaglio! perchè distaccarsi così tanto dagli standard già esistenti (parlo di d3d in particolare)?

edit: tra l'altro non è faticoso come dici utilizzare librerie eterogenee per fare cose eterogenee! chi sviluppa in linux lo sa bene! a volte è addirittura meglio poter scegliere la libreria che più si adatta agli scopi!

[mjordan]

Comunque se vi interessano le dispute fra OpenGL e DirectX, leggete qui... Guardate che schifo...
http://www.vcnet.com/bms/features/3d.html

Leggete bene mi raccomando.

[k0nt3]

Originariamente inviato da mjordan

Comunque se vi interessano le dispute fra OpenGL e DirectX, leggete qui... Guardate che schifo...
http://www.vcnet.com/bms/features/3d.html

Leggete bene mi raccomando.

ho appena letto questo:

GL's interface is procedural: You perform operations by calling gl
functions to pass vertex data and specify primitives.

glBegin (GL_TRIANGLES);
glVertex (0,0,0);
glVertex (1,1,0);
glVertex (2,0,0);
glEnd ();

D3D's interface is by execute buffers: You build a structure
containing vertex data and commands, and pass the entire thing with a
single call. On the surface, this appears to be an efficiency
improvement for D3D, because it gets rid of a lot of procedure call
overhead. In reality, it is a gigantic pain-in-the-ass.

(pseudo code, and incomplete)
v = &buffer.vertexes[0];
v->x = 0; v->y = 0; v->z = 0; v++;
v->x = 1; v->y = 1; v->z = 0; v++;
v->x = 2; v->y = 0; v->z = 0;
c = &buffer.commands;
c->operation = DRAW_TRIANGLE;
c->vertexes[0] = 0;
c->vertexes[1] = 1;
c->vertexes[2] = 2;
IssueExecuteBuffer (buffer);

domanda 1: sono ancora così le d3d?
domanda 2: se sì... dov'è che si risparmia tempo?

[darkquasar]

Originariamente inviato da cdimauro

Semplicemente perché non esiste un porting delle DirectX per piattaforme diverse da Windows.

"semplicemente"?
Dici poco, tu...
Dentro quel "semplicemente" é racchiuso il core-business di MS...

Originariamente inviato da ^-fidel-^

Sarebbe troppo bello pensare se MS avesse potuto usare dall'inizio OpenGl invece di reinventare tutto come al solito e creare directX?
Chiedo: era il solito problema di opportunita' (tecnica "abbraccia ed espandi") oppure un problema tecnico? Escludo un vantaggio economico diretto di MS, visto che le directX (come i corrispondenti tool di sviluppo) sono sempre state closed source ma gratis.

MS poteva benissimo usare OpenGL, e la motivazione per cui hanno imposto le DirectX é proprio di carattere economico: tra l'altro é anche ovvio, visto che MS non é un'associazione di beneficenza ma una società a scopo di lucro.
Il fatto di imporre le DirectX anche regalandole, ha garantito che i videogiochi non fossero facilmente portabili su altre piattaforme, facendo rimanere Windows la piattaforma standard per il PC di casa, che in molti casi, specie quando usato da bambini/adolescenti, é usato per far girare software da ufficio/browsing/email E SOPRATTUTTO videogiochi.
Siccome quei software da ufficio/browsing/email ci sono anche su Mac e Linux, se i videogiochi fossero facilmente portabili su Mac e Linux (quelli OpenGL infatti sono stati portati), quegli utenti casalinghi non sarebbero più costretti a rimanere legati a Windows.
E siccome quella fascia di utenza é *ENORME*, ne va del business di MS.

Infatti se noti adesso che i Mac sono passati a Intel, i Mac-users sono tutti contenti perché finalmente (forse) tra poco potranno installare Windows in dual-boot e USARE I VIDEOGIOCHI, per quanto riguarda tutto il resto sono già a posto con OS-X.

[jappilas]

Originariamente inviato da mjordan

Comunque se vi interessano le dispute fra OpenGL e DirectX, leggete qui... Guardate che schifo...
http://www.vcnet.com/bms/features/3d.html

Leggete bene mi raccomando.

letto tutto or ora

ma hai visto la data ? last revised: 30 August 1998
alcune considerazioni restano valide (e mi chiariscono alcuni dettagli che il mio cervello aveva già eliminato dal buffer) , però in 7 anni e mezzo ne è passata di acqua sotto i ponti...

[mjordan]

Originariamente inviato da k0nt3

ho appena letto questo:

GL's interface is procedural: You perform operations by calling gl
functions to pass vertex data and specify primitives.

glBegin (GL_TRIANGLES);
glVertex (0,0,0);
glVertex (1,1,0);
glVertex (2,0,0);
glEnd ();

D3D's interface is by execute buffers: You build a structure
containing vertex data and commands, and pass the entire thing with a
single call. On the surface, this appears to be an efficiency
improvement for D3D, because it gets rid of a lot of procedure call
overhead. In reality, it is a gigantic pain-in-the-ass.

(pseudo code, and incomplete)
v = &buffer.vertexes[0];
v->x = 0; v->y = 0; v->z = 0; v++;
v->x = 1; v->y = 1; v->z = 0; v++;
v->x = 2; v->y = 0; v->z = 0;
c = &buffer.commands;
c->operation = DRAW_TRIANGLE;
c->vertexes[0] = 0;
c->vertexes[1] = 1;
c->vertexes[2] = 2;
IssueExecuteBuffer (buffer);

domanda 1: sono ancora così le d3d?
domanda 2: se sì... dov'è che si risparmia tempo?

Si risparmia molto tempo nelle chiamate. Chiamare le funzioni costa del tempo. Con l'approccio OpenGL che hai visto, usi 3 chiamate a glVertex(). Nell'approccio Direct3D invece riempi i valori dei vertici in un vertex buffer e lanci una sola chiamata di funzione.
Inoltre, proprio perchè i valori vengono messi dentro un'array, ci sono piu' possibilità di ottimizzazione laddove piu' chiamate singole sarebbero piu' generiche.
Per esempio, disegnare un poligono di 20 facce richiede almeno 22 chiamate di funzione. 20 per i vertici e 2 per glBegin() e glEnd(). Inoltre aggiungi che molte volte hai bisogno delle informazioni per il colore (altre 20 chiamate). Aggiungi che magari ti servono le normali alla superficie... Altre chiamate... Come vedi è facile che il numero di chiamate si moltiplica rispetto al numero di vertici...
Tuttavia anche OpenGL adesso implementa dei tipi di array per ottenere la stessa cosa. I vertex arrays, i color arrays, ecc. Ce n'è un tipo per ogni uso. Non solo vertici quindi, ma anche normali alla superficie, o le coordinate per le texture.
Si possono disegnare tutti i vertici dentro un array con una sola funzione. Inoltre le funzioni per dereferenziare un array (per esempio di vertici) non devono essere inserite fra glBegin() e glEnd() (altro risparmio di risorse). Tali array si attivano con la funzione glEnableClientState() passandogli come parametro la costante che identifica il tipo di array da usare, come ad esempio GL_VERTEX_ARRAY oppure GL_NORMAL_ARRAY oppure ancora GL_TEXTURE_COORD_ARRAY.
Non solo!!! OpenGL include anche le Display Lists, che sono piu' o meno la stessa cosa di quello che ho detto adesso, ma garantiscono un controllo ancora piu' potente e ottimizzato. Infatti le display list sono delle vere e proprie "cache di oggetti".

EDIT:

I LOVE: