[Asesinos ciberneticos]

 Mi aportacion,

La mal llamada en españa Asesinos ciberneticos , deberia llamarse "segunda variedad" relato corto de philip k.dick - sobre evolucion de las maquinas
Dias Extraños - lectura/grabacion de sentidos
Saturno 3 - IA retro space
Engendro Mecanico - IA

Y, a quien no le gustan las conversaciones con Madre en Alien ? jejeje

Un saludo

 Holas,

Yo tambien tengo w2000 y tengo la sdk 9.0 a secas.
La version 9c de octubre no me dejo por tener 2000, y tuve que instalarla en otro ordenador con un xp home. Debe ser que el sdk 9c tiene conciencia estetica y requiere de botones bonitos para ejecutarse.... porque otra cosa no tiene más el xp. Estos de M$....
No se si alguna versión entre estas dos va bien en w2000.

Un saludo

 Solo unas puntualizaciones,

Abuse se hizo en MSDOS por lo tanto no esta hecho con DirectDraw, es curioso ver los requerimientos minimos que tenia:  un 486DX a 50 MHz.
Abuse en Wikipedia

Utilizan mapas de luz precalculados, pero estos mapas de luz se pueden mover/activar dinamicamente a cualquier punto del mapa en cualquier momento del juego(ejemplo: rafagas de luz por disparos etc...).

El rollo que solté unos post más arriba(con la técnica que se utiliza para hacer esto rapido) asumia que al final esto se implementaba con C y que el bucle más interno que renderizaba una linea de sprite(por ejemplo) se implementaba en ASM. Si se hace bien no tengo duda que sin tarjeta grafica 3d y con unos requerimientos pequeñisimos funciona perfectamente.

Creo que me equivoque asumiendo que nuestros amigos sabian o les interesaba C y ASM para hacer estas cosas. Mis disculpas.

Y muchos pensaran: "Y este calentamiento de cabeza en los tiempos que corren ¿para que?". Pues por un lado para ver como se hacian las cosas antes con poca maquina. Por otro lado todo depende de la maquina objetivo para la que queramos hacer las cosas, no todo el mundo tiene una tarjeta grafica 3d. Ademas estas técnicas nos permiten hacer cosas interesantes en los dispositivos que "no son tan rapidos" como un movil symbian, pocket pc, palm etc... ampliando nuestro mercado. Estos dispositivos no tan rapidos suelen tener minimo un procesador ARM a 100Mhz como poco y sin embargo veo algunos juegos/emuladores que no van todo lo rapido/fluidos que podrian ir.

Y dejando atrás la última reflexión, si lo que se quiere es hacer algo para las maquinas actuales pues desde luego es una buena inversión aprender DirectGraphics/OpenGl y olvidarnos de lo anterior.

Un saludo a todos.

[Con 8 bits]

 Existe un juego con codigo fuente liberado que utilizaba ese tipo de efectos, aqui te dejo el link a un port del codigo con la libreria SDL.

Abuse-SDL

El juego original para MS-DOS se llama Abuse y se publico en 1996. Utilizaba iluminación dinamica con modos de 8bits de color. Con 8bits y por tanto una paleta de 256 colores la técnica para conseguir esto se basa en "tablas de traducción"(o look-up tables). Esta técnica es la misma que utilizaba el Doom para conseguir algo de iluminacion con 256 colores.

Con 8 bits

Digamos que tienes una paleta original de 256 colores y 32 niveles de luminosidad.
Pues necesitas una tabla de 32*256 elementos de 8bits. Llamemosla T. :-)
Cada vez que vas a pintar con luminosidad l un color c haces: nuevo_color = T[l*256+c]
l = 31 es la paleta original, l=0 es con luminosidad 0(es decir, muy oscuro :) )

Es decir esta tabla traduce colores de iluminación normal(paleta original) a colores con iluminación más oscura, y estos colores más oscuros estan todos en la misma paleta original.

