ups! Ahora que lo recuerdo, el ultimo pixel de cada linea que forma el triangulo no se pinta, con lo que no deberia haber problema con 1.0.. .sorry  :oops: ... o eso creo recordar...


Se me ocurre que podrias usar D3DTADDRESS_CLAMP en el SetTextureStageState(), asi, conservarias el color de "su" borde. Pero si tienes una "gran" textura con todas las demas dentro para minimizar los cambios de estado igual no te servira... :?

No se me ocurre mucho mas.. si alguien mas se anima...

El maximo de la textura, en la parte de abajo y la derecha, no deberia ser 1.0 sino 0.9999 o asi. No te sabria decir por que le pasa en un ejemplo y no en otro, pero si la textura se puede repetir (D3DTADDRESS_WR) la repeticion empieza en el segundo entero 0.0==1.0==2.0==3.0.

Hace mucho qu eno toco D3D... bueno y casi todo de 3D ... o ya puestos, codigo, que uno se hace viejo, pero tambien recuerdo que se puede variar el "centro del pixel de la textura" o algo asi, de todas formas ese problema se deberia solucionar cambiando los 1.0 por simplemente 0.9999.

Espero que sea de ayuda, saludos.

Dices que en Debug no te da errores y en Release si... bien, veras, en Debug, si la memoria no me falla, las variables van inicializadas con valores por defecto, cosa que en Release no.
Podria ser, es una posibilidad, que tengas un puntero que esta a NULL en la version Debug y con datos "basura" en la version Release. No seria estraño, todos lo tenemos en algun punto del codigo de alguno de nuestros objetos, que ese puntero se reutilice, seguramente tengas funciones que piden memoria cuando este esta a NULL, y que lo liberen cuando no es NULL antes de cojer memoria, la estariamos liando.
Procura tener en el constructor de la clase, el codigo necesario de iniciacion de todas las variables esa clase.

Tambien podria ser que nada de esto te sirva  :P  :roll: , dices que tienes cosas en static?? ves con cuidado si todas las instancias de esa clase esten compartiendo algo importante, y toqueteando sin que el resto de instancias lo sepan. En general las variables static en clases no tienen mucha utilidad, no abuses de ellas.

Ya nos contaras si te sirve algo de esto, saludos.

Ya no se hacen plataformas 2D como el nuevo mario de DS, si te gustan, este es muy bueno, pero no exesivamente largo.
Mario Kart, tiene bastante "enganche".
Respecto a brain training, no esta mal, sobre todo como experimento, pero no tiene muchas pruebas, y a los dias se te hara monotono, eso si, no se puede negar que es una experiencia nueva, pero algo justo.

Saludos.

La falacia del jugador

Yo de vosotros no iria al casino con esa mentalidad.... :mrgreen:  :roll:

No pones mucho, con lo que resulta difícil saber por donde vas... El tema de las patentes me resulta caótico, pero si tienes algo que ayuda al programador en algún aspecto concreto, podrías hacer una mini librería, como una "herramienta" mas a trabajar con otras librerías del mundillo share.

Recuerdo un post de indiegamer en el que se hablaba de cargar ficheros gráficos de diverso tipo, y hubo un usuario del foro que no dudo en hablar de su librería, la cual era únicamente para cargar .jpg's, si mal no recuerdo.

Toda ayuda es bien venida, y si es util,y tiene el precio ajustado(un "mero" tool no podría valer tanto como una librería completa), la gente se podría interesar.

Pero ya hablar de patentes... pues no se, dependerá de lo que tengas.

Saludos.

No estoy seguro de entender lo que dices...  :?  
.. pero creo comprender que estas trabajando con WM_CHAR para leer el teclado, y te funciona bien, el problema es que no sabes si tirara bien cuando tenga que leer un valor de 16bits (UNICODE), es eso no!?

No he lidiado este problema con profundidad pero recuerdo algunas cosas que tengo en un libro del Ventanucos.
Si registraste la clase con RegisterClassA, recibiras ANSI; si RegisterClassW recibirás UNICODE, el valor de 16bits que creo te preocupa; si lo hiciste con RegisterClass, "a secas", dependerá de si tienes activado UNICODE en el preprocesador.

Cuidado con activar el UNICODE en el preprocesador, por que te cambiara todas las funciones de windows preparadas para UNICODE de como las tenias en ANSI, si has usado _TEXT no tendrías de que preocuparte... creo.

Si no estas seguro de nada, con IsWindowUnicode() deberías obtener si la ventana obtendrá ANSI o UNICODE, en WM_CHAR.

