Sistema De Mapas De Durezas Mediante Gdi De Window

[ethernet]

    Sistema de mapas de durezas mediante GDI de Windows

Aqui os dejo este modulo BAS para Visual Basic 6 que pueder cargar imagenes en formato BMP y DIB nativamente por el API de Windows y soportar tambien los formatos del objeto Picture del VB pudiendo cargar por ejemplo GIF y JPEG en memoria. Este modulo esta diseñado en principio para usarse como almacenamiento de mapas de durezas para un juego y leer los pixeles de dichos mapas en memoria en proyectos para Windows, todo por codigo, sin utilizar controles visuales como el PictureBox o similares. Puede ser util a la hora de desarrollar un juego de plataformas o de cualquier tipo que necesite definir zonas calientes de un escenario: suelo, paredes, techo, o liquidos como agua o lava por ejemplo.

El modulo, una vez añadido a un proyecto, tiene 3 funciones publicas: Load_Bitmap(), Unload_Bitmap() y GetPixel():

- Load_BitMap() - Carga una imagen en memoria y devuelve su identificador para luego poder acceder a ella.

- Unload_BitMap() - Descarga de memoria una imagen almacenada liberando el espacio ocupado por esta.

- GetPixel() - Lee el valor RGB del pixel situado en las coordenadas X e Y pasadas como parametros de la imagen localizada en memoria por su identificador.

Una sencilla muestra del uso de cada funcion:

Código [Seleccionar] Expand


Dim i As Long, Color As Long

i = Load_BitMap("dibujo.bmp") '// Carga la imagen en memoria y devuelve su identificador.

Color = GetPixel(i, 10, 5) '// Le el pixel x10 y5 de la imagen i.

Call Unload_BitMap(i) '// Descarga la imagen de la memoria.



El codigo en principio tiene que la ventaja de que se puede portar facilmente a otros lenguajes como C++ dada su sencillez ya que se apoya en funciones existentes en el API de Windows, tan solo habria que cambiar una llamada a una funcion intrinseca de Visual Basic, LoadPicture(), y el uso de un objeto propio de Visual Basic, el objeto Picture (no confundir con el control PictureBox) por la o las funciones pertinentes para cargar imagenes en memoria en formato BMP y las estructuras relacionadas que almacenen esos datos.

Es un codigo muy sencillo pero que pienso que puede ser util.
Podeis Descargar el código de aquí -> http://dxlib32.se32.com/private/regmap.zip


Salu2...

Autor: [EX3] - Josè Miguel Sánchez Fernández
[/list]

Si quieres enviar un código de la semana solo tienes que mandarlo a qualopec@gmail.com o por PM a ethernet.

[zupervaca]

 siento decirte que el GetPixel del GDI de windows es la funcion mas lenta que puede existir, que conste que no es por pinchar ni nada, es la realidad

[Lord Trancos 2]

 coincido con zupervaca.

[ajmendoza]

 Pero es una aportación a quien  le pueda servir, y eso ya vale mucho.

Saludos.

[_Grey]

 Yo entiendo que: Load_Bitmap(), Unload_Bitmap() y GetPixel() ; son funciones creadas por el, no necesariamente las del API de win, todo y que seguro que tiene algunas detras,m pero ya es otra cosa.

[zupervaca]

 yo es que me he bajado el codigo y lo he mirado antes para no meter la pata  :P  

[ethernet]

 En mi opinión el punto fuerte de este COTW es la simplicidad que ofrece al programador. Estoy seguro que un montón de gente que empieza se ha preguntado miles de veces por qué no hay una función que me permita cargar una imagen y leer sus pixels sin tener que pelearte con el API de windows. En mi opinión pesa mucho más la simplicidad que la velocidad, quedando un resultado positivo.

Por mi parte yo tengo una clase que carga texturas y permite hacer lo mismo que especifica [EX3], además de aplicar algún filtro y hacer alguna operación más con ella (suma, resta, multiplicación...) etc. Ya la pondré como COTW.

[[EX3]]

 

Yo entiendo que: Load_Bitmap(), Unload_Bitmap() y GetPixel() ; son funciones creadas por el, no necesariamente las del API de win, todo y que seguro que tiene algunas detras,m pero ya es otra cosa.

Se referia al GetPixel() del API de Windows que utiliza mi funcion GetPixel(), que para no crear conflictos de nombres en el codigo con mi funcion la declaracion del API esta renombrada con un alias a GDIGetPixel() en el codigo.

