Jump to content
  • Advertisement
  • entries
    437
  • comments
    1000
  • views
    336830

GP2X Pt2

Sign in to follow this  
evolutional

104 views

On the thrid day, the GP2X said to me:-

"GIVE ME BATTERIES OR I SHALL DIE"

The battery life on the unit SUCKS. I have been reading various forums and have seen that you need some beastly 2500mA rechargable batteries, the generic alkaline batteries that you get with it aren't worth a shit in a GP2X. So a trip to argos and GBP12.99 later, the NiMH 2500mA batteries need charging. I will do that when I get home tonight.

If you're getting a GP2X soon, buy a DC adapter. It needs a 3V source with a tiny (Sony-style) jack head.

My initial ravings about the unit have subsided somewhat, mainly because of this battery crap I'm having with it - I can't get it to boot under battery power right now. DC it's fine, but batteries is a no-no. Kinda shitty for a portable unit, eh? Let's hope the NiMH beasts work...

And now for some good news about my GP2X experiences...

I got GameMonkey Script to compile on the devkit. Afterwards, I hacked the SDL demo app that comes with the devkit and threw in some scripting to move a sprite around screen. A quick compile later and it worked nicely on the GP2X - brilliant. This news is fantastic as it means I'll be able to port my new project over to the GP2X with little or no trouble; it'll also mean that games people make for the GMGX engine will work on Windows, Linux and the GP2X with no problems. This is very, very cool.

This weekend I'm going to focus on porting over PhysicsFS to the GP2X. I'd like to make it a shared library, but don't know how to do that on the 2X right now, so a static lib will be fine. If this compiles, it'll mean seamless zip-file loading support on the GP2X and again, will mean I will have to do little work on GMGX to make it compatible.

The main brunt of the work now is to rip out all my OpenGL calls and port the graphics engine over to use SDL. Again, this will be simple as I was smerty enough to keep everything platform and API specific tucked away in their own files with a nice interface over the top. Once SDL is thrown in, I'll drop OpenGL support as I probably won't need it anymore - GMGX is 2D only...
Sign in to follow this  


7 Comments


Recommended Comments

ah, one of my ideas for when I get mine was to see if someone had Lua working and if not port/compile that [grin]

My 2nd plan was see if I could port GTL over to it, this ofcourse means that I'll need boost to compile for it, HOWEVER the devkit seems to have pretty good C++ support, so I dont suspect this will be a huge problem, it'll be something I run into next week I guess [grin]

The battery life thing sucks a bit... I'm going to town in a bit so I'll pick up a couple of beasty batteries then, if I put 'em on charge now chances are they will be done by next friday [wink]

Share this comment


Link to comment
I have to use 2100ma (although I use 2600's) for my DigiCam.. I once tried to use regular AA's and it was a joke - I'd easily say that my 2600's last 10x as long as the generic AA's. You should be fine with your new batteries!

Quote:
games people make for the GMGX engine will work on Windows, Linux and the GP2X with no problems. This is very, very cool.

I'll 2ND the coolness of that. That has to be the quickest and (seemingly) most trouble-free X-Platform porting that I've heard of. Either you write some seriously good code, or you've got some pretty awesome tools there [grin]

Jack

Share this comment


Link to comment
Quote:
Either you write some seriously good code
++

Nah, I just try and be as portable as I can. Anything that's tied to a platform or API is hidden under an interface... Porting is mainly a case of rewriting those new bits, plus using platform independent libs anyway (GMScript, PhysFS, SDL) means you have to do nothing of note to get the suckers ported :)

Share this comment


Link to comment
hehe,

I've tried to abstract every piece of cross-platform specific code in the F1CM engine. However, I keep reading about stupid differences in compilers and STL implementations - such that "pure" C/C++ isn't really portable.

I'll work it out if I get there.

Jack

Share this comment


Link to comment
I try to make code as portable as I possibly can, as a rule of thumb. Usually all I have to do to port between Linux, OS X and Windows is change a few lines of header directives the first time I build, and then set up an #ifdef for successive builds. Easy!

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!