GP2X Playing Catch-up

[Epicenter]

Hello! You might have seen me here before the GP2x was released, around October. My intentions were, and still are, to program and release a GP2x version of a first-person shooter based on the Quake engine already under deveopment for PC/Mac (Armor of Acheron 2), and a top-scrolling arcade-style shooter presently codenamed "Project Luminence". The latter is an SDL application under development at present.

Now, I've been away for about 2 and a half months due to being in basic training in the Air Force. Now that I'm finally done and have time to dedicate to development, I am very much out of the loop on how the GP2x release went, the tools that have been made available by community members (it would appear GPH has released basically just a copy of the SDL libs and a compiler as the SDK), so on and so forth.

What I am basically wondering is, what is the present situation when it comes to the system's compatibility-- do SDL applications configured for the GP2x (e.g. resolution set to 320x240px, using the proper input buttons in the event loop, etc.) generally compile and run cleanly and properly on the GP2x? How is speed, particularly with blitting? Is it terribly slow necessitating the use of hardware blitting in a separate library written by a forum member (it seems there is one or two now?) or does hardware blitting take place on its own (seemingly very unlikely)? How much RAM is available to applications with the Linux OS running? How is battery life under gameplay conditions? What custom libraries exist, so far, to take advantage of the ARM940T coprocessor? What is the truth behind hardware audio decoding-- most particularly, are there provisions in place to do OGG Vorbis audio decoding on the 2nd processor to remove burden from the ARM920T? What is the situation with the firmware updates and what major issues exist?

I realize this is a hefty list, but I'd greatly appreciate if someone wouldn't mind catching me up-- I barely have enough time for development, much less to read hundreds of pages of forum threads and try to make sense of all the community projects in the works. Thanks for any sort of assistance. I look forward to showing you all some great things soon and giving you all some very fun things to play-- and I think you will be very much impressed with the kind of limits we'll be pushing the Gp2x to once we know just what it's capable of!

 

[Radek]

Hello! You might have seen me here before the GP2x was released, around October. My intentions were, and still are, to program and release a GP2x version of a first-person shooter based on the Quake engine already under deveopment for PC/Mac (Armor of Acheron 2), and a top-scrolling arcade-style shooter presently codenamed "Project Luminence". The latter is an SDL application under development at present.

Now, I've been away for about 2 and a half months due to being in basic training in the Air Force. Now that I'm finally done and have time to dedicate to development, I am very much out of the loop on how the GP2x release went, the tools that have been made available by community members (it would appear GPH has released basically just a copy of the SDL libs and a compiler as the SDK), so on and so forth.

What I am basically wondering is, what is the present situation when it comes to the system's compatibility-- do SDL applications configured for the GP2x (e.g. resolution set to 320x240px, using the proper input buttons in the event loop, etc.) generally compile and run cleanly and properly on the GP2x? How is speed, particularly with blitting? Is it terribly slow necessitating the use of hardware blitting

The hardware blitter of gp2x is quite powerfull. However when it will be supported in the official GPH's firmware is an unknow.

in a separate library written by a forum member (it seems there is one or two now?) or does hardware blitting take place on its own (seemingly very unlikely)?

It's GPH's task to add support for the blitter. The 3rd party libraries are already supporting it to a degree.

How much RAM is available to applications with the Linux OS running? How is battery life under gameplay conditions? What custom libraries exist, so far, to take

At 200Mhz for me it's around 3 hours. When using higher clockrate (266MHz) it is vastly reduced (all GP2100 batteries).

advantage of the ARM940T coprocessor? What is the truth behind hardware audio decoding-- most particularly, are there provisions in place to do OGG Vorbis audio decoding on the 2nd processor to remove burden from the ARM920T? What is the situation with the firmware updates and what major issues exist?

The second core (the 940T) is fully functional Arm cpu. It hasn't a MMU so using it under Linux is somewhat complicated (but there are workarounds).

I realize this is a hefty list, but I'd greatly appreciate if someone wouldn't mind catching me up-- I barely have enough time for development, much less to read hundreds of pages of forum threads and try to make sense of all the community projects in the works. Thanks for any sort of assistance. I look forward to showing you all some great things soon and giving you all some very fun things to play-- and I think you will be very much impressed with the kind of limits we'll be pushing the Gp2x to once we know just what it's capable of!

​

So far... there is fast enough port of Quake1 and excellent (and fast!) port of DukeNukem3D. Both are using just one cpu so it's promising that when utilizing the gp2x's hardware to a greater extent much better results could be achieved. There is also workable PSX1 emulator already. It's too slow overall but it's better than expected and again it isn't using all possibilites what gp2x is offering.

There is VideoPostProcessor and people are getting first results from it too (hardware scaler and scrolling, possibly hardware translucency and alphablending).

So things are looking optimistic...

But there problems too... (the stick's issues and the lcd's interlacing)

Overall it's going in the right direction.

 

[Epicenter]

When you refer to hardware scaling, alpha-blending, etc. you are referring to the entire screen image before it's drawn to the screen, not usable functionality within applications e.g. rotation of graphics or hardware translucency, right? As for the ARM940T, I suspect we'll have to spoon-feed it data from the 920T and give it work that doesn't require it touch RAM when the 920T is using it-- Sega Saturn style. A pain in the ass and probably only useful for long, drawn out operations the 920T doesn't need any involvement in. It would be nice if there were some sort of lower-level library that could be used to utilize this CPU without going into shoving executable code at specific addresses, which is no fun to be messing with when you're trying to focus on an OOP SDL environment.

