He descubierto porque tardaba tanto  :D  :D

Estaba haciendo el blitsurface de una superficie a la que aun no habia aplicado SDL_DisplayFormat, esta funcion convierte una surface al "formato" de la pantalla, es decir cada vez que dibujaba un sprite el ordenador tenia que "convertir" la surface a otra surface con la profundidad de color y todas esas caracteristicas raras de las pantallas.
Ahora dibujando el fondo (sin dirtyrect) y los sprites animados  58 fps... XDDD YES!!

Por cierto loover, despues de haberme convencido a utilizar tu libreria, me doy cuenta que visual c++ 2008 necesita un procesador con 1.6 Ghz para corre,  todo son pegas, de todas maneras antes de Julio pienso gastarme pasta y pillar un QuadDumped con su Nvidia 8000series GT. La utilizare porque sino nadie podra ver mi juegillo , todo el mundo usa güindous.!!! :cry:

Al final loover me vas a convencer.

Dado que opengl y direct3d ataca directamente a la tarjeta grafica y a su memoria, digamos que usar tu librería seria lo mismo que lo que estoy haciendo ahora con SDL.
La unica pega es que yo suelo programar en linux (ubuntu) creo que tu libreria no esta disponible para linux o si?

Pues si asi lo voy a hacer.

He medido el tiempo individual de cada funcion.
El dibujar los dos sprite me da 0 ó 1 milisegundos, mientras que dibujar el fondo de pantalla consume 40 milisegundos, si cogemos que doy 17 vueltas, 17*40 = 680, es decir el 68% del tiempo lo gasto en pintar el fondo, esto me lleva a una conclusion obvia -> DirtyRectangles.
Estoy pensando como hacerlo y el problema primero que me ha llamado la atencion es que antes de dibujar cualquier cosa tengo que conocer las coordenadas de todo lo que he dibujado en la iteraccion anterior...OMG creo que abrire otro post para esto XDD. Perdón, antes me documentare y si no me sale bien a la primera entonces abrire post.

Probando el programa de prueba sin pintar el fondo me daba 58 fps. Thats GOOD

Bueno ya he conseguido medir las fps, y no paso el corte, lo he hecho mil y una veces y no paso de -17- siempre 17 vueltas da en un segundo.

En cuanto a las preguntas de loover si, tienes razon, cargo la imagen en memoria, y luego interiormente la clase CSprite copia su parte de la imagen a una surface suya que hace de buffer, y de ahi cuando sea requerido lo copia a memoria., es decir hago una copia intermedia que me puedo quitar.

Si no he entendido mal te refieres a pasar del fichero cargado en memoria directamente a pantalla el sprite adecuado verdad.

Ahora hare ese cambio a ver si me llega a 30 fps.

Tienes razon, pero la verdad es que me he explicado mal.

Yo cargo el fichero de imagen  entero y creo unos vectores con las coordenadas para hacer  los recortes de todos los sprites.
Esto antes de empezar el bucle de juego.
Luego la funcion dibujarsprite simplemente coge del vector de coordenadas las que le toquen y corta del fichero la imagen adecuada.
Ambos vector de coordenadas y fichero de imagen estan en memoria.
Se que un acceso a disco es del orden de 100000 mas lento que un acceso a memoria;
se puede hacer mas rapido?

No puede ser!!

Hago lo siguiente:

Inicializo todo, sprites, pantalla, animaciones.

while (!fin)
    uint32 start = 0
    Dibujarsprite(1)
    Dibujarsprite(2)
    Animar(1)
    Animar(2)
    start = sdl_getticks
    if (start>1000)
        fin = true
   
Pues bien, da una vuelta y tarda 3700 milisegundos????
Si pongo el limite a 10000, por si me equivoco con las unidades de medida, aunque pensaba que daba milisegundos da 111 vueltas

Vaya esto se complica, no tenia ni idea que opengl iba directo al hardware, para q veais la idea que tengo XD...
Ahora mismo mido los fps.
Buena idea esa de medir cada funcion por separado para ir optimizando las mas lentas, me pongo a ello.
He depurado un poco y no hago nada raro;
*Cargo sprite
*Lo bliteo en la surface temporal
*Lo elimino
*Y cuando todos los sprites estan dibujados, flasheo a la pantalla fisica.
Lo habitual imagino...

