BCX-BASIC v1.0 (de BASIC a C por arte de magia)

no creo que alguien sea capas de hacer algo en basic....

No????
Tendrías que ver las maravillas que se programaban y que algún lejano día programaba para mi MSX.
Eso era aprovechar al máximo una maquina.
Tendré que echarle un vistazo a este programa y desenpolvar mis conocimientos de BASIC, supongo que por algún rincón de mi cabeza andarán.... jejejejeje
Un saludo
Father-X

Joder, y precisamente yo utilizando visual basic.net para un proyecto que estoy haciendo (para pc)..
La verdad yo no se si habrá algo para diseñar la aplicacion a lo visual basic para wii, pero si la hay, de una me pongo a hacer bastantes aplicaciones...Aunque la verdad, me parece que para un programador, es mas "reto" hacer algo en c o c++, el solo hecho de tener que escribir absolutamente todo el entorno lo hace mas complicadito...
Salu2

no pues no.
nop pues de programacion a mi se me hace algo un poco más complicado C que visual basic
pero asi no te cierras en el universo windows saludos!!
aunque para empezar esta bién

en basic se usan librerias?

En BASIC que yo recuerde (de allá por esa época del ZX Spectrum), no se importan librerías.

Por aquel entonces, todo lo necesario para programar en BASIC, me parece que estaba en la ROM del PC. Cualquier cosa que necesitases (tratamiento de cadenas, gráficos, sonido, E/S, etc...), todo estaba en esa ROM.

Visual Basic, no creo que pueda ser portado a Wii, porque entonces, a ver por donde metían la .NET Framework o las ventanas .

Salu2, será interesante cuanto menos echarle un vistazo... y rememorar esa época en que programaba con mi ZX Spectrum

P.D: "while retaining the relative ease of use by anyone familiar with modern BASIC programming".

Ay madre... que me parece que esto no es lo que creía ... ¿A que se refieren con BASIC moderno?

Porque, que yo sepa, la evolución del BASIC, fue el Visual Basic... ¿A ver si va a ser verdad que...?

por eso digo,yo tambien tuve zx 48k y cpc6128 y no tenia librerias el basic.

Que tiempos aquellos programando en basic en el 6128+

10 PRINT "que tiempos aquellos, a mi me iria bien porque de C no tengo ni idea (y de Basic tendria que rememorar)"
20 GO TO 10



Ala, toma bucle

Joder, hace mucho que no practico, no me acuerdo de casi nada...

Salu2

Madre mia, lo que tiene que oir uno...

Basic es un lenguaje pasadísimo de moda. El que diga que Basic es más facil que C es que nisiquiera ha intentado hacer algo en C.

Y eso no es cuestión de opiniones ni gustos... buscad algo de información antes de decir barbaridades, se agradece.

friki_master escribió:Madre mia, lo que tiene que oir uno...

Basic es un lenguaje pasadísimo de moda. El que diga que Basic es más facil que C es que nisiquiera ha intentado hacer algo en C.

Y eso no es cuestión de opiniones ni gustos... buscad algo de información antes de decir barbaridades, se agradece.

Pues yo he intentado hacer algo en c y algo en basic, y por lo menos para computador, usando basic es mucho mas facil que con c ...
Salu2

Danielc escribió:

friki_master escribió:Madre mia, lo que tiene que oir uno...

Basic es un lenguaje pasadísimo de moda. El que diga que Basic es más facil que C es que nisiquiera ha intentado hacer algo en C.

Y eso no es cuestión de opiniones ni gustos... buscad algo de información antes de decir barbaridades, se agradece.

Pues yo he intentado hacer algo en c y algo en basic, y por lo menos para computador, usando basic es mucho mas facil que con c ...
Salu2

En realidad C es mas facil y lógico: el problema es el manejo de punteros, que en BASIC todo es automatico (te da un error si usas un indice incorrecto, mientras que en C ese tipo de comprobaciones no existen)

Aparte de eso, está el tema de las funciones: hay una serie de funciones que forman parte de lo que se conoce como librería estandar, como por ejemplo, printf() (printf con formato), pero luego pueden haber miles de funciones diferentes para hacer diferentes cosas en diferentes maquinas. Pero eso en si no establece complejidad en el lenguaje.


Por ejemplo, el ejemplo anterior que han puesto de BASIC, pasado a C:



Incluso si quieres, puedes usar goto:




Vamos, que realmente, con cuatro cosas ya sabes programar en C: Otra cosa es que te cueste entender el tema de los "Makefile" por ejemplo, sobre como incluir las librerias y compilar los distintos ficheros, pero eso es algo que no pertenece a C: es otra cosa

C es algo facil,solo k programar para wii se me hace un poco complejo,por el uso de librerias,k no se tiene tanta informacion,k no conosco para nada millones de funciones

pinopop escribió:C es algo facil,solo k programar para wii se me hace un poco complejo,por el uso de librerias,k no se tiene tanta informacion,k no conosco para nada millones de funciones

Bueno, creo que todos tenemos ese mismo problema y yo personalmente, me tomé la molestia de documentar todo lo que pude el uso de las funciones GX, he suministrado ejemplos y he procurado que librerias como SNDLIB/ASNDLIB estuvieran comentadas las funciones (en el include) para que todo fuera mas facil.

De todas formas, es un fallo de planteamiento vuestro muchas veces. Te explico.

Cuando un problema es demasiado grande o demasiado complejo para asimilarlo de golpe , lo que hay que hacer es aplicarle la Teoría de las Cajas Negras. Esto es: no importa saber exactamente como funciona por dentro, la 'caja' si no saber utilizarla por fuera. Incluso si no se conoce muy bien como funciona exactamente por fuera, tampoco es esencialmente importante: te vale solo con saber que si usas todas esas funciones así, tienes video

Hay ejemplos que inicializan el Video, el pad, usan polígonos, sprites, sonido, acceden a ficheros, etc. Y muchas funciones estándar, que si las buscas en google te las explican de pe a pa. Si tu ves que alguien llama a un puñado de funciones que inicializan todo esto, lo importante no es saber que es lo que hacen exactamente, si no saber que eso que se ve tan raro, el lo que inicializa el video, etc. Y a partir de ahí, hay que "jugar" con las cosas, estudiarlas un poco y llevarlas a nuestro terreno.

Al final todo es lo mismo y si lo quieres hacer sencillo, no es nada complicado hacer una plantilla que utilice sonido, pad y por ejemplo, un sprite warro que ocupe toda la pantalla para simular lo que haciamos en tiempos del spectrum, dibujar "directamente" en la pantalla.