Lo "dificil" es calcular la tabla de traducción:

Código [Seleccionar] Expand


Para cada color c de la paleta original con su (R,G,B) tenemos 32 niveles de lum.
  Para cada nivel de lum. l de 0 a 31
       
       (R2,G2,B2) = CalculaLuminosidad(R,G,B,l)   Buscamos el valor R2,G2,B2 del nuevo color segun lum. l
                                                                              seria algo asi: R2=(R/32.)*l; G2=(G/32.)*l; .....

       c2 = BuscaColorMásParecido(R2,G2,B2)   Busca el color más parecido en la paleta original
       T[l*256+c] = c2


Una vez tienes todo esto, el hacer luces se haria con mapas de luz, es decir, Sprites cuyos pixeles son niveles de luz(las l anteriores).
Los mapas de luz los situas donde te de la gana como con los sprites. Seria algo similar a esto:

Código [Seleccionar] Expand


Para cada pixel
 l = MapaLuz[sx,sy]   // mapa de luz niveles de 0 a 31
 c = Sprite[ox,oy]   // nuestro bicho
 c2 = T[l*256+c]    // traducción de color
 Pantalla[ sx , sy ] = c2  // pintamos en pantalla


Con esta tecnica se pueden crear efectos de transparencias facilmente. Es más, como la tabla ocupa 32*256=8Kb y se utiliza constantemente será bastante rapido ya que estará almacenada en cache.

En 24bits:
Para el tema de 24bits de color el sistema seria similar solo que esta vez hacen falta 3 traducciones una por cada componente de color. Tendrias la tabla para R, para G y para B. Y harias la traducción de esta forma:
R2 = TR[ R + l*256 ]
G2 = TG[ G + l*256 ]
B2 = TB[ B + l*256 ]

donde R,G,B son los componentes del pixel del sprite y l como siempre el nivel de luminosidad

y donde la tabla TR se pre calcularia asi TR[R + l*256] = (R/32.) * l   y asi para la tabla de verde (TG) y la del azul( TB). asumo que l va de 0 a 31.
La tecnica para hacer luces dinamicas seria la misma que en 8 bits: mapas de luz con niveles de luminosidad.

En fin, espero que te sirvan algunas ideas ó que decidas hacerlo mediante direct3d u opengl.

Un saludo

[Texturing and Modeling: A Procedural Approach]

 Si quieres profundizar en el tema de generar texturas (2d,3d,procedurales,raymarching etc) te recomiendo el mejor libro sobre este tema:

Texturing and Modeling: A Procedural Approach
http://www.amazon.co.uk/exec/obidos/ASIN/1...2790919-9096621

Un saludo

[Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Third Edition]

 
Te recomiendo uno de los mejores libros sobre analisis y desarrollo orientado a objetos utilizando UML:

Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Third Edition

Tan solo comentar que UML es solo una especificación de diversos tipos de diagramas que nos sirven para construir(analisis y diseño) programas. Esto es, UML es una forma estandar de dibujar diagramas. No es un metodo para construir programas.

En particular el tipo de diagrama que a posteado zupervaca de ogre es muy util , es el diagrama de clases donde vemos el tipo de asociación(como se relacionan) de las clases de nuestro programa.
Luego hay otros tipos de diagramas como el de secuencia y el de colaboración que sirven para ver como interactuan los objetos para conseguir "algo"(ej. mover un jugador). Estos son casi el codigo del programa.

Los casos de uso son para capturar requerimientos de nuestro programa, es decir, que demonios debe hacer. Los "actores" del caso de uso normalmente son usuarios(recepcionista, dependiente, servicio tecnico etc) del programa y el sistema/subsistema. El titulo es siempre un objetivo a realizar por el actor principal; ejemplos: "Comprar productos","Inicio del programa"(actor el sistema) etc..