JAjaj , te has dado cuenta.

Este foro es mortal o te publica por duplicado o no te publica.

Agradezco tu respuesta fuenlabreño.

A que te refieres exactamente con frames?, se que es una pregunta tonta pero esque tiene tantas acepciones.
A las veces que llamo a mi funcion Pantalla.Actualizar? esta funcion blitea a la pantalla lo que hay en memoria de video, digamos, se que sabes lo q quiero decir, primero hago todas las animaciones los cambios de posicion y luego llamo a Pantalla.Actualizar que lo blitea todo a pantalla. Cuando hablas de frame te refieres a las veces que flasheo la pantalla?

Si es asi, no llego a 30 por segundo ni de coña. Cuando este en casa lo mido y t lo digo.

Antes se me olvidó dar un dato muy importante que me has recordado al hablar de la tostadora de tu oficina, mi programa de momento esta corriendo en mi ordenador personal, y le llamo personal porque hace tanto tiempo que lo tengo que ya le he cogido cariño....

PIII 800, XDDD en su defensa he de decir que la grafica es una Geforce4MX4000, tiene 1 Gb de memoria y El gestor de escritorio de Ubuntu, BERYL realiza todos los efectos a la perfeccion, por no hablar del Warcraft III que puede correr con todas las opciones graficas al maximo con una suavidad q ya la querrian muchos PIV XDD.

En las pruebas que estoy haciendo todo es optimo, dibujo los sprites justos y lo unico que podria mejorar  es dibujar solo la parte del fondo que cambia y no todo como hago ahora.

Hola a todos,

Mi problema es el siguiente, he creado unas clases para manejar sprites y otras para manejar eventos del teclado, hasta aqui todo bien, dado que considero terminada la primera parte de mi mini proyecto. Asi que me he puesto a cronometrar tiempos para ver como va el tema y...

Mi bucle principal de momento solo dibuja y maneja dos sprites con sus animaciones , los eventos de teclado para manejarlos y un fondo de pantalla, q de momento se dibuja entero a cada iteraccion. Pues de media tarda 60 milisegundos en completar una vuelta !!!

Desearia que me dijerais que en el fondo las operaciones graficas son las que mas tiempo consumen, porque ahora deberia implementar:

-El detector de colisiones, con multirectangulos.
-La IA, que tengo pensada con maquinas de estados y unos pocos arbolillos.
-El subsitema de sonido....

Tras implementar esto imagino que mi bucle se ira facilmente a los 100-150 milisegundos no??

Mi pregunta es cual debe ser el tiempo medio por cada iteraccion de un bucle principal en un juego normalillo ?

Porque, si tenemos en cuenta esto de que el ojo humano ve 25 imagenes por segundo, el tiempo optimo del bucle sería 40 ms. Esto seria pedir demasiado?

El hecho de dibujar todo el fondo en vez de solo la parte que cambia pesa mucho en tiempo??

BUeno, gracias anticipadas. TOY HUNDIO

Hola a todos,

Mi problema es el siguiente, he creado unas clases para manejar sprites y otras para manejar eventos del teclado, hasta aqui todo bien, dado que considero terminada la primera parte de mi mini proyecto. Asi que me he puesto a cronometrar tiempos para ver como va el tema y...

Mi bucle principal de momento solo dibuja y maneja dos sprites con sus animaciones , los eventos de teclado para manejarlos y un fondo de pantalla, q de momento se dibuja entero a cada iteraccion. Pues de media tarda 60 milisegundos en completar una vuelta !!!

Desearia que me dijerais que en el fondo las operaciones graficas son las que mas tiempo consumen, porque ahora deberia implementar:

-El detector de colisiones, con multirectangulos.
-La IA, que tengo pensada con maquinas de estados y unos pocos arbolillos.
-El subsitema de sonido....

Tras implementar esto imagino que mi bucle se ira facilmente a los 100-150 milisegundos no??

Mi pregunta es cual debe ser el tiempo medio por cada iteraccion de un bucle principal en un juego normalillo ?

Porque, si tenemos en cuenta esto de que el ojo humano ve 25 imagenes por segundo, el tiempo optimo del bucle sería 40 ms. Esto seria pedir demasiado?

