Busca en google algo llamado heaven7 para ver raytracing en tiempo real en tu
maquina. Eso si, todo codeado en asm. Hyay mucho mas ejemplos si buscas en
google


> De:: "Miguel A. Torres" <mikemex_ask@...>
> Para: war_3d@yahoogroups.com
> Asunto:: Re: [war_3d]  Re: [war_3d] Re:  Re: [war 3d] Re: Re: [war 3d] Re:
[war 3d] Pequeña mejor a en seno coseno y mas comentarios
> BCC: 09/09/2004

> También es retrógrada pensar que no hace falta optimizar, pues las
> máquinas ya son "demasiado rápidas". Eso es completamente falso
> y se ha
> demostrado muchas veces. "Entre más tienes, más quieres".
>
> Yo me inicié en estos negocios con una máquina Pentium 66, de 8 mb
> creo, con la cuál podía abrir corel photopait 5 y hacer mil maravillas
> (anda, y no recuerdo que se alentara ni tantito). Despues tuve una
> Pentium 166 MMX y me corría el Quake 2 por software (con una tarjeta de
> esas cutres de 1 MB). Teóricamente, con mi computadora actual de 1.1
> GHz, ya debería poder hacer raytracing en tiempo real. Pero no...
>
> Saludos.
>
>  --- qualopec@... escribió:
> >
> >
> > _Personalemente_ me parece que codear en ASM es un atraso gradisimo
> y
> > mucho mas cuando las maquinas que vienen (ya han venido :P) son VLIW.
> > Una de dos, o sabes muy bien como funciona la maquina (unidades d
> > ejecucion, tamaño del pipeline, politicas de saltos, algoritmos de
> > planificacion....) y programas en asm o dejas al compilador que haga
> > ese trabajo. Incluso los dsp que trabajan en tiempo real se codean
> en
> > C y eso que son maquinas mucho mas especificas que un procesador de
> > proposito general como los que tenemos en casa.
> >
> > No obstante no he dicho q eso no optimice, optimizara seguro, pero
> me
> > refiero si merece la pena en cuanto a esfuerzo/resultados y si no
> > habria que mirar antes cosas de algoritmos (que no depende para nada
> > de la maquina) en vez de mirar detalles de codificacion. Que quede
> > clara mi postura por dios, no estoy en contra de optimizar el war3d.
> >
> > un saludo
> >
> > > De:: "JOSE GERARDO PALMA DURAN, ESCUELA TECNICA SUPERIOR
> DE
> > INFORMATICA" <jgpd16@...>
> > > Para: war_3d@yahoogroups.com
> > > Asunto:: [war_3d] Re:  Re: [war 3d] Re: Re: [war 3d] Re: [war
> 3d]
> > Pequeña mejor a en seno coseno y mas comentarios
> > > BCC: 07/09/2004
> >
> > > Lo que dije "chupa maquina", son los castings de float
>  a int,
> > > no es coña es
> > > una brutalidad, puede ser un cuello de botella para la aplicacion,
> > el
> > > compilador internamente llama a una funcion llama
> > > _ftol().
> > > Lo que yo hago es hacer esto
> > >
> > > _asm
> > > {
> > > fld f
> > > fistp i
> > > }
> > >
> > > donde f es el flotante e i es el entero.
> > >
> > > Por cierto lo de mi libreria matematica en un test que he hecho
> sin
> > usar
> > >
> > > extensiones MMX o SIMD(todavia no las he metido), es un 1200%
> mas
> > rapida
> > > que
> > > una en c compilada con visual studio 2003,(en cuestiones de
> > optimizacion
> > >
> > > solo lo supera el VectorPC, que usa SIMD...), así que bueno tu
> > mismo si
> > >
> > > dices que eso no va a optimizar.
> > >
> > > Lo del sonido ya lo tratare de adaptar a lo actual para que no
> haya
> > que
> > >
> > > modificar nada. Lo del callback lo he usado en algunas demos
> mias y
> > me
> > >
> > > funciono...
> > >
> > > Otro tema es reservar memoria con un gestor de memoria propio,
> y
> > otra cosa
> > >
> > > es tambien alinear la memoria al tamaño de una palabra, asi
> > evitaremos
> > >
> > > tonterias.
> > >
> > > Tampoco he visto si usamos 2.4 o 2.4f por ejemplo, (con 2.4f
> es mas
> > rapido,
> > >
> > > evitas casting de double a float,(double 64 bits, float 32)).
> > Tampoco me
> > > he
> > > fijado es cosas de divisiones, pero probablemente se pueda mejorar,
> > como
> > >
> > > sabemos es mas rapido lo siguiente
> > >
> > > float x = 1.0f/valor;
> > > for(int i=0;i<algo;++i)
> > > inverso[i] *=x;
> > >
> > > que
> > >
> > > for(int i=0;i<algo;++i)
> > > inverso[i]/=valor;
> > >
> > >
> > > En todo el codigo en asm que he usado no he puesto ninguna
> > instruccion
> > > que
> > > solo sea de intel o de amd, ya que no he usado extensiones tipo
> > 3dnow,
> > > o
> > > SEE3, asi que debe funcionar en TODOS los ordenadores que sean
> > compatibles
> > >
> > > con intel desde el 486 para arriba.
> > > Hay alguna otras optimizaciones en asm, pero bueno paro por el
> > momento.
> > >
> > >
> > >
> > >
> > > _____________________________________
> > > WAR3D -> <A HREF="<A HREF="http://war3d.sourceforge.net/"
> TARGET="_blank">http://war3d.sourceforge.net/</A>"
> > TARGET="_blank"><A HREF="http://war3d.sourceforge.net/&lt;/A&gt;"
> TARGET="_blank">http://war3d.sourceforge.net/</A></A>
> > >
> > > Si quieres cancelar tu suscripcion, envia un mensaje a
> > war_3d-unsubscribe@yahoogroups.com
> > > _____________________________________
> > > Enlaces a Yahoo! Grupos
> > >
> > >
> > >     war_3d-unsubscribe@yahoogroups.com
> > >
> > >     <A HREF="<A HREF="http://es.docs.yahoo.com/info/utos.html"
> TARGET="_blank">http://es.docs.yahoo.com/info/utos.html</A>"
> > TARGET="_blank"><A HREF="http://es.docs.yahoo.com/info/utos.html&lt;/A&gt;"
> TARGET="_blank">http://es.docs.yahoo.com/info/utos.html</A></A>
> >
> >
>
>
> _____________________________________
> WAR3D -> <A HREF="http://war3d.sourceforge.net/"
TARGET="_blank">http://war3d.sourceforge.net/</A>
>
> Si quieres cancelar tu suscripcion, envia un mensaje a
war_3d-unsubscribe@yahoogroups.com
> _____________________________________
> Enlaces a Yahoo! Grupos
>
>
>     war_3d-unsubscribe@yahoogroups.com
>
>     <A HREF="http://es.docs.yahoo.com/info/utos.html"
TARGET="_blank">http://es.docs.yahoo.com/info/utos.html</A>

jgpd16 wrote:
> Bueno me he descargado el codigo con el cvs(como anonimo el tortoise
> de los huevos no me rula, y el ssh no me vale, ademas hay algo
> parecido en win al export?¿),

siempre tienes cygwin, y usar el CVS de cygwin, yo tengo ese y turtoise,
y un cliente grafico de cvs que es un poco tontorron (al final tengo que
usar *siempre* la opcion "tools->linea de comandos" y hacer lo mismo que
haria desde linea de comandos)

con cygwin tienes export

otra opcion son las MSYS, que vienen con el minisistema gnu ese de gcc
que se llama ...mierda, ahora no recuerdo el nombre. Y tal.

quizas en dos dias el cvs se pasa de moda y todos nos pasamos a
subversion, monotone o una cosa mejor que inventen (incluso
suficientemente buena para torpes como yo)

Ya se que deberia estudiar, pero cuando empiezo ha hacer cosas que
me gustan paso de lo que no me gusta,(aunque se me de bien :P).

Ya he modificado mi programa de reproduccion de sonido para uqe use
pthread y permite lo siguiente:

1º Cargar una lista de sonidos para toda la aplicacion(WAV)
2º Cargar sonidos independientes(WAV)
3º Cargar ficheros de musica.(OGG)
La carga de ficheros de sonido wav muy largos tiene como principal
problema que no se tiene tanto control sobre ellos.

Las caracteristicas son.

Para 1º Reproduce sonidos de una lista que cargamos al programa
mediante un fichero de configuracion de sonidos, de un determinado
formato. Problema que presenta hemos de saber todos los sonidos
basicos. Beneficios, para sonidos de por ejemplo el menu, o de picar
con el raton, es mucho más rápido, ya que lo unico que hace es crear
una fuente.(La propia clase autogestiona las fuentes libres y las
libera si estan libres,esto no es obligatorio, pero me parece buena
idea).

