Hola estoy liado con la potencia de 2 por culpa de las texturas, mi problema es que no se si la pequeña rutina para calcular la potencia de 2 de un numero es lo mas optima posible:

Código [Seleccionar] Expand


int numero = 510;
int numeroPow2 = 2;
while( numeroPow2 < numero )
{
   numeroPow2 <<= 1;
}

¿Que os parece? hay algo mejor por ahi, tener en cuenta que las texturas no suelen ser muy grandes con lo que por ejemplo para 512 hace 9 pasos nada mas.

Yo en vez de por tipo lo pondria por fecha, poniendo un campo fecha que indicara cuando pasar la itv, mas que nada por si acaso hay casos especiales. No obstante estas poniendo un ejercicio en el que indicas que por "webs" hay que saber el tipo de vehiculo que se quiere mostrar, con un ejercicio en el que se haga una busqueda por tipo de vehiculo ya tienes el campo tipo de vehiculo obligado, de hay que a mi me guste poner funcionalidad extra tipo getType aunque yo no vaya a usarla, yo es que realmente no veo el problema en tener getType y no usarlo y/o tener funciones virtuales vacias :?

Editado: Pero date cuenta que realizar una busqueda por tipo no tiene nada que ver con la poo.

Estaría bien que los detractores del GetType explicasen cómo se haría para seleccionar aquellos objetos que nos interesan, por ejemplo para mostrar las imágenes o sacar una media de precios de un determinado tipo de vehiculo, o ver un listado de las características de los vehículos sin que me diga que el maletero de una moto mide cero metros.

Aun mejor, veamos si eres capaz de meter en la misma tabla de la base de datos para un tipo de vehiculos los centimetros del maletero y para otros no, la solucion a este problema (si se quieren meter varios tipos de vehiculos en la misma tabla como es el caso) es un campo en el que se indican las propiedades del vehiculo.
Ademas las consultas tipo listado en la bases de datos se hacen mediante controles tipo rejilla, que tenga o no centimetros de maletero la columna de centimetros del maletero estara ahi.
Creo que has buscado un mal ejemplo :wink:

Por mi experiencia en la empresa que estoy ahora y leyendo lo que dicen de ella en trabajobasura..., creo que lamentablemente lo que se dice de virtualtoys es cierto, aparte conozco gente que estubo por alli.
Cada dia me mentalizo mas de que en las empresas de juegos al principio todo pinta muy bonito, pero luego poco a poco descubres la cruda realidad.

Este hilo es la caña jeje, sigo pensando que los dos bandos teneis razon a vuestra manera, ejemplo: si juntamos churros con merinas (o como decis algunos por aqui) el gettype es necesario, pero no por ello el usar funciones virtuales vacias esta mal, ya que como se ha dicho si el objetivo del ejercicio es mostrar en pantalla los valores se podria hacer una funcion virutal pura en la clase base que fuera pintar datos de la de clase.
He estado mirando codigo de la libreria multiplataforma que tengo ya que yo me acordaba de que en algun sitio tenia funciones virtuales vacias, es en la clase Texture de direct3d9, el motivo es que para opengl me hacia falta un par de eventos cuando se cambia la calidad de la textura, pero en direct3d9 no me hace falta, no obstante son dos funciones (eventos) que tienen algo en comun, que es algo totalmente diferente a tener una funcion virtual preguntando si un coche tiene manillar.
En definitiva creo que la base de la programacion orientada a objetos es que las clases bases desconocen a sus hijas y segun se van creando clases hijas las bases las desconocen aun mas, ademas cuando una clase base es creada y dada por finiquitada nunca mas se vuelve a tocar con lo que si se agrega un nuevo vehiculo preguntando si tiene alas al tocar la clase base estariamos rompiendo con esta filosofia (que no tiene por que ser la correcta tampoco :wink:)

