Openbor For Gp2x


jbrodack

gp2x fan
Joined
Dec 22, 2005
Messages
1,034
Age
40
Location
new jersey, USA
Website
jbrodack.googlepages.com
thanks for a least commenting on it. the link worked before I'm not sure whats happening now. I'll mention that the link isn't working to samuraix. I really want to get a recent build of openbor running on gp2x but samuraix who has worked on ports for numerous platforms and done updates to the engine unforntunately doesn't have a gp2x and all I've been able to do in testing is just say I get a black screen. Hopefully the link will be working again soon and we can get some gp2x users especially those with degugging tools to see whats going wrong with the gp2x port and we can get an actual current version of openbor working
 
rokdcasbah posted on Feb 18 2007 at 11:43 PM said:
sorry, i didn't get to that one in time it seems. it's also shut down. is it too large to email?

the more recent link is working now as of 1:07 eastern US time. the site might not always work keep trying to check the link. seems to go up and down. its not too large to email but right now im stuck using dial up so downloading and sending would take a while.
 
Last edited by a moderator:
i have uploaded it to another location for those which want to try. You can find it here
This is the last version of openbor openbor-v2.0055 with all the version (windows, linux, gp2x, psp...)

---------------------------------​
I have done some telnet test but i think there a problem in the code then i can't see the problem
Code:
[root@gp2x openbor]£exec ./OpenBOR.gpe
Fatal signal: Segmentation Fault <SDL Parachute Deployed>
 
Yod4z posted on Feb 21 2007 at 08:32 AM said:
i have uploaded it to another location for those which want to try. You can find it here
This is the last version of openbor openbor-v2.0055 with all the version (windows, linux, gp2x, psp...)

---------------------------------​
I have done some telnet test but i think there a problem in the code then i can't see the problem
Code:
[root@gp2x openbor]£exec ./OpenBOR.gpe
Fatal signal: Segmentation Fault <SDL Parachute Deployed>


I've realized that my enviroment Cygwin+OfficialLinuxSDK doesn't support SDL Hardware Video Mode! :eek: Once that was figured out... things started to progress much faster and now I have something for all of you GP2X users to tryout and enjoy and that is......

DevBuild-v2.0055-008 Included in this release is a working version of OpenBoR running on GP2X! :D However, there is one bug at the moment and that is with our engine running on this platform. So while you are not able to shut down properly.... you can enjoy OpenBoR to its full glory! You can grab it from my site here:

http://www.lavalit.com/forum/index.php?topic=26.new#new


Not bad for someone who doesn't own the platform..... but I would like to thank my testers:


Tails and jbrodack

Without them.... well why would i bother.....lol
 
Last edited by a moderator:
cool to see you posting here again samuraix. this version is newer than the last version I tested and graphics are much better and text much more readable. Some intro screens either have color messed up or show garbage though. also sound can't be controlled and the game seems to set the volume itself since using gmenu2x to set the volume before launching doesnt seem to have any effect. also there is the exiting bug. one version you sent me exited straight to the gp2x menu but i guess i didnt show credits that it was supposed to.

anyway thanks for all your work on bringing us gp2x user up to date with the other platforms.

also what are so of the more recently released mods that take advantage of newer openbor features. the full version of battletoads is one example and one that wouldnt work with lemon's port.
 
jbrodack posted on Mar 12 2007 at 12:06 AM said:
cool to see you posting here again samuraix. this version is newer than the last version I tested and graphics are much better and text much more readable. Some intro screens either have color messed up or show garbage though. also sound can't be controlled and the game seems to set the volume itself since using gmenu2x to set the volume before launching doesnt seem to have any effect. also there is the exiting bug. one version you sent me exited straight to the gp2x menu but i guess i didnt show credits that it was supposed to.

anyway thanks for all your work on bringing us gp2x user up to date with the other platforms.

also what are so of the more recently released mods that take advantage of newer openbor features. the full version of battletoads is one example and one that wouldnt work with lemon's port.



For the time being you can set the volume by going into the sound options menu and manually setting it there. As for the other issues I will look into them....
 
