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 - Jare

#1
i<=128
Prueba con < solamente. Te estas saliendo del array.
#2
General / Cuidado, Se Ocultan Tras Otros Nombres
20 de Diciembre de 2007, 06:31:05 PM
Cita de: "Prompt"Para saber algo de la situación actual de Gextech podriamos ver un post de Jare bastante explicito. Aunque ya es de hace un tiempo.
Te refieres a lo que escribi en http://www.stratos-ad.com/forums3/viewtopic.php?t=5611 ? Eso es de hace mas de dos años, yo no lo llamaria "actual". :) Ademas, ahi no hablaba de GexTech, a quienes no conocia por entonces (aparte de Alberto G.B.), sino de los sinverguenzas estos que andaban enmierdando de forma rastrera y carente de toda etica profesional.

Parece que hechos recientes han confirmado la calaña de esta gentuza. Francamente, el que personajes asi hablen mal de una empresa (GexTech o la que sea) es señal que, al menos, la empresa ha hecho alguna cosa bien (librarse de ellos).
#3
General Programadores / ¿Eventos vs funciones virtuales?
19 de Diciembre de 2007, 09:39:43 AM
Cada vez que tengo que debuguear algo pasando por el rollo de signal/slots de Qt me dan ganas de matar a alguien. En cambio, los delegates de C# me gustan mucho. Para gustos, colores...
#4
General Programadores / Abrir la aplicación una sola vez
19 de Diciembre de 2007, 09:12:52 AM
Lo de la DLL efectivamente no es buena idea.

"Win32 DLLs are mapped into the address space of the calling process. By default, each process using a DLL has its own instance of all the DLLs global and static variables."

http://msdn2.microsoft.com/en-us/library/h90dkhs0(VS.80).aspx

Por cierto que un metodo mejor para detectar si la aplicacion ya existe, que siempre funcionara sin coñas de cuanto de rapido las arrancas, lo mencionan en la ayuda de WinMain:

http://msdn2.microsoft.com/en-us/library/ms633559.aspx

Me puse a experimentar un poco con el tema, asi que aqui va un tocho con funcionalidades mas avanzadas. Los comentarios deberian explicarlo todo; siento que esten en ingles, pero la costumbre es la costumbre. :)


#include <stdio.h>
#include <stdlib.h>
#include <windows.h>

LRESULT WINAPI MsgProc( HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam )
{
   switch( msg )
   {
       case WM_COPYDATA:
       {
           const COPYDATASTRUCT *cd = (const COPYDATASTRUCT *)lParam;
           char buf[1000];
           sprintf_s(buf, sizeof(buf), "WM_COPYDATA\n dwData = %d\ncbData = %d\nlpData = '%s'", (int)cd->dwData, cd->cbData, cd->lpData);
           MessageBox(hWnd, buf, "Received", MB_OK);
           OutputDebugString(buf);
           break;
       }
       case WM_DESTROY:
           PostQuitMessage( 0 );
           return 0;
   }
   return DefWindowProc( hWnd, msg, wParam, lParam );
}


int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
   static char WndClass[] = "WCTest";

   // Try to locate the other application a few times before giving up
   DWORD err;
   for (int i = 0; i < 10; ++i)
   {
       // "Local" indicates the current session, so multiple users on the same machine
       // will be able to run their own copy of the app.
       // You could use "Global" to enforce one copy of the app PER MACHINE.
       //    In that case, to communicate with the running app from another user
       //    you will likely need additional work with security descriptors (ugh)
       // If you don't specify either, it will behave as if you used "Local".
       // Remember to use a name that is unique to this application!
       HANDLE onlyOneMutex = CreateMutex(NULL, TRUE, "Local\\OnlyOnceMyApp"); // Or just use the WndClass string
       err = GetLastError();

       if (err == ERROR_ALREADY_EXISTS)
       {
           // Another copy of the app is running already and owns the Mutex.
           // Close the handle ASAP because we don't own the Mutex, but our handle would keep it alive
           // if the owner application exits right now.
           CloseHandle(onlyOneMutex);

           HWND hwOther = FindWindow(WndClass, NULL);
           if (hwOther)
           {
               // Show the existing app's window (restore if it's minimized).
               if (IsIconic(hwOther))
                   ShowWindow(hwOther, SW_RESTORE);
               SetForegroundWindow(hwOther);
               // We found the other app's window, send it the command and finish.
               COPYDATASTRUCT cd;
               cd.dwData = 0; // Some number identifying your command.
               cd.lpData = "This is a string message";
               cd.cbData = (DWORD)strlen((const char*)cd.lpData) + 1; // trailing \0
               SendMessage(hwOther, WM_COPYDATA, NULL, (LPARAM)&cd);
               return 0;
           }
       }
       else
       {
           // The app is not currently running, no need to retry
           break;
       }
       Sleep(500); // Wait a bit and retry
   }

   // Verify what really happened
   if (err == ERROR_ALREADY_EXISTS)
   {
       // The app is already running but it doesn't answer (maybe it crashed)
       MessageBox(NULL, "Application is already running but doesn't listen", "Oops", MB_OK);
       return 1;
   }
   else if (err == ERROR_ACCESS_DENIED)
   {
       // The app is already running but we don't have permissions to access it
       MessageBox(NULL, "We lack permissions to access the running application", "Oops", MB_OK);
       return 1;
   }
   else if (err != ERROR_SUCCESS)
   {
       // We can't create the handle, something horrible happens
       MessageBox(NULL, "We suck", "Oops", MB_OK);
       return 1;
   }

   // Use this for testing to force the application to delay creating the main window.
   MessageBox(NULL, "Before creating the window", "delay", MB_OK);