Un claro ejemplo de juntar churros con merinas es meter los enemigos en la misma lista que los jugadores, si se hace esto no queda mas remedio que usar gettytpe, en cambio la forma correcta es poner una lista de enemigos y otra de jugadores. (Aunque si nos ponemos tontos podemos hacer una clase base que sepa controlar enemigos y jugadores sin gettype, es solo para un ejemplo).
Si se tiene una lista de enemigos individual se podran sacar funciones y eventos comunes para ellos y como es logico algun enemigo puede tener un evento vacio ya que puede que no tenga que hacer nada en ese caso, por ejemplo: un enemigo tiene movimiento y otro siempre esta estatico, en el evento de OnMove uno tendria codigo y el otro no, es decir, uno tiene la funcion virtual con codigo y el otro sin nada.
Ya para terminar, lo que quiero decir es que gettype se usa en casos muy raros y la mayoria de las veces por un mal plateamiento y las funciones virtuales vacias estan bien, pero siempre y cuando sean cosas comunes para las clases hijas, por lo menos es mi forma de ver la poo.

Preguntar que cilindrada tiene un vehiculo es romper con la POO

Efectivamente, es lo que se lleva intentando explicar desde unas cuantas paginas, como dije anteriormente en este caso no queda mas "webs" que saber que tipo de objeto se esta tratando, pero este caso es imposible de encontrar en un proyecto real, sobre todo si tienes via libre para hacerlo como tu quieras.
Creo que el hilo no va a evolucionar mucho mas ya que ambos bandos tienen razon, por lo menos desde mi punto de vista, ademas si vierais el codigo final con el que se trabaja en una empresa no le dariais mucha importancia a esto :lol:

Si lo se, por eso digo que he tenido suerte al librarme del proyecto, ademas mi idea de venir a una empresa de madrid como programador de juegos, es sacar los maximos posibles y engordar mi cv con ellos, por el momento ya tengo dos y el tercero le tocara en breves. Lamentablemente el motor actual tiene muchos fallos y carencias y me esta tocando a mi arreglarlo y/o actualizarlo, faenas de la vida :?

3) le pregunto a zuper: finalmente, ¿por cuál os habéis decidido? ¿3DGS o TGE?

Pues si te digo la verdad no lo se, ya que me he librado del proyecto por los pelos jeje, me parece que tienen como idea hacer un motor 3d desde cero. A mi por el momento me sigue tocando actualizar el supermotor viejo que hace aguas por todas partes :lol:

Para solucionar el caso que indicais en el que una funcion puede ser llamada desde diferentes controles es que en los eventos de cada control se llama a esa funcion comun, la funcion solo puede tener cosas en comun que tienen los controles, los demas cambios se producen en los eventos de cada control.

Como no se muy bien lo que quieres hacer, lo unico que te puede decir es que vayas memorizando los valores en una tabla hash por ejemplo, usando el nombre del valor como indice, luego pasale la tabla hash con los valores al objeto y que el se organice como quiera, no obstante para crear los controles no te queda mas remedio que hacerlo con ifs o mediante una tabla hash (otra vez por ejemplo) con punteros a funciones, si todos los objetos derivan de la misma clase puedes hacer una funcion que retorne el objeto creado ya que puedes tener en la clase base una funcion virtual que tenga como parametro la tabla hash entre otras cosas claro, algo asi:

Código [Seleccionar] Expand


class Base
{
public:
   virtual bool Inicializar( TablaHash* valores ) = 0;
}
class Boton : public Base
{
public:
   bool Inicializar( TablaHash* valores )
   {
       this->padre = valores.getctrlbase("padre");
       this->colorBoton = valores.getint("colorboton");
       this->coordenadas = valores.getcaja("coordenadas");
       ...
       return true;
   }
}

// Funcion que crea el control
Base* CrearControl( const char* tipo, TablaHash* valores )
{
       if( tipo == "boton" )
       {
           return (Base*)new Boton( valores );
       }
       return NULL;
}

Como en XML puede que no se especifiquen todos los valores puedes hacer que la funcion de la tablahash getint por ejemplo permita especificar un valor por defecto, algo asi:

Código [Seleccionar] Expand


colorpordefecto = 0xFF
this->colorBoton = valores.getint("colorboton", colorpordefecto);

Asi te ahorras tener que mirar si el valor existe o no, ya que lo hace la propia funcion dentro.

Editado: Queda dado de si que la tablahash no es una tablahash normal y corriente, puedes tener una clase tablahash y luego deriva otra para hacer las funciones especiales de obtener valores. Tambien deberias hacer una clase base para memorizar dentro de esta tablahash todos los tipos de valores que existan, date cuenta que solo el control sabe como manejarlos, es decir, el "colorboton" siempre va a ser un int, el "padre va a ser un control "base", etc.

