Pues si tan asqueroso esta el panorama... solo hay dos opciones: irte al extranjero o dejar la informatica como hobbie y hacerte fontanero/electricista/... que se cobra mejor.

Yo opto por la primera.

¿Y no se podria usar el tiempo que esta la GPU trabajando para cargar los datos?
Todavia no se bien como funciona este aspecto del renderizado, es decir, que no se si mientras la GPU trabaja, el proceso que le da las ordenes se queda bloqueado o esperando o que.
A ver si alguien arroja algo de luz sobre mis dudas :D

Pues se le llama construccion de software, y tienes tantas metodologias que no vas a terminarlas de estudiar todas :P

Personalmente, creo que para hacer un videojuego hay que tirar por metodos evolutivos, algo como lo que ha comentado EJSainz. La peculiaridad de los videojuegos que no tienen otras aplicaciones es que suelen estar al borde de la tecnologia, para tener un producto que destaque por graficos, IA, etc. y para que funcione en la mayor parte de maquinas.
Este es un requerimiento importantisimo, puesto que la tecnologia cambia tan rapidamente, que siguiendo una metodologia ortodoxa terminarias con un producto viejo en cuanto saliese al mercado.

Claro que siempre puedes hacer algo que no vaya hasta los limites del hardware actual, o especular sobre la capacidad del hardware a 2 o 3 años vista y adaptarte a ello. Pero creo que se puede hacer mucho mas facil sacando pequeñas releases y rediseñando.

Si quieres mirar algo sobre metodologias, puedes echarle un vistazo a Agile Development. Desde ahi tienes links a otras metodologias.
De todos modos, deberias tener presente que una metodologia no es algo que haya que seguir al pie de la letra. Influyen muchos factores tales como tamaño del equipo, preparacion de los individuos, experiencia, tipo de producto y un largo etcetera. Eso no te lo enseñan en la universidad ;)
Asi que lo que tienes que hacer es adaptar la metodologia a las capacidades/necesidades de tu equipo/proyecto y no al reves.

La creacion de webs ha cambiado bastante, aunque mucha gente aun sigue en la edad antigua, pero bueno.

Lo mas sencillo es tirar de DIVs y CSS para el layout de la pagina. El DIV tiene una propiedad genial llamada innerHTML, asi que con javascript es muy sencillo cargar un .html dentro de un DIV, con lo que te ahorras recargar la pagina entera (mirate el AJAX, gmail creo que lo utiliza, al menos la idea es la misma).

Puedes maquetar lo que dices de tener dos frames con un par de DIVs, uno para el menu y otro para el contenido. Una opcion del menu simplemente cambia el innerHTML del DIV de contenido. El JavaScript lo puedes generar dinamicamente con ASP.

[buen]

Pues eso, con la reciente adquisicion de mi nuevo reproductor mp3, he visto que solo se basa en el tag ID3 del archivo para organizar la libreria, con lo que o bien me hago playlists a saco (ya las tengo) o me pongo a renombrar/editar todos mis ficheros mp3.
Asi que lo que busco es un editor de ID3 para cambiar facilmente los tags, pero no puede ser uno cualquiera, deberia tener estas caracteristicas (a grandes rasgos):
- Editar varios ficheros a la vez para cambiar uno o varios campos del ID3, p.e. seleccionar los mp3 de un disco y decirle "esto es tal grupo y tal disco".
- Pasarle un fichero con los titulos y que lo rellene en base a un patron que le indique yo, p.e 'autor - numero pista - titulo'.
- Cambiar el nombre del fichero en base al tag o viceversa, rellenar el tag con lo que pone en el nombre del fichero (dandole un patron a seguir).

En definitiva, busco un buen editor ID3. Antes que programarlo yo mismo prefiero saber si ya existe, que no me extrañaria (por lo de no reinventar la rueda y eso). Creo que todos nosotros hemos deseado un programa asi alguna vez, asi que tiene que existir!

Finalmente he visto que es mejor el ZEN MicroPhoto. En pixmania tienen la version de 4 Gb por 140€ (9% dto) y la de 8 Gb por 205€ (22% dto).
Ahora estoy en un debate interno sobre cual de las dos opciones escoger. Por un lado creo que deberia aprovechar el 22% de descuento, ya que por 65€ mas tengo el doble de capacidad, que nunca viene mal para guardar datos (transporte de pelis p.e.) o mas musica. Por otro lado, en principio no habia pensado tener mas de 4Gb, que considero que es una cantidad suficiente, y de paso me ahorro una pasta, que tampoco es que me sobre. Sinceramente me compraria el de 8Gb con prevision de futuro, pero me pica pasar de los 200€.

A ver si alguien me ayuda a decidir entre las dos versiones. Esta semana me lo pillo en el showroom de bcn.

