Programmazione Videogame

[AnonimoVeneziano]

Originariamente inviato da supermario
anche io sono interessato

intanto ho preso il primi 25 tutorials di NeHe tradotti in ita

e il mulo mi sta aiutando per quelli di gamestutorials


dalla mia ho un manuale cartaceo di c++ e uno microsoft press per le api di win


mi serve altro???penso che quello che sto scaricando vada bene no?

col c++ sn abbastanza avanti

E' una cavolata opengl, non ti serve nient'altro

Ho iniziato ieri sera (dopo aver scoperto come fare a creare le finestre per OpenGL in maniera indolore ) e già stamattina faccio girare poligoni texturizzati per tutto lo schermo come un pazzo

Ciao

[supermario]

si l'avevo intuito che fossero facili


se le ha imparate supertondo......



con le dx cm siamo messi invece in quanto a difficoltà?

[AnonimoVeneziano]

Originariamente inviato da supermario

con le dx cm siamo messi invece in quanto a difficoltà?

Non ne ho idea, non posso programmarci con DX

Ciao

[supermario]

ah tu sei linux addicted

[gokan]

Originariamente inviato da AnonimoVeneziano
Ho trovato grazie

GLUT RULEZ

Ciao

Le GLUT sono delle ottime librerie, peccato che non siano più aggiornate..puoi dare un'occhiata alle freeglut, se dovessi avere bisogno di qualche specifica funzione..
Ciao

[AnonimoVeneziano]

Originariamente inviato da gokan
Le GLUT sono delle ottime librerie, peccato che non siano più aggiornate..puoi dare un'occhiata alle freeglut, se dovessi avere bisogno di qualche specifica funzione..
Ciao

Difatti uso le freeglut .

Non so se non sono aggiornate o cosa, sulla mia distro funzionano egregiamente.

(le glut mi sembra non fossero open source, in tal caso su debian non penso ci abbiano mai messo neanche piede )

Ciao

[supermario]

sarò scemo io ma nn riesco a trovare i 3 headers


#include <gl\gl.h>
#include <gl\glu.h>
#include <gl\glaux.h>


o meglio all'atto di compilare nn mi trova l'ultimo

chi mi da una mano???

[AnonimoVeneziano]

Non so aiutarti, perchè GLAUX è una roba specifica di Windows e ho sentito in giro che sarebbe da evitare come la peste (non so perchè) , comunque praticamente la sua unica funzione è quella di caricare le BMP in memoria (almeno fin ora nel tutorial) .

Volendo puoi caricare la BMP a mano in una struttura ed evitare GLAUX.

Ho trovato in giro le specifiche dell' HEADER del BMP qua http://www.fastgraph.com/help/bmp_header_format.html

E ci ho fatto una funzione per caricare le BMP (dato che appunto su Linux non esiste) , se non riesci a risolvere se vuoi te la passo

Ciao

[supermario]

ho risolto cmq mi interessa tantissimo la tua funzione!


può sempre servire e quindi me la studio

[^TiGeRShArK^]

mi ricordo un casino di anni fa quando avevo fatto queste funzioni per visualizzare sullo skermo BMP TIFF e TGA in c con qualke subroutine in assembly
il bello è ke ai tempi internet praticamente era allo stato embrionale e non avevo idea delle specifike di questi file....
e qdi giù di editor esadecimale x cercare di capire la struttura del file.....
alla fine se nn sbaglio semplicemente ignoravo i byte dell'header a parte quelli delle dimensioni e leggevo tutti gli altri relativi all'immagine....

pekkato ke con quelle routine assembly arrivavo max a 64 colori!

ke bei ricordi cmq!

[sliver80]

nessun "alternativo controtendenza" ?

http://xith.org/tiki-index.php
http://lwjgl.org

[AnonimoVeneziano]

Originariamente inviato da supermario
ho risolto cmq mi interessa tantissimo la tua funzione!


può sempre servire e quindi me la studio

Te la do con piacere , comunque ho scoperto che ce n'è una molto simile nel file contenente il codice per linux della lezione su Texturing (= fatica sprecata ) .

Adesso la metto un po' a posto magari basandomi un po' anche su questo codice e poi te la posto

Intanto ho una domanda .

Nella lezione sul blending il tipo dice che quello non è il metodo migliore di fare il Blending (infatti mettendoci in mezzo una superficie non trasparente sul cubo si incasina ) e che il metodo migliore sarebbe di disegnare tutto con DEPTH buffer attivo partendo dalla figura + lontana a quella + vicina . Se l'immagine è statica viene tutto OK, ma su un cubo rotante appena questo gira viene su un casino perchè l'ordine del depth buffer che gli avevo impresso si scombina .

Come si può fare??

Grazie

Ciao

EDIT: Anche un'altra cosa se qualcuno sa rispondere .

Usando come glBlendFunc GL_ALPHA_SRC e GL_ONE_MINUS_ALPHA_SRC e abilitando contemporaneamente il Lighting ottengo un effetto orribile (cubo rotante mezzo nero e mezzo opaco) , come fare?

[AnonimoVeneziano]

