Bgl + Escape

[sés]

 Pongo la última versión de BGL, aunque tenga pocos cambios, así puedo poner los fuentes de "Escape del Volcán".

Hay pocos cambios respecto a la versión anterior. Solo he añadido un módulo nuevo: BGL Util
En este módulo pondré cosillas que no encajan en otro y que son tan pequeñas que no merecen uno independiente.
De momento incluye:
- Clase Vector simple: Para evitar usar STL.
- Clase Parser: Sencillito por ahora.
- Clase Config: Para leer ficheros de configuración.

Este nuevo módulo vino por culpa de Config, ya que no me gustaba nada de lo que había visto para leer ficheros INI o similares.

La utilizo en un ejemplo de BGL y en Escape. El fichero de Escape es algo así:

Código [Seleccionar] Expand

/*
Fichero de configuración de "Escape del Volcán"
*/

fullscreen = no

player1 {
control {
 left = 75
 right = 77
 up = 57
}
}

Es, para mí, bastante más versátil que los típicos INI de Windows o Properties de Java. Aunque supongo que tendrá algún fallo y seguramente le falten cosas, creo que permite utilizar ficheros con una cierta complejidad ya que permite anidar secciones y el acceso a las variables es muy sencillo (cfg.getIntValue( "player1.control.left" )).
La clase permite tanto extraer variables como secciones completas (similar a XML pero mas simple).

Buneo, bueno, que me enrollo. Los enlaces:

BGL comleta: bgl-full-snapshot-2005-03-03.zip
BGL de desarrollo (cabeceras, librerías y documentación): bgl-dev-snapshot-2005-03-03.zip
La documentación, donde antes: Documentación

Escape del Volcán completo: escape-src.zip

[fiero]

 Una curiosidad, la función bgl::Painter::drawImage ¿La has hecho tú o utilizas internamente algúna función de windows?

un saludo

[sés]

Una curiosidad, la función bgl::Painter::drawImage ¿La has hecho tú o utilizas internamente algúna función de windows?

Es mía, está en los fuentes. Eso sí, aun está en C ^_^, espero pasarla pronto a ensamblador.

BGL Video tiene funciones de dibujo, o sea, mueve memoria de un sitio a otro. No tiene sentido que utilice nada específico del SO (de eso se encarga la clase VideoDriver).

[TheAzazel]

 Ses, si eso solo mueve memoria de un sitio a otro... quizas te interesen las rutinas de copia que tengo por ahi superoptimizadas, basicamente son las de AMD y otras modificadas para que funcionen bien en los P3 y PM.
Si las quieres, te las envio, yo las utilizo con mi lib y dependiendo del caso...sobre todo cuando es render por software..se nota bastante :)

un saludo

[sés]

 Supongo que más adelante, cuando soporte imágenes no indexadas sin transparencia o comprimidas, sí podría ser útil.

Ahora mismo no servirían de mucho :(. Las imágenes que pinto son indexadas; hay pocos "memcpy". Aunque no fueran indexadas, habría que comprobar cada punto para ver si se dibuja o no (key color).

Pero gracias, me lo apunto para cuando se pueda utilizar ;)

[gdl]

 Una preguntita sés... ¿por qué evitas usar STL?

[sés]

Una preguntita sés... ¿por qué evitas usar STL?

Porque quiero que BGL sea independiente de otras librerías. Utilizar un vector no lo veo motivo para obligar a alguien a utilizar STL.

No quiero empezar con dependencias de tropecientas librerías de terceros como otras librerías. Ya me ha pasado más de una vez ver algo que parecía majo... hasta que descubres que tiene 5 dependencias y lo que parecía una librería de unas Kb termina ocupando varias Mb... ejem.

[ethernet]

 Si quieres evitar librerías de "terceros" deberías codearte tu propia libc, tu propio SO, tus propios drivers de dispositivos... te recuerdo que STL es STANDARD template library y que por defecto viene en todos los compiladores de c++. Es posible que ciertas características como hash_map u otras no vengan en todas las implementaciones pero std::vector es tan estandard como printf, std::cout o cualquiera de las que seguramente uses en tu librería.

Todo el párrafo anterior viene a cuento de que si usas std::vector tendrás bastantes ventajas entre las que destaco la mayor rapidez de programación y de ejecución, el poder usar todos los algoritmos disponibles en la STL sin necesidad de cambios... por no citar la ventaja de poder cambiar un std::vector por un std::queue o un std::list sin necesidad de andar cambiando absolutamente nada (solo un typedef).

En conclusión, no veo nada más que ventajas usando STL. La verdad creo que la pega del tamaño es un sin sentido teniendo en cuenta que después hay imágenes y sonidos de un tamaño más que considerable que, seguramente es mucho más de lo que añadirá STL a tu ejecutable final.

un saludo

[sés]

Si quieres evitar librerías de "terceros" deberías codearte tu propia libc, tu propio SO, tus propios drivers de dispositivos...

Tampoco exageres :P Simplemente intento evitar la mayor parte de dependencias de otras librerías.

La clase Vector es un ejemplo. Tengo una clase Vector simple ya hecha, ¿para qué utilizar STL si esta clase me da lo que quiero? ¿Dónde está lo malo de quitarme una dependencia a cambio de nada?

Además hay que tener en cuenta que utilizar una simple función (no digo que este sea el caso) puede hacer que se enlacen bastantes más cosas que esa sencilla función. Cuando necesite varias clases de la STL pues... será otra historia.

[ethernet]

 

Cuando necesite varias clases de la STL pues... será otra historia.

Precisamente por eso puede ser el momento de usar STL

