Spacepong

[AgeR]

 Hola, a ver, me he bajado el SpacePong, y he visto que incluyes varias librerías que no entiendo por qué están ahí. En concreto la mfc71.dll y msvcr71.dll. Queres decir que hacen falta para que funcione el juego?
Qué usas de las mfc y por qué? Cómo solventas esto en la versión linux?

Lo cierto es que estoy programando una pequeña librería (mucho más pequeña que la tuya), y me resulta curioso que uses las mfc sobre todo. De hecho antes de seguir con la mía me interesa ver si la CRM32Pro se adecua a lo que necesito.

Otra cosa, la CRM32Pro funciona para Mac? Me interesa especialmente que funcione en Mac ya que la usaría para un juego con vistas al share o freeware, pero que funcione tanto para PC como para Mac. Además esas dos DLL que comentaba ocupan casi mega y medio, lo cual también me echa un poco para atrás.

Venga gracias!  :lol:  

[TheAzazel]

 Buenas Ager,

a ver si te explico sin liarte mas:

SpacePong.exe -> es un configurador para Win32 que utiliza MFC. Utiliza mfc71.dll, msvcr71.dll, dsetup.dll y CRM32Pro.dll. Esto lo que hace es generar el fichero setup.cfg y despues ejecuta el game.dll que es el juego propiamente dicho. Obviamente este configurador solo es para Win32, por eso hace un tiempo (lo mismo has leido algo por aqui) decidi a la vez que incorporar un XML parser a CRM32Pro, diseñar un nuevo configurador completamente portable(win32,linux y en un futuro mac) que no estuviera basado en MFC(de hecho, utiliza solo CRM32Pro.dll jeje) y ademas, que fuera completamente customizable...utiliza una especie de skin donde puedes cambiar todo su aspecto y adecuarlo a tu juego.
Hoy por hoy, el nuevo configurador esta casi terminado, me falta la parte mas dura que es la de XML, creo que para finales de este mes estara todo listo.

Game.dll -> como dije mas arriba, es el juego propiamente dicho, utiliza CRM32Pro.dll y por razones del compilador utilizado (el VS 2003) necesita msvcr71.dll. Si quieres prescindir de esta lib..se pueden hacer dos cosas, utilizar Mingw32 o VS 6.0(para este ultimo, tendria que compilarte una lib.. pero veo mas practico utilizar ming32 que encima es gratis).


Resumiendo, CRM32Pro no utiliza para nada las MFC y si quieres prescindir de msvcr71.dll es factible utilizando, por ejemplo, mingw32. Luego si quieres que toda la dll sea un poco mas pequeña... puedes pasarla el UPX y se queda en unos 300Kb.
La version para Mac esta mas que prevista, el unico problema es que hoy por hoy no tengo ningun Mac donde hacer las pruebas.... aunque si dispongo del MacOS x86 donde mas adelante podre hacer pruebas... luego si soportara MacOS pero no sobre PPC si no sobre x86 (a no ser que alguien me done un Mac jeje o alguien quiera hacer un port...).

Asi que, usando mingw32 podrias tener la lib empaquetada en unos 300Kb... si tienes cualquier otra duda... aqui estoy. Me gustaria saber al final porque te decides y la razon(para mejorar si es posible jeje).

saludos

[AgeR]

 Ok, gracias, ya me queda todo más claro.

El tema es queeeee....  :rolleyes: no quiero usar mingw32, estoy muy cómodo con VC6 y no quiero calentarme la cabeza cambiando mi forma de trabajar de siempre. Estaría bien que incluyeras una versión para los trogloditas como yo que usamos VC6  :lol: .

Otra cosa, el juego... por qué está en una dll? Alguna paranoia? Me parece cuanto menos curioso.

Por último, cuándo vas a ponerte con la versión Mac? Parece una tontería, pero entre esto y que no me rule la librería con el VC6 me echa un poco para atrás el usarla.
Por lo demás, lo que llevo visto hasta ahora tiene buena pinta  ;)

[TheAzazel]

 De hecho, si linkara la libreria con VS 6.0 me ahorraria el rollito de los msvxxx71.dll ya que serian los standards que todos los win2000 y winxp tienen... y por optimizacion de codigo y demas no es porque entre el 6.0 y el 2003 en lo que yo hago la diferencia es 0. Para la proxima version, como minimo incluire una distri para la 6.0 y es posible que pase del 2003 y lo haga todo con el 6.0 (que por otro lado, es completamente compatible con la gente q utilice el 2002, 2003 y el 2005).