Para 2º Carga sonidos desde un fichero WAV, puedo hacer que los lea
desde memoria, la clase genera un buffer y una fuente nueva, tras
terminar la muestra destruye ambos buffer y fuente.(Si lo hacemos
desde memoria aumenta velocidad a la hora de reproducir el sonido,
así por ejemplo al arrancar la aplicacion o pantalla cargamos
sonidos que vayamos a usar y solo lo pasariamos a la funcion en vez
de tener que abrir y cerar el fichero, asi que decidme si vamos a
usar eso, para implementarlo en la clase).

Para 3º (No esta terminado, pero creo que me estoy luciendo :P).
Permite reproducir canciones ogg mediante la tecnica de doble
buffer, las canciones puede tener loop(por ahora esta por defecto,
pero se puede cambiar sin problema). Se puede parar, pausar,
continuar, iniciar sonando o sin sonar cada cancion de forma
independiente(para todas las canciones tambien lo voy a hacer, así
como para un grupo de canciones :D). Mañana no creo que haga nada
(tengo un examen el viernes), así que probablemente(si no me surge
alguna borrachera eventual), para el sabado este terminado mi
programa, tras lo cual empezare a modificar el del war.

PREGUNTA IMPORTANTE: ¿vamos a implementar un gestor de memoria para
el juego?, lo pregunto ya que uso memoria alineada para evitar
lecturas innecesarias en memoria, y como en linux no esta la funcion
_aligned_malloc, la tengo que implentar(no es problema, es
facilito), si vamos a usar un gestor de memoria para el juego,
prefiero usar new y delete ya que supuestamente si se usa un gestor
los sobreescribiremos, así que si me lo decir será de gran ayuda.

Bueno me he descargado el codigo con el cvs(como anonimo el tortoise
de los huevos no me rula, y el ssh no me vale, ademas hay algo
parecido en win al export?¿), le he hechado un vistado al sonido y
he pensado como adaptar lo mio al juego, y para el refresco de los
bufferes se crearia una hebra para cada ogg, que seria la encargada
de cargar los bufferes(sencillito), ahora en la clase tengo puesto
dos tipos prinicipales de musica la que se repite y no se repite,
¿por qué?, es sencillo, como encolamos los bufferes si especificamos
LOOP al reproducir, al terminar el ultimo buffer se quedaria este
reproduciendo, asi que se comprueba el estado(la clase tiene una
propia maquina de estados) que se encarga si se ha especificado
loop, que al terminar, vuelve al principio y empieza de nuevo.
Ella sola se encarga de poner las fuentes y los bufferes, ademas
para musica lo logico es que no tenga posicion, aunque tambien se le
puede especificar con un tipo que hice llamado localizacion(lo hice
pensando por si un personaje o algo se movia o nos interesaba, por
ejemplo si lleva un walkman o algo por el estilo poder actualizar la
musica o sonido a su posicion correcta).

Por experiencia personal, recomiendo para sonidos pequeños wav, como
pasos, disparor, gritos, ya que alut facilita la tarea, para musica
se usaria lo que tengo hecho con las modificaciones del multihebrado
(de hecho me gusta mas así:)).

Para terminar el ogg reservado , hay dos formas, liberando el
fichero ogg, sin liberarlo, la primera es para cuando no se va a
cargar mas y la segunda la hice principalmente para el loop.

Bueno me voy a poner a trabajar en esto(dadme algunos dias que estoy
de examenes). Cuando lo tenga, si he conseguido que rule el ssh
tratare se subirlo, sino le mandare el codigo a zeru para que lo
ponga él. Venga que ya vereis como queda de PM.

Respecto a optimizar, zeru ha dado la mejor opinion que se podia
dar, optimizar pero al final(ya lo dice un libro que es una obra
maestra game coding complete).(por cierto gcc podra ser muy bueno,
pero te recuerdo que se trata de que tire bien en todos los sitios
posibles, y no todos los compiladores optimizan tanto, así que si
quieres algo que valga para todo, se prodria tratar de  hacer una
libreria en nasm..., pero al final, primero que rule el juego).

Tambien he estado pensando en meterle algun efecto chulo, como una
aura o algo, a las unidades mas "bestias"(que bueno es el stencil
buffer).

Tambien estaria bien tratar de organizar la malla para que la pinte
en un vertex array usando triangles_strip(eso si mejoraria un huevo
el pintado), o sino se puede en los modelos debido a la animacion
con huesos, al menos el mapa y edificios sin animacion. He leido un
algoritmo hoy para eso, aunque la verdad no me enterao mucho(maldito
ingles).

Por cierto respecto al nombre llamadme Raistlin Majere(joder que
friki!!!!!!) Eso es todo.

Dejar de darle al pico malditos coders... A TRABAJAR.
Si esque no se os puede dejar sueltos...

También es retrógrada pensar que no hace falta optimizar, pues las
máquinas ya son "demasiado rápidas". Eso es completamente falso y se ha
demostrado muchas veces. "Entre más tienes, más quieres".

Yo me inicié en estos negocios con una máquina Pentium 66, de 8 mb
creo, con la cuál podía abrir corel photopait 5 y hacer mil maravillas
(anda, y no recuerdo que se alentara ni tantito). Despues tuve una
Pentium 166 MMX y me corría el Quake 2 por software (con una tarjeta de
esas cutres de 1 MB). Teóricamente, con mi computadora actual de 1.1
GHz, ya debería poder hacer raytracing en tiempo real. Pero no...

Saludos.

  --- qualopec@... escribió:
>
>
> _Personalemente_ me parece que codear en ASM es un atraso gradisimo y
> mucho mas cuando las maquinas que vienen (ya han venido :P) son VLIW.
> Una de dos, o sabes muy bien como funciona la maquina (unidades d
> ejecucion, tamaño del pipeline, politicas de saltos, algoritmos de
> planificacion....) y programas en asm o dejas al compilador que haga
> ese trabajo. Incluso los dsp que trabajan en tiempo real se codean en
> C y eso que son maquinas mucho mas especificas que un procesador de
> proposito general como los que tenemos en casa.
>
> No obstante no he dicho q eso no optimice, optimizara seguro, pero me
> refiero si merece la pena en cuanto a esfuerzo/resultados y si no
> habria que mirar antes cosas de algoritmos (que no depende para nada
> de la maquina) en vez de mirar detalles de codificacion. Que quede
> clara mi postura por dios, no estoy en contra de optimizar el war3d.
>
> un saludo
>
> > De:: "JOSE GERARDO PALMA DURAN, ESCUELA TECNICA SUPERIOR DE
> INFORMATICA" <jgpd16@...>
> > Para: war_3d@yahoogroups.com
> > Asunto:: [war_3d] Re:  Re: [war 3d] Re: Re: [war 3d] Re: [war 3d]
> Pequeña mejor a en seno coseno y mas comentarios
> > BCC: 07/09/2004
>
> > Lo que dije "chupa maquina", son los castings de float  a int,
> > no es coña es
> > una brutalidad, puede ser un cuello de botella para la aplicacion,
> el
> > compilador internamente llama a una funcion llama
> > _ftol().
> > Lo que yo hago es hacer esto
> >
> > _asm
> > {
> > fld f
> > fistp i
> > }
> >
> > donde f es el flotante e i es el entero.
> >
> > Por cierto lo de mi libreria matematica en un test que he hecho sin
> usar
> >
> > extensiones MMX o SIMD(todavia no las he metido), es un 1200% mas
> rapida
> > que
> > una en c compilada con visual studio 2003,(en cuestiones de
> optimizacion
> >
> > solo lo supera el VectorPC, que usa SIMD...), así que bueno tu
> mismo si
> >
> > dices que eso no va a optimizar.
> >
> > Lo del sonido ya lo tratare de adaptar a lo actual para que no haya
> que
> >
> > modificar nada. Lo del callback lo he usado en algunas demos mias y
> me
> >
> > funciono...
> >
> > Otro tema es reservar memoria con un gestor de memoria propio, y
> otra cosa
> >
> > es tambien alinear la memoria al tamaño de una palabra, asi
> evitaremos
> >
> > tonterias.
> >
> > Tampoco he visto si usamos 2.4 o 2.4f por ejemplo, (con 2.4f es mas
> rapido,
> >
> > evitas casting de double a float,(double 64 bits, float 32)).
> Tampoco me
> > he
> > fijado es cosas de divisiones, pero probablemente se pueda mejorar,
> como
> >
> > sabemos es mas rapido lo siguiente
> >
> > float x = 1.0f/valor;
> > for(int i=0;i<algo;++i)
> > inverso[i] *=x;
> >
> > que
> >
> > for(int i=0;i<algo;++i)
> > inverso[i]/=valor;
> >
> >
> > En todo el codigo en asm que he usado no he puesto ninguna
> instruccion
> > que
> > solo sea de intel o de amd, ya que no he usado extensiones tipo
> 3dnow,
> > o
> > SEE3, asi que debe funcionar en TODOS los ordenadores que sean
> compatibles
> >
> > con intel desde el 486 para arriba.
> > Hay alguna otras optimizaciones en asm, pero bueno paro por el
> momento.
> >
> >
> >
> >
> > _____________________________________
> > WAR3D -> <A HREF="http://war3d.sourceforge.net/"
> TARGET="_blank">http://war3d.sourceforge.net/</A>
> >
> > Si quieres cancelar tu suscripcion, envia un mensaje a
> war_3d-unsubscribe@yahoogroups.com
> > _____________________________________
> > Enlaces a Yahoo! Grupos
> >
> >
> >     war_3d-unsubscribe@yahoogroups.com
> >
> >     <A HREF="http://es.docs.yahoo.com/info/utos.html"
> TARGET="_blank">http://es.docs.yahoo.com/info/utos.html</A>
>
>

