Un poco tarde, pero comento algo interesante (y básico): las coordenadas homogéneas.

Como en gráficos utilizamos matrices de 4x4 también necesitaremos vectores de 4 elementos para poder multiplicar (4x1 ó 1x4), de la forma (x, y, z, w)

Para verlo en 3d hay que proyectarlo dividiendo cada elemento por la w.

Así a groso modo:
- cuando w es igual a 0, el vector equivale a (x, y, z)
- cuando es 1, es lo mismo que el punto (x, y, z)
- cuando es distinto, equivale al punto (x/w, y/w, z/w)

Así que cuando pones una luz acabada en 0, estás haciendo una luz direcciona, y cuando es distinto, puntual.

Sobre el warning, fíjate en el #include"E_Matrices.cpp".

Realmente te está diciendo que el método what de E_Matrices no siempre devuelve un valor.

Según donde declares el objeto o como instancies la clase, se reservará memoria en el heap, en el stack o en el segmento de datos (new/malloc, variables locales, variables globales). La pila y el segmento de datos tienen máximos con los que no es bueno jugar, por si cambiamos de arquitectura y la cosa deja de ir. El máximo que puedas reservar en el heap dependrá de la RAM que tengas libre y de lo fragmentada que esté.

De todas formas esa clase madre de la que hablas, pues no debería de ser más que un conjunto de punteros a los diferentes subsistemas de los que contará tu juego (lógica, vídeo, audio, ...) y un puñado de métodos. Así que no tendría que ocupar ni unos centenares de bytes de esos que te preocupan tanto.

Una forma de hacerlo sería consultar el estado del teclado con SDL_GetKeyState (http://www.libsdl.org/cgi/docwiki.cgi/SDL_GetKeyState)

Y tu código cambiaría a algo similar a:

Código (c) [Seleccionar] Expand

keys = SDL_GetKeyState(NULL);
...
if(keys[SDLK_UP])
{
   posy-= 10;
   orientacion = norte;
}


Si no llamas a la función Teclado un número de veces fijo por segundo, deberías cambiar ese 10 que tienes ahí para que el movimiento sea fluido e igual en todas las máquinas.


A parte, deberías cambiar el if por un while al llamar a SDL_PollEvent, porque es posible que si llegan más de un evento por frame se procesen los eventos más tarde de lo que toca o en el caso peor, que no se procesen nunca.


Como opinión subjetiva, si es en C++, te sugiero encapsular las posiciones en una clase sobrecargando los operadores para facilitarte la vida.

Si te suscribes al Creators Club, podrás probar directamente en la xbox360 nuestra entrada para el concurso "tú también puedes" :P

Y si no, espero que tengas un mando de xbox usb, que xna no soporta otros mandos. Ya si me sobra tiempo le meteré algo con DirectInput en la parte PC.

 Hola,

dibujando de "alanteatrás" realizamos el mismo número de comprobaciones con el z-buffer, pero escribiremos menos veces, ya que los objetos que están más lejos de la cámara posiblemente estén bloqueados por algún objeto que ya hayamos dibujado. El caso pero sería dibujarlos de atrás-adelante ya que seguro que todos los píxels de todos los objetos se van a dibujar aunque luego estén bloqueados (bueno, realmente no todos, pero sí muchos).

Si has leído en algún sitio sobre el motor de Carmack para el Doom III, verás que el primer paso que hace es escribir en el Z-buffer sin ningún tipo de información de iluminación, y de alante a atrás (¿alguna sugerencia de cómo escribirlo?). Luego ya hace los pasos necesarios por cada fuente de luz, pero el z-buffer ya no será modificado. Lo que no sé muy bien es cómo manejará las transparencias o cómo lo harán los tipos del Half-Life 2 para conseguir esas refracciones.

Tendremos que modificar nuestros motores gráficos, aunque seguro que muchos ya lo hacíais.

Un saludo.