Last edited by a moderator:
I tried the full battletoads mod. good fun but some bad slowdown especially with the zombie stage. also slowdown with kill bill with a lot of sprites. more so than with lemon's port. seems some optimisation might be needed to speed things up.
 
great work but like Rivroner i can't find a archive of this last devbuild :(
 
jbrodack posted on Mar 12 2007 at 12:40 AM said:
I tried the full battletoads mod. good fun but some bad slowdown especially with the zombie stage. also slowdown with kill bill with a lot of sprites. more so than with lemon's port. seems some optimisation might be needed to speed things up.


The only differences in ports are.... lemon's used some toolchain that enabled hardware video acceleration and this one does not.

As for those slowdowns, the two mods reported at the two specific locations happen both on the Dreamcast and PSP. It has to do with enities not being killed from an engine's perspective. So that means for those 2 mods unless the GP2X is light years ahead of the Dreamcast and PSP in terms of CPU power which it is not. You will see those issues.

Its not a platform specific port issue its an Engine issue. Tooo many for loops gone wild!
 
Last edited by a moderator:
in general this port seems a bit more sluggish than lemon's port. there is minor slowdown that happens in other areas as well those were just the ones that really slowed things down.

the mmu hack seems to speed up most programs. might want to ask some gp2x devs how to implement that and if there are any other ways to speed up the port.

im not complaining or anything its great to have an up to date openbor playable on gp2x just letting you know that it seems to run a little more sluggish than it should.


Rivroner and Yod4z make sure you register for the forum. also the link for the latest build is on page 2 of the thread that samuraix linked too.
 
i think this port use classic SDL Gfx and not the hardware accelerated version. I think we can have a great upgrade if the GP2x version use SDG Gfx hardware accelerated with MMU, like 15fps more ;)
 
Well.... All in due time everything will be fixed and up to speed. New devbuild is also coming up! Version 8!


Fixes shutdown... palettes and a whole butt load of stuff! Tails did a great job of narrowing down the issue.... But it seems that the GP2X has issues with memory usage when at levels greater than 32 Mbytes!!!! So I applied all the techniques that the PSP uses for Memory Saving such as FileCaching, Sprite Flipping, and much more.......

So what do we have now..... A stable version of GP2X running that loads quicker than lemons port! Thank You Tails for you hard work and great investigation!



Goto my site http://www.lavalit.com/forum/index.php?topic=26.30 to download...... Will be up in a few minutes!
 
yes to have speed acces to the upper 32Mo of the GP2x you may use a special trick, Squidge MMU Hack
 
regarding the mmu hack I found this information in a thread about implementing it:

2. Apply the MMU Hack once at the beginning of the program (after all mmap() and before any malloc() or memset()). It should work

also here is advice from the gp2x wiki upper 32mb of memory

I also attached the mmu hack file used in the mame port.
 
OpenBOR is one of the hardest things to port due to how ugly the source is/was.
I'm suprised it hasn't been vastly cleaned up by the original authors.
Congrats on this port and hope to see it mature. :)

Oh about the MMU module. Once you have the mmuhack.o in the same directory as your gpe file just do something like:
{
int mmufd = open("/dev/mmuhack", O_RDWR);

if(mmufd < 0)
{
system("/sbin/insmod mmuhack.o");
mmufd = open("/dev/mmuhack", O_RDWR);
}
if(mmufd < 0)
{
// Show error. The module couldn't be loaded.
}
else
{
close(mmufd);
}
}

That should be used after mmap's to the upper 32mb of memory. So if you're using HW SDL (I suggest you use HW SDL from paeyrn), do something similar to this:

SDL_Init(...);
SDL_GP2X_AllowGfxMemory(NULL, 0);
sdl_screen = SDL_SetVideoMode(..., SDL_HWSURFACE);
[call the mmu module loading procedure here]

Basically call the module whenver you mmap the upper 32mb, and by calling AllowGfxMemory this uses the upper 32mb for hardware surfaces.

Hope this helps.
 
Back
Top