Limitación de FPS

[Pato]

Hola.[EX3], por lo que pude apreciar(No lei mucho) ya no vas a programar más esta DLL, no sé si porque considerás que ya está concluida o porque la vas a abandonar definitivamente, lo cual sería una lástima. En fin, creo este thread para ver si habrá alguna posibilidad de hacer un sistema de limitación de FPS que además de limitar los FPS reduzca el consumo del CPU para tener una buena razón como para limitar los FPS, ya que cuando tengo corriendo el engine éste se pone en 100% de uso. Una buena forma es como está hecho en el Argentum Online(http://sourceforge.net/projects/morgoao/)(Sub ShowNextFrame del módulo TileEngine), fijate si hay alguna posibilidad de eso o si habrá que jorobarse, je. Por otro lado, no tenés pensando ni en chiste liberar los códigos de la dll, no? Saludos y gracias por tu tiempo.

[[EX3]]

Wenas.

Hola.[EX3], por lo que pude apreciar(No lei mucho) ya no vas a programar más esta DLL, no sé si porque considerás que ya está concluida o porque la vas a abandonar definitivamente, lo cual sería una lástima.

Esta todo comentado tanto en la web como en un post del foro. El proyecto ya esta terminado, de hecho actualmente esta cumpliendo su funcion inicial que era servir de base para el motor de mi juego en desarrollo. Ampliarla o modiicarla tampoco tiene sentido ya que con todo lo que tiene se puede trabajar perfectamente (la prueba es lo que decia, estoy pudiendo desarrollar mi juego sin problemas gracias a ella).

En fin, creo este thread para ver si habrá alguna posibilidad de hacer un sistema de limitación de FPS

Ya existe un sistema para limitacion de fps en dx_lib32. Mirate el parametro MaxFrames de la funcion Frame() de dx_GFX en la documentacion. Igualmente, el que consuma cierta cantidad de recursos es normal ya que no es que sea una libreria desarrollada ni lo mas optimamente ni que Visual Basic 6.0 se presete a ello. dx_lib32 tiene muchos mecanismos internos que funcionan paralelamente para facilitar diversas tereas, y eso se refleja en el consumo de recursos utilizado. La limitacion de FPS en verdad solo te servira principalmente para que el juego no vaya a tirones si no para que se mantenga a una velocidad constante.

Por otro lado, no tenés pensando ni en chiste liberar los códigos de la dll, no?

Pues por el momento no tengo intencion de ello aunque nunca he descartado la posibilidad.

Salu2...

[Pato]

Sí, vi que se limitan los FPS, pero limitarlos no te genera ningún beneficio en cuanto a consumo del CPU, de hecho, yo preferí limitarlos poniendo un sleep de 5 ms en el main loop, y de ese modo logré no saturar el micro, je. Y justamente eso es lo que te propongo que le implementes a la dll, un sistema de limitación de FPS que además de limitarlos no te sature el micro :), fijate si podés echarle un vistazo a lo que te dije, tal vez entiendas un poco mejor ;). Además, si limitar los FPS actualmente hacen que consuma de igual forma el micro, con que fin limitarlos :P? Es preferible dejarlos totalmente liberados xD. Saludos y gracias por contestar :).

[[EX3]]

Sí, vi que se limitan los FPS, pero limitarlos no te genera ningún beneficio en cuanto a consumo del CPU, de hecho, yo preferí limitarlos poniendo un sleep de 5 ms en el main loop, y de ese modo logré no saturar el micro, je.

Mi proyecto de juego plataformas desarrollado sobre un motor propio programado tambien en Visual Basic 6.0 sobre dx_lib32 del que actualmente se esta utilizando lo siguiente: sistema de tiles variantes (un tile puede tener tamaños distintos respecto al resto, asi como propiedades especificas que definan efectos a la hora de dibujarse y sin contar el sistema de iluminacion dinamica), scroll libre en ambos ejes (lo que comprende procesos en tiempo real para calcular, descartar y posicionar que se dibuja y que no segun posicion de la camara y resolucion de pantalla utilizada), sistemas de animaciones multicanal (un mismo sprite ejecuta varias animaciones independientemente calculando velocidad y posicionamiento de forma autonoma), sistema de fisicas por objeto (se calcula la fisica  de cada objeto junto con el trazado de rayos y trayectorias con el escenario y resto de objetos en tiempo real con pequeñas pausas de tiempo y realizando descartes similares al del sistema de scroll de tiles), motor de efectos en audio posicional (se calculan constantemente parametros por canal segun poscion de emision respecto al jugador), pequeño sistema de script casero para controlar y programar acciones en objetos y personajes para cinematicas (un sencillo interprete de comandos que tambien se ejecuta constantemente). Con lo desarrollado por el momento que no es poco en cuanto a codigo en ejecucion se refiere, funcionando a un maximo de 60 fps, solo estoy consumiendo un 17% del procesador y esto es poco teniendo en cuenta lo que llega a consumir por si solo la maquina virtual de Visual Basic 6.0 al ejecutar una aplicacion desarrollada en este lenguaje.

Un 17% no es saturar el procesador ni mucho menos a mi entender, asi que revisa que estas haciendo en tu codigo para saturar el procesador como me decias por que no es lo normal ni de lejos un 100% como comentas en el primer mensaje, y seguramente ni es problema de la libreria. Ya ves el resultado obtenido corriendo mi motor.

fijate si podés echarle un vistazo a lo que te dije, tal vez entiendas un poco mejor ;).

El Argetum Online no esta programado como un juego normal y corriente, solo han programado un motor grafico para el escenario y los personajes sobre DirectX7 (dx_lib32 utiliza DirectX8 y no es lo mismo) mientras que el resto lo han programado en formularios y controles de Windows. Asi no se desarrollan los juegos normalmente por lo que su sistema no me sirve ya que no es aplicable a dx_lib32 ni lo seria en otras librerias y herramientas como XNA.

Sobre lo de tu limitacion de 5 milisegundos. Sabes cuanto tiempo de espera se necesita para mantener una tasa de actualizacion de 60 fotogramas por segundo, que es la velocidad normal de ejecucion de un juego? Menos de un milisegundo de media (de hecho Sleep() no srive para esto ya que solo trabaja en milisegundos). El tiempo de espera que utiliza dx_lib32 para mantener una tasa constante de fps se calcula dependiendo lo que tarda en ejecutar un ciclo completo el render grafico y el numero de ciclos que se desean en un segundo, en base a eso se obtiene el tiempo aproximado de espera. Tu estas aplicando 5 milisegundos constantes de espera por lo que tu aplicacion no tiene una velocidad constante de ejecucion, y que dicha velocidad variara segun la maquina donde lo ejecutes. En mi juego, por ejemplo, con tu espera de 5 milisegundos me ha bajado la frecuencia de actualizacion a una media inestable entre 33 y 19 fps y un consumo de media entre 11% y 13% del procesador. El resultado es inestable y variable aparte de que no me ha dado un beneficio notable en cuanto a consumo por lo que no es valido.

Además, si limitar los FPS actualmente hacen que consuma de igual forma el micro, con que fin limitarlos :P? Es preferible dejarlos totalmente liberados xD

Veo que no tienes muy claro el por que se limitan los fotogramas por segundo en un juego :P Si tu dejas que el juego corra a la mayor velocidad posible, para empezar esta nunca sera constante, influira lo saturado que este el sistema ejecutando el resto de procesos y aplicaciones, esto hara que tu juego vaya a tirones ya que a ratos ira a una velocidad y a otros ira a otra, eso se traduce en variaciones de velocidad y en que los controles nunca iran sincronizados con lo que ves en pantalla. Otra razon, si no limitas el numero de fotogramas tu juego se vera a distintas velocidades segun la maquina donde corra. Limitando la velocidad te aseguras que se vea igual en cualquier maquina, detalle que no es trivial en absoluto.