WNDCLASSEX wc = { sizeof(WNDCLASSEX), CS_HREDRAW | CS_VREDRAW, MsgProc, 0L, 0L,
 GetModuleHandle(NULL), NULL, LoadCursor(NULL, IDC_ARROW), NULL,
  NULL, WndClass, NULL };
RegisterClassEx( &wc );

HWND hWnd = CreateWindow( wc.lpszClassName, "WC Test",
 WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT,
 NULL, NULL, wc.hInstance, NULL );
   ShowWindow(hWnd, SW_SHOW);
   UpdateWindow(hWnd);

   MSG msg = { 0 };
   while ( GetMessage( &msg, NULL, 0, 0) )
   {
       TranslateMessage( &msg );
       DispatchMessage( &msg );
   }

   // Use this for testing, to force the application to delay exiting
   MessageBox(NULL, "After destroying the window", "delay", MB_OK);

   return (int)msg.wParam;
}


Hale.
#5
General Programadores / Abrir la aplicación una sola vez
21 de Noviembre de 2007, 08:42:45 AM
       case WM_COPYDATA:
       {
           const COPYDATASTRUCT *cd = (const COPYDATASTRUCT *)lParam;
           char buf[1000];
           sprintf(buf, "WM_COPYDATA\n dwData = %d\ncbData = %d\nlpData = '%s'", (int)cd->dwData, cd->cbData, cd->lpData);
           MessageBox(hWnd, buf, "Received", MB_OK);
           break;
       }

...

 HWND hwOther = FindWindow(wc.lpszClassName, NULL);
 if (hwOther)
 {
   COPYDATASTRUCT cd;
   cd.dwData = 0; // Some number identifying your command.
   cd.lpData = "This is a string message";
   cd.cbData = strlen((const char*)cd.lpData) + 1; // trailing \0
   SendMessage(hwOther, WM_COPYDATA, NULL, (LPARAM)&cd);
   return;
 }

Funciona en Vista, pero el metodo para detectar si la aplicacion ya esta corriendo puede fallar si las multiples copias arrancan suficientemente rapido.
#6
Jaime Cifuentes y David Punset tambien estan en Ubi Soft.
Miguel Escudero ya no estaba en EA, pero hace unos meses que no hablo con el.
Juan Ramon Sanchez tambien dejo EA pero no recuerdo su nueva empresa.
David Morris-Oliveros esta en Wizkid.
Jorge Sanchez Magdaleno estaba en Lionhead, no se si sigue ahi.
Se que hay un español en Recoil Games pero no se quien es. :P
Jose Luis Sanchez y Oscar Villelas estan en Eurocom.
#7
Yo tengo una, bastante sencilla pero no hace virguerías con el rendering: http://www.iguanademos.com/Jare/files/FontCreator_1.0.zip
#8
General Programadores / C++ y POO
13 de Enero de 2007, 05:58:28 AM
Cita de: "shephiroth"A ver, no entendi muy bien..
Si piensas que YO hago una librería de clases para vehículos, y que tú quieres usarla en tu aplicación (de cuyo pintado y necesidades yo no sé ni puedo saber nada), entonces verás a qué me refiero.
CitarNO, NO, NO, NO, NO Y MIL VECES NO. Aqui no me entendiste en absoluto. No me refiero en la clase base crear una lista por cada uno de sus tipos. Me referia a crear una lista estatica en cada clase HIJA. De esta forma podrias acceder directamente hija::funcion. Al crear una nueva clase no necesitarias cambiar ningun codigo existente, solo tendrías que clonar el comportamiento de la lista.
¿Y quién es el que accede a cada una de esas listas? Recuerda la idea de que la librería de vehículos no puede ni debe saber nada sobre lo el uso concreto que la aplicación quiere hacer de ella.
#9
General Programadores / C++ y POO
13 de Enero de 2007, 03:52:29 AM
Cita de: "shephiroth"Si los necesitas solo para mostrarlos en pantalla, una funcion virtual de mostrar. Si quieres operar solo con una de las clases hijas podrías usar una funcion estatica y que la clase tenga por medio de una lista dinamica o algo parecido consciencia de todos los objetos de dicha clase.
¿Las clases de la jerarquía de vehiculos necesitan saber cómo queremos (y qué necesitamos para) pintarlas en pantalla? Creamos un acomplamiento extra con nuestro sistema de pintado, que no es muy agradable de cara a la reusabilidad.

