Memoria

[divmas]

Hola a todos!

He decidido retomar un proyecto que inicié hace años con esta librería.... y qué abandoné por el mismo motivo que me ocurre de nuevo: soy incapaz de gestionar los recursos en memoria. No se estabiliza el consumo de memoria y va en aumento poco a poco.  Os dejo el código:

Código [Seleccionar] Expand

Option Strict Off
Option Explicit On
Friend Class Form1
    Inherits System.Windows.Forms.Form


    Private Sub Form1_Load(ByVal eventSender As System.Object, ByVal eventArgs As System.EventArgs) Handles MyBase.Load

        Me.Show()
        Graphics = New dx_lib32.dx_GFX_Class
        MainLoop = Graphics.Init(Me.Handle.ToInt32, 900, 500, 32, True)

        Do While MainLoop

            Select Case Estados
                Case 0 : CargarRecursos()
                Case 1 : BuclePrincipal()
            End Select

        Loop

    End Sub

    Private Sub Form1_FormClosed(ByVal eventSender As System.Object, ByVal eventArgs As System.Windows.Forms.FormClosedEventArgs) Handles Me.FormClosed
        MainLoop = False
        Graphics.Terminate()
        Graphics = Nothing
    End Sub

   

    Private Sub BuclePrincipal()
        nJuego.Update()
        nJuego.Draw()
    End Sub

End Class

Código [Seleccionar] Expand

Module programa

    Public Graphics As dx_lib32.dx_GFX_Class
    Public MainLoop As Boolean
    Public Estados As Integer = 0
    Public TexturaPista As Integer
    Public nJuego As New juego

    Public Sub CargarRecursos()
        TexturaPista = Graphics.MAP_Load("fondo.jpg", 0)
        Estados = 1
    End Sub

End Module

Código [Seleccionar] Expand

Public Class juego

    Public Sub Update()

    End Sub

    Public Sub Draw()

        Graphics.DRAW_Map(TexturaPista, 0, 0, 0, 0, 0)
        Graphics.Frame()

    End Sub

End Class

Seguramente debo ser un nefasto programador... Alguien me ayuda? Gracias!!!

[[EX3]]

Seguramente debo ser un nefasto programador...

O que el código de la librería tampoco es una maravilla :)

He desempolvado alguna prueba que tenia hecha en C# con la ultima versión de la librería (la 2.1.1 que esta subida en el repositorio), que simplemente dibuja primitivas y texto, y el ejecutable compilado como Release suele empezar en 6MB y subir poco a poco hasta 9MB y a partir de ahí, como al minuto o así, subir algunos KB o perderlos, pero prácticamente mantenerse estable en esas cifras en lo que he podido ver durante una hora.

Posiblemente se trate de algún problema de memoria originado de mi propio código en la librería o de como gestiona Visual Basic 6.0 la memoria internamente (que aunque el juego lo escribas en .NET, el runtime de Visual Basic 6.0 corre por debajo al ejecutar llamadas contra dx_lib32). No es cosa de .NET (de algún posible problema en como se comunica y gestiona las llamadas entre .NET y dx_lib32) por que en otras pruebas que tenia escritas en VB6 también sucede.

Un bug que si tenia localizado, aunque no se lo que lo causa, es cuando minimizas la ventana, sigas o no sigas llamando a Frame (tenga dx_GFX el control de la ventana), el consumo de memoria se dispara a lo bestia y sin parar (y también que mientras más tiempo este minimizada la ventana, más tarda Direct3D en retomar el control del contexto de render). Dicho esto, evita la opción de minimizar la ventana si no ejecutas en modo a pantalla completa.

Pues poco más que pueda decirte. Si como veo, el consumo no se dispara demasiado (subir unos pocos KBs cada varios minutos como en mi prueba), no lo vería un problema demasiado serio, así que animo con el proyecto y ya iras enseñando algo :)

Salu2...

P.D.: Algo que ya recomendaba en su momento a más de uno que seguíais usando dx_lib32. Si estáis programando en .NET, ya sea VB .NET o C#, os recomendaría quitaros de problemas y saltar a MonoGame (el XNA multiplataforma open source) o motores como Unity3D o Wave Engine, que son soluciones que están mucho más optimizadas y puestas al día que dx_lib32 (recordar que yo ya no la mantengo desde 2010).