En fin, antes de sugerir modificaciones de algo que no comprendes bien seria interesante que te informaras un poco, en este caso de la tasa de frecuencia de fotogramas por segundo en juegos, el por que se limitan, y el consumo de recursos de un juego o programa multimedia. La libreria lleva 8 años de desarrollo y estudio a sus espaldas y creeme que estas cosas estan miradas y estudiadas con calma desde un principio y en ocasiones con ayuda de gente de este foro que llevan años trabajando de esto amen a parte de que esta probada durante todo este tiempo por mi y por mas gente que la utiliza. Revisa tu codigo por que algo tendras mal implementado que te esta consumiendo excesivamente los recursos de tu maquina.

Salu2...

[Pato]

Hola, gracias por tu respuesta. Mirá, el código que utilizo es bastante básico y es obvio que no estoy haciendo nada mal, de hecho por el momento sólo le puse para que renderee el mapa, ni siquiera tiene chars ni objetos. De hecho, acá te dejo el código del RenderScreen y el sub Dibujar para que veas que no tiene nada malo :).

Sub RenderScreen()
Dim X As Integer
Dim Y As Integer
Dim MinX As Integer
Dim MinY As Integer
Dim MaxX As Integer
Dim MaxY As Integer

MinX = MaximoInt(LBound(Mapdata, 1), MiPos.X - 8)
MaxX = MinimoInt(UBound(Mapdata, 1), MiPos.X + 8)
MinY = MaximoInt(LBound(Mapdata, 2), MiPos.Y - 6)
MaxY = MinimoInt(UBound(Mapdata, 2), MiPos.Y + 6)

For X = MinX To MaxX
    For Y = MinY To MaxY
        With Mapdata(X, Y)
            Call Dibujar(.Graficos(1), _
                ((X - MiPos.X + 8) * 32) _
                , ((Y - MiPos.Y + 6) * 32), 32, 32)
               
            If .Graficos(2) <> 0 Then
                Call Dibujar(.Graficos(2), _
                    ((X - MiPos.X + 8) * 32) _
                    , ((Y - MiPos.Y + 6) * 32), 32, 32)
            End If
                   
            If .Graficos(3) <> 0 Then
                Call Dibujar(.Graficos(3), _
                    ((X - MiPos.X + 8) * 32) _
                    , ((Y - MiPos.Y + 6) * 32), 32, 32)
            End If
        End With
    Next Y
Next X
End Sub

Sub Dibujar(ByVal Texture As Long, ByVal X As Long, ByVal Y As Long, Optional ByVal W As Long = 0, Optional ByVal H As Long = 0, Optional ByVal Angle As Single, Optional ByVal Color As Long = -1)
    Call Engine.MAP_SetRegion(TexturesList(Texture).Grafico, TexturesList(Texture).Region)
   
    Call Engine.DRAW_MapEx(TexturesList(Texture).Grafico, X + 16, Y + 16, 0, W, H, Angle, Blendop_Color, Color, Mirror_None, Filter_None, True)
End Sub

Creo que no hay nada malo :P, jaja.

Y con respecto a tu comentario un poco subido de ego

antes de sugerir modificaciones de algo que no comprendes bien

Te recomiendo que analices mejor el código del argentum, por cómo está diseñado hace que en todas las computadoras se tarde el mismo tiempo en llegar de un tile al otro, aun que en uno tenga 100 FPS y en la otra 50 ;). En fin, no sé si tu computadora será muy buena, la mía muy mala o qué, pero como el uso que le iba a dar a la dll era muy básico me decidí a hacer mi propio módulo de DX 8, y ahora (con el mismo RenderScreen posteado aquí) con el juego limitado en 100FPS tengo un consumo mínimo del CPU :), de todos modos nunca había usado DX8 por lo que se me están complicando algunas cosas, pero bueno.. Saludos

[[EX3]]

Teniendo en cuenta lo que comentaba del consumo habitual de un juego frente a una aplicacion normal y la diferencia de importancia entre uno y otro (salvo que desarrolles para moviles), del codigo que me pones no veo nada raro. Pero te en cuenta que un codigo tan sencillo como:

Código [Seleccionar] Expand

Do
    DoEvents
Loop
Perfectamete puede poner el consumo de la CPU al 100% segun la maquina, todo por la llamada continua a DoEvents para ceder el control al sistema operativo. Quiero decirte con esto, si no fuera este codigo que me pones podria ser cualquier otro que tengas haciendo calculos o lo que sea. Fijate que no estes realizando llamadas recursivas o ejecutando llamadas innecesarias o bien recalculando algun valor que se mantenga fijo la mayor parte del tiempo (coordenadas de desplazamiento de un tile o un sprite por ejemplo) o pintando elementos que queden fuera de la vista de pantalla.

En fin, no sé si tu computadora será muy buena, la mía muy mala o qué

La maquina donde desarrollo es un trasto de 1.6ghz y una grafica integrada de 8Mb. El trasto en si es un ultraportatil de bajo coste, nada del otro mundo, justamente para tratar de optimizar lo que desarrollo :)

Y con respecto a tu comentario un poco subido de ego

antes de sugerir modificaciones de algo que no comprendes bien

Te recomiendo que analices mejor el código del argentum, por cómo está diseñado hace que en todas las computadoras se tarde el mismo tiempo en llegar de un tile al otro, aun que en uno tenga 100 FPS y en la otra 50 ;)

El Argentum Online, codigo que por temas aparte con un par de compañeros tuve que curiosear en su dia hace unos años, lo puede implementar como quiera, ya te dije para empezar que su arquitectura no es la comun. Yo trato de desarrollar sobre metodos mas o menos afines a desarrollos similares o como se realizan en otras plataformas y lenguajes (esto es, mis desarrollos podrian portarse sin mucho problema a C# y XNA por ejemplo, el Argentum Online no).

Ya te explique para que se limitan los fps en un juego, si bien no te sirvio mi explicacion la puedes buscar tu mismo en otros foros o webs. De hecho razona por un momento el tema en cuestion que estamos discutiendo, el consumo de recursos: mas fps significan mas pasadas del render grafico por segundo, lo que se traduce en mas carga de proceso, por ende mas consumo (de ahi por ejemplo que no interese que desboque la tasa de fps entre otras cosas, provocaria picos en el consumo). Pero lo importante no es tener cuantos mas fps o un valor minimo, el que se limite a tasas de 30 a 60 fps es tambien por la fluidez con la que se mostraran las animaciones y desplazamientos en pantalla. Si bajas la tasa por debajo de 30 por ejemplo, tus objetos se desplazaran la misma distancia, si, pero lo haran a saltos y no de seguido. En el caso de superar la tasa de 60 a 100 quizas notes movimientos demasiado fluidos, como acelerados aun desplazandose la misma distancia. Luego el limitarlo a una frecuencia fija es para evitar esto mismo.

Buenos ejemplos de todo esto serian muchos juegos antiquismos de MS-DOS que hoy dia no pueden ser jugados en las maquinas actuales por su excesiva velocidad al no controlar su tasa de actualizacion, juegos como Prince of Persia si aplican control de tiempo y por ello puede ser jugado en una maquina actual sin problemas de velocidad, cosa que el viejo Lode Runner en sus primeras versiones es imposible. Los emuladores de consolas como NES o SNES aplican tambien un control de fotogramas por la misma razon.

Te recomiendo que analices mejor el código del argentum, por cómo está diseñado hace que en todas las computadoras se tarde el mismo tiempo en llegar de un tile al otro, aun que en uno tenga 100 FPS y en la otra 50 ;)

Si me estas diciendo con esto que el AO no controla la tasa de fotogramas por segundo entonces lo estan haciendo mal en ese punto.

como el uso que le iba a dar a la dll era muy básico me decidí a hacer mi propio módulo de DX 8, y ahora (con el mismo RenderScreen posteado aquí) con el juego limitado en 100FPS tengo un consumo mínimo del CPU :), de todos modos nunca había usado DX8 por lo que se me están complicando algunas cosas, pero bueno...

