Here are GP2X binaries of Bennu. Currently it's of revision 22 of the SVN, but I will update it soon.
Download here (http://deathegg.student.utwente.nl/files/gp2x-bgd-r22.zip).
gp2x-bgd-r30 (http://deathegg.student.utwente.nl/files/gp2x-bgd-r30.zip).
thanks! cool! karma up!
Yeahp thanks :)
Wonderful!
Thanks a lot!
Seeking an r22 version of Bennu.
Waiting for r24 version of port.
Destroying lots of clocks (time, i hate you).
:D
r30....
Well, here it is (http://deathegg.student.utwente.nl/files/bgd-r30-gp2x.zip), r30.
thanks...
RAAARGH, I need the same binaries. You two are driven me crazyyyyyyyyyy :D :D :D :D
Ha well, I don't know why you need that, but here it is: bgd-r28-gp2x.zip (http://deathegg.student.utwente.nl/files/bgd-r28-gp2x.zip). I added moddesc to both r28 and r30. bgd-r30-gp2x.zip (http://deathegg.student.utwente.nl/files/bgd-r30-gp2x.zip) is still available.
No, sorry, i got both versions of gp2x-bennu, but none of win-bennu :P
But if there is a bgdc for GP2x, forget about it. Just need r30 to compile in PC (better than compile in gp2x, because conect the cradle with his power suply and usb keyboard is a little tedious)
You can compile your DCB on Windows and use this same DCB on the GP2X. The DCB format hasn't changed since... well some early revision (we are now at DCB version 7) and a new Bennu version does not mean you have to recompile your DCB for it to work. Only if the DCB changes, you have to recompile (the goal is that this will not be needed for quite some time to come).
So you can compile your program with Windows binaries r28 (http://betatester.bennugd.org/betas/bgd-r28-win32.zip) or r30 and run with GP2X binaries r30 (http://deathegg.student.utwente.nl/files/bgd-r30-gp2x.zip).
Cool, i get the r28 a few days, so i'll try.
My worries are because in fenix dcbs aren't compatible between versions. I must been thinking about this: so much bennu versions can't support so many incompatible versions.
I can't wait to try bennu in GP2X.
What could port first? FenixLand? Drumpi TiledEngine v3? "it"? :baboso:
AAAAARRRGGG: 30 minutes writing in english at 2:30 AM and i lost all the text because the time-out login.
Sorry, but i canot write this again, i'm VERY tired, so i'll post in spanish.
Hola a todos:
Finalmente he poodido hacer una pequeña prueba con "Bennu2x", usando mi motor de scroll tileado v 3.0 (Drumpi tiled scroll v 3.0 engine). No es nada serio, dado que tuve que compilar con una version de bennu r28-win y usar el DCB en la r30-gp2x.
Lo primero que me sorprendió fue ¡EL MOTOR FUNCIONÓ A LA PRIMERA! Fue un momento happy... hasta que me di cuenta de que yo no soy daltónico: los colores estaban totalmente cambiados. Supongo que esto se debió a los cambios con las paletas en modo 16 bits hechos recientemente por Splinter, al igual el hecho de que no se viese la segunda capa (el segundo plano de scroll)
Respecto al rendimiento... bueno, eso es un mundo aparte. Debo decir que tve que compararlo con un "fork" que hice de mi motor, la v 3.2, porque la versión original fallaba (algo relacionado con la función "alloc", por eso, en este caso, la carga del mapa tileado, se hizo usando un FPG, ojo, no es lo mismo mapa tileado que tiles o scroll tileado (tilemap, tiles, tiled scroll)).
Bien, rendimiento: UFenix (fenix092a port for gp2x) me dió un máximo de 150 fps cuando había menos carga de procesos (less process working) frente a unos 164 fps de Bennu2x. Lo raro vino con la carga máxima (worst case)... UFenix daba 54 fps constantes, bennu, con la cámara fija (no movement) 58 fps (con máximos de 64), pero si movía la cámara caía a 38 fps
Aparte de eso, me ha encantado las librerías para gp2x, harware playing! (Qué bien me habría ido para apagar la pantalla mientras se tocaba la flauta en FrikiMusic). The only thing i miss was a tv-out function (jump to tv, now fall to gp2x...).
En fin, cuando tenga unos binarios de la r30-win haré un testeo más serio, subiré código fuente y pondré fotos... aunque en realidad, el código que he usado (version Fenix) se puede descargar de aqui (http://www.fenixworld.com/e107_plugins//depot/files/fw75.optimizado_tscroll.zip)
En fin, un saludo... y perdón por no traducir. Good night.
PD: one last question. You didn't use hardware accelerated libraries, don't you? like mmuhack and other like this. They says that you can get some additional fps... and if you can use the second corefor sound or else... (homer thinking on donuts x3). By the way, i make a call for any experienced programmer to help... but always people ignored me, so... ^^U
No me quedo claro si tu prueba fue satisfactoria o no...
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...)... asi que bueno, la caida de rendimiento es eso.
Con respecto a los colores, no se si usas todo en 16 bits... pero segun me dijo Sandman, o lo que le entendi, la version gp2x no tiene aun 8bits...
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.
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...
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?
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...
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...
Quote from: Drumpi on March 22, 2009, 03:45:00 AM
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.
Quote from: SplinterGU on March 21, 2009, 02:43:53 AM
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....
solo gp2x...
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.
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.
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. :)
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
Maybe a great offtopic...have you seen this: http://openpandora.org/index.php ?
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.
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.
Quote from: SplinterGU on March 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
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).
Quote from: Sandman on March 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.
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).
Look at this (http://en.wikipedia.org/wiki/GP2X#Specifications):
"The ARM940T was used by GPH's implementation of Linux to control video processing. Using the 940T core in Linux for other tasks apart from video processing is difficult but possible. Accessing the hardware directly makes it easier to use both CPUs."
Wikipedia is never wrong. ;D Also, in the Magic Eyes documentation (http://www.mesdigital.com/support/downfile/mp2520f%20data%20sheet.pdf) it is said: "Coprocessor used for Video Header Parsing, Video Post Processor Control: ARM 940T CPU (200MHz, >220MIPS), 4KB I-Cache + 4KB D-Cache".
Updating the binaries can be done by a very simple program, much like the "patch" that is done after a firmware update. You just run it, the program updates the libraries and you're done: EVERY game has hardware accelerated stuff. For your own game, you can also just include the shared object with your application, in its folder. It will use it instead of the one in /lib. However there is a downside. There is no FPU in the GP2X, but the official firmware is compiled using hardware floats. This means that it gets emulated at runtime. The alternative is to compile using software floats, which is faster if there is no FPU available. Using static linking, you can use software floats.
The upper 32MB is indeed not 'visible' to Linux. It is non-cached and slow in access, but there is an MMU hack made by Squidge. See here (http://wiki.gp2x.org/wiki/Using_the_upper_32MB_of_memory) and for the MMU hack under "Speed issue".
I don't said that the people use the 2nd CPU for video... I think that gp2x use it... not people... gp2x... the people can will use 2nd cpu for they wish...
The specs (and soft samples) don't say this that you say... divide memory CPU is only software (SO) definition... not hardware restriction... both CPU can access to whole memory...
Quote from: Sandman on March 23, 2009, 12:05:06 PM
Look at this (http://en.wikipedia.org/wiki/GP2X#Specifications):
"The ARM940T was used by GPH's implementation of Linux to control video processing. Using the 940T core in Linux for other tasks apart from video processing is difficult but possible. Accessing the hardware directly makes it easier to use both CPUs."
Wikipedia is never wrong. ;D Also, in the Magic Eyes documentation (http://www.mesdigital.com/support/downfile/mp2520f%20data%20sheet.pdf) it is said: "Coprocessor used for Video Header Parsing, Video Post Processor Control: ARM 940T CPU (200MHz, >220MIPS), 4KB I-Cache + 4KB D-Cache".
Updating the binaries can be done by a very simple program, much like the "patch" that is done after a firmware update. You just run it, the program updates the libraries and you're done: EVERY game has hardware accelerated stuff. For your own game, you can also just include the shared object with your application, in its folder. It will use it instead of the one in /lib. However there is a downside. There is no FPU in the GP2X, but the official firmware is compiled using hardware floats. This means that it gets emulated at runtime. The alternative is to compile using software floats, which is faster if there is no FPU available. Using static linking, you can use software floats.
The upper 32MB is indeed not 'visible' to Linux. It is non-cached and slow in access, but there is an MMU hack made by Squidge. See here (http://wiki.gp2x.org/wiki/Using_the_upper_32MB_of_memory) and for the MMU hack under "Speed issue".
indeed... thanks... ;)
drumpi: well, how you can see... here are (somebody without have a gp2x) GOOD programmers... ;)
I see :D :D :D
I tried to search post about second core in gp32spain, but is very hard to find (looks like there are a lot of massive posters :P). Just for reference, look at this: http://wiki.gp32spain.com/index.php/Estado_de_la_emulaci%C3%B3n#Sega_Mega_drive (sorry, only spanish)
QuoteAdelantó en rendimiento y prestaciones a DrMDx gracias al uso del segundo procesador para el sonido con una calidad de 44Khz
But this is not the question. The question is if it's easy or not to use the second core, for graphics, sound, 3d or else (and how, if you got time to teach a total noob ;D ;D ;D ;D). Scene is scene, people who know programming, but his level... for me are pro, but a monkey with a "hello world" glowing, rotating an jumping in C is a pro for me :P
Meanwhile, i will try to take here some experienced people with gp2x HW.
I hope i'm not bothering you two whit my noob things... and worst english :)
in the url that I tell you, you can found some papers and projects that can help you...
for simplify your task, you can use this...
http://www.symbolengine.com/rlyeh/files/internal_use/readme-c.html
I'll search others utils tools for you...
well, here you have a good post with all stuffs of this...
http://www.gp32x.com/board/index.php?showtopic=27433&st=90#
from startup 2nd CPU, to "LOCKING" mechanism and shared IPC area between CPUs.
good post!
you must read all post from here... some others posts can be useful...
EDIT: ogg940 is good sample too, and have sources.
Ok, thanks, i'll take a look... when i have time: between FNTEdit, crap-compo4, "V days" and other university projects i'm TOO busy ;)
Congratulations Sandman, it's a great port. karma++
Well, I think we may have to check the source (http://www.gp32wip.com/files/projects/gp2x/ufenix_v02_src.zip) of the Fenix port (http://www.gp32wip.com/files/projects/gp2x/ufenix_v02.zip) and what optimizations have been done there because these results speak for themselves:
Bennu:
Time: 10000ms
Frames: 325
FPS: 32
Fenix:
Time: 10000ms
Frames: 588
FPS: 58
To show you that the problem really is that Bennu doesn't use the hardware, I also ran the test with MODE_HARDWARE enabled. This means the final blit from Bennu's screen to the real screen is in fact accelerated. Results:
Time: 10000ms
Frames: 344
FPS: 34
Slight speedup there.
So this means there is a lot left to optimize. This is not a problem at this stage though, because the rendering modules are planned to be rewritten anyway, which will allow these kind of optimizations to be implemented more easily. It's an interesting task, but I don't have all the time in the world, so we'll see what comes of it. :)
And you're all anxious to see the test code, I know, so:
#ifdef COMPILER_VERSION
import "mod_grproc"
import "mod_video"
import "mod_key"
// import "mod_gp2x"
import "mod_map"
import "mod_rand"
import "mod_proc"
import "mod_say"
import "mod_time"
#endif
#define PROCS 100
#define DEPTH 16
#define RUNTIME 10000
Process Main()
Private
int i;
int g;
int t;
int e;
int f;
Begin
set_mode(320,240,16);
set_fps(0,0);
g = new_map(20,20,DEPTH);
map_clear(0,g,rgb(100,150,200));
for(i=0; i<100; i++)
box(rand(15,305),rand(15,225),0,g);
end
t = get_timer();
e = get_timer()+RUNTIME;
f = 0;
repeat
f++;
frame;
until(get_timer()>e)//key(_esc)||gp2x_getbutton(_GP2X_L))
say("Time: " + (e-t) + "ms");
say("Frames: " + f);
say("FPS: " + f*1000/(e-t));
OnExit
let_me_alone();
End
Process box(int x, int y, int dangle, int graph)
Begin
loop
angle+=dangle;
x=rand(15,305);
y=rand(15,225);
frame;
end
End
please, can you do test without render?
well, this sample don't have nothing important to test....
Well I certainly wouldn't call blitting unimportant, especially if optimized it can be almost twice as fast. I made a new test, which does... nothing. So let's see.
The test
#ifdef COMPILER_VERSION
import "mod_time"
import "mod_video" // enable/disable mod_video
import "mod_say"
import "mod_proc"
#endif
#define RUNTIME 10000
Process Main()
Private
int t;
int e;
int f;
Begin
restore_type = complete_restore; // enable/disable complete_restore
set_mode(320,240,16,MODE_HARDWARE); // enable/disable mode_hardware
set_fps(0,0);
t = get_timer();
e = get_timer()+RUNTIME;
f = 0;
repeat
f++;
frame;
until(get_timer()>e)//key(_esc)||gp2x_getbutton(_GP2X_L))
say("Time: " + (e-t) + "ms");
say("Frames: " + f);
say("FPS: " + f*1000/(e-t));
End
Results
Bennu:
Time: 10000ms
Frames: 1154853
FPS: 115485
Bennu +mod_video:
Time: 10000ms
Frames: 250053
FPS: 25005
Fenix:
Time: 10000ms
Frames: 2047
FPS: 204
Bennu +mod_video +complete_restore:
Time: 10000ms
Frames: 1538
FPS: 153
Fenix +complete_restore:
Time: 10000ms
Frames: 886
FPS: 88
Bennu +mod_video +complete_restore +mode_hardware:
Time: 10000ms
Frames: 5044
FPS: 504
Fenix +complete_restore +mode_hardware:
Time: 10000ms
Frames: 5243
FPS: 524
So Bennu beats Fenix until the hardware is kicked in. Bennu's VM is certainly a lot faster than Fenix'. I don't know about the performance of other modules, like mod_sound; they could differ as well. Float operations should be slower in Bennu too, because it's compiled using hardware floats (and there is no FPU, so it gets emulated at runtime) and Fenix with software floats. If it's useful I can test it.
I mean, don't have nothing important to test if we cutoff blitting...
begin
frame
end
not really good sample...
but, the core is more faster... indeed...
Just if you want to know, the Puck's web page is http://www.gp32wip.com/, in "proyectos" section have the lastest source code (i think it's the same as you get) and more from him. be carefull not to mistake between Fenix and UFenix :D
If you can get a HW acceleration, i think Bennu will get lots of programmers there... and a easy WIZ port (people are porting gp2x libraries to WIZ)
@SplinterGU:
Ah, I see. :)
@Drumpi:
Aye, I'm using uFenix v0.2, the one I linked earlier. Is there another Fenix GP2X port then?
We'll get HW acceleration eventually, but it would help a lot more if someone with experience with the GP2X would help. One of the problems is that all those guys use static linking and so there are no dynamic version of the libraries we want.
No, i said that you get the lastest (i didn't know what version you had).
And maybe you only can get static libraries, sceners preferr static linking.
You can ask in gp32x forum, maybe you'll have more luck than me in gp32spain.
People ignore me, i'm like a ghost :( I will be a ninja.
Haha well I tried asking on gp32x.com and on the IRC channel, but they're not very interested (didn't get an answer). But it doesn't matter, because the current Bennu renderer uses its own routines and not SDL, so the renderer needs to be optimized for the GP2X anyway. We can learn how uFenix did this and then see what we need.
Looks like efegea, in gp32spain, is interested to do some bennu modules. I told him to ask to you, Sandman, maybe can help you (if he don't ignore me ;D)
Pray pray ¡play!
Wonderful wonderful!
This is a landmark of development for sure.
I've been looking forward to this moment, because I am going to develop games for the "Pandora", that is, if we are to see a finished console sometime this year!
If anyone is interested go to http://openpandora.org where you can pre-order a machine, but i warn that they are being incredibly slow with making, testing and shipping the consoles!
Now, we got the WIZ version of Bennu, and it's an official port.
Sandman ¿are you tried to "port" this new version?
Recently i downloaded the new official SDK for linux, but i don't know how to use: there are lots of directories, and more executable files and... :S
Sandman ¿Are you here?
Yes! I'm here. :)
I can compile a new version, but I can't test it, because I don't have a power adapter at the moment. Will get one soon. In the meantime, perhaps you can do the testing, if you like. I'm also waiting for the alignment fix to be included, very important...!
Ok, i can help you now ;)
And perhaps can do it for you. I think you readed some other post recently (like the english-only forum one). Now i've got cygwin and toolchains in windows (i don't know if well or not ^^U) and tryin by myself with no results (sorry, but my skills are very low... lower than my spanish->english experience).
Splinter said me to ask to you how do you compile Bennu to try by myself, so here i am.
I hope i could help you with this, a Bennu port for GP2X can boost some of my projects, like FenixLand, a FZero-like (with some strange changes) or another one (i can't tell nothing now), so i'm motivated (and got an exam nearly, so motivation++ ;D).
Thank to your time ;)
PD: About this alignment fix... ¿Splinter don't tell you nothing about...? (don't know if it's a real secret or he's joking ^^U)