Desarrollo para GP2X: Impresiones de los coders

[Finrod]

Erm....

No me ha quedado muy claro que es el SDK

[Anarchy]

Crei haber leido en algun foro que se iba a poder ejecutar programas directamente, sin tener que cargar el s.o.!

Así es, pero para hacer esto se debe disponer de un SDK que permita desarrollar directamente sobre el hardware de la máquina.

Según he leído, hay al menos un par de coders que están preparando un SDK que aprovechará el hardware de la GP2X de forma directa, pero probablemente tardará un tiempo en estar disponible.

Un saludo
Anarchy

[WinterN]

Por una parte, parece que el SDK que se publicará para la GP2X estará basado exclusivamente en el Linux y SDL. ¿Esto qué quiere decir?

Eso me pregunto yo...

Si el SDK de GPH corre exclusivamente sobre Linux, sin hacer referencias directas al HW ¿entonces podría ser de código abierto? Quizá esto al fin y al cabo eso no sea tan malo. Yo prefiero un SDK abierto sobre linux, que uno cerrado sobre el HW.

Respecto al SDL, me imagino que será igual que en GP32, aunque no lo tengo del todo claro. ¿La implementación del SDL forma parte del SDK, o bien el SDL corre sobre el SDK o ninguna de las anteriores?

[anibarro]

Si acierta con lo de "usando los 2 procesadores a pelo, un 50% superior a la gp32 a 166Mhz" me parece muy pobre Con 2 cpus a 200Mhz esperaba un 100% mas de rendimiento :/ Porque lo de "a pelo" es exprimiendolos mucho o poco?

[WinterN]

Erm....

No me ha quedado muy claro que es el SDK

Kit básico de desarrollo (Standard Development Kit). Digamos que son un conjunto de librerías para programar la GP2X. Si tu a la hora de programar en C normalmente importas el stdio.h y otras librerías básicas, pues en la GP2X tendrás librerías para pintar en la pantalla, controlar el sonido o manejar archivos, entre otras cosas.

[otto_xd]

M e parece un poco cagada que las dsl del sdk corran sobre las especificaciones de linux, y no sobre el hardware de la consola.
Esperemos que linux aprobeche bien los recursos, porque sino, en vez de ser una consola, se va a quedar en reproductor multimedia...
Mosquea la politica de esta empresa...
Sludosa

[Anarchy]

Hola:

A pelo quiere decir sin ningún tipo de optimización.

Aparte, es posible que yo haya interpretado su mensaje mal. Quizá haya querido decir que usar el segundo procesador suponga un 50% más de rendimiento que usar solamente el primero, con lo que en realidad sería un 80% más de rendimiento que la GP32 a 166Mhz.

Aparte... 50% te parece poco siendo sin depurar? Con un 50% más que lo que hay ahora, emuladores como el de SNES se pasarían de velocidad.

En cualquiera de los casos, son cifras teniendo en cuenta que se programe usando el SDK del Linux y sobre todo, son especulaciones, por lo que no habrá nada seguro hasta que tengamos las consolas en nuestras manos...

Un saludo
Anarchy

[wborland_es]

Según he leído, hay al menos un par de coders que están preparando un SDK que aprovechará el hardware de la GP2X de forma directa, pero probablemente tardará un tiempo en estar disponible.

Estoy un poco liado, pero si hacen un SDK que use el HW de la GP2X de manera directa ¿tendrian los coders que pagar por usarlo al no ser Open Source? ¿Que dira Magiceyes de esto?

[WinterN]

Con lo cual veremos emuladores cañeros en poco tiempo... pero desaprovechando ese 15% de recursos que se estará comiendo el Linux...

A mi me parece exagerado creer que el linux se estará comiendo el 15% de los recursos. Sí se puede pensar que el redimiento puede bajar en esa cifra por el desaprovechamiento de poder programar directamente el micro.

Como alguien comentó en otro hilo, el kernel se queda ahí dormido el 99'9% del tiempo que no se le necesita.

PD: Estamos todos escribiendo como locos, jejeje. Como molan estas discusiones

[WinterN]