Bueno, como todavia no puedo mirar en el cvs escribo unas cosillas
para el fichero SoundServer.cpp.
En el constructor la parte de
#ifdef _WIN32

   alutInit(0,NULL);
   alGetError();

...

Seria mejor poner
Device = alcOpenDevice((ALubyte*)"DirectSound3D");
//No creo que una tarjeta actual de sonido no soporte Dsound.

Efectivamente, veo que los ogg los cargais enteros en memoria,(un
poco bestia). asi qeu bueno, la solución es algo complicada, ya
que
hay que hacer una serie de funciones que usaremos como callbacks,
y unas cosillas mas, luego tendremos que iniciar cargar, y luego
para actuliazar los bufferes tendriamos que ponerlo dentro de un
bucle(bucle principal), o en todo caso crear una hebra o algo por el
estilo, que se encargue de actualizar los bufferes.
Aqui pongo el codigo que he hecho(teneis mi permiso pa usarlo):

Para el fichero en memoria creo una structura llamada MYFILE

/*
Esta estructura es utilizada para la carga de musica comprimida.
Esta estructura almacena la longitud total del fichero comprimido
así
como su posición actual.
*/
struct MFILE
{
	 long  m_longitudtotal;

	 //Longitud total de la muestra
	 long  m_posactual;

	 //La posicion actual en la que se encuentra reproduciendo
	 char  *m_datos;

	 //Puntero que contiene los datos
	 bool  abre(const std::string nombre);
	 bool  destruye();
	 ~MFILE();
};

/********************************************************************
****/
/*
MFILE                                 */
/********************************************************************
****/
/*
Abre el fichero y lo carga en memoria
*/
bool MFILE::abre(const std::string nombre)
{
	 FILE *fi = fopen(nombre.c_str(),"rb");
	 if(fi==NULL)
	 {
		 printf("ERROR, no existe el fichero\n");
		 return false;
	 }
	 fseek(fi,0,SEEK_END);
	 m_longitudtotal = ftell(fi);
	 rewind(fi);
	 m_datos = (char*)_aligned_malloc(sizeof(char)
*m_longitudtotal,16);
	 if(!m_datos)
		 return false;
	 fread(m_datos,sizeof(char),m_longitudtotal,fi);
	 fclose(fi);
	 m_posactual = 0;
	 return true;
}
/*
Destruye el fichero si contiene informacion la elimina
*/
bool MFILE::destruye()
{
	 if(m_datos!=NULL)
		 _aligned_free(m_datos);
	 m_longitudtotal = 0;
	 m_posactual = 0;
	 return true;
}
/*
Destructor de la clase;
*/
MFILE::~MFILE()
{
	 if(m_datos!=NULL)
		 _aligned_free(m_datos);
}

