Es cierto que el Viernes los betatesters oficiales recibimos el sdk y demas.

Lo unico que te puedo contar es que son 100 Mb de sdk por un lado y unos 25 o 30 de extras. (sin contar el directmusic producer)

Aunque mas que otra cosa este post va para recordar que el pasar el beta del este sdk esta considerado como piracy, y no creo que sea este foro el sitio adecuado para hablar de ello, o poner urls de descarga.

Por cierto en los newsgroups privados de directx tambien se ha hablado de estos sites que "dan el sdk" y han sido reportados a piracy@microsoft.com

Asi que , cada uno que se cuide de si mismo.

mICrO

El 2002-05-27 18:23, Lord Trancos escribió:
Según leo en hispamp3.com:
(http://www.hispamp3.com/noticias/noticia.php?noticia=20020527080813)
--------------------------------
Está circulando por Internet la primera versión beta de la próxima versión de DirectX para Windows.

La versión que está circulando parece ser la beta 1 del futuro Microsoft DirectX 9.0 Software Development Kit.

Contiene todo el software necesario para crear aplicaciones compatible con DirectX 9.0: DirectX 9.0 Application Programming Interface (API), documentación para cada una de las áreas, (para desarrolladores C++, C#, o Visual Basic), cabeceras DirectX 9.0 y librerías, aplicaciones de ejemplo y código fuente de las mismas.
--------------------------------

Tambien ponen un link:
http://ftp.freenet.de/pub/4players/mikemth...ls/DirectX9.zip (29.3 Mb)

Pa mi que 29.3 mb es muy poco para un SDK... y aun no me lo he bajado,... (en aprox hora y media lo tendre) asi que todavia no se que hay de cierto....

¿alguien sabe algo al respecto?

                               

El 2002-05-10 17:33, karotida escribió:
No creo que la mejor solución pase por utilizar un fichero de base de datos. Y digo esto porque si, por ejemplo decides utilizar Access 2000 (vamos un .mdb), y el usuario final tiene un win95 con Access97, no tendrá los últimos drivers, con lo que tendrás que obligarle (y a su vez deberás suministrarle) a instalarlos (el mdac_typ.exe de microsoft en el caso mencionado).

Creo que utilizar ficheros de texto plano que puedes leer desde tu programa sin problemas, es la mejor solución.

El XML como comentan más arriba es un fichero de texto plano, por lo que puede ser una buena opción. Además está organizado de forma jerárquica. Eso sí, si utilizas algún parser no creado por tí (como el MSXML de microsoft) para su lectura, también tendrás que asegurarte que lo tiene instalado el usuario ( o en su defecto incluirlo en tu instalación). Por ejemplo el explorer 5 no lleva la última versión de este parser ( la 4 si no me equivoco), por lo que si utilizas la última a instalar tocan. De todas formas hacerte tu propio parser de XML no es más complicado que hacerte uno para un formato propio, de esto no creo que te libres si usas texto plano.

Hay un parser llamado tinyxml es gratuito y esta en java pero ha sido portado a c++, con  fuentes incluidos, te vale bien para que lo utilices o bien para tu hacerte tu propio parser.

La version de c++
http://sourceforge.net/projects/tinyxml/


[ Este Mensaje fue editado por: mICrO el 2002-05-10 17:53 ]                                

                               

El 2002-05-06 19:59, DoVerMan_ escribió:
Bien, el problema quiza no sea un problema, la cosa es q estoy intentando hacer un engine isometrico utilizando directdraw, y como tengo la intencion de implementar translucencia utilizando alpha blend, decidi hacerme mis propios blt, utilizando asm en linea bajo c++.
Me he currado un blt que me coloca unos 700 bloques de 64x32 a 30 fps utilizando colorkey y con una res 640x480x16. Pero la verdad me parece un rendimiento bastante pobre, ya que imagino un mapeado, con transparencia e iluminación, y creo que necesitare bastante mar rendimiento. He buscado información, pero casi todo me lleva a utilizar mmx, y eso lo haria incompatible con maquinas antiguas.
Utilizo el siguiente planteamiento:
- Triple buffer en vram
- Surface de trabajo en memoria principal
- Surface de graficos en memoria principal

* utilizando mi blt coloco los bloques del surface de graficos al de trabajo
* una vez concluido el frame, copio el surface de trabajo al backbufer con bltfast
* hago un flip.

¿Podria sacar mas rendimiento utilizando alguna otra tecnica, q no pase por colocar todos los surfaces en vram?

gracias de antemano.

He estado mirando tu rutina y bueno quizas te venga bien conocer el par de manera que usabamos en los viejos tiempos para hacer esto rapido, por software.

Claro.

1º Tecnica. Pre-Analisis de segmentos
Vamos a ver, antiguamene cogiamos los graficos y los "preanalizabamos", buscando los segmentos que habia de gracio, por ejemplo
para el grafico :

OOO121OOO210
OO443212OO12
OO1111111111

Siendo O un pixel negro y los demas de color.
De ese graico sacabamos 5 tiras

tira 0 del pixel (3,0) longitud 3
tira 0 del pixel (9,0) longitud 2
tira 2 del pixel (2,1) longitud 6
tira 3 del pixel (2,1) longitud 2
tira 4 del pixel (10,10) longitud 2

Luego las poniamos en una estructura del tipo..
offsetx:offsexty
longitud
[datos]

Asi la podiamos recorrer y con un puntero y unas bonita sumas hacer memcpy de los datos para pintar simple y otras operaciones para
transparencias y demas.

Habia una mejor que era guardar las tiras "de color variados" por un lado y las de color uniforme por oro (rle) y entonces hacer memcpy y memset

El resultado pintas todas las tiras sin hacer ninguna comparacion menos la del propio bucle en si

2º Metodo. Precompilar
Una vez realizado el primer metodo se podia ir aun mas alla...
Cogias las tiras y generabas codigo ASM que al ejecutarse hacia las operaciones, ya desparecia incluso el bucle era un trozo de codigo que al ejecutarse pintaba

Bueno espero que te sirva de algo

Saludos

PD: Revisando el correo quizas hay algo que no quede claro.

La precompilacion consitia en generar una subrutina, opcodes y datos, y cargarla en memoria con sus stowb, reps,  o lo que fueran.

[ Este Mensaje fue editado por: mICrO el 2002-05-10 15:54 ]                                

                               

El 2002-05-10 03:44, Macrojd escribió:
Tengo la necesidad de programar unos juegos en c para DOS (Djgpp). El problema con el que me encuentro es que no tengo herramientas para la construccion de bases de datos como ocurre en Borland Builder (windows), por ejemplo. No sé si construir un archivo con estructura propia o utilizar archivos dbf o algo así. En cualquiera de los dos casos no sabría cómo implementarlo. Me gustaría saber con qué tipo de archivos trabajan ustedes para almacenar los datos y listas necesarias en sus juegos y si conocen algún formato práctico que pueda utilizar desde DOS.

(por supuesto que la programación en DOS no es algo habitual para mí, ni tampoco la programación de juegos, aunque pretendo que esta última comience a ser mi actividad principal).

Yo personalmente uso XML para todo lo referente a datos en un juego.

El xml es pontente y flexible y anula los fallos al cambiar de version del fichero, ya que no tienes porque "joder" la estructura original.

Es un concepto tan simple, que a veces, asusta.

Piensa algo asi

uno.xml

y luego en nua nueva version

dos.xml

Facil y sencillo.

Luego para leer esta info en el juego puedes usar muchas tecnicas, basicamente usar un parser DOM que convierte esa estructura en un arbol de nodos de texto.

Añades un dtd para validar los datos, y asi tendras hasta parsing por si hay errores al escribirlo.

El limite tu imaginacion.

Nota : El ejemplo ha sido escrito sin mas, seguro que hay mejores maneras de reflejar los datos de una pantalla que esa ;-P

[ Este Mensaje fue editado por: mICrO el 2002-05-10 13:01 ]

[ Este Mensaje fue editado por: mICrO el 2002-05-10 13:04 ]

[ Este Mensaje fue editado por: mICrO el 2002-05-10 13:07 ]