Lo del juego y la dll, es solo cuestion de limpieza, es un ejecutable pero para impedir que la gente lo ejecute directamente, lo renombre a dll y asi forzar que todo el mundo pase primero por el configurador y en un futuro es posible que tenga algun otro sentido(proteccion frente a modificaciones) pero hoy por hoy, solo es eso jeje

Lo de Mac.. si mi roadmap va bien, me pondre con ello para enero... antes van muchas mas otras cosas, pero vamos, port a Mac habra, me juego un jamon de pata negra!!! :P ademas, si alguien lo tiene y quiere hacer un port... pues ya sabe jeje

ya me contaras...

[AgeR]

 Más preguntas =)
Para cuando esa nueva versión?
Puedes comentar algo de lo que tienes en el roadmap?
No pueden usarse OGGs como efectos? (Por las shots del Editor parece que no) Podrán?

Una de mis manías es intentar que las librerías que uso o hago me "encorseten" lo mínimo posible. Es decir, que no me pongan restricciones que no tendría si usara otra cosa (lo digo por el uso de los dpf, ipf...

Para cargar las imágenes que usas? Veo que no usas sdl_image, por qué?

Otra cosa que no me acaba de gustar demasiado es la mezcla en el código. Una cosa que me interesa de lo que busco, es que más que una librería, sea un framework. Es decir, veo que llamas a funciones y estructuras de las SDL. En los ejemplos veo SDL_Surface en bastantes sitios. Una de las primeras cosas que había hecho yo es que no se pueda usar una superficie "a palo seco". Veo más adecuado crear varias clases (Button, Sprite, GUI_Image, TileSet, etc, o como se quieran llamar). Luego un manager ya se encargaría de almacenar las superficies adecuadamente.
Otro ejemplo de lo que digo: CRM32Pro_Init(SDL_INIT_VIDEO | SDL_INIT_AUDIO | SDL_INIT_TIMER)
Sería más lógico así: CRM32Pro_Init(CRM_VIDEO | CRM_AUDIO | CRM_TIMER)

Al menos para mí, claro  :rolleyes:
Básicamente a lo que me refiero es a que el usuario se olvide de que está trabajando con las SDL y use funciones proporcionadas directamente por la librería.

Bueno, tómate todo esto como preguntas y curiosidades, después de todo es sólo mi punto de vista. Espero que te ayude en algo.

Voy a seguir trasteando con la librería, y a ver si en la siguiente versión me pongo con ella, porque a pesar de toda la parrafada puntillosa, me parece impresionante todo el curro que llevas  (ole) .

[TheAzazel]

 La version con varias mejoras y con un parser XML sera para este mes:

    x November 2005 - 4.70 - Major Update
    -------------------------------------
    · New main interface with all global functions and vars unified:
      - All global vars (screen,mouse_x,etc) have been added to main class.
      - Init,Quit, etc. have been added to main class.
        For example: CRM32Pro_Init() has changed to CRM32Pro.Init().
      - CRC32 have been fully rewritten and integrated on the main class.
      - Added a true random number generator.
      - TODO: Fully working XML parsing system.
    · IStuffDPF:
      - LoadBlock() return compressed size of loaded block(if it was successfully).
      - AddFile() and AddData() return compressed size of added block(if it was successfully).
      - Added new member ->FreeBlock() to free a loaded block.
    · CSprite does not depend on ITimeSystem.
    · IButton:
      - TODO: Support input box text. (el Normal=Icon, y se utilizara el normal)
      - Icon button type removed. Previous Icon will have its right behaviour. Now, Normal=Icon.
      - Minor fix: hold 'check on' state of check buttons.
      - Minor fix: allow to enable a check button after a previous disable.
      - Minor fix: setup of slider button is easier than before (25pixels on each X side).
    · INetwork:
      - Bug fixed: client thread consumed all CPU cycles.
      - TODO: DataNets reception queue.
      - Print a message when your are losing datanet (your code did not handle it).
      - Ping occurs every second.
    · Added the static library. You can choose between shared or static.
      Use CRM32PRO_STATIC define to enable it. Only works on Win32 platform.
    · Fully cleaned shared interface of external libraries.

Me faltan los TODOs que estoy en ello...

El configurador multiplataforma y mas cosillas(entre ellos, soporte a glSDL) para diciembre/enero.

Roadmap... bueno, aqui tengo uno de desarrollo interno por si te vale de algo :P, no esta completo y solo tiene las ideas generales para que no se me olvide implementarlas... por cierto, puede ser un poco caotico pero total... como solo es para mi y yo lo entiendo jeje

v4.80
- DPF con proteccion,clave?
- Slight improve documentation. (mejora de los linkados, instalacion,problemas tipicos(LOGHIGH),ctile(un ejmplo added) y demas...tipos de botones(sobre todo slider))
-Bucle de eventos...en Button->Check() y en Cursor->UpdateVars() lo hace...mas luego en el main..unificar
-ScreenFX: efecto stars3d, zoom2x altamente optimizado, fuego.
-Autorecuperar superficies en DirectX al perderlas
while ( SDL_BlitSurface(image, imgrect, screen, dstrect) == -2 ) {
                while ( SDL_LockSurface(image)) < 0 )
                        SDL_Delay(10);
                -- Write image pixels to image->pixels --
                SDL_UnlockSurface(image);
        }
