[eside-ghost] Quake 4

Jorge García (aka Bardok) bardok en telefonica.net
Sab Nov 12 18:24:01 CET 2005


Buenas,

> No sé demasdiado de programación, pero tengo entendido que a la hora de la
> portabilidad, lo que da más problemas es, precisamente la salida. Es decir,
> un juego de rol no debería dar problemas de portabilidad sólo por ser de
> rol. Si estoy metiendo la pata, por favor, corregidme (quiero aprender a
> programar).

No sé a qué te refieres con la "salida"... si por "salida" te refieres a 
"salida por pantalla", la portabilidad "puede" ser complicada si no utilizas 
librerías independientes de plataforma. Por ejemplo:

Para un juego, diseñado inicialmente para Windows: interfaz de usuario OpenGL: 
portabilidad sencilla; interfaz de usuario DirectX: la cagaste. Lo mismo pasa 
con aplicaciones de ventanas, si las desarrollas con MFC, o ventantas nativas 
de Win, pues vas a tener más complicada la portabilidad, que si utilizas 
wxWidgets, GTK o QT.

De todas maneras, al utilizar este tipo de toolkits, básicamente te aseguras 
que el código se puede compilar, sin tener que cambiarlo, en diferentes 
plataformas. Si el diseño de la arquitectura es bueno, resulta relativamente 
sencillo utilizar librerías nativas de cada sistema, sin ningún problema (oh, 
bendita orientación a objetos, y sus clases abstractas e interfaces), te lo 
digo por experiencia. Lo único necesario es separar bien, en clases 
diferentes, todo aquello dependiente de plataforma, y realizar una 
implementación de dicha clase para cada plataforma. Hay muchas maneras de 
hacer esto, cada una con sus ventajas y desventajas. A mí me gusta la de 
tener una clase abstracta, y luego, derivadas. Un ejemplo típico es el de los 
temporizadores, ya que las funciones necesarias para obtener tiempos en 
Windows y en Linux son distintas. Lo único que habría que hacer sería:

Clase Timer
^
|- Clase TimerWin32
|- Clase TimerGNULniux

La aplicación trabajará siempre con punteros a la clase padre, pero a la hora 
de instanciar objetos, en cada plataforma se instanciarán unos u otros (esto 
se puede definir a través de macros, con factorías de objetos, etc.).

La otra solución, que a mí no me gusta mucho, porque me parece menos elegante, 
es tener una implementación de la clase Timer (en este ejemplo) para cada 
plataforma, y bien usando directivas de preprocesador, bien incluyendo unos u 
otros ficheros en el proyecto, para cada plataforma compilas su 
correspondiente clase. Digo que esta no me gusta mucho porque, con la 
anterior, si te lo curras, puedes incluso elegir, en tiempo de ejecución, y 
para una misma plataforma, entre diferentes implementaciones (es lo típico de 
los juegos que te dejaban usar render DirectX u OpenGL).

Pues eso, no sé si he respondido a tu pregunta, ni tan siquiera si se entiende 
lo que he puesto, jeje.

Un abrazo:

	Bdk

-- 
---------------------------------------------------------------------------
| Jorge García Ochoa de Aspuru                                            |
| e-mail: bardok en telefonica.net - shadow en bardok.net                       |
| URL:    http://www.bardok.net                                           |
| Host: Linux Bdk-Pc 2.6.12 #7 Wed Sep 14 00:21:27 CEST 2005 i686         |
---------------------------------------------------------------------------
| I Used To Be A Bird Of Prey                                             |
| Crying To Be Heard                                                      |
| A Heavy Heart                                                           |
| Carrying The Weight Of Sorrow                                           |
|   - Ark, "Ressurection"                                                 |
---------------------------------------------------------------------------


Más información sobre la lista de distribución eside-ghost