Ver la versión completa : Visual Basic??
He buscado sobre el tema, pero no e encontrado nada que me aclare... :confused:
Mi duda es: se pueden hacer juegos con el visual basic para la gp32¿¿
Si es asi, me podriais indicar que necesito?
Gracias, y un saludo.
pues nidea, dudo que con el lenguaje visual basic se pueda ya que es de microsoft, lo que se es que puedes compilar con el visual studio para la gp32
Un saludo
Pero visual studio no deja de ser un pakete que contiene el visual basic, no??? o eso creia hasta ahora... xD
claro, quiero decir que puedes compilar para gp32 con el compilador de visual basic, weno eso creo. Pero no sera para el de visual c? :confused:
Un saludo
a, ok xD
y sabes ke mas necesitaria aparte del visual studio, klaro?
timofonic
25/06/2004, 00:56
No, no puedes hacer juegos con visual basic, visual basic es una mierda, si quieres hacer juegos en gp32 usa C/C++ (este ultimo creo que hay problemas), fenix, zot o algun engine de esos de rpg si es para rpg, kof91 o BOR...
Mirate esto www.freepascal.org pero tampoco podras hacer juegos para gp32 con eso...
Propeller
25/06/2004, 07:43
visual basic es una mierda
Creo que ahí te has pasado en tu habitual negativismo. Puedes decir que no te gusta (como a mi, que lo odio), dar una opinión fundada sobre el lenguaje o decir simplemente que no le sirve para lo que quiere, pero lo que no puedes hacer es decir que ese lenguaje/bibliotecas/intérprete es una mierda, puesto que cumple de manera brillante su función. Y es que fue diseñado para la creación rápida de interfaces gráficos basados en windows, y eso lo hace muy bien (mejor que Visual C/C++).
Hay que medir mejor las palabras, hombre.
Propeller
No se deberia de poder hacer videojuegos con VB :( , ya que, como VFP, entre otros, son lenguajes de programacion que generan ejecutables para ser utilizados ejecutados en Windows y sólo en windows (txungueces de funciones y librerias, a mi no me mires que yo no tengo la culpa:D )
Yo lo que te puedo asegurar es que los programas que he hecho con estos leguajes no los he podido ejecutar en amquinas con otros sistemas operativos que no sea Windows (lo que me ratifica lo indicado arriba)
Propeller
25/06/2004, 08:20
Bueno, como parece que no ha quedado nada claro:
NO, no se puede. ¿La razón? Visual Basic es un lenguaje interpretado (como Java, más o menos). Eso quiere decir que, de buenas a primeras, necesitas un intérprete para la máquina donde quieras ejecutar tus programas. Y para Gp32, no tenemos un intérprete de Visual Basic. Además, todas esas funciones que decís, son programadas por Microsoft para Windows y para VB, con lo que jamás vereis portada una aplicación de VB para Windows en gp32 mientras siga la política actual de M$.
En resumen, que todo lenguaje interpretado necesita de un intérprete, y si no lo hay, hay que hacerlo.
Propeller
Bueno, pues habrá que empezar a aprender a programar en otro lenguaje... xD
Me recomendais alguno en especial?? :p
Muchas gracias por responder a todos!
Un saludo.
timofonic
25/06/2004, 09:21
- Fenix es un lenguaje interpretado para hacer juegos, no es jodido de aprender, tiene sintaxis parecida a C y se pueden hacer cosas curiosas.
- Zot! dicen que no esta mal pero no conozco a gente que lo use, no se si solo vale para rpg...
- kof91 pues es para hacer juegos de lucha, tu eres uno de ellos y el otro es la cpu, creo que no soporta el gplink.
- C/C++ es con el que mas posibilidades tendras, tanto en GP32 como en muchisimas otras plataformas ( tanto de videojuegos como ordenadores ), puede resultar algo mas dificil que el resto pero luego veras su increible potencial, y practicamente los limites seran los conocimientos que tengas y "tu imaginacion" ( y que lo que hagas este lo suficiente optimizado para que vaya bien en la plataforma para la que se ha programado, claro ;) )
De los que te he dicho, el mejor es C/C++, es mas potente y al no ser interpretado es mucho mas rapido, si bien es recomendable si programas para GP32 que aprendas un poco de ASM de ARM para optimizar rutinas graficas y tal. El C/C++ al principio te va resultar mucho mas dificil que Visual Basic ( aunque considero VB como un lenguaje de programacion muy lioso y no me gusta su estructura ), pero luego veras la diferencia a mejor. C++ da problemas con GP32 de momento, desconozco si ya se solucionaron estos.
PD: Vale, el comentario que puse pudo ser bastante negativista, pero es que soy asi...
Un pequeño paréntesi:
Pues a mi me gusta bastante el Visual Basic.
Es el lenguage que utilizo profesionalmente, aunque si hubiera escogido yo, hubiera escogido el Delphi.
Es verdad que el VB puede ser un poco lioso, pero si programas con su funciones objeto (classes, col·lecciones, propiedades, ...)entonces se vuelve muy estructurado y se pueden hacer cosas muy interesantes. Y tiene el mejor entorno de depuración que conozco.
Lo que menos me gusta del VB es que no puedes crear un .exe autónomo y que necesitats bastantes .dlls.
Pero contráriamente a lo que se ha dicho, el VB 6 no está interpretado, está compilado. Necesita sus runtimes es cierto, pero está compilado. Aunque también puede ser interpretado si se ejecuta desde su entorno de desarollo.
Propeller
25/06/2004, 11:52
No me has convencido. Hasta donde yo se, el VB tiene la opción de ser compilado (dentro del VBStudio), pero desde el principio de los tiempos ha sido interpretado.
Incluso el Basic normal era interpretado.
Propeller
(_=*ZaXeR*=_)
25/06/2004, 19:38
Bueno no se muy bien si os estais liando, o entendeis cosas distintas por interpretado, que es posible.
La cosa es que a mi visual basic tambien me parece muy bueno, osea mas que bueno facil de usar con resultado de aplicaciones potentisimas. Lo de que es compilado pues no, no lo es aunque genere un exe, porque ese exe sin las dlls de otros programas no vale para nada. Claro si nos ponemos asi es una mezcla de interpretado y de compilado, pero compilado puro y duro no es, porque depende del sistema operativo al 100%, si el sistema no tiene instaladas las dlls que necesita no funcionan los programas, osea que esto nos hace pensar en interpretado, pero sino tenemos el exe no hay programa, esto nos hace pensar en compilado. Yo diria que es un hibrido extraño muy potente (bueno no es tan flexible como visual c, pero cada cosa esta enfocada de distintas forma) Esta claro que visual basic es potentisimo y simplifica bestialmente el trabajo para hacer aplicaciones a medida (aunque siempre tengas que acudir a SQL para hacer las cosas bien hechas)
Bueno, el tema de la programacion en visual basic para la GP32, pues es un pequeño error, visual basic es uno de los programas del Visual Studio, pero muchos inexpertos confunden Visual Studio con Visual basic (y otros muchos no tan inexpertos :p ). Lo que si se puede hacer es programar con Visual C++ que viene en el paquete Visual Studio, y ademas es algo que aconsejo encarecidamente, porque eso de usar el gcc para compilar no es tan agradecido como ver las lineas que tienes mal y que puede estar fallando (aunque siempre es puede, porque se equivoca mas que la aramis), probar en tiempo real los errores, poder depurar... la verdad es que a mi me parece la mejor opcion, aunque no se lleve muy bien con los punteros.
Mas info en la Web de NURIA (la cual aconsejo a todos)
mortimor
27/06/2004, 16:35
No quiero que se me caliente la boca, pero... Zaxer, sabes de que hablas realmente??? desde cuando por utilizar DLLs un programa a de ser interpretado??? *****... hablar con un poco de propiedad.
Visual Studio es un IDE -> Entorno de desarrollo interactivo
Visual Studio permite utilizar diferentes compiladores y puede interpretar el codigo en varios lenguajes que soporta para mostrarlo de forma que facilite la manipulacion de los ficheros de un proyecto.
Visual Studio puede utilizar lenguajes de programacion como C, Basic o Java y lenguajes de etiquetas como HTML, XML, ...
Efectivamente se puede "compilar" para GP32 con el compilador de Visual C++. Compilar exactamente ->> NO; no genera codigo para GP32 pero permite ver si utilizando las funciones del SDK de GP32 el programa funcionaria -->> genera codigo para windows.
(_=*ZaXeR*=_)
27/06/2004, 22:59
mortimor, creo que un poco si se de lo que hablo, aunque admito que solo un poco, solo he hechoun par de cosas en visual basic, mi proyecto de fin del modulo fue una aplicacion bastante importante, he hecho dos aplicaciones comerciales a medida para una cadena de joyerias, un par de troyanos y muchas cosas mas de andar por casa, proyectos de la carrera etc.
Cuando digo que yo entiendo que el uso de dlls hace pensar que es un lenguaje interpretado, es una apreciacion propia, y que la verdad me parece bastante acertada si se tiene en cuenta lo siguiente. Las dlls son las que contienen todo el codigo de los controles que utiliza visual basic, con sus metodos, atributos... algunos de estos controles, objetos o como querais llamarlos, osea los tipicos OLE, pertenecen al sistema operativo (bueno realmente la mayoria) puesto que visual basic fue pensao para que el programador se olvidara de todo lo referente a la gestion del raton, maximizar ventanas, y otros pertenecen a otras aplicaciones instaladas en el pc, sin las cuales no se podrian hacer ciertas cosas, como puede ser el windows media player o el internet explorer, lo cual permite que cualquier programador los pueda usar. Visual basic es un entorno de desarrollo visual que hace uso de estos dlls que maneja e interpreta el windows, la creacion de botones, ventanas, cajas de texto... todo eso depende de windows, que los genera tomandolos de los dlls correspondientes. Basicamente el visual basic es un lenguaje interpretado por el sistema operativo, puesto que todos los elementos del interfaz son generados por el mismo, y todos eso elementos pertenecen a dlls que contienen su codigo correspondiente, solo una parte del programa depende de si mismo, y es la parte que corresponde al codigo escrito por el mismo programador, que basicamente lo qu hace es hacer de puente entre los controles, y llamar al control correspondiente que el SO se encarga de generar. Por lo tanto hay una parte compilada, y que es necesaria y opera por si sola, que es el exe del proyecto, y por otra parte hay codigo compilado en tiempo de carga que interpreta el sistema operativo que es el que se encuentra en los dlls, y que es la que se comunica entre si gracias al exe compilado (me diras que los dlls estan compilados...), este uso exclusivo de dlls para la programacion, es la que proboca una falta de flexibilidad inmensa, no se puede hacer uso de la maquina a bajo nivel, y no se pueden controlar otros aspectos que no existan ya es los correspondientes dlls. Creo que todo estos son motivos suficientes para decir que es interpretado, ahora bien, si quieres extrapolar mi afirmacion sobre Visual Basic a todos los lenguajes que hagan uso de dlls, como puesde ser Delphi pues tu sabras, pero yo no lo he dicho, son cosas totalmente distintas, ademas de que hay que diferenciar entre las dlls del SO y las de otros programas.
Creo que aunque he tratado de explicarlo, sino se tienen en cuenta los matices, no se comprendera nada, no todos los lenguajes que usan dlls estan interpretados, no todos los interpretados tienen que usar dlls, hay diferentes tipos de dlls... bueno a mi ya te digo que me da absolutamente igual, porque estoy acostumbrado a que no se traten de entender las cosas, porque lo que mola es echar por tierra, es o no?
A mi si me dicen que tienes un lenguaje de programacion que se basa unicamente en el uso de librerias, las cuales las toma en un 80% del SO para generar sus interfaz, para gestionar el entorno, dispositivos de entrada salida etc etc, sin dejarte hacer uso de la maquina a bajo nivel precisamente porque el lenguaje se basa al 100% en el uso de dlls y no te deja una flexibilidad. Y ademas es imposible de portar por el mismo problema de la dependencia del SO por ese uso de dlls. Pues mira si profundizas en esto creo que es para decir: ¡¡¡ tio aqui lo que pasa es que este lenguaje no es compilado sino interpretado !!!, y precisamente por este uso de las dlls del sistema.
Ea a ser felices, que con todo lo que he dicho seguro que de loco paso a ser GILI..... o algo similar, y servira de entretenimiento para un rato largo, y surgiran debates como: las dlls estan compiladas? no veo diferencia entre dlls, de verdad sabes lo que es una dll? jode r de donde te has sacado todo este follon? de donde ha salido este? :pirado: .... y 1000 cosas mas, pero sino se lee como hay que leerlo pues que quieres que te diga, puedo decir misa y no tener efecto.
Enga a estudiar otras cuantas horas hasta que mueran las neuronas. :pirado:
Un saludo
Bueno, el tema empieza a gustarme :)
Me parece interesante tu interpretación de lo que para ti se puede entender como un programa interpretado :)
Pero vamos a ver, para que no haya confusión, que significa exactamente un programa interpretado y un programa compilado.
Un programa interpretado es un archivo que contiene pseudo instrucciones que no tienen nada que ver con las instrucciones en ensamblador del procesador sobre el cual tienen que correr el programa. Es decir que para poder ejecutar el archivo se necesita un programa especial, el interpretador, que se encargará de traducir cada pseudo instrucción a instrucciones en ensamblador para procesador en cuestión. En algunos casos, estas pseudo instrucciones son el código fuente del programa como por ejemplo en dBase o en Basic, en otros casos estas pseudo instrucciones están generadas a partir de un código fuente como pueden ser los applets de Java que no contienen código ensamblador i86 sino que contienen pseudo instrucciones ejecutables en cualquier tipo de ordenador.
Un programa compilado es un archivo de programa (en el mundo DOS/Windows: .exe, .dll, .com), que tiene, a parte de una cabecera con información, código ensamblador directamente ejecutable por el procesador al que va destinado el programa.
Eso no quiere decir que un código fuente de un programa en un lenguaje como el Basic será siempre interpretado. Todo depende de lo que se haya hecho con el. En tiempos del DOS existían varios Basic, el más conocido siendo el GW Basic que venía con el DOS. Este Basic era puramente interpretado, pero existía otro mucho más potente, el QuickBasic que era compilado. Tenías un entorno de desarrollo bastante sencillo con el que compilabas un programa .exe completamente autónomo y muy eficaz.
Un ejemplo aún más interesante era el caso del dBase. El código fuente de los programas dBase era interpretado, al menos en el caso del entorno de desarrollo de la casa que inventó el dBase (no recuerdo el nombre), pero también podía ser compilado por el compilador Clipper que saco otra casa (me parece que era Nantucket).
Hoy en día nos encontramos con lo mismo, en principio el C se compila, pero también hay interpretadores. El Visual Basic es interpretado cuando lo ejecutamos desde el entorno de desarrollo, pero una vez compilado es un ejecutable compilado de verdad (ver la pestaña opciones de compilación para ver que se puede optimizar para un Pentium Pro). Hasta la versión 4.0 el archivo genenerado contenía pseudo instrucciones, ahora contiene código compilado.
En definitiva, que en principio todo lenguaje se podría interpretar y/o compilar, aunque algunos sean más fáciles de interpretar que otros.
El que hace que un programa sea interpretado o no, no tiene nada que ver en la manera que cree una ventana, si lo hace a través de una .dll o directamente.
De hecho un programa en C compilado con Visual C++ necesita también sus .dll para funcionar, no es completamente autónomo. Hoy en día, bajo Windows, no existe un solo programa independiente, todos recurren a .ddls, que sean del sistema operativo, o que sean propias del lenguaje.
Y para finalizar, el decir que un lenguaje como el Visual Basic es interpretado porque hace un uso intensivo de .dlls para acceder a funciones de bajo nivel, no es cierta. Es solo que hay lenguajes que se han diseñado para esto como el C, y otros que no como el VB, que no tiene acceso a punteros por ejemplo y por eso recurre a .dlls creadas con otros lenguajes que si lo permiten.
Bueno, y decir que respecto a lo que toca la GP32, me parece en ciertos casos que debe ser más fácil portar un motor que interprete un lenguaje como el VB (hablo del lenguaje, no de los componentes que es capaz de ejecutar) que emular un procesador como los de la familia i86.
De hecho, ¿los programas DIV o FÉNIX no son programas interpretados? ¿O los de Scumm?
Estoy convencido que no sería demasiado complicado hacer un interpretador de algún Basic de DOS, o de Pascal.
¿Alguien no habló de crear un runtime de Java para la GP32?
Si voy equivocado, no dudéis en decírmelo, que en informática estamos acostumbrados a aprender a base de errores :)
Un saludo.
mortimor
28/06/2004, 07:52
Despues de leer lo que ha escrito Oankali no puedo mas que decir: "Gracias a dios hay alguien que sabe bien de lo que habla".
No quiero decir con esto que tu no tengas ni idea, ni mucho menos Zaxer :).
Por cierto, si que se propuso portar el KVM de Java cuando este fue portado a GBA. Creo que no seria un trabajo dificil ya que los fuentes son bastante sencillos y estan, si no recuerdo mal, en C++.
Aprobecho tambien para decirte, Oankali, que tu web esta muy bien y que lo del selector de ficheros es una idea cojonuda que deberia haber llevado a cabo alguien mucho antes :)
No soy el primero en sacar un selector de ficheros, conozco 2 más, pero en un caso no es muy configurable, y en el otro lo es un poco más pero de una forma muy poco práctica, tocando el código fuente del selector, por lo que he querido hacer uno que se pueda configurar en modo ejecución, y sobretodo que se pueda configurar mucho (fuentes, colores, pantalla de fondo, idioma, ...), teniendo en cuenta la estética del programa si hace falta.
Aún se puede mejorar, pero por el momento no tengo tiempo.
Para que sepas, lo he diseñado para poder seleccionar la carpeta de MODs en la próxima versión de Puzzle Mix que sacaré quien sabe cuando :)
Ah, y espera tener tiempo para actualizar regularmente mi web, que tengo aún bastantes cosas por publicar.
mortimor
29/06/2004, 07:31
Eres un currante tio. A ver esos nuevos proyectos :D
Yo hasta que no termine el proyecto de la carrera no pienso sacar nada. Que luego me vicio y no hago lo que tengo que hacer (llevo con este problema ya un tiempo :))
(_=*ZaXeR*=_)
01/07/2004, 18:07
Mas o menos creo que habeis captado lo que quiero decir, pero no al 100%. Amos a ver el tema de ser interpretado por el uso de las dlls, quiero que quede totalmente claro que desde un principio lo estoy aplicando al caso concreto del Visual Basic. Ahora bien, visual basic no lo podemos comparar con Visual C++, porque en uno se hace uso de dlls cuando es necesario, y en el otro se hace uso siempre de estas dlls, porque de por si no es capaz de hacer nada. Entonces atendiendo a que VisualBasic no puede hacer uso de la maquina a bajo nivel, porque de por si solo puede hacer lo que existen en dlls existentes, y a:
Un programa interpretado es un archivo que contiene pseudo instrucciones que no tienen nada que ver con las instrucciones en ensamblador del procesador sobre el cual tienen que correr el programa. Es decir que para poder ejecutar el archivo se necesita un programa especial, el interpretador, que se encargará de traducir cada pseudo instrucción a instrucciones en ensamblador para procesador en cuestión.
Entendiendo que esto en el caso que nos ocupa lo realizan las dlls y el SO, creo yo que estan mas que justificadas mis palabras.
El tandem dlls-SO es claramente el programa especial, el que se encargara de traducir cada pseudo intruccion en instrucciones en ensamblador.
Ahora bien, si estais en desacuerdo, ya me explicareis cual es el interprete y como se comunica con el programa creado por visual Basic, porque no tengo la mas remota idea.
mortimor
01/07/2004, 18:25
Mira, lo que diferencia a Visual C++ de C++ es la utilizacion del armazon de aplicacion de las MFCs. Pueden compilarse los programas utilizando las MFCs como librerias que se linkan en tiempo de compilacion o como librerias que se utilizan en tiempo de ejecucion (en tal caso los programas no funcionaran sin ellas). La carga de estas librerias de forma dinamica (en tiempo de ejecucion ) esta enmascarada por el armazon de aplicacion de las MFCs.
En el caso de Visual Basic nos encontramos con la misma situacion exactamente. Que sucede: pues que las funciones y los widgets (o componentes de GUI) y formularios son de un nivel mucho mas alto y enmascaran llamadas a Win32 (como CreateWindowEx al crear una ventana por ejemplo). Esto qeu te digo lo podras comprobar si usas un decompilador de win32 sobre un programa de Visual Basic.
El SO solo interviene para gestionar la carga de las DLLs y los enlaces a las mismas, la gestion de procesos, hilos y memoria.
Yo solo queria comentaros una cosilla:
El que pone el tocho mas grande no es el que gana, asi que podeis dejar de cebaros un poc que se os van a borrar las letras del teclado.
Somos gente civilizada y por tanto para saber quien tiene razon hay que hacer un corro y darse de ostias. El que quede en pie tiene razon.:quepalmo:
si es que hay que explicarlo todo...:sobando:
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.