• Viernes 15 de Noviembre de 2024, 05:42

Autor Tema:  Re: cambio de modo  (Leído 1874 veces)

JuanK

  • Miembro de ORO
  • ******
  • Mensajes: 5393
  • Nacionalidad: co
    • Ver Perfil
    • http://juank.io
Re: cambio de modo
« en: Lunes 4 de Agosto de 2003, 18:26 »
0
Hola, espreo que alguien pueda ayudarme,  resulta que estoy diseñando un juego  (si ahi voy otra vez con e,l cuento del juego..)

Y quisiera saber como puedo intercambiar de fullscreen a modo windowed y viceversa, ya que siempre que intento hacerlo, me salen errores al intentar dibujar en las superficies, no estoy utilizando flip page, sino solo blits comunes y corrientes, si arranco el sw en pantalla normal, no hay problema, igual si lo arranco -fullscreen, el problema es cuando quiero cambiar de modo, y cuando por ejemplo otro programa toma el foco de la aplicacion, al devolverme al juego se pierde la superficie tambien..:(

Voy a tratar creando inicializadores para ambos casos, de tal manera que pueda intercambiar entre las dos sin problemas, pero me gustaria saber sino hay un metodo màs optimo..

Aclaro que no estoy con Direct3D sino con DirectDraw.


Juank:hippi:

PDT: No importa en que lenguaje me den la explicacion, necesito es el concepto, de hecho la aplicacion es en c#, pero hay màs posibilidades de que alguien de aca me ayude.
[size=109]Juan Carlos Ruiz Pacheco
[/size]
Microsoft Technical Evangelist
@JuanKRuiz
http://juank.io

JuanK

  • Miembro de ORO
  • ******
  • Mensajes: 5393
  • Nacionalidad: co
    • Ver Perfil
    • http://juank.io
Re: cambio de modo
« Respuesta #1 en: Lunes 11 de Agosto de 2003, 03:49 »
0
Como supuse desde el comienzo la unica manera, y por cierto la mas confiable si llegara a haber otra,  es volver a crear cada una de las superficies, casi se puede decir que lo unico necesario es destruir y volver a crear la superficie primaria, pero es mejor prevenir y reinicalizar todas las texturas, con esto de paso ahorramos codigo porque no necesitariamos crear una funcion adicional, sino que solamente se haria una invocacion a la rutina de inicializacion, al igual que cuando se controlan las excepciones de dibujo.

Desde luego esta solucion es mucho más
exigente a nivel de diseño del codigo fuente, porque es necesario adaptar las funciones para que sean mas generales, sino solo arrojaria errores de superficies ya utilizadas y aparecerian dibujos donde no deben estar.

Si alguien  necesita informacion más especifica no dude en contactarme dejando un post o en uiltimas escribiendo a mi mail.

Juank:hippi::hippi::hippi:

Bueno logicamente aunque yo mismo me res`pondi, he colocado el post para que si a alguin añgun dia se le presenta el incoveniente del cambio de modo tenga la solucion a la mano.

Esto es para que se encuentra mas facil por google:

DirectDraw DirectX pantalla modo windowed fullscreen superficies surfaces cambio switch mode
[size=109]Juan Carlos Ruiz Pacheco
[/size]
Microsoft Technical Evangelist
@JuanKRuiz
http://juank.io

Amilius

  • Miembro HIPER activo
  • ****
  • Mensajes: 665
    • Ver Perfil
cambio de modo
« Respuesta #2 en: Viernes 17 de Octubre de 2003, 21:08 »
0
Un extracto de un tutorial:

3. Losing Surfaces

One very important area of robustness that the code samples above ignored is what happens if the user switches away from a fullscreen DirectDraw app to some other app running in the system. First of all, your code needs to handle the WM_ACTIVATEAPP message and set a flag when your app goes inactive. In the idle section of your PeekMessage loop, check this flag, and don't try to update your display when you're not active.

But the real issue is that once you switch to another app, you have left the DirectDraw environment and allowed GDI to become active. GDI is oblivious to DirectDraw, and will overwrite the areas of display memory in use by your DirectDraw surfaces. This means that your bitmaps get wiped out and will need to be reloaded. Fortunately, when you call a function that operates on a surface, such as Flip() or BltFast(), DirectDraw will return an error of DDERR_SURFACELOST to let you know if the surface was lost. So, your code has to check for this error and reload the bitmaps into the surfaces if this error occurs.

ddrval = lpDDSPrimary->Blt( &rcRectDest, lpDDSBack, &rcRectSrc, DDBLT_WAIT, NULL);

                if( ddrval == DDERR_SURFACELOST )

                {

                    ddrval = restoreAll();

                }

               

                ddrval = lpDDSPrimary->Flip( NULL, DDFLIP_WAIT);

               

                if( ddrval == DDERR_SURFACELOST )

                {

                    ddrval = restoreAll();

                }

                :

                :

               

                void restoreAll()

                {

                    // for each surface your app has created you should do the following:

                    ddrval = lpMyDDSurface->Restore(); // this reattaches the video memory to the surface

                    if( ddrval == DD_OK )

                    {

                        lpTempDDS ->DDReLoadBitmap(); // this will be the same as the function above

                                                      // that was originally used to load the bitmap

                                                      // with the exception that the surface is already

                                                      // created and ready to go

                    }

                }
Bueno, básicamente cuendo el DDraw avisa si se perdió la superficie hay que aplicar un "restore" a la superficie y volver a recuperarla.

En mi caso uso siempre modo cooperativo, por lo menos hasta que termine mi juego.
¿Por que:?
1.- Cuando pasa algo "malo" en modo exclusivo (no cooperativo) y no preveiste el caso la pantalla no se restaura y queda toda negra y no queda otra que reiniciar.
2.- En modo cooperativo nunca pierdes superficies:)
3.- Aunque si hay que diseñar el juego para que pueda ser ejecutado en modo  exclusivo y se pueda implementar la recuperación de superficies sin mayores problemas, pienso que esa parte de la implementación se la debe hacer al final por comodidad ya que básicamente lo único que se gana es optimización (y no mucha la verdad) al utilizar el flip real. Digo esto especialmente por el punto 1.