Utilidades:
- los casos de uso son buenos para tener un saco donde poner las cosas que se pueden hacer en el juego. Sobre todo las importantes. Además siempre hay casos de uso más dificiles por lo que se debe empezar a desarrollar estos al principio y asi sabrás si se puede hacer o no(si es viable vamos).
- los otros diagramas como el de clases te ofrecen una vista general y otras más en detalle(d.colaboración/secuencia) utiles para visualizar la estructura de lo que se va a programar.
- lo mejor es escoger los diagramas que mejor te sirvan para lo que vayas a hacer.

Sobre un metodo o proceso a seguir para construir con estos diagramas lo mejor es mirar el libro que te he puesto. Ahora bien, como tu dices realmente es muy usado en gestion pero en juegos estamos aún algo verdes.

Como herramientas la famosa es de Rational ahora de IBM.
Y más novedosa es la de borland: Borland Together, no la he tocado mucho pero me ha sorprendido, sobre todo por que otras herramientas siempre tienen una manera de generar codigo a partir de los diagramas y obtener diagramas a partir de codigo pero esto solo es util al final de un desarrollo o al principio de un desarrollo viejo respectivamente. Es decir el codigo y los diagramas van cada uno por su lado y todos sabemos que esto de diseñar software es iterativo no se hace de golpe y listo.
Lo que me sorprendio de Together fue que modificaba el codigo(c++ fue lo que probé) mientras cambiabas los diagramas y cambiaba los diagramas mientras editaba el codigo. Y esto es genial ya que de otra forma los diagramas al final son algo que no esta conectado con el codigo y al final puede(lo más seguro)  que esten desincronizados del codigo por pereza a la hora de mantenerlos. No soy un experto en el tema pero no he visto ninguna herramienta que haga esto.



Un saludo

 

Bueno, lo de usar coordenadas decimales, por supuesto, sino quedaría muy feo. Aunque en modo software lo hago todo en coordenadas enteras, por cuestiones de rendimiento, pero eso sólo se activa en máquinas muy malas (o a voluntad).

Sobre todo me referia a la hora de renderizar el sprite a la posicion (x,y) (sea la posicion con enteros en coma fija o con el copro en coma flotante).
Quizas estoy algo anticuado por haber hecho demasiado codigo que dibuja todo con software. :)  No se si la forma de renderizar que utilizas es mediante el hardware en 3d mapeado al plano 2d; y si el hardware te permite situar el sprite en una posicion no entera y además realiza un filtro sobre cada pixel del sprite para que puedas situar el sprite aparentemente "entre dos pixeles"(me refiero a la posicion origen del sprite, claro :) )  .   ¿?

[subsampling]

 Sobre cosas a añadir al sistema de particulas:

-  subsampling: para que la animación del movimiento de particulas sea suave. Es decir, tomar "posiciones x,y decimales". Aunque quizas con una resolución grande no haya diferencia.  Respecto a esto puedes ver Wu Pixels

- Te faltaria poner la aceleración como propiedad de una particula. Y calcular en cada paso  v= v+a; p = p + v; Con esto los "affector" pueden modificar la dirección de la particula simplemente variando su aceleración y podras añadirle los efectos gravedad , colisión etc... solo modificando eso.
Esta acelaración puedes cambiarla en funcion del tiempo , distancia , colision etc.... Quizas se puede prescindir de la aceleración  pero no tendrás
tanta flexibilidad.

-  turbulencia:  Seria la función que modela el caos que se ha mencionado antes. Aplicar el caos sobre la aceleración y siempre aplicando el mismo cada x particulas genera unas trayectorias muy vistosas. Esta turbulencia puedes verla por ahi como "noise", se aplica mucho en las texturas procedurales.

- Sobre el codigo que has puesto debes decidir quien mantiene la lista de particulas. La lista de affectors los puedes agregar a los emitters, aunque lo mismo puedes hacer instanciando varios ParticleSystems sobre la misma posición.