(quitad los _aligned_malloc y free por lo que useis(new o malloc, da
igual).


A continuacion pongo las callbacks necesarias

/********************************************************************
****/
/*                         CALLBACKS PARA
OGG                           */
/********************************************************************
****/
/*
	 Funcion de posicionamiento:
		 Abstrae el posicionamiento de la funcion fseek.
		 Se realiza desde la memoria, esta es lineal y ademas
alineada.
*/
int    funcion_seek(void *mfile,ogg_int64_t offset,int whence)
{
	 switch(whence)
	 {
	 case 0://SET
		 ((MFILE*)mfile)->m_posactual = (long)offset;
		 break;
	 case 1://CUR
		 if(offset+((MFILE*)mfile)->m_posactual<=((MFILE*)
mfile)->m_longitudtotal)
			 ((MFILE*)mfile)->m_posactual = ((MFILE*)
mfile)->m_posactual + (long)offset;
		 else
			 ((MFILE*)mfile)->m_posactual = ((MFILE*)
mfile)->m_longitudtotal;
		 break;
	 case 2://END
		 ((MFILE*)mfile)->m_posactual = ((MFILE*)mfile)-
>m_longitudtotal+(long)offset;
		 break;
	 default:
		 return -1;
	 }
	 return 0;
}
/*
	 Funcion de posicion:
		 Indica cual es la posicion actual en el vector.
		 Abstrae el funcionamiento de ftell();
*/
long   funcion_tell(void *mfile)
{
	 return ((MFILE*)mfile)->m_posactual;
}
/*
	 Funcion de cierre:
		 Como no queremos tener que recargar el contenido en
memoria, para
		 el cierre lo que hacemos es posicionar la posicion
actual en 0
		 así las funciones de lectura simplemnte no sabran
que se ha cerrado
		 ni nada por el estilo.
		 Para la eliminacion del contenido de mfile habria
que llamar a destruye
*/
int   funcion_close(void *mfile)
{
	 ((MFILE*)mfile)->m_posactual=0;
	 return 1;
}
/*
	 Funcion de lectura:
		 Tiene comprobaciones de que no se ha llegado al
final del array,
		 o si por algún caso se ha producido un error y hemos
sobrepasado
		 el limite.
		 Sino realiza en memcpu del buffer en buf simulando
la lectura desde
		 el disco solo que es desde memoria
*/
size_t funcion_lectura(void *buf,size_t size,size_t nmeb,void *mfile)
{
	 if(((MFILE*)mfile)->m_posactual == ((MFILE*)mfile)-
>m_longitudtotal)
	 {
		 return 0;
	 }
	 if(((MFILE*)mfile)->m_posactual > ((MFILE*)mfile)-
>m_longitudtotal)
	 {
		 return -1;
	 }
	 long disponible = ((MFILE*)mfile)->m_longitudtotal -
((MFILE*)mfile)->m_posactual;
	 long pedido = (long)(nmeb*size);
	 long datos_a_leer = disponible>pedido?pedido:disponible;
	 memcpy(buf,&(((MFILE*)mfile)->m_datos[((MFILE*)mfile)-
>m_posactual]),datos_a_leer*sizeof(char));
	 ((MFILE*)mfile)->m_posactual+=datos_a_leer;
	 return datos_a_leer;
}

Para mi reproductor tengo una clase ogg(si no creais que pq haya
dicho de usar asm, no uso c++, de hecho la libreria matematica esa
usa una interfaz de c++)

la clase es largo y complicado para ponerlo aqui, asi que pongo lo
que hace.

tengo un miembro de la clase que se llama
m_call, que es del tipo ov_callback

asi abro el fichero con MFILE, y despues hago:

	 m_call.close_func = funcion_close;
	 m_call.read_func  = funcion_lectura;
	 m_call.seek_func  = funcion_seek;
	 m_call.tell_func  = funcion_tell;

para abrir el fichero ogg usamos

ov_open_callbacks(m_mfichero,&m_ogg,NULL,0,m_call);

donde m_mfichero es del tipo MFILE.

La diferencia es la siguiente:

fichero ogg de 4 megas
metodo:  todo el fichero en memoria,
          memoria      30 megas
          cpu           2%
metodo:  leer del disco duro lo necesario
          memoria       0 megas
          cpu           99%
metodo:  leer con callback
          memoria       2 megas
          cpu           6%

La diferencia a mi me parece aceptable.

Hay dos tipos de maquinas:

   - limitadas por CPU
   - limitadas por GPU

las primeras tienen una tarjeta que puede dibujar lo que le eches, al ser
la GPU un procesador separado con su memoria separada acaba antes y se
pega casi todo el tiempo aburrida leyendo revistas porno

las segundas tienen una tarjeta mala, asi que la pobre se dedica a
dibujar poligonos intentando llegar a tiempo para dibujar un frame.

las maquinas viejas, estilo mas viejas que p200, estan limitadas por CPU
los ordenadores normales suelen estar limitados por GPU

la optimizacion de sincos y todas las que se hagan de este estilo VALEN
para el caso de aparatos limitados por CPU, cuando el cuello de botella
esta en la cpu, esto sera normalmente ordenadores antiguos, especialmente
aquellos que el opengl o gran parte del opengl lo tienen que emular por
software

y por ahi, opino...


Miguel A. Torres wrote:

> Caray, que cachetón te oiste diciendo que C++ es un lenguaje de verdad,
> y que nosotros, los pendejos, programamos en C/ensamblador.
>
> ¿Cuándo llegarán esos pregonando que, si hay Visual Basic, los demás
> lenguajes ya no tienen sentido?
>
> Saludos.
>
>  --- qualopec@... escribió:
>
>>
>>
>>Lo de usar asm en los senos y cosenos es mas viejo que el cagar y la
>>verdad, no creo q vaya a umentar el rendimiento del war como para
>>andar perdiendo el tiempo, yo antes quitaría todos los glVertex3f y
>>pondría unos vertex array como mínimo antes de hacer nada en el
>>apartado de optimizaciones.
>>
>>Con respecto a lo del puntero a función, no olvides que usa c++, que
>>es un lenguaje de verdad y por lo tanto puedes usar abstracción sin
>>ningún tipo de problemas evitando tener que guarrear el código con
>>punteros a funciones...  Además en el caso de hacer un fade en los
>>cambios de pantalla ya no podrías usar el mecanismo de cambiar el
>>callback de GLUT.
>>
>>Lo del sonido que dices tiene buena pinta.
>>
>>un saludo, ethernet
>>
>>
>>
>>>De:: "jgpd16" <jgpd16@...>
>>>Para: war_3d@yahoogroups.com
>>>Asunto:: [war_3d] Pequeña mejora en seno coseno y mas comentarios
>>>BCC: 07/09/2004
>>
>>>Como supongo que muchos sabreis la fpu tiene la posibilidad de
>>>realizar el seno y el coseno de un angulo dado al mismo tiempo,
>>>ahorrando muchisimos ciclos de reloj(casi la mitad del tiempo).
>>>Para las funciones que usan sin y cos,matrices,etc he desarrollado
>>>(todavia sigo)una libreria matematica (esta casi toda en asm, y es
>>>rapidisima, el problema es que es VC inline) y bueno se me ha
>>>ocurrido poner la funcion sincos en asm inline de VC,
>>>
>>>void sincos(float val,float *sine,float *cosine)
>>>{
>>> _asm
>>> {
>>>  mov  eax,cosine
>>>  mov  edx,sine
>>>  fld  val
>>>  fwait
>>>  fsincos
>>>  fwait
>>>  fstp [eax]
>>>  fstp [edx]
>>> }
>>>}
>>>
>>>Bueno eso para VC, para Gas que es que usa gcc seria algo distinto
>>>por motivos de la sintaxis AT&L que usa(que fea coño), asi la
>>>funcion quedaria algo parecido al
>>>
>>>void sincos(float val,float *sine,float *cosine)
>>>{
>>>#ifndef WIN32
>>>
>>> _asm
>>> {
>>>  mov  eax,cosine
>>>  mov  edx,sine
>>>  fld  val
>>>  fwait
>>>  fsincos
>>>  fwait
>>>  fstp [eax]
>>>  fstp [edx]
>>> }
>>>#elseif defined /*pondriamos otras macros que definen los
>>>compiladores */
>>>/*Codigo en asm en linea*/
>>>#endif
>>>}
>>>
>>>
>>>Tendriamos una funcion que se llamaria de la siguiente forma
>>>
>>>sincos(angulo,&seno,&coseno);
>>>
>>>y nos devolveria el seno y el coseno del angulo y ademas es muy
>>>rapida.
>>>
>>>Estaria bien tratar de optimizar alguna que otra funcion
>>
>>matematica,
>>
>>>tambien (no se si lo hareis así ahora mismo) para pintar la
>>
>>pantalla
>>
>>>usar punteros a funciones, así se ahorrarian comprobaciones if
>>>inutiles que son tan importantes a la hora de pintar
>>>asi el GlutDisplayloquesea(no manejo glut, wgl y glx :P mira que
>>
>>soy
>>
>>>raro) tendriamos por ejemplo un puntero a funcion generico
>>>void (*PintaPantalla)(void);
>>>Y según el estado del juego hariamos algo parecido a
>>>PintaPantalla = PintaMenu;
>>>PintaPantalla = PintaSinglePlayer;
>>>etc.
>>>y la llamada en glut seria algo como
>>>glutDisplayWindow(PintaPantalla);(Repito no se glut, no me gusta).
>>>
>>>Digo esto pq no me deja descargar el codigo anonimamente y no le he
>>
>>>pasao a Zeru mi nombre de Sourceforge y no he podio ver el codigo
>>
>>de
>>
>>>forma comoda.
>>>
>>>Otra cuestion, para el sonido usais ogg y openal, pero ¿cargais el
>>>fichero de audio entero en memoria y lo leeis?, ¿lo leeis desde el
>>>disco duro poco a poco o cargais el fichero ogg y despues lo que
>>>haceis es ir encolando bufferes de sonido para su reproduccion?,
>>>(como consecuencia se usa muy poca memoria y es muy rapido)(el
>>>fichero ogg, no mas de 3MG y dos bufferes de como mucho 8KB cada
>>>uno). Es que tengo hecho un reproductor de Ogg con OpenAl que usa
>>>eso, si os interesa y no teneis algo por el estilo podria pasarlo,
>>>de hecho tengo intencion en usarlo en un juego que estoy haciendo
>>>por mi cuenta(ya tengo casi terminado el editor :), por ciero la
>>>funcion sincos esta mas que provada en el editor para las
>>>rotaciones).
>>>
>>>Cuando tenga el codigo le hechare un ojillo por encima a ver que
>>>puedo aportar, que llevo un tiempo en el grupo y no he hecho na,
>>>bueno si compilarlo en suse pero soy tan perro que no escribi ni
>>>como lo hice.
>>>
>>>Por cierto mi cuenta en sourceforge en Raistmaj asi que ya sabes
>>>Zeru :). Si quereis comentarme algo personalmente mi correo:
>>>gmail.com 1
>>>@ 2
>>>Raistmaj 3
>>>
>>>El orden (es logico) es 321.(esto lo hago por si acaso hay spam).
>>>
>>>
>>>
>>>
>>>
>>>_____________________________________
>>>WAR3D -> <A HREF="http://war3d.sourceforge.net/"
>>
>>TARGET="_blank">http://war3d.sourceforge.net/</A>
>>
>>>Si quieres cancelar tu suscripcion, envia un mensaje a
>>
>>war_3d-unsubscribe@yahoogroups.com
>>
>>>_____________________________________
>>>Enlaces a Yahoo! Grupos
>>>
>>>
>>>    war_3d-unsubscribe@yahoogroups.com
>>>
>>>    <A HREF="http://es.docs.yahoo.com/info/utos.html"
>>
>>TARGET="_blank">http://es.docs.yahoo.com/info/utos.html</A>
>>
>>
>
>
> _________________________________________________________

_Personalemente_ me parece que codear en ASM es un atraso gradisimo y mucho mas
cuando las maquinas que vienen (ya han venido :P) son VLIW. Una de dos, o sabes
muy bien como funciona la maquina (unidades d ejecucion, tamaño del pipeline,
politicas de saltos, algoritmos de planificacion....) y programas en asm o dejas
al compilador que haga ese trabajo. Incluso los dsp que trabajan en tiempo real
se codean en C y eso que son maquinas mucho mas especificas que un procesador de
proposito general como los que tenemos en casa.

No obstante no he dicho q eso no optimice, optimizara seguro, pero me refiero si
merece la pena en cuanto a esfuerzo/resultados y si no habria que mirar antes
cosas de algoritmos (que no depende para nada de la maquina) en vez de mirar
detalles de codificacion. Que quede clara mi postura por dios, no estoy en
contra de optimizar el war3d.

un saludo

> De:: "JOSE GERARDO PALMA DURAN, ESCUELA TECNICA SUPERIOR DE INFORMATICA"
<jgpd16@...>
> Para: war_3d@yahoogroups.com
> Asunto:: [war_3d] Re:  Re: [war 3d] Re: Re: [war 3d] Re: [war 3d] Pequeña
mejor a en seno coseno y mas comentarios
> BCC: 07/09/2004

> Lo que dije "chupa maquina", son los castings de float  a int,
> no es coña es
> una brutalidad, puede ser un cuello de botella para la aplicacion, el
> compilador internamente llama a una funcion llama
> _ftol().
> Lo que yo hago es hacer esto
>
> _asm
> {
> fld f
> fistp i
> }
>
> donde f es el flotante e i es el entero.
>
> Por cierto lo de mi libreria matematica en un test que he hecho sin usar
>
> extensiones MMX o SIMD(todavia no las he metido), es un 1200% mas rapida
> que
> una en c compilada con visual studio 2003,(en cuestiones de optimizacion
>
> solo lo supera el VectorPC, que usa SIMD...), así que bueno tu mismo si
>
> dices que eso no va a optimizar.
>
> Lo del sonido ya lo tratare de adaptar a lo actual para que no haya que
>
> modificar nada. Lo del callback lo he usado en algunas demos mias y me
>
> funciono...
>
> Otro tema es reservar memoria con un gestor de memoria propio, y otra cosa
>
> es tambien alinear la memoria al tamaño de una palabra, asi evitaremos
>
> tonterias.
>
> Tampoco he visto si usamos 2.4 o 2.4f por ejemplo, (con 2.4f es mas rapido,
>
> evitas casting de double a float,(double 64 bits, float 32)). Tampoco me
> he
> fijado es cosas de divisiones, pero probablemente se pueda mejorar, como
>
> sabemos es mas rapido lo siguiente
>
> float x = 1.0f/valor;
> for(int i=0;i<algo;++i)
> inverso[i] *=x;
>
> que
>
> for(int i=0;i<algo;++i)
> inverso[i]/=valor;
>
>
> En todo el codigo en asm que he usado no he puesto ninguna instruccion
> que
> solo sea de intel o de amd, ya que no he usado extensiones tipo 3dnow,
> o
> SEE3, asi que debe funcionar en TODOS los ordenadores que sean compatibles
>
> con intel desde el 486 para arriba.
> Hay alguna otras optimizaciones en asm, pero bueno paro por el momento.
>
>
>
>
> _____________________________________
> WAR3D -> <A HREF="http://war3d.sourceforge.net/"
TARGET="_blank">http://war3d.sourceforge.net/</A>
>
> Si quieres cancelar tu suscripcion, envia un mensaje a
war_3d-unsubscribe@yahoogroups.com
> _____________________________________
> Enlaces a Yahoo! Grupos
>
>
>     war_3d-unsubscribe@yahoogroups.com
>
>     <A HREF="http://es.docs.yahoo.com/info/utos.html"
TARGET="_blank">http://es.docs.yahoo.com/info/utos.html</A>

