Que tonto, no se me había ocurrido. Gracias.

La verdad es que nunca se mehabria ocurrido que pudiera ser eso. Suponía que hoy en día esa limitación sería bastante alta... Yo estoy haciendo llamadas de 1000-6000 vértices

Buenas

Sigo peleándome con direct3d9.

El caso es que tengo implementada la función DRAW_Trapezoid() de dx_lib32 mediante indexbuffers, para empaquetar todas las llamadas encadenadas en una sola llamada a drawindexedprimitive. En el sobremesa funciona perfectamente, pero cuando lo pruebo en el netbook me salta un bufffer overflow en la llamada a drawindexedprimitive().

Alguna idea?

Muchas gracias

Buenas

Estaba pensando en una manera eficiente de hacer animaciones sencillas para sprites. Basicamente cambiar la textura del sprite una vez por "tick", seleccionando esa textura de la lista de texturas que forman la animación.

Algo así:

Código [Seleccionar] Expand


class AnimatedSprite
{
private:
static void _timerHook();

int _framesCount_1;
Texture _frames[_framesCount_1 + 1];
int _frame;
public:
static const MAXANIMATIONFRAMES = 1000;
void tick();
void draw(GraphicsDevice gfx);
}

void AnimatedSprite::_timerHook()
{
foreach(AnimatedSprite instance : instances)
instance.tick();
}

void AnimatedSprite::tick()
{
if(_frame<_framesCount)
             _frame++;
        else
             _frame=0;
}

void AnimatedSprite::draw(GraphicsDevice gfx)
{
gfx.DrawTexture(_frames[_frame]);
}

(Se supone que es un ejemplo, una especie de C++ en pseudocódigo)
El único detalle es que utiliza el mismo timer para todas las instancias, de manera que la velocidad de la animación sea la misma. Me parecía lo más correcto.

Os parece la mejor manera de implementar animaciones? O usáis alguna forma más eficiente?

PD: También se me había ocurrido una manera para reducir el número de operaciones:

Código [Seleccionar] Expand


class AnimatedSprite
{
private:
static _tickCounter;
static void _timerHook();

int _framesCount_1;
Texture _frames[_framesCount_1 + 1];
int _frame;
public:
static const MAXANIMATIONFRAMES = 1024;
void tick();
void draw(GraphicsDevice gfx);
}

void AnimatedSprite::_timerHook()
{
if(_tickCounter <= MAXANIMATIONFRAMES)
_tickCounter++;
else
_tickCounter = 0;

foreach(AnimatedSprite instance : instances)
instance.tick();
}

void AnimatedSprite::tick()
{
_frame = MAXANIMATIONFRAMES & _framesCount_1
}

void AnimatedSprite::draw(GraphicsDevice gfx)
{
gfx.DrawTexture(_frames[_frame]);
}


Suponiendo que el número de frames de una animación siempre es potencia de dos. (Un poco chorra, lo se, al final es n sumas vs 1 suma y n ands, supongo que en el hardware de hoy en día será imperceptible la diferencia de rendimiento entre una and y una suma)

