Designing The Gp2x's Successor - Hardware Selection Poll

[Epicenter]

playstation killed (s)nes

The 8-bit generation and NES' lifespan came to a close about 4 years before the Playstation was released. The SNES was coming to the end of ITS lifespan before the PSX came out, too. If the PSX competed with anything, it was the N64 and Saturn, not the SNES or NES.

xbox(360) killing playstation(2/3)

Again, the 360 is a new generation of console, and the PS2 is well .. very old. It's 5 years old. The 360 is about ONE year old. As for the PS3, it isn't out, how has it been 'killed'? All current information shows the PS3 is roughly graphically on par with the 360, perhaps slightly more advanced in that regard, but is at a CPU disadvantage in most tasks. Neither one really 'kills' the other, except perhaps in price.

gp(3x with turbo-hardware) would kill m$

Microsoft hasn't announced or released any portable hardware, so I don't even know how you can draw a comparison against .. nothing.

for example... games like www.planeshift.it.. need cpu power + 3d

This is the REALLY confusing argument. You prefer Option 2, which has a faster CPU but NO 3D acceleration at all. A 400 MHz ARM9 processor is only capable of simple, slow 3D and supports none of the special rendering technologies and features a proper GPU like the MBX RS does. 3D performance would be roughly 5% or less of a dedicated GPU, and there would be no CPU time left for much game processing, so no complex game logic...

At any rate, I had a look at this Planeshift game you linked to. The creators recommend *512 MB OF RAM* for decent performance, and that a GeForce 2 video card would provide 'good' performance. That's overshooting the GPU available in S3C2460 or VRENDER-3D, though it might run fine with reduced graphical quality at 320x240 acceptably. More worrying is that they also recommend a 600 MHz Pentium 3. Maybe this game could run half-decently with the S3C2460's CPU, a bit of overclocking, the FPU/Vector processor, and the GPU working in tandem but I honestly doubt it'd run well.

Also please define 'turbo hardware'.

 

[b._.o._.b]

Nice thread

I voted 1, but I don't really care that much about the hardware. Wifi would be nice, but it doesn't have to be build in.
I like the GP2X because there are a lot of emulators available and the community is very active.
Guess it's not up to users like me, but up to the developers here to decide how the successor of the GP2X should be like. If they don't buy it, it will be a dead system soon.
Maybe the best thing to do is to make a system that is compatible with the GP2X and has some extra features (and faster).

 

[Epicenter]

Well if it runs Linux, has a 320x240 display and an ARM-architecture processor it'll run GP2X software, maybe without even recompiling it. Should be the same case for the XGP series, except you'd want to make some changes for a 480x272 display if the XGP uses one. But even then you don't HAVE to, the screen just won't be completely filled.

 

[Cruel]

Not strong in english, sorry.

1. 8-way Digital Pad is absolutely necessary. No analog sticks, please, they are very uncomfortable for arcade games (although, it was nice to rotate camera in Prince of Persia SOT and Tomb Raider Legend). I think, D-Pad is the most important thing in console - it should be perfect. Just like Sega genesis D-pad is. IMHO Genesis joystick even better, than NES.

2. Center button shoudn`t be on Joystick. It can find another place.

3. As for mouse, GPH could integrate some kind of pointing stick. I had an old notebook with this thing, and it was cool, needed little time to get used to. It`s small, should fit above or below Joypad.

4. Well, i want run SNES without overclocking, so next GP?X must be a little faster, and battery life longer. Yeah, that impossible together, i know, but hope will never dies

5. Have no use in WiFi, but many people wanted it, so it can be as external USB-device, no integrated, no eating batterys.

6. No Touchscreen, please no! It makes more chances to scratch the screen, or break handheld at all. If you need mouse, there could be pointing stick. I need console with arghh... what the word... hight reliability. Yes, bulletprof and water resist...

7. More buttons need fo future use. Who knows, maybe some day, we will be able to run Starcraft on it.

 

[Wez]

Well, from looking at what the GP2x already has, the only 'must' would be to add propper 3D acceleration, ooOOo and some built-in network ability to connect these handhelds together? WiFi would be cool but I agree maybe add it as an external dongle or something, it'd really suck to be playing something multiplayer and you or your mate dies :\
!! how about a USB port where you could connect a USB pen to? Sure SD's are more discrete but you cant just go anywhere and plug in a SD card if you want to upload/download an mp3 or picture... Pendrives are far more common as most computers nowadays have a USB port.
The 3rd GP HAS to be GP2x compat. -.- We develop & use software, and soon enough its updated & we only usually have to download a patch, like firmware... we shouldnt have to re-develop & port stuff again and we'd have to re-go thru patching up bugs...
but er... dont start doing anything about a 3rd yet give it a few years so i can gather enough money XD

 

[MWeston]

Well if it runs Linux, has a 320x240 display and an ARM-architecture processor it'll run GP2X software, maybe without even recompiling it. Should be the same case for the XGP series, except you'd want to make some changes for a 480x272 display if the XGP uses one. But even then you don't HAVE to, the screen just won't be completely filled.