Segun dices ahora mismo solo tienes implementado un render sencillo con codigo propio sobre DirectX8 (el codigo que has posteado antes pero con tus llamadas) pues todavia te queda implementar el resto del motor de tu juego (IA, Audio, fisicas, la propia logica de los niveles, etc...), entonces veras como tu consumo de recursos se vuelve a disparar facilmente por las nubes ;) Por cierto, para programacion en DirectX8 sobre VB6.0 parada obligatoria y recomendada: http://directx4vb.vbgamer.com/

En fin, compañero, no voy a seguir discutiendo esto y mas cuando lo consideras "subido de ego". Creo que te argumente correctamente desde mi primera respuesta como buenamente he podido, es un tema que tengo trilladisimo desde que lo implemente en la libreria y desde entonces ha funcionado como se esperaba. Si no quieres o consideras que no es necesario limitar los fotogramas por segundo en tu juego y que una espera fija que duerma la ejecucion de tu aplicacion es lo correcto, pues tu mismo, si asi te funciona a tu gusto perfecto pues (no se entonces el motivo de discursion y mas cuando curiosamente nadie se ha quejado por este asunto en años salvo tu).

Salu2...

P.D.: De la experiencia se aprende...

[Pato]

Antes que nada, no te sientas ofendido por ese comentario, pero realmente así lo noté, pido disculpas. Volviendo al tema, no sé si vistes el código del AO de alguna versión anterior a la 12.1(es demasiado probable) o vistes una más reciente, si no vistes apartir de la versión 12.1, te recomiendo que lo mirés ;), hay cosas interesantes sobre los FPS y como mostrar la animación, por ahí puedas sacar algo bueno sobre el asunto :D. Y en el AO sí se controlan los FPS, están limitados a 100, pero tranquilamente si se liberaran la fluidez es la misma, pero sería algo medio absurdo hacerlo, porque sería poner el CPU a 100% de uso y sin ningún fin porque el ojo humano no distinguría entre 100 y 200 FPS. Te agradezo demasiado el link que me pasastes, espero poder sacar algo provechoso de ahí ya que no me llevo bien con DX8(siempre he usado el 7). Saludos y nuevamente pido disculpas por mi comentario, no quería que suene como una ofensa.

[[EX3]]

La version de AO que en su dia vi trabajaba sobre DirectDraw7 si mal no recuerdo. Un par de personas me pidieron echar un ojo por que pretendian hacer su propia version del motor portandolo a DirectX8 con dx_lib32 hace un par de años o asi (que yo tenga entendido las ultimas versiones trabajan ya con Direct3D8 a la vista de los efectos utilizados y demas elementos).

Te agradezo demasiado el link que me pasastes, espero poder sacar algo provechoso de ahí ya que no me llevo bien con DX8(siempre he usado el 7). Saludos y nuevamente pido disculpas por mi comentario, no quería que suene como una ofensa.

De nada, y no me lo tome como ofensa, descuida (no te has pasado mucho los foros de stratos para saber de verdad lo que es una ofensa jajaja :P) DirectX4Vb es un referente en cuanto a programacion de DirectX sobre Visual Basic 6.0. Ahi comence en su dia a aprender las bases, primero en DirectX7 (DirectDraw7 sobre todo) y despues en DirectX8 en general, y paciencia por que entender como trabajar correctamente con una API 3D lleva su tiempo, incluso para temas 2D (mucha optimizacion para no formar un cuello de botella en la grafica, muy tedioso).

Salu2...

[Pato]

El AO sigue estando en DX7 aun que las intenciones es migrarlo a DX8, pero tener DX7 no es un impedimento para que tenga cosas rescatables como lo que te he mencionado. Lo que sí pasó de DX7 a DX8 es el ORE, que es el engine en el que se basa, que ahí también está implementado lo que te dije ^^. En fin, un saludo y gracias por tu tiempo, me voy a seguir peleando con el DX 8 :P.