"Pasale un interfaz a la función de pintar, y así tu te lo implementas para tus funciones de pintado concretas" dirá alguno. Pero claro, para que mi interfaz pueda recibir los datos de cualquiera de las clases para usarlos como YO quiera, la función "pintar" tendrá que pasarselos de alguna forma simbólica y genérica, por ejemplo un mapa indexado por cadenas del tipo "Cilindrada" y "Consumo". No es que sea muy óptimo...

Mi implementación del interfaz de pintado tendrá que ir consultando cada elemento del mapa de datos que me da el vehículo, y hacer un... ¿switch/case o cadena de IFs? Y eso aún sería fácil si todos los datos consultables son del mismo tipo, números por ejemplo. ¿Y si algunos son floats, otros cadenas, y otros son a su vez contenedores de otros objetos, por ejemplo el campo "Cargamento"?

Eso solamente para el problema de pintarlos. Si quiero hacer una "librería de vehiculos" para que otra gente la use, tengo que preveer todos los posibles usos que la gente querrá hacer con esos vehiculos, y preparar un interfaz para cada funcionalidad. Lo siento, pero mi bola de cristal está sin pilas.

La solución de implementar una lista estática que contenga las instancias de cada clase no es que ayude mucho, ya que:

- Introduce costes extras de gestión y memoria.

- Sólo tiene sentido en clases que no tengan a su vez otras derivadas (lo que podría no ser aplicable), ya que el mismo objeto aparecería en varias listas estáticas diferentes. También hace poco viable que yo derive nuevas clases especializadas a partir de las ya existentes. Supongo que los constructores de cada clase tendrán que recibir un parámetro "bool bRegisterInStaticList" que por defecto sea true, pero que las derivadas lo pasen como false al constructor de su clase padre.

- Asume que sólo tengo una colección de vehículos sobre la que quiero iterar, o bien me obliga a asegurarme de que cada vehículo de la lista estática está en mi contenedor concreto, subiendo el coste del algoritmo de O(n) a O(n^2).

- Me obliga de igual forma a conocer todas las clases posibles, para acceder a la lista estática de cada una de ellas. Si añado nuevas clases, tengo que modificar cada algoritmo que haya implementado sobre la colección. Que es exactamente el mismo problema que tenía con los mecanismos tipo RTTI, pero con todos los problemas adicionales ya descritos.

Lo de las funciones virtuales vacías en la base no resulta muy aplicable cuando la clase base me la dan ya hecha en una librería que yo quiero extender con nuevas clases (que incluyen datos no previstos en la librería original).

En serio... de verdad os creeis que el RTTI se metió en C++ porque la mayoría de los desarrolladores son vagos o idiotas? Existen muchos problemas para los cuales RTTI es realmente la mejor solución. El que diga que esos problemas no te los encuentras en el mundo laboral, no sabe muy bien de lo que habla.