Código [Seleccionar] Expand


class Item
{
public:
}
class ItemInt : public Item
{
public:
   int valor;
}
class ItemBase : public Item
{
public:
   Base* base;
}
class HashTableXML : public HashTable<Item*>
{
public:
   ...
   int getint( const char* id )
   {
       // obtener el puntero al elemento
       Item* item = ...
       // Retornarlo
       return ((ItemInt*)item)->valor;
   }
   ...
}

Otra forma es usar una tabla hash normal y corriente y que retorne siempre strings o el puntero al valor directamente y luego hacer una conversion a "int" para la getint, para el caso del control "base" (funcion getctrlbase) puedes hacer que retorne su nombre o su direccion en memoria en formato string (si siempre retornas un string) y luego hacer la conversion, pero esto ya es cuestion de gustos :wink:
Puede que el sistema de Item sea mas lioso al principio, pero al final si algun dia tienes que meter alguna funcionalidad extra por cada valor no tendrias que cambiar nada, por ejemplo, que mire en el registro de windows si ya existe un valor para el control.

Código [Seleccionar] Expand


class Item
{
public:
   bool verRegWin;
};

Asi agregarias la funcionalidad sin tener que tocar apenas codigo, exceptuando claro en las funciones de obtener los valores para ver si es true o false este valor.

Editado 2: Releyendo todo me he dado cuenta que lo mejor es que la tablahash memorize un objeto como este:

Código [Seleccionar] Expand


class Item
{
public:
   const char* valor;
   bool verRegWin; // Este bool es un ejemplo por poner algo
};
class HashTableXML : public HashTable<Item*>
{
public:
   int getint( const char* id )
   {
       // Obtener item
       Item *item = ...
       // Retornarlo
       return atoi(item->valor);
};

El motivo es sencillo, si quieres automatizar la lectura del xml tiene que ser todo strings ya que si no tendrias que andar creando otra estructura para automatizar el tipo de dato por su nombre.
PD: No borro el sistema anterior por si a alguien le ayuda en algo.

Editado 3: Para casos en el que un control puede tener elementos con nombres de valores iguales, haz que si existe el valor ya en la tablahash le agrega un numero correlativo, algo asi:

Código [Seleccionar] Expand


<ctrl tipo="lista">
   <item nombre="pepe">
   <item nombre"=luis">
</ctrl>

En la tabla hash quedaria algo asi:

Código [Seleccionar] Expand


lista0.nombre0 = pepe
lista0.nombre1 = luis

Ademas asi te aseguras que el control cuando se inicializa no coja valores erroneos si esta mal hecho el xml.
Despues para obtener esos valores lo puedes hacer con un simple while:

Código [Seleccionar] Expand


class Boton : public Base
{
public:
   bool Inicializar( TablaHash* valores )
   {
       this->padre = valores.getctrlbase("boton0.padre0");
       this->colorBoton = valores.getint("boton0.colorboton0");
       this->coordenadas = valores.getcaja("boton0.coordenadas0");
       char sz[256] = "boton0.nombre0";
       int n = 0;
       while( valores.tiene(sz) )
       {
           this->agregarElemento( valores.getstr(sz) );
           n++;
           sprintf( sz, "boton0.nombre%i", n );
       }
       ...
       return true;
   }
}

El while es un ejemplo, pero podria optimizarse por ejemplo que la funcion valores.getstr retornara true o false si el valor existe y que devolviera el valor en un puntero a string que le pasaras a la funcion, pero eso ya es cuestion de gustos.
Si quieres para optimizar al agregar valores a la tabla hash le puedes pasar una clave, por ejemplo, para el "nombre", su clave seria "nombre" y la propia tablahash va incrementando el valor en 1 cada vez que se use esa clave, el motivo de esto es que si no te tocaria mirar si existe "nombre0", "nombre1", "nombre2", etc. hasta encontrar el que no existe.

Editado 4: Tios me piro pa la piltra :shock:

Editado 5: Como veo que al final si metes el problema de la lista te recomiendo usar el sistema clasico, una jerarquia de nodos, algo asi:

Código [Seleccionar] Expand


class Nodo
{
public:
   const char* indice;
   const char* valor;
   Nodo* siguiente;
   Nodo* primerHijo;
   Nodo* padre;

