Source: http://foro.speccy.org/viewtopic.php?f=6&t=2913&p=30576
Timestamp: 2017-06-24 13:52:58+00:00

Document:
por sromero el Mie Oct 17, 2012 2:02 pm Hola a todos,Tengo una pregunta sobre la programación de juegos 2D en entornos modernos con un problema que no se sufre en los juegos 3D (ni en el Spectrum, claro). La planteo aquí porque se me dió hace uno o dos años cuando me planteé la posibilidad de acabar mi PCMaziacs y hacerlo multiplataforma e incluso de hacer algún otro remake de juego de Spectrum. Si no os parece un lugar apropiado, lo puedo mover a otro subforo.Hago la versión resumida de la pregunta, y luego la exposición. Si alguien quiere participar en la discusión, me gustaría que se leyera la exposición (aunque sea larga) para entender mis motivaciones y dudas.Ojo, es posible que la pregunta no tenga una respuesta directa o fácil. Yo tengo mi propia idea de cómo atacar el problema, pero lo que quiero saber no es cómo se puede hacer sino cómo se debe hacer o cómo se hace normalmente a día de hoy.--- Pregunta versión resumida: ---¿Cómo se tiene que diseñar o programar un juego 2D en cuanto a los gráficos y el GUI para que pueda funcionar en diferentes resoluciones y aspects ratios, es decir, poder llegar tanto a PC, como a iOS, Android, etc?Me estoy refiriendo a soportar:- Diferentes resoluciones (sin perder calidad gráfica).- Diferentes aspects-ratios (4:3, 16:9, 16:10...) (e incluso orientación vertical/horizontal!)Y me refiero a soportarlo en estos aspectos:- Gráficos de fondos y personajes (calidad de los mismos, ¿varios sets?, ¿gráficos vectoriales? ¿2.5D?, ¿renderizar escena+zoom?).- Elementos del GUI (fuentes, menúes, inventarios, puntuación) : posicionamiento en pantalla, etc.- Velocidades y posiciones de los personajes proporcionales a la resolución .La duda puede ser tan simple como elegir en qué resolución hacer un remake, y que el usuario no lo vea en una ventanita de tamaño ridículo o en un fullscreen de píxeles del tamaño de un puño porque la resolución nativa del monitor es FullHD. De elegir entre varias resoluciones, o de cuál elegir.--Fin pregunta resumida--------------------------------Ahora viene el contexto histórico y el torrente de dudas e ideas. Personalmente, siempre que he programado aplicaciones gráficas (demos, juegos, lo que sea) ha sido con una resolución fija.En el Spectrum no tenías ninguna duda con la resolución: 256x192 y a trabajar. En el PC, en la época del 486 y Pentium MMX, lo habitual era tanto en MSDOS como en Windows elegir una resolución fija (320x200, 320x240, 640x480...) y lanzar el juego en fullscreen. Tampoco había muchas resoluciones a elegir: 320x200, 640x480, 800x600 y 1024x768 en 4:3 eran los "estándares".La selección fija de resolución te permitía utilizar un único set de gráficos, y (erróneamente) mover todo el entorno de juego (personajes, etc) con "coordenadas de pantalla" en lugar de utilizar "coordenadas de mundo" y después transformarlas (ej: la bala se mueve 2 píxeles por segundo, la nave 3 píxeles por segundo, etc). Incluso se fijaba el número de cuadros por segundo y se asumía que no variaba.Si querías soportar más de una resolución en un PC, como eran "conocidas" (desde 320x200 a 1024x768), podías optar por 2 sets gráficos a diferentes resoluciones y "hardcodear" (también error) en cierta manera todo (GUI, movimientos, etc) según si estabas en una resolución u otra.Cuando entraron en juego hardwares más potentes, tenías la posibilidad de alcanzar más cuadros por segundo y los podías aprovechar bien especificando una tasa de FPS fija superior (normalmente la máxima del refresco 50-60Hz, y asumiendo que el juego no iría bien en sistemas más antiguos) o basando el movimiento de los personajes en el tiempo transcurrido desde el anterior fotograma, lo que adaptaba los frames a la velocidad de la máquina de forma "automática" (más fluído en hw potente, más "choppy" en hardware antiguo). Esto solucionaba el problema del "posicionamiento" y "movimiento", en cierta medida.Los problemas aparecen por la parte de las resoluciones y los gráficos, cuando:- Entran en juego diferentes resoluciones.- El jugador puede tener monitor panorámico 16:9, 16:10, o un monitor 4:3.- Entran en juego tablets, móviles, etc, con resoluciones variadas o desconocidas a priori y con 2 posibles orientaciones.- Entra en juego permitir al usuario CAMBIAR de resolución (en ordenadores).- Los LCDs/TFTs tienen una resolución nativa y forzar una resolución en FULL SCREEN queda horroroso.Concretamente:Caso Monitor panoramico 16:9/16:10 vs 4:3:Si eliges una única resolución "base" (por ej 800x600) y fuerzas ese modo de pantalla en fullscreen, puede darse el caso de que el usuario tenga un monitor panorámico (aparte de que se vea horrible en un LCD/TFT por la diferencia con la resolución nativa). En ese caso se me ocurre que tienes que detectar la resolución y elegir entre dos opciones: a.- El juego transcurre en 4:3 a todos los efectos, tanto internamente como visualmente -> Si el monitor es 4:3 no se cambia nada al renderizar la escena y si el monitor es 16:9 se selecciona el modo equivalente en 16:9 y o bien se centra la imagen en pantalla (con bandas negras) o bien se pone algún tipo de marco decorativo, o bien se aprovecha el área para mejorar los marcadores / inventario / etc. Lo ideal supongo que sería asumir que el juego sea 16:9 y hacer la "adaptación" para 4:3, por eso de que casi todos los monitores hoy en día son panorámicos, pero ... el iPAD es 4:3 y no se puede despreciar su público en número de usuarios. b.- El juego se adapta a la resolución adicional -> Se diseña para "jugar" 4:3 pero según el tipo de juego, puede ser factible o no mostrar más área de pantalla. Por ejemplo en un juego con vista superior tipo Advance Wars o Zelda, podemos elegir mostrar más área de juego pero en otros puede no serlo. Por ejemplo, en un Bubble Bobble o un FinalFight ver más cantidad de pantalla no es lo adecuado.Con lo que la primera duda es: ¿programas pensando en 4:3 y desaprovechando panorámicos (cuando todos los monitores de PC son panorámicos)? ¿Se puede o debe hacer la inversa? (para panorámicos y recortar de alguna forma a 4:3).Caso diferentes resoluciones:Vas a diseñar un remake de un juego... ¿qué resolución eliges?a.- Si eliges una resolución baja y fuerzas FULLSCREEN, en monitores grandes se ven píxeles como puños. b.- Si eliges una resolución alta, puede haber equipos incapaces de moverlo.Además, si no es la nativa del monitor y es LCD/TFT el resultado es difuso.c- Si eliges soportar varias resoluciones, tienes 2 opciones: c.1. Dar soporte a varias resoluciones preseleccionadas, con lo que tienes el problema de que necesitas varios sets de gráficos si quieres que el área de juego sea la misma en las diferentes resoluciones (y no que en cada resolución sea vea mayor área de juego con los gráficos más pequeños). c.2. Dar soporte a todas las posibles resoluciones eligiendo una resolución base contra un buffer y escalando el volcado de ese buffer a la resolución de pantalla. De nuevo tienes que tener en cuenta además el aspect ratio para esto. Es decir, si queremos dar soporte no sólo al PC y a varias resoluciones concretas en 4:3 y 16:9, y queremos añadir iOS, Android, etc, la cantidad de resoluciones destino disponibles es enorme. Y puede que el dispositivo no sea lo bastante potente (y esto es CPU) para el escalado en tiempo real de todo el área de trabajo a la resolución destino. Más posibilidades y problemas:- ¿Escalar los personajes? -> definir los gráficos para la mayor de las resoluciones y escalar para las menores o viceversa.- ¿Diferentes sets gráficos? -> requiere un enorme trabajo gráfico para juegos 2D.- ¿Gráficos vectoriales tipo svg? -> ¿Realmente se usa esta técnica?- La solución pueden ser los 2.5D (2D hecho con opengl renderizado con una cámara "lateral" o "superior"). Las múltiples resoluciones y aspect ratios también te obligan a adaptar la "velocidad" de los personajes según la resolución y los widgets del gui (menúes, marcadores, fuentes, etc). Esto no debería ser problema si las velocidades no se definen en "pixeles por segundo" sino en "unidades de movimiento del mundo virtual por segundo" (ej: metros por segundo) y después se escala lo que es "un metro" a las dimensiones en píxeles de los gráficos en la pantalla (según la resolución). Pero ya no es la facilidad de decir "esta nave se mueve 2 pixeles por segundo y esta mas rapido, a 3", hay que andar haciendo conversiones para todo lo que se va a trazar en pantalla.¿Cuál es la mejor opción entonces para este problema?- Sets de gráficos -> "formatos gráficos pequeños + escalar hacia arriba" (entiendo que horrible a menos que quieras zoom de tipo 2x, 3x puro estilo retro), "formatos gráficos grandes + escalar hacia abajo" (entiendo que mejor, aunque el resultado del escalado sea "fuzzy"), "varios formatos (pequeño, mediano, grande) y escalar el más cercano", "2.5D y utilizar opengl"?.- 16:9 vs 4:3 -> ¿Marco? ¿centrar? ¿y si el juego no permite "dar más área visible?"- Menúes, fuentes, pantallas intermedias y de fin de fase -> ¿tenerlas en diferentes resoluciones? ¿de resolución fija y escalar?PD: Veo que no soy el único que se plantea o se ha planteado estas preguntas:Resolution-and-Aspect-Ration-Independent-2D-GameEngine-DesignDifferent-screen-resolutions-in-a-2d-gameDifferent screen resolutions in a 2D gameWhat-should-i-keep-in-mind-when-making-2d-games-for-multiple-resolutionsPor desgracia, no veo muchas soluciones más allá de "ceñirse al dispositivo mayoritario al que apunta el juego y escalar al vuelo el buffer resultante para el resto, en cada fotograma"... o "hacer diferentes versiones (ipad, pc, android) centrando cada una en una resolución estándar".Ya ni siquiera considerando Android, sino simplemente el PC, si tuviera que hacer un remake y tuviera que elegir una o varias resoluciones, me veo en un dilema por la existencia de 4:3/16:9/16:10 o de gente con monitores de portátil de 1280x800 y gente con monitores FullHD donde cualquier tamaño tipo 640x480 se vería horrible.¿Opiniones?
por na_th_an el Mie Oct 17, 2012 4:07 pm Yo haría lo siguiente:1.- Diferentes resoluciones: nativamente, trabajo en una "estándar" más o menos grande (siempre hay, más o menos, una estándar, 800 y algo por 480 para los móviles está muy extendida, por poner un ejemplo, o 1280x800 en portátiles), y escalo para las demás. Puede ser buena práctica trabajar como para 720p y escalar arriba o abajo en otras resoluciones.2.- Diferentes aspect ratios: Adaptable. Si estás usando pantallas fijas, lo suyo es trabajar para 16:9 y luego expandir arriba y abajo con más fondo si detectas 4:3. Si estás usando scroll, puedes hacer lo que mejor te venga: trabajar como para 4:3 y dejar más espacio a los lados, o viceversa, dependiendo de la orientación o del tipo de juego. Por lo general la acción ocupará la pantalla completa, sólo tienes que reposicionar el HUD (o no, si lo pones en la esquina superior izquierda, como hacen tantos ).Hay que cambiar el chip, no se puede pensar en una resolución fija y ya no tiene demasiado sentido poner un marcador que pille media pantalla (y que habría que adaptar).También hay que pensar que muchos desarrolladores trabajan ahora con gráficos vectoriales, por lo que tampoco hay problemas de escalado, solo de aspecto.Sobre lo de forzar una resolución en full screen, pues no es necesario si usas un buen escalado hardware. De todas formas, mi monitor no es para nada caro y las resoluciones forzadas se ven muy bien, el hardware escala aplicando un buen filtro. La nativa es de 1440x900, pero si pongo un juego de 640x480 (por poner un ejemplo) a pantalla completa, respetando o no el aspect ratio, se ve bastante bien. Por ejemplo, el Spectaculator a 640x480 sin aspect ratio a pantalla completa se ve de arte. A ver si hago alguna foto.
por sromero el Mie Oct 17, 2012 6:29 pm na_th_an escribió:Yo haría lo siguiente:1.- Diferentes resoluciones: nativamente, trabajo en una "estándar" más o menos grande (siempre hay, más o menos, una estándar, 800 y algo por 480 para los móviles está muy extendida, por poner un ejemplo, o 1280x800 en portátiles), y escalo para las demás. Puede ser buena práctica trabajar como para 720p y escalar arriba o abajo en otras resoluciones. En resumen, que acabamos con:- 2 versiones (una para móviles y otra para sobremesas o tablets HD).- Escalar desde una resolución preseleccionada para cada una de esas versiones.¿Qué pasa entonces con toda la miriada de dispositivos "baratos"? ¿Tienen suficiente CPU/GPU para soportar "escalar cada frame"?2.- Diferentes aspect ratios: Adaptable. Si estás usando pantallas fijas, lo suyo es trabajar para 16:9 y luego expandir arriba y abajo con más fondo si detectas 4:3. Si estás usando scroll, puedes hacer lo que mejor te venga: trabajar como para 4:3 y dejar más espacio a los lados, o viceversa, dependiendo de la orientación o del tipo de juego. Por lo general la acción ocupará la pantalla completa, sólo tienes que reposicionar el HUD (o no, si lo pones en la esquina superior izquierda, como hacen tantos ).Lo lógico sería pensar que lo que más tiene la gente son dispositivos panorámicos (monitores de PC, móviles, tablets) pero entonces llega el iPAD y te revienta la teoría.Lo de desarrollar 16:9 y "adaptar" 4:3 no veo cómo en juegos de pantalla fija. Si la pantalla tiene un tamaño fijo ¿cómo la expandes en 4:3? Por ejemplo, si programas un Bubble Bobble (por decir algo) en 4:3 lo puedes adapta a 16:9 con franjas negras. Pero al revés ... ¿cómo se adapta? ¿Lo centras en 4:3 en una resolución mayor (si la hay)? ¿Y si no la hay? Hay que cambiar el chip, no se puede pensar en una resolución fija y ya no tiene demasiado sentido poner un marcador que pille media pantalla (y que habría que adaptar). Ya, por eso, pero eso complica "bastante" el desarrollo. Quiero decir, que se convierte en más abstracto, y tienes que tener en cuenta montones de posibilidades tanto en el diseño como en la programación. Está claro que si utilizas correctamente variables "de mundo" (de juego) tipo screen_w, screen_h, start_x, start_y, graphic_scale_factor, movement_scale_factor, etc, se debería de poder hacer el juego y extraer de él fácilmente subversiones con otros tamaños de gráficos y demás (o hacer el escalado al vuelo al cargar los gráficos) pero no deja de ser un coñazo (con perdón) y una incomodidad.También hay que pensar que muchos desarrolladores trabajan ahora con gráficos vectoriales, por lo que tampoco hay problemas de escalado, solo de aspecto. Sí, esa puede ser la clave del escalado. Entiendo que la mayoría de los juegos de iOS usan ese tipo de gráficos, ¿verdad? Lo que pasa es que crear ese tipo de gráficos ya no es tan inmediato como el pixel-art (no digo que el pixel-art sea más difícil, sino que esto es diferente).Sobre lo de forzar una resolución en full screen, pues no es necesario si usas un buen escalado hardware. De todas formas, mi monitor no es para nada caro y las resoluciones forzadas se ven muy bien, el hardware escala aplicando un buen filtro. La nativa es de 1440x900, pero si pongo un juego de 640x480 (por poner un ejemplo) a pantalla completa, respetando o no el aspect ratio, se ve bastante bien. Por ejemplo, el Spectaculator a 640x480 sin aspect ratio a pantalla completa se ve de arte. A ver si hago alguna foto.Bueno, supongo que conforme vas subiendo de resolución (vamos, que no uses 320x200 ni 640x480 sino superiores) se tiene que ir viendo cada vez mejor ... entonces sí que podrías elegir una resolución "alta" (800x600 o superior) y dar al usuario opción de Windowed / FullScreen.De todas formas, todas estas cosas terminan acabando para mí con la sensación de "diversión" que me da programar algo. Cuando para hacer un simple tetris tienes que tirar 2000 líneas de código sólo para controlar la resolución del juego, el aspect ratio y 100 variables abstractas, se pierde "romanticismo"...
por na_th_an el Mie Oct 17, 2012 6:43 pm Por eso paso de hacer cosas para dispositivos modernos Por muy simple que quieras hacer algo, necesitas un equipo y convertirlo en un trabajo. Paso. Me lo paso mucho mejor haciendo juegos para 8 bits o, como mucho, para MSDOS (que es a lo que estoy "jugando" ahora )De todos modos, ten en cuenta que no creo que haya nadie que haya escrito un juego tan adaptable que lo único que tengas que hacer para cada nuevo dispositivo sea compilarlo... Nada más que partiendo de la base de que los juegos en Android se programan en Java y en iOs se programan en Objective C, ya tienes necesidad (heavy) de adaptación. Por lo general ahora lo que hay son motores ya hechos y la gente programa scripts en LUA o en otros lenguajes parecidos y/o nativos del engine que se emplean para definir el gameplay. Sobre todo si hablamos de juegos "tipo retro", te puedes permitir trabajar interpretado sobre un engine que ya haya resuelto todos los problemas.Ahora mismo, aunque el gameplay sea en 2D, pocos juegos están hechos "realmente" en 2D. Todos emplean algún tipo de motor 3D, aunque solo sea para mostrar planos paralelos a la pantalla... Trabajar así te permite simplificar muchísimo el desarrollo, sobre todo a la hora de tener un scroll de varios planos, o de emplear el mismo gráfico más cerca o más lejos, o de mostrar más o menos área de juego dependiendo de la relación de aspecto de la pantalla...El problema real es cuando pensamos en un diseño de videojuegos claramente orientado a una resolución y relación de aspecto fijas, como el Bomberman que has mencionado.A la hora de trasladar el gameplay del Bomberman a otras plataformas, Hudson soft lo tuvo claro: scroll. ¿Qué más da la resolución o la relación de aspecto si no tienes más que un área de visión de un mapeado mayor? Que se vea más o menos por los lados, es lo de menos. El juego funciona igual en una GB o en una PSP, por poner dos extremos.El problema viene cuando quieres hacer un remake y hacerlo fidedigno. En ese caso, lo mejor es el letterbox y a tirar.
por sromero el Mie Oct 17, 2012 6:56 pm na_th_an escribió:Por eso paso de hacer cosas para dispositivos modernos Por muy simple que quieras hacer algo, necesitas un equipo y convertirlo en un trabajo. Paso. Me lo paso mucho mejor haciendo juegos para 8 bits o, como mucho, para MSDOS (que es a lo que estoy "jugando" ahora ) Pues eso, esa es la sensación que tengo ahora. Yo hubiera querido aprovechar la potencia de los ordenadores de ahora (y las herramientas) y que prácticamente no hay ninguna limitación para el desarrollador si lo comparamos con desarrollar para Spectrum (donde TODO está limitado, potencia de CPU, memoria, almacenamiento, formato de los gráficos, colores...). Pero entonces llegas y te encuentras este tipo de "peculiaridades" y la verdad es que echa para atrás.De todos modos, ten en cuenta que no creo que haya nadie que haya escrito un juego tan adaptable que lo único que tengas que hacer para cada nuevo dispositivo sea compilarlo... Nada más que partiendo de la base de que los juegos en Android se programan en Java y en iOs se programan en Objective C, ya tienes necesidad (heavy) de adaptación.Bueno, yo había pensado en usar Python+pygame (PC) y RENPY (http://pygame.renpy.org/) para Android. Así podría programar en Python que es un lenguaje que me encanta.Por lo general ahora lo que hay son motores ya hechos y la gente programa scripts en LUA o en otros lenguajes parecidos y/o nativos del engine que se emplean para definir el gameplay. Sobre todo si hablamos de juegos "tipo retro", te puedes permitir trabajar interpretado sobre un engine que ya haya resuelto todos los problemas.Bueno, es una opción, pero estuve viendo LUA y no me apetece mucho aprender otro lenguaje interpretado, conociendo ya python.Ahora mismo, aunque el gameplay sea en 2D, pocos juegos están hechos "realmente" en 2D. Todos emplean algún tipo de motor 3D, aunque solo sea para mostrar planos paralelos a la pantalla... Trabajar así te permite simplificar muchísimo el desarrollo, sobre todo a la hora de tener un scroll de varios planos, o de emplear el mismo gráfico más cerca o más lejos, o de mostrar más o menos área de juego dependiendo de la relación de aspecto de la pantalla... Eso es lo que comentaba, juegos en 2.5D. Esto lo hace en python por ejemplo el motor pyglet. Y te salen juegos tipo New Super Mario Bros, etc (podemos remontarnos hasta el Pandemonium, Klonoa...), donde tienes resuelto todo: resoluciones, escalado...Pero tiene varias pegas (de opengl) texturas con ciertos límites o restricciones, cámaras, etc...El problema real es cuando pensamos en un diseño de videojuegos claramente orientado a una resolución y relación de aspecto fijas, como el Bomberman que has mencionado. Sí: bomberman, bubble bobble, manic miners, etc...A la hora de trasladar el gameplay del Bomberman a otras plataformas, Hudson soft lo tuvo claro: scroll. ¿Qué más da la resolución o la relación de aspecto si no tienes más que un área de visión de un mapeado mayor? Que se vea más o menos por los lados, es lo de menos. El juego funciona igual en una GB o en una PSP, por poner dos extremos. Ya ... pero no lo "siento igual" X-D Sí, es una tontería, pero me sale así xD
por antoniovillena el Mie Oct 17, 2012 10:15 pm Lo suyo es que hagas un único juego que funcione a 2 ó 3 resoluciones distintas y vas escalando según la plataforma. Eso sí, el escalado debe ser cúbico o Lanczos, de lo contrario se verá muy cutre.Yo personalmente te recomiendo un aspect ratio intermedio, 3:2 que es el que tiene el iPhone. El cociente ancho/alto es de 1.5. En el caso de PAL/VGA no panorámico es 4:3= 1.3333 y en el caso panorámico 16:9= 1.7777. Así solventas los distintos aspect ratios con bandas negras no muy anchas. Aunque también puedes incluir en el juego la opción de escalar a toda la pantalla, viéndose el juego un poco deformado.Por ponerte un ejemplo, usando estas 3 resoluciones:a) 240x160b) 480x320c) 960x640Tienes cubierto todo el espectro posible de dispositivos. Tampoco necesitas tener 3 versiones distintas de cada sprite. Almacenas solo los sprites de mayor resolución y haces el escalado de sprites en RAM en la inicialización del juego. Al ser las dimensiones doble y cuádruple, el escalado es muy sencillo, tan sólo tienes que hacer la media de 4 ó 16 píxeles.Te ahorrarás muchos quebraderos de cabeza si sólo publicas una única versión del juego. La pega que tiene es que en las plataformas móviles tendrías un ejecutable bastante grande por el tema de los gráficos. Esto lo puedes solucionar usando compilación condicional para el escalado. La clave está en que el mismo código fuente compile/se interprete en todas las plataformas.Edito: En algunos casos no merece la pena hacer el escalado, empleando 4 bandas negras en lugar de 2. Si la resolución a adaptar es 640x480 sí tendrías que escalar (desde 480x320 ó 960x640 dependiendo si prefieres más rendimiento o mejores gráficos). Pero por ejemplo si tienes 800x600, es preferible perder 20px a los lados y 80px arriba y abajo a tener que escalar. Tendrías que diseñarte un algoritmo que decida cuándo escalar y cuándo no.
por sromero el Jue Oct 18, 2012 10:12 am antoniovillena escribió:Por ponerte un ejemplo, usando estas 3 resoluciones:a) 240x160b) 480x320c) 960x640Tienes cubierto todo el espectro posible de dispositivos.Bufff... pero 240x160 es ... joder, es menos que el Spectrum. ¿Eso para el iphone? ¿o para una gameboy? ¿Algo usa esa resolución a día de hoy? Yo como mínimo apuntaría inicialmente a iPhone 3 o superior (320 x 480 pixels). No creo que quede ya mucha gente con menos que eso o que la obsolescencia programada de Apple en sus cacharros le deje llevarlo mucho más tiempo.Eso dejaría b) y c), pero c) la veo algo escasa para un PC y para un tablet moderno... ¿no? Te ahorrarás muchos quebraderos de cabeza si sólo publicas una única versión del juego. La pega que tiene es que en las plataformas móviles tendrías un ejecutable bastante grande por el tema de los gráficos. Esto lo puedes solucionar usando compilación condicional para el escalado. La clave está en que el mismo código fuente compile/se interprete en todas las plataformas. Pero ... ¿es realmente posible una única versión del juego? Para iOS tiene que ser ObjectiveC. Para PC y Android puede ser Python, pero para iOS no...Edito: En algunos casos no merece la pena hacer el escalado, empleando 4 bandas negras en lugar de 2. Si la resolución a adaptar es 640x480 sí tendrías que escalar (desde 480x320 ó 960x640 dependiendo si prefieres más rendimiento o mejores gráficos). Pero por ejemplo si tienes 800x600, es preferible perder 20px a los lados y 80px arriba y abajo a tener que escalar. Tendrías que diseñarte un algoritmo que decida cuándo escalar y cuándo no. Sí, entiendo que sí. Un saludo.
por antoniovillena el Jue Oct 18, 2012 10:52 am sromero escribió:Bufff... pero 240x160 es ... joder, es menos que el Spectrum. ¿Eso para el iphone? ¿o para una gameboy? ¿Algo usa esa resolución a día de hoy? Yo como mínimo apuntaría inicialmente a iPhone 3 o superior (320 x 480 pixels). No creo que quede ya mucha gente con menos que eso o que la obsolescencia programada de Apple en sus cacharros le deje llevarlo mucho más tiempo.Eso dejaría b) y c), pero c) la veo algo escasa para un PC y para un tablet moderno... ¿no? Pues entonces quita la a) y mete una d):b) 480x320c) 960x640d) 1920x1280La idea es que cada resolución sea el doble (cuádruple en área) que la anterior. b) y c) coinciden con las resoluciones del iPhone 3 y del iPhone 4.sromero escribió: Pero ... ¿es realmente posible una única versión del juego? Para iOS tiene que ser ObjectiveC. Para PC y Android puede ser Python, pero para iOS no...Si te refieres a un único ejecutable y que sea el mismo para todas las arquitecturas, es posible en entornos con máquina virtual. Por ejemplo en Java te valdría el mismo archivo .jar para todas las arquitecturas, y en javascript también te valdría el mismo .html.Pero claro ciertas plataformas donde la resolución es relativamente alta con respecto a la capacidad gráfica de la GPU/CPU te quedarías corto en FPS usando una VM, por lo que tendrías que usar un lenguaje compilado, y evidentemente cada ejecutable sería distinto.Aún así sería mucho más fácil mantener el código fuente si es el mismo para todas las arquitecturas, empleando directivas de compilación condicional en el precompilador. Lo difícil tal vez es encontrar un lenguaje común y compiladores para las diferentes plataformas que reconozcan la misma versión del lenguaje. Aquí no puedo ayudarte, lo único decirte que el Ansi C es el lenguaje compilado más portable que existe, y si no existe para iOS (desconozco dicha plataforma) es porque los de Apple quieren que sus desarrolladores sólo trabajen para iOS.
por na_th_an el Vie Oct 19, 2012 8:30 pm No es que no se pueda programar en C puro para iOS, es que luego los programas no pasan el validador de Apple y no te los publican. Al menos eso tengo entendido. Tienen una lista de restricciones más larga que el Levítico.
por sromero el Sab Oct 20, 2012 6:36 pm Esta lectura totalmente enfocada a dispositivos móviles (es de un framework) me ha parecido interesante :http://wiki.starling-framework.org/manu ... evelopment
por Gandulf el Mie Oct 24, 2012 7:55 am Desde mi punto de vista la única solución buena es hacer gráficos vectoriales y simplemente cambiar el formato de la vista. Si esto no es una opción, puedes depende del tipo de juego. Si no es un arcade lateral y la vista es por ejemplo isométrica o cenital, creo que la mejor opción es mostrar más tiles (más zona de mapa) pero mantener la resolución de los gráficos, así a mayor resolución, más comodidad pero la calidad se mantiene. Si ampliar la zona de mapa a mostrar tampoco es una opción, mal asunto. Como decía na_th_an, lo mejor es basarse en un estandar tipo 720p y luego escalar, pero si las resoluciones a mostrar son muy diferentes no va a funcionar bien (y hacer diferentes sets gráficos para cada resolución es un trabajo ingente)
por sromero el Mie Oct 24, 2012 8:32 am Gandulf escribió:Desde mi punto de vista la única solución buena es hacer gráficos vectoriales y simplemente cambiar el formato de la vista. Si esto no es una opción, puedes depende del tipo de juego. Si no es un arcade lateral y la vista es por ejemplo isométrica o cenital, creo que la mejor opción es mostrar más tiles (más zona de mapa) pero mantener la resolución de los gráficos, así a mayor resolución, más comodidad pero la calidad se mantiene. Si ampliar la zona de mapa a mostrar tampoco es una opción, mal asunto. Como decía na_th_an, lo mejor es basarse en un estandar tipo 720p y luego escalar, pero si las resoluciones a mostrar son muy diferentes no va a funcionar bien (y hacer diferentes sets gráficos para cada resolución es un trabajo ingente) Yo creo que las únicas soluciones cuyo resultado es visual y gráficamente decente son:1.- La que comentas: gráficos SVG, y escalarlos "en el inicio" como bitmaps a la resolución destino elegida, y reescalarlos ante petición de cambio de resolución o de orientación del dispositivo. Pero claro, necesitas TODO en formato vectorial: sprites, tiles, fuentes, etc...2.- Programarlo en 3D con OpenGL, más concretamente en 2.5D como hacen muchas bibliotecas. Los sprites (en alta resolución o vectoriales) se renderizan como texturas sobre "cubos" y se coloca la cámara en la perspectiva deseada (superior, cenital, lateral...). Tiene la ventaja de que encima puedes añadir efectos de iluminación y demás.En fin ... a mí es que programar en 3D no me llama nada ... NoP / Compiler

References: resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución