• Miércoles 20 de Noviembre de 2024, 08:35

Mostrar Mensajes

Esta sección te permite ver todos los posts escritos por este usuario. Ten en cuenta que sólo puedes ver los posts escritos en zonas a las que tienes acceso en este momento.


Mensajes - Amilius

Páginas: 1 ... 24 25 [26] 27
626
Programación de Videojuegos / Re: El Fin De Los Videojuegos
« en: Jueves 18 de Marzo de 2004, 20:31 »
No concuerdo que se diga que los viedeojuegos están llegando a su fin, pero si creo que están estancados en una visión meramente mercantilista donde vale más las ganancias que el producto o el cliente.

Creo que a los motores gráficos les falta mucho camino por recorrer así mismo a las tarjetas aceleradoras. NECESITAMOS más capacidad de motores y tarjetas gráficas a BAJO costo. ¿Que no ven el trabajo que es optimizar polígono a polígono para optener un buen resultado con el menor número posible de ellos?

Lo que es deseable es que los motores gráficos se convientan en un sólo estándar (o grupo de estándares), con la misma interfaz de uso (open source por supuesto), implementado internamente de distintas formas, pero con la misma interfaz. De esta forma se convertirán en una capa de software lo suficientemente estable y potente como para no tener que crear más motores gráficos. Todos saben que no tienen que implementar un Sistema Operativo cuando hacen un juego, ni tienen que rediseñar el TCP/IP si quieren crear un juego para jugarse en Internet.

De esa forma se tendrá más tiempo para dedicarlo a la esencia del juego.

627
Gracias por el dato Ruben!!!

628
Programación de Videojuegos / Re: El Fin De Los Videojuegos
« en: Lunes 15 de Marzo de 2004, 16:28 »
Actualmente las grandes compañias de juegos están más interesadas en producir peliculas en lugar de juegos. Le dan demasiada importancia al dulce gráficos y sonoro y se olvidan que lo escencial en un juego es que pueda recrear al jugador, que le de agradables momentos de diversión, entretenimiento, etc.

El dulce gráfico y sonoro es importante para captar la atención del jugador, pero un juego sólo será un éxito si conserva su escencia: divertir. Si no la conserva el jugador se aburrirá rápido de los "efectos", videos, etc. Uno juega para interactuar activamente y para PENSAR (no importa el "tipo" de inteligencia que uses), no para ser un elemento pasivo receptivo zombie (como lo que ocurre al ver TV). Como saben a los empresarios no les gusta arriesgarse, van a lo seguro: copiar cosas que tuvieron éxito, resultado: miles de clones ESCENCIALMENTE IGUALES aunque con fachada distinta. Muy pocos son los que tienen agallas para emprender un proyecto innovador, no les gusta los riesgos.
 
Un buen juego es fácil de APRENDER pero muy difícil de DOMINAR. Cuando DOMINAS el juego este se vuelve aburrido y pierdes todo interes por el. Si no aprendes rápidamente el juego simplemente lo dejas "No entiendo esta cosa".

629
Programación de Videojuegos / Re: Por Qué No En Java?
« en: Viernes 12 de Marzo de 2004, 07:03 »
Cita de: "Kev"
Bueno no es por ofender pero.

¡Zapatero a tus zapatos!

Java a la web y C++ A TODO LO DEMAS.

Salu2.
En realidad la tendencia es a la inversa...

Notarás que actualmente los tiempos destinados al desarrollo de software son cada vez más cortos, a tal punto que perder el tiempo en detalles de manipulación de memoria que si bien optimizan el programa hacen más lento y caro el proceso de producción de software al punto que pueden afectar la viabilidad de todo un proyecto.

C++ es un gran criadero de bugs (lo digo por los programadores inexpertos). Necesitas tener un equipo de programadores bastante experimentados en C++ para evitar que tu proyecto sea devorado por los bugs y eso cuesta dinero y los buenos programadores en C++ escacean. ¿Realmente crees que en estos tiempos a alguien le importa que tu programa vaya 3% más rápido (sólo si tienes excelentes programadores o de lo contrario no te servirá de NADA usar C++), o que sea un producto más barato que haga lo mismo y que no tenga los detestables bugs?

C es ideal para programar librerías, específicamente para optimizarlas, pero poco a poco es menos viable para emprender proyectos COMPLETOS: Micro$oft lo sabe muy bien y por eso existe C# : Un copy/paste de Java (forma, sintaxis, apariencia externa) fusionado con object pascal (escencia, mecanismos internos, lenguaje con tipos de datos fuertes, orden) y potencia para trabajar "cómodamente" (según el evangelio de micro$oft) con tecnologías de Internet.

