Ver la versión completa : Desarrollo para GP2X: Impresiones de los coders
Hola:
Dado que ya se comienzan a conocer algunas cosas sobre el desarrollo para GP2X, me ha parecido interesante abrir un tema para discutir sobre las posibilidades que los coders ven a la máquina, además de para reunir la información hasta ahora disponible.
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? Pues que debido a que el procesador utilizado en la máquina es de "código cerrado", aquellos que deseen crear un SDK específico para usar el hardware a bajo nivel, deberán realizarlo de código cerrado, además de firmar un NDA con el fabricante para que este le mande la información necesaria.
Resumiendo: La pega es que durante los primeros meses no se podrá aprovechar el 100% de las posibilidades de la máquina, hasta que alguien desarrolle un SDK, que tendrá que ser de código cerrado. Según comenta mr.mirko, solo por el hecho de tener el Linux "por debajo", se perderá aproximadamente un 15% del rendimiento general de la consola. En el mismo tema, calcula que usando a pelo los dos procesadores, se dispondría de un rendimiento aproximadamente un 50% superior al actual de la GP32 a 166Mhz.
Por otra parte, tiene una gran ventaja y es que muchísimos desarrolladores podrán compilar de forma relativamente sencilla y rápida programas, emuladores y juegos para la consola, de forma que al poco de tener la consola, habrá una gran cantidad de software disponible para ella.
Además, mr-mirko augura que para principios del año que viene (es decir en unos 2~3 meses desde el lanzamiento de la consola) ya se dispondrá de un emu de SNES fullspeed (según parece tiene intención de programarlo él mismo) :D
¿Qué piensan los desarrolladores españoles? Apreciaríamos mucho vuestros comentarios :brindis:
Un saludo
Anarchy
Furanchu
13/09/2005, 21:32
Vaya,que parece que al final no va a ser tan potente la consola...Aunque esto será al principio,claro.
A ver que opinan los expertos en la materia.Pero eso de que se que se haga un SDK cerrado,pues como que no lo veo yo muy en la filosofia de la gp32.No se suponia que iba estar orientada casi al 100% al desarrollo libre?Mal vamos.
En fin,que hasta que no pase un tiempo tras la salida de la gp2x,no se verá el auténtico potencial de la consolilla.
Mientras haya un Mame que soporte el Shinobi ya me puedo conformar :musico: Aunque ese emu de Snes al 100% suena muy bien... :babea:
Lo del SDK de código cerrado no me gusta mucho pero weno, lo podría pasar. Lo que sí me gustaría saber es que pasa con el kernel de linux, supongo que harán binarios tipo drivers de nvidia para los componentes "secretos" :rolleyes: como dijo un forero en otro post pero me gustaría saber la versión oficial.
Saludos...
Wenas!
Aunke al recibir la documentacion oficial firmando un NDA y teniendo ke cerrar el codigo, no se podria usando ingenieria inversa (ilegal en algunos paises creo) y sacar unas lib abiertas sin firmar ningun NDA ni nada??
Supongo ke costaria un poco, xo si Linux lo soporta con un simple parche...
He visto opinionen realmente fuertes en el foro de gp32x, y la verdad es ke algo frustrante si ke sta jugada. De ke tienen miedo GPH? De ke les roben la idea? :loco: O es MagicEyes la ke les impide hacer otra cosa? El HW cerrado nunca ha conducido a nada bueno. Esperemos ke, tal y como ocurrio con la GP32 en un principio, al final cambien de idea y se haga totalmente libre.
Salu2
Hola:
Es MagicEyes quien lo impide, no GPH.
El desarrollo para la GP2X seguirá siendo libre, tanto si se realiza con el SDK para linux como si alguien decide sacar un SDK especifico, aunque no pueda publicar el código fuente.
A pesar de que durante un tiempo no se pueda exprimir al máximo el potencial de la consola, es lo mismo que sucedió con la GP32 en sus comienzos. Por otra parte, en cuanto los desarrolladores empiecen a sacarle jugo y dominen el uso de ambos procesadores, la memoria nand, etc... las posibilidades de la máquina se multiplicarán.
Por decirlo de alguna manera, si cualquiera recompila un emulador directamente para usarlo en la GP2X, pero no aprovecha los dos procesadores, sencillamente tendremos un emulador funcionando en un micro a 200Mhz. Si el programador sabe utilizar los dos procesadores, el emulador tendrá un chute "de cagarse", :D incluso usando el SDK para Linux.
Así, lo lógico es que tarde o temprano se publique un SDK cañero, aunque sea de código cerrado, y se pueda exprimir al máximo la máquina, aunque tengan que pasar algunos meses.
Un saludo
Anarchy
Wenas!
Aunke al recibir la documentacion oficial firmando un NDA y teniendo ke cerrar el codigo, no se podria usando ingenieria inversa (ilegal en algunos paises creo) y sacar unas lib abiertas sin firmar ningun NDA ni nada??
Supongo ke costaria un poco, xo si Linux lo soporta con un simple parche...
He visto opinionen realmente fuertes en el foro de gp32x, y la verdad es ke algo frustrante si ke sta jugada. De ke tienen miedo GPH? De ke les roben la idea? :loco: O es MagicEyes la ke les impide hacer otra cosa? El HW cerrado nunca ha conducido a nada bueno. Esperemos ke, tal y como ocurrio con la GP32 en un principio, al final cambien de idea y se haga totalmente libre.
Salu2
¿Qué pasó con GP32, al principio era de HW cerrado?, perdonad mi ignorancia pero no tuve noticias de la consola hasta su salida en españa http://img347.imageshack.us/img347/1466/iconredface7ek.gif
Yo tengo una duda. Ellos estan usando Linux en la consola, no estan "obligados" a tener disponible el código fuente del kernel que estan usando?
Yo tengo una duda. Ellos estan usando Linux en la consola, no estan "obligados" a tener disponible el código fuente del kernel que estan usando?
Eso es lo que pensaba yo...
Puck2099
13/09/2005, 22:05
Eso es lo que pensaba yo...
Y así es.
Como los cambios no los hayan hecho en módulos aparte, como han sugerido por ahí, sino que estén en el propio kernel y no pongan a disposición el código fuente se van a buscar un lio gordo...
Saludos
Yo tengo una duda. Ellos estan usando Linux en la consola, no estan "obligados" a tener disponible el código fuente del kernel que estan usando?Sobre Linux, si, la licencia GPL les obliga a ello, pero se supone que estamos hablando que sobre el tema de lo cerradas que son especificaciones, y el problema de un SDK no es de GPH, que es quien se supone que ha creado/modificado el S.O. con kernel Linux que llevará, así que liberar, deberan liberar el código del kernel.
Lo que no entiendo muy bien es lo de MagicEyes, de hecho tengo entendido que para el MMSP2 tienen un SDK (no se si viene con la unidad de desarrollo), obviamente de codigo cerrado y previa aceptación de unos terminos de uso. Pero que yo sepa, hoy dia existen drivers "libres" (por poner un ejemplo) obra de programadores que no tienen que ver con la empresa del hardware para el que han creado ese driver (usando documentación extraoficial, ingeniería inversa, etc.) y que al no obtener la información de una fuente oficial no han tenido que firmar ningún acuerdo, por tanto pueden usar la licencia que quieran para ese driver, normalmente y en el mundo de Linux y *BSD, una licencia libre, así que analogamente si alguien opta por hacer un SDK y documentarse "por medios no-oficiales" puede ser un SDK libre. Solo especulo, la verdad es que todo esto lo veo muy raro.
P.D: Puck, otra vez nos ha pasado lo mismo xDDD
Vale,ahora mi segunda pregunta. Con el código del kernel se puede ver como se "trabaja" con la consola a bajo nivel. Ver como se ha de programar el hardware para hacer algo en concreto, y entonces a partir de ahí currarse un SDK independiente. O no es posible?
P.D.: Espero haberme explicado bien :$
Mmm, bueno para empezar a usar el 2º procesador es cuestion de hacer programas multi-hilo y que linux se encargue de gestionarlo, al menos usariamos los 2 procesadores.
mortimor
13/09/2005, 22:34
He aqui la trampa, el segundo procesador me temo que sera cosa de las SDL y si acaso del kernel de linux. Eso le resta posibilidades a la maquina, pero no sera algo como tener una GP32 a 200Mhz ya que las SDL si estan bien hechas seran muy rapidas. Veremos en que queda esto.
Ya me imagino a Mr. Spiv como un loco investigando de nuevo las caracteristicas hardware y haciendo test.
No me ha gustado nada esta noticia. :(
Mmm, bueno para empezar a usar el 2º procesador es cuestion de hacer programas multi-hilo y que linux se encargue de gestionarlo, al menos usariamos los 2 procesadores.
Con lo cual veremos emuladores cañeros en poco tiempo... pero desaprovechando ese 15% de recursos que se estará comiendo el Linux...
Crei haber leido en algun foro que se iba a poder ejecutar programas directamente, sin tener que cargar el s.o.!
Erm....
No me ha quedado muy claro que es el SDK
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
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... :chupete:
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? :shock:
anibarro
13/09/2005, 22:51
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?
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.
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
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. :D
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
13/09/2005, 23:04
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?
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 :brindis:
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.
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 :brindis:
Saludos...
P.D.: ¿Nos pasamos al IRC? xDD
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.
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.
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
13/09/2005, 23:21
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 :shock:
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%.
El 50%, estoy convencido que se refiere programando sin optimizacion, es decir, portando cualquier aplicacion de gp32 y usando solo el micro principal.
Si le sumamos el segundo micro la cosa tiene que cambiar, ya que las operaciones de pintado de pantalla y de procesado de sonido son las que hacian que los emuladores en gp32 fuesen lentos, y con un segundo micro, conseguimos mejores velocidades, asi que supongo que el rendimiento sera bastante mas elevado, mucho mayor si finalmente se puede overcloquear.
Pienso que que corra bajo linux esta bien para portar aplicaciones, pero si realmente perde un 15%, es mucho, deberian plantearse sacar un sdk en condicines, y que lo saquen ellos, no que le dejen el marron a programadores amateur, no puedes alcanzar la gloria sin mojarte el culo, eso ya lo consiguieron con la gp32, y me parece mucho abusar.
Saludos
Pienso que que corra bajo linux esta bien para portar aplicaciones, pero si realmente perde un 15%, es mucho, deberian plantearse sacar un sdk en condicines, y que lo saquen ellos, no que le dejen el marron a programadores amateur, no puedes alcanzar la gloria sin mojarte el culo, eso ya lo consiguieron con la gp32, y me parece mucho abusar.
Si tuviéramos que esperar a que los de GPH sacaran un SDK, nos daban las uvas :D Ellos han cogido el chip y el SDK de MagicEyes, le han puesto una pantalla, memoria, una carcasa y poco más.
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.
A mí entre ellos. Yo ni siquiera conocía la GP32 hace un mes, y buscando opiniones sobre la PSP en Barrapunto (http://www.barrapunto.com) me topé con un artículo que hablaba de una consola portatil que iba a llevar Linux y que podía ser programada de forma abierta ¿adivinais cual, no?
Así que pasito a pasito llegué hasta aquí... y estoy ansioso por recibir mi GPX2 (no tengo la GP32) y ponerme como un loco a trastear con ella. :babea: :babea: :babea: :babea:
Ahora debería venir vuestro "bienvenido a ésta, nuestra comunidad", un poco tarde, jeje, pero también es que he entrado sin presentarme :arriba:
Te lo podría decir yo pero soy nuevo y a mi tampoco me dieron la bienvenida :chupete:
Saludos...
adolomitica
13/09/2005, 23:56
Aunque sea con retraso bienvenidos a esta, nuestra comunidad.
Saludos.
firesign
13/09/2005, 23:57
Pues yo te diria que muy mal por no tener la GP32... no sabes lo que te pierdes :)
P.D.: yo no tengo la PSP, tampoco se lo que me estoy perdiendo... de todas formas, mi novia no me deja tiempo libre y dice que no me lo va a dejar en mucho tiempo :rolleyes:
No me había dado cuenta de este traslado de post a "GP2X - Programación". Y yo buscándolo en "General" :loco:
Saludos.
Pues yo te diria que muy mal por no tener la GP32... no sabes lo que te pierdes :)
Hombre, ya por estas fechas me espero a la GP2X, aunque si me decepciona (que no creo) o veo que el desarrollo avanza muy lento, quizá me plantee entonces una GP32.
Por cierto, ¿éste hilo no era para que los privilegiados desarrolladores que ya han podido trastear con el SDK diesen sus primeras observaciones? Porque creo que aún ninguno... XD (los que lo tengan estarán tran enfrascados con el cacharrejo que me imagino que se les habrá olvidado hasta pasar por aqui) :babea: :babea:
firesign
14/09/2005, 00:15
creo que los que iba a conseguir anarchy aun no estan por aqui... no?
A mí entre ellos. Yo ni siquiera conocía la GP32 hace un mes, y buscando opiniones sobre la PSP en Barrapunto (http://www.barrapunto.com) me topé con un artículo que hablaba de una consola portatil que iba a llevar Linux y que podía ser programada de forma abierta ¿adivinais cual, no?
Así que pasito a pasito llegué hasta aquí... y estoy ansioso por recibir mi GPX2 (no tengo la GP32) y ponerme como un loco a trastear con ella. :babea: :babea: :babea: :babea:
Ahora debería venir vuestro "bienvenido a ésta, nuestra comunidad", un poco tarde, jeje, pero también es que he entrado sin presentarme :arriba:
¿Un comentario en una noticia sobre PSP en Barrapunto que hablaba de la GP2X y con un enlace a gp32spain? Creo que sé quien es el responsable de que estés aquí :D
Bienvenido a esta nuestra comunidad hestimado hamigo :D
Por cierto, ¿éste hilo no era para que los privilegiados desarrolladores que ya han podido trastear con el SDK diesen sus primeras observaciones? Porque creo que aún ninguno... XD (los que lo tengan estarán tran enfrascados con el cacharrejo que me imagino que se les habrá olvidado hasta pasar por aqui) :babea: :babea:
no he visto ninguna evidencia en ningún sitio que indique que algún desarrollador tenga acceso al SDK ó a la consola todavía...
a esperar... :babea:
no he visto ninguna evidencia en ningún sitio que indique que algún desarrollador tenga acceso al SDK ó a la consola todavía...
a esperar... :babea:
Ah, yo lo decía por el título del hilo, sorry. Es lo que me dio a entender... :confused:
¿Un comentario en una noticia sobre PSP en Barrapunto que hablaba de la GP2X y con un enlace a gp32spain? Creo que sé quien es el responsable de que estés aquí
Bueno, el enlace a esta web no estaba en el comentario. Llegué aquí a través de Google
:)
Realmente en vista de que la GP32 no se puede "conseguir" y que se presupone que todo lo que habia para la GP32 vamos a poder tenerlo "sin problemas" para la GPX2 no me importa mucho tener que esperar para que le saquen todo el potencial.
Eso si, si al final resulta que me pillo la GPX2 y que no se portan las cosas de la GP32... pues como que me llevaria un chasco de cojones vaya.
De todas maneras esperar a que se haya experimentado con el potencial de la consola me parece , aunque razonable y logico, un poco como quien en la epoca de la SuperFamicon esperaba a que sacasen juegos que aprovechasen su verdadero potencial para comprarsela porque veia que en realidad hacia mas o menos lo que hacia la Nes, solo que con mejores graficos. Esto le paso a un colega, se paso años diciendo "Voy a esperar un poco mas" "Voy a esperar un poco mas" y cuando salio el Donkey Kong Country y fue a pillarsela ya estaban en proyecto la Saturn y la PSX.
Ademas.... ¿Cuantos años tiene la GP32? ¿No tendra la misma "Esperanza de Vida" la GPX2? ¿Voy a estar esperando dos años para pillarmela estudiando la evolucion del software que desarrollen para ella?
No creo que se tarde mas de dos meses en ver como evoluciona y como evolucionara la cosa.
Por cierto... ¿Estais haciendo promocion de la consola? ¡Cada vez que alguien me dice que se quiere pillar la PSP le mando a buscar informacion de la GPX2!
(Si, es muy rastrero) :cool:
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.
Para mí SDK siempre había querido decir Software Development Kit, pero buscando con el google he visto que se utiliza indistintamente.
no he visto ninguna evidencia en ningún sitio que indique que algún desarrollador tenga acceso al SDK ó a la consola todavía...
a esperar... :babea:
Pues según lo que he leído, me da la impresión que Squidge en gp32x ya tiene su kit y Mr.Mirko la documentación.
Por mi parte, considero que la decisión de GPH de utilizar Linux/SLD es acertada siempre y cuando salga un SDK eficiente que prescinda del sistema operativo. Como dice Anarchy, esto atraerá probablemente a unos cuantos coders más.
Pero yo separaría los coders en dos grupos: los que necesitan toda la potencia de la consola como los coders de emuladores y demos, y los otros coders que solo necesitan un buen SDK y si es portable, mejor que mejor. Yo me sitúo en este segundo grupo que es de lejos el grupo más importante. Nunca he programado en SDL, pero estoy convencido que el que estará implementado en la GP2X será bastante más rápido que el SDK oficial de la GP32 con lo que quedo completamente satisfecho ya que en raras ocasiones he necesitado más velocidad de la proporcionada en estándar por la GP32.
Tal como están las cosas, GPH ha dado prioridad a este segundo grupo, lo que permitirá que salgan muchos programas los primeros meses de la salida de la consola. Una buena manera de consolidarla.
GPH solo dará soporte a este grupo, pero lo positivo es que no prohíbe el trabajo del primero permitiendo que buenos coders saquen un SDK de bajo nivel que prescinda de Linux/SDL con lo que los coders del primer grupo también quedarán satisfechos.
Personalmente, lo que haría yo si tuviera la posibilidad de hacer este SDK de bajo nivel, sería intentar portar el SDL directamente a bajo nivel, tal como lo ha hecho Chui con la GP32, de esta manera los programas hechos por los coders del primer grupo, siempre se podrían recompilar más tarde con el otro SDL de bajo nivel para conseguir más velocidad si hiciera falta. Aunque no creo que sea así.
Lo que realmente espero, es que sea un SDK bien pensado y que no cometa los mismos errores que el SDK de MrMirko que personalmente no me gusta mucho, aunque tenga cosas muy interesantes.
Y ahora planteo otro problema: esta claro que los programas hechos con el SDK distribuido por GPH se instalaran de forma similar y que tendrán, un acceso fácil a través de algún menú del sistema operativo.
En el caso de pasar por alto el Linux, significa que o bien solo podremos ejecutar un programa/juego por tarjeta SD, o que lo primero que tendrán que programar los coders del primer grupo es un launcher para poder acceder a los diferentes programas de la SD.
Una saludo.
Oankali.
Puck2099
14/09/2005, 08:59
Nunca he programado en SDL, pero estoy convencido que el que estará implementado en la GP2X será bastante más rápido que el SDK oficial de la GP32 con lo que quedo completamente satisfecho ya que en raras ocasiones he necesitado más velocidad de la proporcionada en estándar por la GP32.
Oankali, yo también soy de los que nunca han tocado el SDL, pero me estoy poniendo las pilas para ir portando mis juegos a la GP2X y empezar a controlar como programar nuevas cosillas para ella.
Si te interesa, puedes echar un vistazo a esta web, que tiene unos tutoriales sencillitos y bastante claros para empezar a usar el SDL: Tutoriales SDL (http://cone3d.gamedev.net/cgi-bin/index.pl?page=tutorials/gfxsdl/index)
Saludos
wborland_es
14/09/2005, 09:10
Por cierto... ¿Estais haciendo promocion de la consola? ¡Cada vez que alguien me dice que se quiere pillar la PSP le mando a buscar informacion de la GPX2!
(Si, es muy rastrero) :cool:
$ony manipula a los chicos de Centro mail para que digan a los que quieren una DS que mejor se pillen una P$P, asi que tu conciencia debe estar tranquila ;) .
Oankali, yo también soy de los que nunca han tocado el SDL, pero me estoy poniendo las pilas para ir portando mis juegos a la GP2X y empezar a controlar como programar nuevas cosillas para ella.
Si te interesa, puedes echar un vistazo a esta web, que tiene unos tutoriales sencillitos y bastante claros para empezar a usar el SDL: Tutoriales SDL (http://cone3d.gamedev.net/cgi-bin/index.pl?page=tutorials/gfxsdl/index)
Saludos
Gracias Puck por la web, ya la conocía :).
También me gustaría portar mis programas, empezando por mi librería de fuentes, aunque lo primero que estoy haciendo es portar mi ejemplo de 16 bits que tengo en los tutoriales para la instalación del SDK oficial.
Por cierto, ¿alguien sabe si con el SDL de GPH todo estará listo para programar en C++? ¿O tendremos que volver a investigar hasta dar con la buena configuración?
Ya sé la respuesta, nadie lo sabe y habrá que esperar para ver pero bueno, tenía ganas de preguntarlo :p
Oankali.
ZeNiTRaM
14/09/2005, 09:32
no he visto ninguna evidencia en ningún sitio que indique que algún desarrollador tenga acceso al SDK ó a la consola todavía...
a esperar... :babea:
¿Seguro? Piensa un poco, ¿A quien mas les trae el devkit Craigx, ademas de a Squidge y Mirko? Porque a los 5 que lo iban a obtener, parece que a los 5 les ha llegado el SDK.. Que no digan que lo tengan no quiere decir que no lo tengan.. y no me voy mas de la lengua que me apedrean...
:ametra: :ametra: :ametra: y me veo aqui :canon2: :canon2: :canon2:
mortimor
14/09/2005, 10:57
Oankali tiene toda la razón en cuanto al enfoque que le ha dado GPH. "Lamentablemente" Mirko es uno de los que está desarrollando el SDK alternativo por lo que he leido y seguramente estara basado en el que ha hecho para la GP32, esperemos que el diseño lo mejore.
$ony manipula a los chicos de Centro mail para que digan a los que quieren una DS que mejor se pillen una P$P, asi que tu conciencia debe estar tranquila ;) .
Offtopic: Pues el otro dia me sorprendi al ver lo contrario :D:D. Llega una madre con su hijo y este queria una DS, aunque no decia nada, y la madre le decia al del CM: "pero esa pleyesteision de mano no es mejor que esta???" a lo que sorprendentemente el tio del CM dijo: "es diferente, esta orientada mas a ver peliculas, escuchar musica y tambien tiene sus juegos pero es mas un reproductor multimedia que una consola". Yo flipe en cinemascope psicodelico :D:D, no solo por recomendar la DS para al chaval (no llegue a escuchar nada de "la PSP es mas juvenil", vamos referencias a la edad) sino por vender la PSP como PMP y no tanto como megaconsola con juegos como los de la PS2 pero en tu mano ;).
"Lamentablemente" Mirko es uno de los que está desarrollando el SDK alternativo por lo que he leido y seguramente estara basado en el que ha hecho para la GP32, esperemos que el diseño lo mejore.
mr.mirko ya ha confirmado que no va a programar un SDK para la gp2x (se va a dedicar a los emus).
mr.mirko ya ha confirmado que no va a programar un SDK para la gp2x (se va a dedicar a los emus).
De hecho, dice que ha firmado el NDA con MagicEyes, por lo que si programa un SDK tendrá que ser cerrado.
mortimor
14/09/2005, 13:39
¿¿Siii?? vaya, pues hace no mucho le preguntaron en el foro de GP32X y creo que dijo que si no le convencia el SDK portaria el suyo. En fin, supongo que segun hayan ido las negociaciones para la obtencion de su unidad de desarrollo habra cambiado de opinion.
Aquí están sus palabras:
For me, iam no longer in the SDK creating role, iam now creating emulator stuff, thats more fun, and gives more fame
Vaya, iba a realizar ahora mismo la reserva pero despues de leer bien todo este tema y lo comentado en gp32x igual voy a esperar un poco ya que hay bastante gente esceptica con la posibilidad de que se pueda emular la neo-geo dada la perdida de potencia que va a suponer para la consola todo este tema. Teniendo en cuenta que la super mas o menos la puedo emular bien con la n-gage pierde bastante atractivo la gp2x sin poder llegar hasta la neo-geo! Asi que me parece ke voy a estar atento a ver como evoluciona un poco la scene o bien a que algun coder que este ya metido en el tema pueda asegurar que si es posible!
Por lo visto le interesa más la fama con un emulador que la satisfacción de preparar un SDK que otros coders utilizaran para sus creaciones.
Yo pensaría al revés. En fin, cada uno sus ambiciones.
De todos modos, yo de lo que diga el mirko... amos que no le haria demasiado caso.
Y si, he tenido ocasion de hablar con el.
EDIT: hablo sobre el comentario de la potencia real de la consola, vale que nunca va a ser 200+200Mhz, pero de ahi a decir que es solo un 50% por encima de una gp32 a 166 es exagerar un poco, en todo caso me creeria ese "solo" 50% si fuera usando el procesador principal de la gp2x solamente y el segundo para la parte grafica y sonora, entonces si tendriamos un aumento de mas o menos eso, un 50%.
Tened tambien en cuenta que la gp32 esta muy limitada por el tema de que todo, y cuando digo todo es ABSOLUTAMENTE TODO lo hace el unico procesador que tiene.
Descargamos el procesador de pintar graficos y procesar sonido, y tenemos un arm9 a 200Mhz pelao para lo que nos de la gana (mas o menos, un poco menos que mas)
Amos, que lo del 50% nada mas, me parece una exageracion por lo bajo.
En mi opinion, la cosa va a estar partiendo de que la gp32 es el 100%, en un 160-180% pero es solo una opinion personal, no me hagais mucho caso.
EDIT2: amos, que la cifra del 150% no es nada desdeñable, pero comparandola con una gp32 a 166 me parece poco, estamos hablando de el mismo procesador a 200Mhz con la mitad de carga practicamente, no es como comparar uvas con uvas y peras con peras.
mortimor
14/09/2005, 16:02
Para ese que esta preocupado por lo de emular Neogeo... creo que esa va a ser de las que menos problemas va a dar, sobra memoria ram.
Para algunos juegos de neogeo AES si falta ram, pero amos, 2 o 3, los mas tochos.
Es más, emular la NeoGeo tiene pinta de que va a ser una de las cosas relativamente sencillas...
Hombre, es basicamente una megadrive dopada, asi que tu me diras...
enkantao
14/09/2005, 16:27
Los datos que da Mirko no son muy esperanzadores, aun asi creo que no habria que creer demasiado ya que son aproximaciones (suponiendo, entre otras cosas, que Linux se coma un 15% de la maquina). Aun asi, yo creo que el SDK de GPH estara bastante optimizado. Si lo sueltan pronto le echare un vistazo.
Respecto al tema de la NeoGeo, es dificil asegurar q pueda emularse a la perfeccion sin optimizar el codigo. Buscare los requisitos del gngeo (emulador de neogeo para linux + sdl), aunq claro, sin las optimizaciones asm imagino que pedira bastante maquinita.
Oankali, la fama da kits de desarrollo para GP2X de gratis :P.
En fin, yo creo que todo es posible con la GP2X. ;)
Salu2
Hombre, es basicamente una megadrive dopada, asi que tu me diras...
xDDDDDDDDDD Bonita descripción para tan brutal maquina :D
Y si, hay juegos que no van a caber en la RAM ... ya veréis como habrá quejas de casuals gp2xeros; tiempo al tiempo :(
Que ganas hay de tenerla! Yo quiero mi gp2x ya :llorosr:
xDDDDDDDDDD Bonita descripción para tan brutal maquina :D
Que yo creo lo que cuentas
que es una bestia parda
la mega subida de vueltas
la tendria por lo que fardas
Pero no es tonteria
lo de tenerla por coj0nes
con la gp2x se podria
para eso esta el cyclone
No me ha quedado muy fino
no estoy muy entonado
pero que me da lo mismo
igualmente, me he explicado.
Perdonad la ignorancia... ya me imaginaba que las roms que sobrepasasen el tamaño de la ram no podrian ser emulables... pero en ese caso, como puede la psp emular neo-geo con 32 megas de ram? si emulase neo-geo cd desde un umd ok, pero como a dia de hoy solo se puede hacer a traves de memory stick...no lo entiendo es el mismo caso que la gp2x!
Y otra cosa, si por tema de ram algunas roms de neo-geo se quedaran fuera, como es posible que se especulase con la posibilidad de emular una psx si cada juego anda por los 400 megas x lo menos¿?
Ya se que igual estoy preguntando cosas obvias... pero me ha surgido la duda y seguro que alguno de vosotros sabe solucionarmela!
Puck2099
14/09/2005, 18:55
Y otra cosa, si por tema de ram algunas roms de neo-geo se quedaran fuera, como es posible que se especulase con la posibilidad de emular una psx si cada juego anda por los 400 megas x lo menos¿?
Los juegos de PSX no hay que cargarlos completos en memoria, sino que se va accediendo a la imagen en disco cuando se necesitan datos. Ten en cuenta que si hubiera que meterlo entero en memoria se necesitaría PCs con 1 giga de RAM para emular a la PSX, cosa descabellada.
Saludos
Me pregunto yo si se podría hacer una especie de caché para cargar las ROMs de NeoGeo por bloques, según se vayan necesitando, con algún sencillo algortimo de remplazo y bloques relativamente grandes para no generar mucho tráfico...
Claro que eso complicaría el emulador y disminuiría el rendimiento, del cual no andamos muy sobrados.
Me pregunto yo si se podría hacer una especie de caché para cargar las ROMs de NeoGeo por bloques, según se vayan necesitando, con algún sencillo algortimo de remplazo y bloques relativamente grandes para no generar mucho tráfico...
Algo tambien llamado memoria virtual y si, se podria. (con sus correspondientes tiempos de carga "aleatorios")
Perdonad la ignorancia... ya me imaginaba que las roms que sobrepasasen el tamaño de la ram no podrian ser emulables... pero en ese caso, como puede la psp emular neo-geo con 32 megas de ram? si emulase neo-geo cd desde un umd ok, pero como a dia de hoy solo se puede hacer a traves de memory stick...no lo entiendo es el mismo caso que la gp2x!
PSP emula neogeoCD con isos y mp3.
nefutari
14/09/2005, 21:16
Buenas a todos.
Sere claro, la verdad que venga o no venga cerrado, da igual (no se de programacion aviso) ya que siemrpe es bien sabido que la scene hacen a la consola. Ya ocurrio con GP32 y ocurrira con la GP2X. Todo es cuestion de tiempo, el unico problema que yo veria y la verdad no es que sea muy grave el problema para mi punto de vista, es que con casi toda certeza no se vera casi nada de la PSX en la GP2X, por la razon del trabajo que va a conllevar ello en la grandisima optimizacion de todo al final para llegar quizas a juegos unicamente 2D (seria un paso bastante bueno), pero bueno terminando y que me desvio del tema, la Scene es el arma de esta consola, y o lo liberaran a causas legales, o por questiones de poco software (no lo creo), o aunque lo saquen alguien ya habra echo un SDK mejor que el de ellos.
PD: Que de ilusiones tengo
Los datos que da Mirko no son muy esperanzadores, aun asi creo que no habria que creer demasiado ya que son aproximaciones (suponiendo, entre otras cosas, que Linux se coma un 15% de la maquina). Aun asi, yo creo que el SDK de GPH estara bastante optimizado. Si lo sueltan pronto le echare un vistazo.
Salu2
No se yo creo que me parece muy desesperanzador... pero a ver y esto que me lo confirme chui y la demas gente....
Las SDL si solo nos dan la surface y el page flip "no relentizan" por si, en el caso de la gp normal SI porque hay que "girar" la pantalla, pero espero que eso lo hayan cambiado en la gp2x...
Si NO fuese asi bastaria con ser capaces de "hackear" la SDL para que nos el buffer a pelo y usar el mismo tipo de rutinas "optimizadas" que estamos usando para la gp32...
Por otro lado el kernel de linux el solo NO puede chuparse el 15% ni el 5% del sistema le daria algo al linus...
Lo que SI deberia de dar es el soporte de multithread "posix" y multiprocesador o si no chungo porque volveriamos atener problemas en la gestion de memoria etc...
Por tanto SI la pantalla de la gp2x NO esta torcida y nos dan soporte Posix en el linux... no deberia de merecer la pena usar algo que no fuese liniux+SDL.
Si la pantalla esra chungamente orientada pues nada a usar las rutiasuqe tenemos en la gp y pasar de los sprites de la SDL o a "sobreescribir" las rutinas de la la SDL, pero teniendo aceleracion de graficos 2d es mu posibles que el "girado" de pantalla lo pudiese hacer el hard y tambien estariamos salbados... asi que por la SDL yo creo que no habra problemas d erendimiento.
Con el tema de multiprocesador ya es mas complicado....
Si no hay posix podriamo salvar el cuello si nos dan una libreria para comunicarnos a pelo con el otro micro.. pero eso ya pasaria por cosas "problematicas" como si se puede "compartir" la memoria o si la memoria que puede reservar un micro y hay que decir sela o si una allocacion de mmeoria hay que liberara en el mismo "micro" en el que se ejecuto o que haya mas de una stdlib en la aplicacion... vamso que muy chungo.
En resumen o dan especificacinones mas claras o no hay nada que hacer... yo creo que las estimaciones de mirko eran en mi peor caso, pantalla "chunga" y sin soporte de multiprocesador en el kernel
Unai.
P.D: Esto es una vomitona mental no esperes estructura ni orden...
Propeller
14/09/2005, 21:29
P.D: Esto es una vomitona mental no esperes estructura ni orden...
Hay algunos que incluso vomitando dicen cosas sensatas.
Propeller
Si no me equivoco, el "girado" de pantalla, en el caso de que viniera como en la GP32, en esta ocasión se podrá realizar por hard. Creo que lo leí o en la zona de consultas de GP2X o en algún e-mail de los que intercambiamos al poco de anunciarse la consola.
Por otra parte, me juraron y perjuraron que iban a tratar de facilitar al máximo el uso de los dos procesadores, por lo que supongo que con el SDK incluído se ofrece todo lo necesario para que los desarrolladores puedan usarlos sin tener que hacer virguerías.
Así que según lo que comentas, parece que el desarrollo en Linux+SDL en lugar de ser una traba va a suponer una ventaja... :brindis: :brindis: :brindis:
Hay algunos que incluso vomitando dicen cosas sensatas.
Propeller
Que tio más majete y bien queda que eres.... Por cierto hace mucho que no se de ti... estas en casa o esta en la "tierra de la penicilina" ??? que paso con vosotros al final??
Ya estas afilando los cuchillos pa la gp2x?? esperoq ue si ;)
Unai.
Si no me equivoco, el "girado" de pantalla, en el caso de que viniera como en la GP32, en esta ocasión se podrá realizar por hard. Creo que lo leí o en la zona de consultas de GP2X o en algún e-mail de los que intercambiamos al poco de anunciarse la consola.
Si es es cierto es una buena noticia, y parece fiable...
Editado: Lo he mirado y el hard de la gpx2 sopota 4 splits con rotacion y zoom independiente por split asi que eso seguroq ue ya no es problema.
Por otra parte, me juraron y perjuraron que iban a tratar de facilitar al máximo el uso de los dos procesadores, por lo que supongo que con el SDK incluído se ofrece todo lo necesario para que los desarrolladores puedan usarlos sin tener que hacer virguerías.
Eso ya te digo que es lo que mas dudas me da.... es la parte mas dedicada... si los de Magic Eyes no dan ellos y ael "kernel arreglado" no creo que los de gampark lo den... no creo que hayan podido hacerlo ellos...
De todas maneras si lo dan y deberian, puede ser muy chulo...asiq ue ya sabeis a probr todos en casa a usar multithreading :P
Así que según lo que comentas, parece que el desarrollo en Linux+SDL en lugar de ser una traba va a suponer una ventaja... :brindis: :brindis: :brindis:
SI y solo SI los dos puntos anteriores son favorables sera una gozada sino será más interesante :P
Unai.
P.D: Anarchy cuentame algo.. como va el bussines... ;P
Propeller
14/09/2005, 21:47
Que tio más majete y bien queda que eres.... Por cierto hace mucho que no se de ti... estas en casa o esta en la "tierra de la penicilina" ??? que paso con vosotros al final??
Desde hace meses ando de congreso a curso y de curso a congreso. Creo que el 2 de Octubre cuando vuelva de París se acabará todo este lío de los últimos 'n' meses, así que ya vamos a tener tiempo para charlar con más calma entonces :)
Ya estas afilando los cuchillos pa la gp2x?? esperoq ue si
Me da mucha pena, porque tengo muchas cosas, algunas bonitas, sin acabar para GP32... así que de momento soy gp2xcéptico.
Propeller
Puck2099
14/09/2005, 22:04
Me da mucha pena, porque tengo muchas cosas, algunas bonitas, sin acabar para GP32... así que de momento soy gp2xcéptico.
Bueno, siempre puedes acabarlas en la GP32 y luego portarlas a la GP2X como haré yo con el LK :)
Saludos
Propeller
14/09/2005, 22:42
Bueno, siempre puedes acabarlas en la GP32 y luego portarlas a la GP2X como haré yo con el LK
Eso seguro, pero primero tendré que acabarlas, porque ya llevo demasiados meses sin hacer nada. Además, también tengo *desde hace meses* cosas pendientes con la NDS, que no puedo probar en HW real porque hasta ahora no he podido hacerme con una supercard+superpass (aunque todavía no he ido a recogerlas).
Es por eso que los +-160€ de la gp2x sumados (sobre todo) a las incertidumbres que tengo sobre el aparato y su "filosofía" me echan para atrás cosa mala de momento.
No obstante, como no se cuánto puede pasar hasta que tenga la consola (si la llego a tener), ten por seguro que tan pronto tenga el sdk trataré de recompilar las cosas para gp2x :)
Propeller
enkantao
14/09/2005, 23:12
Así que según lo que comentas, parece que el desarrollo en Linux+SDL en lugar de ser una traba va a suponer una ventaja...
El tema de las SDL va a resultar bastante interesante, hay multitud de software(incluyendo emuladores) que puede funcionar en esta maquina sin apenas esfuerzo, asi que esperemos que se lo curren.
No me extrañaria que el emulador de GBC que sale en el video de GPH fuera un port de algun emu Linux + SDL, y lo hicieron en 5 minutos.
De todas maneras si lo dan y deberian, puede ser muy chulo...asiq ue ya sabeis a probr todos en casa a usar multithreading :P
Si lo dan.. van a salirle "hijos" hasta debajo de las piedras (lo se, lo se :canon2: ... pa matarme :ametra: :loco: )
Salu2
al final habra que meterse a mirar un poco de SDL. a ver si se aclaran todas las dudas de una vez
Lo de que linux se va a comer un 15% NI DE COÑA :loco:
Se supone que quien dijo eso se refería a las capas de software que habría entre el emulador y el hardware. Esa carga es MÍNIMA.
Voy a poner un ejemplo sobre la repercusión de múltiples capas de software. Los juegos emulados en linux bajo wine/cedega. Hay juegos que van más rápidos en wine que en Windows en la misma máquina. Es curioso teniendo en cuenta que tenemos:
El juego->Wine o Cedega (translada la API de Windows y DirectX a API X11)->Cliente X11->Servidor X11->GLX(opengl)->Driver gráfico en el kernel->hardware
Aparte, a la vez el kernel se está encargando de todas esas cosas que se tiene que encargar un kernel(ejem :D ) y hay aplicaciones de fondo ejecutándose. Aún así hay juegos que funcionan más rápido emulados en linux que nativamente en Windows. Curioso, desde luego.
Y si linux se usa en muchísimos sistemas embebidos, que son escasean tanto de recursos, es por algo.
Vaya que de 15% nada...
Es más, como dice Anarchy, linux va a dar muchos más beneficios que problemas. Es lo que vengo diciendo desde que descubrí la GP2X (antes GPX2 :D )
(información sobre la diferencia de velocidad linux/win/wine sacada de los foros de Gentoo y experiencia propia, no es inventada)
Vaya que de 15% nada...
Es más, como dice Anarchy, linux va a dar muchos más beneficios que problemas. Es lo que vengo diciendo desde que descubrí la GP2X (antes GPX2 :D )
(información sobre la diferencia de velocidad linux/win/wine sacada de los foros de Gentoo y experiencia propia, no es inventada)Es un lujo las ventajas del diseño de los sis. operativos unix. Desde luego la scene va a pegar un subidon con esta consola.
Y no creo que lo de que el linux sea cerrado sea un problema pues no creo que alguien tarde mucho en programar portar un kernel del arm9 de código abierto, que debería ser siempre así. La scene va a pegar un subidon con esta consola gracias a la flash memory y la ram. Además del coprocesador claro. :D
Hombre, cuando se habla de un 15% no se habla de que Linux se va a comer un 15% de los recursos, sino que la pérdida de rendimiento de programar los micros directamente en ensamblador a hacer a través del SO es de un 15%, lo cual puede parecer hasta lógico... otra cosa es que se gestionen los recursos HW tan bien como lo haría el kernel...
Claro que tambien soy de los que piensan que que el linux trae más ventajas que inconvenientes. Creo que no hace falta enumerarlas, pues ya se han dicho antes. Además, estoy seguro que más del 90% de los coders no tocaríamos el ensamblador aunque estuviera disponible, limitandonos a SDL o directamente al SDK...
Pero a pesar de todo creo que la GP2X debería estar abierta a las 2 posibilidades: programar por encima de linux, o directamente al micro. Creo que si los de GamePark han dejado abierta la posibilidad de cargar código antes del SO, es pq saben que sólo es cuestión de tiempo que alguien se salte la barrera, cosa que seguramente ellos gustosamente hubiesen hecho, pero que por movidas de contrato con MagicEyes no han podido hacer. :canon2:
suscribo lo dicho por WinterN.
Puck2099
15/09/2005, 08:39
(información sobre la diferencia de velocidad linux/win/wine sacada de los foros de Gentoo y experiencia propia, no es inventada)
Es que Gentoo no es Linux "normal", es el Ferrari de los Linux ;)
Pero a pesar de todo creo que la GP2X debería estar abierta a las 2 posibilidades: programar por encima de linux, o directamente al micro. Creo que si los de GamePark han dejado abierta la posibilidad de cargar código antes del SO, es pq saben que sólo es cuestión de tiempo que alguien se salte la barrera, cosa que seguramente ellos gustosamente hubiesen hecho, pero que por movidas de contrato con MagicEyes no han podido hacer. :canon2:
Quienes son esos mangarranes??? y por qué tienen ese derecho a beto???
Puck2099
15/09/2005, 11:45
Quienes son esos mangarranes??? y por qué tienen ese derecho a beto???
Más que nada porque son quienes fabrican los chips... :rolleyes:
Es un lujo las ventajas del diseño de los sis. operativos unix. Desde luego la scene va a pegar un subidon con esta consola.
Y no creo que lo de que el linux sea cerrado sea un problema pues no creo que alguien tarde mucho en programar portar un kernel del arm9 de código abierto, que debería ser siempre así. La scene va a pegar un subidon con esta consola gracias a la flash memory y la ram. Además del coprocesador claro. :D
A ver si es verdad porque me da la impresion de que ultimamente se nota una especie de bajon de animo respecto a las posibilidades de la GPX2 y lo que se vaya a hacer con ella.
Eso ya te digo que es lo que mas dudas me da.... es la parte mas dedicada... si los de Magic Eyes no dan ellos y ael "kernel arreglado" no creo que los de gampark lo den... no creo que hayan podido hacerlo ellos...
De todas maneras si lo dan y deberian, puede ser muy chulo...asiq ue ya sabeis a probr todos en casa a usar multithreading :P
Pues me respondo a mi mismo... y después de hablar con un colega más listo y guapo que yo del linux, he llegado a la conclusion de que el linux solo correra en el primer micro porque el otro no tiene mmu y por tanto fuera del alcance de linux... esto es un marron por varios motivos...
a) los punteros que maneje la aplicacion estaran en memoria "virtual" es decir no en direcciones fisiscas y para pasle datos al 2do micro habra que "traducirlos" y "bloquearlos" para que el sistema no los mueva... o que haya cierta cnatidad de memoria qu eel linux "no vea" o este bloqueada y nos la gestionemos nosotros
b) debido a esto es posible que o bien el segundo micro no pude hacer cosas que requieran alocaciones de memoria es decir que desde el segundo micro no se pueda llmar a la libreria estandar estando "resignado" a ser un "rompe numeros" que en mi caso no es problma pero que para otras aplicaciones si puede ser una putada... (Y sigo dandolo vueltas lo de la gestion de memoria)
c) Ya no podremos hacer las cosas en "posix" y que funcionen directamente ne la consola
Bueno esto de aqui arriba ser no es malo.. pero es menos fácil :) también despues de haber leido algun manual de los uqe tiene el la ww lopone bastante claro dice que micreo principal para el os y el sonido y el otro micro esta como coporcesadro programable por lo que todo apunta a que lo dan es un alibreria para "programar" el otro micro... ahora oslo falta ver como funciona eso...
Unai.
Eso seguro, pero primero tendré que acabarlas, porque ya llevo demasiados meses sin hacer nada. Además, también tengo *desde hace meses* cosas pendientes con la NDS, que no puedo probar en HW real porque hasta ahora no he podido hacerme con una supercard+superpass (aunque todavía no he ido a recogerlas).
Es por eso que los +-160€ de la gp2x sumados (sobre todo) a las incertidumbres que tengo sobre el aparato y su "filosofía" me echan para atrás cosa mala de momento.
No obstante, como no se cuánto puede pasar hasta que tenga la consola (si la llego a tener), ten por seguro que tan pronto tenga el sdk trataré de recompilar las cosas para gp2x :)
Propeller
Weeee ese Propeller! Venga hombre, tienes mi apoyo moral en todos tus proyectos, sobretodo esos "arrinconados" para la GP32 :).
Hombre, realmente espero que aparezcan nuevos coders del mundo linuxero que hayan conocido la nueva consola y se sientan atraídos. Hay comunidades muy grandes en internet (y "físicamente reales", como pude comprobar en las Jornadas de Programario Libre), haciendo un poco de publicidad, creo que habria gente muy interesada que no dudaría en portar sus aplicaciones.
Para esto, todo va a depender del SDK y sus pros/contras. Va a ser la clave del triunfo de la consola.
Cuando la tenga en mis manos, se la voy a enseñar a un profe de la Uni con el que hay bastante buen rollo. Con la GP32 ya se le caía la babilla, con la gpx2 espero que intente programar alguna cosa de probecho (se dedica a gráficos 3D y otras cosillas).
Por cierto Propeller, el VMUmod 2.0 tienes pensado continuarlo? Es que tengo una carcasa de VMU por allí tirada, esperando a ser perforada :D. Ah, y ya verás como vas a caer y te vas a pillar una gpx2 ... el gusanillo te va a corroer por dentro :p
He visto una version de UAE ( emulador de AMIGA ) para linux y especial para los micros ARM.
Mi pregunta es para los coders entendidos,¿ seria posible portar este emulador a la Gp2x ?.
Aqui os pongo las caracteristicas tecnicas de este emulador.
UAE emulates:
A 68000/010/020/040 CPU, optionally a 68881 FPU
OCS, ECS and AGA Graphics Chipset (including sprite-playfield collisions)
Up to 2MB Chip RAM and up to 8MB Fast RAM, or 8MB Chip RAM without Fast RAM
Up to 64MB Zorro III Fast RAM, independent of Chip RAM setting (68020+ only)
Up to 1MB Slow RAM, for extended compatibility with problem software
Up to 8MB of graphics card memory, usable by software that supports Picasso 96 compatible graphics cards
4 x 3.5" floppy disk drives (DF0:, DF1:, DF2: and DF3:). It's not possible to read Amiga disks, so these are emulated with disk files.
A hard-disk: either a harddisk image file or part of the native filesystem
Joystick support (with option of mapping joystick to numeric keypad)
Mouse support
Ability to run in various screen modes (for better display quality or better speed)
Full stereo sound support, consisting of 4 x 8bit channels
Simple parallel and serial port support. Note: the parallel port is not really implemented. Though it's sufficient for printing.
state-saving. you can save the state of your emulated Amiga and continue later on.
some other things which don't work well enough to mention them here...
¿ Que opinais ?,¿ merece la pena o seria lento en la Gp ?.
Un saludo a todos y Gracias. :arriba: '
Segata Sanshiro
15/09/2005, 18:17
El emulador completo quizás sería difícil, más que nada por la parte de AGA y tal (no sé de Amiga, repito de aquellas cosas que he oído las que entiendo), pero Amiga 500 será emulado tan bien como lo hace la Dreamcast.
Propeller
15/09/2005, 20:50
Weeee ese Propeller! Venga hombre, tienes mi apoyo moral en todos tus proyectos, sobretodo esos "arrinconados" para la GP32 :)
Gracias socio :)
Por cierto Propeller, el VMUmod 2.0 tienes pensado continuarlo? Es que tengo una carcasa de VMU por allí tirada, esperando a ser perforada :D.
Por supuesto. Tengo los componentes comprados desde hace meses, pero no saco tiempo. También tengo que acabar una escultura de Kirby, así que tal vez un día de estos.
Ah, y ya verás como vas a caer y te vas a pillar una gpx2 ... el gusanillo te va a corroer por dentro :p
Complicado lo veo. Tengo mis razones (además de lo escaso que he expuesto), pero solo las explicaré en privado, no quiero desanimar a nadie, sobre todo cuando puede que esté equivocado.
Propeller
bulbastre
15/09/2005, 21:23
Resumiendo: La pega es que durante los primeros meses no se podrá aprovechar el 100% de las posibilidades de la máquina, hasta que alguien desarrolle un SDK, que tendrá que ser de código cerrado.
Corregidme si mete la pata
SDK> conjunto de librerias
SDK cerrado> se puede usar libremente pero no se puede modificar el SDK en si
pregunta 1> porque esto ultimo?
pregunta 2> Es por culpa de esos Magic Eyes / quienes son / porque quieren jodernos la parada?
pregunta 3> El SDK no vendra de parte de los de gueimparc?
pregunta 3.1> en caso de que no, tendremos que desarrollarlo nosotros / es este el SDK que se supone que debe ser cerrado / si lo desarrollamos nosotros no podemos dejarlo abierto?
pregunta 4> la GP32 sufria de lo mismo?
Digo esto porque leyendo el post inicial de Anarchy no me he enterado de mucho, y da la sensacion de que el resto de posts ya hablan con conocimiento.
Corregidme si mete la pata
SDK> conjunto de librerias
SDK cerrado> se puede usar libremente pero no se puede modificar el SDK en si
pregunta 1> porque esto ultimo?
pregunta 2> Es por culpa de esos Magic Eyes / quienes son / porque quieren jodernos la parada?
si no me equivoco, magic eyes son los que diseñan los chips arm. Por lo que he leído en estos foros, y he podido deducir, no quieren que exista un sdk libre, porque ello implicaría que se difundieran todos los conocimientos a bajo nivel del chip, por lo que "cualquiera" podría copiar el diseño del chip.
Es por eso que si alguien quiere desarrollar el sdk, ellos le dan la información necesaria, pero firmando un NDA.
Segata Sanshiro
15/09/2005, 21:39
Complicado lo veo. Tengo mis razones (además de lo escaso que he expuesto), pero solo las explicaré en privado, no quiero desanimar a nadie, sobre todo cuando puede que esté equivocado.
Lo que pasa es que muchos tenemos confianza ciega en gente como tú en cuanto a programación se refiere :rolleyes:
Intentaré contestarte lo mejor que pueda.
1. Sí.
2. En este caso, sí. Se puede usar libremente, pero no distribuir su código fuente (el del SDK, no el de los programas en el que lo utilices).
3. Porque la empresa fabricante del chip no quiere que su tecnología sea revelada. Un SDK contiene información importante que muestra el funcionamiento de la máquina a bajo nivel.
4. Aparentemente no, al menos de momento.
5. Sí podremos desarrollar uno nosotros. Pero tendremos que pedir las especificaciones a MagicEyes después de firmar un NDA o Acuerdo de No Divulgación, y el SDK que hagamos, no los programas en los que lo utilicemos, deberá ser de código cerrado, no público.
6. Al principio parece ser que sí. Después Mr. Mirko hizo su propio SDK y mucha gente lo usa como alternativa seria, pero era de código abierto. Si hubiera sido de código cerrado no creo que hubiera cambiado mucho la historia, pero algunos programadores se hubieran resignado a usarlo.
Personalmente y aunque sea por ignorancia, si me dan un buen SDK que aproveche la máquina a fondo, me da igual que sea cerrado si no me imponen restricciones a la hora de distribuir mi programa.
Con lo que he tardado en escribir esto seguro que 100 personas se me han adelantado xDD
PD: Al final solo Alberdi ;)
Propeller
15/09/2005, 22:13
Lo que pasa es que muchos tenemos confianza ciega en gente como tú en cuanto a programación se refiere :rolleyes:
Te agradezco de corazón este comentario, pero creo que no lo merezco.
Propeller
Segata Sanshiro
15/09/2005, 22:21
Te agradezco de corazón este comentario, pero creo que no lo merezco.
Propeller
Lo digo, como mínimo, porque alguien que no sabe de programación se cree lo que un programador le dice ;) Y eso es verdad.
Estaba mirando lo que pensaban en gp32x y están más preocupados por si emulará N64 y cosas por el estilo, aparentemente.
Propeller
15/09/2005, 22:38
Estaba mirando lo que pensaban en gp32x y están más preocupados por si emulará N64 y cosas por el estilo, aparentemente.
Hay una canción de un grupo llamado Propellerheads, cuyo título es "History Repeating". Tengo una sensación facilmente descriptible por ese corte sonoro:
Queríamos emular bien SNES -> sus juegos se reeditan en GBA (1 arm) -> Acabamos no emulando bien ninguna con la GP32 (1 arm tocho).
Ahora quien emular N64 -> sus juegos se reeditan en NDS (2 arm) -> Acabaremos por no emular bien ninguna con la GP2X (2 arm's tochos).
El paralelismo es de guardería.
Propeller
porque siempre hay algo que tiene que salir mal, *****. pos que se busquen la vida pa que sea libre. encima aora a los pocos meses de sacarla ya nos empiezan a capar con el jodido procesador gay
Kit básico de desarrollo (Standard Development Kit).
En realidad esSoftware Development Kit ;)
En realidad esSoftware Development Kit ;)
Leches, es verdad. Me había liado con J2SE (Standard Edition).. ultimamente tengo demasiados despistes :chupete:
menos mal que aquí estais para corregirme :arriba:
No te creas, tuve que leerlo dos veces para darme cuenta de que ponía software, la primera vez lo leí e inconscientemente me di cuenta de que algo no encajaba :P
Vamos que es un error aceptable en la informática, que tenemos acrónimos para parar un tren o dos :brindis:
porque siempre hay algo que tiene que salir mal, *****. pos que se busquen la vida pa que sea libre. encima aora a los pocos meses de sacarla ya nos empiezan a capar con el jodido procesador gay
No te preocupes tanto :rolleyes:.
Como dijo el elfo es importante que se emule la snes y la neogeo además de prefeccionar el resto de emuladores para que rulen perfectos en la GP2X. Ques lo importante y a lo que nadie hace caso. :loco:
Lo del SDK es tontería. Aunque el SDK al final no sea libre y no deje aprovechar la maquina al 100% (Linux/SDL) siempre se puede hacer cosas en ensamblador (como interface para (C/CPP)... o es que acaso no hay especificaciones de los dos procesadores por separado?? tiene algo de especial este aparte de no tener el coprocesador la unidad de control de direcciones??
No se me parece que estas son nimiedades en comparación con el problema de que alguien se tome en serio portar y poner a full los emuladores que sabemos que "deben" funcionar en la GP2X:
anteriores + SNES + neogeoCD + amiga500 y que vayan bien.
Ese es nuestro único problema :D
Con todos mis respetos hacia Mirko y cia, creo que estan equivocados.
Por tener Linux no se pierde un 15%, nose vosotros pero yo no pretendo tener el cron, syslog, etc.. rulando en la GP2X. Opino que no se pierde ni un 1% si se compila un kernel decente.
Por otra parte, tener un SDL por la propia peña del hardware puede ser sencillamente de cojo-nes.
Aparte, las pthreads en GNU/Linux con las dos CPUs operativas y enlazando facilmente con SDL_thread, puede ser la repera de potente y facil de usar. Recordad que manejarse con dos CPUs no es sencillo, toda ayuda es poca.
Resumiendo, la idea es muy buena aunque ya no esta la cosa tan abierta como en principio se vende, ahora falta que se haga bien.
Con todos mis respetos hacia Mirko y cia, creo que estan equivocados.
Por tener Linux no se pierde un 15%, nose vosotros pero yo no pretendo tener el cron, syslog, etc.. rulando en la GP2X. Opino que no se pierde ni un 1% si se compila un kernel decente.
Por otra parte, tener un SDL por la propia peña del hardware puede ser sencillamente de cojo-nes.
Aparte, las pthreads en GNU/Linux con las dos CPUs operativas y enlazando facilmente con SDL_thread, puede ser la repera de potente y facil de usar. Recordad que manejarse con dos CPUs no es sencillo, toda ayuda es poca.
Resumiendo, la idea es muy buena aunque ya no esta la cosa tan abierta como en principio se vende, ahora falta que se haga bien.
De lo de las threads olvidate las threas las tendras solo corrinedo en uno de los micro s el otro mico no tiene mmu y ellinux no lo va a ni a conocer....
Mi apuesta es que te vas a hacer un "tread" en el otro micro tu al que vas a mandar "tareas" para que te las vaya montando tu a tu bola ...
Te dara unaLibreria que te deje
-Resetear el otro micro
-Crear "Mutex" o algo similar
-se PC en el otro micro y poco mas....
El resto tu, ejemplo el codigo de pintar los tiles del negogeo lo puedes tener ahi entero, acediendo a la estructura que tu feneras por frame en el emu y el otro micro se encarga de pintarla a saco.. pero en ese orden de cosas...
Unai
Unai.
Unai, deja de darle al orujo cuando escribas que te salen las letras torcidas XDDDDDD
Pos eso mismo, menos mal que lo ha dicho chui cabr0nes, que si no a mi me tomais por loco, como va a comerse un 15% de proceso el sistema? si eso me lo hace mi pc, lo tiro a la basura, y creedme, mi pc con linux ya anda cargadillo, y con windows mas aun.
Y bueno, siempre que el segundo procesador se pueda usar para aligerar al primero, sera cojonudo, la cosa es que sea facil de hacer, amos, yo asi de primeras no se si sere capaz de hacer algo que lo aproveche... (claro que tampoco he sido capaz de hacer nada que aproveche la gp32 porque soy un vagomierdaquenoseponenuncaycuandoseponesecansaense guida)
Segata Sanshiro
16/09/2005, 21:07
Si va a ser tan inusable, para qué c0ño ponen ese procesador?
Si va a ser tan inusable, para qué c0ño ponen ese procesador?Los coprocesadores tienen mucho juego.
¿De verdad creeis que no se va a poner nadie a currarse una buena api para esto?
Al final tarde o temprano surgirán ingenieros apasionados con los procesadores en paralelo, tener en cuenta que esta consola es todo un lujo para probar cosas así.
Yo no me preocuparía. Creo que esta consola va a tener mucha mas scene que cualquiera de las salidas hasta ahora.
Segata Sanshiro
16/09/2005, 22:03
Los coprocesadores tienen mucho juego.
¿De verdad creeis que no se va a poner nadie a currarse una buena api para esto?
Al final tarde o temprano surgirán ingenieros apasionados con los procesadores en paralelo, tener en cuenta que esta consola es todo un lujo para probar cosas así.
Yo no me preocuparía. Creo que esta consola va a tener mucha mas scene que cualquiera de las salidas hasta ahora.
Hombre, supongo que en GPH algo de idea de diseñar consolas tendrán. Y si han incluido un procesador así será porque se puede usar, pero en fin...
Yo dejaría de darle vueltas a ese asunto, porque está claro que el procesador se utilizará, ya sea de forma directa o indirecta. La cuestión real es cuanto tiempo se tardará en extraerle todo el potencial.
mortimor
16/09/2005, 22:52
Pues si mis sospechas son ciertas y las SDL no le sacan mucho jugo (que no lo exprimiran al máximo, seguro) me temo que tardaria mas de un año en empezar a exprimirlo bien, hay mucho que programar y no hay muchos en la scene que sepan manejar dos procesadores a un nivel tan bajo como el que requiere. Eso si, una vez se cree una expansion para el SDK que facilite estas tareas...
Si se tarda un año en exprimir el máximo potencial de la consola ya nos podemos dar con un canto en los dientes :D :D :D
La GP32 ha tardado más de 3 años en empezar a demostrar de lo que es capaz realmente, con el MAME GP y con el DrMD. La ventaja que tiene la GP2X es que los coders vienen con mucha experiencia por detrás exprimiendo las posibilidades de la GP32, por lo que personalmente creo que se tardará mucho menos en empezar a sacarle jugo al hardware de la máquina.
Propeller
17/09/2005, 01:36
Si se tarda un año en exprimir el máximo potencial de la consola ya nos podemos dar con un canto en los dientes :D :D :D
Jouni Korhonen va a tardar 48 horas. Tal vez menos, dependiendo de la marca del café que use.
Propeller
http://gbax.com/gp2xreal.jpg
Je, je,... que tacaños son estos coreanos.
Si, parece que van a enviar GP2X sin carcasa a los desarrolladores. :D
Si, parece que van a enviar GP2X sin carcasa a los desarrolladores. :D
me parece que no vas desencaminado
Al parecer, el segundo procesador no se puede usar mientras no se hackee :(
Posteado por squidge en gp32x:
It's not exactly difficult to use both processors, but the Linux used on the gp2x at the moment dedicates the second processor to mpeg4 decoding duties, and doesn't allow user code on it. So therefore we need to "hack" it to get it to run our code instead of mpeg4 code.
Al parecer, el segundo procesador no se puede usar mientras no se hackee :(
Posteado por squidge en gp32x:Hamigito si me contarás esto refiriendote a que no podríamos acceder a un segmente de memoria porque está protegido por los descriptores del kernel pues vale, pero al coprocesador se puede acceder directamente en ensamblador. Desde ese punto de vista no hay problema. :) Otra cosa es que el kernel no nos ofrezca facilidades, pero por lo que he visto hasta ahora me conformo conque el hardware funcione bien.... espero que los de GPH almenos sepan hacer eso. Tendremos que currar un poco. :D
Puck2099
21/09/2005, 16:15
Después de unas dos o tres semanas, Anna me ha contestado y me ha pasado un user y password para una web (en coreano o chino) donde se supone hay material relacionado con el desarrollo para GP2X.
Por los nombres de los archivos parecen cosas interesantes (gplayer, armtools, ¿WinCE para MMSP2?), en cuanto los baje y eche un vistazo os lo haré saber :)
Saludos
espero que los de GPH almenos sepan hacer eso. Tendremos que currar un poco. :D
Ese es el problema: los de GPH no van a hacer nada al respecto. Squidge está trabajando en ello y supongo que lo conseguirá.
Perdonadme si digo alguna burrada, pero me estoy iniciando en la consola esta, que puede que me interese y todo.
El caso es que lo que mas me llama la atencion de la GP2x es el uso de tarjetas sd (porque ya tengo una) y la posibilidad de programar mis juegos, pero lo hago en Fenix, y un requisito indispensable es que tenga las SDL. Y estoy leyendo tanto lo de cambiar el software que me pregunto si, al cambiarlo, se perderian las SDL, y por lo tanto, la posibilidad de tener mis juegos hechos en fenix (o el nazcadreams, me encanta :D).
Me preocupa mas que pueda poner mis juegos, juegos hechos por los demas (y sin gastar un duro, claro), ver videos, poner musica (he leido que se podra) que si el software de bajo o medio nivel es de codigo cerrado o no, que lo sea, no significa que no den medios para usarlo.
En fin, que si se mantiene dicha posibilidad y se consigue que la cosa vaya mas rapida, genial, pero si ya de por si podemos tener juegos hechos por nosotros y jugarlos donde queramos (y fardar un poquito) y encima estacion multimedia ¿por que preocuparse?
Offtopic: ya que estoy, lo pregunto. Overclockear es peligroso si se hace sin saber y he oido que a la gp32 se le hacia ¿es cierto?¿es seguro?¿que mejora de rendimiento se obtiene?¿soy demasiado novato? :chupete:
timofonic
22/09/2005, 11:30
Con lo del código cerrado se van a comer un colin...
Que se haga ingeniría inversa y punto, que no firmen NDA y saquen SDK limpio y abierto...
Si sacan porquerías cerradas, muy mal lo tienen, será otra Zodiac...
Edito: Hace bastante que he visto la información técnica, así que si sacan SDK no libre, tenemos a grandes de la scene (mr mirko, Chui, Una-I...) para que se unan y entre todos saquen un equivalente 100% libre (licencia BSD o algo así al ser posible) y yo creo que incluso aún mejor... Unas SDL optimizadas para el hardware de la GP2x al máximo, optimizadas en ensamblador... podrían dar mucho juego...
Propeller
22/09/2005, 15:27
Edito: Hace bastante que he visto la información técnica, así que si sacan SDK no libre, tenemos a grandes de la scene (mr mirko, Chui, Una-I...) para que se unan y entre todos saquen un equivalente 100% libre (licencia BSD o algo así al ser posible) y yo creo que incluso aún mejor...
Chui y Una-i tienen ya bastante curro por su parte. Mr Mirko ahora dice que se divierte más haciendo emuladores, que ya no está en el rol de crear SDK.
¿Nadie se acuerda de Mr Spiv? Si hay alguien que va a hacer ingeniería inversa (a hackear la consola, que estoy harto de estas palabras bien sonantes) y a programar en ensamblador a pelo, ese va a ser Mr Spiv. Cuando este tío se haya merendado la consola, otro vendrá y hará una capa de abstracción. ¿Quién será? Pues no lo se, pero tampoco tiene por qué ser un capo de la scene "heredada".
Propeller
Topochan
22/09/2005, 22:48
Si se uutiliza el SDK proporcionado por Anna es libre por la sencilla razon de que SDL es libre y la slibrerias que usa son libres (zlin,libjpg, libpng, etc...) el unico problema es el segundo procesador pero por lo que se puede ve si va a ser accesible.(se ha visto en otro hilo)
hectorblanco
10/11/2005, 21:02
Ahí va mi teoria o lo que deduzco como debe de funcionar el conjunto SDK oficial + Linux + SDL.
El SDK supongo que incluirá las librerias SDL dentro (espero que las más importantes por lo menos: ttf, mixer, e image). La optimización y demás no tendría que ir directamente de las liberias, sino que el linker es el que ya prepararia el ejecutable para la plataforma en concreto, y los modulos de hard del kernel (que no tienen porque ser abiertos estos modulos) serian los encargados de para cada proceso, mandar las tareas a uno u otro CPU. Es decir, si ejecutamos funciones de dibujado en SDL el kernel deberia discriminarlas y enviarlas al segundo procesador, o al acelerador 2D, y el resto, como es IA, memoria ...etc, al CPU principal.
Esto ya funciona así en cualquier máquina. Cuando haces algo en 3D en OGL por ejemplo, no tienes que hacer cosas raras para que las ejecute el GPU en vez del CPU. Esto lo realiza el kernel con los drivers gráficos. Esto me imagino que irá igual en la GP2x.
Y lo del multihilo dudo que sea lo que todos pensamos en un principio. El coprocesador supongo que estará destinado a tareas de aceleración multimedia, que ojo, no es poco. Es ya un gran avance, además de que la programación con threads es un auténtico conñazo.
No se si es exactamente así como funcionará la consola, pero es como yo por lógica creo que deberia hacerlo.
El SDK supongo que incluirá las librerias SDL dentro (espero que las más importantes por lo menos: ttf, mixer, e image). La optimización y demás no tendría que ir directamente de las liberias, sino que el linker es el que ya prepararia el ejecutable para la plataforma en concreto, y los modulos de hard del kernel (que no tienen porque ser abiertos estos modulos) serian los encargados de para cada proceso, mandar las tareas a uno u otro CPU. Es decir, si ejecutamos funciones de dibujado en SDL el kernel deberia discriminarlas y enviarlas al segundo procesador, o al acelerador 2D, y el resto, como es IA, memoria ...etc, al CPU principal.
Así debería ir en teoría pero hasta que alguien de la scene se lo curre, habrá que esperar. Eso sí, cuando eso suceda, ports como el scummvm quedarán de p.m. : con el Broken Sword, por ej., se podrá usar el segundo micro para reproducir los videos y el audio :babea:
timofonic
10/11/2005, 22:09
Recordar el Shenmue de saturn, usaba los DSPs de sonido para 3D...
Propeller
10/11/2005, 22:23
Recordar el Shenmue de saturn, usaba los DSPs de sonido para 3D...
¿De dónde has sacado esa información?
Propeller
Animos a los coders españoles (aunq mejor tendre q pillar alguna capilla de esas de HG :)) seguro q se lograran grandes cosas pero el problema es la paciencia (o la falta de ella:P)
Segata Sanshiro
10/11/2005, 22:59
¿De dónde has sacado esa información?
Propeller
A mí también me encantaría saberlo.
¿El Broken Sword? Supongo que si ese se logra el Mundo Disco 1 y 2 tambien serian posibles ¿nop?.
Una pregunta a aquellos que tengan una GP32, las aventuras graficas ¿Que tal son en una pantalla pequeña y sin raton? Es que con la pantalla grande ya te tienes que dejar los ojos para encontrar el micro-objeto clave que estara casi-escondido en una esquina pos en una pantalla pequeña... No se, que hable la voz de la experiencia.
Puck2099
11/11/2005, 05:28
¿El Broken Sword? Supongo que si ese se logra el Mundo Disco 1 y 2 tambien serian posibles ¿nop?.
Una pregunta a aquellos que tengan una GP32, las aventuras graficas ¿Que tal son en una pantalla pequeña y sin raton? Es que con la pantalla grande ya te tienes que dejar los ojos para encontrar el micro-objeto clave que estara casi-escondido en una esquina pos en una pantalla pequeña... No se, que hable la voz de la experiencia.
Pues yo me he pasado el Fate of Atlantis y genial :)
Lo único malo es acertar en ciertos objetos pequeños, pero verse se ve todo bien ;)
Saludos
Hay varias cosas:
1. No creo que linux se coma un 15% de rendimiento, ni siquiera para las operaciones de i/o, no no, eso seria inaceptable y cualquier programador linux se los va a confirmar.
2. Para mi es obvio que la gente de GamePark se las esta currando para aprovechar el hardware lo mejor posible desde el kernel, tambien me parece que la version de SDL del GP2X debe estar super optimizada para correr sobre el susodicho hardware, una implementacion de "referencia" simplemente no serviria.
3. Vamos, esta cosa puede correr un video de 700x480 a 30fps con sonido usando mplayer y sin siquiera tener una FPU, si eso no es aprovechar el hardware entonces no se que es...
4. Obviamente el segundo procesador esta ahi para algo, si ya lo estan empleando para decodificar mpg4 significa que efectivamente se puede usar!, tengo la sospecha que en el GP2X el SDL debe usar el segundo procesador para algo de forma silenciosa.
5. Linux es una ventaja no una desventaja, uds ahora solo piensan en rendimiento de graficos y ese tipo de cosas porque solo imaginan juegos y emuladores, por eso es que alucinan con un SDK de acceso directo al hardware, pero la GP2X va a servir para muuucho mas que eso, la cantidad de programas interesantes que podria portear a la GP2X es inmensa (imaginan tener un driver para poder acceder a un disco duro usb?, o un teclado usb?).
6. En un principio quien creyo que la GP32 seria capaz de lo que es ahora??, no balsfemen amigos fieles.
Hay varias cosas:
1. No creo que linux se coma un 15% de rendimiento, ni siquiera para las operaciones de i/o, no no, eso seria inaceptable y cualquier programador linux se los va a confirmar.
2. Para mi es obvio que la gente de GamePark se las esta currando para aprovechar el hardware lo mejor posible desde el kernel, tambien me parece que la version de SDL del GP2X debe estar super optimizada para correr sobre el susodicho hardware, una implementacion de "referencia" simplemente no serviria.
3. Vamos, esta cosa puede correr un video de 700x480 a 30fps con sonido usando mplayer y sin siquiera tener una FPU, si eso no es aprovechar el hardware entonces no se que es...
4. Obviamente el segundo procesador esta ahi para algo, si ya lo estan empleando para decodificar mpg4 significa que efectivamente se puede usar!, tengo la sospecha que en el GP2X el SDL debe usar el segundo procesador para algo de forma silenciosa.
5. Linux es una ventaja no una desventaja, uds ahora solo piensan en rendimiento de graficos y ese tipo de cosas porque solo imaginan juegos y emuladores, por eso es que alucinan con un SDK de acceso directo al hardware, pero la GP2X va a servir para muuucho mas que eso, la cantidad de programas interesantes que podria portear a la GP2X es inmensa (imaginan tener un driver para poder acceder a un disco duro usb?, o un teclado usb?).
6. En un principio quien creyo que la GP32 seria capaz de lo que es ahora??, no balsfemen amigos fieles.
Hasta donde yo se (que alguien me corrija si me equivoco):
1. Linux + SDL se comen bastante más que ese 15% del que hablas.
2,3,4. Las SDL que hay ahora para GP2X no utilizan el segundo procesador para nada. Que yo sepa el segundo procesador solo se usa para la aceleración de la decodificación de los videos (cortesía de Magic Eyes). Pero como todavía no hay SDK publicado oficialmente por GamePark, quizás se lo esté currando GamePark para la versión que publiquen oficialmente, veremos.
5. Linux + SDL es una gran ventaja para portar los emuladores y juegos, no cabe duda. Pero para que funcionen bien con el micro a 200 MHz de la GP2x hará falta *creo* acceder directamente al hardware, y/o conseguir utilizar el segundo micro a 200 MHz para algo más que gastar pilas :-)
6. Creo que todo mejorará pronto, sinceramente creo que la GP2X será en breve la plataforma ideal para lo que todos queremos, paciencia ;-).
Alguien sabe si usará gráficos de 32 bits o tendremos que seguir con los 16 de la gp32?
Más que nada porque le estoy dando caña a las SDL y me gustaría saber de antemano las restricciones que me voy a encontrar para cuando quierar portar las cosas a gp2x [wei4]
5. Linux es una ventaja no una desventaja, uds ahora solo piensan en rendimiento de graficos y ese tipo de cosas porque solo imaginan juegos y emuladores, por eso es que alucinan con un SDK de acceso directo al hardware, pero la GP2X va a servir para muuucho mas que eso, la cantidad de programas interesantes que podria portear a la GP2X es inmensa (imaginan tener un driver para poder acceder a un disco duro usb?, o un teclado usb?).
En cualquier caso, diría que Linux, más que una ventaja, es una posibilidad. Pero no la única (ver aquí (http://www.gp32x.com/board/index.php?showtopic=21904)).
1. Linux + SDL se comen bastante más que ese 15% del que hablas.
De memoria es posible, pero de CPU ni de coña :)
timofonic
22/11/2005, 10:42
¿De dónde has sacado esa información?
Propeller
Al parecer usaba "AVR processing", pero ya he leido por ahí que son fantasmadas de los "fanboys"...
timofonic
22/11/2005, 10:51
Hasta donde yo se (que alguien me corrija si me equivoco):
1. Linux + SDL se comen bastante más que ese 15% del que hablas.
Yo no creo que una buena distribución optimizada basada en OpenEmbedded (http://oe.handhelds.org) consuma tanto, nisiquiera de memoria, pero mejor que opinen los programadores que conozcan bien Linux.
2,3,4. Las SDL que hay ahora para GP2X no utilizan el segundo procesador para nada. Que yo sepa el segundo procesador solo se usa para la aceleración de la decodificación de los videos (cortesía de Magic Eyes). Pero como todavía no hay SDK publicado oficialmente por GamePark, quizás se lo esté currando GamePark para la versión que publiquen oficialmente, veremos.
Linux no te impide acceder a bajo nivel para nada, además, podría crearse un módulo para manejar el segundo procesador, por ejemplo, y así facilitar el acceso a este de varias formas...
5. Linux + SDL es una gran ventaja para portar los emuladores y juegos, no cabe duda. Pero para que funcionen bien con el micro a 200 MHz de la GP2x hará falta *creo* acceder directamente al hardware, y/o conseguir utilizar el segundo micro a 200 MHz para algo más que gastar pilas :-)
Eso habrá que verlo, todo depende de como se facilite a nivel de OS.
6. Creo que todo mejorará pronto, sinceramente creo que la GP2X será en breve la plataforma ideal para lo que todos queremos, paciencia ;-).
Tampoco hay que ser tan optimista, hay que ser más realista y esperar a ver que pasa. GP2X no estrena un mercado virgen como lo hizo la GP32, ahora hay más "competencia" y la gente quiere tener lo que ya ha visto en otros sistemas o su "predecesora"...
Damizean
22/11/2005, 16:24
Usará 16 bpp (5R 6G 5B).
P.D. Tengo la intensa sensacion de haber sido timado...
mortimor
22/11/2005, 16:28
Usará 16 bpp (5R 6G 5B).
P.D. Tengo la intensa sensacion de haber sido timado...
:rolleyes: :D:D:D:D:D Ya se te pasara hombre, eso con una actualizacion del firmware...
PD: tu firmwre, no el de la consola :p
:rolleyes: :D:D:D:D:D Ya se te pasara hombre, eso con una actualizacion del firmware...
PD: tu firmwre, no el de la consola :p
Pues yo no lo veo un tema para tomarselo a risa :loco:
mortimor
22/11/2005, 16:59
Hombre, el sarcasmo es rara vez aceptado por todos. Pero, ¿no crees que reirse es mejor que lamentarse???
Que conste que no me rio de Damizean, sino de la situacion actual.
Hombre, el sarcasmo es rara vez aceptado por todos. Pero, ¿no crees que reirse es mejor que lamentarse???
Que conste que no me rio de Damizean, sino de la situacion actual.
Sorry .
Usará 16 bpp (5R 6G 5B).
P.D. Tengo la intensa sensacion de haber sido timado...
16 bpp? :-(
Y usa esa distribución de componentes (R5 G6 B5), o usa (R5 G5 B5 0) o (0 R5 G5 B5)?
Es que me parece raro que le de un bit más a un componente que a otros.
La verdad es que da un poco de palo no poder saltar a los 32bits de color, y esto entre otras cosas pues como que es una jarra de agua fria y a uno le hace temer que no va a haber un cambio cualitativo importante entre la vieja y querida gp32 y esta.
Yo de todos modos mantengo la confianza en la scene y estoy convencido de que se le sacará mucho partido al nuevo cacharrito, no tiene sentido ser derrotistas, sentirse timados o frustrados cuando aún no ha salido. ;-)
mortimor
22/11/2005, 17:58
La unidad de video y demas historias soportan 32bit de color y hasta 1024x768 de resolucion, la LCD no :)
La codificación 5:6:5 no es tan extravagante como puede parecer en un principio.
Esta regida por el hecho que el ojo humano distingue más tonalidades de verde que de los otros dos componentes.
Por lo visto, el hecho de que la pantalla accepte más colores por hard de lo que puede el soft, repercute en una mejor definición de los colores. Si la pantalla también fuera de 200K colores, no tendrian la misma calidad. (lo he leído en algún lugar).
Es verdad que a nivel programación, 24 bits sería lo ideal, 32 en el caso de un canal alpha.
Pero si somos vagos, el SDL ya se encarga de todo ello y no hay diferéncia a la hora de programar en 15, 16, 18, 24... bits, ya que es questión de hacerlo todo en 24 bits. Salvo a la hora de optimizar claro. En ese caso, mejor ajustar los gráficos a los colores reales del modo de vídeo seleccionado.
La unidad de video y demas historias soportan 32bit de color y hasta 1024x768 de resolucion, la LCD no :)Es que no me entero...
Entonces ¿cuantos colores reales podremos ver en la consola?
¿Y esto que pusieron en la web * 3.5" TFT LCD (Hardware : 16.7 Million Colors / Software: 260,000 Colors)?
La unidad de video y demas historias soportan 32bit de color y hasta 1024x768 de resolucion, la LCD no :)
En realidad hasta 24bpp, aunque las funciones de aceleración 2D sólo funcionan a 16bpp.
15.1 OVERVIEW
MP2520F has a 2D Graphic Controller to accelerate the GUI performance and is optimized in the O/S with various Graphic bases such as Windows CE or Linux.
32-deep source image FIFO
Dual-bank Command Register Set provides efficient interface between CPU and graphics controller
Hardware support for font color expansion, font caching, and image caching
Graphic acceleration support for 16 bits per pixel mode
Graphic acceleration functions include:
- Rectangular source-copy block transfer (BitBLTs)
- Transparent source-copy BitBLTs
- Masked source-copy BitBLTs
- Monochrome-to-color expansion on source and pattern data
- Pattern and Rectangle Fills
- 256 Raster Operations (ROPs)
When the direction of the screen is changed, RGB ROTATION rotates the detailed components on the screen. The ROTATION rotates selected shapes by 0, 90, 180 or 270 degrees and its BIT PER PIXEL (BPP) is 8, 16 or 24 bits.
Aquí está la tabla de los modos de video de la GP2X:
Hasta donde yo se (que alguien me corrija si me equivoco):
1. Linux + SDL se comen bastante más que ese 15% del que hablas.
2,3,4. Las SDL que hay ahora para GP2X no utilizan el segundo procesador para nada. Que yo sepa el segundo procesador solo se usa para la aceleración de la decodificación de los videos (cortesía de Magic Eyes). Pero como todavía no hay SDK publicado oficialmente por GamePark, quizás se lo esté currando GamePark para la versión que publiquen oficialmente, veremos.
5. Linux + SDL es una gran ventaja para portar los emuladores y juegos, no cabe duda. Pero para que funcionen bien con el micro a 200 MHz de la GP2x hará falta *creo* acceder directamente al hardware, y/o conseguir utilizar el segundo micro a 200 MHz para algo más que gastar pilas :-)
6. Creo que todo mejorará pronto, sinceramente creo que la GP2X será en breve la plataforma ideal para lo que todos queremos, paciencia ;-).
1. Esplicame como es que kernel+sdl se comen ese 15%+
2.3.4. Si como dices el segundro procesador solo sirve para decodificar mpeg4, entonces la gente de gamepark no deberia hacer la publicidad de que la consolita cuenta con doble procesador, si no mas bien con un chip de decodificacion de mpeg4....
5. .asm{}
6. Estoy completamente de acuerdo contigo :D
Creo que seria muy agradable poder poner a dormir al pinguino de vez en cuando para poder aprovechar todo el poder de la consolita, sin embargo tambien creo que subestiman mucho al pajaro ese y a SDL.
Alguien tiene una buena descripcion de la distribucion del hardware dentro del GP2X?, me gustaria saber como estan interfaceados los dos procesadores y la memoria.
2.3.4. Si como dices el segundro procesador solo sirve para decodificar mpeg4, entonces la gente de gamepark no deberia hacer la publicidad de que la consolita cuenta con doble procesador, si no mas bien con un chip de decodificacion de mpeg4....El segundo procesador es totalmente programable y puede usarse para lo que se quiera, pero el kernel de linux solamente lo usa como descompresor mpeg.
Damizean
22/11/2005, 21:32
Se podran ver 65.536 colores distintos en pantalla :P
Alguien tiene una buena descripcion de la distribucion del hardware dentro del GP2X?, me gustaria saber como estan interfaceados los dos procesadores y la memoria.
Existe un documentación de MagicEyes muy completita del MMSP2 en pdf que se puede conseguir en varios sitios, como por ejemplo este (http://www.gp2xdev.co.uk/).
Muchas gracias WinterN, si linux usa el segundo chip para procesamiento de video quiere decir que entonces programaron alguna especie de driver para esto, me imagino que con un kernel modificado se podria usar el segundo procesador para otras cosas.
Creo que la pega no es el linux, son las restricciones que GP le estan poniendo al kernel, segun mi parecer el desarrollo de la GP2X se va a distribuir en algo asi como 3 ramas:
1. Los que estan felices con el kernel actual y solo se van a dedicar a portear aplicaciones
2. Los que no estan felices con el kernel actual y va a querer modificarlo para aprovechar mejor el hardware
3. Los que no estan satisfechos con ninguna de las dos opciones anteriores y quieren tener acceso directo a todo el hardware
Creo que a pesar de que estos ultimos van a tener que esperar un poco mas, las tres ramas son perfectamente viables e incluso recomendables.
Estoy bastante de acuerdo con lo que dices, E.J., de todas maneras, lo que hay que tener en cuenta es que ninguna de las 3 ramas es incompatible con la otra. Lo explico:
Los que están contentos con el Kernel actual harán ports rápidamente, lo que en poco tiempo nos dará la oportunidad de usar programas de, por llamarlo de alguna manera, "poca potencia". En cambio, los que se dediquen a retocar el Kernel, lo que harán es conseguir que se puedan utilizar programas de "media potencia", pero los primeros se podrán seguir utilizando directamente, o, si hay que hacer algún cambio radical en el Kernel, con pocos arreglos. Los terceros se dedicarán a usar toda la potencia de la máquina, para conseguir usar aplicaciones de "gran potencia", pero muy posiblemente saldrá algún gestor de arranque (GRUB en GP2X? :rolleyes: ) para que podamos seguir cargando nuestro Kernel Linux, con lo que los 2 primeros seguirán funcionando perfectamente. Entonces, y a menos que los terceros consigan algo bestial, dependiendo de qué queramos, arrancaremos Linux o el otro firmware.
De todas maneras, pienso que un kernel bien optimizado es muy ligero, nos da unas subrutinas muy cómodas para trabajar contra el hardware y recordar que C es un lenguaje muy potente, y siempre podemos hacer alguna parte del Kernel en ensamblador, para ganar potencia en ejecuciones críticas.
Lo que está claro es que el Kernel tiene que poder aprovecharse para subir/bajar la velocidad de los procesadores, para que los componentes que no se usen en un momento dado, salida de tv, aceleradora 2d, etc... no consuman, e incluso para dejar el segundo procesador en reposo si la aplicación no lo requiere, como escuchar mp3. La ejecución multitarea real me parece secundaria por ahora, ya se verá con el tiempo.
PD: Creo que lo de "poco potente", "media potencia" y "gran potencia" me han quedado fatal explicados, espero que se entienda.
PD2: Tengo que desempolvar mis apuntes de Laboratorio de sistemas operativos, a ver si hago un Kernel revolucionario y podemos emular Xbox360 en la GP2X [wei4]
Yo me apunto a la emulacion del 360 en GP2X!!! ( o por lo menus en fake para el dia de los inocentes).
Por supuesto seria genial tener un bootloader tipo grub o lilo para poder seleccionar el sistema operativo que queremos arrancar (jeje, esto cada vez suena mas lindo *.*)
Yo dudo que puedas optimizar el kernel de linux mas de lo que esta, ya de esto se han encargado los chorrocientos de programadores del kernel alrededor del mundo.
Lo que si se puede optimizar son los modulos adjuntos del kernel: I/O, sonido, video, aceleracion 2d. etc... esto porque los modulos si son muy dependientes de la plataforma sobre la que corren y mientras mas a bajo nivel los hagas pues mejor, lo mismo pasa con las librerias.
Seria muy bueno que la comunidad linux viera potencial en el GP2X y muchos de esos extremadamente habilidosos programadores le dedicaran un poco de tiempo.
En fin... como dice mi abuela, estamos contando los polluelos antes que se rompan los huevos, mejor esperamos a ver de que es capaz la GP2X.
1. Esplicame como es que kernel+sdl se comen ese 15%+
2.3.4. Si como dices el segundro procesador solo sirve para decodificar mpeg4, entonces la gente de gamepark no deberia hacer la publicidad de que la consolita cuenta con doble procesador, si no mas bien con un chip de decodificacion de mpeg4....
5. .asm{}
6. Estoy completamente de acuerdo contigo :D
Creo que seria muy agradable poder poner a dormir al pinguino de vez en cuando para poder aprovechar todo el poder de la consolita, sin embargo tambien creo que subestiman mucho al pajaro ese y a SDL.
Alguien tiene una buena descripcion de la distribucion del hardware dentro del GP2X?, me gustaria saber como estan interfaceados los dos procesadores y la memoria.
Vamos a ver:
1. Utilizando SDL en lugar de acceso directo al hardware se pierde aproximadamente (según me ha contado gente que ha tratado con SDL) un 10-20% de rendimiento. Utilizando Linux en lugar de acceso directo a la GP2X sólo tienes acceso a la mitad de la memoria (32Mb) y además de esas 32Mb una parte está reservada para Linux, además de la merma de rendimiento que conlleva tener cargado el Linux por debajo... Y créeme que en las pruebas con el MAME GP32, al incrementar el tamaño de los ejecutables se perdía rendimiento...
2.3.4. Ahora el segundo procesador lo usa el kernel para acelerar la reproducción de videos, y se supone que se usará en las SDL para acelerar el rendimiento (cuando la nueva versión de las librerías se haga pública, a esperar...)
5. asm {}... xDDD no sa jodío.
timofonic
23/11/2005, 11:40
Vamos a ver:
1. Utilizando SDL en lugar de acceso directo al hardware se pierde aproximadamente (según me ha contado gente que ha tratado con SDL) un 10-20% de rendimiento. Utilizando Linux en lugar de acceso directo a la GP2X sólo tienes acceso a la mitad de la memoria (32Mb) y además de esas 32Mb una parte está reservada para Linux, además de la merma de rendimiento que conlleva tener cargado el Linux por debajo... Y créeme que en las pruebas con el MAME GP32, al incrementar el tamaño de los ejecutables se perdía rendimiento...
2.3.4. Ahora el segundo procesador lo usa el kernel para acelerar la reproducción de videos, y se supone que se usará en las SDL para acelerar el rendimiento (cuando la nueva versión de las librerías se haga pública, a esperar...)
5. asm {}... xDDD no sa jodío.
Franxis, creo que estas metiendo muchas escusas, no se si me vuelvo paranoico o es que quereis convencer a todo el mundo a que no use Linux...
La GP32 solo se parece a la GP2X con el micro. Esas pruebas no se a que sistema son, me parece demasiado bestia, además de que si no hay pruebas en condiciones sobre rendimiento pueden decir lo que quieran, me fio más de Chui que lo que hayan contado a alguien por muy buen coder que seas (que no lo discuto, ese MAME es una maravilla ;)).
Sobre la RAM, eso es un fallo de GPH y de sus multiples chapuzas, meten un "driver" que se queda con parte de la ram y el micro, pero que se use Linux en GP2X no implica que solo tengas 32MB, sino que es un fallo de GPH al no hacer las cosas en condiciones y cargar/descargar las cosas bajo demanda.
1. Utilizando SDL en lugar de acceso directo al hardware se pierde aproximadamente (según me ha contado gente que ha tratado con SDL) un 10-20% de rendimiento.
Eso te lo puedo confirmar yo. La misma versión del xrick usando las SDL en la GP32 es un 15-20% más lenta que con el SDK de Gamepark.
Eso te lo puedo confirmar yo. La misma versión del xrick usando las SDL en la GP32 es un 15-20% más lenta que con el SDK de Gamepark.
Supongo que todo es cuestión de como se ha implementado el SDL para la GP32.
Sospecho que se podría conseguir la misma velocidad que con el GPSDK siempre y cuando el SDL no tenga que convertir los gráficos ya que eso de poder utilizar gráficos de cualquier formato (me refiero a colores), está muy bien pero tiene que repercutir por huevos en el rendimiento si se hace de forma generalizada (una rutina para todas las posibilidades usando las máscaras).
Franxis, creo que estas metiendo muchas escusas, no se si me vuelvo paranoico o es que quereis convencer a todo el mundo a que no use Linux...De verdad que empiezas a ser cansino. Nadie quiere convencer a nadie de que no use Linux, solo se expone la situación REAL de la consola, tú te limitas a especular.
mortimor
23/11/2005, 17:07
Supongo que todo es cuestión de como se ha implementado el SDL para la GP32.
Sospecho que se podría conseguir la misma velocidad que con el GPSDK siempre y cuando el SDL no tenga que convertir los gráficos ya que eso de poder utilizar gráficos de cualquier formato (me refiero a colores), está muy bien pero tiene que repercutir por huevos en el rendimiento si se hace de forma generalizada (una rutina para todas las posibilidades usando las máscaras).
Creo que acabas de dar en el clavo con la cuestion. Es muy bonito disponer de la conversion de formato y luego quejarnos de que es mas lento. Es obvio que algo de rendimiento se lo quedan las SDL, pero creo que habria que probarlo en igualdad de condiciones y sin que se fuerce la conversion.
En lo que se nota diferencia no es entre GPSDL y GPSDK. Si pruebas a copiar los buffers y hacer el cambio de buffer con las "funciones" de MrSpiv veras que le ganas bastante rendimiento (de tener un scroll vertical y musica ogg a 25-30 fps y pasar a usar los registros directamente par hacer el scroll como MrSpiv y obtener 35-40 fps). Pero es normal sacrificar potencia a cambio de facilidad de uso :), puedes tener mas de 100 sprites(por decir algo, se pueden bastantes mas, si no recuerdo mal) de 16x16 en pantalla a 60fps y 16 bpp, pero es un coñazo molestarse en ir mas alla de una demo y meterlo en un juego.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.