Avances, Diario de...

Started by SplinterGU, April 17, 2008, 03:00:51 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

SplinterGU

no, podes modificar el alpha como ya probaste, pero no con suavizado...
eso implicaria que la linea realmente sea mas grande que 1 pixel... lo que podes hacer es trazar varias lineas con diferentes alfas y con algun pixel de diferencia... y finalmente trazar la linea final sin el alfa...
Download Lastest BennuGD Release: http://www.bennugd.org/node/2

Windgate

Ok Splinter gracias por la aclaración. Aquí dejo el detalle del efecto de línea con suavizado, a 1 píxel en negro puro, sin alpha, por si a alguien le diese por implementar el algoritmo en un futuro, fijaros que ni un sólo pixel queda totalmente negro realmente xD


Por supuesto sin zoom la línea queda estupendamente, no se ve ni un pixel.
Iván García Subero. Programador, profesor de informática, monitor de actividades culturales y presidente de TRINIT Asociación de Informáticos de Zaragoza. http://trinit.es

SplinterGU

he incluido nuevos productos en el svn de autoria propia con licencia LGPL... y he actualizado el componente loadlib a LGPL... ire haciendo lo propio con los modulos de mi autoria... y si en el futuro puedo pasar todo a LGPL, asi lo hare.

saludos...
Download Lastest BennuGD Release: http://www.bennugd.org/node/2

Windgate

Por lo que leo: http://es.wikipedia.org/wiki/GNU_Lesser_General_Public_License

Con ello Bennu es todavía más libre... No puede ser más libre diría yo... Karma++ SplinterGU, ¿Sabes que vas a ir al cielo quieras o no? ;)
Iván García Subero. Programador, profesor de informática, monitor de actividades culturales y presidente de TRINIT Asociación de Informáticos de Zaragoza. http://trinit.es

SplinterGU

je, gracias... todavia no estan todos los modulos, hay que estudiar bien, cuanto tienen de fenix aun... y si se llegara a conseguir que todos los que participaron en Fenix (o por lo menos los principales) autoricen a cambiar la licencia a LGPL entonces seria fantastico y se cambiaria...
Download Lastest BennuGD Release: http://www.bennugd.org/node/2

Windgate

He accedido al Centro de Software de Ubuntu, el "gestor de paquetes" de la nueva 9.10, he buscado Bennu para ver si había algo pero veo que no... En el tema de Linux ya sabéis que apenas llevo 1 año y eso es "nada", ¿Habría alguna forma de hacer que el paquete de Bennu fuese un paquete instalable desde ese menú?

Por tema de hostearlo supongo que no hay problema, bennugd tiene su hosting y algunos más podríamos aportar, ¿Qué clase de impedimentos hay? Por curiosidad :P
Iván García Subero. Programador, profesor de informática, monitor de actividades culturales y presidente de TRINIT Asociación de Informáticos de Zaragoza. http://trinit.es

DCelso

Monstruos Diabólicos

"A PAck of classic GAMEs For BennuGD" en desarrollo
http://code.google.com/p/apagame4be/

Windgate

Gracias DCelso... Ahora creo recordar que mire ese hilo tiempo ha, voy a verlo de nuevo porque tengo memoria de pez :P
Iván García Subero. Programador, profesor de informática, monitor de actividades culturales y presidente de TRINIT Asociación de Informáticos de Zaragoza. http://trinit.es

FreeYourMind

Me estaba haciendo una preguntilla:


Sobre el map_block_copy:


Seria posible crear un mapa 'virtual' que no ocupará memória à diferencia de crear uno cargando un mapa vacio, el cual si va ocupar memória ?

Lo pregunto sobretodo por temas de rendimiento, ya que el mapa seria para pintarlo utilizando el map_block_copy, y lo ideal es que la memória que este ocupa fuera sólo la memória ocupada por los gráficos utilizados en el map_block_copy (y sus punteros) y creo que la memória del mapa inicial para poder utilizar el map_block_copy sobrária....

Vamos, resumiendo, actualmente este mapa se carga al principio de la fase para poder pintar los tiles sobre el, pero creo que la memória de este mapa en sí sobraria, ya que sólo sirve para servir de referencia a los tiles pintados con map_block_copy...

a lo mejor existe otra alternativa para hacer esto sin usar un mapa de base ...

No se se me entendeis...


Windgate

No comprendo, un mapa virtual seguiría ocupando memoria, ¿Dónde iba a estar si no?
Iván García Subero. Programador, profesor de informática, monitor de actividades culturales y presidente de TRINIT Asociación de Informáticos de Zaragoza. http://trinit.es

FreeYourMind

#760
Claro es que le llamo virtual para decir un mapa null.
Vamos lo ideal seria que el map_block_copy puediera copiar sobre una region nula (o mapa nulo que es lo mismo), sin tener aparte de la memória del tile, la memória del mapa vacio (ya que me imagino que los otros tiles iguales apuntarian a la memoria del primero y no ocuparian espacio).

O sea, que el map_block_copy pudiera poner ese tile en las coordenadas x,y pero sin necesidad de basarse en un mapa destino, y al final tendriamos un mapa completo pero compuesto sólo por la memória de los tiles.

Porque me imagino que al usar un mapa + tiles, vas a tener aparte de la memoria de mapa que cargaste al inicio, la memoria de los tiles usados en el. Si este ultimo no es así pues el problema ya estaria resuelto ;)