siento decirte que el GetPixel del GDI de windows es la funcion mas lenta que puede existir, que conste que no es por pinchar ni nada, es la realidad

Estoy deacuerdo de que no es la funcion mas rapida que existe para leer pixeles, pero al menos es mil veces mas rapida que la que implemente en mi libreria, que entre lockear y deslockear las texturas o surfaces con D3D bajaba el rendimiento agresivamente hasta los 3fps leyendo 4 pixeles mientras que con el metodo a traves del GDI ni se inmuta casi el rendimiento leyendo 16 pixeles (como hecho de menos en D3D el veloz GetPixel() que trae DirectDraw)

El codigo esta diseñado para leer unos pocos pixeles en cada vuelta del bucle del juego sin que se vea severamente afectado el rendimiento del mismo ya que lo idee con la intencion de utilizarlo para leer mapas de durezas, cosa que preciso para mi proyecto. Me acorde de subir este codigo al cotw al responder una duda reciente sobre mapas de durezas que plantearon (link al post "Videojuego De Plataformas") y pense que podria ser util, como dice ethernet, para los que se inician en esto y buscan realizar algo tan simple como leer un pixel de una imagen.

Salu2...

[zupervaca]

 si quieres ganar velocidad con los surfaces de direct3d o directdraw obligale a que lo lea en memoria, al hacer el bloqueo lo mas seguro que este bajando la textura por el agp o el pci-express siempre, no obstante la forma mas correcta es metiendo el mapa de durezas en la propia ram del ordenador y accediendo a ella como un tozo de memoria mas.

saludos

[[EX3]]

 

si quieres ganar velocidad con los surfaces de direct3d o directdraw obligale a que lo lea en memoria, al hacer el bloqueo lo mas seguro que este bajando la textura por el agp o el pci-express siempre

Te refieres a almacenar las texturas y surfaces en memoria RAM mediante uno de estos dos flags?

Enum CONST_D3DPOOL
    D3DPOOL_DEFAULT        = 0
    D3DPOOL_MANAGED        = 1
    D3DPOOL_SYSTEMMEM      = 2
    D3DPOOL_SCRATCH        = 3
End Enum

Me da que esto no me iba a solucionar mucho, ya que el problema radica en que en D3D, al menos como me han enseñado a mi y como he visto en varios ejemplos, tienes que copiar en un array los datos de la textura que quieres leer o escribir, y para ello hay que lockear, copiar, deslockear, y esto es algo lento y se nota si haces varias entradas a diferentes o la misma superficie.

no obstante la forma mas correcta es metiendo el mapa de durezas en la propia ram del ordenador y accediendo a ella como un tozo de memoria mas.

En teoria el metodo del GDI si no me equivoco lo hace por RAM y supongo que el GetPixel() del GDI no tendra que lockear, ni copiar memoria de alli para aca, ni deslockear para leer la informacion de una imagen, posiblemente sea por ello por lo que sea mas rapido que en D3D. Ahora, si alguien conoce un metodo mucho mas rapido y optimo con D3D estare encantado de poder echarle un ojo :) (asi que ya sabes, ethernet, espero ansioso tu cotw (ole))

Salu2...

[zupervaca]

 veamos el GetPixel del api de win32 tiene que funcionar para muchos formatos de color, desde 1bit a 32bits y lo hace todo la misma funcion ademas de que estas llamando a una dll por cada llamada a GetPixel, si con este no lo ves claro dejo el tema, por que una funcion inline hace maravillas en bucles tochos como puede ser las comprobaciones de mapas de durezas y si ademas el formato siempre es de 8bits mas rapido aun ya que se puede hacer mediante rotaciones

saludos

[[EX3]]

 

veamos el GetPixel del api de win32 tiene que funcionar para muchos formatos de color, desde 1bit a 32bits y lo hace todo la misma funcion ademas de que estas llamando a una dll por cada llamada a GetPixel, si con este no lo ves claro dejo el tema, por que una funcion inline hace maravillas en bucles tochos como puede ser las comprobaciones de mapas de durezas y si ademas el formato siempre es de 8bits mas rapido aun ya que se puede hacer mediante rotaciones

Vale, D3D son varias dlls y sigue realizando mas pasos para leer 4 bytes que lo que hace GetPixel() del GDI y programarme "inline" en VB6 una funcion de lectura de pixeles a pelo para leer surfaces de D3D (MAP_GetPixel() o SURF_GetPixel() de mi libreria) o simplemente en una estructura de datos como usa el GDI para los BMP haria que fuese mucho mas lenta que GetPixel() del GDI (sencillamente por el lenguaje), si con esto no lo ves claro dejo el tema por que veo que no me sigues :P

