Segundo Tutorial De Haddd

[Haddd]

 Bueno, ahí va el segundo. Espero que alguien pueda verlo porque parece que los shaders 2.0 no están muy arraigados por estos foros.

Ese enlace

Cargamos un fondo y mostramos un sprite con transparencias animado y moviéndose por la pantalla.

(uoh)  

[BeRSeRKeR]

 Va a unos 380 fps en la Radeon 9600. El primer tutorial me iba a unos 320 fps. La verdad, me parece poco. Volveré a probarlos cuando reinicie el ordenador, que hace más de 1 semana que no lo hago. :)

Saludos.

[Astat]

 600fps mas o menos estables en mi r9600.  En cuanto al codigo del ejemplo, no me gusta demasiado como lo has pensado para el "cliente" (con cliente me refiero al que utilice tu motor).

Y lo que me remata son los nombres de las variables en español!! XDD

[AgeR]

 He actualizado los drivers y me funciona en mi GF4 MX 440 (unos 435 fps).
Se ve el fondo y un sprite dando tumbos por ahí.

Yo metería el tema del input (lo del ratón y tal) dentro de una clase. Daría más claridad al código y quitarías algo de trabajo a los usuarios.

Saludos!

[Haddd]

 Tengo una 9500 softmodeada y me funciona a 1000 y pico FPS. A veri si teneis puesto DX en modo Debug.

Astat, gracias por hacer el primer comentario sobre el código. Ahora necesitaría que aclararas un poco lo que dices...

Ager, una cosa es claridad y otra potencia. Utilizar DirectInput está muy bien, pero me parece más fácil y "compatible" utilizar WinProc. Sin embargo, en un futuro habrá las dos opciones.

[AgeR]

 No me refería a utilizar DirectInput, me has entendido mal. Me refería a "recopilar" las rutinas del raton por ejemplo en una clase, ya que si no hay demasiadas variables desperdigadas por el código.

De todos modos, si vas a dar las dos opciones, pues mejor que mejor  ;) .

Saludos!

[jpastor]

 

Astat, gracias por hacer el primer comentario sobre el código. Ahora necesitaría que aclararas un poco lo que dices...

No soy astat pero me gustaria comentar que la gente prefiere acceder a los objetos por metodos en vez de por datos miembro. Ademas puede hacerse engorroso ir escarbando y escarbando hasta llegar a donde quieres llegar. Un ejemplo:

Código [Seleccionar] Expand


Video.m_Inicializacion.m_Requerido.Ancho=740;
Video.m_Inicializacion.m_Requerido.Alto=540;
Video.m_Inicializacion.m_Requerido.BPP=8;
Video.m_Inicializacion.m_Requerido.ZDepth=16;
Video.m_Inicializacion.m_Requerido.StencilDepth=0;


podria ser:

Código [Seleccionar] Expand


Video.Requerir (VIDEO_ANCHO, 740);
Video.Requerir (VIDEO_ALTO, 540);
Video.Requerir (VIDEO_BPP, 8);


[Astat]

 

Astat, gracias por hacer el primer comentario sobre el código. Ahora necesitaría que aclararas un poco lo que dices...

Me parece que le das demasiado "poder" al usuario (con usuario me refiero a tipo que va a usar tu motor para hacer un juego).  Para mi lo mejor seria que la plataforma (windows, linux, psx, etc) le fuera totalmente transparente, asi como la api que usa el motor. Una buena forma para conseguir esto podria ser utilizar interfaces virtuales para toda la comunicacion "usuario <-> motor". Asi es mas o menos como lo hago yo, y para muestra te dejo aqui un ejemplo de lo que seria una apliacion minima (inicializacion, carga de una escena, movimiento con la camara, y fin) con mi sistema (evil game engine):

descarga de ejemplo

Un saludo.

[Haddd]

 Bien, en esto que decís os doy un poco la razón. Al principio, yo hice mi primer motor pensando de esta forma. Definí las clases con sus miembro protegidos, públicos y privados, pensando en la herencia y en derivar las funciones útiles. Sin embargo, con el paso del tiempo, creo que ese no es el enfoque para este motor. Creo que la gente que sabe mucho, ya no utilizará un motor que ha hecho otro. Por eso estructuré el motor un poco más al estilo de visual basic, encapsulando más que "claseando". Considero que alguien que sepa poco C++ verás más fácil la utilizacíón del motor de esta forma.

Otro "error" que cometí fue lo de definir el acceso a los miembros de las clases tan bien. No es que sea un error, es que como cambia tanto el motor, me cuesta muchísimo menos mantener el código si el acceso a las variables es público y no privado. Ya sé que no se debe hacer, pero por mi experiencia del tiempo que le puedo dedicar, es lo más sensato.

Y Astat, lo de "una API transparente" me parece lo mejor, desde luego, pero no para una persona que dedica un par de horillas a la semana al motor.

Pero os agradezco mucho los comentarios, de verdad. Espero que salgan más voces discordantes y me ayuden a mejorar. También espero que en un mes, de una vez por todas, pueda tener una serie de ejemplos que permitan al desarrollador poder trabajar ya de una forma clara y concisa, sin cambiarle las estructuras. Por eso he empezado con 2D, porque es mucho más fácil. Pero creo que lo de los shaders 2.0 ha sido un poco precipitado. Bueno, el tiempo lo dirá.