-CRM32Pro.Flip() coordinara todas las acciones de redibujado, dirty rectangle and so on.
o
-CRM32Pro.update: sera un flip y demas historias para coordinar los volcados con autorestores(dirty rectangle, etc..)

v5.00
-Incluir glSDL backend(funciona muy bien!). SDL 1.3?
-Integrarlo con los demas sistemas
-Rediseñar el setupproyect para que incluya a Opengl,ddraw y windib en win32 y en linux sus backend
-Añadir al setup un readme y una descripcion del proyecto propio?.
-Even a un microtest para averiguar que es mejor, ddraw,windib o ogl.
-Funcion en main.cpp que cargue/grabe las configuraciones de este


Varios sin catalogar (futuras versiones)
--------------------------------------
-Support UDP communications.
-Fine tuning en pentiummx,k6,p4 willamette
-Rollito begindraw enddraw para englobar todos los restores...interaccion entre tile,sprite y cursor
-Particulas??
-Mejorar la documentacion
-Added the posibility to center video stream on screen
-Editor de GUI.

Y si se pueden usar OGGs como efectos y como musica... en el screenshot se ve que en efectos tambien soporta OGGs... o te refieres a otra cosa?

Y no utilizo sdl_image porque no quiero engrosar mas la lib, nativamente soporta solo BMP y a traves del EditorDPF tambien PNG para transparencias y demas aunque es posible que el soporte PNG tambien lo incluya directamente en la lib, pero por el momento no lo tengo pensado... Si quieres usar sdl_image puedes, todas las funciones internas de la lib estan preparadas para cargar informacion alpha asi que puedes abrir el formato que quieras que funcionara... hoy por hoy es solo por tema de no hacer mas grande la lib.

Y eso de la mezcla de SDL+CRM32Pro pues...es que mas que una libreria quizas deberia llamarlo framework ya que lo que hace es añadir otra capa mas por encima de SDL para simplificar varias tareas...pero SDL sigue estando ahi, es el nucleo de todo. Cambiar sus flags, el nombre de sus funciones, ademas de ser costoso en tiempo y sobre todo mantenimiento, no es muy practico. De este modo cualquiera que sepa usar SDL podra utilizar CRM32Pro y al reves puesto que es lo mismo.
Te pongo un ejemplo de la facilidad de no renombrar nada... si utilizas CRM32Pro puedes usarlo solo como si fuera SDL (no utiliza nada de CRM32Pro) y luego , con solo cambiar el Init y Quit(SDL_Init() por CRM32Pro_Init()) obtendras mas rendimiento grafico puesto que CRM32Pro_Init ademas de iniciar SDL, cambia un par de cosas, optimizaciones de copia y demas que se nota... puedes hacer la prueba si quieres.

Bueno, espero haber resuelto todas tus dudas... y no te preocupes, todo lo que me dices me lo tomo como un feedback que lo unico que puede lograr es que mejore esto o lo otro. Ya sabes, si te van saliendo mas cosillas...solo tienes que decirlo!

Saludos

PD: perdonar por el ladrillo jeje