   const char* obtenervalor( Nodo* buscarDesde, const char* indice )
   {
       // Buscar nodo
       Nodo* nodo = ...
       // Retornar valor
       return nodo->valor;
   }
}

Ahora si que me voy pa la pilta que ya estoy desvariando demasiado :?

En mi opinion creo que se esta debatiendo algo absurdo, ya que aunque yo defiendo el tipo de funciones getType como una funcionalidad extra, en toda la libreria multiplataforma que monte no la uso, el motivo es muy sencillo, no me he encontrado ningun caso en el que me haga falta, es mas en las propiedades del visual studio tengo desactivado el RTTI.
El otro dia pensando como meter ogl 1.1 pense en hacer funciones virtuales vacias que retornen NULL y en debug produzcan una ruptura del programa cuando se intenta crear por ejemplo un pixel o vertex shader ya que en la version de ogl 1.1 no se pueden crear (el motivo es para poder renderizar igualmente sprites 2d con la clase sprite desde ogl 1.1), con lo que aunque defiendo el getType siempre lo intento usar lo menos posible, no obstante creo que para el problema que indica el primer post del hilo no queda mas remedio, ya que mete todo en un mismo vector, otra posibilidad al getType para este problema es crear una funcion virtual en la clase base que permita obtener propiedades mediante un string o un identificador numerico (algo asi como la clasica funcion de mensajes que se usaba en c), como veis hay mas soluciones, no existe una mejor o peor, es solo cuestion de como se programe o nos guste programar o nos digan como debemos hacerlo :wink:
Creo que el caso que se expone aqui es algo imposible de encontrarse (por lo menos en la vida laboral, en la de estudiante puede), referente a los GUI normalmente se soluciona todo mediante eventos, el evento lo recibe el propio control, con lo que en el evento de ese control ya se sabe que tipo de control es y sabemos lo que queremos hacer.

Yo tambien lei varios hilos donde ponias imagenes y la verdad es que ya me gustaba antes, pero cada vez le pones mas calidad al juego y si que entra ganas de verlo funcionando :!:

Editado: Solo un apunte que creo que te puede gustar, viendo el video otra vez, durante la muerte del guerrero estaria bien que en vez de desaparecer despues de ver la animacion de que ha muerto se lo tragara la tierra, es decir, la malla bajara verticalmente, creo que quedaria mas bonito.

Otra cosa, ¿tienes soporte para multijugador por red? por que de ser asi, puede que me eche unas cuantas partidas con algunos amigos :D

Me estas diciendo que los compiladores de c solo compilan lo que utilizas en vez de todo el codigo?? Bueno saberlo :)

P.D: Actualmente no estdio c en la uni, sino component pascal y java.

Es lo que hacen y yo lo uso para optimizar muchas cosas, sobre todo las funciones virtuales, por ejemplo, tienes una clase base abstracta y dos derivadas que son para renderizar en ogl y d3d, si compilas las dos en el ejecutable las funciones virtuales seguiran siendolo teniendo que resolverse las llamadas a ellas en tiempo de ejecucion, ahora si compilas solo la del ogl o d3d el compilador resolvera en tiempo de compilacion las funciones virtuales con la consiguiente ganancia de velocidad.

Efectivamente en java no existe esta ventaja :( , no obstante tienes algunos ofuscadores que eliminan el codigo que no va a ser usado ahorrando espacio en el jar final :D, aunque no se exactamente si la eliminacion es por funciones y clases o solo por clases.

pero como dice mi profesor de universidad "hay que evitar usar codigo muerto", es decir, codigo que no se va a usar. El getType hay que ponerlo cuando se necesita, no por costumbre.

Pues sin querer ofender, pero no se decirlo de mejor manera... tu porofesor no sabe de lo que habla, ya que si la funcion getType existe, pero no se usa, esta funcion no existira en el ejecutable final, mientras mas funcionalidad mejor y si no se usa no pasa nada, esta es una de las mejores cosas que tienen los compiladores de c/c++.

Ya han censurado parte de los informativos y solo se muestra lo que ellos quieren, ahora llega la hora a internet, la izquierda es mas facha que nunca.

http://www.internautas.org/html/4037.html