Lo que dije "chupa maquina", son los castings de float  a int, no es coña es
una brutalidad, puede ser un cuello de botella para la aplicacion, el
compilador internamente llama a una funcion llama
_ftol().
Lo que yo hago es hacer esto

_asm
{
fld f
fistp i
}

donde f es el flotante e i es el entero.

Por cierto lo de mi libreria matematica en un test que he hecho sin usar
extensiones MMX o SIMD(todavia no las he metido), es un 1200% mas rapida que
una en c compilada con visual studio 2003,(en cuestiones de optimizacion
solo lo supera el VectorPC, que usa SIMD...), así que bueno tu mismo si
dices que eso no va a optimizar.

Lo del sonido ya lo tratare de adaptar a lo actual para que no haya que
modificar nada. Lo del callback lo he usado en algunas demos mias y me
funciono...

Otro tema es reservar memoria con un gestor de memoria propio, y otra cosa
es tambien alinear la memoria al tamaño de una palabra, asi evitaremos
tonterias.

Tampoco he visto si usamos 2.4 o 2.4f por ejemplo, (con 2.4f es mas rapido,
evitas casting de double a float,(double 64 bits, float 32)). Tampoco me he
fijado es cosas de divisiones, pero probablemente se pueda mejorar, como
sabemos es mas rapido lo siguiente

float x = 1.0f/valor;
for(int i=0;i<algo;++i)
inverso[i] *=x;

que

for(int i=0;i<algo;++i)
inverso[i]/=valor;


En todo el codigo en asm que he usado no he puesto ninguna instruccion que
solo sea de intel o de amd, ya que no he usado extensiones tipo 3dnow, o
SEE3, asi que debe funcionar en TODOS los ordenadores que sean compatibles
con intel desde el 486 para arriba.
Hay alguna otras optimizaciones en asm, pero bueno paro por el momento.

mucho tiempo de maquina? de que maquina? en nada (o ya :) tenemos maquinas q ya
no son cisc, ademas como sabras el compilador, tiene mucho que ver en eso. Creo
que debemos dejarnos de esas optimizaciones, muchas veces infundados y
recapacitar en cosas mas grandes como por ejemplo el dibjado del terreno que a
mi modo de ver es mas lento q el caballo del malo (echadlo un vistazo). Aunque
la verdad pienso q antes se deberia terminar el war no? almenos el nucleo para
que se pueda jugar > De:: "JOSE GERARDO PALMA DURAN, ESCUELA TECNICA SUPERIOR DE
INFORMATICA" > Para: war_3d@yahoogroups.com > Asunto:: [war_3d] Re: Pequeña
mejora en seno coseno y mas comentarios > BCC: 07/09/2004 > Bueno ya se que
tiene mas años que el cagar, pero 1º mejoraria a lo mejor > un > 1 por ciento,
tambien tengo tecnicas para acelerar los casting de int a > > float, que pierde
mucho tiempo la maquina. > > Y ya que estamos podemos usar vertex buffer object
que eso si aceleraria > los > graficos en vez de v

----- Original Message -----

From: qualopec@...

To: war_3d@yahoogroups.com

Sent: Tuesday, September 07, 2004 3:34 AM

Subject: [war_3d] Re: [war 3d] Pequeña mejora en seno coseno y mas comentarios

     
Lo de usar asm en los senos y cosenos es mas viejo que el cagar y la verdad, no creo q vaya a umentar el rendimiento del war como para andar perdiendo el tiempo, yo antes quitaría todos los glVertex3f y pondría unos vertex array como mínimo antes de hacer nada en el apartado de optimizaciones.

Con respecto a lo del puntero a función, no olvides que usa c++, que es un lenguaje de verdad y por lo tanto puedes usar abstracción sin ningún tipo de problemas evitando tener que guarrear el código con punteros a funciones...  Además en el caso de hacer un fade en los cambios de pantalla ya no podrías usar el mecanismo de cambiar el callback de GLUT.

Lo del sonido que dices tiene buena pinta.

un saludo, ethernet


> De:: "jgpd16" <jgpd16@...>
> Para: war_3d@yahoogroups.com
> Asunto:: [war_3d] Pequeña mejora en seno coseno y mas comentarios
> BCC: 07/09/2004

> Como supongo que muchos sabreis la fpu tiene la posibilidad de
> realizar el seno y el coseno de un angulo dado al mismo tiempo,
> ahorrando muchisimos ciclos de reloj(casi la mitad del tiempo).
> Para las funciones que usan sin y cos,matrices,etc he desarrollado
> (todavia sigo)una libreria matematica (esta casi toda en asm, y es
> rapidisima, el problema es que es VC inline) y bueno se me ha
> ocurrido poner la funcion sincos en asm inline de VC,
>
> void sincos(float val,float *sine,float *cosine)
> {
>  _asm
>  {
>   mov  eax,cosine
>   mov  edx,sine
>   fld  val
>   fwait
>   fsincos
>   fwait
>   fstp [eax]
>   fstp [edx]
>  }
> }
>
> Bueno eso para VC, para Gas que es que usa gcc seria algo distinto
> por motivos de la sintaxis AT&L que usa(que fea coño), asi la
> funcion quedaria algo parecido al
>
> void sincos(float val,float *sine,float *cosine)
> {
> #ifndef WIN32
>
>  _asm
>  {
>   mov  eax,cosine
>   mov  edx,sine
>   fld  val
>   fwait
>   fsincos
>   fwait
>   fstp [eax]
>   fstp [edx]
>  }
> #elseif defined /*pondriamos otras macros que definen los
> compiladores */
> /*Codigo en asm en linea*/
> #endif
> }
>
>
> Tendriamos una funcion que se llamaria de la siguiente forma
>
> sincos(angulo,&seno,&coseno);
>
> y nos devolveria el seno y el coseno del angulo y ademas es muy
> rapida.
>
> Estaria bien tratar de optimizar alguna que otra funcion matematica,
> tambien (no se si lo hareis así ahora mismo) para pintar la pantalla
> usar punteros a funciones, así se ahorrarian comprobaciones if
> inutiles que son tan importantes a la hora de pintar
> asi el GlutDisplayloquesea(no manejo glut, wgl y glx :P mira que soy
> raro) tendriamos por ejemplo un puntero a funcion generico
> void (*PintaPantalla)(void);
> Y según el estado del juego hariamos algo parecido a
> PintaPantalla = PintaMenu;
> PintaPantalla = PintaSinglePlayer;
> etc.
> y la llamada en glut seria algo como
> glutDisplayWindow(PintaPantalla);(Repito no se glut, no me gusta).
>
> Digo esto pq no me deja descargar el codigo anonimamente y no le he
> pasao a Zeru mi nombre de Sourceforge y no he podio ver el codigo de
> forma comoda.
>
> Otra cuestion, para el sonido usais ogg y openal, pero ¿cargais el
> fichero de audio entero en memoria y lo leeis?, ¿lo leeis desde el
> disco duro poco a poco o cargais el fichero ogg y despues lo que
> haceis es ir encolando bufferes de sonido para su reproduccion?,
> (como consecuencia se usa muy poca memoria y es muy rapido)(el
> fichero ogg, no mas de 3MG y dos bufferes de como mucho 8KB cada
> uno). Es que tengo hecho un reproductor de Ogg con OpenAl que usa
> eso, si os interesa y no teneis algo por el estilo podria pasarlo,
> de hecho tengo intencion en usarlo en un juego que estoy haciendo
> por mi cuenta(ya tengo casi terminado el editor :), por ciero la
> funcion sincos esta mas que provada en el editor para las
> rotaciones).
>
> Cuando tenga el codigo le hechare un ojillo por encima a ver que
> puedo aportar, que llevo un tiempo en el grupo y no he hecho na,
> bueno si compilarlo en suse pero soy tan perro que no escribi ni
> como lo hice.
>
> Por cierto mi cuenta en sourceforge en Raistmaj asi que ya sabes
> Zeru :). Si quereis comentarme algo personalmente mi correo:
> gmail.com 1
> @ 2
> Raistmaj 3
>
> El orden (es logico) es 321.(esto lo hago por si acaso hay spam).
>
>
>
>
>
> _____________________________________
> WAR3D -> <A HREF="http://war3d.sourceforge.net/" TARGET="_blank">http://war3d.sourceforge.net/</A>
>
> Si quieres cancelar tu suscripcion, envia un mensaje a war_3d-unsubscribe@yahoogroups.com
> _____________________________________
> Enlaces a Yahoo! Grupos
>
>
>     war_3d-unsubscribe@yahoogroups.com
>
>     <A HREF="http://es.docs.yahoo.com/info/utos.html" TARGET="_blank">http://es.docs.yahoo.com/info/utos.html</A>