Lo que no se puede pretender es que una persona que desconoce demasiadas cosas, quiera hacer un complejo juego en 3D o usar los acelerómetros y cosas asi de una tacada: anda que no se pueden hacer juegos a patadas que usen 2D, con un control clasico y 4 efectos de sonido bien majos y un mod de fondo si te apetece, sin tener que comerte demasiado el tarro con cuestiones que realmente, no te hacen falta. Y te digo yo que un juego hecho con esos medios, no desmerece en absoluto y se pueden conseguir cosas muy logradas en Wii, sin necesidad utilizar polígonos, si no con la CPU a saco.

Vamos, que si alguien echa de menos los tiempos del BASIC de spectrum y sus UDG (o GDU, Graficos Definidos por el Usuario) eso es porque en el fondo, se empeñan en querer hacer algo muy superior, en vez de aprender primero a gatear, luego andar y ya veremos cuando corremos

Y si algo no se entiende, se puede preguntar... que para eso estamos, pero yo por ejemplo, no puedo escribir un PDF supertocho sobre como iniciarse en C y la Wii para novatos, porque al final, te va a resultar hasta mas complejo

Lo que si puedo es proporcionar ejemplos que podeis usar como plantillas y de hecho he publicado varios ejemplos y en Wiireader por ejemplo tienes una librería sencilla que te permite dibujar en 2D y se incluyen dos fuentes de letra de bastante calidad, pero si hay un grupo de personas que se atascan en algo, dificil es que se les pueda orientar o echar una mano, si no sabes que es lo que les resulta tan dificil o que es lo que necesitan

xD, claro, yo no le veo nada de complicado a escribir un texto que aparezca en un bucle infinito, de hecho es demasiado facil..
Lo que pasa es que lo que te digo, por lo menos en computador, utilizando el entorno grafico que nos da visual studio es demasiado facil programar en basic..
El problema con c, es como tu ya lo dijiste el tema de los punteros.. Lo entendí y logre hacer algo sencillo con ellos, pero luego me plantearon un ejercicio de mejorar una agenda que habia hecho antes utilizando punteros y ahi me fregué ..
De todos modos, voy a ver si un dia de estos me animo y programo para wii xD, lo que pasa es que programar para una consola y programar para un computador no tiene punto de comparacion ....

Salu2

Si tu ves que alguien llama a un puñado de funciones que inicializan todo esto, lo importante no es saber que es lo que hacen exactamente, si no saber que eso que se ve tan raro, el lo que inicializa el video, etc. Y a partir de ahí, hay que "jugar" con las cosas, estudiarlas un poco y llevarlas a nuestro terreno.

xD, eso me recuerda a cuando aprendia allegro usando Dev C++, que te tiraba una plantilla gigante, y en un bloque te decia /*Aca va el codigo.*/, con el paso del tiempo entendi un poco que significaba cada cosa, pero como dice Hermes, no hace falta saber todo a la hora de hacer algo, lo que nos parace raro con el paso del tiempo lo comenzamos a entender y asimilar.

Danielc escribió:xD, claro, yo no le veo nada de complicado a escribir un texto que aparezca en un bucle infinito, de hecho es demasiado facil..
Lo que pasa es que lo que te digo, por lo menos en computador, utilizando el entorno grafico que nos da visual studio es demasiado facil programar en basic..

Yo nunca he programado en Visual Basic, pero no creo que sea tan 'facil'. Lo que pasa es que para Visual Basic, tienes libros, tienes documentación abundante y te has acostumbrado a ello. Yo por ejemplo, he programado en Visual C++, incluso usando las Microsoft Fundation Class y no es tan sencillo hacer cosas: si, te monta todo lo necesario para tener una aplicación 'tonta' con una serie de clases para manejar ventanas y puedes hacer muchas cosas que facilitan el trabajo desde el IDE, pero eso es cosa del IDE en sí y no del lenguaje empleado

Danielc escribió:
El problema con c, es como tu ya lo dijiste el tema de los punteros.. Lo entendí y logre hacer algo sencillo con ellos, pero luego me plantearon un ejercicio de mejorar una agenda que había hecho antes utilizando punteros y ahi me fregué ..
De todos modos, voy a ver si un dia de estos me animo y programo para wii xD, lo que pasa es que programar para una consola y programar para un computador no tiene punto de comparación ....

Salu2

Pues no, programar para consola o para ordenador, no tiene ni punto de comparación, no: Yo empecé con un Spectrum y a los tres meses de tenerlo, ya estaba trabajando en ASM porque si, el interprete BASIC era moderno para la época, pero bastante inutil para hacer cualquier cosa con cierta entidad. En mi 8088, era la mar de divertido utilizar el modo EGA, que habia que programarlo usando registros para cambiar de bancos y que tuve la 'potra' de obtener esa información de un libro de Pascal en el Corte Ingles, que por aquella época, no existía Internet y como no te fueras al extranjero a por libros, poco había aqui. El día que me hice con el 'PC Interno', que me costó 10 mil pesetas, pensé que era una ganga y que había venido Dios a visitarme

Ahora, si por ordenador te refieres a 'Windows' y al uso de herramientas de Microsoft, obviamente, parece mas facil aparentemente, pero eso no es mas que por que el IDE te da ciertas facilidades. Y te sales de ahí y no sabes hacer nada, porque en realidad, estás en una vía muerta.

Dime, ¿que juego complejo has creado en Visual Basic para pensar que sería mejor realizarlo ahí que por ejemplo, en Wii, programando en C?.

Porque si resulta que para hacer el juego vas a tener que conocer el uso de 500 funciones y de librerías externas, crear otras 500 funciones que conformen el juego, yo no veo una ventaja tan real, si no metodos diferentes de hacer las cosas. No creo que el acceso a DirectX desde Visual Basic sea mas facil que acceder a las GX, al pad o a la ASNDLIB en Wii desde C. Otra cosa es que para tí resulte extraño porque es algo nuevo que tienes que aprender, pero es que el programador es una persona que está constantemente aprendiendo a hacer cosas, porque es una persona creativa y que s etiene que adaptar al entorno, no el entorno a el.

El lenguaje C no tiene esa proteccion de punteros de la que hace uso BASIC, e incluso en consola, hay que tener un cuidado extra con el tamaño de los datos porque el procesador necesita que estén alineados en memoria en relacion a su tamaño (un int ocupa 4 bytes y se debe cargar o guardar desde una direccion alineada a 4 bytes, si se usan punteros). Todo eso no debe ser problema desde BASIC pues el compilador lo hace por ti, pero a cambio, pierdes rendimiento y te limitas a un lenguaje que es como si dijéramos, para "torpes" y que se circunscribe a un circulo muy limitado y que tampoco tiene una distancia tan grande con C, salvo que en C, uno tiene que ser mas cuidadoso con lo que se hace (pero eso es solo cuestión de acostumbrarse. Es el precio de tener tanta libertad )