Really? Does the SDL/SDK not contain hardward specific code for the GP2X? I don't know how high up the abstraction goes. Of course I have never coded for it because I don't own one and so I am curious if the XGP really could run binaries so easily due to the OS commonaility? That would be great, but I assumed every developer would need to do a recompile on the new platform.

 

[Shikaku]

Well if it runs Linux, has a 320x240 display and an ARM-architecture processor it'll run GP2X software, maybe without even recompiling it. Should be the same case for the XGP series, except you'd want to make some changes for a 480x272 display if the XGP uses one. But even then you don't HAVE to, the screen just won't be completely filled.

Really? Does the SDL/SDK not contain hardward specific code for the GP2X? I don't know how high up the abstraction goes. Of course I have never coded for it because I don't own one and so I am curious if the XGP really could run binaries so easily due to the OS commonaility? That would be great, but I assumed every developer would need to do a recompile on the new platform.

Even if not, a wrapper is always possible... however I can guarantee it will be simpler than a GP32 to GP2X/XGP wrapper

 

[pantera6]

Well if it runs Linux, has a 320x240 display and an ARM-architecture processor it'll run GP2X software, maybe without even recompiling it. Should be the same case for the XGP series, except you'd want to make some changes for a 480x272 display if the XGP uses one. But even then you don't HAVE to, the screen just won't be completely filled.

hey epicenter
sorry if someone already asked this in the last 17 pages lol.
but anyway, how long do you think it would be before gamepark or someone decides to make a homebrew console which could emulate dreamcast. i like the sound of this new one your designing being able to run N64 at near full speed.

 

[Epicenter]

Really? Does the SDL/SDK not contain hardward specific code for the GP2X? I don't know how high up the abstraction goes. Of course I have never coded for it because I don't own one and so I am curious if the XGP really could run binaries so easily due to the OS commonaility? That would be great, but I assumed every developer would need to do a recompile on the new platform.

They may need to recompile to use hardware acclerated 2D, e.g. I imagine there'll be a custom SDL library developed to utilize the GPU for programs that don't exclusively use OpenGL code. The only hardware-specific code in 99% of GP2X applications is hardware-accelerated SDL by Paeryn.

hey epicenter
sorry if someone already asked this in the last 17 pages lol.
but anyway, how long do you think it would be before gamepark or someone decides to make a homebrew console which could emulate dreamcast. i like the sound of this new one your designing being able to run N64 at near full speed.

It's going to be a long while, really. First of all, Dreamcast emulators at the moment are slow and unoptimized-- this complicates the issue terribly. Second, the common saying is that a system that emulates another must be at least 10 times faster-- this is not a perfect rule since clock speeds can't be compared between architectures .. but you get the idea. If GP uses the S3C2460 in their next machines (XGP/XGPmini) it'll have about the same INTEGER performance as the Dreamcast, but the DC is still over 10 times more powerful at Floating Point math, and has an enormously more powerful 3D accelerator. It will take a machine enormously more powerful-- which does not presently exist-- to emulate it. Right now you're stuck with a very high-end laptop if you want to play Dreamcast games on the go.

N64 is more realistic, it should be able to run at ~30 FPS with some smart devs working on it..

 

[pepone]

Really? Does the SDL/SDK not contain hardward specific code for the GP2X? I don't know how high up the abstraction goes. Of course I have never coded for it because I don't own one and so I am curious if the XGP really could run binaries so easily due to the OS commonaility? That would be great, but I assumed every developer would need to do a recompile on the new platform.

They may need to recompile to use hardware acclerated 2D, e.g. I imagine there'll be a custom SDL library developed to utilize the GPU for programs that don't exclusively use OpenGL code. The only hardware-specific code in 99% of GP2X applications is hardware-accelerated SDL by Paeryn.

binary compatibility is not easy. Nearly all the app released on the gp2x are staticaly compiled against lib like Paeryn SDL and the Minimal lib, so they all access the hardware directly.
An other problem is the weird joystick implementation used in the GP2X (at least, when viewed from the SDL): the pad register button event instead of axe event, shocking
Source compatibility is relatively easy if the target support at least the SDL and preferably Linux.

 

[Orkie]

Really? Does the SDL/SDK not contain hardward specific code for the GP2X? I don't know how high up the abstraction goes. Of course I have never coded for it because I don't own one and so I am curious if the XGP really could run binaries so easily due to the OS commonaility? That would be great, but I assumed every developer would need to do a recompile on the new platform.

Some people access the GP2X hardware directly - these programs wouldn't run. However, as an example, you can already run things that have been compiled for say the iPAQ on the GP2X, so you should be able to with the XGP to some extent too if it runs Linux.

 

[pantera6]