[EDIT] Lo mas que podria mirar con D3D seria probar hacerme unas funciones que cargaran las superficies y las dejaran lockeadas permanentemente para realizar las lecturas, que esto seria mas rapido ya que solo tendria copiar una sola vez la textura al array, pero pre-supongo que esto haria mucho gasto de memoria, me equivoco? [/EDIT]

Salu2...

[zupervaca]

 haz lo que quieras, cada vez me doy mas cuenta de realmente no hay nivel por estos foros

saludos

editado: rectifico, no es que no haiga nivel, es mas bien que no quieren aprender

[fiero]

 zupervaca tio, creo que sabes mucho, pero a veces te pones muy testarudo :rolleyes: . Simplemente EX3 trabaja en VB, es distinta forma de trabajar que la que tienes tú. Tú zupervaca nunca harías un juego en VB simplemente porque pensarías que hay una forma más rápida, y claro que la hay, C++ ó asm. Pero hay gente que le gusta trabajar a otro nivel, sin tratar con buffers de memoria ni nada de eso, trabajando simplemente con las imagenes y un Getpixel de toda la vida, cosa que veo totalmente factible. Y ahora no me ataques a mi, que mi Getpixel son cuatro lineas de ensamblador  :P .

En cuanto lo que comenta EX3 de velocidades, puedo comentar mi caso. Yo renderizo con mis propias funciones en ensamblador y sólo utilizo DX o GDI para crear las superficies de renderizado. Pues he comprobado que me va más rápido (unos poquillos FPS) utilizando GDI. La razón es que con GDI creo un BITMAP que me hace de backbuffer y no necesito realizar algunas funciones de DX como Lock y UnLock, ya que el bitmap permanece siempre en la misma zona de memoria.

Saludos y buen rollo, [yo si creo que por aquí hay nivel...]

[[EX3]]

 

haz lo que quieras, cada vez me doy mas cuenta de realmente no hay nivel por estos foros

saludos

editado: rectifico, no es que no haiga nivel, es mas bien que no quieren aprender

Siento desilusionarle, "maestro" :P, pero no puedes pretender que todo el mundo haga las cosas como tu piensas que deben ser. Lo bonito de este mundo es que haya variedad y que la gente eliga que le interesa usar, habra quien prefiera complicarse y apurar al maximo logrando un resultado impecable que zoza la perfeccion... y habra quienes prefieren acortar trabajo y lograr lo que buscan en corto plazo sacrificando algo de potencia y eficacia.

Aplaudo tu impetu con intentar alcanzar la perfeccion en tus codigos. Mis codigos no seran lo mas rapidos del mundo pero si me permiten realizar mis ideas en corto espacio de tiempo y logrando unos resultados mas que aceptables, al menos para mi, suficientes para quedarme satisfecho con lo que hago.

Y eso de que no quieren aprender... 6 años me he tirado aprendiendo VB sin tener muchas nociones en metodologia de programacion, aprendiendo y probando multitud de funciones del API de Windows que pudiese aprovechar para mis proyectos y aprendiendo DirectX, su api grafico mas a fondo que el resto de librerias y que aun sigo aprendiendo. El fruto a sido la mierda de libreria que tengo colgada en mi web que no sera la mas eficiente del mundo pero que si permite que cualquiera haga cosas vistosas y con unos resultados decentes sin mucho esfuerzo en una mierda pero sencillo y lento lenguaje como es VB y que mucha gente, al igual que yo, usamos y que de por si mismo no da mucho si que digamos. Siendo esto asi significa que he cumplido con mi objetivo y me siento satisfecho de mi trabajo y de mis horas invertidas en el.

Dicho todo esto espero que entiendas de una vez por todas cual es objetivo de mis codigos, de mis aportaciones, el de hacer facil lo que para muchos es casi imposible, lo que se supone que se busca con el COTW, y no el de lograr la perfeccion. A ver si de ahora en adelante podemos evitar berrinches similares a este y respetar un poco el trabajo de los demas, aunque no tengan un "level" de tu agrado :P

Salu2... ;)

P.D.: Aunque no te lo parezca agradezco y valoro tus consejos como hago con los del resto, siempre son bienvenidos.