El caso es que C es algo así como una llave maestra y que si se quiere, se puede adaptar al uso de personas que se están iniciando en la programación o que no quieren complicarse demasiado la vida, pero quieren hacer cosas en Wii: si se me pide, puedo preparar lo necesario para manejar graficos 2D de forma sencilla y sonido acelerado en forma de una librería, crearos una plantilla para que sepais utilizar los PADs de forma clasica, la inicializacion de la libfat, alguna funcion para leer/escribir ficheros, si es necesario.

Por suerte os puedo proporcionar todo eso de forma que solo necesitaréis conocer el uso de unas pocas funciones para poder trabajar realmente. Las unicas condiciones que os pido serían:

1) Que no me lo pida uno solo, si no que sea mas gente. Por lo menos 10 personas que tengan las suficientes nociones de C como para poder hacer algo, por simple que sea

2) Que no vayais con la idea de hacer cosas muy complejas, si no pequeñas cosas para divertiros y aprender. Nada de humo en la cabeza, ni de videojuegos que requieran un equipo de personas detrás: sprites simples, simpáticos y cutres . Si podeis utilizar mi utilidad Spritegen, aunque solo sea para exportar finalmente los graficos, mejor. Recordad los tiempos del spectrum y maquinas así, y si no habíais nacido, da igual: esto es para aprender o para realizar pequeños videojuegos con el fin de divertirse. Cuanto mas corto sea el tiempo de realización de lo que hagais, mas facil es que se haga realidad. No trateis de llegar a metas inalcanzables, ni os disanimeis por que otros trabajos tienen mas nivel que el vuestro, que eso carece de importancia.

3) Que seais serios: no quiero gente que se ilusione rápidamente y que luego pase de todo, se rinda a las primeras de cambio o que me lo pida para "a ver si dentro de tres meses, me pongo con ello"

4) Que mostreis vuestros trabajos en publico, aunque sea un "hola mundo". Si podeis proporcionar el código fuente, mejor. Esto es muy importante para mí porque obviamente, me llevará tiempo y trabajo preparar todo: la única recompensa que obtengo es ver que os sirve para hacer algo. Mi interés es facilitar el acceso a gente que tiene dificultades para hacer algo que a mi me apasiona. Si no veo nada o solo veo que lo usan 3, pensaré que estoy perdiendo el tiempo

Y por mi parte ofrecería:

1) Un entorno común con todo preparado para utilizar graficos 2D, sonido y uso de pads, de forma que podais empezar a trabajar desde ya, con todo lo mas sencillo posible, con librerías actualizadas

2) Algunos ejemplos practicos comentados, para estudiarlos. Si veo interés, la cosa irá en aumento y poco a poco aprendereis a controlar cosas mas complejas: todo depende de como vuestro interés despierte el mío.

3) Soporte en vuestro idioma, lo cual no es poco. Mi experiencia de 24 años, en programación de varias máquinas, mi conocimiento sobre Wii... cosa que podré ejercer mejor si compartimos algunos métodos de trabajo.

"Esto es una oferta por tiempo limitado" con dicen en la TV, asi que si os interesa el tema, decidlo ya

Hermes escribió:

Danielc escribió:xD, claro, yo no le veo nada de complicado a escribir un texto que aparezca en un bucle infinito, de hecho es demasiado facil..
Lo que pasa es que lo que te digo, por lo menos en computador, utilizando el entorno grafico que nos da visual studio es demasiado facil programar en basic..

Yo nunca he programado en Visual Basic, pero no creo que sea tan 'facil'. Lo que pasa es que para Visual Basic, tienes libros, tienes documentación abundante y te has acostumbrado a ello. Yo por ejemplo, he programado en Visual C++, incluso usando las Microsoft Fundation Class y no es tan sencillo hacer cosas: si, te monta todo lo necesario para tener una aplicación 'tonta' con una serie de clases para manejar ventanas y puedes hacer muchas cosas que facilitan el trabajo desde el IDE, pero eso es cosa del IDE en sí y no del lenguaje empleado

Danielc escribió:
El problema con c, es como tu ya lo dijiste el tema de los punteros.. Lo entendí y logre hacer algo sencillo con ellos, pero luego me plantearon un ejercicio de mejorar una agenda que había hecho antes utilizando punteros y ahi me fregué ..
De todos modos, voy a ver si un dia de estos me animo y programo para wii xD, lo que pasa es que programar para una consola y programar para un computador no tiene punto de comparación ....

Salu2

Pues no, programar para consola o para ordenador, no tiene ni punto de comparación, no: Yo empecé con un Spectrum y a los tres meses de tenerlo, ya estaba trabajando en ASM porque si, el interprete BASIC era moderno para la época, pero bastante inutil para hacer cualquier cosa con cierta entidad. En mi 8088, era la mar de divertido utilizar el modo EGA, que habia que programarlo usando registros para cambiar de bancos y que tuve la 'potra' de obtener esa información de un libro de Pascal en el Corte Ingles, que por aquella época, no existía Internet y como no te fueras al extranjero a por libros, poco había aqui. El día que me hice con el 'PC Interno', que me costó 10 mil pesetas, pensé que era una ganga y que había venido Dios a visitarme

Ahora, si por ordenador te refieres a 'Windows' y al uso de herramientas de Microsoft, obviamente, parece mas facil aparentemente, pero eso no es mas que por que el IDE te da ciertas facilidades. Y te sales de ahí y no sabes hacer nada, porque en realidad, estás en una vía muerta.

Dime, ¿que juego complejo has creado en Visual Basic para pensar que sería mejor realizarlo ahí que por ejemplo, en Wii, programando en C?.

Porque si resulta que para hacer el juego vas a tener que conocer el uso de 500 funciones y de librerías externas, crear otras 500 funciones que conformen el juego, yo no veo una ventaja tan real, si no metodos diferentes de hacer las cosas. No creo que el acceso a DirectX desde Visual Basic sea mas facil que acceder a las GX, al pad o a la ASNDLIB en Wii desde C. Otra cosa es que para tí resulte extraño porque es algo nuevo que tienes que aprender, pero es que el programador es una persona que está constantemente aprendiendo a hacer cosas, porque es una persona creativa y que s etiene que adaptar al entorno, no el entorno a el.