El hecho de dibujar todo el fondo en vez de solo la parte que cambia pesa mucho en tiempo??

BUeno, gracias anticipadas. TOY HUNDIO :cry:

Uff que de cosas.

1- Me dice ex3 que si quiero hacer un juego o una libreria, pues... las dos cosas, en realidad lo que quiero es aprender a programar y que mejor manera que haciendo un juegillo, eso si en vez de hacerlo en un simple main como hay por ahi miles de ejemplos de tetris y demas, quiero hacerlo desarrollando librerias que me sirvan para mas adelante y bueno como decis, imagino que es un proceso que nunca acaba, simpre seguire retocando mi codigo, imagino, la perfeccion no existe.

2- En cuanto a loover, no se me habia ocurrido !!, que el delay forme parte de la clase animacion y no donde yo tenia pensado meterla, en una clase para manejar eventos de tiempo. Gracias ! lo hare asi.

3- Ya se que no es lo mismo que los editores de aventuras graficas, habia dicho "es casi como" y se que la looverlib no te lo da todo hecho pero usarla me quitaria lo mas divertido de el desarrollo de un juego.

4- Nunca habia pensado en desarrollar el sistema de camara, de momento en mis sprites no he implementado nada para proporciones o tamaños, y de momento no quiero ni pensarlo !! creo que eso podria ser un infierno.

5- En cuanto a lo de la carga entre fase y fase, si esa era mi intencion cargar antes de jugar, lo q dudaba era si por ejemplo en una parte del juego hay 10 personajes que han usado cada uno 10 animaciones distintas mantener todos los sprites cargados con todas las animaciones, es que no me he puesto a calcular cuanto ocuparia esto en memoria, no pesa demasiado no ???, creo que cargare todas las animaciones posibles a utilizar antes de empezar.

Como habia imaginado, mas me meto mas se complica esto, lo dificil que es hacer que un "queco" se mueva por la pantalla!! Si seguro que despues de todo mi trabajo acabo utilizando la looverlib!!

Thx por vuestros post !!  :lol: da gusto encontrar de vez en cuando un foro activo de verdad !  :D :?

Gracias Loover, he estado mirando tu libreria y bueno, hay cosas que no entiendo, esta muy por encima de mi nivel como programador, y si ya se lo de la rueda, pero te aseguro que disfruto mas programando una libreria, que haciendo un juego con una libreria existente, eso es casi como utilizar uno de esos editores de aventuras graficas, que te lo dan todo hecho
(un dia un colega albañil me dijo que sabia programar juegos, me sorprendio , le pregunte como lo hacia y descubri los editores estos de aventuras graficas donde lo mas complejo a usar es un "if then else")

Y bueno que quieres decir que a cada velocidad posible del sprite asocie una secuencia de cambios distinta entre frames?, eso seria poco escalable, tiene que existir alguna triquiñuela matematica para ajustarlo, quiero decir:

Si mi animacion tiene 5 frames y quiero que llegue al mismo sitio en menos tiempo seria tan simple como  ajustar el tiempo entre frames con el tipico "frecuencia = 1/Periodo" no?

Y bueno en cuanto a lo de agrupacion de rectangulos de colision, estoy implementandolo yo tambien, es una muy buena idea, lo malo es que me estoy liando un poquillo con el uso de memoria de estos elementos, al haber 20 sprites cargados hay unos 100 rectangulos y estoy intentando que el uso de memoria sea optimo, ya sabeis "cuando no y cuando si hacer destroy" tengo problemas serios, pero saldre adelante  :lol:

Vaya has editado justo cuando yo publique ahora lo leo.......
Editado respondiendo a la edicion de loover:

Gracias por los links, ahora salgo de currar luego me los miro.
Si es verdad que nunca esas estructuras pesarian en memoria que tonteria, lo que pasa es que mi profesor de prog I y II insistio mucho con nosotros en la gestion limpia de memoria y siempre me ha obsesionado esto.

Hola a todos, soy un programador de C++ que lleva toda la vida,trabajando bajo Linux, he tenido alguna aventurilla con VisualC pero apenas nada.

Me gustaria trbajar en paralelo mis programas en linux y Win, pero no tengo ni idea de que IDE elegir, que me recomendais??

