Abro este "topic", en consecencia al debate surgido con los cores en el topic de bennu wii, para recoger los post referentes a este tema.
Post que inició el debate.
Pues yo estoy sorprendido con el tema de transparencias en 8 bits de color.
He hecho mil pruebas y la única que me ha dado resultado es poner el color que quiero que sea transparente en la primera posición de la paleta y luego en las propiedades del png decirle que este color sea el transparente.
Si el color que eliijo como transparente está en otra posición, las aplicaciones como gimp, xnview y acdsee pillan bien la transparencia pero bennu no,sigue mostrando el color real y usa como transparente el color negro (0,0,0).
Si no elijo color transparente y dejo el color que quiero como transparente al principio de la paleta, bennu tampoco me lo pilla como transparente, pilla siempre como transparente el negro (0,0,0).
Osea que bien o usas imágenes de 8 bits de color usando el negro como fondo sin seleccionar ningun color como transparete
O bien pones al principio de la paleta el color que vas a usar como fondo y en las propiedades del png dices que es éste tu color transparente, supongo que esta información irá en la cabecera del png.
He visto que gimp también maneja pngs de 16 bits en el que 8 son para el color usando paleta y 8 para el canal alpha, estos ni papa de si van en bennu.
De esto se ha debatido ya varias veces y creía que me había quedado claro pero siempre aparece algo que pone en duda lo que sé. :D
yo tengo poca memoria, pero uds. me ganan...
ya se hablo mil veces que el color transparente es el 0 (no rgb(0,0,0), sino el valor de color "0")
en 8 bits = index de paleta 0
en 16 bits = valor "0", en el caso de los png, se convierte cualquier pixel cuyo alpha sea menor de 50% a valor "0"
en 32 bits = solo el valor "0" absoluto (teniendo en cuenta el alpha) es tranparente, eso igual que en 16 bits, pero la diferencia es que hay transparencias parciales (alphas diferentes en cada pixel).
Quote from: DCelso on May 31, 2009, 11:46:19 AM
Pues yo estoy sorprendido con el tema de transparencias en 8 bits de color.
He hecho mil pruebas y la única que me ha dado resultado es poner el color que quiero que sea transparente en la primera posición de la paleta y luego en las propiedades del png decirle que este color sea el transparente.
Si el color que eliijo como transparente está en otra posición, las aplicaciones como gimp, xnview y acdsee pillan bien la transparencia pero bennu no,sigue mostrando el color real y usa como transparente el color negro (0,0,0).
Si no elijo color transparente y dejo el color que quiero como transparente al principio de la paleta, bennu tampoco me lo pilla como transparente, pilla siempre como transparente el negro (0,0,0).
Osea que bien o usas imágenes de 8 bits de color usando el negro como fondo sin seleccionar ningun color como transparete
O bien pones al principio de la paleta el color que vas a usar como fondo y en las propiedades del png dices que es éste tu color transparente, supongo que esta información irá en la cabecera del png.
He visto que gimp también maneja pngs de 16 bits en el que 8 son para el color usando paleta y 8 para el canal alpha, estos ni papa de si van en bennu.
De esto se ha debatido ya varias veces y creía que me había quedado claro pero siempre aparece algo que pone en duda lo que sé. :D
ja ja ja amigo :)
si tanto se les complica hacer esto, tienen una solución muy sencilla, aunque un poco tardada:
trabajar sobre el buffer, tomar todos los colores 0 y cambiarle el índice al del color que debe ser, o al más parecido, y el del color que podría ser el negro cambiarlo a 0, con eso debe funcionar, aunque es muy tardado, nada recomendable es una solución, haganse un programita que lo haga y exporte sus png y listo, ya tienes png con paletas correctas. :)
SplinterGU, no sé que versión de pngs soporta Bennu, me he vuelto a leer varias especificaciones de pngs (http://es.wikipedia.org/wiki/PNG) y en todas ellas hablan de lo mismo. A un PNG indexado de 8 bits se le puede asignar que uno de los colores de su paleta sea el transparente.
Quote
El PNG admite, al igual que el GIF, imágenes indexadas con transparencia de 1 bit o "binaria". Este tipo de transparencia no requiere de un canal adicional y únicamente admite que un color de la paleta aparezca transparente al 100%.
Además si pruebas con diferentes visores de imágenes (como xnview o acdsee) ves que éste soporte es nativo, es decir el color que seleccionaste en la paleta que quisieras que fuera transparente no se ve.
Lo que hace bennu es obligar a que sea siempre el color que está en el índice 0. Por eso, si lees mi antiguo post, verás que la única prueba que me fué válida es en la que puse mi color que quería que fuera transparente (en este caso era el blanco) en el primer índice de la paleta y le dije al editor que lo usara como transparente. Es el único caso en que el blanco se ve transparente en los visores de imágenes png y en bennu.
Ejemplo práctico usando gimp:
creas tu imagen indexada de 256 colores, usas el verde clarito como fondo y empiezas a dibujar tu sprite, usas por ejemplo el negro para crearle los bordes del sprite, cuando terminas seleccionas el verde clarito y le das a añadir al canal alfa, desaparece y no se ve. Guardas el archivo en png.
Lo abres con xnview y no se ve el verde clarito, es decir, es transparente.
Lo abres con bennu y sí que se ve el verde, pero es más, si pones una imagen de fondo y mueves el sprite, verás que por los bordes se ve el fondo, esto es porque al guardar la imagen gimp pone el negro en el primer índice de la paleta. Por tanto bennu asigna automáticamente éste como color transparente.
Yo creo que habría que revisar cómo abre bennu los pngs de 8 bits, porque no utiliza la información de transparente que en ellos hay, lo suyo sería que usase esta información para respetar lo que hacen los demás programas externos, y si no encontrara la información de transparente entonces aplicar la lógica que hasta ahora hace. Así cumpliría el estándar png y habría compatibilidad hacia atrás.
Las imágenes de 16 bits ya es otra historia, porque las especificaciones de png no soportan RGB para este tipo. Bennu tiene que usar por pe...otas pngs de 24 bits para meter en su formato 16 bits. Estas imágenes png de 24 bits usan 8 bits para cada canal RGB, aquí no existe transparencia (ni siquiera binaria) así que bennu usa el absoluto 0 para transparente pero coincide con el rgb(0,0,0) así que el negro en imágenes de 24 bits es el transparente para bennu en densidad 16.
Prueba práctica, haces tu imagen con gimp poniendo el negro como fondo, eliminas el canal alfa en la sección de capas. Guardas la imagen, la abres con xnview y el fondo se ve negro.
La abres con bennu en densidad 16 bits y se ve transparente el negro.
Las imágenes de 32 bits funcionan perfectamente porque bennu se ajusta al formato png de 32 bits de forma adecuada(en este aspecto Splinter hizo un gran trabajo), en este formato hay 8 bits para cada canal RGB y 8 bits para el canal alfa, lo que supone poder usar colores semitransparentes. En este caso el color que usa bennu como transparente es el absoluto 0, éste coincide con el RGBA(0,0,0,0) (negro con alfa igual a cero) y solo con este, si intentáramos usar el blanco con alfa 0 no se vería el blanco pero sí daría colisión otro objeto con él.
Ejemplo práctico con gimp.
Creamos una imagen con gimp, usamos como fondo el negro, creamos un sprite con un borde bastante gordo de color blanco, añadimos el negro al canal alfa desde el menú de capas, añadimos el blanco al canal alfa de la misma forma, para nosotros se ven los dos transparentes pero en verdad por detrás son dos colores distintos. Guardamos nuestro sprite.
Abrimos con xnview y vemos que no se ve ni el fondo negro ni el borde blanco del sprite.
Abrimos con bennu en densidad 32 bits y apreciamos el mismo resultado, pero si pasamos un objeto cerca veremos que colisiona antes de tiempo, justo al llegar al borde blanco que no se ve, esto es debido a lo comentado anteriormente que transparente pero no es el color 0 absoluto sino el RGBA(255,255,255,0). En cambio con el negro que hicimos transparente no pasa porque coincide con el color 0 absoluto.
He probado todos los ejemplos antes de poner estas líneas por si alguien llega a pensar que es una fumada mía, si alguien está en desacuerdo que los realice con las mismas herramientas antes de opinar.
Como conclusión mía para bennu y viendo que se usa png como formato base:
1.- intentaría implementar la funcionalidad de 8 bits para que se ajuste al estándar png. Simplemente es saber donde guarda png la información del color transparente e interpretarla.
2.- eliminaría la densidad de 16 bits ya que es un arreglo impreciso para usar RGB (por eso de que un canal tenga un bit más que los otros en precisión) y no se ajusta al estándar png. Existe el formato 24 bits sin este fallo, en el que usando el negro podemos simular transparencia binaria.
3.- fomentar el uso del formato 32 bits ya que es el que soporta semitransparencias y estas dan mejor apariencia a nuestros juegos siempre que sepamos diseñar bien nuestros sprites y tengamos en cuenta que hay que añadir como transparente absoluto para no colisionar el negro.
Por cierto, Splinter seguro que insistes en que rgba(0,0,0,0) es distinto a 0 (ya me lo hiciste otras veces :D), mira por dentro el algoritmo que usa para generar el entero y tendrá que salir que al final es igual a 0 sino no funcionarían mis ejemplos.
jajaja...
Pix, es necesario hacer una prueba bien controlada...
8 bits, png, fpg, fpg sin compresion, map, map sin compresion
16 bits lo mismo
32 bits lo mismo
probar solo seteando el modo de video (en cada uno) y hacer un simple while(!key(...) or joy...), etc, sin dibujar nada... ver si se cuelga... o no...
y todas pruebas controladas, y mostrando los resultados... asi, aunque no tenga la wii, puedo intentar deducir donde esta el problema....
A ver... ya se hablo mucho de esto... vamos de nuevo...
Bennu solo soporta formato MAP... las lecturas png, etc, son solo importaciones donde el resultado final es un map... y bennu necesita que el valor 0 sea transparente (por muchos motivos que ya explique muchas veces, una cosa es un visor que muestra 1 imagen 1 vez y no necesita performance y otra es algo que tiene que dibujar el grafico continuamente y a la mayor velocidad posible, no se puede comparar)...
usar otro color significaria conversion de los pixels con ese color a 0, y que hacer entonces con el 0? como sea, estariamos generando un mapa totalmente diferente al creado, y si en la logica de nuestro juego usamos ese color "transparente" para algo, ya no estara con el mismo valor...
Resumiendo... no importa lo que diga el formato png, bennu necesita que el color transparente sea el "0".
Vamos de nuevo, por enesima vez, rgb(0,0,0) != 0 = 1
rgba es otra cosa
32 bits es otro mundo... 8 y 16 se heredan de fenix... y esta bien como estan implementados...
int gr_rgb( int r, int g, int b )
{
int color ;
color = (( r >> sys_pixel_format->Rloss ) << sys_pixel_format->Rshift ) |
(( g >> sys_pixel_format->Gloss ) << sys_pixel_format->Gshift ) |
(( b >> sys_pixel_format->Bloss ) << sys_pixel_format->Bshift ) ;
if ( sys_pixel_format->depth == 32 ) return 0xff000000 | color ;
if ( !color ) return 1 ;
return color ;
}
/* --------------------------------------------------------------------------- */
int gr_rgba( int r, int g, int b, int a )
{
int color = 0;
if ( sys_pixel_format->depth == 32 )
{
color = (( r >> sys_pixel_format->Rloss ) << sys_pixel_format->Rshift ) |
(( g >> sys_pixel_format->Gloss ) << sys_pixel_format->Gshift ) |
(( b >> sys_pixel_format->Bloss ) << sys_pixel_format->Bshift ) |
(( a >> sys_pixel_format->Aloss ) << sys_pixel_format->Ashift ) ;
}
else if ( sys_pixel_format->depth == 16 )
{
color = (( r >> sys_pixel_format->Rloss ) << sys_pixel_format->Rshift ) |
(( g >> sys_pixel_format->Gloss ) << sys_pixel_format->Gshift ) |
(( b >> sys_pixel_format->Bloss ) << sys_pixel_format->Bshift ) ;
}
if ( !color ) return 1 ;
return color ;
}
Bueno, veo que hay un error en rgba para 32bits... ahora lo soluciono...
:D, yo me referia a la hora de cargar el png nada mas, no a cambiar el sistema de almacenamiento de bennu.
No veo que sea dificil mirar el dato del png para el color transparente y ponerlo el primero de la paleta cambiándolo en todas sus referencias. Solo al leer el png, luego ya guardado en map o lo que sea pues que siga igual. En fin que no lo vea dificil no quiere decir que no lo sea :D.
De todas formas es una sugerencia no tienes porqué hacerla pero ayudaría a no despistar por lo de que en otros visores se vea transparente y luego en bennu no. (quieras o no eso mosquea y da quebraderos de cabeza hasta que se descubren las entrañas y llegan a la conclusión de que hay que ponerlo al principio de la paleta del png :D)
con esas funciones no puedes meter un color transparente nunca
RGB(0,0,0) devuelve 1 y RGBA(0,0,0,0) devuelve también 1.
No creo que sean las que use load_png para cargar la imagen porque sino no podrías leer la información de transparencia 0 para el negro de las imagenes png de 32 bits.
Y actualmente va bien, mi ejemplo funciona, es deci,r el pixel con información 0,0,0,0 no lo dibuja.
En 16 bits algo parecido, porque a mi el negro rgb 0,0,0 de mi png de 24 bits me lo pone transparente, voy a revisar mis ejemplos. pero para mi que estas funciones no son las que se usan en la carga del png al map.
no es dificil, sino es erratico, porque si, cambiamos todos los "color transparente" a 0, bien, pero que pasa con los 0 que ya existian? esos deben ser negros, no transparentes... entonces requiere ir swapeando el "transparente definido por el usuario" y el "0 absoluto" pixel a pixel... y esto ya estas cambiando los datos del grafico, y si esos datos se usan en la logica estamos haciendo cagadas... ni que hablar con la ruptura de compatibilidad con todo lo existente, hay rupturas que no son graves, pero esta creo que si lo es...
esas funciones no tienen nada que ver con el color transparente, digo que retornan 1.
rgba 0,0,0,0 en los programas graficos (y en bennu 32bits)... si, claro, son pixel = 0... pero no son rgba(0,0,0,0)...
esas funciones no se usan para la carga, claro que no... pero veo que es muy complicado explicarlo, y muy complicado entender los porque cuando no se conoce la filosofia de la transparencia div/fenix/bennu.
Por otro lado, es un requisito del motor, color 0 = transparente...
Killo, no nos entendemos, no quise decir eso, en fin, aceptamos barco en lo referente a 8 bits.
En cuanto a 16 o más, da igual como lo haga por dentro, la cosa es que va con lo que hago así que debemos tener razón los dos aunque lo veamos desde puntos de vista distintos.
En resumen, a nivel de vista de NO programador interno de bennu y de SÍ programador de juegos bennu:
Si usas modo 8 bits en bennu, las imágenes tienes que hacerlas en png indexado sabiendo que el primer color de la paleta será el transparente para bennu independientemente del color que elijas en el editor gráfico. Y todas las imágenes deben usar esa misma paleta, si las imágenes tienen paletas distintas, la primera imagen cargada será la que inserte su paleta para el resto, haciendo que las que usan paleta diferente a ella se vean usando ésta y a efectos visuales cambien sus colores.
Si usas modo 16 bits en bennu, las imágenes tienes que hacerlas en png 24 bits de color sabiendo que el negro 0,0,0 será el transparente para bennu.
Si usas modo 32 bits en bennu, las imágenes tienes que hacerlas en png 32 bits de color sabiendo que bennu usará el canal alfa para mostrar los semitransparentes y que el color negro transparente será el único que no causará colisión con otros colores.
No hay mas vuelta de hoja, mis ejemplos lo demuestran, no quiero pasarlos para no llevaros por mi camino y que cada uno lo descubra a su manera pero si hace falta los subo.
exacto, asi es...
una cosa, en 16 bits, no solo el 0,0,0, sino aquellos pixels cuyo componente alpha es menor al 50%, es transparente o sea, 0...
Esa opción no la mencioné para no liar pero está, aunque no tengo la prueba, la tengo que hacer pero básicamente es:
En caso de usar 16 bits de profuncidad en bennu y usar imágenes png de 32 bits. Bennu pone a transparente todos los píxeles en que su componente alfa esté por debajo de 128.
Os recuerdo que en imágenes png de 24 bits no existe canal alfa. Solo son 8R 8G 8B =24 en contraoposición al 32 bits que son 8R 8G 8B 8A = 32.
Quedan mas cruces de densidades en mis pruebas yo me basé en intentar usar la misma densidad para hacer la imagen que para cargar en bennu con la peculiaridad de que 16 bits en color RBG no existe en el png. (hay 16 bits divididos en un canal de 8 para escala de grises y un canal de 8 para alfa. También una escala de grises sin componente alfa de alta densidad de 16 bits. Pero nada para color, es decir, no existe en png un canal indexado de 8 bits de color mas un canal alfa de 8 bits)
Referencia:
http://es.wikipedia.org/w/index.php?title=Portable_Network_Graphics&action=submit
Intentaré hacer ejemplos para los cruces de densidades que faltan y sacar a la luz como actúa bennu en la práctica con estos.
bennu en 8 - pngs en 8 <-- ya visto. Primer color de paleta como transparente.
- pngs en 24 <-- Supongo que no se podrá, falta probar.
- pngs en 32 <-- Supongo que no se podrá, falta probar.
bennu en 16 - pngs en 8 <-- supongo que usará el color negro como transparente, falta probar.
- pngs en 24 <-- ya visto. Color negro como transparente.
- pngs en 32 <-- ya visto. Alfas menor a 128 como transparentes, falta probar.
bennu en 32 - pngs en 8 <-- supongo que usará el color negro como transparente, falta probar.
- pngs en 24 <-- supongo que usará el color negro como transparente, falta probar.
- pngs en 32 <-- ya visto. Usa componente alfa con semitransparentes.
PD: Splinter, voy a quitar estas cuestiones de este post, que wii ha sido el desencadenante por solo soportar por ahora 8 bits, pero es un poco offtopic, ¿no crees?
En base a esto, sugiero que se arme un post en el area de documentacion... sobre transparencias en Bennu... y que quede como tutorial, luego borramos todo esto...
Gracias DCelso por la molestia que te tomaste en abrir el thread y mover los hilos...
Saludos.
Ok, te refieres en la wiki o aqui, porque esto ya está en documentación.
Por otro lado no hablé de 24 bits en bennu, este modo supongo que es clavadito al de 16 pero usando 8 bits para cada canal RGB en vezde 565. Me refiero a que se comportaría igual que en las pruebas a 16 bits mencionadas.
aqui mismo, pero no como color, sino como transparencias...
Splinter, ya tengo la primera versión rápida de lo que podría ser el documento este.
Cuando puedas éche un vistazo a ver qué no está del todo correcto, qué se puede mejorar, qué se puede añadir, etc, todo lo que se te ocurra es bienvenido.
Notar que está en bruto, sin imágenes, ni índices ni referencias ni ejemplos, todo eso haría falta para la versión final.
1) Fpg, como maximo 999 imagenes de 1 a 999.
2) Se pueden importar de forma nativa png y pcx.
3) Bennu no soporta modo de video de 24 bits.
4) Las funciones RGB y RGBA internas en modo 16 bits no dan 0, sino 1. En el documento se entiende como que dan 0 y que se usan para setear un color transparente.
5) En 32 bits, hay que destacar la diferencia entre transparencia y color transparente 0.
color 0 absoluto es transparente/ausente/agujero/"no data", lo cual significa que estos pixels no solo no se veran, sino que tambien no colisionaran.
transparencia/alpha es una transparencia, que incluso si dicho alpha es 0, solo dira que no se ve, pero que si colisionara.
Veo que el punto 5) ya lo explicaste.
Yo me referia a un documento mas generico sobre las transparencias, que describa a las mismas a nivel MAP, y luego explicar las caracteristicas correspondientes a png y a pcx.
Que inutil soy, eso me pasa por hacer las cosas rápidas. :( :)
no, esta bien... es util, pero en mi opinion habria que acomodarlo y orientarlo como te digo...
pero no, nada de inutil, la informacion es muy util...
He cambiado lo que me comentas. A ver que tal ahora.
Lo de que parecía que rgb (0 0 0) era lo mismo que 0 no lo encontré, he explicado un poco más en donde está la parte que habla del color negro puro.
Ahora bien, enfocarlo hacia un map ¿en que consistiría?, yo es que los maps para mí siempre han sido invisibles, he pasado directamente los png al fpg. o trabajado directamente con pngs.
Sé que son una especie de png que guardan además unas coordenadas, un número y un texto. Cosa que vi un poco rara porque más bien deberían de ser datos del fpg, ya que es éste quien los necesita.
En cuanto al pcx, ¿alguien usa ese formato? :D.
Acepto críticas de mejoras :)
Hola SplinterGU, he realizado ya todas las pruebas que hice en el documento y cual ha sido mi sorpresa al descubrir que están casi todas mal en el documento.
A ver, te pogo adjuntos todos los prgs de las pruebas, pero te predigo lo siguiente:
- Los pcx de 24 bits no están implementados en bennu, casca de lo lindo en los tres modos de profundidad de bennu 8,16 y 32.
- Bennu, cuando carga las imágenes png de 24 bits no hace ninguna conversión de transparencia en ninguno de los modos bennu 16bits y 32 bits, eso que puse de que el negro puro es convertido a color transparente es mentira.
- Bennu cuando carga las imágenes png y pcx de 8 bits siempre usa el primer color de la paleta como transparente independientemente del modo de profundidad seleccionado en benu, es decir, lo que puse de que en modo 16 y 32 bits usaba el negro como transparente, también es mentira.
Si no recuedo mal, el segundo punto en fenix si que era así, usaba el negro como transparente, voy a probarlo con los dos fenix que se suelen usar a ver si es que estoy equivocado.
Bien.
1) Si, pcx 24 no funciona... y creo que alguna otra cuestion hay con los pcx.
2) Transparencias:
en 8 bits siempre es el primer valor 0 (index 0 de la paleta), sea pcx, png, map, etc
en 16 bits tambien es el valor 0, pero solo cuando ya esta cargado en memoria, los pngs convierte a 0 (transparente) cuando el alpha es menor al 50%, y obviamente el color 0 tambien es transparente.
en 32 bits es 0, y la transparencia alpha es por separado.
fenix se comporta igual en estos puntos.
creo que esto ya lo habia explicado, pero puede que no haya sido claro.
Ok, gracias splinter, yo me acuerdo de trabajar con negro para transparente en modo 16 bits, puede que me haya confundido pero no recuerdo trabajar con pngs de 32 bits en modo 16 bits Fenix, seguro que estoy mezclando lenguajes, he usado tantoos ..., me disculpo por las veces que dige algo que no era cierto y me encabezoné porque sí lo era. (Tengo un gazpacho en la cabeza..)
Actualizo documentación con los resultados.
De nada, y no hace falta disculparse... con decir que ahora se entiende como funciona es suficiente.
Subo nuevo fichero, he eliminado los anteriores para que nade se los descargue ya que estaban totalmente mal y pueden llevar a error, ruego a todos los que se los descargaron borren definitivamente para no confundir a nadie y descarguen esta versión corregida y que parece estar correcta.
PD: Splinter, la he gerido y sin querer borré el "attach" de los ejemplos, no he sabido recuperarlo, si puedes hacer el favor de revertir la modificación del post para recuperar la descarga vendría de perlas.
no se puede revertir. no importa.
Ya encontré donde se habla del negro como transparente para fenix, en el manual de osk.
Concretamente en el ejemplo del laberinto. Creo que es FPGEdit quien hace esta conversión.
Siento ser tan cabezón pero es que sabía que no me lo inventé no eran imaginaciones mías :D.
He estado probando en el fenix92a a abrir en modo 16 un png en modo 24 y no convierte el negro a transparente.
También he probado con las herramientas map.exe y fpg.exe a crear un map de 16 bits, posteriormente a un fpg de 16 bits y luego abrirlo desde fenix y tampoco convierte el negro a transparente.
Solo me queda la prueba de FPGEdit, ya mañana la intento. Si esta tampoco va, entonces encontré un fallo en el tutorial de osk :D.
He visto que si pongo a modo 32 fenix casca de lo lindo, cosa que era de esperar, pero curiosamente puse modo 24 y funcionó, también probé a poner accidentalmente 25 y también ruló. Internamente debe hacer algun rango para asignar modo 16 bits.¿Te suena Splinter?
Otra pregunta, he visto que en fenix solo existían maps de 8 y 16 bits, se (o eso creo) que en bennu hay maps de 32 bits, pero ¿También hay maps de 24bits?.
Misma pregunta para fpg.
Gracias por las aclaraciones Splinter.
Guay. Me lo apunto!
24 bits no hay... deberia revisar el codigo a ver que mascara actua y hace que esto setee algun modo valido.
Pero 24 no hay, nada.
hola
se que ya casi no es el tema de esto, pero he preparado un código para brincarnos la restriccion de que el color 0 sea el transparente... aunque se necesita primero cargar una paleta válida (con el color transparente como posición 0).
[code language="bennu"] import "mod_text";
import "mod_grproc";
import "mod_video";
import "mod_map";
import "mod_screen";
import "mod_rand";
import "mod_say";
import "mod_mouse";
import "mod_dir";
import "mod_math";
import "mod_proc";
import "mod_string"
import "mod_key";
import "mod_draw";
import "mod_time";
import "mod_sound";
import "mod_wm";
import "mod_regex";
import "mod_file";
import "mod_sys";
import "mod_blendop";
type mic;
byte rojo;
byte azul;
byte verde;
end
global
pal1;
fondo;
begin
set_mode(800,600,32);
fondo=new_map(800,600,32);
map_clear(0,fondo,rgb(200,150,120));
put_screen(0,fondo);
pal1=load_pal("default.pal");
graph=load_png("grafico.png");
convert_8_8(0,graph,0,graph,pal1);
x=400; y=300;
loop
if (key(_esc)) exit(); end
frame;
end
end
function convert_8_8(file1,graph1,file2,graph2,pal2);
private
temp_graph;
anc,alt;
mic colors[256];
paleta[256];
pal1;
begin
anc=graphic_info (file1, graph1, g_wide );
alt=graphic_info (file1, graph1, G_HEIGHT );
temp_graph=new_map(anc,alt,8);
pal1=PAL_MAP_GETID(file1, graph1);
pal_map_assign(0,temp_graph,pal2);
map_put(0,temp_graph,graph1,anc/2,alt/2);
PAL_GET(pal1,0, 256, &colors);
say(colors[z].rojo +","+colors[z].azul+","+colors[z].verde);
say(find_color(colors[z].rojo,colors[z].azul,colors[z].verde));
from z=0 to 255;
paleta[z]=find_color(colors[z].rojo,colors[z].azul,colors[z].verde);
end
convert_palette(0,temp_graph,&paleta);
fpg_add(file2,graph2,file1,temp_graph);
unload_map(0,temp_graph);
end[/code]
jejeje, en 8 bits, la posicion 0 es el color 0.
je je je
si, tienes razón,
pero lo anteriro es buena idea, no? si tienen problemas con sus gráficos, que los carguen como en el ejemplo anterior y listo, tomará la coloración más parecida a la original... :)
oye, find_color sobre qué paleta trabaja? sobre la primera que se carga o cómo está ??? es que algunas veces parece que lo entiendo y otras nomás no... je je je
Gracias, PRG por el ejemplo, yo por mi parte no lo veo práctico, pero oye ahí está como ejemplo :D.
Yo lo que he sacado de conclusión es que hay que evitar trabajar con imágenes PNG de 24 bits de color.
Y también evitar de trabajar con profundidad de 8 bits en BennuGD.
Lo suyo, claro hablo siempre en programación para pc, es trabajar siempre con bennu en 16 o 32 bits.
Usar imágenes PNG de 8 bits sin transparencias y sabiendo que Bennu usará el primer color de la paleta como el colr transparente. Este último formato creo que es el ideal para los juegos típicos 2d ya que un sprite no va a necesitar por lo general más de 256 colores distintos, ocupa poco y si usamos muchos sprites se nota, y permite el cambio de color de los sprites rápidamente con sólo cambiar la paleta por otra.
O bien usar imágenes PNG de 32 bits si necesitas mucha calidad o semitransparencias.
png de 24 bits no hay problemas, porque se convierten a la resolucion adecuada... lo que no hay de 24 bits son mapas en memoria ni modo de video.
8 bits tiene las mismas caracteristicas que tuvo siempre (fenix/bennu), salvo que ahora en modos 16 y 32, los mapas en 8 bits tienen una paleta propia (o pueden usar la del sistema)
ya, pero los png de 24 bits no tienen transparencias, así que solo nos sirven para fondos. :D.
efectiviwonder, Juan Piruleta, el fpgedit es el que hace la conversión. Prueba:
Abres fpgedit.
Creas un nuevo fpg 16 bits.
Añades un png sin transparencias de 24 bits.
Guardas fpg.
Cargas en fenix el fpg
Creas dos procesos con la misma imagen del fpg.
Al segundo proceso pones que se pueda mover con las flechas.
Mueves éste por el otro y ves que el negro que había en la imagen no se dibuja.
Curioso, siempre creí que era una restricción de fenix y resulta que era de fpgedit. Osk, con esto podemos decir que tu manual no tenía una errata, sino más bien información incompleta :o. Sería cuestión de aclararlo nada más. :).
POST DATA: he descubiero que la herramienta map también puede hacer esa misma conversión de negro a transparente si pones -z=0. Bueno, me doy cuenta que no tengo PI de programación en div/fenix/bennu :( :(
A mi me parece normal que en un png de 24 bits se setee la transparencia al color 0,0,0, ya que los png de 24 no tienen canal alfa.
Splinter dijo:
Quoteen 16 bits tambien es el valor 0, pero solo cuando ya esta cargado en memoria, los pngs convierte a 0 (transparente) cuando el alpha es menor al 50%, y obviamente el color 0 tambien es transparente.
Según esto yo entiendo que no es que el FPGEdit "añada" la transparencia. Cuando añades un png de 24bits a un FPG de 16bits y trabajas en este modo en BennuGD, el color (0,0,0) se considera transparente. Por eso, la parte negra se ve transparente. En realidad FPGEdit no está convirtiendo nada, simplemente está manteniendo el color que tiene la imagen en el PNG. Para que no saliese transparente habría que convertir los píxeles que están a 0,0,0 a un color cercano (1,1,1)
Mal, ahí splinter se refería a pngs de 32 bits, que son los que llevan canal alpha.
A las pruebas me remito. Crea un proyecto bennu con "set_mode(640,480,16)" crea dos procesos uno encima del otro cargando una imagen de 24bits, es decir graph=load_png("img24bits.png") y verás que no convierte el negro a transparente.
Por las pruebas anteriores se deduce que la conversión se produce al pasar el png a map usando map.exe con la opción "-z=0". Y que FPGEdit debe de hacer algo al estilo.
Pon un fondo de pantalla (putscreen) para hacer una prueba mas acertada, porque las prioridades de las z pueden hacer que un objeto se vea transparente y otro no.
O no entendi la explicacion.
Con respecto al canal alpha, obviamente hablo de pngs que tienen dicho canal.
Pero si es así (y eso no lo pongo en duda ya que has hecho la prueba) es porque la rutina "load_png" de bennu estará convirtiendo el color 0,0,0 de la imagen PNG a un color cercano. Hasta donde yo creo tener entendido, internamente todas las imágenes cargadas se convierten a un "map" tal y como es entendido por Bennu, y un MAP de 16bpp entenderá el color 0,0,0 como transparente.
El tema está, que FPGEdit no hace esa conversión de color 0,0,0 en imagenes de 24 bits a un color cercano y por eso, una vez dentro del FPG, el gráfico (que ahora tiene estructura de un MAP) tendrá píxeles a 0,0,0, que se interpretarán como transparente.
Cuando usas el map-exe con la opción -z=0, lo que yo entiendo que se hace es precisamente que no se convierta. Cuando no usas -z=0 entonces es cuando realmente se están convirtiendo los píxeles 0,0,0 a un color cercano.
En fin, este asunto me interesa porque estoy trabajando en un editor FPG (SmartFpgEditor) y me gustaría saber como debo tratar los PNGs de 24 bits a la hora de agregarlos al FPG (es decir, si debo convertir los píxeles 0,0,0 a un color cercano para eliminar transparencia o si no debo hacerlo).
Yo lo que no acabo de entender son los problemas asociados a hacer un intercambio de colores, en la carga de PNGs de 8 bits, entre el definido como color transparente y el color cero: todas las operaciones relativas a los colores de cada pixel los hace el propio programador, que ya conoce (o debería conocer) esta característica de las paletas.
Aunque claro, deberíamos ser nosotros los que al crear el PNG tuviéramos esto en cuenta a la hora de crearlos ;D (siempre que no estemos "tomando prestados" gráficos :D)
Se complican demasiado.
Tienen que pensar en los png, pcx, o cualquier otro formato grafico, solo como un container... como un transporte de lo que realmente es un MAP.
Eso es lo que termina aplicando.
Sí, yo lo único que quería hacer ver es que FPG Edit no está convirtiendo los pixeles negros de una imagen de 24bits en transparente, simplemente que el 0,0,0, siempre representará transparente en 16bits y que si un MAP no muestra unos pixeles transparentes es porque no están a 0,0,0.
Quote from: splinter_work on June 04, 2009, 01:55:41 PM
Se complican demasiado.
Tienen que pensar en los png, pcx, o cualquier otro formato grafico, solo como un container... como un transporte de lo que realmente es un MAP.
Eso es lo que termina aplicando.
A eso me refiero: cuando se crea el map en memoria, usar como color 0 el color definido como transparente en el PNG, y como color X el color 0 del PNG. Luego ya se preocupará el programador de hacer las cosas bien con las durezas o lo que sea (no tomar el color X como "sin dureza", sino el 0 por el que ha sido sustituido).
De todas formas, PNG lo cargaba la image.dll de Fenix ¿no? entonces una pasadita por mi cambia_color y varios PNG en un BMP/MAP con los colores bien puestos del tirón (en FPG creo que no arreglé el tema de paletas y siempre detecta todas las paletas distintas ^^U)
Buenas, pongo este reply, para confirmar que fpg edit no hace ningún tipo de conversión de color a transparente con imágenes de 16/24 bits, simplemente hace una copia perfercta a nivel de pixel en el fpg destino.
Asi pues, cuando lee el color RGB(0,0,0) de una imagen 16/24 bits, mete el byte = 0, que es el color que usa bennu como transparente cuando lee el fpg guardado.
NOTA: una cosa que me ha sorprendido mucho, viendo el SVN de bennu, es que bennu da soporte para maps y fpgs de 1 bpp. Asombroso, tengo que probarlo :D. Con dos colores posibles solo da para que uno sea transparente y el otro no :D.
Si, y con drawing color se define el color no transparente, eso lleva con nosotros desde Fenix, pero nunca se ha usado.
Yo estuve mirándolo para las especificaciones de los FNT y puedo decir sin miedo que FNTEdit sólo usa un 30% de las capacidades de ese formato, por eso quise hacer el mío (en realidad, es porque no teníamos ningun programa para crear fuentes de 1 o 16 bits ;D FNTEdit trabajaba sólo con fuentes de DIV).
PD: por lo mismo que tu comentas, siempre es mejor trabajar con PNGs con canal alpha, que entonces sí que lo respeta, y parece que convierte el color (0,0,0) en un negro no transparente.
Quote
PD: por lo mismo que tu comentas, siempre es mejor trabajar con PNGs con canal alpha, que entonces sí que lo respeta, y parece que convierte el color (0,0,0) en un negro no transparente.
Bueno, el tema es que los editores FPGs que han salido hasta la fecha no realizan esa conversión de color, pero en realidad es muy fácil de hacer. Yo se lo voy a implementar a mi editor FPG como opción a la hora de añadir gráficos a los FPGs de 16 bits.
Lo que me gustaría saber es: ¿cual es el "negro cercano" que se usa en 16bpp? ¿es (1,1,1), (0,1,0) o cuál?
Para Fenix/Bennu es el 1 (recuerda que para ellos, los colores valen 0-255 en 8 bits, y 0-65565 en 16 bits, otra cosa es la conversión a RGB).
Aproximadamente un (0,0,3) con el paintbrush me lo ha cogido el FPGEdit como "no transparente", pero por ahi anda la cosa (azul muy oscuro, porque el azul es el más parecido de los tres al negro, pero vamos, cualquier color con componentes mínimas, si no tienes ambos colores uno al lado del otro, no los distingues).
Hola a todos,
aqui estoy de nuevo con un pequeño gran problema, cagoen ..,
he dado soporte a fpgedit para imágenes de un bits, como dije, vi que bennu lo soportaba en el código.
Pues nada, que fpgedit los crea y los abre bien, pero cuando los abro en bennu, éste se queda grogui total.
la única restricción que he leído que tienen los bitmaps de un bit por pixel es que el ancho por el alto debe ser múltiplo de 8. (Por eso de que lo mínimo que se puede escribir en un archivo es un byte).
Bueno el truco que hacen los formatos de imagen para insertar cualquier ancho por alto es añadir ceros al final hasta llegar al siguiente múltiplo de 8, es decir una imagen 3x4, osea 12 pixeles o 12 bits, se ponen los 12 bits correspondeintes y se añaden 4 ceros más obteneindo asi 16 bits, para poder insertar dos bytes en el archivo. Luego al leer simplemente se desprecian esos ceros ya que lees alto * ancho que es 12.
Esto es lo que he implementado en fpgedit2009 y no va en bennugd, me gustaría que me ayudaseis los doctos, especialmente, splinter que se conoce a fondo el core, y me explicara porqué se queda colgado bennu con este fpg de un bit que he hecho con fpgedit.
PD: ya se que este formato no sirve para mucho, oye pero didáctico es un rato :D. Así utilidad directa le veo programar handhelds de las antiguas (http://images.google.es/imgres?imgurl=http://youretime.files.wordpress.com/2007/08/donkey.jpg&imgrefurl=http://youretime.wordpress.com/2007/08/08/play-old-handheld-games-online/&usg=__2AT95d6nkzhr9254BBPNa2pqluA=&h=401&w=666&sz=44&hl=es&start=4&um=1&tbnid=nNNGcrZvT0kihM:&tbnh=83&tbnw=138&prev=/images%3Fq%3Dhandheld%2Bdonkey%26hl%3Des%26sa%3DG%26um%3D1) esas LCDs que solo tenían un color de pixel y que detrás habia dibujada una imagen de fondo a capón :D.
Quote
Para Fenix/Bennu es el 1
No se por qué no lo había pensado... jaja que tonto soy. Gracias
Según me explicó Splinter en otro hilo:
http://forum.bennugd.org/index.php?topic=464.0
Los bytes sólo sirven para una única fila: si tienes 4 filas debes usar 4 bytes, aunque tengas sólo 3 columnas y puedas rellenar de una a otra.
Sin embargo, he obtenido unas letras muy curiosas, de una linea de ancho, que parecen un morse vertical o algo muy raro (y muy chulo como lenguaje extraterrestre ;D).
No he tenido tiempo de seguir experimentando, pero mucho me temo que en realidad se usa un byte por pixel, con valores 1 o 0.
por eso te comentaba en el otro hilo que quería ver cómo habías hecho los mapas de 1 bit.
creo que 0,0,1... a fin de cuentas da lo mismo, cualquiera que pongas...
esto es en 16 bits... en 32 no hay estas chupuzadas (o creo...:P).
EDIT: si, (0,0,1) = 1 (yo tambien soy un tonto)
No se como lo estas haciendo, pero si el ancho es de 12 pixels, esto serian 16 bits = 2 bytes. Supongo que hasta ahi esta todo igual.
Y el alto no deber ser dividido por 8, logicamente.
Luego le echare un vistazo a tu codigo y hare pruebas en bennu, pero ya del vamos los mapas de 1 bits funcionan en bennu, quizas algo en los fpg, mapas de 1 bits que se usen en bennu, tenes de ejemplo el font del sistema.