Por otro lado, creo que no ocupa lo mismo un mapa con X,Y dimensión pintado de negro, que el mismo mapa lleno de colores.

Drumpi

Pues yo sigo sin enterarme de lo que quieres decir, la verdad...
Creo que map_block_copy coge los datos del mapa origen y los pega en el destino, sin usar memoria intermedia, porque no vas a descargar el mapa origen durante la operación. Si lo que quieres es tener una copia en memoria tienes map_clone, y si quieres guardar un trozo creas un nuevo mapa del tamaño que quieras y haces el map_block_copy sobre este.

Pero un mapa con dimensión (x,y) pintado de negro ocupará lo mismo que el mismo mapa lleno de colores, porque el propio negro es un color (aunque hablemos de negro, transparente o vacío, el 0 ocupa una posición de memoria). Lo que dices sería cierto si se usase algún tipo de compresión en memoria, pero no es así.
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)

Windgate

Yo tampoco entiendo del todo la sugerencia, pero FreeYourMind, créeme que he estado investigando map_block_copy y me interesan mucho las posibles mejoras sobre esta función, especialmente en 32 bits.

Entiendo que propones una mejora de eficiencia, pero no comprendo qué propósito tiene ese mapa virtual... ¿Para qué caso o casos en concreto ahorraría memoria?

Por tu último comentario me parece que te refieres a hacer un map_block_copy sobre un mapa "vacío", para componerlo completamente desde 0. Por ejemplo con mí módulo "Dialog Boxes" hacía algo así, la idea de hacerlo desde 0 es interesante pero no la tuve en cuenta, exprésate más a fondo sobre el tema please.
Iván García Subero. Programador, profesor de informática, monitor de actividades culturales y presidente de TRINIT Asociación de Informáticos de Zaragoza. http://trinit.es

SplinterGU

Quote from: FreeYourMind on November 27, 2009, 12:42:42 PM
Claro es que le llamo virtual para decir un mapa null.
Vamos lo ideal seria que el map_block_copy puediera copiar sobre una region nula (o mapa nulo que es lo mismo), sin tener aparte de la memória del tile, la memória del mapa vacio (ya que me imagino que los otros tiles iguales apuntarian a la memoria del primero y no ocuparian espacio).

O sea, que el map_block_copy pudiera poner ese tile en las coordenadas x,y pero sin necesidad de basarse en un mapa destino, y al final tendriamos un mapa completo pero compuesto sólo por la memória de los tiles.

Porque me imagino que al usar un mapa + tiles, vas a tener aparte de la memoria de mapa que cargaste al inicio, la memoria de los tiles usados en el. Si este ultimo no es así pues el problema ya estaria resuelto ;)

Por otro lado, creo que no ocupa lo mismo un mapa con X,Y dimensión pintado de negro, que el mismo mapa lleno de colores.

La idea de un tile no es que si tenes que pintar un tile 10 veces tengas 10 graficos clones... la idea es que uses un solo grafico para cada uno de los tiles...

tiles no necesariamente significa que tengas que usar map_block_copy (puede, pero no es necesario), podes usar procesos tambien...

como sea, en el caso del block_copy, solo copias a un mapa mas grande... pero no por eso vas a consumir mas memoria...

segun leo en el mensaje que queres transmitir es que ademas de hacer el map_block_copy, tenes un grafico unico por cada uso del tile... eso no es necesario... si no es eso lo que quisiste decir, entonces no te entendi...
Download Lastest BennuGD Release: http://www.bennugd.org/node/2

FreeYourMind

#764
Buenas. Estoy de vuelta, por fin espero no volver a quedar sin portatil, ya que de una vez quite el maldito disco duro de mi portatil, ahora acabo de estrenar disco duro de 680 gigas, como evolucionan estos trastos :)

Comento lo del map_block_copy, porque cargo 3 mapas para pintar las distintas partes de un nivel (objectos de fondo, objetos de colisiones y objetos frontales que tapan a los personajes), como si fueran 3 en 1. Al hacerlo repito 3 veces el mismo mapa, ya que cada uno va construir su respectiva region o scroll. Lo que pienso es que internamente esta función podria ser más optimizada, no veo sentido que se necesite de principio un mapa para poner tiles en el, tener un mapa sin memória y que al final los tiles al copiarse en realidad se estarian creando regiones de mapas con esos tiles. o sea, se construyerá el mapa con tiles sin tener una base para ponerlos... ya se que hay formas de hacerlo, pero si tuvieramos una función equivalente a la que le pasaramos un mapa destino que no existierá molaria por comodidad.

Es que noto que por ejemplo si no borro este mapa al empezar de nuevo el nivel, al generar de nuevo los tiles (ya que lo hago al empezar el nivel), estos se sobreponen sobre los antiguos del mismo mapa en memoria (y como los antiguos son los mismos en la misma posición), el mapa va tener cada vez mas memoria ya que se va sobrecargar de objetos, aunque siga teniendo la misma dimensión...

Esto tambien me parece un poco raro ya que si estamos poniendo tiles en ese mapa es como si estuvieramos de nuevo pintando en el, y si un mapa ocupa siempre el mismo tamaño tenga el pintado que tenga como decis, el mapa no tendria que aumentar de memoria...