Estoy un poco liado, pero si hacen un SDK que use el HW de la GP2X de manera directa ¿tendrian los coders que pagar por usarlo al no ser Open Source? ¿Que dira Magiceyes de esto?

No tendrán que pagar por usarlo, pero no podrán ver el código fuente de dicho SDK, y por tanto saber como funciona la GP2X internamente.

[ArTo]

Estoy un poco liado, pero si hacen un SDK que use el HW de la GP2X de manera directa ¿tendrian los coders que pagar por usarlo al no ser Open Source? ¿Que dira Magiceyes de esto?

Ni algo es gratis por ser Open Source ni es de pago por no serlo: Puedes vender un programa Open Source y puedes dar gratis uno de código cerrado

Saludos...

P.D.: ¿Nos pasamos al IRC? xDD

[Anarchy]

Estoy un poco liado, pero si hacen un SDK que use el HW de la GP2X de manera directa ¿tendrian los coders que pagar por usarlo al no ser Open Source? ¿Que dira Magiceyes de esto?

Hola:

No. Los coders no tendrán que pagar por usarlo. La ventaja de que el SDK tenga el código abierto es que cada coder podrá optimizarlo o usar las partes que más le convengan para el desarrollo de sus aplicaciones.

[Anarchy]

Otra cosa:

Una ventaja considerable que la gente no está teniendo en cuenta es que hay una gran cantidad de usuarios y programadores de Linux que en cuanto vean las posibilidades de la máquina probablemente se lanzarán a desarrollar para ella o a portar programas. Esto unido a que probablemente sea sencillo recompilar mucho software, hará que el listado actual de juegos/emuladores/aplicaciones que hay para GP32 sea meramente anecdótico frente al que probablemente acabará teniendo la GP2X.

[Malenko]

Una cosa es que el kernel no este haciendo nada en la mayoría del tiempo, como en windows, cuando no tocas nada lo que se esta ejecutando es un proceso "nulo", vamos que no chupa rendimiento (de ahi que este dormido el 99'9%). Lo que es diferente es que cuando quieras acceder al hardware tienes que pasar por Linux y todas las capas que tenga (funciones que llaman a funciones, ...) en lugar de hacer la llamada directamente al hardware. A eso se refieren con que quitaría el 15% de rendimiento.

[Electric Dreams]

El kit de desarrollo de MagicEyes no solo es hardware, también librerias (para Linux y WinCE, etc) propias y de terceros. Son esas librerias propias las que no podrán publicarse, supongo.

Lo mejor de todos modos es esperar. Si el kernel está basado en GNU, lo mejor es denunciarlo "a toro pasado", para que no tengan más remedio que publicarlo una vez lo tengamos.

Yo me he hecho con un documento de MagicEyes donde se puede ver como se compone la placa de des$arrollo. Tambien debe pulular un hilo por ahí, donde Babyface explicaba como era la GP2X y se parece mucho a lo que pienso yo.

El segundo procesador está enlazado como un coprocesador por el bus para tal efecto del primero. En el TRM (Technical Reference Manual) del ARM920t podemos conocer como accede el procesador al copro. Este método de acceso no es el más eficiente y no podemos hacer el calculo 2 x 200 = 400. Yo diría que obtendríamos un 160% de rendimiento respecto a un solo procesador, lo cual está muy bien.

Como comente en otro hilo he comenzado a programar un driver para OpenGL ES y lo estoy haciendo a bajo nivel (va para rato, porque el trabajo no me deja mucho tiempo). Como no tengo una GP32, estoy usando un ensamblador para ARM que tenemos en la empresa. Como se enteren que me he llevado una copia a casa me cortan el cuello

Por ahora solo puedo comprobar que las rutinas funcionan y no producen errores en el cálculo. Hace mucho tiempo que no programo en ensamblador y mucho menos en un ARM, pero me gusta mucho este tipo de programación y espero que auque poquito a poco, salga algo bueno.


En definitiva, estamos un poco impacientes y las espectativas están por las nubes, razón por la que los nervios afloran y surgen dudas que no deberían. Además, tenemos muchos compiladores para ARM compatibles al 100%.