630
Programación de Videojuegos / Re: Niebla En Doom 3
« en: Domingo 29 de Febrero de 2004, 17:17 »
Habría que ver el juego en acción. Una simple pantalla capturada puede ser muy engañosa.

Si el stencil buffer puede almacenar números de 8 bits (para usarlo como superficie para un efecto alpha) y se pudiera agregar un parámetro al algorimo que genera la máscara en el stencil buffer para indicarle que tan "oscura" será la máscara se podría evitar una segunda pasada.

631
Programación de Videojuegos / Re: Colision Circulo - Cuadrado
« en: Sábado 21 de Febrero de 2004, 14:41 »
Cita de: "Ruben3d"
Hola.

Para poder saber si un círculo ha colisionado con un cuadrado (o rectángulo o cualquier cuadrilátero en general) se me ocurre que podrías hacer lo siguiente:
  • Tener representado el cuadrado por sus 4 vértices y sus 4 aristas.</li>
  • Calcular la distancia desde cada arista al centro del círculo.</li>
  • Si la distancia es menor que el radio del círculo, entonces hay colisión.</li>
Espero que te sirva, un saludo.

Ruben3d
Buena idea, pero existe un caso no cubierto:

- Si el círculo está contenido por completo por el cuadrilátero.

En ese caso la distancia desde cualquier punto del borde del cuadrilátero al centro del círculo será siempre mayor al radio del círculo.

Y la solución también es simple: calcular la distancia entre los centros de ambas figuras y que esa distancia también sea mayor al radio del círculo.

632
Programación de Videojuegos / Re: Colision Circulo - Cuadrado
« en: Miércoles 18 de Febrero de 2004, 16:18 »
Prueba con el DelphiX, es Open Source para Delphi 3 adelante.

Tiene un algoritmo de colisión inicialmente por rectángulos y una opción para activar colisión por pixeles.

Como el algoritmo que buscas es demasiado específico y poco aplicable en la generalidad de casos dudo que lo encuentres.

El algoritmo de colisión de pixeles sirve para cualquier tipo de formas geométricas, no importa lo retorcidas que sean:

- 1. Calcula el rectángulo de intersección de los dos rectángulos que enmarcan los "sprites" que se desea verificar si colisionaron o no. Es decir que previamente ejecuta un algoritmo de colisión por rectángulos que por fines de optimización es muchísimo más rápido.

- 2. Si el área del rectángulo de intersección es mayor o igual a cierto porcentaje "umbral" de una de las áreas rectángulo de los sprites,  por ejemplo 50%, es aconsejable indicar que existió una colisión. (<100% Sólo con fines de optimización. Si se quiere ser estrictamente precisos este umbral debe ser del 100%)

- 3. En el rectángulo intersección calculado hace un barrido hasta terminar con dicha área o encontrar dos pixeles con valor disntinto de "transparente" en ambos sprites y que vayan a "dibujarse" en el mismo sector, en ese caso existió una colisión.

Como ves el algoritmo es bastante sencillo, lo complicado son los detalles de implementación.

633
Inteligencia Artificial / Re: Sólo un comentario sobre la IA
« en: Viernes 13 de Febrero de 2004, 16:56 »
Cita de: "jorge__cano"
Es verdad, estamos estrando en un tema muy controvertido.

Simplemente respondi a tu pregunta:
-----
"De todas formas, no dices por que no podemos comparar la inteligencia humana con la de una máquina."
-----

Bueno, por todo eso.

El tema es que todo lo que comento en el mensaje anterior esta intimemente ligado a la inteligencia humana y me resulta muy dificil dejar todos esos conceptos de lado.

Volviendo a la IA, dado que recien me estoy asomando a este apasionante mundo queria tener claro a que se refiere o de que estamos hablando cuando decimos IA para comenzar a manejar el mismo "idioma" del foro.

Volviendo a la IA:
¿Se puede programar IA en VB? (para no tener que empezar a estudiar otro lenguaje dado que no dispongo de mucho tiempo).

Si es asi, ¿por donde empiezo?.
¿Alguien conoce en la red algun tutorial basico acerca de IA?

Gracias.
 
Un saludo.
Jorge Cano
Claro que se puede programa IA en VB!!.

La diferencia es la facilidad y tiempo que toma programar IA. Desgraciadamente los lenguajes para IA están orientados a un ambiente académico, investigación y realización de prototipos.

634
Programación de Videojuegos / Re: ¿qué Librería Gráfica Utilizar?
« en: Jueves 5 de Febrero de 2004, 01:55 »
"el resultadio no sera mejor ya que las librerias ahn sido desarrololadas de la forma mas optimizada posible lo cual seguramente es mejor de lo que cualquirea de nosotros lograria"

Hmmm... Considerando que hablamos de microsoft...

En realidad es relativo, si hablas de funciones de propósito general o específicas para cubrir un problema puntual:

Ej. "Cambiar el tamaño a una superficie", sólo perderíamos tiempo haciendo una nueva función que haga esto, ya que existe una buena de propósito general que hace lo mismo. Pero si lo que SIEMPRE haremos es "Cambiar el tamaño de una superficie al DOBLE de ancho y de alto" entoces podremos crear una función de propósito específico y por esto mismo podrá ser mucho más rápida.

Lo mismo sucede con los efectos alpha: el método genérico es útil para multitud de casos, pero si sólo necesitamos un alpha del 50% podremos crear una función específica que será mucho más rápida, claro que esto puede ser muy relativo si la tarjeta aceleradora es TAN buena que incluso su función genérica de alpha es más rápida que una función simplificada e implementada para que la ejecute el procesador, aunque seguramente la transmisión entre memoria de video, RAM y otra vez memoria de video sea el peso fundamental que termine por hacer más lento cualquier edición hecha por el procesador.

Personalmente pude comprobar el peso de tener memorias lentas: mover memoria (bitblt) toma prácticamente el mismo tiempo que aplicar un efecto de transparencia al 50%. La respuesta es que mientras el procesador espera a la lenta RAM, puede darse el lujo de hacer algunas operaciones con sus registros.

¿Alguien sabe en que quedo el "cg" de NVIDIA?

PD.

Lo mejor del direct draw es esto:

if SuperficieRender.lock (@Rectangulo_Origen,lpDDSurfaceDesc,DDLOCK_WAIT,0)=DD_OK then
begin
   .....
    membase:=lpDDSurfaceDesc.lpSurface;
    ...

    SuperficieRender.unlock(@Rectangulo_Origen);
end

Te da una referencia al sector de memoria donde está la "superficie" gráfica, además de otras variables para navegar por ese bloque contiguo de memoria (ancho, alto, ancho con alineación a n bytes, etc).

"membase" y "posicionActual" son referencias a memoria,

luego tu

" backbuffer[x+y*anchuraPantalla] = color "

sería:

posicionActual:=pointer (integer(membase)+x+y*anchuraPantalla);

si anchuraPantalla es potencia de 2 mejor por velocidad:
(log2anchuraPantalla es una constante)

posicionActual:=pointer (integer(membase)+x+y shl log2anchuraPantalla);

luego para escribir o leer:

miword:=word(posicionActual^ );
milongint:=longint(posicionActual^ );
mibyte:=byte(posicionActual^ );

word(posicionActual^ ):=$09FF;
longint(posicionActual^ ):=$00FFFFFF;
byte(posicionActual^ ):=$09;

PD2. Los primeros 4 "type casting" sólo son para el programador, por respeto a los tipos de datos y para evitar bugs por interpretaciones ambiguas, en realidad no generan código máquina y no se usan en C. Los 6 restantes "type casting" indican tamaños de memoria.

635
Delphi / Re: Problema Con Sockets En Delphi
« en: Lunes 2 de Febrero de 2004, 19:27 »
Es mejor que veas el ejemplo del chat con sockets y ver que paso te falta. Seguramente te falta llamar a un método o asignar una propiedad.

Cuando usas un componente lo mejor es tener un ejemplo de uso ya que muchas veces existen algunos "detalles" que se les olvida mencionar.

Bueno, esto es lo básico: (y por supuesto definir los cuatro OnClient...)

En este esquema el servidor recibe todo centralizado (OnClientRead) y despacha info al cliente donde y cuando le de la gana usando el socket que le da el "SSocketClientConnect".

Código: Text
  1.  
  2.   SSocket:=TServerSocket.create(self);
  3.   with SSocket do
  4.   begin
  5.     Active := False;
  6.     Port:=PUERTO_COMUNICACION;
  7.     ServerType :=stNonBlocking;
  8.     OnClientConnect := SSocketClientConnect;
  9.     OnClientDisconnect := SSocketClientDisconnect;
  10.     OnClientRead := SSocketClientRead;
  11.     OnClientError := SSocketClientError;
  12.   end;
  13.  
  14. .....
  15. SSocket.open;
  16. .
  17. .
  18. .
  19. Con el socket que te da el &#34;SSocketClientConnect&#34; :
  20. (Un array de referencias a objetos &#34;socket&#34; para identificar mejor cada conexión)
  21.  
  22. socketConectado[i]:=Socket;
  23. ..
  24. .
  25. socketConectado[i].sendText(s);
  26. .
  27. .
  28. ........SOLO si esta activo:
  29. SSocket.close;
  30.  
  31.  

636
Programación de Videojuegos / Re: Que Horror
« en: Viernes 30 de Enero de 2004, 04:49 »
Vaya Vaya...

Sin duda la Xbox está condenada al fracaso...

Esa .net en realidad debería llamarse ".bug" para combinar con el lema de esa empresa.

Que asco que existan tantos ingenuos con "actitud" de esclavo.

637
Cita de: "Martin Candurra"
Mira necesito los datasheets, es decir las hojas de dato que provee el fabricante con la placa de video.
El modo VGA puede ser obsoleto en lo que a juegos se refiera, pero yo lo necesito para el control de una consola.
Particularmente no logro ubicar el cursor, cuando modifico el offset de la memoria de video de modo texto de 0xB8000 a 0xB8FA0, por ejemplo.

Estoy trabajando directamente sobre el hard y en modo protegido, por lo que no puedo utilizar funciones de BIOS, y no tengo tampoco un sistema operativo debajo.
Entonces está my dificil que encuentres algo...

(Nota: Todo esto es para los modos VGA de 256 colores indexados)

En pascal usaba algunos puertos (que encontré mientras hacia unas "pruebas") como:

port[966]:=0;
//Para modificar el número de colores visibles, esto hace que que la pantalla //aparezca toda negram, para volver a modo normal:
port[966]:=255;

//Esto es para cambiar la paleta de colores, es muchísimo más rápido que usar
//las funciones del bios.
port[968]:=0;
for x:=0 to 255 do
begin
//esto va en orden: rojo, verde y azul (o era azul verde y rojo??)
//son 256 colores
port[969]:=color_i[0,x];
port[969]:=color_i[1,x];
port[969]:=color_i[2,x];
end;

//También se puede leer la paleta actual de colores con ese puerto 969 (ojo está //en decimal).

Otros puertos similares (los 960... y pico) permiten cambiar la frecuencia de actualización de la pantalla, pero es un tanto peligroso cambiarlos especialmente en monitores antiguos, ya que puedes distorcionar la pantalla y si el monitor no es muy bueno hasta lo puedes quemar (Recuerden el mensaje que saca windows cuando cambias la frecuencia de actualización de la pantalla). Los monitores modernos se limitan a apagarse o colocarse en modo de bajo consumo, pero ojo que si estás en windows puede que tengas que reiniciar la máquina para volver a ver algo en tu monitor. Personalmente con mi monitor antiguo sólo veia como la imagen se distorcionaba como en un televisor antiguo.

Para Los visual y Delphi tendrás que usar en ASM el "in" y el "out".

mov al, 100
mov dx, 969
out dx, al //Port[969]:=100 // dx=969
in ax, dx //ax:=Port[969] // dx=969

638
Programación de Videojuegos / Re: ¿erramientas Para Turbo C++ Porfa?
« en: Domingo 11 de Enero de 2004, 19:25 »
Sólo agrego que

"page flipping" lo usan los juegos de cualquier tipo y también programas reproductores de video que funcionan en pantalla completa. Originalmente fué pensado para ahorrar recursos de CPU y placa de video. En los tiempos de la VGA era totalmente necesario, ahora se usa más que todo para sincronizar el juego con el monitor para evitar que cuando la placa de video refresque el monitor la copiada de superficie esté a medias. Como sólo se intercambia el valor de dos punteros no hay copia de memoria y nunca verás una imagen "partida".

639
Delphi / Re: Juego de Rol Multi-Usuario Masivo 100% Hecho en Delphi 3
« en: Sábado 10 de Enero de 2004, 23:33 »
El juego completo (cliente+servidor) lo puedes bajar de:

(link actualizado 2004.04.02)
groups.msn.com/legadodelasartesarcanas

El sistema de combate permite realizar movimientos ofensivos y defensivos para tener bonificaciones en defensa si estás usando un escudo. Un ataque ofensivo permite usar el 100% de tus habilidades de ataque. Un movimiento defensivo permite usar el 50% de tus habilidades de ataque pero incrementa el factor de defensa de tu escudo de acuerdo al % de Destreza de tu personaje.

El daño depende de tu arma y tu fuerza, que puedes incrementar en cada nivel hasta el nivel 12 pudiendo llegar a 100% en fuerza. Tu % de fuerza multiplica el daño que hace tu arma hasta un 250% para 100% de fuerza. A diferencia de muchos juegos de rol existe un balance en las armas entre el daño que hacen y su efectividad. Una daga hace poco daño pero incrementa tus probabilidades de acertar en el ataque. Una espada de dos manos hace mucho más daño pero puedes fallar más frecuentemente. También los guerreros y bribones pueden especializarse en el manejo de un arma a medida que la vayan usando. Si tienes especialidad en un arma determinada tu probabilidad de acertar aumenta y contrarresta cualquier penalización que tenga el arma por ser pesada (como una guadaña, un mandoble o una alabarda).

El sistema de creación de personajes evita trampas y asegura que todos comiencen con la misma cantidad de puntaje total sumado. De esta forma evita personajes con puntajes bajos en todas las habilidadades o puntajes altos en todas sus habilidades.

Los conjuros de combate no se limitan a apuntar y lanzar el conjuro, aparte existe la posibilidad de realizar conjuros sin apuntar que afecten a varios jugadores, en linea al frente del mago (meteoro de fuego) o alrededor del mago (vortex congelante).

Existe diferencia entre hechizos de clérigo y mago por los niveles de Inteligencia y Sabiduría necesarios para memorizar un conjuro. Si no cumples con los mínimos requeridos es poco probable que puedas memorizar el conjuro y tendrás que comprar varias veces el pergamino hasta memorizarlo exitosamente. Algunos hechizos de ataque como el vortex congelante pueden reducir la velocidad de ataque del enemigo momentáneamente si le hacen suficiente daño.

Es posible construir tus propias armas mágicas con gemas valiosas y oricalco fabricado por los alquimistas. Algunos conjuros varían de efecto si utilizas una gema para potenciar el conjuro como conjurar armas mágicas especiales que hacen daño congelante, fuego, rayo, veneno, etc.

Las armas con el uso van deteriorándose y mucho más si las usas bajo la lluvia, tienes que afilar tus espadas, reparar armaduras y aceitar tus arcos y ballestas para que no se vayan a estropear en medio de una batalla.

Puedes crear tus propias pociones mágicas si eres herbalista y tienes un caldero mágico, luego las puedes guardar en frascos y venderlas si es necesario.

Puedes escribir pergaminos mágicos para venderlos o dárselos a tus aliados para que aprendan los conjuros que dominas.

Algunos monstruos siempre están moviéndose mientras otros resguardan celosamente tesoros y minas. Los monstruos tienen rango de visión, así que te puedes pasar cerca de ellos y si no te están mirando no te atacarán. Ten cuidado con los contempladores que tienen ojos en todos lados!!

Puedes fabricar varitas mágicas y llenarlas de maná para futuras batallas. También son muy importantes los símbolos sagrados para los clérigos y los cetros para los hechiceros. Ambos artefactos incrementan el daño base que realizan los conjuros de combate hasta x6 en el caso de los magos. También puedes comprar un libro de hechicería o de oraciones para recuperar maná meditando mucho más rápido.

El dia, la noche y la niebla tienen efecto sobre tu capacidad de acertar si usas el arco y flecha o ballestas. En la noche, en la niebla o dentro de calabozos poco iluminados es más difícil acertar.

El comercio y precios están autobalanceado por la oferta y la demanda, a medida que vendas cierto bien a un comerciante su precio disminuirá y se elevará a medida que exista más demanda que oferta. Para eludir estos terribles efectos puedes utilizar la pericia "regatear" que te permite obtener mejores precios al momento de vender y rebajas al momento de comprar.

640
Delphi / Re: Me Parece Algo Raro...
« en: Sábado 10 de Enero de 2004, 22:24 »
Cita de: "BlackTigerX"
agregale mas parentesis:

IF (int(shape4.Top) >= (int(shape3.Top) -8)) AND (int(shape4.Top) <= (int(shape3.Top) + 3))
 
Y en C++ o C generalmente agregas más paréntesis. :)

641
Sería bueno que describas mejor y especifiques que tipo de información estás buscando. En estos días nadie se mete con esos detalles de fabricantes de hard. Para eso está el directX para los juegos. Con excepción del estándar VGA y SVGA de 256 colores no creo que vayas a poder encontrar información útil, además si lograras encontrar información acerca de esos modos recuerda que ya son obsoletos.

642
Programación de Videojuegos / Re: Por Qué No En Java?
« en: Domingo 4 de Enero de 2004, 01:31 »
:blink:

El problema que veo de programar con JAVA es que tienes que olvidarte de usar ASM. En Delphi y en C++ puedes usar ASM donde te de la gana y optimizar puntos claves de tu código.

No te preocupes que tu juego vaya lento o no por hacerlo en JAVA, en ese caso pesa mucho más la eficiencia de las APIs 3D que consigas para JAVA. Recuerda que el trabajo pesado lo hace el procesador de la tarjeta de video y las librerías para controlarla.

No estoy de acuerdo con Juank respecto a que por el solo hecho de trabajar con JAVA tengas que bajar la calidad de texturas efectos y música, pero si afectará el conteo de polígonos si la API 3D no tiene bibliotecas que eviten usar codigo JAVA para trabajar con los polígonos. Eso si: olvídate de incluir tus propios "efectos", tendrás que conformarte con los que incluya la API 3D y posiblemente restringirte a los que "soporte" la tarjeta de video.

643
Programación de Videojuegos / Re: programacion en c++
« en: Sábado 3 de Enero de 2004, 19:39 »
Cita de: "Geo"
Cita de: "DarkSlash"
sino TODAVIA más flojo como para NO buscar en google o algun buscador similar... ahjgr...
:kicking:

Yo también creo que un editor de textos es una buena tarea, sobretodo porque en algunos entornos es algo "casi" intuitivo, por ejemplo, en Visual Basic y Delphi (o en este caso con el C++ Builder) se puede hacer un Notepad sin tener que recurrir a mirar código, es simplemente agregar componentes y checar sus funciones  :rolleyes:.

Chécate la página www.lawebdelprogramador.com, en la sección Biblioteca (o Código fuente) quizá encuentres algo que te sirva.

Saludos,
José Jorge (Geo).
No creo que el trabajo tenga valor si usas componentes prefabricados... creo que la idea es que realizen el editor desde 0 o casi 0. El hecho que actualmente, como dices basta arrastrar y soltar y tienes un mini editor de texto implica que deberían pensar en dar otro tipo de trabajos que permitan al estudiante comprender las ventajas y desventajas en el manejo de punteros o referencias a memoria. Para que comprendan cuando, donde, porque y como se debe usar la memoria dinámica.

644
Te digo algo: Si necesitas hacer un par de cosas "raras" para que tu juego funcione bien.

1.- Cuando envias información, la información no siempre llega "igual" como la mandaste. Ej:

Mandas "Hola", luego mandas "Mundo":

Puede que reciban: "Hola" y luego "Mundo", también: "HolaMundo" todo unido, :(
esto complica la recepción de datos y puede que necesites reconsiderar tu "protocolo" de envio de mensajes que creaste para tu juego. Necesitas diferenciar el "Hola" del "Mundo". Puedes usar un caracter especial que es lo más fácil, o también indicar la longitud de cada fragmento de información que envies:

Así si a tu método de recepción de mensajes llega:

t4Holat5Mundo

Tu método podría reconocer la "t" como inicio de fragmento de texto y el 4 como la longitud de ese texo. Obviamente mejor si envías datos binarios y en lugar de enviar un "4" en texto envías un 4 binario (un byte) para poder enviar más información sin desperdiciar ancho de banda:

Ej, Mandar 200 en texto es menos eficiente y más complicado que enviar un 200 en binario que ocupa un solo byte. Es más fácil hacer un programa que luego de leer la "t" que indica texto lea el siguiente byte y determine la longitud del texto que sigue que tener que distinguir si 200 se refiere a que la longitud del texto es 200 caracteres o es de 2 caracteres y los caracteres son "00".


2.- Si el paquete es demasiado grande, se fragmenta. Es bueno que evites despachar paquetes grandes (más de 1Kb de información), especialmente si quieres hacer un juego en "Tiempo real" ya que esperar por el resto de información faltante destruye el ritmo del juego y en los juegos en "tiempo real" el ritmo de juego es vital para crear la ilusión de continuidad.

Como tu juego es por turnos, puedes agregar a tu método de recepción un sistema que detecte que falta información adicional y espere a que llegue otro paquete con la información faltante en cierto tiempo, evitando que el juego quede detenido mucho tiempo.

Ej. Te llega "t4ho", como esperas 4 caracteres y sólo te llegaron dos esperas hasta que en un máximo de digamos 4 segundos llegue otro paquete con el "la"

¿Pero no se supone que esas cosas las hace el winsock?

Nadie dijo que los "paquetes" no vayan a llegar juntos o primero llegue una parte y luego el resto. Lo que asegura el "soket" es que TODA la información llegue a destino... eventualmente (si no ocurren problemas mayores) y llegue en orden. Tu tienes que saber distinquir tus fragmentos de datos que envias y saber si ya te llego todo tu fragmento.

P.D.

Si no me crees haz que tu programa te muestre en pantalla todo lo que recibe el socket y haz la prueba enviando cantidades muy chicas de información en varias llamadas a "send" una detrás de otra  y también enviando un buen paquete de información como de 64Kb y verás los resultados. Prueba sólo en tu máquina, en red a otra máquina y si es posible por internet usando una conexión "dial up". Verás las sorpresas que te esperan.

----------------

  La diferencia de los juegos "con turnos" de los juegos en "tiempo real" es que en los juegos en tiempo real puedes o no usar tu turno, los turnos apenas duran una fracción de segundo o en el caso de juegos de estrategia tu puedes mandar la cantidad de órdenes que desees pero tus "bichos" se mueven y atacan en sus respectivos turnos. Obviamente no se espera a que el jugador realize su "movida" para que comience el siguiente turno y pocas veces los turnos están sincronizados.

 Turnos no sincronizados: por bicho y acción existe un tiempo de espera hasta realizar la siguiente acción, esto lo sincronizan muy bien con la animación de los "bichos" para desvanecer cualquier impresión que todo el juego va por turnos y dar la sensación de continuidad.

645
Programación de Videojuegos / Re: ¿erramientas Para Turbo C++ Porfa?
« en: Miércoles 31 de Diciembre de 2003, 02:44 »
La verdad es que con Turbo C++ y si como me imagino (por los 16 colores que dijiste) es un compilador antiguo "16 bits", no te conviene para nada, por el tipo de juego (de plataforma?) que quieres hacer.

1.- Limitaciones de memoria, 640kb (un dolor de cabeza tremendo y más si te metes con las antiguas EMS y/o XMS ) , a diferencia de usar un compilador a 32bits y olvidarse de ese problema gracias a la memoria virtual.

2.- Limitaciones de calidad o te conformas con 16 colores a 640x480 o 256 colores a 320x200 (modos de video VGA estándar), además por la limitación de 16bits sólo te puedes mover en "completa" libertad en 64Kb, (bueno para el 256col y 320x200), sino tienes que cambiar de pagina, todo un lio y ni que decir si quieres hacer el famoso "page fliping". Todo eso está superado con DirectX (Ojo que ahora cada fabricante de tarjetas de video :P, aceleradores de gráficos 3d  incluye sus "drivers", ya que no se controlan con un estandar como ocurría con las antiguas VGA, por eso si usas un compilador a 16bits despídete de 15, 16, 24 y 32bits de color).

3.- En el futuro, en tu carrera, utilizar manejar un compilador de 16bits no te servirá para NADA, aparte de aprender el lenguaje C++. Tienes que aprender a utilizar un RAD (y programación de interface orientada a eventos, ya te darás cuenta de lo que hablo), personalmente prefiero Delphi, talvez te muevas más a gusto en un Borland o Visual C++. Te recomiendo que comiences a usar un RAD lo más pronto posible, aprendiendo a usarlo programando un juego es una buena opción.

646
Programación de Videojuegos / Re: programacion en c++
« en: Viernes 26 de Diciembre de 2003, 21:16 »
Cita de: "mayko_man"
necesito el codigo de un editor de texto hecho en c++, por favor si alguien lo tien me lo puede enviar si..:comp:
Si eres un "diablillo" de programación haz uno tu mismo, y no vayas buscando por ahi códigos ajenos.

P.D.

Que estupidez de trabajo "editor de texto", yo daría distintos trabajos para hacer cosas útiles, pequeñas herramientas que utilices en la vida real y no un "editor de texto", eso sobra ya e incita al "copy/paste", tu catedrático debe ser un cretino imbécil de primera y no creo que seas tan flojo como para no buscar por ahí en la red y quieras que te manden a tu correo todo listo.

647
Programación de Videojuegos / Re: Juegos Sin Utilizar C/c++
« en: Viernes 26 de Diciembre de 2003, 21:01 »
Cita de: "Reus"
practicamente se puede programar videojuegos casi cualquier lenguaje de programación, basic es una herramienta muy sencilla de utilizar y en donde puedes crear un videojuego express... por el otro lado te limitaria mucho y tus opciones serian pocas.

si tomas en serio la programacion de videojuegos usa ASM, no la blasfemia (desde mi punto de vista) de C++ (y/o genericos).
Respecto a usar ASM es necesario aclarar algunas cosas:

1.- No programas TODO el juego en ASM.
2.- Sólo programas en ASM tdo lo que tenga un consumo crítico de CPU, que necesiten ser optimizados tanto como sea posible, por lo general métodos o funciones de un objeto que son ejecutados la mayor parte del tiempo.
3.- Aunque programes el juego en C o C++, eventualmente necesitarás optimizarlo con ASM.

Algunas cosas respecto al " C++ ": :angry:

1.- El lenguje C++ no genera código más eficiente, eso es mentira, son los compiladores que trabajan con el lenguaje los responsables por generar código más o menos eficiente.
2.- C++ es un lenguaje oscuro, de dificil lectura y mantenimiento por su léxico "abreviado", por eso es severamente propenso a los bugs.
3.- Otros lenguajes como Delphi son mucho mejores, tienen las ventajas de C++ sin incurrir en sus deficiencias.
4.- C# es mucho mejor que C++ para programar juegos.

648
DirectX / Re: Tiles
« en: Viernes 12 de Diciembre de 2003, 03:03 »
Cita de: "sk8erlucas"
Estuve investigando como usar tiles y no encontré nada, lo que quería saber es como usarlos, necesito crear un lugar largo y no me parece buena idea hacer un BMP de tan gran tamaño.
Así que investigué y decubrí que hay una técnica llamada tiles para hacer eso, el método es reemplazar una letra o número por un cuadrado, así se puede hacer el mapa en forma de texto. El problema es que no sé como copiar el sprite a otra superficie, y no sé si hacer tantos sprites (Uno por cuadrado por cámara).

Estoy seguro que hay una forma general de hacerla de la que todos parten al principio, si alguien la sabe me sería de mucha ayuda que me la diga.
Si puedes copiar una superficie  a la superficie de render no veo por que no puedas copiar una superficie a otra, es con la misma función. Si no estás usando 3D mejor si colocas TODAS tus superficies en RAM al momento de crearlas para que todo vaya más rápido en la mayoría de las máquinas.

Para los tiles (generalmente 32x32 pixeles o potencias de 2) utilizo una superficie con varios tiles ej: 512*512 y 256  tiles de 32x32 pixeles. Luego para copiarlos utilizo un simple cálculo para determinar el rectángulo "origen" en la superficie de tiles, que puedes optimizar con desplazadores si utilizas anchos de tiles que sean potencias de 2. De esta forma un byte representaría a uno de los 256 tiles.

Saludos.

649
Seguridad y Criptografía / Coger a una pesadilla..
« en: Martes 11 de Noviembre de 2003, 05:00 »
No.
El truco es que la compu dentro de la lan te informe de todo, es cuestión de preguntar o mejor, que te digan.

Piensa:

Si tu máquina tiene que bajar una imagen de una dirección x, como un avatar de un foro, tu máquina tiene que enviar un montón de información al servidor, que es la máquina del individuo que te está rastreando para establecer una conexion y es su máquina de donde tu explorador baja la imagen. Con esa información a mano es posible que te puedan rastrear.

Un ejemplo típico son esas imágenes hechas a medida donde te muestra tu ip, tu isp y que explorador estás usando. No son nocivos (no la imagen claro, sino la técnica) a menos que exploten los miles de bugs de windows y logren "instalar" un agente en tu máquina o usen al mismo windows que actuará como un maldito gremlin destrozando tu máquina según le ordenen desde la red.

Como ves tu misma máquina te traiciona y envía toda la información que necesita el invasor para infectar tu máquina (claro, con la ayuda de uno que otro maldito bug de windows).

650
Además:

- Auras para ver los hechizos que afectan a monstruos y jugadores
-Nuevas animaciones para personajes
- El aspecto de tu personaje cambia dependiendo de la vestimente, por el momento sólo existen dos a tres variaciones dependiendo de la clase y raza, pero el sistema ya está hecho y "sólo" es cuestión de diseñar más animaciones sin modificar código.
- 6 mapas para jugar, un calabozo y diversos terrenos y sonidos ambientales.

Pueden bajarse el juego completo de:

http://groups.msn.com/Legadodelasartesarcanas

Páginas: 1 ... 24 25 [26] 27