Newsgroup: it.comp.lang.c++
Titolo: applicazione opengl e classi c++

Ciao,
provo a spiegare concisamente quello che ho in mente di fare.
Diciamo che sono pratico di C++ e della programmazione modulare.
Ora mi sto apprestando alla realizzazione di un progetto che utilizzi
le OGL ed il C++.
Più precisamente la mia applicazione dovrà fare uso delle GLUT che
sono scritte in C e io vorrei utilizzarle con un approccio OOP usando
le classi.
Non avendo mai programmato con le API in questione non riesco a
strutturare questo approccio.
Cioè le funzioni di inizializzazione delle OGL (glutInit,
glutInitDisplayMode, glutInitWindowSize, glutCreateWindow, ecc.)
possono essere messe nel costruttore di una classe base, o dovranno
essere all'interno della classe ma facenti parte di una funzione
membro (es. initOGL()) che richiamerò dal Main.
Bhè a questo punto mi chiedo, allora il costruttore a che serve?
Cercando in rete ho visto che le funzioni sopra citate sono messe nel
Main e poi sono richiamate le callback tramite le varie
glutDisplayFunc et simila (sempre nel Main).
Avreste dei consigli in merito? Esistono linee guida in proposito?
Quale è secondo voi l'approccio migliore?
Non so se sono riuscito a spiegarmi, forse sono ancora troppo
confuso.. spero di non aver scritto solo sciocchezze.
Ah il progetto riguarda un gioco 3d per cui dovrò gestire diverse cose
come luci, ombre, oggetti nella scena e comandi da mouse e tastiera..
Queste cose possono essere implementate come classi o sottoclassi di
una classe base? Con quali vincoli?
ps: se avete a disposizione qualche link specifico sulle OGL e l'OOP
magari con qualche esempio di qualche piccola applicazione ve ne sarei
immensamente grato.
Grazie e scusate la lunghezza del post.

 immensamente grato.
Non vedo particolari difficoltà nell'inglobare l'init openGL in un 
costruttore. Crea un oggetto MyRenderingSurface il cui costruttore 
prende come argomento l'handle della finestra del tuo gioco e crea una 
rendering surface openGL. Poi userai i metodi dell'oggetto 
MyRenderingSurface per rendere a video i vari elementi visibili del gioco.
I tutorial NeHe sull'OpenGL sono un classico.
http://nehe.gamedev.net/
A parte tutto però, se hai davvero intenzione di creare un gioco 3D ti 
consiglio caldamente di NON partire dalle OpenGL ma di usare un motore 
3D già pronto (ce ne sono tanti e pure buoni. Uno per tutti: OGRE) e di 
usare il tuo tempo e il tuo ingegno per creare dei buoni modelli 3D, 
delle buone texture e delle scene originali. Una scena 3D che abbia una 
pretesa di verosimiglianza ha bisogno di circa 500 texture diverse, di 
varie dimensioni: in tutto ne dovrai creare o trovare diverse migliaia.
Oltre a queste dovrai creare una IA per governare i mostri, un database 
gerarchico per gli oggetti nelle scene, l'audio, gestore collisioni e 
motore fisico, l'interazione con la tastiera e il mouse ecc. ecc. ecc... 
credimi, cerca assolutamente di perdere meno tempo possibile con la 
programmazione: anche così il lavoro da fare sarà colossale.

 programmazione: anche così il lavoro da fare sarà colossale.
La mia deve essere un applicazione incentrata sulle openGL, che faccia
uso delle sole GL, GLU, GLUT.
Inoltre, io devo proprio creare classi per un'applicazione
*specifica*. Quindi una mia, semplice, libreria.
grazie per il tuo aiuto :)

 Scusa ma non capisco bene... potresti fare un esempio per favore?
Dipende da cosa decidi che il tuo RenderingSurface debba fare e da come 
decidi che deve farlo. Se dovrà tenere traccia LUI di quali oggetti 
esistono e chiamare i loro metodi per disegnarli, il costruttore 
allocherà una lista (o quel che è) di puntatori o di reference (o quel 
che è) agli oggetti da disegnare. Se invece decidi che il 
RenderingSurface non ha responsabilità e il disegno lo farà qualche 
altro componente, una volta che il rendering context GL è pronto, il 
costruttore ha più o meno finito.
Alcuni design pattern che ti possono essere utili: Chain of 
Responsibility, Visitor, Command, Factory.
http://it.wikipedia.org/wiki/Design_pattern


grazie per il tuo aiuto.
Ora sto prendendo spunto da questo articolo:
http://paulsolt.com/2009/07/openglglut-classes-oop-and-problems/
mi sembra un buon punto di partenza.