thanks for the explantion epicenter
glad to hear 30fps will be possible on the next machine which is good.
only problem i can see is how to implement all the right buttons on the new gp2x.to be honest i could think of a way to implement the right amount of buttons to play N64 games, but wont nintendo get all sensitive an a portable n64 emu with all the right buttons to play them with?

 

[icurafu]

N64 is more realistic, it should be able to run at ~30 FPS with some smart devs working on it..

That's if you can emulate a 94Mhz MIPS 64-bit RISC CPU on a ARM9 at 300Mhz at most.

 

[Epicenter]

N64 is more realistic, it should be able to run at ~30 FPS with some smart devs working on it..

That's if you can emulate a 94Mhz MIPS 64-bit RISC CPU on a ARM9 at 300Mhz at most.

You'd probably have to drop the speed of the emulated CPU. This would result in slowdown much like if the real system had a slower processor-- more 'bullet-time' slowdown instead of dropped frames like on more modern systems-- but this would have a huge impact on the emulation quality as a whole. 3D capabilities should be taken care of by any decent accelerator like the PowerVR MBX RS ('MBX Lite'). It's much the same case with the NeoGeo. If you emulate it with the original 12 Mhz M68000 and 4 MHz Z80 at 200 Mhz ARM920T clock it won't be very snappy in most games. Now, if you drop the M68000 to 6 MHz and the Z80 to 2.5, you'll see the same performance in most games, and only the most intense ones like Metal Slug will experience much real slowdown-- but the system stops stuttering like it does without the clock adjustments, since it's emulating the system at 100% speed, but the emulated system is just slower.

 

[icurafu]

N64 is more realistic, it should be able to run at ~30 FPS with some smart devs working on it..

That's if you can emulate a 94Mhz MIPS 64-bit RISC CPU on a ARM9 at 300Mhz at most.

You'd probably have to drop the speed of the emulated CPU. This would result in slowdown much like if the real system had a slower processor-- more 'bullet-time' slowdown instead of dropped frames like on more modern systems-- but this would have a huge impact on the emulation quality as a whole. 3D capabilities should be taken care of by any decent accelerator like the PowerVR MBX RS ('MBX Lite'). It's much the same case with the NeoGeo. If you emulate it with the original 12 Mhz M68000 and 4 MHz Z80 at 200 Mhz ARM920T clock it won't be very snappy in most games. Now, if you drop the M68000 to 6 MHz and the Z80 to 2.5, you'll see the same performance in most games, and only the most intense ones like Metal Slug will experience much real slowdown-- but the system stops stuttering like it does without the clock adjustments, since it's emulating the system at 100% speed, but the emulated system is just slower.

Totally agree. Most of the popular games are GPU intensive rather then CPU intensive. Mario 64 and Mario Kart.

 

[Epicenter]

Totally agree. Most of the popular games are GPU intensive rather then CPU intensive. Mario 64 and Mario Kart.

The laggiest games I've seen, like Perfect Dark and Goldeneye, saw only moderate benefits when the CPU was overclocked. There was still brutal lag.. this'd lend evidence to that statement.

 

[Aninhumer]

BTW I thought the point of using libraries was to make apps easy to port?

It's certain SDL will appear for XGP, so wouldn't we just need to recompile the apps?
And I presume someone could make the other libs for XGP too, even if they wouldn't be optimised at first.

Is there some fundamental I'm missing here?

 

[DavidBeoulve]

I came in late, but read up. Option #1 because that's really what the GP2X lacks. Option #2 will have the same problems as the GP2X, only with a slightly faster CPU(s). Yay. Ra ra black & gold.

Or, we could have Option #1, and have some serious fun.

 

[Epicenter]

BTW I thought the point of using libraries was to make apps easy to port?

It's certain SDL will appear for XGP, so wouldn't we just need to recompile the apps?
And I presume someone could make the other libs for XGP too, even if they wouldn't be optimised at first.

Is there some fundamental I'm missing here?

No, I think you've got it about right. The intention on Gamepark's part is to utilize an OpenGL-ES API-compatible GPU. A straight recompile of a program without the hardware SDL the GP2X uses should provide normal unaccelerated performance, I'm sure an SDL library with hardware blitting support (like Paeryn's 'HW-SDL') will be put togther quickly. True performance would be obtained by writing software that utilizes OpenGL technologies to do all heavy graphics operations as well as blitting on the GPU, and in all likelihood, an SDL version will also come up that will provide acceleration of common SDL functionality using the GPU. (Blitting, drawing, alpha-blending, scaling/rotation.) Some things will just get faster automatically if Gamepark's SoC selection includes a VFP9-S unit like the S3C2460 contains, or a Floating point coprocessor-- since functions like SDL_gfx's rotation/scaling routines are exceedingly floating-point heavy, causing them to crawl on the GP2X.

But bottom line, even the most minimal software support will provide the same performance or better on the XGP with no code changes.

 

[nemt]

Sorry if this has been answered a million times, but is GPH completely committed to the ARM architecture? If so, why - is it just a power consumption issue?