HR-Timer
Keinier Caboverde R.
Quisiera preguntarles que librerias son utiles para pera crear una
clase timer de alta resolucion como para una simulacion, como algunos
sabran o supondran (aquellos que estan enterados) se dirije al
proyecto IllusionRender, he investigado y hay muchas funciones y
clases pero dependientes del sistema operativo o plataforma. Si me
aconsejan usar la libreria estandar TIME.H o CTIME estari mejor pero
no estoy seguro de si resolucion.
les agradeceria su ayuda porfavor :)
.
Jon Valdés
http://support.microsoft.com/kb/815668
En linux, clock_gettime() :
http://stackoverflow.com/questions/538609/high-resolution-timer-with-c-and-linux
2011/5/1 Keinier Caboverde R. <kei...@gmail.com>:
> --
> Has recibido este mensaje porque estás suscrito a code...@googlegroups.com
> Incluye tu información de perfil en https://sites.google.com/site/listadecodepixel/
> Para obtener más opciones, visita este grupo en http://groups.google.es/group/codepixel?hl=es.
>
> http://www.codepixel.com
>
Keinier Caboverde R.
On 1 mayo, 16:48, Jon Valdés <juan...@gmail.com> wrote:
> Si estás en windows, QueryPerformanceCounter :http://support.microsoft.com/kb/815668
>
> 2011/5/1 Keinier Caboverde R. <kein...@gmail.com>:
> > Hla a todos amigos,
>
> > Quisiera preguntarles que librerias son utiles para pera crear una
> > clase timer de alta resolucion como para una simulacion, como algunos
> > sabran o supondran (aquellos que estan enterados) se dirije al
> > proyecto IllusionRender, he investigado y hay muchas funciones y
> > clases pero dependientes del sistema operativo o plataforma. Si me
> > aconsejan usar la libreria estandar TIME.H o CTIME estari mejor pero
> > no estoy seguro de si resolucion.
>
> > les agradeceria su ayuda porfavor :)
> > .
>
> > --
> > Has recibido este mensaje porque estás suscrito a code...@googlegroups.com
Lobo Oscuro
de cambiarle la resolucion.
El 01/05/11, Keinier Caboverde R. <kei...@gmail.com> escribió:
> Para obtener más opciones, visita este grupo en
> http://groups.google.es/group/codepixel?hl=es.
>
> http://www.codepixel.com
>
--
La vida es tan miserable y decadente, este mundo podrido que se cae a
pedazos, no tiene recuperacion....
No soy emo, tengo cuchillo pero corto en pedazos a los demas, jojojo OwO
Humanos masoquistas, de que se quejan?
Keinier Caboverde R.
como las de la TV?, y en caso de implemetarla en la pc como llevo los
ticks del game loop?
On 1 mayo, 17:25, Lobo Oscuro <lobooscu...@gmail.com> wrote:
> Mas facil podes elegir sincronizar con el refresco del monitor despues
> de cambiarle la resolucion.
>
Jon Valdés
simplemente activándolo. Aún así, necesitarás timings precisos para
todo lo que dependa del tiempo en el motor, porque no puedes depender
de que todos los frames tarden exactamente lo mismo en procesarse (el
OS puede pararse medio segundo, y te destroza la animación,
movimiento, etc).
2011/5/1 Keinier Caboverde R. <kei...@gmail.com>:
Pablo Quesada Barriuso
simulacion. Puedes configurarte un incremento de tiempo dt para el
cual tu simulacion sea estable y luego en cada llamada haces un bucle
con la diferencia de tiempos desde la ultima llamada con un incremento
dt.
Sería más estable a costa de algo más de computación.
Saludos!
2011/5/2 Jon Valdés <jua...@gmail.com>:
--
Pablo Quesada Barriuso.
email: pab...@gmail.com
blog: http://pabloqb.evolution42.com
Keinier Caboverde Ramirez
Veran lo que yo tengo planeado hasta ahora es, implementar DirectX(D3D,DINPUT,DSOUND,DPLAYER) bajo windows y (OGL,OAL,GLUT) en linux y Mac OS.
Ademas de otras librerias como zlib y STL que no dependen de la plataforma. No se que piensen Ustds que tiene mas experiencias que yo, ademas investigando por internet me topecon algunos articulos (no recuerdo en donde en estos momentos) que contradice lo que comenta Jason Gregory en su libre "The Game Engine Architecture" acerca de la reserva de memoria, el comenta que es mas optimo customizarlas por medio de funciones estandares alloc en lugar de emplear los operadores new/delete de C++. Con eso encontre que la serie alloc es mas rapida que el operador new pero no inicializa el objeto, sin embargo New si lo inicializa (por eso la perdida de algunos ciclos del cpu), realmente no se que implementar en este caso porque estoy como cuando se presenta a elegir OPENGL O DIRECTX algo similar.
Lobo Oscuro
todas las aplicaciones o procesos que te joden y rogar que no tenga
ninguna basura mas en memoria (Al menos en windows). Es muy raro que
el proceso supere un frame de mas, esos errores se notan mucho y si lo
notas seguido algo falla.
Keinier: Me refiero a los puertos E/S que se puede usar desde
programacion. No me acuerdo cuales son ahora, podes averiguarlo viendo
la funcion vsync() o algo parecido, que no lleva mas que un par de
lineas.
Usando el refresco del monitor trae la ventaja de que podes
actualizar el monitor justo cuando la pantalla no se esta refrescando.
En vez si usas el reloj interno de la CPU sincronizas solo la
velocidad, pero podes ver parpadeos igual.
Lo del alloc y new tambien lo vi, todavia no se si realmente es
cierto, (ni siquiera las diferencias entre alloc y malloc), pero
cuanto tenga tiempo algun dia lo averiguare.
El 02/05/11, Keinier Caboverde Ramirez <kei...@gmail.com> escribió:
shash
Lobo Oscuro: Deja de decir cosas que no aplican en PC, sin linkar referencias. Primero, usar como sistema de timing de alta frecuencia el VSync es completamente estúpido. Si eres afortunado, tendrás vsync a 120Hz, lo cual significa una granularidad de 1000 ms / 120 ciclos = 8.33 ms. Una mierda, vaya. Segundo, y quizás más importante, en PC no hay soporte para sincronía explicita en VSync, a diferencia de las consolas (hace años que se pide, pero aún no hay soporte general). No puedes linkar una interrupción al VBlank para poder operar en ese momento. Lo más importante: no es necesario! En PC no tienes los problemas que hay en consolas de areas de memoria en las que no puedes escribir durante el frame, así que puedes mandar al driver las operaciones durante el frame, y él ya se ocupa de enviarlo a la tarjeta cuando lo cree adecuado: Puedo explicarlo en algo más de detalle, pero creo que ya es bastante offtopic para el thread actual. En resumen, documentate un poco antes de decir cosas al "tun-tun", o al menos provee links que prueben lo que dices, por favor. Decir cosas por decir es peor que estar callado, gracias.
General: Usad los sistemas de timing que comenta Jon Valdés en su primer post. A veces se debe ser prudente en casos de parones largos debido al OS / carga de datos / lo-que-sea, pero a nivel particular y profesional no lo he necesitado nunca.
Sobre los allocators, depende de la plataforma, pero en consolas (y en PC, por localidad), querrás tener custom allocators, para evitar fragmentación y tener todos tus datos juntos. Es un tema bastante complejo para resumirlo, pero te recomiendo que leas el Effective C++/Effective STL para aprender los patrones de alloc de STL, y busques memory fragmentation en Google. Opcionalmente, lee también esto (blog donde también escribo, pero ese post no es mío :P)
Y con esto hago el cupo anual, de escribir en la lista,
shash
Lobo Oscuro
1) lo que te parece estupido el vsync todavia se sigue usando.
2) Los juegos como maximo se usa 60Hz, pedir 120Hz aunque se pudiera
es demasiado alto y innecesario. Al menos decime vos para que se
utiliza. (Supongo yo que para simuladores o realidad virtual, cosa que
sige sin necesitarse tampoco)
3) En ningun momento hable de sistema de timing de alta frecuencia.
4) Quien dijo de linkar? Estoy hablando de usar el puerto E/S para
sincronizar con la velocidad del monitor. Si queres un link entonces
googlealo. No creo que sea tan dificil consultar los puertos.
5) No es necesario tocar ninguna interrupcion.
6) Ya que estamos, porque no informas un poco a todo el grupo ya que
lo sabes todo? Cuales son las funciones/programacion/loquesea que
decis vos el que se encarga de sincronizar y enviar la informacion a
pantalla en el momento correcto? Y con que hardware si tiene algo que
ver?
7) Cualquier reserva de memoria que hagas con alloc o new ocurre
fragmentacion de memoria. La buena administracion de memoria depende
de vos.
---------
Si escribis por cupo anual, entonces mejor que la proxima escribas en
el año que viene despues de estudiarte todo lo que corresponde, claro.
El que no tiene fundamento y escribe al tuntun sos vos.
El 02/05/11, shash <shas...@gmail.com> escribió:
> A ver...
>
> *Lobo Oscuro*: Deja de decir cosas que no aplican en PC, sin linkar
> referencias. Primero, usar como sistema de timing de alta frecuencia el
> VSync es completamente estúpido. Si eres afortunado, tendrás vsync a 120Hz,
> lo cual significa una granularidad de 1000 ms / 120 ciclos = 8.33 ms. *Una
> mierda, vaya*. Segundo, y quizás más importante, en PC no hay soporte para
> sincronía explicita en VSync, a diferencia de las consolas (hace años que se
> pide, pero aún no hay soporte general). No puedes linkar una interrupción al
> VBlank para poder operar en ese momento. Lo más importante: *no es necesario
> *! En PC no tienes los problemas que hay en consolas de areas de memoria en
> las que no puedes escribir durante el frame, así que puedes mandar al driver
> las operaciones durante el frame, y él ya se ocupa de enviarlo a la tarjeta
> cuando lo cree adecuado: Puedo explicarlo en algo más de detalle, pero creo
> que ya es bastante offtopic para el thread actual. En resumen, documentate
> un poco antes de decir cosas al "tun-tun", o al menos provee links que
> prueben lo que dices, por favor. Decir cosas por decir es peor que estar
> callado, gracias.
>
> *General*: Usad los sistemas de timing que comenta Jon Valdés en su primer
> post. A veces se debe ser prudente en casos de parones largos debido al OS /
> carga de datos / lo-que-sea, pero a nivel particular y profesional no lo he
> necesitado nunca.
>
> Sobre los allocators, depende de la plataforma, pero en consolas (y en PC,
> por localidad), querrás tener custom allocators, para evitar fragmentación y
> tener todos tus datos juntos. Es un tema bastante complejo para resumirlo,
> pero te recomiendo que leas el Effective C++/Effective STL para aprender los
> patrones de alloc de STL, y busques *memory fragmentation* en Google.
> Opcionalmente, lee también
> esto<http://altdevblogaday.org/2011/02/12/alternatives-to-malloc-and-new/>(blog
Jon Valdés
> A ver... De que carajo estas hablando? Para comenzar:
>
> 1) lo que te parece estupido el vsync todavia se sigue usando.
Por supuesto. Es la única manera de sincronizar la aplicación con el monitor.
> 3) En ningun momento hable de sistema de timing de alta frecuencia.
Sin embargo, esa era la pregunta de Keinier
> 4) Quien dijo de linkar? Estoy hablando de usar el puerto E/S para
> sincronizar con la velocidad del monitor. Si queres un link entonces
> googlealo. No creo que sea tan dificil consultar los puertos.
Sinceramente, en mi vida he oído algo así. Yo también agradecería un link.
> 6) Ya que estamos, porque no informas un poco a todo el grupo ya que
> lo sabes todo? Cuales son las funciones/programacion/loquesea que
> decis vos el que se encarga de sincronizar y enviar la informacion a
> pantalla en el momento correcto? Y con que hardware si tiene algo que
> ver?
Precisamente para sincronizar y enviar a pantalla en el momento
correcto está el vsync. Lo que dice sash es que el vsync de las
consolas permite un acceso más específico, porque las consolas están
más limitadas técnicamente que un PC. En un PC, no puedes más que
activar el vsync y dejar que el driver de la GPU se encargue de todo.
> 7) Cualquier reserva de memoria que hagas con alloc o new ocurre
> fragmentacion de memoria. La buena administracion de memoria depende
> de vos.
Precisamente por eso, prácticamente todo motor 3D utiliza un sistema
propio de allocs, que reserva un gran bloque de memoria (o unos pocos
bloques) con malloc y luego lo gestiona internamente, utilizando
pequeñas secciones de ese bloque.
Eso mejora la coherencia de cache y disminuye el overhead que supone
llamar a malloc/new por cada nuevo uso de memoria que haga falta. A
eso es a lo que se refiere sash.
Un par de links sobre memory fragmentation y cómo tratar on ella:
http://stackoverflow.com/questions/3770457/what-is-memory-fragmentation
http://stackoverflow.com/questions/60871/how-to-solve-memory-fragmentation
shash
3) Es de lo que habla el thread, reservate los offtopics para tus propios threads.
4) No se puede consultar esos puertos de forma estandard, es lo que te estaba intentando de explicar. Somos ingenieros/programadores. Pon referencias, o lo aceptamos como falso.
5) Entonces como sincronizas con el vsync para hacer calculos mientras estas en un VBlank? Somos ingenieros/programadores. Pon referencias, o lo aceptamos como falso.
6) De eso se ocupa el driver. Si está configurado para esperar al Vsync (por ejemplo, desde el panel de control del driver o de forma explicita desde la aplicación), él se ocupa de cambiar el buffer que se muestra en el VBlank. Esto normalmente se hace con N-Buffering, y el control por parte del usuario / programador es muy limitado en PC.
7) Mentira. La fragmentación ocurre respecto a la evolución de los allocs durante el transcurso de la ejecución. No ocurre con cada alloc, como dices. Lee el artículo que linkee en mi mail previo.
En serio, la mayoría de lo que comentas son cosas que se usaban en 1995 en MS-Dos, pero hace mucho que nada de eso se usa. Si dices cosas que no son ciertas, le haces un flaco favor a quien no sepa del tema, así que mejor no comentes sin citar referencias.
Lobo Oscuro
Es lo que ganas criticando a los demas y actuando como sobrador...
shash
A parte, Keinier, si quieres más detalles de lo que comento, pregunta: puedo detallarlo más, o citarte sitios donde leer artículos más extensos.
shash
"Somos ingenieros/programadores. Pon referencias, o lo aceptamos como falso."
--
Lobo Oscuro
Vaya sobrados que estan echo los usuarios de aqui, necesitan unas
lecciones con palo. ^^ Shash, es cosa mia y tuya el que te lo merezcas
la informacion o no.
Veamos, cuantos usuarios son como shash en este grupo? Depende de la
respuesta el valor del grupo. Porque no quiero descartar el grupo por
un tonto que se cree sabelotodo.
El 03/05/11, shash <shas...@gmail.com> escribió:
> Tu mismo, la información que se pedía en el thread ya está (y la errónea
> corregida), y solo TU te pones tu en evidencia, sin probar tus afirmaciones.
>
> A parte, Keinier, si quieres más detalles de lo que comento, pregunta: puedo
> detallarlo más, o citarte sitios donde leer artículos más extensos.
>
> shash
>
> 2011/5/3 Lobo Oscuro <loboo...@gmail.com>
>
>> "*Somos ingenieros**/programadores**. Pon referencias, o lo aceptamos como
>> falso.*"
>> Pues aceptenlo como falso entonces, seran los ingenieros/programadores
>> carente de conocimientos.
>> [image:
>> http://i658.photobucket.com/albums/uu308/NiggiesExist/cool%20shit/TrollFace.png]
>>
>> Es lo que ganas criticando a los demas y actuando como sobrador...
>>
>> --
>> Has recibido este mensaje porque estás suscrito a
>> code...@googlegroups.com
>> Incluye tu información de perfil en
>> https://sites.google.com/site/listadecodepixel/
>> Para obtener más opciones, visita este grupo en
>> http://groups.google.es/group/codepixel?hl=es.
>>
>> http://www.codepixel.com
>>
>
> --
> Has recibido este mensaje porque estás suscrito a code...@googlegroups.com
> Incluye tu información de perfil en
> https://sites.google.com/site/listadecodepixel/
> Para obtener más opciones, visita este grupo en
> http://groups.google.es/group/codepixel?hl=es.
>
> http://www.codepixel.com
>
Review
Desde hace bastante tiempo soy lector de Codepixel, y desde hace bien
poco estoy en estas listas de correo , las cuales son bastante
interesantes para ver un poco la opinión de la gente, los proyectos y
demás cosas que creo que nos interesan a todos los que estamos
apuntados.
Veo que este hilo se ha desvirtuado completamente para pasar de
discutir y debatir sobre temas que supongo que todos nos hemos
encontrado o nos encontraremos al hacer aplicaciones gráficas a un
ataque entre usuarios para ver quién gana verbalmente.
Después de la charla, quiero poner mis cinco céntimos en el debate del
VSync :
Hace unos años hice un programa como trabajo de clase utilizando SDL +
OpenGL, y utilizando como timing el Vsync. Fué un error, ya que
basarse como timer del programa en el refresco de pantalla hace que en
cada Pc o máquina vaya a su ritmo (os imagináis un juego en red de esa
aplicación, uno con el monitor a 60 hz y otro con el monitor a 120? )
pues eso pasó
, que un tanque iba el doble de rápido que el otro :P
Desde mi opinión, creo que la solución correcta para una aplicación
que puede ser incluso multiplataforma (por lo poquito que he leido),
lo ideal sería un timing independiente de la pantalla. Hay que pensar
que la pantalla es un elemento más del videojuego, y que hay que
"cocinar" muchos datos antes de dibujar en pantalla. Lo mejor sería
cocinarlos independientemente de la velocidad de refresco del monitor,
y después ir "escupiendo" en pantalla los resultados según como se
quiera: Si con VSync o a pelo.
También cabe recordar que lo del Vsync no es un valor que siempre se
repita. En los drivers de NVidia, por ejemplo, puedes desactivar o
activarlo.
Bueno! No me enrollo mas! Sólo pido que los mensajes que nos llegue al
grupo sean cargados de respeto y constructivos, aportando datos de
calidad, y evitar el enfrentarnos, ya que seguramente nos podemos
enriquecer todos de lo que sabemos entre todos y hacer cosas
interesantes.
Un saludo a la comunidad
On 4 mayo, 00:39, Lobo Oscuro <lobooscu...@gmail.com> wrote:
> EL QUE ULTIMO HABLA RIE MEJOR JAJAJA!
>
> Vaya sobrados que estan echo los usuarios de aqui, necesitan unas
> lecciones con palo. ^^ Shash, es cosa mia y tuya el que te lo merezcas
> la informacion o no.
>
> Veamos, cuantos usuarios son como shash en este grupo? Depende de la
> respuesta el valor del grupo. Porque no quiero descartar el grupo por
> un tonto que se cree sabelotodo.
>
>
>
>
>
> > Tu mismo, la información que se pedía en el thread ya está (y la errónea
> > corregida), y solo TU te pones tu en evidencia, sin probar tus afirmaciones.
>
> > A parte, Keinier, si quieres más detalles de lo que comento, pregunta: puedo
> > detallarlo más, o citarte sitios donde leer artículos más extensos.
>
> > shash
>
> >> "*Somos ingenieros**/programadores**. Pon referencias, o lo aceptamos como
> >> falso.*"
> >> Pues aceptenlo como falso entonces, seran los ingenieros/programadores
> >> carente de conocimientos.
> >> [image:
shash
Que tu te pongas en evidencia sin demostrar nada de lo que dices (que como he dicho está mal), atacando a la primera, dice mucho de tu actitud :P
Si tus aportaciones son lo que has ofrecido hasta ahora, es decir, datos erroneos sin referencias e insultos, ante la corrección de estos por alguien que tiene más experiencia (tanto profesional como a nivel de hobby), respondes con insultos, mejor deja de postear, no ayudas a nadie.
Por favor, modera tu lenguaje y respeto,
shash
Keinier Caboverde Ramirez
me ha proporcionada Jhon Valdes en si primer post y respecto a los allocators efectivamente es mejor customizarlos ya que aumentan la rapidez en la localizacion de los datos, cabe destacar que en mis pruebas la optimizacion no fue muy notoria al igual que la carga de datos,lo cual gracias a la comunidad y a la curiosidad llegue a la conclucion de que la notoriedad de allocators customizados es directamentamente proporcional a la complegidad del escenario y/o Mesh implementadas.
Gracias a todos por plasmar sus conocimientos en este thread ya que es uno de los temas interesantes de este mundo, pero siempre con cortesia ;) ya que cuando se dibaga el tema los novatos se pueden confundir mas y no es la idea.
Suerte chic@s .
javier loureiro varela
> de todas formas desidi implementar ambas ideas para probar su
> rendimiento
Esta es la mejor (única) forma de mejorar el motor. Lo ideal sería
mantener una serie de pruebas, escenas, ejemplos, donde pudieses medir
el rendimiento , e ir mejorándolo con distintas ideas, consejos, etc.