Hola,
está claro que la libreria está diseñada para trabajar en una única ventana, así que mi duda es: se puede hacer un juego que requiere de muchas pantallas(ventanas) diferentes?
como se implementaria?
Gracias
No se puede por que dx_lib32 solo puede gestionar un render grafico al mismo tiempo. Puedes probar a crear varias instancias de la clase gráfica en el programa pero no se si te dara problemas (no recuerdo si lo llegue a probar alguna vez), y ten en cuenta que cada instancia de la clase grafica necesitara sus propios graficos (es como si fueran programas distintos).
Salu2...
Lo que no entiendo entonces es como programan esos juegos que tienen tantas pantallas porque aunque esta libreria no soporte mas de un render a la vez, en realidad programar sobre directx es igual si no me equivoco. Estoy mirando y no entiendo como se puede hacer eso.
Alguna sugerencia?
No es tan sencillo. Para programar en varias pantallas a la vez se ha de usar un mecanismo llamado Swap Chains, y esto es en tanto en DirectX como en OpenGL. Ese sistema se supone permite crear varios renders asociados a distintos contenedores (Ventanas por ejemplo) y todos asociados a la misma instancia y recursos de Direct3D. Piensa tambien que no es comun hacer juegos que utilicen mas de un monitor, yo de hecho en mas de 10 años nunca he jugado ninguno en PC que lo haga y no me era necesidad implementar esa función. Realmente ese mecanismo se utiliza para mas desarrollar herramientas como editores 3D que necesitas diferentes vistas de una misma escena que en juegos donde solo usas una sola vista.
Salu2...
Quizás me he explicado mal, es que yo lo que necesito es:
quiero hacer un juego tipo manager y por lo tanto necesito varias pantallas: alineación, tácticas, etc....
como puedo hacer eso???
gracias por todo
Cita de: divmas en 22 de Marzo de 2011, 10:16:27 AM
quiero hacer un juego tipo manager y por lo tanto necesito varias pantallas: alineación, tácticas, etc....
Por diferentes pantallas me hablas de diferentes secciones/estados de tu juego? (Introducción, menú principal, configuración, juego, game over, créditos, etc...)
Salu2...
exacto... como implemento eso??
gracias
La respuesta son Maquinas de estados. La idea es separar logicamente secciones del juego como compartimentos aislados con su propio codigo y desde de un punto principal del programa, mediante x estados ejecutar el compartimento o seccion correspondiente. Piensalo como si hablaramos de un select case y cada caso fuera un estado diferente del juego. Lo mas comodo para programarlo es que separes en clases cada seccion de tu juego y siguieras un patron tipo Actualizar y Dibujar, dos metodos que tuvieran cada compartimento para tal acciones, de esa forma en ese select case solo tendrias llamadas al metodo Update() y el metodo Draw() de cada estado:
Una lista de estados predefinda:
enum GameStates
menu
juego
configuracion
gameover
end enum
Variable global que controlara el estado en que se encuentra el programa:
public estado as gameStates
estado = menu
Codigo para actualizar los estados del programa:
select case estado
case menu
claseMenu.Update()
case juego
claseJuego.Update()
case configuracion
claseConfiguracion.Update()
case gameover
claseGameOver.Update()
end select
Codigo para actualizar la vista del programa:
select case estado
case menu
claseMenu.Draw()
case juego
claseJuego.Draw()
case configuracion
claseConfiguracion.Draw()
case gameover
claseGameOver.Draw()
end select
La idea por ejemplo seria que si estas en el estado juego y matan a tu personaje querras mostrar la pantalla de Game Over y las opciones de continuar o volver al menu del juego, eso seria principalmente cambiar el estado de "juego" a "gameover" para que el Select Case ejecute el codigo de la pantalla de gameover, y dicho codigo tendra las opciones pertinentes para o bien volver al estado de juego (inicializando el codigo necesario del juego por ejemplo para resetear el nivel) o bien para volver al menu principal del programa.
Esto en verdad te lo puedes montar de mil maneras pero la idea es generalmente esta.
Salu2...
Muchas gracias por tu ayuda. Intentaré implementar esas pantallas como has comentado esperando tener éxito.
Aprovecho para darte la enhorabuena, tanto por la libreria como por la labor de ayuda constante.
Un saludo
estaba probando tus consejos y perdona, sólo una cosa:
el select case del metodo draw está claro que ha de ir dentro del loop pero el método update donde iria? ya que no hay que ir actualizando constantemente.
Entiendo que en draw va todo el dibujado y en update la carga de recursos. Es asi?
Gracias una vez más
Traduce "update" y te llevarás una sorpresa sobre cuándo hay que actualizarlo :)
Update/Actualizar - Siempre antes que los graficos:
- Fisicas/Colisiones
- IA
- Estados de los personajes y elementos del juego
- Lectura del input
- Calculos varios
- Etc...
Draw/Dibujar - Siempre despues de actualizar todo:
- Solo dibujo, nada de calculo ni logica alguna. Los calculos necesarios y cambios de estado en los graficos los habras realizado en la actualización.
Salu2... :)
Piensa que tu bucle principal tendria que tener simplemente una estructura tan sencilla como esta:
Do While Condicion
Juego.Update()
Juego.Actualizar()
Loop
Juego.Update() tendria todas las llamadas a los metodos Update de cada elemento de tu juego:
Sub Update()
Dim Elemento As ElementoJuego
For Each Elemento In ListaElementos
If Elemento.Enabled Then Elemento.Update()
Next
End Sub
Juego.Draw() todas las llamada a los metodos Draw de cada elemento de tu juego.
Sub Draw()
Dim Elemento As ElementoJuego
For Each Elemento In ListaElementos
If Elemento.Visible Then Elemento.Draw()
Next
End Sub
ElementoJuego es una definicion de lo que vendria a ser cualquier clase que definas en tu juego que tenga su metodo Update() y Draw() y sus propiedades Enabled y Visible.
Cada una de estas funciones internamente pueden dividirse en mas niveles y asi sucesivamente segun como diseñes tu codigo. Resultado? Un bonito arbol de llamadas facil de seguir y de depurar asi como de limpio y organizado a la par de facil de mantener. Esto, muy en base, es el sistema de componentes que tanto hablo en otros post y que desde hace años implemento en mis desarrollos y no es nada nuevo bajo el sol ya que este tipo de implementacion la vas a encontrar en la mayoria de software y herramientas como XNA o Unity3D :)
Salu2...
Se supone que la carga de recursos iria en update?
si va en el método update de la clase de la pantalla en cuestión se carga constantemente, si se pone en draw igual....
entonces?
La carga de recursos sólo se hace una vez y tienes dos formas de hacerlo, si el juego es pequeño te puedes cargar todo antes. Si el juego es grande puedes hacer una máquina de estados donde uno de los estados sea cargar los recursos y que solo se ejecute una vez.
Cargar_Recursos
Do while.....
ciclo principal
Loop
Descargar_recursos
Do while MainLoop
Select Case Estados
case 0: CargarRecursos
case 1: ciclo principal
end select
Loop
Private sub CargarRecursos
....
....
....
Estados = 1 'mueves el estado del juego una vez cargado los recursos
End sub
[code]
No es necesario que uses el mismo código, estoy solo ejemplificando la forma de hacerlo.
La logica y el dibujado nada tienen que ver con la gestion o carga de recursos. La logica solo comprende la parte no visible del elemento como son calculos, lecturas de input, colisiones, etc... y el dibujado unicamente la parte visible, solo las llamadas graficas que reflejan los cambios realizados en la logica (de ahi que siempre se ejecute la logica antes del dibujado). La carga de recursos es un proceso puntual del juego.
Cita de: Hechelion en 25 de Marzo de 2011, 01:17:20 AM
La carga de recursos sólo se hace una vez y tienes dos formas de hacerlo, si el juego es pequeño te puedes cargar todo antes.
En XNA por ejemplo viene predefinido en la clase principal del proyecto un método llamado LoadContent() y otro llamado UnloadContent() que es donde se escribe todo el codigo de carga y descarga de recursos del juego. Esto viene bien si tu juego es pequeño, defines toda la carga en un mismo punto que solo se ejecutara una única vez al iniciar el programa. Cuando el juego es mas grande puedes seguir la idea de Hechelion o definir bien la estructura de tu juego, por ejemplo, la carga de recursos puede ser parte del constructor de la clase principal que representa el nivel del juego, que en base a un archivo listado cargue e inicialice los elementos definidos de dicho escenario. Entidades como los enemigos, su constructor puede realizar la carga de los recursos relacionados.
Salu2...