Acerca del modo grafico.

[notoi]

Hola a todos, me acabo de registrar en Stratos. Me pico el gusanillo de la programación de nuevo y he empezado a hacer un juego sencillo. Aunque de hecho en el pasado hize una aventura conversacional 'piloto' en ensamblador y con poca info. Se trata de Khurdian. De momento he conseguido cambiar el modo grafico para directx. Puse el modo en 800x600 y 16 bits. Pero al cargar la pantalla no sale como en photoshop o como cuando lo visualizo en acdsee cn un degradado suave. Salen como unas bandas de separacion entre tonalidades. El bitmap de prueba lo grabe como 16 bits, pero nada. Asi que he pensado hacer el juego en 800x600 y 32bits. Pero mi pregunta es, hoy en dia cual es la resolución standard y la profundidad de color?  Yo iba a poner 800x600 y 24 bits, pero mi portatil no lo soporta. Solo 16 o 32. Asi q creo q tirare hacia los 32. Gracias.

[[EX3]]

Wenas.

Actualmente cualquier equipo soporta 32 bits de profundidad de color, que viene a ser como los 24 bits algunas graficas antiguas no aceleradas, calidad de color real. Lo que tu ves en photoshop y en cualquier otro editor grafico se corresponde en principio y salvo que la imagen tenga otra profunidad menor con la profundidad de color de tu escritorio, que lo mas seguro es que sea 32 bits, es dificil encontrar actualmente una maquina usando 16 bits o 24 para el modo grafico de escritorio.

Respecto a las dimensiones, muchos pensamos que 800x600 es lo mas adecuado como resolucion minima, que no tiene por que ser lo estandar, la mayoria de equipos igualmente soportan resoluciones desde el estandar SVGA 1024x768 a resoluciones como la 1280x800 de muchos portatiles por ejemplo. Lo ideal es preparar tu motor grafico para que adapte su renderizado a cualquier resolucion que aplique el usuario final, pero de no ser posible o ser muy laborioso, yo te recomendaria 800x600 como minimo aceptable y dar la opcion de aplicar los 16 o 32 bits.

Salu2...

[notoi]

Gracias por tu respuesta. Pues vere si al final lo hago en 16 o 32. Tb la proxima vez me fijare donde postear, creo q iba a la seccion d programacion grafica. Oops. Merci.

[[EX3]]

Pues vere si al final lo hago en 16 o 32.

Y por que no las dos? Recuerda que puedes dar la opcion al usuario de elegir una u otra desde un menu de configuracion o similar. Lo suyo seria intentar inicializar en 32 y si da error por que el dispositivo grafico no lo permite, inicializar en 16.

Salu2...

[notoi]

Bueno hare una prueba cn eso de 2 modos. Es que es mi primer juego y no quiero complicarme la vida. Pero puesto que todos los graficos 'en bruto' los hago en 32bits y a mayor resolucion pues igual es una buena opcion lo que dices para que alcance mayor publico posible. Gracias.

[[EX3]]

Es que es mi primer juego y no quiero complicarme la vida.

No te preocupes, cuando aprendas a inicializar en 32 bits veras que solo es cambiar ese 32 por un 16 y listos, no tiene mas complicacion la cosa ;)

Salu2...

[notoi]

Bueno ya mas o menos me voy aclarando. Ya codifique rutinas para imprimir un pixel en 16 y 32. Ahora tengo una duda que es mejor hacer todos los graficos y grabarlos en formato de 32 bits y mostralos despues en la pantalla sea el modo 16 o 32?? O tener 2 versiones de graficos, una grabada en formato 32 y otra 16 para los 2 modos??  Yo he hecho unas pruebas y creo que con grabar todos los graficos en formato de 32 bits basta. Pues probe cargar un bitmap de 32bit en el modo de pantalla de 16bits y la verdad se veia mucho mejor que si lo hubiera grabado el bitmap en formato de 16bits y presentado en su modo correspondiente de pantalla a 16 bits de profundidad.

[[EX3]]

Mi libreria y pongo la mano en el fuego de que la gran mayoria de motores y librerias tambien, trabajan internamente todos los graficos en memoria en formato de 32 bits, esto sobre todo facilita tambien el tema de leer y escribir valores RGB unicos entre un modo grafico y otro, por ejemplo para dibujar pixeles sueltos como estas haciendo (esto al menos en Direct3D, no recuerdo si se regia igual en DirectDraw).

