|
|
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 ... 19 20 [21] 22 23 ... 27
501
« en: Sábado 4 de Septiembre de 2004, 19:58 »
La estupidez es un atributo de la humanidad, fijate como "Terminator" es gobernador de California y un demente ignorante es presidente de usa. La extinción total de la especie humana es inminente. 
502
« en: Miércoles 1 de Septiembre de 2004, 19:43 »
Y la verdad que aun no se.. Me gustaria hacer algo estratègico No tengo conocimientos muy profundos de C++ pero aprendo rapido... Haz un Tetris, un Space Invaders, algo así. Cuando tengas hecho eso puedes pensar en un juego de estrategia.
Un saludo.
Ruben3d Mejor inventa tu propio juego, algo simple, pero divertido... No siempre es necesario un alto nivel técnico para crear un juego divertido. Puede ser un juego de estrategia estremadamente simple (No se, rayas, circulos, algo simple pero que se pueda jugar), tampoco intentes hacer algo parecido a juegos comerciales: cuestan mucho trabajo artístico!!.
503
« en: Miércoles 1 de Septiembre de 2004, 19:20 »
Mmmm, el código anterior no funciona en XP o es por la mugre tarjeta de sonido de mi nueva máquina, en nada comparable al chip YAMAHA para midis de mi antigua computadora.  Esto modificara el volumen de TODOS los dispositivos midi, claro que casi siempre sólo tendrán 1 habilitado. Error si no pudo fijar el volumen de al menos 1 dispositivo. function VolumenMidi(Volumen_Midi_L,Volumen_Midi_R:integer):boolean; var NroDispositivos,i:integer; begin NroDispositivos:=MidiOutGetNumDevs; result:=false; for i := 0 to NroDispositivos-1 do result:=result or (midiOutSetVolume(i, (VOLUMEN_MIDI_R shl 16) + VOLUMEN_MIDI_L)=MMSYSERR_NOERROR); end;
504
« en: Miércoles 1 de Septiembre de 2004, 18:57 »
Este procedure modifica el volumen para midi. implementation uses mmSystem,registry,sysutils; .... procedure VolumenMidi(VOLUMEN_MIDI_R, VOLUMEN_MIDI_L:integer); var MidiOutPutDev:string; amt,MidiOutputDevid,t:integer; MidiCap:TMIDIOUTCAPS; begin with TRegistry.Create do begin RootKey := HKEY_CURRENT_USER; OpenKey('Software\Microsoft\Windows\CurrentVersion\Multimedia\MIDIMap', false); if ValueExists('CurrentInstrument') then MidiOutPutDev := ReadString('CurrentInstrument'); free; end; amt := MidiOutGetNumDevs; MidiOutputDevid := - 1; for t := 0 to amt-1 do begin MidiOutGetDevCaps(t, @Midicap, Sizeof(Midicap)); if StrPas(@MidiCap.szPName)= MidiOutPutDev then MidiOutputDevid := t; end; midiOutSetVolume(MidiOutputDevid, (VOLUMEN_MIDI_R shl 16) + VOLUMEN_MIDI_L); end;
505
« en: Miércoles 1 de Septiembre de 2004, 18:34 »
Para juegos, SEGURO necesitarás aplicar matemáticas (cálculo principalmente) y física. Cálculo es una herramienta matemática CONTINUA y para aplicar sus herramientas al mundo informático (que es TOTALMENTE DISCRETO) tienes que hechar mano de las "versiones" discretas de cada herramienta. En otras palabras necesitas la versión traducida de cada herramienta (por ejemplo filtros) a matrices, multipicaciones y sumas. Por otro lado lo que en el mundo matemático podría ser realmente simple... los detalles de la implementación (y sobre todo la optimización, que muchas veces es realmente necesaria) pueden convertirlo en algo realmente complicado.
506
« en: Lunes 30 de Agosto de 2004, 22:50 »
Sólo agregar un detalle: Dudo que alguna aceleradora de video algún dia implemente un "circlefill", así que esa operación sólo se puede realizar moviendo la superficie a RAM y luego volver a moverla a video. Si realizarás cualquier operación de filtrado en alguna superficie, esta tiene que estar en memoria del sistema y no en tarjeta de video, o tendrás el mismo lío que en el caso: "copia de video a video cuando la tarjeta NO lo soporta" (Ver el mensaje de Juank.) Ya que para procesar la superficie, esta tendrá que ser copiada a memoria de sistema y luego de terminado el filtrado debe ser copiada a memoria de video. Aunque no creas esa "simple copia" entre memoria de sistema y de video puede ser realmente LEEEEENTA. (Eso muestra la gran importancia de tener tanta memoria como sea posible en la tarjeta de video, o aceleradora si prefieren y que esta tarjeta se encargue de todo el trabajo de filtrado para evitar a toda costa el trámite de pasar de memoria de video a Sistema y viceversa) Sólo cuando tu superficie esté totalmente terminada de "filtrar" la pasarás a video. P.D. Tal vez el problema más molesto del page flipping es cuando ocurre un error en tu programa, tu pantalla NO vuelve al estado normal: Todo negro y tienes que reiniciar.
507
« en: Sábado 28 de Agosto de 2004, 04:10 »
La idea básica del archivo con todos los cuadros (frames) de animación es esta:
1. Obtienes VARIOS archivos gráficos (con algún editor) cada uno con un cuadro de animación: caminando, parado, corriendo, etc. Y para cada dirección que sea necesaria: caminando a la derecha, arriba, abajo, etc.
2. Recortas los pedazos que no se usan en cada gráfico, las partes "transparentes", de forma que quede un rectángulo conteniendo el sprite.
3. Realizas un "collage" de estos gráficos de la mejor manera que puedas para evitar desperdiciar espacio. Es más práctico una collage por dirección del sprite (secuencia de caminando a la derecha, secuencia de caminando hacia arriba, etc).
4. Guardas en un archivo las coordenadas de los rectángulos que corresponden con cada "cuadro", esto tendrías que hacerlo para cada cuadro a medida que lo colocas en el collage. TU TIENES QUE SABER las posiciones x, y, por que tu armas el collage.
5. En tiempo de ejecución cargas en memoria los gráficos de los "collage" (secuencias de frames) y al momento de pintarlos en pantalla indicas el rectánculo origen correspondiente para cada cuadro (frame) de acuerdo a la acción, dirección y secuencia de animación del sprite.
¿Complicado?
Sin duda, es complicado. Puedes facilitarte las cosas si las dimensiones de los rectángulos siempre tienen el mismo ancho y alto, pero desperdiciarás memoria en cantidad.
¿Existen programas gratuitos que ya hacen esto?
Si, DelphiX tiene varias herramientas (gratuitas) para realizar esto y muchas otras cosas necesarias para programar juegos. Por supuesto que no es un hada madrina que hará el trabajo por ti, pero ayudará bastante.
508
« en: Sábado 28 de Agosto de 2004, 03:51 »
 Hola, una pregunta,cual creen ustedes que sea el lenguaje mas 'portable' para la programacion de juegos(yo creo que c y c++).Por que Java en Xp tienes que bajarte el Java, en assambler depende del hardware de la maquina etc.... Java fue diseñado para ser totalmente portable, desgraciadamente los afanes monopolistas de los que sabemos terminaron menguando dicha capacidad. Sin embargo aún así es mucho más portable que C++. El problema son las particularidades de cada compilador, ahí es donde falla la portabilidad. Por esto es importante realizar el diseño del sistema de tal forma que el grueso del código no dependa de bibliotecas externas que no sean 100% estándar. Sin embargo esa tarea no es fácil, ya que esas mismas bibliotecas externas son las que facilitan la programación. Pero si hablamos de portabilidad un juego que pueda ser jugado en un navegador estándar y gratuito como el mozilla se lleva la flor (hablamos de una combinación de HTML y javascript que se encargan de la interfaz con el jugador. En el servidor no habrá mucho problema: LINUX + la triada super conocida para aplicaciones basadas en WEB para base de datos) Si no me crees, echa un vistazo a este juego: http://www.astrowars.com/(Juego de conquista espacial gratuito, varios MILES de jugadores, acción TERRIBLEMENTE contínua en tiempo real: mientras duermes plácidamente pueden estar devastando tus planetas ) Un ejemplo de java con capacidades de 3D, basado en web: http://www.droidarena.com (Puedes ver en acción 3D a tu droid, peleando contra otros droid de otros jugadores de algún rincón del planeta. Tu programas a tu droid con un lenguaje del tipo "script", armas por módulos a tu droid con diversas armas, radares, blindajes, radios, procesadores, dispositivos especiales de todo tipo que son agregados a un "esqueleto base") Administras recursos, construyes una empresa para mejorar tus droids, realizas apuestas, puedes pelear en clanes programando a los droids para que trabajen en equipo y mucho más.
509
« en: Lunes 23 de Agosto de 2004, 19:59 »
hola un saludo a todos.
Este foro es la unica forma de despejar mis dudas, no tengo algo de donde aprender, ni libros, algunas paginas...
Me gusta mucho programar, y creo que la causa fue pensar llegar a ser un VJ.
pregunto, como puedo desarrolar un detector de colision, para sprites de formas diferentes, creo que eso se hace colisionando pixel por pixel, desarrollado con funciones allegro?, o si no es asi solo el algoritmo.
si alguien me pudiera contestar se lo agradeceria. 
JeoV.  En resumen en 2d: Mediante colisiones entre cuadrados, grupos de cuadrados, círculos, elipses, polígonos, etc. Generalmente los algoritmos de colisión a nivel de pixeles se optimizan con un algoritmo de colisión de rectángulos. Cuando existe intersección se realiza la comprobación a pixeles en el área de intersección. Otra alternativa bastante buena es que exista un algoritmo que a partir del sprite defina unos cuantos (unos 3) rectángulos cuya unión represente en buen nivel la forma del sprite. Comprobar colisión entre rectángulos es bastante fácil y optimizable. En juegos de vista isométrica son bastante prácticos simples cuadrados y elipses, incluso si tienen gráficos en 3d por el tipo de vista de cámara que usan no se ven a simple vista los defectos de este tipo de colisión. (Mientras juegas difícilmente y en raras ocasiones podrás notar claramente que existe "algo raro" y que los personajes se fusionan en algunas partes)
510
« en: Lunes 23 de Agosto de 2004, 18:23 »
Bueno, Bueno, Bueno, aun espero algún alma caritativa que me muestre el camino.¿alguien que se ofrezca a mostrarme un poco de código?¿BMP de 8,16,24,32 bits? Para ver código mejor bajas un open source de Sourceforge, por ejemplo para Delphi tienes el delphiX que es un paquete de componentes para crear juegos usando directX. DelphiX (unos cuantos megas) facilita muchísimo la creación de juegos con delphi en 2d y 3d, al punto que si quieres usar un sonido, lo editas y luego lo agregas con las opciones de la paleta de propiedades, lo mismo con los gráficos. Existen además otras herramientas para 3d para utilizar archivos .dxf y convertirlos en archivos .x de directx, lo cual es bastante útil para agregar objetos 3d a tu juego. Por supuesto lo mejor es que el código es open source y podrás ver personalmente como se programó cada parte de esta biblioteca de componentes. Si trabajas con el visual C++ puedes bajarte un paquete completo (sdk) para directx que si mal no recuerdo ocupa unos 130 a 200 megas e incluye ejemplos básicos de como usar las bibliotecas directX.
511
« en: Viernes 13 de Agosto de 2004, 18:50 »
No diría que son dos "métodos generales" pero dos situaciones distintas. Generalmente si manejaras tal cantidad de información que no "entre" en RAM utilizarás algún manejador de base de datos.
1.- Si, por supuesto, no esperarás a que se tenga que cargar en memoria (aunque sea virtual) toda esa información: imagínate si lo que deseas buscar está entre los primeros segmentos de información, cargar toda la información a memoria del sistema (RAM o virtual) sería un gran desperdicio. Existen cientos de formas cada una adecuada a un caso particular para administrar esa información, todo depende del problema y los recursos que tengas a mano.
2.- Si (mientras se ejecute tu proceso), pero si el procesador ejecuta otro proceso y le falta RAM, tu proceso y su área de memoria se van a disco duro (memoria virtual) para hacer espacio para el proceso con el que está trabajando. Luego cuando continue con tu proceso volverá a colocarla en RAM y lo que antes ocupaba la RAM necesaria para tu proceso se ira a disco duro. De ahí la importancia de tener grandes cantidades de RAM (ahora que es barata) para evitar en lo posible esta situación.
512
« en: Jueves 12 de Agosto de 2004, 18:40 »
si el problema son las imágenes, en html existe la posibilidad de indicar una imagen de mucha menor resolución para que sea cargada antes que la imagen propiamente dicha.
Mejor si diseñas la página de forma tal que aunque los gráficos no fueron cargados se pueda ver claramente las opciones de menús y textos breves que indiquen que contiene cada "espacio en blanco".
Otra opción puede ser bloques de código JS a lo largo de la página que cambien el título de la página o algo visible con un porcentaje a grandes rasgos: 25, 50, 75% ...
513
« en: Martes 10 de Agosto de 2004, 19:05 »
Vamos a ver.
Tambien lo cargo en una clase bitmap, el codigo que tengo es para cargar archivos BMP de 8bits. El problema es que si creo un bitmap con algún programa de dibujo no lo puedo mostrar, y eso que lo pongo a las mismas caracteristicas que el otro, y si lo muestra no sale la imagen bien.
Quisiera saber como cargar archivos BMP en clase bitmap de 24 y 32 bits y luego poderlos mostrar por pantalla, lo mismo para los sprites.
Si teneis el código a ver si lo podeis poner a disposición de todo aquel que como yo se hace la picha un lio con esto de la carga de archivos BMP u otros formatos.
Algún alma caritativa?  Generalmente prefiero usar BMP de 8 bits para tener los gráficos listos para editarlos, o mi propio formato: dimensiones, bits por pixel, indice de colores si corresponde y datos. Es que es mejor no desperdiciar espacio en disco, aunque luego tu BMP lo pases a 16 bits por pixel para superficie directDraw, o lo que tengas que usar. Realmente admiro como hicieron la saga diablo con 256 colores!, conocimiento tremendo de la teoría del color!!. Usar 256 colores tiene sus ventajas: velocidad trucos interesantes para cambiar el color de los sprites... pero preparar las imágenes para que todas correspondan con la misma tabla de colores y obtener un resultado visualmente tan bueno no es cosa fácil... Usando JPG puedes comprimir mucho más perdiendo calidad, pero no es recomendable para sprites, sino para imágenes de fondo o cualquier otra que nunca tengan partes "transparentes".
514
« en: Miércoles 4 de Agosto de 2004, 05:13 »
hola
quisiera saber si alguien tiene idea, mas bien sepa como se hace
que una secuencia de teclas  aga un movimiento
tipo juego de pelea.
1salu2 Tomando las ideas publicadas: Un simple buffer común y corriente POR JUGADOR pero con: 1.- Filtro para guardar sólo las teclas correspondientes a cada jugador. 2.- Guardar en tiempo transcurrido entre tecla y tecla ingresada en buffer para ahorrar líos de timer que no son pocos. Finalmente: 3.- Simplemente revisar el buffer como cadena de texto para encontrar la secuencia deseada. Si se la encuentra revisar que la suma de tiempos transcurridos sea menor a un umbral aceptable. Ejemplo típico de "brutality" MK "arriba,derecha,izquierda,abajo, salto, puñete, arriba, derecha,izquierda,puñete fuerte, patada media, puñete débil, patada fuerte... etc" El anterior ejemplo, digamos una secuencia de 50 teclas presionadas en unos 5 segundos resultaría en un tremendo brutality. La ventajas de usar buffers y secuencias prácticamente en cadena de texto son bastante obvias: sólo tienes que poner en cadena de texto la secuencia de códigos de teclas y tener el tiempo máximo en el que tiene que presionarse la secuencia completa. Recomendable tener un buffer adicional que guarda el estado de "presionado" "no presionado" de las teclas, botones o lo que sea que trabaje junto con los buffers de secuencia de teclas presionadas.
515
« en: Domingo 1 de Agosto de 2004, 17:05 »
Mejor si el código muestra en pantalla en código que presionaste, el ASCII y el SCANCODE (mucho mejor si sólo nos importa la tecla que presionó el usuario y no exactamente el código ASCII)
516
« en: Viernes 30 de Julio de 2004, 16:04 »
Complicado... depende de lo que estás programando. Yo diría que ayuda bastante a evitar bugs, por la filosofía del mismo lenguaje: orden y tipos fuertes. Si quieres hacer trucos de optimización tienes que indicar al compilador claramente lo que quieres hacer, aunque el resultado compilado sea el mismo. Otra ventaja de delphi es la gran cantidad de componentes disponibles, arrastras un ícono y puedes usar el componente, sin mencionar que gran parte son open source y los puedes adaptar a tus necesidades específicas. Por ejemplo para programar videojuegos está el DelphiX, genial si estás comenzando a programar tu primer juego y quieres usar DirectX, DirectSound, Direct3d, DirectPlay, DirectInput, etc, sin meterte a fondo en detalles de programación. También es open source y te sirve para aprender.
Esas interfaces las puedes hacer con cualquier lenguaje que te permita comunicación TCP/IP, pero siempre existirá uno más adecuado que otro dependiendo del problema o requerimientos del sistema.
517
« en: Jueves 29 de Julio de 2004, 00:01 »
Se que existe edonkey, overnet, kazaa, emule... pero por motivos desconocidos hace tiempo que dejaron de funcionar en mi ordenador, 1.- Tienes versiones no oficiales que no comparten nada o tu calificación está en "sanguijuela egoista". 2.- Puertos bloqueados por tu ISP, configura otros. 3.- Gusanos, virus y otros bichos de todos tipo pueden estar engordando chupando todo el ancho de banda que tienes. ?? 
518
« en: Lunes 26 de Julio de 2004, 23:34 »
La facilidad de hacer eso depende también del compilador, en algunos existe la opción de elegir el archivo dll y te genera un .h para utilizarlo, con todo el código extra necesario y listo para usar!.
519
« en: Lunes 26 de Julio de 2004, 23:27 »
Si quieres arrastrar y soltar, fíjate en los ejemplos que vienen con delphi.
Demo: RichEdit
Busca
" procedure TMainForm.WMDropFiles(var Msg: TWMDropFiles); "
Así veras todo lo que necesitas para activar "arrastrar y soltar",
520
« en: Lunes 26 de Julio de 2004, 23:14 »
a ver si entendi... si creo un videojuego comercial utilizando openGL no tengo que pagar pero si quiero crear un driver para una tarjeta de video (incluso si yo no soy el fabricante) si??  Si creas un juego comercial usando opengl no pagas (sólo usas la biblioteca). Si creas un driver a partir del código OpenGl si pagas (creas una nueva biblioteca para una tarjeta en particular) P.D. ...crear un driver para una tarjeta de video de un determinado fabricante... Sólo si te pagan, te dan las especificaciones de la tarjeta al detalle máximo... nadie en su sano juicio haría eso gratis por que sólo beneficias a la compañía que fabricó la tarjeta (SE SUPONE QUE LOS DRIVERS LOS HACEN LOS FABRICANTES DE SOFTWARE), además que tendrías que sacar, yo no se de donde, las especificaciones de como usar la tarjeta gráfica X, modelo Z de la empresa Y.
521
« en: Lunes 26 de Julio de 2004, 19:52 »
 Recuerdo esos dían donde tenías que encajar el DOS donde pudieras para tener 600Kb de RAM para correr un juego con sonido Sound Blaster como DarkSeed. Recuerdo que la clave era activar la XMS con el himem, el EMS con el emm386, encajar el DOS=HIGH, conseguir el driver más pequeño para ratón y volar los archivos DRVSPACE, DLBSPACE para lograrlo. P.D. Usar XMS o EMS en estos días? Que masoquistas...
522
« en: Sábado 24 de Julio de 2004, 05:20 »
Y si, con Pascal, muy lejos no llegas a menos que sepas Assambler(los 'programadores' de Pascal lo conocen demasiado bien) y para eso
uso Assambles sin Pascal y punto.
He visto algunos codigos fuente de Pascal dry.gif "avanzados" y son puro assambler ¿Y donde quedó Pascal? "Y si, con Pascal, muy lejos no llegas"... Eso depende del compilador que uses. En el caso de que uses Delphi (Object Pascal) es mejor escribir cómodamente el 99% del código y sólo usar assembler en el 1% crítico. Para encontrar un bug generalmente tienes que revisar un montón de codigo y todo el codigo relacionado con el problema si no tienes idea de lo que puede estar pasando. El pascal es mucho más cómodo por el control estricto de tipos y por el mismo lenguaje para revisar bugs, además que obliga a ser ordenado. No quisiera pensar ni por si acaso en revisar un bug en un código ASM extenso y del cual no tenga una versíon que funciona bien (en caso de emergencia ) en un lenguaje de alto nivel como pascal. Por otra parte para optimizar código tienes que focalizarte en un porcentaje reducido de código y que generalmente es bien comprendido y documentado antes de realizar la optimización. En resumen: Usar un lenguaje cómodo te ahorra tiempo y trabajo para focalizarte en puntos críticos.
523
« en: Viernes 23 de Julio de 2004, 19:55 »
... sum +=(f( b )-f( a ))/2; //Línea adicional ... //justo antes de: sum *= dx Esto debería hacerlo un poco más preciso en la gran mayoría de los casos con sólo agregar una línea de código.
524
« en: Viernes 23 de Julio de 2004, 06:20 »
Verdugo...  La verdad que no conozco ese juego... tal vez con otro nombre pero... "verdugo" no. Podría ser el juego del ahorcado???  ???
525
« en: Jueves 22 de Julio de 2004, 01:09 »
Me tarde todo el fin de semana... P.D. Actualize los links: +midis, +niveles. +reflejo de nivel (voltear en horiz, vert, rotar 180º). P.D. El programa sólo usa lo estándar que viene con delphi. Los "uses" del archivo principal: uses Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs, Menus, ExtCtrls,Juego, MPlayer; "Juego" Es la biblioteca (que no usa otras funciones externas a parte de dos del sysutils) donde está la médula del juego las clases TJuegoSokoban y TTablero.
Páginas: 1 ... 19 20 [21] 22 23 ... 27
|
|
|
Mostrar Mensajes