El lenguaje C no tiene esa proteccion de punteros de la que hace uso BASIC, e incluso en consola, hay que tener un cuidado extra con el tamaño de los datos porque el procesador necesita que estén alineados en memoria en relacion a su tamaño (un int ocupa 4 bytes y se debe cargar o guardar desde una direccion alineada a 4 bytes, si se usan punteros). Todo eso no debe ser problema desde BASIC pues el compilador lo hace por ti, pero a cambio, pierdes rendimiento y te limitas a un lenguaje que es como si dijéramos, para "torpes" y que se circunscribe a un circulo muy limitado y que tampoco tiene una distancia tan grande con C, salvo que en C, uno tiene que ser mas cuidadoso con lo que se hace (pero eso es solo cuestión de acostumbrarse. Es el precio de tener tanta libertad )

El caso es que C es algo así como una llave maestra y que si se quiere, se puede adaptar al uso de personas que se están iniciando en la programación o que no quieren complicarse demasiado la vida, pero quieren hacer cosas en Wii: si se me pide, puedo preparar lo necesario para manejar graficos 2D de forma sencilla y sonido acelerado en forma de una librería, crearos una plantilla para que sepais utilizar los PADs de forma clasica, la inicializacion de la libfat, alguna funcion para leer/escribir ficheros, si es necesario.

Por suerte os puedo proporcionar todo eso de forma que solo necesitaréis conocer el uso de unas pocas funciones para poder trabajar realmente. Las unicas condiciones que os pido serían:

1) Que no me lo pida uno solo, si no que sea mas gente. Por lo menos 10 personas que tengan las suficientes nociones de C como para poder hacer algo, por simple que sea

2) Que no vayais con la idea de hacer cosas muy complejas, si no pequeñas cosas para divertiros y aprender. Nada de humo en la cabeza, ni de videojuegos que requieran un equipo de personas detrás: sprites simples, simpáticos y cutres . Si podeis utilizar mi utilidad Spritegen, aunque solo sea para exportar finalmente los graficos, mejor. Recordad los tiempos del spectrum y maquinas así, y si no habíais nacido, da igual: esto es para aprender o para realizar pequeños videojuegos con el fin de divertirse. Cuanto mas corto sea el tiempo de realización de lo que hagais, mas facil es que se haga realidad. No trateis de llegar a metas inalcanzables, ni os disanimeis por que otros trabajos tienen mas nivel que el vuestro, que eso carece de importancia.

3) Que seais serios: no quiero gente que se ilusione rápidamente y que luego pase de todo, se rinda a las primeras de cambio o que me lo pida para "a ver si dentro de tres meses, me pongo con ello"

4) Que mostreis vuestros trabajos en publico, aunque sea un "hola mundo". Si podeis proporcionar el código fuente, mejor. Esto es muy importante para mí porque obviamente, me llevará tiempo y trabajo preparar todo: la única recompensa que obtengo es ver que os sirve para hacer algo. Mi interés es facilitar el acceso a gente que tiene dificultades para hacer algo que a mi me apasiona. Si no veo nada o solo veo que lo usan 3, pensaré que estoy perdiendo el tiempo

Y por mi parte ofrecería:

1) Un entorno común con todo preparado para utilizar graficos 2D, sonido y uso de pads, de forma que podais empezar a trabajar desde ya, con todo lo mas sencillo posible, con librerías actualizadas

2) Algunos ejemplos practicos comentados, para estudiarlos. Si veo interés, la cosa irá en aumento y poco a poco aprendereis a controlar cosas mas complejas: todo depende de como vuestro interés despierte el mío.

3) Soporte en vuestro idioma, lo cual no es poco. Mi experiencia de 24 años, en programación de varias máquinas, mi conocimiento sobre Wii... cosa que podré ejercer mejor si compartimos algunos métodos de trabajo.

"Esto es una oferta por tiempo limitado" con dicen en la TV, asi que si os interesa el tema, decidlo ya

Hermes desde luego te admiro demasiado
Todo lo que has hecho por esta comunidad no tiene precio y encima ahora nos dices que nos preparas un entorno para desarrollar para wii... ¿pués que quieres que te diga? Yo encantado . A mi me interesa mucho el tema: empecé con la nds portando un jueguecillo de Asteroides que había hecho para PC y luego me metí en la psp que por cierto no lo conseguí portar no se porque aunque bueno eso fue hace tiempo ya. Y bueno ahora que tengo entre manos una Wii me gustaría mucho programar algo para ella

Así que bueno, espero que mas gente se anime y diga que también le interesa el tema xD Eso sí, yo no puedo estar todo el día liado con la wii; habrá semanas que igual me tiro hasta las 4 de la mañana haciendo cosillas pero otras semanas que igual ni la toco por temas de estudios mayormente (y es que yo no se que pasa pero el primer trimestre de 2º de bach es como el 3º trimestre de 1º de bach, estas en constante tensión por que hay 4 examenes cada semana -.-U)

Bueno pues eso es todo, gracias otra vez y salu2!!

Hermes, xD, yo no soy ningun programador experimentado, apenas estoy aprendiendo, y aunque en c no he hecho nada serio mas que una agenda, ya mas o menos lo domino...
Obviamente hacer un juego con cosas 3d y todo eso seria mas facil en c que en basic.. Pero por ejemplo, para un proyecto que actualmente estoy haciendo (un creador de listas para warhammer, un juego de estrategia y de mesa xD) me queda mas facil con basic, porque puedo editar mas facil la parte gráfica y no necesito preocuparme por nada de 3d, porque el programa no lo necesita...
Y si, si me refiero a ordenador con "windows" aunque actualmente estoy escribiendo desde kubuntu...
Cuando domine mejor el hecho de usar c para cosas con entorno gráfico, pasare mi programa a dicho lenguaje, y asi tengo "mas libertad" como tu dices, y tambien lo podria portar a otras plataformas mas facil..
Obviamente, como tu lo dices, es cosa del ide, por eso he especificado que "usando visual basic.net para programar es bastante facil", si me ponen a programar en basic asi sin el entorno gráfico, tal vez no pueda hacer en este momento lo que estoy haciendo con el ide, pero al menos conozco los comandos básicos (se que no se llama asi, pero ahora se me fue el nombre) en basic..
Y no soy ningun veterano ni en basic ni en ningun otro lenguaje, es mas, basic lo he aprendido en menos de 1 mes, pero no tanto como estudiaba c, que por cada cosa nueva me proponian ejercicios y yo los iba haciendo todos, aqui sencillamente fui directo al grano y empecé con mi aplicación, y cada vez que se me presentaban incovenientes me dedicaba a buscar en google o descubrirlo por mi mismo.
Como tu dices, si hago un programa en c, podrá ser mucho mas liviano que en basic, al igual, que segun he leido, si hago un programa en lenguaje ensamblador, correrá mas rapido que en c, obviamente, si se hace el programa bien.. Pero como te digo, aun soy muy novato en programación, y no se si te acuerdes, pero hace unos meses un usuario acá me recomendó un curso de nacho cabanes que me ha servido muchisimo y que es con el curso que he aprendido..

