|
|
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 - Geo
Páginas: 1 ... 34 35 [36] 37 38 ... 41
876
« en: Miércoles 29 de Diciembre de 2004, 22:03 »
Allegro es una librería para juegos que se maneja en C/C++, por lo que (como EugenioEnko apuntó) debes saber programar en ese lenguaje para poder emplear la librería. Por otra parte, actualmente existe Fenix, que está basado en la sintaxis de DIV: programación de procesos, es gratuito y de código abierto. Puedes encontrar información en http://fenix.divsite.nethttp://divnet.divsite.netSaludos, José Jorge (Geo).
877
« en: Miércoles 29 de Diciembre de 2004, 02:33 »
Lamentablemente no conozco NINGÚN sitio, ni en las comunidades DIV ni en las de Fenix de donde se pueda descargar (jeje, yo hace algún tiempo encontré Div2).
No sé, podrías probar en el eMule.
Saludos,
José Jorge (Geo).
878
« en: Martes 21 de Diciembre de 2004, 04:43 »
no he usado OpenGL, pero para escribir texto lo mejor es usar SDL_Font, en la página de SDL la encuentras.
Saludos,
José Jorge (Geo).
881
« en: Miércoles 17 de Noviembre de 2004, 02:49 »
Excelente juego, sólo me gustaría que también se incluyera el ejecutable en la descarga, por todos aquellos que tengan problemas para compilarlo  . Saludos, José Jorge (Geo).
882
« en: Sábado 13 de Noviembre de 2004, 22:10 »
883
« en: Viernes 12 de Noviembre de 2004, 21:48 »
Busca Milkshape.
Saludos,
José Jorge (Geo).
884
« en: Jueves 11 de Noviembre de 2004, 02:23 »
Pues no se la neta es que yo soy un chico estudiante de ingenieria en sistemas computacionales (creo que todos los que andan posteando por aqui) y la neta a mi me enseñan en la escuela a usar el compilador de ms-dos de borland c.
a mi no me gusta y lo mismo digo de la diferencia de linux , unix , windows para que chingados te sirve saber progamar una pantalla en modo ms-dos si en teoria se puede hacer bajo ambiente windows mas facil y eficazmente (potencial), lo mismo va los programadores como somos tantos y si todavia te limitas solo a programar en linux sirves para dos cosas para nada y ni madres porque porque lo que vende o se necesita es saber programar en el sistema pra dummy´s.
como le vas a vender a alguien que sabe programar un porgrama que hace numeros aleatorios por ejemplo. Es que la idea más aceptada sobre aprender a programar en C/C++ es aprender en entorno de consola, porque te enfocas en aprender rápidamente la estructura del lenguaje y no librerías externas. Una vez dominado el lenguaje, puedes optar (claro, por tu cuenta ya) por aprender la librería que prefieras: para programar en Windows, la WinAPI o la MFC de Microsoft, o también la VCL de Borland (usando Borland C++ Builder). En Linux normalmente se programa usando la librería nativa de tu distribución, p. ej. en Gnome se usa GTK y en KDE se usa Qt, pero afortunadamente varias de estas librerías son multiplataforma (también funcionan en Windows), por lo que no quedas tan "limitado" en un principio. Aunque eso si, MS domina el mercado y si vas a realizar aplicaciones comerciales lo más probable es que desarrolles Windows (la mayor parte de empresas de software trabajan bajo este SO, aunque también hay cada vez más que trabajan en otros como Linux), y también hay que poner atención al nuevo Windows (Longhorn) que implantará completamente la plataforma .NET; pero bueno, eso ya son otras cosas. Lo importante es que no desprecies el aprender C/C++ bajo MS-DOS, aunque eso si, podrías actualizar tu compilador (si es que estás usando Turbo C/C++)  . Saludos, José Jorge (Geo).
885
« en: Lunes 8 de Noviembre de 2004, 23:01 »
Simplemente se trata de elegir la herramienta más adecuada para completar los requisitos que se tengan. Comparto esa frase. También, si no me equivoco Blitz Basic soporta DLLs, por lo que se pueden implementar algunas características (claro, programándolas en C/C++ o Delphi por ej.) con las que no cuente . Saludos, José Jorge (Geo).
886
« en: Viernes 5 de Noviembre de 2004, 04:45 »
lo de string sólo lo puse porque es mucho más sencillo hacer esto: string a, b; a = "cadena de texto"; b = "otra cadena de texto"; if (a == b) { cout << "las cadenas a y b son iguales\n"; }
que comparar los "arrays de caracteres" (cadenas en C) posición por posición. Aunque igual, se puede hacer uso de la función strcmp(const char*, const char*); (tienes que declarar la librería string.h) si se trabaja en C. Esto porque normalmente las cadenas de caracteres no se comparan posición por posición como lo estaba haciendo wanaya, mejor hacemos uso de las funciones que para ello tenemos . Saludos, José Jorge (Geo).
887
« en: Miércoles 3 de Noviembre de 2004, 16:28 »
Qué tal, lamentablemente no tengo respuesta a tu duda y al contrario quizá la amplie un poco . Yo también he estado buscando la manera/librería por la cual decantarme para crear GUIs en mis programas en C/C++, pero definitivamente no hay una solución definitiva que cubra todo y que se ajuste a todo  . Además de wxWidgets (wxWindows cambió su nombre a este por presión de Microsoft  ), también están (aclaro que no las conozco muy bien y quizá me equivoque en mis comentarios): - Qt, portable, gratis para proyectos personales, hay que pagar para proyectos comerciales. Librería empleada en la distribución KDevelop de Linux. Según comentarios, es muy buena, aunque creo que sólo para C++.</li>
- GTK, portable, gratuita, empleada en la distribución Gnome de Linux. Nació con el programa gráfico The Gimp (GTK: the Gimp Tool Kit). Su principal diferencia es que puede usarse también en C (y en C++, por supuesto).</li>
- Fox toolkit, portable, he oído menos menciones de esta pero todas apuntan a que es muy buena, se había detenido su desarrollo pero al parecer va a continuar .</li>
Yo me había inclinado a usar wxWidgets, pero aún no domino C++ (programo en C). Sin embargo, el emplear una librería de este tipo si se desarrolla principalmente en Windows (mi caso) representa algunos problemas y limitaciones: es muy cierto que las aplicaciones estarán listas para ser portadas a otros SO como Linux de manera mucho más rápida que usando la WinAPI, pero para hacer cosas específicas de Windows la WinAPI me parece que siempre será el camino a tomar. Una duda que tengo es la siguiente: si quisiera por ejemplo crear una aplicación extendible mediante plugins, supongamos que se trata de un programa de edición de gráficos, para que los plugins pudieran manipular la imagen en turno habría que pasarla a las funciones del plugin de alguna manera. En Windows supongo que se pasa el handle a la ventana de la imagen o el HDC en cuestión (o sería una manera de hacerlo), pero si decidiera usar GTK o wxWidgets, ¿qué es lo que se pasaría? ¿es posible hacer esto? ¿estas librerías multiplataforma serían capaces de recibir un HDC de la WinAPI como parámetro y manipularlo o realizar una conversión y manejarlo? No sé si alguien pudiera responderme en esta discusión, pero creo que son algunas dudas que alguien buscando elegir una librería GUI pudiera llegar a tener . Saludos, José Jorge (Geo).
888
« en: Lunes 1 de Noviembre de 2004, 21:49 »
Como juank mencionó, la librería contenida en graphics.h que se incluye con el compilador TurboC/C++ no pertenece al estándar ANSI C, por lo que sólo está disponible en dicho compilador. El compilador GCC está bastante apegado al estándar y no incluye ninguna librería gráfica, puedes probar utilizando Allegro que es multiplataforma (funciona en Windows, Linux y algunos más); también hay otra librería multiplataforma: SDL. Creo que con cualquiera de esas dos puedes hacer sin problemas lo que hacías en Turbo C, e incluso más  . Y para quien empezó la discusión, este enlace puede servirle: http://pinsa.escomposlinux.org/sromero/art.../gfx/graf1.htmlSaludos, José Jorge (Geo).
889
« en: Viernes 29 de Octubre de 2004, 04:42 »
pues ya que estás en C++, aprovecha y usa string, es mucho más fácil manejar "cadenas de caracteres" que con char *.
Saludos,
José Jorge (Geo).
890
« en: Miércoles 27 de Octubre de 2004, 04:32 »
Sues si el dispositivo es comercial, para la comunicación te conviene emplear el software que para tal efecto te ofrezca el fabricante. Aunque quizá el mismo dispositivo tenga integrados algunos protocolos de comunicación estándar (HART, PROFIBUS, etc.), entonces si podrías emplear CUALQUIER programa/aplicación que soporte el protocolo de comunicación deseado.
Por otro lado, si tu idea es diseñar algún dispositivo tú mismo para monitorear alguna variable o sistema (para algo simple no es tan complicado, necesitas un sensor que te de alguna salida de voltaje o corriente, luego un convertidor A/D y ya con eso lo que te haría falta sería el software de control y/o monitoreo), te recomendaría Visual Basic (si no has programado y quieres hacer algo lo más pronto posible) o Delphi.
Saludos,
José Jorge (Geo).
891
« en: Viernes 22 de Octubre de 2004, 23:36 »
No entiendo eso. Los buenos programadores son todos de Linux... A mi también me gusta. Windows es muy malo y mas encima nos obligan a usar eso. Por eso lo odio, pero no se pregunto eso en este foro  :smar  tass: Windows no es malo, como tampoco TODOS los buenos programadores están en Linux (y recordemos que también existe Mac, BSD, Unix y muchos más). Tanto decir uno como lo otro es precipitar una opinión basándose en prejuicios que últimamente se han desatado por la carga anti--Microsoft que sus políticas han generado. Por otro lado, nadie nos obliga a usar tal o cual cosa, sin embargo hay que estar consciente que Linux aún no cuenta con el soporte suficiente para los usuarios finales NO programadores (en oficinas y hogar, principalmente), pero tampoco se puede decir que sea malo (que no lo es), simplemente que le falta camino por recorrer para instalarse en las oficinas y hogares del mundo además de los servidores . Lo que nos importa es tratar de ser mejores cada uno de nosotros, sin importar en donde nos desenvolvamos . Bien se podría separar esta discusión en dos ¿no? Sobre el tema del motor, no puedo participar (al menos respondí ), pero si se puede me gustaría echarle un ojo a lo que se tiene . Saludos, José Jorge (Geo).
892
« en: Jueves 21 de Octubre de 2004, 22:16 »
Es muy cierto que hay muchas propuestas como esta que no han prosperado, pero se debe más a la falta de consistencia y disciplina que a otra cosa (aunque eso si, el contacto vía internet aún supone cierta dificultad no muy fácil de sortear). Lo que te recomiendo es que sigas por un rato por tu cuenta y hagas varias cosas hasta dominar la librería y el lenguaje por los que te decidiste, entonces, cuando estés listo para iniciar un proyecto más grande, podrás buscar gente con tus mismos intereses y te aseguro que entonces si se podrá pasar a crear un juego. Esa es la opción por la que me he decantado, ahora estoy aprendiendo C++ aunque en tanto he hecho varias cosas con C y Allegro, pero quiero dominar C++ y lo de la orientación a objetos antes de poder participar en un grupo . Lo que si te recomiendo es paciencia y consistencia, con disciplina poco a poco lograrás avanzar, te lo aseguro. Saludos, José Jorge (Geo).
893
« en: Martes 12 de Octubre de 2004, 22:00 »
Recuerda que cronodragón recomienda a menudo Blitz Basic para empezar o para crear algún demo , él conoce más sobre dicha herramienta. Saludos, José Jorge (Geo).
894
« en: Martes 12 de Octubre de 2004, 01:15 »
Creo que puede aprovechar mejor la herramienta que usaste para hacer cosas mas poderosas, aunque en verdad dezconozco las capcidades de la herramienta. Blitz Basic es más sencillo que C/C++, Delphi, etc. Pero tampoco es lo sencillo que alguien pudiera imaginar, aún hay que aprender un lenguaje para poder realizar las aplicaciones, no hay manera de hacer cosas al estilo arrastrar y soltar, a mi parecer, esto no le quita nada de mérito al juego. No pude probarlo a fondo, pero te felicito, lo que ví me pareció MUY BUENO. El tamaño del juego se debe obviamente al formato de los archivos de audio, lo que quizá podrías hacer es ofrecer la posibilidad de no jugar con audio o tener dos opciones, baja y alta calidad, desde una página cada quien que se descargue la versión que más le acomode  . Saludos, José Jorge Geo.
895
« en: Martes 12 de Octubre de 2004, 00:34 »
sólo un comentario, ni OpenGL ni DirectX son lenguajes, sino APIs. Ambas son manejadas con los lenguajes C/C++, DirectX puede usarse con Visual Basic y Delphi también.
Saludos,
José Jorge Geo.
896
« en: Domingo 3 de Octubre de 2004, 17:58 »
Aquí encuentras ayuda para empezar: http://gda.utp.edu.co:9673/gdaPara crear programas con Allegro enlazados estáticamente, primero debes crear la librería estática (.a), sigue los mismos pasos que para compilar la librería dinámica: pero ahora agrega el parámetro STATICLINK=1 Aquí compila, y luego para instalarla: make install STATICLINK=1
Ahora, para compilar tus programas debes agregar lo siguiente: al compilador: y a la línea de comandos del enlazador (linker): -lalleg_s -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lole32 -ldinput -lddraw -ldxguid -lwinmm -ldsound
Saludos, José Jorge (Geo).
897
« en: Domingo 3 de Octubre de 2004, 17:20 »
¿porque en turbo c? porque quiero programar como juegos de atari, y mi duda es que quisiera saber como inserto las librerias a turbo c Para hacer juegos como los de Atari puedes usar hasta la última versión de DirectX, lo que tendrías que hacer es ponerle el "estilo" a tus juegos. Te recomiendo que uses la versión más reciente de Allegro (estable: 4.0.3, WIP: 4.1.15), con Dev-C++ (gratuito) o Visual C++ (si lo tienes), para lograr ese estilo de juegos usa resoluciones pequeñas (digamos un 320x200 p. ej.), y pocos colores (un máximo de 256 colores, Allegro los soporta perfectamente, hasta te permite más efectos con los difuminados entre paletas). Saludos, José Jorge (Geo).
898
« en: Sábado 2 de Octubre de 2004, 16:40 »
si no me equivoco Allegro nunca funcionó con TurboC, si quieres un compilador "de ese estilo" prueba con DJGPP.
Saludos,
José Jorge (Geo).
899
« en: Domingo 26 de Septiembre de 2004, 01:46 »
Dreamcast no fracasó por si misma, en si era (es) una consola con muy buenas características, además amigable para los desarrolladores.
Sin embargo, lo que la hundió fue el pesimismo por la consola anterior de SEGA: la Saturn (muy mala) y la gran estrategia publicitaria de Sony con su PS2 (que según decían superaría por MUCHO a la de SEGA, lo cual no fué cierto, pero en fin).
Saludos,
José Jorge (Geo).
900
« en: Lunes 20 de Septiembre de 2004, 19:11 »
Esta fué una típica discusión (al menos lo imagino) en el momento en que aparecieron los primeros lenguajes de alto nivel contra el ensamblador (y luego la siguiente generación de lenguajes de alto nivel contra la primera), siempre se dice que un lenguaje de alto nivel será más lento que el ensamblador, pero eso en muchos casos deja de ser cierto si se programa bien, además de que cada vez contamos con procesadores mucho más rápidos.
Por otro lado, ¿quién quiere mantener un código escrito completamente en ASM? Lo que se gana con los lenguajes de alto nivel es rapidez de desarrollo, además de una mayor flexibilidad al momento de mantener y/o actualizar el software.
En un videojuego profesional muy probablemente se programe en C++ el 95%, y el resto en ASM, pero sólo en aquellas partes donde sea evidente la ganancia en eficiencia y/o velocidad.
Saludos,
José Jorge (Geo).
Páginas: 1 ... 34 35 [36] 37 38 ... 41
|
|
|
Mostrar Mensajes
