Autor Tema: [PORT] GP2X  (Leído 21909 veces)

Drumpi

  • Hero Member
  • *****
  • Mensajes: 6340
  • Karma: 162
  • Odio el periodo "entre proyectos"
    • La web de Drumpi
Re: [PORT] GP2X
« Respuesta #15 en: Marzo 21, 2009, 04:22:26 pm »
Bueno, para hacer un juego aun no está la cosa, no. Los fallos de cambio de colores (por cierto, se me olvidó volver a comentarlo: FPG 8bits en modo 16 bits) y la caida a 38 fps son problemas bastante serios para ponerse a desarrollar. Sin embargo, el rendimiento general, el funcionamiento del motor (básico para muchos de mis proyectos) y que ya no hay "hard-reset" (L+R+clic del joystick para cerrar el programa, algo similar al alt+x) le dan muchísimos enteros. Sumados a las funciones HW del módulo gp2x sí que lo ponen como serio candidato a sustituir mi herramienta de programación habitual.
Respecto al hardware, no te comas la cabeza: la gp2x sólo dispone de dos procesadores ARM overclockeables (lo normal es tener sólo uno a 200MHz, pero se podrían usar los dos a 250MHz de forma estable, más segun la consola), así que todo va por soft. Lo que comentaba es que ya existen librerías que actúan sobre el hardware, que sustituyen las funciones del SDK oficial, sólo habría que compilar el BGDI usándolas. Otra cosa es que se quiera usar el segundo nucleo, eso ya sólo los BUENOS programadores saben hacerlo.
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)

SplinterGU

  • Hero Member
  • *****
  • Mensajes: 12902
  • Karma: 377
Re: [PORT] GP2X
« Respuesta #16 en: Marzo 21, 2009, 05:11:14 pm »
no se trata de usar los 2 procesadores, no estamos buscando eso... por lo menos, no por ahora... eso de BUENOS programadores no lo entendi...
ufenix usa una SDL con acceleracion de hardware, pero es una lib statica, nosotros necesitamos una dinamica... ni bien la tengamos vas a tener un buen rendimiento... por otro lado, no estamos usando overlocking...
Download Lastest BennuGD Release: http://www.bennugd.org/node/2

Sandman

  • Sr. Member
  • ****
  • Mensajes: 298
  • Karma: 48
Re: [PORT] GP2X
« Respuesta #17 en: Marzo 21, 2009, 07:53:18 pm »
Like SplinterGU said: uFenix was compiled using a static SDL version. Hardware accelerated indeed, but we can't use a static one, because it is important to keep the modularity. It doesn't take a "GOOD" programmer to link to a library.

I also experienced problems in 8bit, but I didn't investigate it. Maybe I should force 16bit in the port.

I did not know of L+R+stick. I don't know of a lot of things unique for the GP2X or uFenix, so if you can give me a list, I will implement this.

I can't read Spanish insinuations and nuances that well, so I will have to ask: were you implying I am a bad programmer or not?
-- Sandman

Drumpi

  • Hero Member
  • *****
  • Mensajes: 6340
  • Karma: 162
  • Odio el periodo "entre proyectos"
    • La web de Drumpi
Re: [PORT] GP2X
« Respuesta #18 en: Marzo 22, 2009, 03:45:00 am »
Uf, i try to explain myself...
I don't know how UFenix was compiled. I try to question to Puck2099 in gp32spain, but i have no answer.
I know that exists an mmuhack library, that boost memory access, a more optimized SDL libraries (that static libraries, i think) an others more, made by the sceners, because the official SDK isn't as powerfull as people done. Maybe, they doesn't do a clearly programing, or stylist... in spain says "chapuza" to this :D :D :D

I don't calling you BAD programmers, no no and no. I only said that to program using the second CPU is very very very HARD (ALL, repeat, ALL the gp2x programers around the world says the same, only two or three programs can use both CPU: a game from GPH, the MegaDrive emulator and... don't know). I didn't xpect that you can do, but if you can, i think most of gp2x programmers will call you God :D :D :D

I tried to call someone to go here and help you, but...
And please, don't make a hard reset!!! i've got nightmares because it, i can't do games that uses L and R buttons simultaneously (a tank game, for example). It's an addition by Puck for compatibility with gp32 fenix games without exit (or div-coded games, i don't remember), like an splash screen (you can change it with a png image with the same name of DCB, or disable by -nosplash argument) or overclocking (another argument).

If my alzheimer leave me, tomorrow i'll try to upload two mobile-phone snapshots of win and gp2x bennu, running the tiled scroll, maybe will help to you.

And sorry for worried you... and my scary english ^^U I can read english with no matters, but write...
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)

SplinterGU

  • Hero Member
  • *****
  • Mensajes: 12902
  • Karma: 377
Re: [PORT] GP2X
« Respuesta #19 en: Marzo 22, 2009, 10:04:15 am »
Well, I'll reply you for this...

I was reading (this only I requiered 10 minutes), and I must say that use of 2 CPU aren't really complex... but this isn't the problem... the problem is that now don't exists reason for do this... BennuGD (or Fenix) don't are multithread (or concurrent processing)... then. when we will have splited in two threads interpreter and video, then in this moment, we can think in use 2nd CPU...