Mamma mia ragazzi, dopo essermi letto il tutorial 10 mi è venuta una mezza idea di scrivere un mini motorino 3D per cazzeggiare

Proprio carino OpenGL, è divertente creare mondi 3D, non credevo mi avrebbe appassionato così

Ciao

[Luc@s]

Originariamente inviato da AnonimoVeneziano

(dopo aver scoperto come fare a creare le finestre per OpenGL in maniera indolore )

Ciao

e cioè?

[AnonimoVeneziano]

Originariamente inviato da Luc@s
e cioè?

GLUT Rulez

E' veramente semplice creare finestre con GLUT, ti consiglio di leggere il sorgente di qualche lezione di NeHe per "Linux" per capire come fare a creare pure te finestre pronte per adempiere al loro dovere di contenitori di Viewport opengl

Se hai problemi chiama

Ciao

[Luc@s]

quindi...da questa base:

 
#include <GL/openglut.h>
#include <gl/gl.h>

#define W 800
#define H 600
#define TITLE "Ogl Base"

void renderScene() 
{
}

void changeSize(int w, int h) 
{
}

void idleFunc()
{
}

void processNormalKeys(unsigned char key, int x, int y) 
{
}
/*
GLUT_KEY_F1		        F1 function key
GLUT_KEY_F2		        F2 function key
GLUT_KEY_F3		        F3 function key
GLUT_KEY_F4		        F4 function key
GLUT_KEY_F5		        F5 function key
GLUT_KEY_F6		        F6 function key
GLUT_KEY_F7		        F7 function key
GLUT_KEY_F8		        F8 function key
GLUT_KEY_F9		        F9 function key
GLUT_KEY_F10		      F10 function key
GLUT_KEY_F11		      F11 function key
GLUT_KEY_F12		      F12 function key
GLUT_KEY_LEFT		      Left function key
GLUT_KEY_RIGHT	      Up function key
GLUT_KEY_UP		        Right function key
GLUT_KEY_DOWN		      Down function key
GLUT_KEY_PAGE_UP      Page Up function key
GLUT_KEY_PAGE_DOWN	  Page Down function key
GLUT_KEY_HOME		      Home function key
GLUT_KEY_END		      End function key
GLUT_KEY_INSERT		    Insert function key
*/
void processSpecialKeys(int key, int x, int y) 
{
}



int main(int argc, char **argv)
{
	glutInit(&argc, argv);
	
	glutInitDisplayMode(GLUT_DEPTH | GLUT_SINGLE | GLUT_RGBA);
	
	glutInitWindowPosition(100,100);
	glutInitWindowSize(W,H);
	
	glutCreateWindow(TITLE);
	
	glutDisplayFunc(renderScene);
	glutReshapeFunc(changeSize);
	glutIdleFunc(idleFunc);
	glutKeyboardFunc(processNormalKeys);
	glutSpecialFunc(processSpecialKeys);	


	glutMainLoop();
	return 0;
}

Parto per tutto senza curarmi di creare la finestra?

[AnonimoVeneziano]

si, diciamo di si

Ciao

[Luc@s]

Originariamente inviato da AnonimoVeneziano
si, diciamo di si

Ciao

cosa non hai detto in questa frase?

[fek]

Originariamente inviato da AnonimoVeneziano
Nella lezione sul blending il tipo dice che quello non è il metodo migliore di fare il Blending (infatti mettendoci in mezzo una superficie non trasparente sul cubo si incasina ) e che il metodo migliore sarebbe di disegnare tutto con DEPTH buffer attivo partendo dalla figura + lontana a quella + vicina . Se l'immagine è statica viene tutto OK, ma su un cubo rotante appena questo gira viene su un casino perchè l'ordine del depth buffer che gli avevo impresso si scombina .

Come si può fare??

Non si fa'

E' uno dei problemi tosti della grafica in real time, bisogna convivere con l'impossibilita' di ordinare i frammenti trasparenti per pixel in maniera efficiente ancora per qualche anno.
Al massimo puoi ordinare per primitiva, ma il cubo che ruota ti dara' sempre e comunque problemi.

Ordina le primitive trasparenti dalla piu' lontana alla piu' vicina (quelle non trasparenti al contrario) e spera che i problemi non si vedano.

Esistono tecniche di depth peeling per risolvere il problema, ma richiedono troppo passate ed in tempo reale sono ancora troppo costase. Qualche anno ancora...

[supermario]

Originariamente inviato da fek
Non si fa'

E' uno dei problemi tosti della grafica in real time, bisogna convivere con l'impossibilita' di ordinare i frammenti trasparenti per pixel in maniera efficiente ancora per qualche anno.
Al massimo puoi ordinare per primitiva, ma il cubo che ruota ti dara' sempre e comunque problemi.

Ordina le primitive trasparenti dalla piu' lontana alla piu' vicina (quelle non trasparenti al contrario) e spera che i problemi non si vedano.

Esistono tecniche di depth peeling per risolvere il problema, ma richiedono troppo passate ed in tempo reale sono ancora troppo costase. Qualche anno ancora...

come dire.......resitete ragazzi