Si quieres crear una librería de objetos especializada, genérica, flexible y extensible, realmente necesitas un mecanismo de este tipo o limitarás sus posibles usos. La gente que se encontraba con este problema se inventaban su propio getType(), y al final el lenguaje incorporó una forma común de hacerlo.
#10
General Programadores / C++ y POO
11 de Enero de 2007, 03:54:09 PM
Cita de: "Pogacha"La POO se basa en llevar el problema a los dominios de la mente y no a los dominios de la codificación.
:shock: Eso no tiene ningun sentido, y el que "pretende" tener no es cierto.
#11
General Programadores / C++ y POO
09 de Enero de 2007, 01:42:41 AM
Preguntar si un determinado objeto es de una clase o no es un caso concreto de un problema más general: preguntar si un objeto tiene o no una propiedad o conjunto de propiedades. Estoy seguro de que todo el mundo ha hecho eso alguna vez. Basta de "chorradas" sobre si es "OOP" o no. :)
#12
General Programadores / C++ y POO
08 de Enero de 2007, 08:37:11 PM
1 - Extender las clases base con métodos virtuales vacíos.
2 - Llamar a getType() en el código que usa esas clases.
3 - Acompañar a un contenedor polimórfico de contenedores para cada tipo concreto.

La primera es la solución "por defecto" siempre que podamos hacerlo (podamos modificar las clases con las que estamos trabajando) y no se nos vaya de madre.

La segunda es la solución habitual cuando no podemos (o no queremos) incluir la funcionalidad que estamos programando dentro de esas clases.

La tercera suele aplicarse para optimizar, o cuando no queremos abusar de ninguna de las otras dos.

Hacer cualquier cosa de esas por norma es una marranada, hacerlo cuando resulta apropiado es perfectamente válido. Menos religión y más sentido común! :P
#13
Off-topic / Alguien se acuerda de estos juegos?
21 de Noviembre de 2006, 12:27:56 AM
Cita de: "Cralfer"
CitarIf I were to be a game tester for EA back in 96 my tip to them would be; make the game bigger!

:-O
Bueno, el juego lo distribuyó Electronic Arts en Europa, en una de sus lineas "budget". :)
#14
Industria y mercado / Jare se va....!
18 de Noviembre de 2006, 08:49:27 PM
Cita de: "seryu"Y a todo esto, Jare no ha dicho que se pyre de pyro por estar a disgusto. A lo mejor simplemente encontro un sitio que le gustaba mas.
No hay que darle muchas vueltas, siempre hay un poco de todo. Cada cual tiene que buscar lo que quiere hacer, y cómo quiere hacerlo. A mi me a veces me acusan de ser bastante radical en esos temas (y algo de razón tienen ;)) o sea que no es extraño que después de 8 años haya decidido moverme otra vez.

Así que hale, a pelear por lo que cada uno quiere, pero sin pisotear a nadie para conseguirlo! Y gracias por los cumplidos. ;)
#15
Off-topic / Alguien se acuerda de estos juegos?
18 de Noviembre de 2006, 08:31:43 PM
Cita de: "zwiTTeR"Tengo el speed haste en cd-rom por aquí :-D
Me consta que no lo pagaste! ;)

Jeje, las historias para no dormir siempre vuelven, que si tal me timó o que si cual no me pagó... es una pena. En mi caso, mi contrato para el Speed Haste era con Friendware, y aunque los temas económicos siempre eran tensos, cobré decentemente y no me puedo quejar; dudo que nadie se hiciera rico a nuestra costa. Por aquella época la gente en España todavía no concebía la idea de poner más de 4 o 5 millones de pelas para financiar un juego completo, y no les faltaba razón: era raro que los royalties dieran para mucho más que eso. Aparte de lo que supuso para mi propia carrera profesional, me queda el orgullo de que de aquellas experiencias (y las de gente como Revistronic) se crease una sensación de que en España se podía hacer algo más, y unos cuantos años después hubo un Pyro, un Rebel Act, etc para corroborarlo.

La única empresa de la que me puedo quejar que me dejó algo sin pagar es americana, pero yo sabía a lo que me arriesgaba llegando a un acuerdo puramente verbal. De todo se aprende. :)

La web de Moby Games recuerdo que en sus origenes la montó Trixter, un demoero yanqui que vivía en Chicago. Una vez que le visité me comentó que la acababa de poner en marcha, pero no imaginaba que se convertiría en la Wikipedia de los juegos! Tiene su jeta puesta en http://www.mobygames.com/developer/sheet/view/developerId,46400/

Ah! El Haste bastante tuvimos con sacarlo, pero se nos llevaban los diablos cuando veiamos los juegos de carreras 3D que estaban saliendo por esa época, especialmente el Screamer (y encima eran italianos! ;)). Yo curraba, luego tenia la universidad, y encima de todo sólo 10 meses para hacer el Haste enterito, con red y todo. ¿Alguien sabe si el multiplayer por modem funcionaba? Creo que no llegamos ni siquiera a probarlo.  :shock:





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.