Pregunta
Cuando tienes un juego en 2D que usa imágenes realmente grandes (más grandes de lo que admite tu hardware), ¿qué haces? Quizás haya alguna solución interesante a este problema que nunca antes me haya ocurrido.
Básicamente estoy trabajando en una especie de creador de juegos de aventura gráfica. Mi público objetivo son personas con poca o ninguna experiencia en desarrollo de juegos (y programación). Si estuvieras trabajando con una aplicación de este tipo, ¿no preferirías que maneje el problema internamente en lugar de decirte que "dividas tus imágenes"?
Contexto
Es bien sabido que las tarjetas gráficas imponen un conjunto de restricciones en el tamaño de las texturas que pueden usar. Por ejemplo, cuando trabajas con XNA estás restringido a un tamaño de textura máximo de 2048 o 4096 píxeles dependiendo del perfil que elijas.
Por lo general, esto no representa un gran problema en los juegos 2D porque la mayoría de ellos tienen niveles que se pueden construir a partir de piezas individuales más pequeñas (por ejemplo, fichas o sprites transformados).
Pero piense en algunos juegos clásicos de aventura gráfica point'n'click (por ejemplo, Monkey Island). Las salas de los juegos de aventuras gráficas generalmente están diseñadas en su conjunto, con secciones pequeñas o nulas repetibles, como un pintor que trabaja en un paisaje. O tal vez un juego como Final Fantasy 7 que utiliza grandes fondos pre-renderizados.
Algunas de estas habitaciones pueden ser bastante grandes, con frecuencia abarcando tres o más pantallas de ancho. Ahora, si consideramos estos fondos en el contexto de un juego moderno de alta definición, superarán fácilmente el tamaño máximo de textura admitido.
Ahora, la solución obvia para esto es dividir el fondo en secciones más pequeñas que se ajusten a los requisitos y dibujarlas una al lado de la otra. Pero, ¿debería usted (o su artista) ser el que divide todas sus texturas?
Si está trabajando con una API de alto nivel, ¿no debería estar preparado para lidiar con esta situación y dividir y ensamblar las texturas internamente (ya sea como un proceso previo como el Canal de contenido de XNA o en tiempo de ejecución)?
Editar
Esto es lo que estaba pensando, desde el punto de vista de la implementación de XNA.
Mi motor 2D solo requiere un subconjunto muy pequeño de la funcionalidad de Texture2D. De hecho, puedo reducirlo a esta interfaz:
public interface ITexture
{
int Height { get; }
int Width { get; }
void Draw(SpriteBatch spriteBatch, Vector2 position, Rectangle? source, Color color, float rotation, Vector2 origin, Vector2 scale, SpriteEffects effects, float layerDepth);
}
El único método externo que uso que se basa en Texture2D es SpriteBatch.Draw () para poder crear un puente entre ellos agregando un método de extensión:
public static void Draw(this SpriteBatch spriteBatch, ITexture texture, Vector2 position, Rectangle? sourceRectangle, Color color, float rotation, Vector2 origin, Vector2 scale, SpriteEffects effects, float layerDepth)
{
texture.Draw(spriteBatch, position, sourceRectangle, color, rotation, origin, scale, effects, layerDepth);
}
Esto me permitiría usar una ITexture de manera intercambiable cada vez que use una Texture2D antes.
Entonces podría crear dos implementaciones diferentes de ITexture, por ejemplo, RegularTexture y LargeTexture, donde RegularTexture simplemente envolvería un Texture2D normal.
Por otro lado, LargeTexture mantendría una Lista de Texture2D cada una correspondiente a una de las piezas divididas de la imagen completa. La parte más importante es que llamar a Draw () en LargeTexture debería poder aplicar todas las transformaciones y dibujar todas las piezas como si fueran solo una imagen contigua.
Finalmente, para hacer que todo el proceso sea transparente, crearía una clase de cargador de texturas unificado que actuaría como un Método de Fábrica. Tomaría la ruta de la textura como parámetro y devolvería una ITexture que sería una RegularTexture o una LargeTexture, dependiendo de que el tamaño de la imagen exceda el límite o no. Pero el usuario no necesitaba saber cuál era.
¿Un poco exagerado o suena bien?