Ver la versión completa : Empezar desde cero
:confused: Buenas, soy novato en eso de programar para videoconsolas (nunca lo he hecho), y en el la programación para PC, nunca he terminado nada, pero le he dedicado muchisimas horas a Dark Basic original(del pro reniego) y a Turbo C (no reirse), la verdad es que he obtenido resultados interesantes creando mis propias funciones para simular las leyes de la fisica y los efectos de reflejo sobre los poligonos.
Creo que puedo presumir de haber hecho algunas proezas con lenguajes muy limitados, pero quiero mas...
Desde que descubrí la wiz, tengo la tentación de pasarme a otros lenguajes, pero no tengo ni idea de donde descargarme kits de desarrollo, ni mucho menos se como compilar archivos de C para wiz.
Alguien me podria dar algún consejo.
Jonazan2
19/05/2009, 20:09
Para empezar con wiz como en muchos otros hilos se ha dicho el lenguaje mas facil de aprender es Fenix que no necesita compilacion para wiz debido a que es un lenguaje interpretado. Si quieres dar un paso mas es aconsejable C y SDL, con lo que deberias descargarte ( no se si esta disponible yo no lo encuentro ) el SDK de la consola para su compilacion y hay diversos tutoriales en internet para aprender a usarlo.
Espero haberte ayudado un poco.
Corrigiendo a Jonazan2, sí que hay que compilar Fenix porque su filosofía es similar a la de Java ó .Net: al compilar obtienes un bytecode para una "máquina virtual Fenix". Eso hace que en realidad programar para Wiz o para PC con Fenix sea exactamente lo mismo: solo hace falta instalar la máquina virtual en tu PC (igual que Java o .Net), porque la Wiz ya la trae de serie.
Algo parecido pasa con C: si usas la librería SDL estándar puedes programar y probar las cosas en tu PC con cualquier compilador y sistema operativo, y luego simplemente usas el SDK de Wiz (que creo que está en la sección de descargas) para compilar la versión específica para Wiz. Con C+SDL el código fuente de la versión PC será el mismo que el de la versión Wiz.
Python (con Pygame) sí que es interpretado. De nuevo, el código fuente en PC y Python es el mismo. Lo malo es que aún no parece haber intérprete de Python para Wiz, pero es cuestión de tiempo.
Con cualquiera de estas tres alternativas, Fenix, C+SDL y Python, además puedes programar exactamente igual en Windows, Linux o Mac, porque el código fuente seguirá siendo el mismo :D
Así que ya ves, tienes para elegir :D Lo normal es hacer las cosas en PC con Fenix, Python ó C+SDL y probarlo en el PC, que es mucho más cómodo, y solo pasarlo a Wiz cuando ya estás seguro de que funciona.
Jonazan2
19/05/2009, 20:28
Tiene razon el amigo juanvvc que me he explicado mal en ese concepto ;)
Aquí falta ñuño diciendo que no solo C sirve para programar juegos y que Pascal también es una opción xD
Fenix está bien para empezar, pero tu ya tienes algo de rodaje y el hecho que fenix a la larga se te pueda quedar corto y que es un lenguaje procedural (se llama así, no, orientado a procesos, con multihilo) puede hacer que te cueste acostumbrarte si vienes de lenguajes estructurados como C.
Si has hecho cosas en Turbo C y te acuerdas de algo todavía, te recomiendo que te bajes el Kit oficial de la GP2X. Te vale para la Wiz también e incluye el entorno Dev-C++ y el compilador con todo lo necesario. Después es recomendable que repases C y empieces con la librería SDL, hay muchos tutoriales en la red.
Luego tienes el Fénix que también tiene un kit con su entorno, y es parecido a Basic y Pascal orientado a juegos. Hay un tutorial muy bueno de Fenix en español que se ha comentado varias veces en el foro.
Pero Fénix no es tan sencillo como parece, requiere que pienses en objetos y procesos concurrentes, y los editores no son tan avanzados. No se si hay algún archivo de sintaxis para usar en Notepad++. En contra de C te diría que tienes que ser cuidadoso con los punteros (SDL usa muchos de ellos) y de liberar la memoria que usas, ya que la puedes liar parda. Pero a cambio tendrás un código muy rápido y podrás hacer algoritmos más complejos.
endaramiz
20/05/2009, 20:38
Veo que mencionáis a C, sin embargo, ¿no se puede programar también en C++? En caso afirmativo, tiene algún tipo de restricciones como no poder utilizar listas de la STL (o algo por el estilo...)
Lo digo porque yo "sé programar" en C++ y no en C, pero he visto códigos en C y me parece bastante más engorroso.
Saludos.
Jonazan2
20/05/2009, 20:42
Me parece curioso que no sepas programar en Cy si en C++ cuando este ultimo se podria decir que es como una ampliacion o mejora del primero. Puedes perfectamente programar en este lenguaje ayudandandote de las libreriras SDL para el tratamiento de imagenes, musica...
SpaVampyre
20/05/2009, 23:03
Jonazan, eso es más habitual de lo que imaginas, hay gente que ve un malloc y no sabe que es.
Jonazan2
20/05/2009, 23:05
Jonazan, eso es más habitual de lo que imaginas, hay gente que ve un malloc y no sabe que es.
La verdad no lo sabia me ha resultado muy curioso, no te acostaras sin saber una cosa nueva :brindis:
La verdad no lo sabia me ha resultado muy curioso, no te acostaras sin saber una cosa nueva :brindis:
+1 jeje
Jonazan, eso es más habitual de lo que imaginas, hay gente que ve un malloc y no sabe que es.
¿En C++ no existen los malloc? Me estoy empezando a enamorar de ese lenguaje xD
Yo programo en C con el compilador de C++ :S, o estoy metiendo la pata?
Jonazan2
21/05/2009, 00:03
Yo programo en C con el compilador de C++ :S, o estoy metiendo la pata?
Los compiladores de C++ por definicion deben compilar C a la perfeccion, pero vamos ya con eso de saber C++ y no saber C me he quedado descolocado un poco :lol:
¿En C++ no existen los malloc? Me estoy empezando a enamorar de ese lenguaje xD
Si no hay malloc, habra otra cosa, quien sabe si peor xD
ZarkGhost
21/05/2009, 00:37
ummmm C , que gran lenguaje (por tema de practicas estoy obligado a programar en lisp y se le echa de menos)
Y como que a la gente no le gusta los malloc??? con la libertad que dan! si os dan problemas siempre podéis usar valgrind (gran aplicación), y si no, os programais un sencillo recolector de basura en C (no se si existe alguna libreria, si no, si quieren algún día hago una y la subo, cuando acabe el curso obviamente)
Y volviendo al tema del hilo, quizás sea mejor programar en C++, aunque en mi opinión, lo mejor es programar con lo que mejor domines y cuente con suficientes recursos para tu proyecto.
SpaVampyre
21/05/2009, 01:03
no he dicho que no les guste malloc, digo que no saben ni lo que es.
Ñuño Martínez
21/05/2009, 01:24
Si no hay malloc, habra otra cosa, quien sabe si peor xD Lo hay: se llama new
Y volviendo al tema del hilo, quizás sea mejor programar en C++, aunque en mi opinión, lo mejor es programar con lo que mejor domines y cuente con suficientes recursos para tu proyecto. Esa es la clave, y únicamente hay que quedarse con eso. No hay lenguajes mejores ni peores, sino lenguajes que conoces o no, y que tienen o no recursos adecuados para lo que quieres hacer.
Excepto VisualBasic.
Lo hay: se llama new
Esa es la clave, y únicamente hay que quedarse con eso. No hay lenguajes mejores ni peores, sino lenguajes que conoces o no, y que tienen o no recursos adecuados para lo que quieres hacer.
Excepto VisualBasic.
Hombre... ten en cuenta que el VB ha cambiado mucho desde su versión .NET ya parece algo sólido y si no eres un guarro programando puedes hacer muchas cosas, de hecho la versión CIL de vb.net es la misma que la de C# así que ya es un gran logro... La putada es que en vb.net puedes hacer tantas guarradas como quieras... Hablo desde la experiencia de estar ahora mismo "teoricamente" picando en VB.NET XD
Ñuño Martínez
21/05/2009, 09:42
Bueno, la verdad es que el último VB que he toqué es de hace años, pero para mi el BASIC murió después de QuickBASIC 4.5 (en mi opinión el mejor dialecto BASIC que existe), porque la siguiente versión (BASIC 7.10 alias ISAM) ya la empezó a liar con el acceso a bases de datos y los primeros atisbos Visual, que aún no se llamaba así. El primer VisualBasic ya apestaba. Tengo curiosidad por probar FreeBasic y Gambas, pero por lo que he leído por la Internet se parecen demasiado a VB...
He visto poco de C#, pero lo poco que he visto me parece un plagio de Java, lenguaje que no me hace mucha gracia, aunque sí entiendo que haya gente que le guste y le saque provecho (hablo de Java). Aparte C++ tampoco me gusta. Sin embargo siento una extraña atracción por Objective C, pero me da no-sé-qué abandonar Object Pascal. Es como si le pusiera los cuernos...
¡Menuda paranoia me ha entrado! :lol:
Bueno, la verdad es que el último VB que he toqué es de hace años, pero para mi el BASIC murió después de QuickBASIC 4.5 (en mi opinión el mejor dialecto BASIC que existe), porque la siguiente versión (BASIC 7.10 alias ISAM) ya la empezó a liar con el acceso a bases de datos y los primeros atisbos Visual, que aún no se llamaba así. El primer VisualBasic ya apestaba. Tengo curiosidad por probar FreeBasic y Gambas, pero por lo que he leído por la Internet se parecen demasiado a VB...
He visto poco de C#, pero lo poco que he visto me parece un plagio de Java, lenguaje que no me hace mucha gracia, aunque sí entiendo que haya gente que le guste y le saque provecho (hablo de Java). Aparte C++ tampoco me gusta. Sin embargo siento una extraña atracción por Objective C, pero me da no-sé-qué abandonar Object Pascal. Es como si le pusiera los cuernos...
¡Menuda paranoia me ha entrado! :lol:
Es plagio de java para mi tb jejejeje lo único que el java funciona de pm en linux y .net no va del todo perfecto con mono... típico porq papi gates sólo quiere guindos XD
C# es un plagio de Java, como todo el concepto .NET. Por la misma razón, VB.NET también es más parecido a Java que a VisualBasic. Y a mí también me encantaba QuickBasic :)
Hace mucho que no toco C++, pero x=new X() es esolo un atajo para algo similar a x=malloc(sizeof(X)); x->constructor(), ¿verdad?
C# es un plagio de Java, como todo el concepto .NET. Por la misma razón, VB.NET también es más parecido a Java que a VisualBasic. Y a mí también me encantaba QuickBasic :)
Hace mucho que no toco C++, pero x=new X() es esolo un atajo para algo similar a x=malloc(sizeof(X)); x->constructor(), ¿verdad?
yo diría que si, las dos reservan espacio de memoria para la instancia del objeto, la diferencia es que hacer un new es mucho más visual pa mi gusto xD
endaramiz
21/05/2009, 13:18
La verdad no lo sabia me ha resultado muy curioso, no te acostaras sin saber una cosa nueva :brindis:A ver, voy a explicarlo un poco para que luego no haya pesadillas con las cosas nuevas aprendidas (que alguno parece incluso traumado :D). En mi caso, si leo un programa en C lo entiendo. (aunque el estilo de programar es distinto). El problema viene un día que quise hacer un programa en C y cada vez que compilaba decía: "*****, ¿esto tampoco se puede hacer?". Pero claro, me puse a hacer simplificaciones y, al final, acabó compilando. (Con simplificaciones me refiero a, por ejemplo, que no se puede declarar las variables dentro de la inicialización for, o al menos yo no pude [wei5] )
Ñuño Martínez
21/05/2009, 13:37
(Con simplificaciones me refiero a, por ejemplo, que no se puede declarar las variables dentro del for, o al menos yo no pude [wei5] )
Pues claro: porque el compilador necesita saber exactamente cuántas variables hay antes de empezar a generar el código ejecutable. Es más, la idea esa de declarar variables dentro del código me parece una de las peores características de C++ (y de cualquier otro lenguaje que lo permita). Sé que es una chorrada, pero me cuesta horrores encontrar la declaración de una variable. En C (y en Pascal, y en Objective C, etc.) es fácil: si no está al principio de la función, está al principio del archivo.
flozanot
21/05/2009, 13:42
Pues claro: porque el compilador necesita saber exactamente cuántas variables hay antes de empezar a generar el código ejecutable. Es más, la idea esa de declarar variables dentro del código me parece una de las peores características de C++ (y de cualquier otro lenguaje que lo permita). Sé que es una chorrada, pero me cuesta horrores encontrar la declaración de una variable. En C (y en Pascal, y en Objective C, etc.) es fácil: si no está al principio de la función, está al principio del archivo.
Eso en C de K&R, que en GNU C si que puedes declararlas cuando donde quieras en el cuerpo de cualquier bucle o función (excepto en las condiciones de los bucles iterativos, ie: prohibido while(int...), for(int...), etc)
Ñuño Martínez
21/05/2009, 14:04
Eso en C de K&R, que en GNU C si que puedes declararlas cuando donde quieras en el cuerpo de cualquier bucle o función (excepto en las condiciones de los bucles iterativos, ie: prohibido while(int...), for(int...), etc) Pues será algo que han metido en el C99, porque con el Turbo no se podía, con SmallC tampoco y con el Quick creo recordar que tampoco: Sólo permitían declarar variables al inicio de un bloque o fuera de las funciones, antes de cualquier instrucción ejecutable.
Y aunque lo permita, me parece una mala característica.
flozanot
21/05/2009, 14:08
Pues será algo que han metido en el C99, porque con el Turbo no se podía, con SmallC tampoco y con el Quick creo recordar que tampoco: Sólo permitían declarar variables al inicio de un bloque o fuera de las funciones, antes de cualquier instrucción ejecutable.
Y aunque lo permita, me parece una mala característica.
Pues a mi me parece cojonuda. Y si, es propia del C99 y la soportan tanto GNU C como ICC. Por cierto, el Turbo C es una antigualla del pleistoceno informático, y del SamllC y el Quick C mejor no hablamos... asi, en confianza, ¿tú has estado criogenizado o algo asi durante los últimos 10 años? ¿no?
Ñuño Martínez
21/05/2009, 14:15
asi, en confianza, ¿tú has estado criogenizado o algo asi durante los últimos 10 años? ¿no? No. Lo que pasa es que llevo mucho tiempo en esto. Y cuando digo mucho, quiero decir mucho. La gente no me cree, porque según ellos soy demasiado joven para llevar tanto tiempo programando, pero lo he estado. A mi mismo me dio un shock cuando descubrí que llevaba ya más de 2/3 de mi vida programando, antes de que los padres de muchos de vosotros se hubieran conocido, siquiera.
[edita] Aparte de que soy muy leído. Me encanta la arqueología informática, y eso me ha permitido conocer lenguajes cojonudos como FORTH y Small-Talk, que si están en desuso es únicamente por cuestiones mercantilistas, no porque no sean potentes o estén mal diseñados.
flozanot
21/05/2009, 14:17
No. Lo que pasa es que llevo mucho tiempo en esto. Y cuando digo mucho, quiero decir mucho. La gente no me cree, porque según ellos soy demasiado joven para llevar tanto tiempo programando, pero lo he estado. A mi mismo me dio un shock cuando descubrí que llevaba ya más de 2/3 de mi vida programando.
Entonces no te digo los que llevo yo porque no te recuperas. Pero en serio, no has probado el Watcom C o el cygwin. Vamos, tienes que haberlos probado...
Ñuño Martínez
21/05/2009, 14:24
Entonces no te digo los que llevo yo porque no te recuperas. Pero en serio, no has probado el Watcom C o el cygwin. Vamos, tienes que haberlos probado...
Sí, pero prefiero DJGPP (http://www.delorie.com/djgpp/) o MinGW y MSys (http://www.mingw.org/). :p
(Y hablo sólo de compiladores C, porque prefiero otros lenguajes para según qué cosas)
flozanot
21/05/2009, 14:29
Sí, pero prefiero DJGPP (http://www.delorie.com/djgpp/) o MinGW32 y MSys (http://www.mingw.org/). :p
(Y hablo sólo de compiladores C, porque prefiero otros lenguajes para según qué cosas)
Pues DJGPP también compila C. Esta basado en el GCC. De hecho, es un GCC para MsDOS. Lo que no me explico es como quitaron el enable_near_ptr, con lo retiradisimo que es hacerlo para DOS y WinNT. :loco:
¿Tal vez ignorancia? Lo digo por la burrada que circula por hay de que VESA dependía del OS etc...
Ñuño Martínez
21/05/2009, 14:50
Supongo que fue por el direccionamiento, porque DJGPP compila sólo para 32 bits y lo punteros "near" y "far" sólo tenían sentido en 16 bit.
flozanot
21/05/2009, 15:02
Supongo que fue por el direccionamiento, porque DJGPP compila sólo para 32 bits y lo punteros "near" y "far" sólo tenían sentido en 16 bit.
No es eso. En pmode hay dos modelos, bueno, hay más, de direccionamiento: flat y segmentado. Para habilitar los punteros "cercanos", que no consiste mas que en acceder a cualquier posición de memoria con un desplazamiento en base a tu selector de datos, es necesario manipular los descriptores de memoria. Dichos descriptores son heredados de los 16bits (si, en 16bits también había modo protegido, la pega era que para salir de este la única salida era el botón de "reset") y WinNT tiene código de 16bits recompilado por un tubo, así que la llamada a "set segment limit" del DPMI funciona para <=64MB, y no para un limite de 4GB, que es lo que se requiere. La solución es hacerlo a mano con "get y set descriptor rights".
De todas formas, la cosa mas absurda en programación la he visto en los sources del Duke Nukem 3D para DOS. Ken Silverman se monto un taco con el tema de la memoria acojonante y fue incapaz de entrar en modo FLAT bajo WinNT.:loco: Y la solución que ofreció fue patética, un TSR que degradaba la versión VESA para acceder mediante bancos. :asomb:
Ñuño Martínez
21/05/2009, 15:18
Pues mira, dos cosas más que sé. De todas formas, lo de los modos de direccionamiento dependerán del GO32V2 ese, ¿no?
Por cierto: menudo desfase. XD
flozanot
21/05/2009, 15:50
Pues mira, dos cosas más que sé. De todas formas, lo de los modos de direccionamiento dependerán del GO32V2 ese, ¿no?
Por cierto: menudo desfase. XD
La cuestion va (o iba) así: En el DOS tu tienes tu aplicación que se llama cliente, que requiere de los servicios de otro programa llamado servidor DPMI (servidor de DOS Protected Mode Interface) y hay dos versiones estables, la 0.9 y la 1.0.
Windows hacia las veces de servidor DMPI para las aplicaciones clientes, pero en puro DOS necesitabas un programa que extendiera los servicios del OS. De hay que el programa MsDOS para servir la DPMI se denominase DOS-Extender.
Tu los has visto, seguro. Los mas famosos:
CWSDPMI.EXE
DOS4G.EXE
DOS4GW.EXE
PMODE.EXE
etc...
Lo del Go32V2 es para manejar el formatos de ejecutables COFF:
http://www.delorie.com/djgpp/v2faq/faq22_14.html
Frikis, que sois unos frikis.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.