Stratos: Punto de Encuentro de Desarrolladores

¡Bienvenido a Stratos!

Acceder

Foros





Menu

Mostrar Mensajes

Esta sección te permite ver todos los posts escritos por este usuario. Ten en cuenta que sólo puedes ver los posts escritos en zonas a las que tienes acceso en este momento.

Mostrar Mensajes Menu

Mensajes - ALRAZ

#1
Es decir, usar un delete en lugar de Release?

por cierto: gracias por la respuesta :)
#2
Hola, pego aquí un temilla que me está dando dolores de cabeza...

Trato de explicar la situación:

Estoy usando DirectInput 8 para una pequeña librería de manejo de entradas. Por ahora no hace mucho, pero ya tengo mapeados los eventos de DirectInput tanto de teclado como de Mouse y Joystick. (No hace falta decir que estoy ya está hecho, es para algo distinto de lo que hace SDL).

Todo funciona a las mil maravillas excepto por un pequeño detalle: Al salir de la aplicación, por alguna razón, la función IDirectInputDevice8::Release, se cuelga si mi ventana perdió el foco, y sólo se cuelga cuando el dispositivo es un Joystick. Si la aplicación no pierde el foco, el release funciona bien; adicionalmente, el Teclado y Mouse se liberan correctamente independientemente de si la ventana perdió o no el foco.

El código para Liberar y Adquirir dispositivos va más o menos así:


map <input_device, LPDIRECTINPUTDEVICE8> diDevice;


void unacquire_devs ()
{
map <input_device, LPDIRECTINPUTDEVICE8>::iterator Pos;
    for (Pos = diDevice.begin (); Pos != diDevice.end (); ++Pos)
    {
        cout << "Unacquiring dev " << Pos->first << endl;

        if (Pos->second != NULL)
            Pos->second->Unacquire ();
    }
}


void acquire_devs ()
{
map <input_device, LPDIRECTINPUTDEVICE8>::iterator Pos;
    for (Pos = diDevice.begin (); Pos != diDevice.end (); ++Pos)
        Pos->second->Acquire ();
}


Y en la función que procesa los mensajes tengo esto:

LRESULT CALLBACK WndProc( HWND hWnd,   // Handle For This Window
                          UINT uMsg,   // Message For This Window
                          WPARAM wParam,   // Additional Message Information
                          LPARAM lParam)   // Additional Message Information
{

    switch (uMsg)         // Check For Windows Messages
    {
case WA_INACTIVE:
{
unacquire_devs ();
}
        case WM_ACTIVATE:       // Watch For Window Activate Message
        {
acquire_devs ();
        }
// ...



Entonces, al momento de cerrar la aplicación, entre las muchas otras cosas que hago es llamar a una función que hace el Release de cada dispositivo que haya sido creado:



bool release_dev (input_device Dev)
{
if (diDevice [Dev] != NULL)
{
diDevice [Dev]->Unacquire ();
diDevice [Dev]->Release ();
diDevice [Dev] = NULL;

        return true;
}

    return false;
}


void destroy_dx ()
{
map <input_device, LPDIRECTINPUTDEVICE8>::iterator Pos;

    unacquire_devs ();

    for (Pos = diDevice.begin (); Pos != diDevice.end (); ++Pos)
        release_dev (Pos->first);

if (DXInputObj != NULL)
{
DXInputObj->Release ();
DXInputObj = NULL;
}

}



El programa se cuelga en la línea:       diDevice [Dev]->Release ();
Pero ello sólo ocurre cuando el Dev a liberar es un joystick y la ventana perdió el foco anteriormente.

Alguien se ha enfrentado a algo como esto antes?


Si sirve de algo, pego la función con la que estoy creando los Dispositivos DXI; aclarando que input_device es un enum de los tipos posibles de dispositivos (teclado, mouse, joystick0 a joystick7, ...)


bool open_dev (input_device Dev)
{
GUID DevGUID;
LPCDIDATAFORMAT DevDataFormat;
DIPROPDWORD Props;
DWORD CopLevel;

if (diDevice [Dev] != NULL)
return true;

switch (Dev)
{
case device_keyboard:
DevGUID = GUID_SysKeyboard;
DevDataFormat = &c_dfDIKeyboard;
            CopLevel = DISCL_FOREGROUND | DISCL_NONEXCLUSIVE;
break;
case device_mouse:
DevGUID = GUID_SysMouse;
DevDataFormat = &c_dfDIMouse;
            CopLevel = DISCL_FOREGROUND | DISCL_NONEXCLUSIVE;
break;
case device_joystick0:
case device_joystick1:
case device_joystick2:
case device_joystick3:
case device_joystick4:
case device_joystick5:
case device_joystick6:
case device_joystick7:

if (AvailJoy.find (Dev) == AvailJoy.end ())
{
seterror ("open_dev: Attempt to open an unavailable joystick");
return false;
}

DevGUID = AvailJoy [Dev];
DevDataFormat = &c_dfDIJoystick2;
            CopLevel = DISCL_NONEXCLUSIVE | DISCL_FOREGROUND;
break;

default:
seterror ("open_dev: Attempt to open an unknown device type");
return false;
}

hr = DXInputObj->CreateDevice (DevGUID, &diDevice [Dev], NULL);
if (FAILED(hr))
{
seterror ("open_dev: could not open DirectInput 8 Device");
return false;
}

diDevice [Dev]->SetDataFormat (DevDataFormat);
diDevice [Dev]->SetCooperativeLevel(hWnd, CopLevel);

//We are using Buffered input
    Props.diph.dwSize       = sizeof(DIPROPDWORD);
    Props.diph.dwHeaderSize = sizeof(DIPROPHEADER);
    Props.diph.dwObj        = 0;
    Props.diph.dwHow        = DIPH_DEVICE;
    Props.dwData            = _input_buffer_size;

hr = diDevice [Dev]->SetProperty (DIPROP_BUFFERSIZE, &Props.diph);

if (FAILED(hr))
{
seterror ("open_dev: could not set buffered device");
return false;
}

diDevice [Dev]->Acquire();

return true;
}
#3
General Programadores / Iteradores dentro de Templates
14 de Febrero de 2008, 02:03:45 AM
funciona  :D

Mil gracias ZaelSiuS :)
#4
General Programadores / Iteradores dentro de Templates
14 de Febrero de 2008, 01:24:50 AM
wenas  :D
Tengo una duda sobre plantillas y los iteradores de STL.

Sucede que tengo una api donde tengo varios tipos distintos de clases, las cuales se entregan solo como punteros mediante llamadas a funciones "createobject", "createanim", "createetc" (Las clases están en una DLL y son derivadas de clases virtuales, que son las que ve el programador).

Estaba pensando en hacer un administrador de clases para llevar a cabo un registro de todo lo que se crea y hacer una respectiva labor de limpieza a la salida.

La primera idea que me vino a la mente es con un template como el que sigue:


template <class T> class ClassMan
{
private:
   vector <T *>MyLst;

public:
   ClassMan ()  {};
   ~ClassMan () {clear ();};

   T *create ()
   {
       T *Tmp = new T;

       if (Tmp != NULL)
           MyLst.push_back (Tmp);

       return Tmp;
   };

   void release (T *ClassPtr)
   {

       vector <T *>::iterator Pos;

       Pos = find (MyLst.begin (), MyLst.end (), ClassPtr);

       if (Pos != MyLst.end ())
       {
           delete (*Pos);
           MyLst.erase (Pos);
       }
   };

   void clear ()
   {
       vector <T *>::iterator Pos;
       Pos = MyLst.begin ();

       while (Pos != MyLst.end ())
       {
           (*Pos)->clear ();
           delete (*Pos);

           ++Pos;
       }

       MyLst.clear ();
   };
};



El problema es que, al momento de crear el iterador, el compilador me dice:

G:/yge/yg_sdk/include/YG/yg_classman.h: In member function `void ClassMan<T>::release(T*)':
G:/yge/yg_sdk/include/YG/yg_classman.h:62: error: expected `;' before "Pos"
G:/yge/yg_sdk/include/YG/yg_classman.h:64: error: `Pos' was not declared in this scope


ese "; before Pos" lo marca en la línea donde estoy tratando de crear el iterator. Imagino que esto se debe hacer de otra forma...


alguien sabe si se puede o una forma de darle la vuelta a esto?

Gracias de antemano :)
#5
Creo que esta OpenInput es precisamente lo que estaba buscando :)

Muchas gracias a todos, en especial a [EX3] por la sugerencia
#6
En realidad estoy haciendo una API basada en plugins; uno de los plugins se encarga del manejo de las entradas, de ahí que necesito que sea una cosa independiente (dado que la ventana la maneja el plugin de gráficos)

Una alternativa sería crear la ventana principal de forma independiente a los plugins y luego pasarles la información tanto al de entrada como al de gráficos...?

Sigo abierto a sugerencias  :wink:
#7
Wenas otra vez  :D

Tengo otra de esas preguntillas raras... bueno, esta vez no es tan rara:
alguien sabe de alguna librería multiplataforma para manejo de entradas en C++?

Y por "entradas" me refiero a Joystick, Teclado, mouse y semejantes. SDL no me sirve pues requiere crear su propia ventana utilizando sus propias funciones y eso no es lo que requiero.

De antemano, gracias ;)
#8
General Programadores / GCC: Opcion -fPIC?
06 de Noviembre de 2007, 01:59:10 AM
Cita de: "aguspiza"Pues si tienes curiosidad y sabes un poquito de ingles aqui hay algunas razones de por que:

http://www.swig.org/Doc1.3/Python.html#Python_nn10
http://www.swig.org/Doc1.3/Python.html#Python_nn11
http://en.wikipedia.org/wiki/Position_independent_code

Basicamente es que la arquitectura AMD64 en Linux necesita codigo relocalizable (relocalizable sin necesidar de ejecutar un setup). Por cierto recuerda linkar a /usr/lib64 si haces librerias para AMD64

P.D: Este es mi primer mensaje por aqui, asi que aprovecho para saludar. Me he registrado para intentar hacer un prototipo de juego con CRM32Pro antes de que se lance metaplace y poder ir avanzando algo. Estaba intentando hacerme el wrapper con swig para python y por eso di con esta informacion :wink:

Interezantes links, muchas gracias :D

con lo de /usr/lib64 te refieres a las librerías ya compiladas (los .so)?
porque veo que mi ubuntu tiene un symlink de lib64 que apunta a lib
es decir, /usr/lib64 es lo mismo que /usr/lib
#9
General Programadores / GCC: Opcion -fPIC?
04 de Noviembre de 2007, 07:33:14 PM
Wenas!
Tenía rato que no me aparecía por aquí. Esta ves vengo con una dudilla sobre el compilador GNU GCC que viene con ubuntu.

Sucede que estoy haciendo una DLL que compila tanto en Güindous como en Linux.
La cosa está en que cuando compilo con Linux, el linker me marca el siguiente error:


/usr/bin/ld: ./obj/yg_aux.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC


Buen, lo solucioné agregando la dichosa opción -fPIC en los comandos de compilación, pero tengo curiosidad por saber qué es lo que hace esa opción exactamente.


Como nota adicional, comentar que estoy usando code::blocks en Ubuntu 7.10 para AMD64.

Gracias por sus comentarios y sugerencias :)
#10
En la función InitGL
tienes:


glOrtho(0, Width, Height, 0, 0, 1);


los últimos dos parámetros son la distancia mínima y máxima para Z, por lo que le estás diciendo que el valor mínimo para la profundidad es 0 y el máximo 1.
Intenta poner algo como 100 en lugar de ese 1.

Por cierto, creo que tienes mal un parámetro, según yo, es:

glOrtho (0 , ScrWidth, 0, ScrHeight, DrawNearDistance, DrawFarDistance);


Además de eso, claro, tendrás que activar el Depth test si no has ordenado previamente tus objetos
#11
General Programadores / CVS vs SVN
08 de Marzo de 2007, 09:20:10 PM
SVN se creó con el propósito específico de ser un remplazo de CVS.
#12
Programación gráfica / Multithreading En SDL
08 de Diciembre de 2006, 07:10:49 AM
Cita de: "phantom"
Si le añado un thread, el thread se ejecuta 1 sola vez:
¿como puedo hacer para que se ejecute varias veces?

haces un ciclo dentro del trhead
si es necesario que haga pausas, llamas SDL_Sleep dentro de ese ciclo.
(o algo así... hace mucho que no le muevo al SDL  :roll: )
#13
Programación gráfica / Multithreading En SDL
07 de Diciembre de 2006, 07:36:13 PM

mLog->write(2,"[CMultiThreading]-> added a Thread with the following name: %s & data: %s",THREADName, THREADData);


Mmmm...
esa línea me parece muy sospechosa...
Estás tratando de escribir THREADName como si fuera un string, siendo que en realidad es un puntero a función... muy malo muy malo...

lo mismo para THREADData


mmm...
aún así, no dices claramente cual es tu problema...
si el problema está en que se te cuelga la aplicación, muy probablemente sea eso que te dije arriba.


Si el problema es que sospechas que no te está creando los Threads, prueba escribir algo desde el thread.

mmm...
no sé...
necesitaría más información sobre el problema en si
#14
Cita de: "tamat"no, si ya las tengo estaticas, yo quiero juntarlas todas en una por evitar que el que cree un proyecto tenga que poner en la lista de librerias con las que linkar todas las que uso, que son casi unas 10.

Bueno, si eso es todo lo que necesitas, tal vez no te pese tanto tener que entregar los fuentes de lo siguiente que te voy a explicar:

Primero, tendrás que usar Visual C++, porque me he dado cuenta que la versión precompilada de DevIL da mucho problemas con MinGW. Si vas a usar DevIL con MinGW tendrás que recompilar esa librería

y segundo, siga usted las instrucciones que aparecen en pantalla:
-Crea un proyecto DLL
-Agrega un Main.cpp al proyecto, o ponle el nombre que más te guste
-en el código de Main.cpp, agrega todos los includes de cada una de las librerías. Ejemplo:
#include <sdl.h>
#include <sdl_image.h>
#include <il/il.h>
#include <il/ilu.h>
//etc...
-Busca en las propiedades del proyecto algo donde agregar los nombres de los .lib de cada una de las librerías y obviamente, agrega ahí sus nombres
-Compila!
-Obtendrás una DLL de salida, además de un .lib (o un .a si estás usando MinGW).
-Crea un archivo .h con los includes arriba mencionados

Ahora sólo tienes que decirle al programador que incluya tu .h y linkee al .lib que te ha generado el compilador
y liiiiistooooo

El problema es que ahora tendrás otra DLL que incluir en el directorio donde se encuentran los archivos compilados con tu librería.


Bueno, por ay va la cosa.
#15
General Programadores / Problema extraño
23 de Septiembre de 2006, 07:12:42 AM
mmm...
bueno, pueden ser muchas cosas

pero para empezar
me parece bastante sospechoso ese "screen = iniciar_sdl ();"


es para crear una surface o para iniciar sdl en sí?
porque si es lo segundo, está muy mal ubicado.

Otra cosa es que habría que ver bien el código de cómo inicias SDL con OpenGL y cómo los haces trabajar en conjunto.





Stratos es un servicio gratuito, cuyos costes se cubren en parte con la publicidad.
Por favor, desactiva el bloqueador de anuncios en esta web para ayudar a que siga adelante.
Muchísimas gracias.