We don't matter how uFenix works... or how uFenix version is different version of Fenix... we, in BennuGD, want an unique version for all plattaform... with right exceptions in the sourcecode in the official proyect...

Well, really isn't hard use 2nd CPU... maybe for rookie programmer... but for programmers that works previous with concurrent access to memory, IPC, shared memory, semaphores mecanisms (own implementation or not) and other stuffs... this aren't a problem...

P.S.: I read your post in gpspain (or something), first thanks for publish the news, well, I must say that you have functions for check battery, turn on/off leds (I think) and others HW stuff from gp2x, this are in the gp2x.dll (if I don't wrong)...
And 8 bits graphics have problem now in gp2x... Sandman is working in it... this don't have relation with palettes changes... maybe have it, with default RGB masks... but no with the palettes changes...

Again, thanks for test this port... and for your comments... all criticism are constructive...
« última modificación: Marzo 22, 2009, 10:06:29 am por SplinterGU »
Download Lastest BennuGD Release: http://www.bennugd.org/node/2

Sandman

  • Sr. Member
  • ****
  • Mensajes: 298
  • Karma: 48
Re: [PORT] GP2X
« Respuesta #20 en: Marzo 22, 2009, 02:12:46 pm »
I don't calling you BAD programmers, no no and no. I only said that to program using the second CPU is very very very HARD (ALL, repeat, ALL the gp2x programers around the world says the same, only two or three programs can use both CPU: a game from GPH, the MegaDrive emulator and... don't know). I didn't xpect that you can do, but if you can, i think most of gp2x programmers will call you God :D :D :D
Okay, sorry for the misunderstanding. :)

Well, I just successfully built a working hardware accelerated SDL shared object. It does give a slight increase, but it's not fantastic. The reason is obvious: Bennu doesn't use SDL for blitting every graphic, it uses its own routines. Only the final screen is blitted using SDL, so the speed gain is minimal. Still, it's nice to have.
At first I didn't compile some FB support in the library, so the gp2xmenu wouldn't boot, but then I did. Now the gp2xmenu also boots using this version, but there appears a cursor in the topleft corner which was not there with the original SDL shared object.

So, I think this means Bennu cannot take advantage of the hw accelerated SDL (Fenix did not either, because Fenix also had its own routines). But maybe it can use other libraries, maybe rlyeh's or something, I don't know enough of the GP2X. I do know that I need to finish the input mapping like uFenix did and make it optional.
-- Sandman

Danielo515

  • Sr. Member
  • ****
  • Mensajes: 480
  • Karma: 4
    • Blog del Blogbo
Re: [PORT] GP2X
« Respuesta #21 en: Marzo 22, 2009, 04:13:34 pm »

Por otro lado, hay que tener en cuenta que para bennu todavia no estan las librerias SDL con aceleracion por hardware... Sandman esta trabajando en eso (bueno, creo que ahora esta entretenido en otras cosas... espero que cuando lea esto se vuelva a poner en curso...)...


Esas librerias por hardware SDL, serán solo para GP2x o debo entender que en PC también vamos a tener por fin aceleración Hardware (aunque sea para gráficos 2D, yo no uso otra cosa).

Dios, cada día me gusta más bennu. Al final me voy a programar aplicaciones de todo tipo con este lenguaje,  ya verás....

SplinterGU

  • Hero Member
  • *****
  • Mensajes: 12902
  • Karma: 377
Re: [PORT] GP2X
« Respuesta #22 en: Marzo 22, 2009, 04:14:26 pm »
solo gp2x...
Download Lastest BennuGD Release: http://www.bennugd.org/node/2

Sandman

  • Sr. Member
  • ****
  • Mensajes: 298
  • Karma: 48
Re: [PORT] GP2X
« Respuesta #23 en: Marzo 22, 2009, 04:26:29 pm »
I am also working on a OpenGL library for Bennu, but there are problems with it. The absolute worst problem is that Bennu always expects access to the graphics at pixel level, but that's very, very slow, using OpenGL. Furthermore, palettes can be an issue. However, I plan on using shaders next, so almost all these things can be resolved (well not the pixel access of course), even blendops. So the next few steps will be to also modify the existing Bennu modules to be more compatible with hardware accelerated low level libraries.
-- Sandman

Drumpi

  • Hero Member
  • *****
  • Mensajes: 6340
  • Karma: 162
  • Odio el periodo "entre proyectos"
    • La web de Drumpi
Re: [PORT] GP2X
« Respuesta #24 en: Marzo 22, 2009, 05:35:26 pm »
Ok, thanks for your interest. Don't think i'm telling you all this because i want to be Bennu2x the same as UFenix: if you don't want to use HW SDL, accelerated libraries or else, don't use it. Now Bennu is almost as fast as UFenix (except the fps falls with movement in my test) and this is most than i expect for a first try.