Quizás dentro de 3 meses cuando necesites algún contenedor más te arrepientas y tengas que volver atrás el desarrollo. Y eso en el caso de que todo vaya bien porque quien no se ha estado horas buscando un error que finalmente lo has encontrado en el código que supuestamente estaba bien.

Desde mi punto de vista el uso de STL da muchísimo más de lo que quita. Es más, yo diría que ahora mismo es lo mínimo que puede ofrecerte un lenguaje de programación.

[sés]

 Acabo de hacer una prueba. He compilado un programa que tenía de pruebas para mis clases Vector y String:

Usando bgl::Vector y bgl::String -> 49217 bytes
Usando stl::vector y stl::string -> 120059 bytes

70842 bytes de diferencia.

De momento como que me quedo con mis clases ^_^

Para mí es el mismo caso que tengo entre utilizar SDL o hacer BGL. SDL me da muchas cosas, pero no quiero cargar con todo para 2 que utilizo. Así que hago BGL. Lo mismo con STL.

Que algo tenga 1000 cosas y no tenga fallos me parece estupendo, pero si solo necesito el 1%, me lo hago yo mismo y listo.

Por muy estándar que sea, si hace crecer mi código con cosas que no necesito, me sobra. Hacer las cosas de otra forma sería ir en contra de mis principios, y BGL no sería como yo quiero.
Terminaría convirtiendose en un mastodonte y al final tendría un pegote sin las ventajas que quiero que tenga. Entre ellas está el que sea ligera.

[ethernet]

 ok, supongo entonces que sintetizarás las imágenes y el sonido para que no te ocupen más de los 70kb que te añade STL.

Por otra parte debes saber que el código el código "extra" que te añade STL es muy ortogonal con lo cual añadie nuevas funcionalidades apenas hará variar tu tamaño de ejcutable. Me resulta curioso que a estas alturas os preocupeis por 70kb más de ejecutable, si quieres reducirlo usa upx (upx.sf.net).

Ahora me gustaría que hicieras un benchmark de rapidez de ejecución, eso sí, especificando como has usado STL.

saludos

[senior wapo]

 Pobre sés, un poco más y le pegas  (twist) Es broma  ;)

La verdad es que STL tiene sus ventajas, como bien dices.

El contrapunto es el peso que añade al ejecutable y al working set de la aplicación (modo pijo de decir que usa mucha memoria de acceso frecuente y la fragmenta, y si, se que luego crece homogeneamente, es solo el pico inicial y tal).

El tema es que para determinados casos, el tamaño si importa. Y aunque no importase, los puristas lo queremos todo light y con 0% grasas XD


Y ya hablando de importancia de tamaños, me marco un offtopic por la face:
Interesado como estoy en el mundo indie, donde la descarga del juego completo (con graficos y sonido) debe ser de unos 10MB máximo (15MB en casos muy muy muy excepcionales) y funcionar en  PCs de 64MB-128MB, me hice unas pruebecillas de carga de distintos motores 3D (los valores son medias a ojo, no es una prueba estricta ni quiere ser una comparativa):

Código [Seleccionar] Expand


Ogre:                    10MB en disco       40-50MB de RAM
Irrlicht:                  1.5MB disco           25-35MB de RAM
Blitz3D:                 1.5MB disco             8-10MB de RAM
Nebula Device 1:    1.5MB disco               4-9MB  de RAM


Me ha sorprendido ver el consumo de memoria de Irrlicht. No es tan compacto como parece al ver el tamaño en disco.

[zupervaca]

 el blitz3d ponlo en cabeza con 10000megas por que las pruebas que hice yo hace tiempo con simplemente leer una animacion de md2 consume 60 megas  :D

bueno yo puedo decir y sentirme orgullo que yo no uso stl tampoco ya que usa templates (no os hecheis las manos a la cabeza jeje), los templates no me gustan por que por cada tipo que definas el compilador genera una clase entera con ese nuevo tipo y el exe y la memoria en ejecuacion aumentan, mientras que si usas conversiones de void solo generas una clase en disco y en memoria, ademas las conversiones entre puntero son "ficticias" ya que son para que el compilador entienda el tipo de dato y no implica perdida de velocidad en ningun caso y si no os gusta el void hacer una clase base y derivar de ella  :P

saludos

[sés]

 No entiendo que tiene de raro no querer usar STL (o cualquier otra librería o función).

Si no me gusta, sea por la razón que sea, cómo funciona una librería o función concreta, ¿por qué no rehacerla a mi gusto?
Para eso aprendí a programar, para hacer lo que necesite como lo necesite. Si algo no sé hacerlo, me aguanto con lo que tenga a mano, pero mientras tanto...

Creo que las librerías y las funciones están ahí para el que le sirvan y quiera utilizarlas. No veo la razón de usar algo por el simple hecho de que esté ahí.

Si la gente se limitase a utilizar lo que ya está hecho, solo por no reinventar la rueda, probablemente estaríamos utilizado la librería BGI de Borland... o algo peor :P

La programación no es si no reinventar constantemente la rueda. A veces, curiosamente, se inventan ruedas mejores ;)

Yo ni siquiera estoy reinventando la rueda, simplemente hago mi popia rueda.


-= EDIT =-
Se me olvidaba decir que probablemente utilice el método que dice zupervaca. Es lo que hacía antes y me parece lo mejor. Utilicé mi "template" Vector porque la tenía hecha y quería probarla. Seguramente cambie mi "template" Vector por una "clase" Vector (solo tengo que convertir lo que tengo en C a una clase C++ y listo).
Si os fijáis, ni siquiera incluí Vector en la documentación ^_^