_____________________________________
WAR3D -> http://war3d.sourceforge.net/

Si quieres cancelar tu suscripcion, envia un mensaje a war_3d-unsubscribe@yahoogroups.com
_____________________________________

Bueno ya se que tiene mas años que el cagar, pero 1º mejoraria a lo mejor un
1 por ciento, tambien tengo tecnicas para acelerar los casting de int a
float, que pierde mucho tiempo la maquina.

Y ya que estamos podemos usar vertex buffer object que eso si aceleraria los
graficos en vez de vertex array normalitos. Para eso propongo usar glew.



Miguel A. Torres writes:

Caray, que cachetón te oiste diciendo que C++ es un lenguaje de verdad,
y que nosotros, los pendejos, programamos en C/ensamblador.

¿Cuándo llegarán esos pregonando que, si hay Visual Basic, los demás
lenguajes ya no tienen sentido?

Saludos.

  --- qualopec@... escribió:
>
>
> Lo de usar asm en los senos y cosenos es mas viejo que el cagar y la
> verdad, no creo q vaya a umentar el rendimiento del war como para
> andar perdiendo el tiempo, yo antes quitaría todos los glVertex3f y
> pondría unos vertex array como mínimo antes de hacer nada en el
> apartado de optimizaciones.
>
> Con respecto a lo del puntero a función, no olvides que usa c++, que
> es un lenguaje de verdad y por lo tanto puedes usar abstracción sin
> ningún tipo de problemas evitando tener que guarrear el código con
> punteros a funciones...  Además en el caso de hacer un fade en los
> cambios de pantalla ya no podrías usar el mecanismo de cambiar el
> callback de GLUT.
>
> Lo del sonido que dices tiene buena pinta.
>
> un saludo, ethernet
>
>
> > De:: "jgpd16" <jgpd16@...>
> > Para: war_3d@yahoogroups.com
> > Asunto:: [war_3d] Pequeña mejora en seno coseno y mas comentarios
> > BCC: 07/09/2004
>
> > Como supongo que muchos sabreis la fpu tiene la posibilidad de
> > realizar el seno y el coseno de un angulo dado al mismo tiempo,
> > ahorrando muchisimos ciclos de reloj(casi la mitad del tiempo).
> > Para las funciones que usan sin y cos,matrices,etc he desarrollado
> > (todavia sigo)una libreria matematica (esta casi toda en asm, y es
> > rapidisima, el problema es que es VC inline) y bueno se me ha
> > ocurrido poner la funcion sincos en asm inline de VC,
> >
> > void sincos(float val,float *sine,float *cosine)
> > {
> >  _asm
> >  {
> >   mov  eax,cosine
> >   mov  edx,sine
> >   fld  val
> >   fwait
> >   fsincos
> >   fwait
> >   fstp [eax]
> >   fstp [edx]
> >  }
> > }
> >
> > Bueno eso para VC, para Gas que es que usa gcc seria algo distinto
> > por motivos de la sintaxis AT&L que usa(que fea coño), asi la
> > funcion quedaria algo parecido al
> >
> > void sincos(float val,float *sine,float *cosine)
> > {
> > #ifndef WIN32
> >
> >  _asm
> >  {
> >   mov  eax,cosine
> >   mov  edx,sine
> >   fld  val
> >   fwait
> >   fsincos
> >   fwait
> >   fstp [eax]
> >   fstp [edx]
> >  }
> > #elseif defined /*pondriamos otras macros que definen los
> > compiladores */
> > /*Codigo en asm en linea*/
> > #endif
> > }
> >
> >
> > Tendriamos una funcion que se llamaria de la siguiente forma
> >
> > sincos(angulo,&seno,&coseno);
> >
> > y nos devolveria el seno y el coseno del angulo y ademas es muy
> > rapida.
> >
> > Estaria bien tratar de optimizar alguna que otra funcion
> matematica,
> > tambien (no se si lo hareis así ahora mismo) para pintar la
> pantalla
> > usar punteros a funciones, así se ahorrarian comprobaciones if
> > inutiles que son tan importantes a la hora de pintar
> > asi el GlutDisplayloquesea(no manejo glut, wgl y glx :P mira que
> soy
> > raro) tendriamos por ejemplo un puntero a funcion generico
> > void (*PintaPantalla)(void);
> > Y según el estado del juego hariamos algo parecido a
> > PintaPantalla = PintaMenu;
> > PintaPantalla = PintaSinglePlayer;
> > etc.
> > y la llamada en glut seria algo como
> > glutDisplayWindow(PintaPantalla);(Repito no se glut, no me gusta).
> >
> > Digo esto pq no me deja descargar el codigo anonimamente y no le he
>
> > pasao a Zeru mi nombre de Sourceforge y no he podio ver el codigo
> de
> > forma comoda.
> >
> > Otra cuestion, para el sonido usais ogg y openal, pero ¿cargais el
> > fichero de audio entero en memoria y lo leeis?, ¿lo leeis desde el
> > disco duro poco a poco o cargais el fichero ogg y despues lo que
> > haceis es ir encolando bufferes de sonido para su reproduccion?,
> > (como consecuencia se usa muy poca memoria y es muy rapido)(el
> > fichero ogg, no mas de 3MG y dos bufferes de como mucho 8KB cada
> > uno). Es que tengo hecho un reproductor de Ogg con OpenAl que usa
> > eso, si os interesa y no teneis algo por el estilo podria pasarlo,
> > de hecho tengo intencion en usarlo en un juego que estoy haciendo
> > por mi cuenta(ya tengo casi terminado el editor :), por ciero la
> > funcion sincos esta mas que provada en el editor para las
> > rotaciones).
> >
> > Cuando tenga el codigo le hechare un ojillo por encima a ver que
> > puedo aportar, que llevo un tiempo en el grupo y no he hecho na,
> > bueno si compilarlo en suse pero soy tan perro que no escribi ni
> > como lo hice.
> >
> > Por cierto mi cuenta en sourceforge en Raistmaj asi que ya sabes
> > Zeru :). Si quereis comentarme algo personalmente mi correo:
> > gmail.com 1
> > @ 2
> > Raistmaj 3
> >
> > El orden (es logico) es 321.(esto lo hago por si acaso hay spam).
> >
> >
> >
> >
> >
> > _____________________________________
> > WAR3D -> <A HREF="http://war3d.sourceforge.net/"
> TARGET="_blank">http://war3d.sourceforge.net/</A>
> >
> > Si quieres cancelar tu suscripcion, envia un mensaje a
> war_3d-unsubscribe@yahoogroups.com
> > _____________________________________
> > Enlaces a Yahoo! Grupos
> >
> >
> >     war_3d-unsubscribe@yahoogroups.com
> >
> >     <A HREF="http://es.docs.yahoo.com/info/utos.html"
> TARGET="_blank">http://es.docs.yahoo.com/info/utos.html</A>
>
>

_________________________________________________________
Do You Yahoo!?
La mejor conexión a internet y 25MB extra a tu correo por $100 al mes.
http://net.yahoo.com.mx

Lo de usar asm en los senos y cosenos es mas viejo que el cagar y la verdad, no
creo q vaya a umentar el rendimiento del war como para andar perdiendo el
tiempo, yo antes quitaría todos los glVertex3f y pondría unos vertex array como
mínimo antes de hacer nada en el apartado de optimizaciones.

Con respecto a lo del puntero a función, no olvides que usa c++, que es un
lenguaje de verdad y por lo tanto puedes usar abstracción sin ningún tipo de
problemas evitando tener que guarrear el código con punteros a funciones... 
Además en el caso de hacer un fade en los cambios de pantalla ya no podrías usar
el mecanismo de cambiar el callback de GLUT.

Lo del sonido que dices tiene buena pinta.

un saludo, ethernet


> De:: "jgpd16" <jgpd16@...>
> Para: war_3d@yahoogroups.com
> Asunto:: [war_3d] Pequeña mejora en seno coseno y mas comentarios
> BCC: 07/09/2004