A partir de ahí, supongo que si sale algo mal sera de que el bitmap con el font de windows-1251 no sea correcto.

...
...
...

Por otro lado estoy viendo que Window-1251 tiene 256 caracteres... si lo tienes en ANSI te debería valer no!??!?!
Eso si, asegurate que tienes el TranslateMessage(), en el bucle de mensajes, que es el que se encarga de que WM_CHAR funcione bien.

Espero que sirva y no lo haya complicado mas....Saludos.

[EDIT]
que caotico no.... :x  :|

Disculpa que te responda este ser desactualizado, pero...

Yo usaría floats... realmente no recuerdo si es mas lenta o no la FPU, diría que si... pero de todas formas... ¡¡El FPU a muerto Larga vida a SIMD (SSE)!!

En los compiladores de hoy puedes usar las instrucciones SIMD que pueden hacer varios cálculos a la vez. Si no recuerdo mal los registros son de ¿128bits?, y meter 4 floats o 2 double, de una vez podrías hacer 4 operaciones o ... solo 2.

Hay día podrías hacer lo que te venga en gana, tiramos mas de la gráfica que de la CPU (con permiso...), con lo que quizás no notes nada, pero si no es para hacer cálculos científicos, deberías tener mas que suficiente con float, y apurar rendimiento.

Lo que puedes hacer para tratar la perdida de precisión es crear un valor que haga las veces de "margen de error" como con un 0.999999f, puede que para un perfeccionista sea un problema, pero como he dicho si no estas haciendo cálculos científicos, y se trata de colisiones 2D/3D, suficiente.


Saludos.

PD: creo que los registros del FPU son de 80bits, aun que no creo que fuera desde los primeros modelos.

ups! no habia visto este post antes...

Deberias aprender C++ antes de DirectX, y no al reves como dices al inicio del post. No he visto muchos libros de C++, pero me gusto bastante el "C++,Como programar" de DEITEL, han salido nuevas ediciones, asi que lo tendras seguramente al dia.

Despues de conocer C++ podrias afrontar DirectX, pero te recomendaria que aprendieras algo de programacion del systema, como con el Programming Windows.
Con esto deberias ser capaz de hacer cosas en 2D con sonido incluso.
Despues de esto podrias complicarte la vida, si quieres, con OpenGL lo tendras mas facil para trastear por que conseguiras antes resultados,pero como no se usa tanto en juegos como DirectX... pues tu mismo.

Saludos.

Creo por lo que dices que quieres hacer algo así como un vídeo de tu programa en ejecución.

Si no tienes una maquina para la ocasión, si no algo "normal", seguramente TheAzazel tenga razón, y sea demasiado para tiempo real.

Creo que, bajando a un nivel "normal" tienes algunas opciones, como tener otra maquina con entrada de vídeo y grabar desde ahí, lo cual puede parecer una opción cutre... o podrías hacer trabajar la aplicación a cámara lenta con un control del tiempo como el que pone Pogacha, así daría igual el tiempo que consuma la grabación al HD.

Eso si, siempre puedes bajar la resolución, no se suelen ver vídeos de juegos y demás a grandes resoluciones, y seguro que a 800x600 o incluso 640x480 te valdría... aquí ya especulo, claro...

Saludos.

hmm... interesante apunte Pogacha.

Saludos.

Por dios! no sale la palanca de freeman! ignominia!!

Saludos.

Bueno en tal caso... se comprende  :wink: , es lo que tienen los primeros proyectos.

Suerte, y saludos.

No aseguro nada. Entiendo que todos los que intentamos meternos en este mundillo estamos muy interesados en las ventas de los demás, pero yo lo considero información bastante secreta. Puede que diga algo, puede que no...

jajaja! vamos hombre.... si no lo dices sera por verguenza, en indiegamr no es raro sacar esa informacion, incluso colson2 la mostro, reconociendo que era menos de lo que esperaba, pero estaba "explorando" el mundillo y lo entendemos.

Que no tienes un tesoro!!! hombre de dios!!!

Si fuera yo, el unico motivo para no revelar el dato seria que sean tan bajas que la gente se fuera a reir de mi....

Saludos.

Es una muy buena nota para un juego shareware.

En esa web puntuian juegos AAA comerciales, parece que la gente solo conoce el 3 para los malos, el 8 para los buenos y a partir del 9 del imprescindibles.

Esa nota roza el notable, para un juego share, si le ponen mas nota se quedaran siempre cortos con los FF o los MGS!!

Saludos.