Estoy estudiando segundo del grado de Ingeniería Informática también en la UCM, y tenía pensado hacer el master de programación de videojuegos.
La verdad es que estoy un poco desanimado, la carrera no me esta enseñando nada... Bien es cierto que yo llevo algunos años ya haciendo mis frikadas (http://www.stratos-ad.com/forums/index.php?topic=15113.msg153953#msg153953, https://github.com/Manu343726), pero habiendo visto lo que he visto durante este tiempo (La optativa de informática gráfica de tercero, por ejemplo. Es de risa), no esperaba mucho del master...

Pero viendo vuestro proyecto, igual me equivoco. No se. El tiempo lo dirá.


Por cierto, que herramienta/framework/API estais usando?

Hace un tiempo leí este artículo en el que se hace una comparativa entre diferentes lenguajes de programación en el campo de la bioinformatica. http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2267699/

Por los resultados que muestra, parece que C# suele consumir menos memoria que JAVA, pero en líneas generales el rendimiento es equivalente.

Pero sinceramente, cuando programas con cosas tipo Java/C# no tienes en mente el rendimiento. Tienes en mente la productividad. Al fin y al cabo, son plataformas que están diseñadas para RAD. Si necesitas estrujar la máquina, usa C o Cpp.

Y es en productividad donde, a día de hoy, todos estamos de acuerdo que .NET framework destaca sobre Java sin lugar a dudas. Sobre el diseño del lenguaje, estoy totalmente de acuerdo con Gorkinovich. Java esta estancado en un modelo de programación de hace casi veinte años, que no se ajusta para nada a las necesidades actuales.

C# ha evolucionado poco a poco, asustándose a los cambios, y sinceramente pienso que esta diseñado con bastante más cabeza que JAVA.

Una preguntita, la cuenta de twitter que acaba de aparecer (https://mobile.twitter.com/Stratos_AD es oficial?

Muchas gracias por los comentarios, lo tendré en cuenta.

Estoy pensando en migrar de direct3d a OpenGL, dado el actual estado de Microsoft, que no hace más que tirar por la ventana todas sus plataformas. Además, esta el tema de la portabilidad, por supuesto.

Mira que en su día cuando empezaste el port de dx_lib32 a C++ te lo dije, pásate directamente a OpenGL, olvídate de DirectX :P

Salu2...

Ya ya, tu ahora restriegamelo por la cara XD. Si en su día hubiera empezado con OpenGL, a estas alturas no tendría absolutamente nada implementado.....
En cambio ahora, por la parte de gráficos, sólo me queda el tema de surfaces/render targets, con el que no me he puesto pro falta de tiempo, más que nada.
En cuanto acabe los exámenes me pondré a hacer un pequeño engine isométrico para renderizar terreno, para mostrar las capacidades que tiene la librería en estos momentos. Y no se me ha olvidado el tema de la "proyección en perspectiva" en cuanto tenga un rato implemento un pequeño ejemplo.

Respecto al resto (input y audio mayormente) la verdad es que no se que hacer. La parte de input ya la tengo cubierta con mi sencillo sistema de ventanas, ( se supone que la clase gráfica esta diseñada para ser utilizada en cualquier sistema de ventanas, véase Qt por ejemplo, de manera que eso es lo de menos). Y la parte de audio no se que utilizar. En su momento me plantee usar XACT, pero visto que como con muchas otras cosas Microsoft lo esta mandando a la mierda, igual aprovecho el paso a OpenGL y utilizo OpenAL.

Que os parece?

Pues no se que decirte. El tema de diseño/arte/guión parece que lo tiene bien cubierto. Pero si lo que te interesa es programación de videojuegos, y más programación de motores de videojuegos (que parece que es a lo que esta orientado) hecho en falta bastante más programación.

Igual me equivoco y luego no es así, pero te lo digo por experiencia: Leer el listado de asignaturas no te sirve de nada. Tienes que mirar los temarios.

Me he bajado la versión para iOS (free) y la verdad es que me ha gustado mucho. Sólo tengo una pega: De vez en cuando, mientras estas en mitad de un juego (aka frenesí liquidatopos) salta un popup publicitario. Este tipo de popups deberían salir al acabar un nivel, o cosas de ese estilo no?

Más que nada porque así es imposible jugar. Los topos siguen entrando/ saliendo y yo tengo la maldita ventanita delante, y en lo que tardo en cerrarla he perdido uno o dos topos.

Buenas

Estoy pensando en migrar de direct3d a OpenGL, dado el actual estado de Microsoft, que no hace más que tirar por la ventana todas sus plataformas. Además, esta el tema de la portabilidad, por supuesto.

Me gustaría que me dierais algún consejo, guía, pdf o lo que sea para cambiar el chip.
Vengo de direct3d9, la fixed function pipeline, y esas historias.

Gracias

Siempre puedes dejar VB y meterte con otro lenguaje, sea C++ o C#. Yo también era de los de "VB VB es lo más!" Pero tras aprender algo más te das cuenta que es una verdadera basura

El mundo se va a la mierda....

Volviendo al tema que nos concierne, joysticks virtuales, no digo que su sola presencia haga que el juego ya sea considerado una mierda. Solo que se debe utilizar como último recurso.

Si es un port de un juego de otra plataforma, entiendo que llegues a la situación en la que te planteas poner un pad virtual. Al fin de al cabo, el juego original usaba un pad, y tu no quieres modificar mucho el juego.

Pero si es un juego planteado desde cero para dispositivos táctiles, eso ya no es así. Si hay un pad/joystick virtual es que hay un error en el planteamiento/diseño del juego, el juego no tiene sentido en esa plataforma, o que no entiendes del todo lo que es jugar con un dispositivo táctil.

Cada cosa tiene una funcionalidad, se diseñó para hacer ciertas cosas. Lo mismo ocurre con las plataformas táctiles. No sirven para todo. Por supuesto, puedes hacer lo que quieras si te pones cabezota. Funcionar funcionara. Pero será un churro.

Si quieres podemos hacer un juego de frisbee, en el que se lanza el móvil volando y mides la fuerza del lanzamiento con el acelerómetro. Pero puede que acabe muy mal....
Por poder puedes hacer lo que te de la gana. Otra cosa es que tenga sentido o sea verdaderamente cómodo. Y no olvidemos que pretendes que la gente pague por lo que estas haciendo.