> Como supongo que muchos sabreis la fpu tiene la posibilidad de
> realizar el seno y el coseno de un angulo dado al mismo tiempo,
> ahorrando muchisimos ciclos de reloj(casi la mitad del tiempo).
> Para las funciones que usan sin y cos,matrices,etc he desarrollado
> (todavia sigo)una libreria matematica (esta casi toda en asm, y es
> rapidisima, el problema es que es VC inline) y bueno se me ha
> ocurrido poner la funcion sincos en asm inline de VC,
>
> void sincos(float val,float *sine,float *cosine)
> {
>  _asm
>  {
>   mov  eax,cosine
>   mov  edx,sine
>   fld  val
>   fwait
>   fsincos
>   fwait
>   fstp [eax]
>   fstp [edx]
>  }
> }
>
> Bueno eso para VC, para Gas que es que usa gcc seria algo distinto
> por motivos de la sintaxis AT&L que usa(que fea coño), asi la
> funcion quedaria algo parecido al
>
> void sincos(float val,float *sine,float *cosine)
> {
> #ifndef WIN32
>
>  _asm
>  {
>   mov  eax,cosine
>   mov  edx,sine
>   fld  val
>   fwait
>   fsincos
>   fwait
>   fstp [eax]
>   fstp [edx]
>  }
> #elseif defined /*pondriamos otras macros que definen los
> compiladores */
> /*Codigo en asm en linea*/
> #endif
> }
>
>
> Tendriamos una funcion que se llamaria de la siguiente forma
>
> sincos(angulo,&seno,&coseno);
>
> y nos devolveria el seno y el coseno del angulo y ademas es muy
> rapida.
>
> Estaria bien tratar de optimizar alguna que otra funcion matematica,
> tambien (no se si lo hareis así ahora mismo) para pintar la pantalla
> usar punteros a funciones, así se ahorrarian comprobaciones if
> inutiles que son tan importantes a la hora de pintar
> asi el GlutDisplayloquesea(no manejo glut, wgl y glx :P mira que soy
> raro) tendriamos por ejemplo un puntero a funcion generico
> void (*PintaPantalla)(void);
> Y según el estado del juego hariamos algo parecido a
> PintaPantalla = PintaMenu;
> PintaPantalla = PintaSinglePlayer;
> etc.
> y la llamada en glut seria algo como
> glutDisplayWindow(PintaPantalla);(Repito no se glut, no me gusta).
>
> Digo esto pq no me deja descargar el codigo anonimamente y no le he
> pasao a Zeru mi nombre de Sourceforge y no he podio ver el codigo de
> forma comoda.
>
> Otra cuestion, para el sonido usais ogg y openal, pero ¿cargais el
> fichero de audio entero en memoria y lo leeis?, ¿lo leeis desde el
> disco duro poco a poco o cargais el fichero ogg y despues lo que
> haceis es ir encolando bufferes de sonido para su reproduccion?,
> (como consecuencia se usa muy poca memoria y es muy rapido)(el
> fichero ogg, no mas de 3MG y dos bufferes de como mucho 8KB cada
> uno). Es que tengo hecho un reproductor de Ogg con OpenAl que usa
> eso, si os interesa y no teneis algo por el estilo podria pasarlo,
> de hecho tengo intencion en usarlo en un juego que estoy haciendo
> por mi cuenta(ya tengo casi terminado el editor :), por ciero la
> funcion sincos esta mas que provada en el editor para las
> rotaciones).
>
> Cuando tenga el codigo le hechare un ojillo por encima a ver que
> puedo aportar, que llevo un tiempo en el grupo y no he hecho na,
> bueno si compilarlo en suse pero soy tan perro que no escribi ni
> como lo hice.
>
> Por cierto mi cuenta en sourceforge en Raistmaj asi que ya sabes
> Zeru :). Si quereis comentarme algo personalmente mi correo:
> gmail.com 1
> @ 2
> Raistmaj 3
>
> El orden (es logico) es 321.(esto lo hago por si acaso hay spam).
>
>
>
>
>
> _____________________________________
> WAR3D -> <A HREF="http://war3d.sourceforge.net/"
TARGET="_blank">http://war3d.sourceforge.net/</A>
>
> Si quieres cancelar tu suscripcion, envia un mensaje a
war_3d-unsubscribe@yahoogroups.com
> _____________________________________
> Enlaces a Yahoo! Grupos
>
>
>     war_3d-unsubscribe@yahoogroups.com
>
>     <A HREF="http://es.docs.yahoo.com/info/utos.html"
TARGET="_blank">http://es.docs.yahoo.com/info/utos.html</A>

Como supongo que muchos sabreis la fpu tiene la posibilidad de
realizar el seno y el coseno de un angulo dado al mismo tiempo,
ahorrando muchisimos ciclos de reloj(casi la mitad del tiempo).
Para las funciones que usan sin y cos,matrices,etc he desarrollado
(todavia sigo)una libreria matematica (esta casi toda en asm, y es
rapidisima, el problema es que es VC inline) y bueno se me ha
ocurrido poner la funcion sincos en asm inline de VC,

void sincos(float val,float *sine,float *cosine)
{
	 _asm
	 {
		 mov  eax,cosine
		 mov  edx,sine
		 fld  val
		 fwait
		 fsincos
		 fwait
		 fstp [eax]
		 fstp [edx]
	 }
}

Bueno eso para VC, para Gas que es que usa gcc seria algo distinto
por motivos de la sintaxis AT&L que usa(que fea coño), asi la
funcion quedaria algo parecido al

void sincos(float val,float *sine,float *cosine)
{
#ifndef WIN32

	 _asm
	 {
		 mov  eax,cosine
		 mov  edx,sine
		 fld  val
		 fwait
		 fsincos
		 fwait
		 fstp [eax]
		 fstp [edx]
	 }
#elseif defined /*pondriamos otras macros que definen los
compiladores */
/*Codigo en asm en linea*/
#endif
}


Tendriamos una funcion que se llamaria de la siguiente forma

sincos(angulo,&seno,&coseno);

y nos devolveria el seno y el coseno del angulo y ademas es muy
rapida.

Estaria bien tratar de optimizar alguna que otra funcion matematica,
tambien (no se si lo hareis así ahora mismo) para pintar la pantalla
usar punteros a funciones, así se ahorrarian comprobaciones if
inutiles que son tan importantes a la hora de pintar
asi el GlutDisplayloquesea(no manejo glut, wgl y glx :P mira que soy
raro) tendriamos por ejemplo un puntero a funcion generico
void (*PintaPantalla)(void);
Y según el estado del juego hariamos algo parecido a
PintaPantalla = PintaMenu;
PintaPantalla = PintaSinglePlayer;
etc.
y la llamada en glut seria algo como
glutDisplayWindow(PintaPantalla);(Repito no se glut, no me gusta).

Digo esto pq no me deja descargar el codigo anonimamente y no le he
pasao a Zeru mi nombre de Sourceforge y no he podio ver el codigo de
forma comoda.

Otra cuestion, para el sonido usais ogg y openal, pero ¿cargais el
fichero de audio entero en memoria y lo leeis?, ¿lo leeis desde el
disco duro poco a poco o cargais el fichero ogg y despues lo que
haceis es ir encolando bufferes de sonido para su reproduccion?,
(como consecuencia se usa muy poca memoria y es muy rapido)(el
fichero ogg, no mas de 3MG y dos bufferes de como mucho 8KB cada
uno). Es que tengo hecho un reproductor de Ogg con OpenAl que usa
eso, si os interesa y no teneis algo por el estilo podria pasarlo,
de hecho tengo intencion en usarlo en un juego que estoy haciendo
por mi cuenta(ya tengo casi terminado el editor :), por ciero la
funcion sincos esta mas que provada en el editor para las
rotaciones).

Cuando tenga el codigo le hechare un ojillo por encima a ver que
puedo aportar, que llevo un tiempo en el grupo y no he hecho na,
bueno si compilarlo en suse pero soy tan perro que no escribi ni
como lo hice.

Por cierto mi cuenta en sourceforge en Raistmaj asi que ya sabes
Zeru :). Si quereis comentarme algo personalmente mi correo:
gmail.com 1
@ 2
Raistmaj 3

El orden (es logico) es 321.(esto lo hago por si acaso hay spam).

Hola Sigo trabajando en la conexion del War al IRC, estoy haciendo implementando los comandos del IRC, JOIN, PART, QUIT, NICK, PRIVMSG, PING, PONG ya saben, Ya me faltan pocos, bueno en realidad faltan muchos, pero solo estoy implementando los que vamos a usar.

Tambien estoy implementando las listas de Canales y las listas de Nicks dentro de los canales. ETC.

Archivos modificados este fin de semana:

W3DIRCCliente.cpp
W3DIRCCliente.h
IRCcomunicaciones.cpp
IRCcomunicaciones.h
IRCcomandos.cpp
IRCcomandos.h

Estos archivos aun no son parte del proyecto, lo seran cuando termine con ellos. Por ahora hice un nuevo proyecto con main en IRCBorrame.cpp