He mirado el iPod Nano y vale 250 euros el de 4Gb, frente a los 200 (150 en fnac) del ZEN Micro.
Supongo que el iPod tambien va de lujo, pero yo solo quiero un reproductor mp3. Lo de las fotos y esas mariconadas tipicas de iPod me la soplan, por eso creo que no me compensan los 100 euros extras. No creo que gane tanto mas en calidad (ademas en la web no he encontrado las especificaciones tecnicas...).
Lo que si me jode es que el ZEN pesa mas del doble que el iPod, pero weno, son 100 euros menos (y si, pasa la barrera entre valer mas dinero y ser mas caro :twisted: )

Ah, lo del SAT es en parte culpa mia, pues no encuentro el resguardo de haber enviado el paquete (a ver si lo encuentro esta semana, ¿puedo pedirlo a correos?).

Primero una breve introduccion para poneros en el tema. Hasta hace pocos meses tenia un Creative MuVo 1Gb. La calidad del reproductor me dejo bastante satisfecho, tanto auriculares (que aun conservo) como el propio reproductor. Lo que pasa es que se apagaba de repente cuando le apetecia, asi que lo envie al servicio tecnico y ahi me lo perdieron los muy cabrones. Total, que me sale mas a cuenta comprar uno nuevo que pelearme con ellos para no conseguir nada.

Aqui os pongo una lista de mis preferencias a la hora de buscar, ordenadas de mayor a menor importancia:
- Buena calidad de sonido, al menos como el MuVo.
- Larga duracion de la bateria, a poder ser recargable.
- Minimo 1Gb de memoria (preferiblemente a partir de 2-3Gb).
- Bajo peso (que no me haga ladearme cuando camine con el...).
- Que salga informacion clara en el display (hay reproductores realmente malos en ese aspecto, y jode mucho).
- Precio: no mas de 180-200 euros.

Con esto en mente y viendo que Creative, a parte de en SAT, son decentes en calidad/precio, he visto que el ZEN Micro esta bastante bien, sobre todo en esta oferta de Fnac.
Mis preguntas son: ¿lo habeis probado alguien? ¿que opinion teneis de el? ¿alguna sugerencia mejor? (podeis variar un poco mis preferencias, estoy abierto a sugerencias).

[doble]

La gracia del punto flotante es que la precision es mayor cerca del 0 y menor cuanto mas te alejas, con lo que trabajamos con errores relativos de precision, es decir, que una milesima te importa mucho si trabajas con valores pequeños y te da igual si trabajas con millones.

Si estais haciendo un programa cientifico, p.e. un visor 3d de un cuerpo, puede interesarte ir desde una escala de 2m (cuerpo completo) a una de micrometros, con lo que la precision es muy importante (tema de redondeos, acordaos de lo de 35.55 = 35.549999) y pueden ser necesarios los 64bits.

El tema de usar float extensivamente es por lo que ya han dicho: suficiente precision para gran numero de aplicaciones, mayoria de micros de 32bits y sobre todo que es el doble de tamaño. De hecho, en OpenGL se nota mucho usar indices de 32 a 16 bits. Probadlo.
Y los half float simplemente son 16bits en vez de 32. Osea, suficiente precision para algunas cosas y la mitad de tamaño. En deferred shading o hdr y estas cosas, creo que se usa bastante para ahorrar espacio en los g-buffers.

 Bueno, ahora que esta tan de moda el tema casual gaming y el mercado shareware para los grupos independientes os propongo unas preguntas para ver que opinais, mirando de favorecer el exito del proyecto.

¿Que tematicas creeis que son mas apropiadas para juegos shareware? ¿Deberian estar enfocados a los casual gamers o es inependiente de que sean shareware?

Tras ver el exito que han tenido juegos como Tribal Trouble, he pensado que muchas veces el exito viene dado por el aspecto gracioso del juego. Pensando en hacer un juego de esta indole junto con varias personas, estabamos barajando varios tipos de argumentos para el juego. En mi opinion el humor es un factor clave a la hora de diseñar el concepto del juego y la historia, ya que al menos le da un aliciente para no resultar aburrido.

¿Que generos de juegos pensais que se benefician mas de esta caracteristica?

 Hmmm, creo que tienes varios fallos de diseño.

Dices que el BulletMgr esta enlazado a una nave. ¿Que sentido tiene que sea una entidad a parte? ¿porque no forma parte directamente de la nave (agregado) y le llamas Gun? Por lo que dices que hace tiene mucha mas logica (solo interacciona con una instancia de SpaceShip y no con cualquiera). De ese modo, podrias tener una interfaz basica para armas, y usando polimorfismo puedes tener varios tipos de armas. Algo asi:


Para hacerlo mas realista, cada arma puede tener una cache con un maximo de balas que puede disparar, algo asi como el cargador; lo cual actuara como limite de la cache de balas. Si quieres balas infinitas, con que le pongas 1000 ya te valdra de sobras, no creo que una misma arma pueda disparar 1000 veces sin que ninguna otra bala impacte o se salga de la pantalla.
Para la gestion de las balas libres, te propongo tener un array de enteros con las posiciones del cargador libres. Inicialmente ese array esta lleno con los numeros [0..MAX_BULLETS-1], y cada vez que crees una bala, coges el ultimo indice y lo usas para la nueva instancia. Cuando muere una bala, añades su indice al final de la lista (pop_back, push_back).
Si por lo que sea te quedas sin balas, tienes dos opciones: [1] argumentar que hay que recargar el arma o [2] usas new/delete para las balas 'extra', ya que seran casos remotos para un MAX_BULLETS suficientemente grande (siempre puedes actualizar esa constante en el fichero de configuracion para posteriores ejecuciones, un poco de tweaking automatico no viene mal ;) ).

Para el tema colisiones, yo tendria un evento en la clase SpaceShip que indica que han impactado, y le pasas la bala que lo ha hecho. Puedes tener un gestor de colisiones que sabe donde estan todas las naves de la pantalla en ese momento, o que se lo pregunte al gestor de naves (ahi si seria interesante tener un gestor). Le pasas una bala y le indicas que notifique a las naves a las que ha impactado.

Bueno, creo que no me dejo nada. Espero que te sirva de ayuda :)

 Creo que me he colado un poco con lo del prototype, al final acabas haciendo un new y pasandole una referencia al componente grafico, que es el que compartes. De todos modos ya habeis dicho una manera de solucionarlo, usando una especie de cache de disparos para reutilizar los que te sobran en vez de hacer un delete (hay varias soluciones).

josette, el BulletMgr que gestiona? balas en general o las balas del jugador? creo que no es necesario hacer esa distincion (desde el punto de vista del gestor). De todos modos sigo pensando que no necesitas un gestor de balas (KISS).

 Mirate el patron Prototype para instanciar las balas (no querras hacer un new/delete cada vez que dispares). Simplemente necesitas el mismo grafico pero cambiando la posicion en cada instancia.

El gestor de balas (no creo que haga falta un gestor para algo asi) podria ir tranquilamente como singleton dentro de algun namespace para tener las cosas mas organizadas. Pero repito que no creo que necesites un gestor de balas, simplemente el propio gestor de recursos te da la bala y ya esta, se trata como otra entidad movil y colisionable mas.

 Es como decir que la pornografia pervierte a los menores, ¿no? Que les hace meter el puño hasta el codo a las muñecas de sus amiguitas en el cole en vez de simplemente arrancarles la cabeza como se ha hecho siempre (como se nota que los juegos violentos han pervertido mi mente :ph34r: ).

De todos modos sigue siendo un tema complicado el de la culpabilidad. Si un chaval quiere obtener algo para mayores de edad (porno, juegos violentos, drogas) lo va a hacer igualmente. Aunque claro que eso no quita que haya una irresponsabilidad generalizada por parte de padres y suministradores de ocio adulto.

 Hombre, no esta mal el articulo, aunque tocas temas que ya existian con la FFP. La ordenacion por material siempre se ha tenido en cuenta (o al menos ha estado ahi).
Al final lo que te queda, mas que un shader, es un material abstracto con sus parametros y su guion de ejecucion (el shader en si). Necesitas una interfaz para cambiar dichos parametros, un metodo de ordenacion, etc... Vamos, como en la FFP (sin entrar en temas de programacion, ¿eh?) :)

Sobre el apartado de Los shaders y la geometria, hay cosas que me gustaria comentar.
El caso ese de la esfera - que por cierto, dices que el culling rechaza la esfera, el shader la agranda y entonces se sale del frustum; no tiene mucho sentido, ¿no? - seria algo especial, puesto que si aplicas displacement mapping o algun efecto con geometry shaders (habra que empezar a tenerlos en cuenta :S ) tendrias que usar un hull o algo parecido para marcar el posible volumen de efecto del shader, igual que se hace cuando calculas los shadow casters para cada luz. De ese modo podriamos estar seguros de que si rechazamos un renderable no va a afectar al resultado final del frame.
Sobre lo del tone mapping, tendriamos que distinguir entre shaders de materiales y shaders de post-produccion. Ni se aplican igual ni en la misma fase de renderizado. Tambien habriamos de mirar el soporte para deferred shading, que es otro tema a tener en cuenta.
Cuando comentas lo del volumen de impacto en la luz omni, eso no tiene que ver con la integracion de shaders. Es mas de culling que de otra cosa, y nos podemos referir a lo mismo que he dicho sobre el caso de la esfera.

Concluyendo:
- Abstraer el concepto de material desde la FFP y los shaders, ya que comparten muchas caracteristicas (parametros, cambios de estado, ordenacion).
- Contemplar que la geometria que procesamos en la CPU puede ser diferente que la de la GPU (displacement mapping, geom. shaders).
- Diferenciar entre tipos de efectos, si son para renderizables (materiales) o post-produccion (¿donde iria el deferred shading?).


PD: si me permites un consejo, escribe mas en la seccion de conclusiones.