Maybe, secuencial programmers aren't ready to program in an (concurrente) language, like DIV/Fenix/Bennu users are :D :D :D I read a lot of people saying lot of things about second core, and my programming knowledge is still very poor (just a little C++, and all these years with Fenix, nothing about IDEs, toolchains, etc... only writing code), and when i read about "copy all the program to the second CPU memory map", i get a Homer Simpson face hearing something about nuclear energy.

I don't think you neet to separate the video routines from executing the DCB, gp2x programmers use second CPU to play music an FX. Don't know if it's the best option or the easier way.

As i promised, there is the two images (from gp2x and PC) i take with my mega-high cuality mobile phone camera  ;D Just only to see the psicodelic level of Bennu2x, jejejeje.
« última modificación: Marzo 22, 2009, 05:37:07 pm por Drumpi »
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)

Sandman

  • Sr. Member
  • ****
  • Mensajes: 298
  • Karma: 48
Re: [PORT] GP2X
« Respuesta #25 en: Marzo 22, 2009, 06:50:01 pm »
It's not the issue whether we want it or not. The owner of his/her GP2X should decide what SDL shared object he/she wants, not us. That's one of the ideas behind shared objects. I really don't understand why the GP2X community encourages the use of static linking, instead of telling people to download better shared objects; I guess the answer is that it's easier.

Programming for a multicore CPU is entirely different from programming for two CPU's. The first is basically just using two threads, while the latter also involves lower level managing of the CPU and it's not for the faint of heart.

DIV/Fenix/Bennu users are used to coroutines and not threads. Coroutines are mutual exclusive, meaning there's always at most one coroutine running at a given time, while this is not the case with threads. This means that you don't have to deal with mutual exclusiveness, semaphores, etc, because there is no possibility two coroutines can interfere with each other. However, threads can interfere. Programming a second CPU will involve all this stuff, which means there are to be changes in the Bennu renderer, which will happen, but currently the development focus is elsewhere. It will be done some time, though. :)
-- Sandman

SplinterGU

  • Hero Member
  • *****
  • Mensajes: 12902
  • Karma: 377
Re: [PORT] GP2X
« Respuesta #26 en: Marzo 22, 2009, 11:51:22 pm »
I don't said that are threads...
The both cpu have access to same memory address... but, in gp2x 1 cpu is used for graphics routines... and other cpu for program...
both share the same memory, when If you want use both cpu and share (without problems) the same memory address for program execution, you must use some mutex mechanism...

look this http://wiki.gp2x.org/wiki/Facts_about_the_ARM940T_processor

Download Lastest BennuGD Release: http://www.bennugd.org/node/2

osk

  • Hero Member
  • *****
  • Mensajes: 516
  • Karma: 52
Re: [PORT] GP2X
« Respuesta #27 en: Marzo 23, 2009, 12:07:11 am »
Maybe a great offtopic...have you seen this: http://openpandora.org/index.php ?

Sandman

  • Sr. Member
  • ****
  • Mensajes: 298
  • Karma: 48
Re: [PORT] GP2X
« Respuesta #28 en: Marzo 23, 2009, 12:10:16 am »
I sure did and I dare to say that I will see my very own Pandora within 2 months! Porting Bennu to it will be even easier than to the GP2X.
-- Sandman

Drumpi

  • Hero Member
  • *****
  • Mensajes: 6340
  • Karma: 162
  • Odio el periodo "entre proyectos"
    • La web de Drumpi
Re: [PORT] GP2X
« Respuesta #29 en: Marzo 23, 2009, 11:23:05 am »
Hehehe, ok ok, it's not the same multi-threading than Fenix/Bennu languaje, but you got the same problems if you program an IDE (make a windows-based interface gave me lots of headache, but i haven't read nothing about before :D)
I don't know about the deails, i think that is easier for programmers to use statics SDL, than compile, upload and tell to users how to install new libraries. Write in NAND memory is unusual, because it's short life and hard access without usb-net, terminal or cradle. People only change it's firmware only if it crash.

I don't said that are threads...
The both cpu have access to same memory address... but, in gp2x 1 cpu is used for graphics routines... and other cpu for program...
both share the same memory, when If you want use both cpu and share (without problems) the same memory address for program execution, you must use some mutex mechanism...

look this http://wiki.gp2x.org/wiki/Facts_about_the_ARM940T_processor

As i said before, people don't use second core for video. This wiki looks very "old". It looks like is writen by people reading only the CPU specifications. Again, i only knows what i read in gp32spain: "it's too hard to program the second CPU", "the second CPU looks like only can used to sound process in emulation"...
And i read also: in gp2x, the 64MB RAM are half divided for every CPU. You need a "special hack" to use all 64MB RAM with first CPU (use a pointer to read half ¿up? RAM memory). I can use only 8MB of RAM memory in my Fenix projects (i don't know why, if i load FPGs bigger than 8MB, it crash and show menu again).

I sure did and I dare to say that I will see my very own Pandora within 2 months! Porting Bennu to it will be even easier than to the GP2X.

That's a good news... but i envy you, i wanna pandora too!!! small, wifi, powerfull... expensive. Wiz is cheaper, but isn't as powerfull as pandora and will have got a smaller screen (better, but smaller). If only GP2x F300 will selled here (its a wiz with a gp2x skin).
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)