CVS Actualizado, Main.rar NO Actualizado.

Saludos.

ZeruGiran E-Mail: zerugiran@... MSN: eric@... Tel: 04455-18243353 (Telcel) Web: Perfil

_____________________________________
WAR3D -> http://war3d.sourceforge.net/

Si quieres cancelar tu suscripcion, envia un mensaje a war_3d-unsubscribe@yahoogroups.com
_____________________________________

Patrocinio de Yahoo! Grupos

---

Enlaces a Yahoo! Grupos

• Para visitar tu grupo en la web, accede a :
  http://es.groups.yahoo.com/group/war_3d/
   
• Para cancelar tu suscripción a este grupo, envía un mensaje a:
  war_3d-unsubscribe@yahoogroups.com
   
• El uso que hagas de Yahoo! Grupos está sujeto a las Condiciones del servicio de Yahoo!.

Hay 1 mensaje en este resumen.

Temas de este resumen:

1. War3D Inteface
De: ZeruGiran


________________________________________________________________________
________________________________________________________________________

Mensaje: 1
Fecha: Fri, 27 Aug 2004 23:32:17 -0500
De: ZeruGiran
Asunto: War3D Inteface

Hola:

He estado trabajando un poco en el codigo del war que se conecta a un
servidor IRC, desde el cual se organizaran las partidas. Ya tengo
algunas cosas hechas y es hora de ponerlas junto al codigo del war. Pero
para ello necesito varias cosas una de ellas es un memo o textbox en
donde colocar el texto de las charlas del irc.

Es decir, una vez conectado al irc, debe aparecer en la pantalla el
texto que van escribiendo los demas jugadores, precedido por su nick.
Muy al estilo del IRC.

Para ello es necesario un TextBox o Memo en el cual se puedan poner
letras de colores, y que tenga un scroll, ahora bien, podemos hacer
nuestro propio control ó usar alguna libreria, hace algunas semanas se
proponia que usaramos PLIB y mas espesificamente PUI. Sin embargo creo
que el proyecto fue abandonado. :S

http://plib.sourceforge.net/

El desarrollo de la libreria parece abandonado :(.

Asi que o hacemos nuestros propios controles o buscamos una libreria
para hacer el GUI del War.

¿Alguna propuesta?

Saludos,


ZeruGiran

E-Mail: zerugiran@...
MSN: eric@...
Tel: 04455-18243353 (Telcel)
Web: Perfil



[Este mensaje contenía archivos adjuntos]



________________________________________________________________________
________________________________________________________________________


_____________________________________
WAR3D -> http://war3d.sourceforge.net/

Si quieres cancelar tu suscripcion, envia un mensaje a war_3d-unsubscribe@yahoogroups.com
_____________________________________
------------------------------------------------------------------------
Enlaces a Yahoo! Grupos

<*> Para visitar tu grupo en la web, ve a:
http://es.groups.yahoo.com/group/war_3d/

<*> Para cancelar tu suscripción en este grupo, envía
un mensaje en blanco a:
war_3d-unsubscribe@yahoogroups.com

<*> El uso que hagas de Yahoo! Grupos está sujeto a
las Condiciones del servicio de Yahoo!:
http://es.docs.yahoo.com/info/utos.html

------------------------------------------------------------------------

nota:

MinGW, Cygwin, Dev-C++,etc son GCC instalados de formas algo distintas,
pero todas son GCC. Y GCC es el compilador que se usa en linux. Asi que
un makefile de linux, con algunas adaptaciones ( /d"_WIN32_" o cosas asi)
valdria y correria en "msys", la linea de comandos en mingw.

----- Original Message -----

From: ZeruGiran

To: HyBriDuM ; War3D

Sent: Sunday, August 15, 2004 9:13 AM

Subject: [war_3d] HyBriDuM y MinGW

Hi ya:

Hola HyBridum (Rodolfo)

¿Podrias enviarme todo lo que tengas con respescto a la compilacion del War3D en Mingw? Lo voy a colocar en nuestra Web.

Saludos

P.D. Besitos a Caty mugris.


El jue, 25-03-2004 a las 12:24, HyBriDuM escribió:

Pues naaa'...
Con la noveda' de que ya compila y charcha al 100%...
El problema de lentitud era por los drivers, los de MS no funcionan y
los de nVidia si... que raro verdad?
So, se podría decir que ya casi está listo el SDK para compilar con
MinGW (DevC) bajo windows, la cosa es...
si sirve?
A mi me sirve...
Con gusto lo comparto con todos..
Perooo....
Alguien está interesado???
Lo echamos a la comunida' ????
Lo que pasa es que también como que no he visto que la raza esté muy
interesada...
Tu como vez???

ZeruGiran

E-Mail: zerugiran@...
MSN: eric@...
Tel: 04455-18243353 (Telcel)
Web: Perfil 

_____________________________________
WAR3D -> http://war3d.sourceforge.net/

Si quieres cancelar tu suscripcion, envia un mensaje a war_3d-unsubscribe@yahoogroups.com
_____________________________________

Pues naaa'...
Con la noveda' de que ya compila y charcha al 100%...
El problema de lentitud era por los drivers, los de MS no funcionan y
los de nVidia si... que raro verdad?
So, se podría decir que ya casi está listo el SDK para compilar con
MinGW (DevC) bajo windows, la cosa es...
si sirve?
A mi me sirve...
Con gusto lo comparto con todos..
Perooo....
Alguien está interesado???
Lo echamos a la comunida' ????
Lo que pasa es que también como que no he visto que la raza esté muy
interesada...
Tu como vez???

ZeruGiran



E-Mail: zerugiran@...

MSN: eric@...

Tel: 04455-18243353 (Telcel)

Web: Perfil

El jue, 05-08-2004 a las 13:04, tei escribió:
He estado aprendiendo un poco sobre netcode en juegos

, y he llegado a un par de conclusiones que voy a compartir con vosotros:
- p2p es el mejor diseño de red, pero no me gusta :D

- las cadenas son el enemigo, pero menos,.. lo malo realmente es la redundancia, y siempre se pueden comprimir los datos antes de enviarlos, usar baselines, cachear mensajes, etc..
- si envias binarios, tienes que tener en cuenta distintas arquitecturas (littelendian , bigendian)

- poder salvar a un fichero demo es toda una feature

- un modelo cliente servidor ligeramente desplazado al lado cliente es lo optimo para juegos de red (no tan lado cliente como para que se puedan hacer trampas, y no tan lado servidor y nada cliente como para que haya que esperar siempre al servidor sufriendo todo el impacto del lag, que puede ser del copon de grande y muy irregular)

Añadese a todo lo que se ha comentado en mensajes pasados.
La ultima vez que mire el codigo, creo que war_3d usaba cadenas (o eso me parecio) 

...tras todo lo ultimo que he aprendido (optimizando el netcode de quake1 ) he llegado a la conclusion de que sin ser bueno, no es tan malo, de echo.. puede tener ventajas bastante interesantes.. temporalmente.

_____________________________________
WAR3D -> http://war3d.sourceforge.net/

Si quieres cancelar tu suscripcion, envia un mensaje a war_3d-unsubscribe@yahoogroups.com
_____________________________________ Enlaces a Yahoo! Grupos
<*> Para visitar tu grupo en la web, ve a:
http://es.groups.yahoo.com/group/war_3d/

<*> Para cancelar tu suscripción en este grupo, envía un mensaje en blanco a:
war_3d-unsubscribe@yahoogroups.com
<*> El uso que hagas de Yahoo! Grupos está sujeto a
las Condiciones del servicio de Yahoo!:
http://es.docs.yahoo.com/info/utos.html
 

ZeruGiran



E-Mail: zerugiran@...

MSN: eric@...

Tel: 04455-18243353 (Telcel)

Web: Perfil

He estado aprendiendo un poco sobre netcode en juegos, y he llegado a un
par de conclusiones que voy a compartir con vosotros:

- p2p es el mejor diseño de red, pero no me gusta :D

- las cadenas son el enemigo, pero menos,.. lo malo realmente es la
redundancia, y siempre se pueden comprimir los datos antes de enviarlos,
usar baselines, cachear mensajes, etc..

- si envias binarios, tienes que tener en cuenta distintas arquitecturas
(littelendian , bigendian)

- poder salvar a un fichero demo es toda una feature

- un modelo cliente servidor ligeramente desplazado al lado cliente es lo
optimo para juegos de red (no tan lado cliente como para que se puedan
hacer trampas, y no tan lado servidor y nada cliente como para que haya
que esperar siempre al servidor sufriendo todo el impacto del lag, que
puede ser del copon de grande y muy irregular)

Añadese a todo lo que se ha comentado en mensajes pasados.

La ultima vez que mire el codigo, creo que war_3d usaba cadenas (o eso me
parecio) ...tras todo lo ultimo que he aprendido (optimizando el netcode
de quake1 ) he llegado a la conclusion de que sin ser bueno, no es tan
malo, de echo.. puede tener ventajas bastante interesantes.. temporalmente.