Visual Studio 2003, Visual c++ 6, visual studio 2008? mi mayor miedo es, supongo como en la mayoria de los casos , el tema de librerias, cuando he intentado incluir alguna que otra cosa rara en Windows siempre he tenido problemas, mientras que en Linux soluciono esto con los Makefiles sin ningun esfuerzo, que me recomendais y sobre que IDE hay mas ejemplos/documentacion/pruebas???

No entiendo muy bien lo que dice prompt en su ultimo post, yo no utilizo los colorkey de los sprites, lo que he pensado, es una clase para manejar sprites, y luego, aparte, otra clase para manejar una matriz imaginaria donde "pinto" los rectangulos de cada sprite, y es sobre esta matriz imaginaria donde detecto las colisiones, que luego aplico a los graficos. Se entiende?  Sin duda una clase y otra estan relacionadas, dado que los rectangulos de la clase matriz (que representa todo el tablero de juego) dependen de la geometria del sprite en cuestion.
Ya casi lo tengo acabado, el tema del dibujo y animacion de sprites, y me he encontrado con un problemon y no se por donde tirar.
Mi intencion primera es hacer un juegecillo tipo Street fighter II pero con mis sprites de goku and company.
Algunas de mis animaciones, constan de hasta 16 frames distintos, y tengo dudas de si merece la pena introducir una variable para almacenar la velocidad de cambio entre frames, no la velocidad (x,y) del sprite sino del cambio entre cuadro y cuadro de la animacion, digo esto porke por ejemplo si mi sprite goku se convierte en super saiyan, seria bonito que ademas de desplazarse mas rapido, su animacion fuera mas rapida tambien (velocidad entre frame y frame).
Lo malo de introducir esta propiedad seria por ejemplo en los saltos, (en los que mis sprites dan una vuelta sobre si mismos), cambio de frame segun cambio de posicion (x,y) del sprite, si cambio la velocidad de cambio de frame......la velocidad del sprite deberia ir en relacion proporcional con la velocidad de cambio de frames???
Se que es un tema un poco general, pero si teneis alguna idea ....os lo agradeceria.  :lol:

Yo tambien soy de Fuenla !! Ex3

La indielib es tuya Loover??   un trabajo impresionante.

Le echare un vistazo, pero es que no quiero perder mucho tiempo probando otras librerias, QUIERO HACER LA MIA !! , uno de los principios de la informatica es no reinventes la rueda, lo se, pero todos sabemos que empezando desde abajo es como se adquiere el conocimiento de verdad, y si ese es un principio de la informatica porque el primer año de carrera nos meten tanto calculo y logica formal !?!?!? que nos enseñen lisp y c++ que al final es lo unico q vale, bueno este tema podia formar otro post aparte, asi que paso de seguir en ello. Habra quien no reinvente la rueda y haga un juego en 2 meses, habra quien la reinvente y este dos años para hacer un juego seguramente menos robusto que el anterior pero bueno yo soy de los segundos.

En cuanto a la tecnica, he estado pensando y efectivamente, con varios rectangulos por frame creo que bastará, parece el mejor desarrollo en relacion calidad/precio, que alguna colision quede un poco falsa, pues nada.
En cuanto a la manera de almacenar los datos (coordenadas de los distinto rectangulos) no entiendo loover porque lo haces con xml y mas en un fichero?? no conlleva este mucha sobrecarga?? yo habia pensado en una public class con una matriz de esas estilo [][]  superligera, para cargar los rectangulos en tiempo de ejecucion.
Imagino que si los almacenas en un fichero y con xml cargaras todos los sprites y rectangulos antes de empezar el juego en si, y esto me lleva a otra pregunta, esto no hace el juego muy pesado en memoria??

Yo de momento he optado por una solucion provisional (pseudocod):

Código [Seleccionar] Expand


struct cuadro= {int x, int y, int ancho, int alto, int identificador}
struct sprite
{
  vector<struct cuadro> imgs//aqui almacena los recortes del fichero de imagen
  vector<struct cuadro> forms//aqui los cuadros del modelo
}
//El identificador define los  cuadros de  formas que pertenecen a un determinado cuadro de imagenes(frame)


estoy ahora codificandolo, mas adelante si veo q funciona lo pasare a array [][]

Se que es una solucion simple, como la veis? Alguna aportacion, para este sistema multirectangulo??