No es necesario tener los graficos en los dos formatos ya que es gastar mas recursos y mas complicaciones para mantener ambas versiones cuando seguramente ni si quiera llegues a usar en la vida el modo de 16 bits (insisto, es que hoy dia no hay necesidad con las graficas integradas que circulan y contando con las tarjetas de hace 6 años o mas inclusive). El propio render de DirectX ya se encarga de realizar la conversion al vuelo de los pixeles de las imagenes de un modo a otro a la hora de dibujarlos en pantalla por lo que te quita todo el trabajo tedioso en caso de inicializar en un modo u otro.

Salu2...

[notoi]

OKss. Tomo nota y gracias.

[Netto22]

Es decir que diseñando todos los modelados en 32 si este no lo aguanta automaticamente pasa a 16?

Eso debe estar especificado en el motor ?

[[EX3]]

En el motor solo especificas que las texturas y superficies tengan el formato correcto a 32 bits. Luego, si el render lo permite, Direct3D en mi caso, convierte los pixeles de las texturas al formato del backbuffer. Si el backbuffer se inicializo en 16 bits el render lo convierte a 16 bits (el backbuffer toma el formato del modo de vídeo establecido). Como antes remarcaba, no recuerdo si DirectDraw realizaba esta conversión automáticamente (hace siglos que no lo toco), pero vamos, cargar imágenes de 32 bits o 24 bits en una textura de 16 bits en memoria si lo permitía, previa perdida de calidad de color obviamente, por lo que la conversión solo lo realiza el render al cargar las imágenes en vez de en tiempo de renderizado. Simplemente, tendrías que indicarle al motor que cuando inicialices en modo 16 bits las texturas las cree en ese formato. Esto en Direct3D no es necesario por lo primero que comentaba, lo de la conversión al vuelo en tiempo de renderizado, y supongo que cualquier otra API gráfica con aceleración 3D como OpenGL funcionara igual.

Salu2...

[Netto22]

Existe pues la posibilidad de que por falta de memoria no se pueda realizar la conversion, no?

En ese caso no se podria ordenar la "posible" conversion en un momento donde toda la memoria estuviera disponible, o al inicio de todo el programa?

Es que si la conversion se hace "al vuelo" puede que algunos ordenadores vease antiguos, o por mala optimizacion, se queden sin recursos no?

[[EX3]]

Existe pues la posibilidad de que por falta de memoria no se pueda realizar la conversion, no?

En ese caso no se podria ordenar la "posible" conversion en un momento donde toda la memoria estuviera disponible, o al inicio de todo el programa?

Es que si la conversion se hace "al vuelo" puede que algunos ordenadores vease antiguos, o por mala optimizacion, se queden sin recursos no?

Si estamos hablando de un 8086, sin coprocesador matematico 8087 de apoyo, con 512kb de RAM y una gráfica integrada EGA o CGA de unos pocos kbs de memoria pues si es posible que se quede sin recursos :P

Hoy día cualquier gráfica integrada, como decía antes, soporta de sobra los trabajos a 32 bits de color, incluyendo conversiones de formatos al vuelo y muchas otras operaciones complejas como son el calculo de transparencias (alphablending) o simples escalados con suavizados, ya que disponen de aceleración por hardware. Sinceramente, no soy ingeniero ni nada por el estilo, simplemente me baso en experiencias propias y la verdad que hasta la fecha nunca he sufrido problemas de memoria trabajando las texturas en 32 bits de forma independientemente al modo de vídeo, y tampoco recuerdo haber tenido problemas similares cuando trabaje años atrás con DirectDraw, donde seguramente como comentaba mas arriba, la conversión se realice allí al cargar la textura y no al renderizarla, por lo que en este ultimo caso la disposición de memoria es individual por textura y en su día con mi Pentium 2 a 400mhz, 64Mb RAM y una gráfica sin aceleración por hardware de 4Mb de vídeo iba sobrado en mis pruebas.

Salu2...

[[EX3]]

Acabo de echar un vistazo a uno de los tutoriales de http://directx4vb.vbgamer.com/ sobre DirectDraw para refrescar un poco la memoria y veo que ni si quiera se define el formato de pixel de las superficies al crearlas, cosa que en Direct3D si se tiene que hacer obligatoriamente, por lo que deduzco que lo de la conversión de formatos lo lleva internamente de forma transparente para el usuario, seguramente aplicando el formato del modo de vídeo (osea, del backbuffer una vez creado), por lo que seria como decía, se realiza la conversión del formato en el momento de cargar la textura en memoria, individualmente por textura en el momento de la carga, por lo que seria difícil colapsar o desbordar la memoria de vídeo en dicho proceso.

Salu2...