Mi pequeña aportación, aunque tengo la sensación de que estamos hablando de las mismas cosas con diferentes nombres. :)

Un saludo
Nostromo

 log2(x)=log(x)/log(2)

log(x) es el logaritmo base e o natural

 Buenas,

Para enriquecer un poco la discusión sobre serializar objetos en C++:

Esta claro que cualquier implementación sobre el lenguaje o no es limpia o tienes que decirle que campos guardar, o no sabe nada de referencias, clases derivadas etc....

Por abrir otro frente de ataque al problema os propongo que le echeis un vistazo a OpenC++:

http://opencxx.sourceforge.net/

Se trata de programar los programas de C++, es decir metaprogramación... con esta herramienta podemos generar un compilador de C++ que añada funcionalidad a nuestras clases, y con esto se podria solucionar el tema de la serialización de una manera limpia y potente ....
y muchos otros temas como la reflexión que no tiene el C++ y que hace que en Java y C# sea "facil" serializar puesto que la reflexión como algunos sabeis hace que las clases se puedan conocer a si mismas.

En fin, yo no tengo tiempo para profundizar en esta herramienta pero aunque esta incompleta muestra un futuro prometedor.

Un saludo

 

como llegaron a esto ¿? ~6&N-3  y yo que pensaba que hacer karnaugh no valdria para nada, habra
que ver los apuntes que ha hecho la gente jejejeje

llegue a eso por "casualidad" probando cosas en papel...

resulta que tenemos que aceptar solo 3 5 7 y 9 .... bien, la "casualidad" es que si restamos 3 a N (es decir N-3) tenemos que los 4 numeros anteriores en binario serian:
00000  (3-3)
00010  (5-3)
00100  (7-3)
00110  (9-3)
43210  <- posicion  

con lo que puedes ver que los 4 numeros que buscamos estan codificados en 2 bits (en la posicion 1 y 2), y con esto sabemos que si se encuentra un 1 en una posicion distinta de la 1 o la 2 el numero(dimension) sera incorrecto.

Con todo esto el ~6 ( NOT 000110 )  es igual a ...1111001   y haciendo AND con el N-3  sabemos si el numero es falso....

 Felicidades ses  (ole)

 

Creo que Nostromo va ganando ¿cierto? :)

Ojala!!!   :D  
Pero me temo que no, ses y gdl tienen menos caracteres que yo e imagino que hay gente por ahi de la que todabia no sabemos nada.   O_O

 

Además, nostromo, sobraba el +d en la asignación de la s ya que si hubieras quitado el j%d nunca saldría negativo:

Código [Seleccionar] Expand

#include<stdio.h>
s,j;main(d){for(scanf("%d",&d);~6&d-3?0:j<d*d;printf("\n%-3d"+(j++%d>0),(s-j+d/2)%d*d+s%d+1))s=j*2-j/d;}

Por cierto, me ha gustado mucho la forma que tienes de ver si los valores son correctos.

Sip, una cosa lleva a la otra. Y el caso es que la misma expresión la escribi de varias formas , creo me obsesione tanto con darle vueltas a la expresion que al final se me olvido lo que me acabas de decir; y lo tenia apuntado en alguno de los 10 folios de apuntes que tire a la basura nada más enviar el codigo.   :rolleyes:

Eso si, me alegre de enviarlo porque no veas el tiempo que "perdi" con el tema.

Al principio tenia i

 

Código [Seleccionar] Expand


#include<stdio.h>
s,j;main(d){for(scanf("%d",&d);~6&d-3?0:j<d*d;printf("\n%-3d"+(j++%d>0),(s-j%d+d/2)%d*d+s%d+1))s=j%d*2-j/d+d;}


Me acabo de dar cuenta que he metido dos j%d redundantes dentro de la expresion....
deberian ser solo j y hubiera tenido 123 caracteres!!!!   (nooo)