Sorry to hear about the lack of access to the blitter. I suppose I'll have to live with software blitting for now, but I do hope utilizing it later does not require massive rewriting of anything I've done in standard software blitting in SDL..

As for the battery life .. 3 hours? That's all? What sort of batteries are these, Alkaline AA? NiMH AA? I'd probably use the machine with the latter, or on long trips maybe high-capacity Lithium AAs.

 

[Tobriand]

2100s don't last a great deal of time... you really *need* 2500 or more mAh batteries - but once you've got them, you'll have 4-5 hours of life.

Personally, most of my batteries are 2000 or 2100 (with a couple of 2300s and a couple of 2500s) and barring the 2500s, most last for 3-4 hours - which means one spare set'll more than get you through the day.

 

[Radek]

When you refer to hardware scaling, alpha-blending, etc. you are referring to the entire screen image before it's drawn to the screen, not usable functionality within applications e.g. rotation of graphics or hardware translucency, right? As for the

These are realtime effects done at screen's scaning. So yes - they are not like "true" alphablending yet it's a functionality to get advantage of.

ARM940T, I suspect we'll have to spoon-feed it data from the 920T and give it work that doesn't require it touch RAM when the 920T is using it-- Sega Saturn style. A pain in the ass and probably only useful for long, drawn out operations the 920T

No, no exactly that. The 940T is fully indepedent yet it has to share the same bus to the memory (this isn't uncommon - the PC's multicores aren't that different). The problem is that first core is visible by Linux however the second isn't as it's lacking a MMU. Some tricks are needed but it's not that hard like in the Saturn.

doesn't need any involvement in. It would be nice if there were some sort of lower-level library that could be used to utilize this CPU without going into shoving executable code at specific addresses, which is no fun to be messing with when you're trying to focus on an OOP SDL environment.

Well... the video playing functions are already using second core in the GPH's firmware. I'd conclude then using it is possible for any task.

Sorry to hear about the lack of access to the blitter. I suppose I'll have to live with software blitting for now, but I do hope utilizing it later does not require massive rewriting of anything I've done in standard software blitting in SDL..

No, no. NO! Use SDL as usual then when it will get support of blitter just expect increase in the perfomance.

As for the battery life .. 3 hours? That's all? What sort of batteries are these, Alkaline AA? NiMH AA? I'd probably use the machine with the latter, or on long trips maybe high-capacity Lithium AAs.

​

NiMH. Plain NiMH.

 

[Epicenter]

No, no. NO! Use SDL as usual then when it will get support of blitter just expect increase in the perfomance.

This has been my intention from the start. I mean, I hope that adding hardware blitting acceleration is as simple as dropping in an altered header file to my existing SDL installation and recompiling the application rather than say, rewriting my sprite-drawing functions to take advantage of it.

 

[Radek]

No, no. NO! Use SDL as usual then when it will get support of blitter just expect increase in the perfomance.

This has been my intention from the start. I mean, I hope that adding hardware blitting acceleration is as simple as dropping in an altered header file to my existing SDL installation and recompiling the application rather than say, rewriting my sprite-drawing functions to take advantage of it.

​

NO!

Once the hardware blitter will be supported via SDL (or whatever) your binaries will benefits from it automatically. Just add flag for hardware surfaces if you didn't yet.

 

[paeryn]

I've nearly got my new version of SDL working with blitter support. Whilst going through it I think my original code would let you blit a software surface onto a hardware using the blitter - needless to say the blitter would've been trying to read from >64MB. I made assumptions that it wouldn't try accelerating a blit from sw. The new code should also support 1bpp blits, and a (slowish but faster than sw only) blit from an 8-bit surface to a 16-bit.
I've got the scaler working (coarse only) so if you ask for a 640x480 screen you'll get one, and the display will be shrunk to fit on the LCD automagically. Max screen size will be 1024x768.
Alll being well I should have it ready for testing this afternoon.
I'll add TV support as soon as I can get a decent TV cable - in theory I know how to do it, but without being able to test it...

 

[timbobsteve]

When you say 'hardware scallar', is that just for the screen, or can I use that like rotozoom to resize surfaces?

 

[paeryn]

Just the screen. It's part of the display controller, not the blitter.
What I'm planning on is having a function that takes an SDL_Rect which will define the area of the screen that gets scaled to fit onto the whole LCD.
e.g. if you create the screen as 640x480, calling a function such as SDL_GP2X_Display(SDL_Rect *area); with
area={160,120,320,240} would show the centre of the screen with scale 1:1,
area={0,0,640,480} would show the whole screen, but only every other pixel visible,
area={480,360,160,120} would zoom in 2x on the bottom right-hand corner.
Unfortunately the scaler doesn't do any filtering so in the full-screen example only the top-left of every 2x2 pixel block will show.

 

[Hanz™]

How soon until you think you will be ready to release this updated SDL, code etc...?

 

[paeryn]

I released it last night. It's not had much testing yet though. Follow the "Hw Accelerated SDL" thread for up-to-date info Link to SDL thread