En wii pues creo que ya conozco como manejar los pads y todo eso, y como escribir texto en consola, pero me toca con código en mano para irme ayudando, mientras practico... Si tu quieres ayudarnos a los mas "poco experimentados" a programar mas fácil para wii, pues encantado, por mi, dale.. Por mi parte, esto me animaría mas a programar en wii, y claro que lo usaría, haría cositas sencillas mientras aprendo. Como tu dices, hay que empezar por algo sencillo, porque si no uno luego se desanima...

Salu2 y muchas gracias por todo..

Jope, Hermes ..... no me digas que tienes los ficheros de definicion comentados ..... eso no tiene precio.

Pienso que el problema que ve la gente que programa en visual basic en C es que para el primero el problema más gordo de programar en Visual Basic es usar correctamente los objetos (cosa muy fácil). En C sin embargo el principal problema es la de la gestión correcta de la memoria. Para esto se usan punteros y si no tienes muy claro lo que estás haciendo es muy jodido depurar los errores, ya que no hay una capa intermedia a la compilación que te determine que un puntero está siendo mal usado (o uses un puntero que apunta a un lugar de la memoria equivocado, etc).

En C el programador se encarga de reservar la cantidad de memoria que quieras, el sistema unicamente te devuelve un error si no suficiente memoria para asignarte lo que le has pedido, o no te da ningun error y te devuelve un puntero (una especie de dirección postal) al comienzo de la zona de memoria que el sistema te ha asignado, pero si te pasas de ella no hay errores, simplemente estarás corrompiendo zonas de memoria usados por otros procesos o que no están usadas pero el sistema piensa que si, por lo que la podría asignar a otros procesos. Al final toda la memoria se corrompe y obtienes o un reinicio del sistema o un cuelgue total del sistema.

Además es muy importante conocer el hardware para el que se está programando y como funciona, esto aparte de que C sea más o menos fácil que Basic o Visual Basic (que por cierto se parecen únicamente en el nombre).

Por cierto, como respuesta a la pregunta inicial del post, siempre han habido compiladores cruzados, pero el problema es la potencia que necesitas para programar en la Wii algo. Si quieres un programa que diga 'Hola, mundo' seguro que te sirve hacerlo en basic y transformarlo a C. Pero si lo que necesitas es trabajar con puertos de entrada/salida, llamadas a las funciones internas de la Wii, manejo de memoria, etc, ya te digo que os olvideis del tema. Para hacer un agujero en la pared igual me basta con una navaja, pero si lo que debo hacer es un tunel con salidas de aire, iluminación, etc pos va a ser que no.

Un saludo.

En cuanto a lo que dices de que la gente tiene problema con los punteros en c, totalmente de acuerdo..
De hecho, como ya lo habia dicho, intenté hacer una agenda con nosequé utilizando punteros y no me daba el resultado esperado.. Tal vez apenas termine la primera versión de mi proyecto en visual basic, retome c e intente hacer esta agenda...

También estoy de acuerdo en el resto de tu post, pero como te digo, en el caso de mi proyecto, me sale mas fácil hacerlo en visual basic (por ahora), ya después que esté hecho, si me da por ponerlo mas liviano, me paso a c y listo...
Salu2

Yo ya os digo que a mi no me gusta complicarme de mala manera y mas cuando, hoy estoy trabajando en Wii y mañana en PC o en lo que se tercie: Por eso me gusta darle un enfoque lo mas facil posible a mis funciones de librería.

Y entiendo que la gente que viene de nuevas y lo que es peor, que habeis conectado relativamente hace poco con el mundillo de la programación, es un palo bastante gordo, en relacion a mi caso, por ejemplo, que primero toqué el spectrum, luego atari st, pc, y un buen puñado de consolas y que como se suele decir, mas sabe el Diablo por viejo, que por Diablo.

Y coño, ahora mismo, entre mis propios fuentes hay todo lo necesario para que ordenándolo un poco y organizando el tema para que instaléis devkitpro, copieis las librerias y los include que yo os proporcione, y con cuatro detalles más un poco tontos, se rompa esa dificultad inicial y podais hacer vuestros pinitos en Wii que por cierto, es probablemente, la consola mas adecuada y mas accesible que os vais a encontrar desde un punto de vista homebrew.

Como digo, es todo cuestión de ordenarlo un poco, explicar algunos pequeños detalles y proporcionarlo listo para funcionar, para que se os quite la "pereza" inicial (luego eso si, hacer un programa siempre es complicado, pero mas complicado es cuando uno no conoce los ladrillos para construirlo y si hay demasiada variedad de ladrilllos y uno no sabe que ladrillo toca usar para esa pared)

JEJEJEJEJE .... gracias Hermes, seguro que nos vendrá de perlas a más de uno .....

El problema en mi caso más que pereza es cuestión de tiempo. Igual si me pongo algo y lo veo claro y voy profundizando poco a poco, seguro que me dedico un poco más.

Spectrum ..... Ayyyy, que tiempos !!!
Cualquiera que lo vea igual se lleva las manos a la cabeza, pero con esa maquinita se podían hacer churros con chocolate ..... y si sabias programar en assembler ya lo flipabas ....

En definitiva, no creo que sea cuestión de que uno sea mejor que otro. Es cuestión de que, a las alturas en las que estamos que casi todo está inventado, para cada cosa hay que usar la herramienta que mejor se adapte al resultado final. Lo bueno del C es que puedes hacer cualquier cosa (con más o menos trabajo). Evidentemente hay cosas (como la agenda que dice Danielc) que es absurdo hacerlas en C (bueno , yo me sé de un bestiajo que se hizo una en C ..... pero estaba empezando y me enseño a programar en C y a usar punteros .... además, por aquel entonces no existian los RADs que hay ahora) es mucho más sencillo en Visual Basic y más 'resultón' .... es como si para poner un tornillo uso un martillo. Al final lo meteré pero de peor forma y no quedará tan bien como si lo hago con un destornillador.

A lo mejor no es el hilo mas apropiado para ello, ni tampoco las horas, pero de veras que me gustaría que hubiera mas gente que muestre su interés, antes de hacer nada

Para que sepais de lo que estamos hablando, en cuestión de graficos la cosa sería:

InitScreen(); // esto es todo lo que tendras que hacer para tener el video en funcionamiento

extern int SCR_WIDTH,SCR_HEIGHT; // aqui se devuelve el tamaño de la pantalla, si el alto es igual 480, refresca a 60Hz

Screen_flip(); // esta es la funcion que espera a que se dibuje todo, al sincronismo vertical y que cambia el buffer de la pantalla