[Hechelion]

@Divmas, como dice Ex3, la memoria suele subir en el inicio, pero luego suele estabilizarse y en valores que son decentes para el hardware actual. Por ejemplo, el juego "con 5 duros" (un juego hecho y derecho con mapas de tiles, música, cargas dinámicas,, etc) ronda los 150 MB de RAM usada, en ciertos momentos sube a 160 o 170 MB, pero cuando en NET sale el recolector de basura la memoria baja a 130 MB o 140 MB, así que es normal que veas cambios.

@Ex3 Para ser el trabajo de una sola persona y correr en vb6 el código si que ha sido una maravilla, es cierto que tiene sus problemas y algunos muy raros, pero si colocamos en la balanza lo bueno y lo malo, dxlib32 ha sido una joya, como siempre digo y diré, muchas gracias por el pedazo de trabajo que hiciste.

Durante bastante tiempo estuve en un tira y afloja con Dxlib32, me gusta su simpleza y funcionalidad, pero como dices, tiene sus fallos. En un inicio traté con Mono, pero bajo VB mono solo te permite proyectos "universal project" si quieres compilar un exe de toda la vida o si quieres portarlo a otras plataformas debes tirar de C# y eso me significaba tirar por la borda montones de librerías y clases que tenía programadas para VB con dxlib32.
Como anécdota, mi último juego lo estaba programando en SFML con linux y el mes pasado el PC donde tenía linux pasó a mejor vida y ahora mismo estaba tratando de portarlo a mono en mi PC con windows y no veas como me pican las manos para hacerlo con VB NET y tirar de dxlib32 jajajajaja.

[[EX3]]

@Ex3 Para ser el trabajo de una sola persona y correr en vb6 el código si que ha sido una maravilla, es cierto que tiene sus problemas y algunos muy raros, pero si colocamos en la balanza lo bueno y lo malo, dxlib32 ha sido una joya, como siempre digo y diré, muchas gracias por el pedazo de trabajo que hiciste.

Gracias :) A mi siempre se me ha quedado la espinita de, tras tantos años esforzándome en aprender y sacar adelante esta librería, nunca haberla podido llegar a usar proyectos propios (si, he llegado hacer varios motorcillos y herramientas, pero ningún juego como tal). Al menos el resto si le habéis dado caña a la librería y habéis sacados vuestros proyectos adelante, lo que hace que no se haya quedado en trabajo tirado a la basura :)

Durante bastante tiempo estuve en un tira y afloja con Dxlib32, me gusta su simpleza y funcionalidad, pero como dices, tiene sus fallos. En un inicio traté con Mono, pero bajo VB mono solo te permite proyectos "universal project" si quieres compilar un exe de toda la vida o si quieres portarlo a otras plataformas debes tirar de C# y eso me significaba tirar por la borda montones de librerías y clases que tenía programadas para VB con dxlib32.

Yo en mi caso el salto a C# fue muy positivo, y gracias a XNA en su momento, pude saltar a algo más moderno y poder trabajar sobre una capa más completa y estable que la propia dx_lib32. Y hoy día, si siguiera por ese camino, MonoGame se ha puesto mucho las pilas, cosa que me alegra mucho. XNA fue de lo mejor que salio para poder hacer juegos en .NET y si no es por MonoGame, ya se habría quedado totalmente obsoleto (lo que me sigue costando encontrar son formas de hacer distribuciones ligeras de los proyectos de escritorio, no logro encontrar formas sencillas de embeber las dependencias mínimas de Mono para evitar que el usuario final tenga que instalarselas, pero poder se puede).

Como anécdota, mi último juego lo estaba programando en SFML con linux y el mes pasado el PC donde tenía linux pasó a mejor vida y ahora mismo estaba tratando de portarlo a mono en mi PC con windows y no veas como me pican las manos para hacerlo con VB NET y tirar de dxlib32 jajajajaja.

Yo te diría que dieras portazo a VB en general y te pasaras a C#, seras más feliz, créeme xD (ah, y dx_lib32 es compatible también con C#... ahí lo dejo jeje)

Salu2...