CreateTexture(GXTexObj *texture, int format, void *mem, int width, int height, int repeat); /* esta funcion sirve para crear una textura en memoria: se puede utiliza esta memoria como superficie de dibujado, solo que hay que tener en cuenta que a la salida de esta funcion, la memoria estará organizada como tiles */

DrawSurface(GXTexObj *surface,int x,int y, int width, int height, int layer, u32 color); /* dibuja una textura como superficie en pantalla, haciendo uso de profundidad Z (parametro layer) y aplicando un color con componente alpha (permite translucidez o transparencia total) */

Solo con estas funciones, ya teneis todo lo necesario para inicializar el video, dibujar un porron de sprites acelerados por hardware o crear una especie de ventana donde dibujar a 'POKE' seco lo que os de la gana

El audio:

ASND_Init(); // inicializa el audio

ASND_Pause(0); // quita la pausa general: a partir de aqui podemos utilizar 16 voces aceleradas con el DSP

/* ejecuta la voz 1, monofonica PCM de 8 bits (con signo) a 8000 Hz con un retardo inicial de 20 ms y volumen izquierdo y derecho al maximo valor */

ASND_SetVoice(1, VOICE_MONO_8BIT, 8000, 20, audio2_raw, size_audio2_raw, 255, 255, NULL);

Ya está: esto es todo lo que tienes que hacer para ejecutar una de las 16 voces para efectos que tienes. Lo del retardo sirve para poder crear efectos de reverberacion o eco y por ejemplo, en este caso se usaba para potenciar el sonido de una Magnum en uno de los ejemplos de la ASNDLIB.

No parece tan dificil visto asi ¿verdad?

MMM, voy a tratar de hacer algo en estos dias... Por cierto, como hago para abrir un archivo png y dibujarlo en pantalla?..

LA PURI !!!!!

Eso no es una librería .... es una WiiAPI megasencilla ..... Me pensaba que había que picar bastante más código del que indicas para hacer lo que dices en el post. Por ejemplo para hacer únicamente lo que tu haces con Screen_flip() pensaba que había que hacerlo parecido a como se hace en el PC (sin las APIs de Windows, claro) , leyendo los registros de control de la VGA para esperar el signal retrace, etc.

Me estás picando, Hermes, me estás picando ......

ringfstork escribió:Oooh LA PURI !!!!!

Eso no es una librería .... es una WiiAPI megasencilla ..... Me pensaba que había que picar bastante más código del que indicas para hacer lo que dices en el post. Por ejemplo para hacer únicamente lo que tu haces con Screen_flip() pensaba que había que hacerlo parecido a como se hace en el PC (sin las APIs de Windows, claro) , leyendo los registros de control de la VGA para esperar el signal retrace, etc.

Me estás picando, Hermes, me estás picando ......

Hombre, internamente el código es mas complejo, solo que asi se ve mas limpio

Ademas, teneis otras funciones de dibujo para lineas, cajas, cajas redondeadas, elipses con o sin relleno. Dibujado de caracteres en pantalla con tamaño redimensionable (usa una fuente interna de 16x32 pixeles). Y hay mas funciones para el sonido, etc.

Y estamos hablando de tirar por la via sencilla, que siempre se puede ampliar la funcionalidad, que teneis un documento sobre las GX bastante util en Español que hice para que cualquiera las pueda utilizar a fondo.

Ahora imaginate un MOD player tirando de la voz 0 (que se suele reservar para esas cuestiones) trabajando en Multihilo y sobre el que no te tienes que preocupar, que lo pones en marcha con dos tonterías (o si quieres, lo puedes controlar a mano, para cambiar el MOD cuando finalice) para que tengas tu musiquilla de fondo y detalles asi.

¿De veras es tan coco programar en Wii así? Me refiero para hacer cosas "sencillas", como juegos 2D, pero vamos, yo creo que solo con el puñado de cosas que he explicado aqui, ya da bastante juego para entretenerse (lo unico que hace falta, es cohersionarlo todo para que la gente no se pierda y con hacer "Make" todo rule así, comentar cuatro cosas y poner unos ejemplillos para que te acabes de convencer )

MMM, voy a tratar de hacer algo en estos dias... Por cierto, como hago para abrir un archivo png y dibujarlo en pantalla?..

¿Ya te estas liando? . Creo que alguien tiene portada libpng por ahí: yo no la uso. Yo para mis graficos, tiro de BMP o directamente, exporto desde mi utilidad Spritegen a pelo (que me puede sacar un formato RAW organizado). Vamos, que suelo incluir mis graficos dentro del ejecutable sin compresiones.

Si te empiezas a meter en berenjenales, entonces es normal que te resulte dificil y si usas PNG desde fichero, pues ya te estas metiendo en movidas que no deberías tocar hasta que no domines el tema (es una reflexion que hago en voz alta, no una critica, que conste )

xD, si, ya me estoy liando jeje...
Bueno, y por ejemplo si incluyo en el ejecutable el gráfico con tu utilidad, luego como hago para reproducirlo?...
xD, tanta pregunta mia te va a terminar causando fastidio.
Bueno, igual mejor me espero a que tu nos facilites la programacion, ojala pueda programar algo chevere cuando hagas eso...
Salu2 y gracias..

Un placer leer a gente como tu Hermes.

Pues me pica el gusanillo, lo que no se si estare a la altura, ni si tendre el tiempo, pero picarme me pica. Hasta se que juego podria hacer. Que tal de dificil un tipo picross?

Saludos.

Hermes escribió:A lo mejor no es el hilo mas apropiado para ello, ni tampoco las horas, pero de veras que me gustaría que hubiera mas gente que muestre su interés, antes de hacer nada

Para que sepais de lo que estamos hablando, en cuestión de graficos la cosa sería:

InitScreen(); // esto es todo lo que tendras que hacer para tener el video en funcionamiento

extern int SCR_WIDTH,SCR_HEIGHT; // aqui se devuelve el tamaño de la pantalla, si el alto es igual 480, refresca a 60Hz

Screen_flip(); // esta es la funcion que espera a que se dibuje todo, al sincronismo vertical y que cambia el buffer de la pantalla

CreateTexture(GXTexObj *texture, int format, void *mem, int width, int height, int repeat); /* esta funcion sirve para crear una textura en memoria: se puede utiliza esta memoria como superficie de dibujado, solo que hay que tener en cuenta que a la salida de esta funcion, la memoria estará organizada como tiles */

DrawSurface(GXTexObj *surface,int x,int y, int width, int height, int layer, u32 color); /* dibuja una textura como superficie en pantalla, haciendo uso de profundidad Z (parametro layer) y aplicando un color con componente alpha (permite translucidez o transparencia total) */

Solo con estas funciones, ya teneis todo lo necesario para inicializar el video, dibujar un porron de sprites acelerados por hardware o crear una especie de ventana donde dibujar a 'POKE' seco lo que os de la gana

El audio:

ASND_Init(); // inicializa el audio

ASND_Pause(0); // quita la pausa general: a partir de aqui podemos utilizar 16 voces aceleradas con el DSP

/* ejecuta la voz 1, monofonica PCM de 8 bits (con signo) a 8000 Hz con un retardo inicial de 20 ms y volumen izquierdo y derecho al maximo valor */

ASND_SetVoice(1, VOICE_MONO_8BIT, 8000, 20, audio2_raw, size_audio2_raw, 255, 255, NULL);

Ya está: esto es todo lo que tienes que hacer para ejecutar una de las 16 voces para efectos que tienes. Lo del retardo sirve para poder crear efectos de reverberacion o eco y por ejemplo, en este caso se usaba para potenciar el sonido de una Magnum en uno de los ejemplos de la ASNDLIB.

No parece tan dificil visto asi ¿verdad?

Joder a mi con eso me estás poniendo los dientes largos de mala manera xDDD
Desde luego como al final lo hagas en mi casa te monto un altar o algo

Salu2!!

Puyover escribió:Joder a mi con eso me estás poniendo los dientes largos de mala manera xDDD
Desde luego como al final lo hagas en mi casa te monto un altar o algo

Salu2!!

En realidad está HECHO: la libreria grafica, la tienes en la descarga de wiireader, concretamente screen.c, screen.h y las fuentes de letras font.c/.h font_b.c/.h. (y además, incluyo una utilidad para convertir una fuente .ttf (true type) para poder usarla con la librería). Seguramente le añada alguna cosilla mas.

Lo otro es la asndlib donde lo ultimo de lo ultimo, lo tienes en los fuentes de Guitarfun 3.5, aparte de que en mi rama del git de hackmii tienes todo lo necesario para conectar con el player de mp3 que usa la libmad y el player de formato mod.

La idea es juntarlo y apañarlo con las menores complicaciones posibles para que empeceis a ver claro y que os pique el gusanillo

La libreria de sonido, por ejemplo, te permite poner una voz infinita y cambiarle la frecuencia dinamicamente o el volumen (lo cual te permite hacer un efecto de posicionamiento de voces, o simular un efecto doppler, etc). Es decir, la sencillez de uso no tiene porque estar reñida con la posibilidad de hacer muchas cosas

Luego de utilidades, para el PC uso estas:

- ttf2raw -> captura una fuente truetype al formato usado en mi librería grafica. Incluida en Wiireader (fuente incluido)

- Spritegen -> utilidad que te permite crear sprites de hasta 128x128 y un limite , pero tambien hacer mapas de sprites (pantallas) con hasta cuatro layers y exportarlo a C en distintos formatos de color. Tambien admite copy/paste desde otras utilidades de dibujo, pero hay que tener cuidado porque aqui se trabaja con una paleta de colores de 256 colores. La ultima version la tengo Aqui por si le quereis echar un vistazo (está documentado su uso en español, en el fichero pdf). Puede parecer limitada, pero no la subestimeis, que para hacer juegos con una aire de "vieja escuela" puede ser muy util (sobre todo por el tema de los mapas de sprites)

- filetochar -> lo llamo asi aunque en realidad, es capaz de convertir cualquier fichero binario a fichero C con formato de datos char, short o int con o sin signo y la alineacion de dato que precises (en Wii es muy comun alinear los datos a 32 bytes: texturas, voces PCM para ASNDLIB...). Os sirve para incluir efectos de sonido que no ocupen mucho o vuestros graficos o datos, de forma que se compilen en el programa. Está incluida con los fuentes de Guitarfun (ver carpeta util)

Para convertir audio (efectos, etc), uso Audacity: http://audacity.sourceforge.net/

Con estas sencillas herramientas, mas alguna utilidad grafica (como el Paint! DD) me las apaño bastante bien (si, mis utilidades quiza no rebosan una belleza gráfica apabullante, pero ¿acaso eso tiene tanta importancia? . Si me perdiera en detalles "superfluos" acabaría por no sacar nada )

Evidentemente, formatos graficos como PNG tambien se pueden añadir mas tarde y vosotros podeis usar otros metodos propios para cargar cosas (recordando siempre que hay que convertir el endian, pues muchas cosas usan little endian y la wii usa big endian y eso puede causar quebraderos de cabeza a mas de uno ). Esto es cuestión ya de ir dando un paso tras otro, como se dice

Saludos

Hermes escribió:Con estas sencillas herramientas, mas alguna utilidad grafica (como el Paint! DD) me las apaño bastante bien (si, mis utilidades quiza no rebosan una belleza gráfica apabullante, pero ¿acaso eso tiene tanta importancia? . Si me perdiera en detalles "superfluos" acabaría por no sacar nada )

Ains... de cuantos apuros me habrá sacado a mi el paint...

EDIT: Aunque ahora también uso bastante tu spritegen por el tema de la optimización de paletas.

ANTONIOND escribió:

Hermes escribió:Con estas sencillas herramientas, mas alguna utilidad grafica (como el Paint! DD) me las apaño bastante bien (si, mis utilidades quiza no rebosan una belleza gráfica apabullante, pero ¿acaso eso tiene tanta importancia? . Si me perdiera en detalles "superfluos" acabaría por no sacar nada )

Ains... de cuantos apuros me habrá sacado a mi el paint...

Ya te digo: yo tengo el Photo Paint y he probado el Photo Shop y para ciertos usos, prefiero el Paint. Hay veces que uso el copy /paste desde el Photo Paint al Paint para manipular algo, luego al reves para hacer reescalado y luego de ahí a Spritegen, ya adaptado

ANTONIOND escribió:EDIT: Aunque ahora también uso bastante tu spritegen por el tema de la optimización de paletas

Esa fue una de las ideas que me impulsó a hacer la aplicación: que a veces me perdía con los colores y no sabía localizarlos y en spritegen es muy facil saber que colores estas usando, y la posicion en la paleta del color del pixel al que apuntas. O el reemplazo de colores con F1. Yo diría que es una utilidad grafica para programadores, mas que para grafistas

Hermes escribió:

ANTONIOND escribió:

Hermes escribió:Con estas sencillas herramientas, mas alguna utilidad grafica (como el Paint! DD) me las apaño bastante bien (si, mis utilidades quiza no rebosan una belleza gráfica apabullante, pero ¿acaso eso tiene tanta importancia? . Si me perdiera en detalles "superfluos" acabaría por no sacar nada )

Ains... de cuantos apuros me habrá sacado a mi el paint...

Ya te digo: yo tengo el Photo Paint y he probado el Photo Shop y para ciertos usos, prefiero el Paint. Hay veces que uso el copy /paste desde el Photo Paint al Paint para manipular algo, luego al reves para hacer reescalado y luego de ahí a Spritegen, ya adaptado

Yo lo que hago es coger el paint para el "molde" de la imagen, de ahí al GIMP/Photoshop a meter filtros y cosas por el estilo, y luego al spritegen a retocar si hace falta y reducir calidad, vamos, hacer que la paleta sea de 256 colores.

Y lo peor no son las imágenes, sino los modelos en 3D. Eso si que es desesperante, sobre todo cuando se hacen pequeños cambios para ver si queda bien. Y eso sin tener en cuenta que también hay que hacer la textura... Entre modificaciones y conversiones me puedo tirar media hora a lo tonto mientras retoco un modelo para corregir un detallito de la textura...

Hermes, si no es mucha molestia, me puedes explicar que es eso de big endian ? Eso tiene que ver con los colores? No se, me suena a que lo vi por entuwii que hablaban de que en wii se invertian no se que cosas de los colores, pero no me quedo muy claro....

Danielc escribió:Hermes, si no es mucha molestia, me puedes explicar que es eso de big endian ? Eso tiene que ver con los colores? No se, me suena a que lo vi por entuwii que hablaban de que en wii se invertian no se que cosas de los colores, pero no me quedo muy claro....

Eso tiene que ver con la forma de almacenar el dato. Cuando un dato ocupa mas de un byte, existen dos formas de organizarlo de mayor a menor peso, que eso se conoce como Big Endian y de menor a mayor peso, que se conoce como Little Endian.

En plataformas Intel se utiliza la ordenación de menor a mayor (Little), asi por ejemplo, para almacenar en memoria el valor 256 en decimal, el primer byte sería 0 y el segundo 1 (1*256+0= 256). Sin embargo, en la Wii sería al reves, primero el 1 y despues el 0!.

Con lo cual si por ejemplo, quieres importar un BMP, pues te toca cambiar el orden de los bytes de los datos. Otro caso curioso se da si importas samples PCM a 16 bits, que tendras que invertir el orden de los bytes tambien.

Esa es una de las razones por las que es util exportar los datos a C, puesto que si importas una lista de numeros de 16 bits, no se ve afectada por la forma de almacenar el numero en memoria (es decir, 32767 es el mismo numero en ambos sistemas, pero cambia la forma en que ese numero se almacena en memoria o dentro de un fichero, por ejemplo)

Para convertir el endian, puedes usar estas funciones:

unsigned short inline swap_16(unsigned short a) // para numeros de 16 bits
{
return( (a<<8) | (a>>8));
}

unsigned inline swap_32(unsigned a) // para numeros de 32 bits
{
return( (a<<24) | (a>>24) | ((a<<8) & 0xff0000) | ((a>>8) & 0xff00));
}

(creo que no me he equivocado, que la acabo de poner a pelo )

Uso unsigned debido a que los desplazamientos con enteros con signo, replican ese bit al desplazar a la derecha (desplazamiento aritmetico, en lugar del lógico que es el que necesitamos). Asi que si el compilador "protesta" usa el cast para cambiar el tipo

Muchas gracias, ahora si lo entiendo bien...

Hermes escribió:
Ademas, teneis otras funciones de dibujo para lineas, cajas, cajas redondeadas, elipses con o sin relleno. Dibujado de caracteres en pantalla con tamaño redimensionable (usa una fuente interna de 16x32 pixeles). Y hay mas funciones para el sonido, etc.

Hola Hermes, perdona que te moleste, estoy haciendo un juego con gráficos vectoriales (o poligonales.. según se vea), he probado con GRRLIB, y no me esta gustando mucho.. por lo que ve, aunque la última versión utiliza GX, lo hace todo en su propio frambuffer y solo utiliza GX al final.. si uso tu librería (screen.c) usando DrawLine me ira mas rápido?

Gracias,

Manny

manny2008 escribió:

Hermes escribió:
Ademas, teneis otras funciones de dibujo para lineas, cajas, cajas redondeadas, elipses con o sin relleno. Dibujado de caracteres en pantalla con tamaño redimensionable (usa una fuente interna de 16x32 pixeles). Y hay mas funciones para el sonido, etc.

Hola Hermes, perdona que te moleste, estoy haciendo un juego con gráficos vectoriales (o poligonales.. según se vea), he probado con GRRLIB, y no me esta gustando mucho.. por lo que ve, aunque la última versión utiliza GX, lo hace todo en su propio frambuffer y solo utiliza GX al final.. si uso tu librería (screen.c) usando DrawLine me ira mas rápido?

Gracias,

Manny

No conozco cual es el problema que tienes con GRRLIB, luego no se si irá mas rapido. Mi librería tiene un problema porque plantea el dibujo de lineas desde un punto de vista de poder cambiar el grueso, asi que en realidad dibujo dos triangulos para formar una linea gruesa y tambien introduzco en cada llamada la informacion del formato de vertices, conectar con textura, etc. Es decir, que no está optimizado para dibujar tus graficos vectoriales, porque el objetivo no es mostrar miles de lineas rapidamente.

Peeero, no hay nada que impida dibujar lineas como tu dices, pasandole un buffer conteniendo una lista de coordenadas y un color y dibujarlo asi o a buenas malas, usar las funciones GX a pelo:

Activa transparencia/translucidez usando esto:



Con esto configuras para usar color directo, sin textura



Con esto configuras los parametros de los vertices, para pasar color directo de 32 bits y las coordenadas como enteros de 16 bits (para dibujar en un area de 640x480 mas que suficiente)



Con esto dibujarias una o mas lineas


El ejemplo dibujaria una linea, pero si añades dos vertices mas y pones en GX_Begin 4, serian dos lineas y asi hasta un limite de 65535 vertices "ma o meno" (weno, si te lo soporta el FIFO )

Otra cosa, el color se especifica como RGBA a 32 bits (o sea 8 bits por componente), siendo R el de mayor peso y Alpha el de menor peso.

Inconvenientes que te puedes encontrar: si usas mi libreria, con eso, ninguno, porque está preparada para que tu hagas esos cambios desde fuera. Pero desde GRRLIB seguramente desconfigures algo y pete, porque de por supuesto que las GX estan configuradas a su gusto, cuando no es así.

Ventajas de hacerlo asi: Despues de configurar, es mas rapido porque te evitas usar una lista que luego hay que interpretar para hacer lo que te he pegado ahi (obviamente, el dibujado de lineas es lo que hay entre GX_Begin-GX_End y el resto solo lo haces una vez para configurar antes de empezar a dibujar lineas y el numero de vertices hay que conocerlo antes de empezar a enviarlos)