skeezix
Internal Development
I've not seen a lot of numbers floating around, and Craig was asking me about some actual 'real world' performance on the Wiz vs GP2x so that folks would have a more concrete idea in their heads before ordering one or t'other.
As such, I put together a little testbed using OutcaST (Atari ST emu. a 16-bit general purpose platform with a wide assortment of games and demos and applications and so-on.)
Some things to consider..
- on the gp2x, it uses 'minimal lib', which is relatively low level. (ie: direct framebuffer access and not using intermediary buffes or the like, etc)
- on the gp2x, I disabled secondary core and mmuhack and so-on to be fair
- on the 2x, audio was enabled (but doing nothing)
- on the wiz, audio was disabled - this audio disparity will raise the Wiz numbers a _Touch_, but not much at all as ST audio is no big load; call it a few FPS counted against the 2x that shouldn't be there
- gp2x was a 200 with firmware 4.0 (while Wiz is on pre-release unoptimized firmware)
- by far the largest factor is this.. Wiz was on GPH supplied SDL layer (not low level like minimal)
- ie: its SDL (so indirect access to display and joystick etc)
- ie: its SDL in software mode (no hardware blits etc, which isn't a big deal for this since I do row by row scren updates)
- ie: its SDL so having to lock/unlock/updatre screen (lock/unlock don't do anything in this case, but its a lot of extra function calls and the screen update sucks)
- ie: its GPH SDL, meaning its extra unoptimized
- ie: Its SDL meaning that I'm updating the display essentially when vert blank hits the bottom, and not every row. GP2X one draws raw to screen row by row so is very accurate; SDL is EXTREMELY slow to do row by row updates, so to give Wiz a chance at performance I made it update at VBL bottom so its row by row rendered offsceen, then update the entire screen at once; itd accurate looking, more or less
Anyway, to be a true fair test I should install Open2x onto my F200, and then run the _Exact same binary_ on it, using SDL. That would still be a hardware accel SDL against a slow software only SDL, but it woudl be a better test. But I didn't do that yet.
So all told, the gp2x one is running 'faster' (closer to hardware), a little slower (audio on)
All told, the Wiz is running slower (software SDL), slightly faster (no audio)
I forget most of the game samples and such, but they worked out identical %age speed or more (for Wiz), but the stressier test is just sitting at the big green GEM Desktop.. that piece of code in the OS is a busy-loop that chews through performance hard:
Wiz: 70fps (on slow SDL!)
GP2x: 49fps (on fast direct hardware!)
In actual game performance and demos, the emulated CPU is being worked less hard in a number of ways, while the graphics system is doing a little more work (not much of a graphics system on the ST, but anyway), so in gaming cases it was usually around the same %age upwards to another 30% faster for both (ie: gp2x would go to 60-70fps, while Wiz would hit up to 90-100fps).
Again, this isn't a fair test and my methods were a little crude.
Better test results if I get open2x going, and when a hardware lib gets finished for Wiz (several people are working on that.)
Depending how you want to call these things.. you could say 30-50% performance increase as-is, and thats when the gp2x has an unhealthy advantage over the wiz. (ie: 49 * 1.4 = 70, so about a 1.4 multiplier in performance.)
If I get fre time I'll do a better benchmark.. some popular games and GEM for various operations, and under various environments (open2x, etc).
At least it means that Wi folks can have a OutcaST ASAP if they want it
jeff
edit:
FWIW, the mmuhack didn't really help or hinder outcast, so no biggy; the emu can be made to run faster on the 2x, but my point was not to try a perfectly ideal gp2x setup against the pre-release total not ideal Wiz.. that would not be fair; I'm assumig the desired test is a decent real world estimate of gp2x, versus a not yet real world Wiz, so I tried to approximate that situation. Bear that in mind. (And let me know if my metric is no right.)
As such, I put together a little testbed using OutcaST (Atari ST emu. a 16-bit general purpose platform with a wide assortment of games and demos and applications and so-on.)
Some things to consider..
- on the gp2x, it uses 'minimal lib', which is relatively low level. (ie: direct framebuffer access and not using intermediary buffes or the like, etc)
- on the gp2x, I disabled secondary core and mmuhack and so-on to be fair
- on the 2x, audio was enabled (but doing nothing)
- on the wiz, audio was disabled - this audio disparity will raise the Wiz numbers a _Touch_, but not much at all as ST audio is no big load; call it a few FPS counted against the 2x that shouldn't be there
- gp2x was a 200 with firmware 4.0 (while Wiz is on pre-release unoptimized firmware)
- by far the largest factor is this.. Wiz was on GPH supplied SDL layer (not low level like minimal)
- ie: its SDL (so indirect access to display and joystick etc)
- ie: its SDL in software mode (no hardware blits etc, which isn't a big deal for this since I do row by row scren updates)
- ie: its SDL so having to lock/unlock/updatre screen (lock/unlock don't do anything in this case, but its a lot of extra function calls and the screen update sucks)
- ie: its GPH SDL, meaning its extra unoptimized
- ie: Its SDL meaning that I'm updating the display essentially when vert blank hits the bottom, and not every row. GP2X one draws raw to screen row by row so is very accurate; SDL is EXTREMELY slow to do row by row updates, so to give Wiz a chance at performance I made it update at VBL bottom so its row by row rendered offsceen, then update the entire screen at once; itd accurate looking, more or less
Anyway, to be a true fair test I should install Open2x onto my F200, and then run the _Exact same binary_ on it, using SDL. That would still be a hardware accel SDL against a slow software only SDL, but it woudl be a better test. But I didn't do that yet.
So all told, the gp2x one is running 'faster' (closer to hardware), a little slower (audio on)
All told, the Wiz is running slower (software SDL), slightly faster (no audio)
I forget most of the game samples and such, but they worked out identical %age speed or more (for Wiz), but the stressier test is just sitting at the big green GEM Desktop.. that piece of code in the OS is a busy-loop that chews through performance hard:
Wiz: 70fps (on slow SDL!)
GP2x: 49fps (on fast direct hardware!)
In actual game performance and demos, the emulated CPU is being worked less hard in a number of ways, while the graphics system is doing a little more work (not much of a graphics system on the ST, but anyway), so in gaming cases it was usually around the same %age upwards to another 30% faster for both (ie: gp2x would go to 60-70fps, while Wiz would hit up to 90-100fps).
Again, this isn't a fair test and my methods were a little crude.
Better test results if I get open2x going, and when a hardware lib gets finished for Wiz (several people are working on that.)
Depending how you want to call these things.. you could say 30-50% performance increase as-is, and thats when the gp2x has an unhealthy advantage over the wiz. (ie: 49 * 1.4 = 70, so about a 1.4 multiplier in performance.)
If I get fre time I'll do a better benchmark.. some popular games and GEM for various operations, and under various environments (open2x, etc).
At least it means that Wi folks can have a OutcaST ASAP if they want it
jeff
edit:
FWIW, the mmuhack didn't really help or hinder outcast, so no biggy; the emu can be made to run faster on the 2x, but my point was not to try a perfectly ideal gp2x setup against the pre-release total not ideal Wiz.. that would not be fair; I'm assumig the desired test is a decent real world estimate of gp2x, versus a not yet real world Wiz, so I tried to approximate that situation. Bear that in mind. (And let me know if my metric is no right.)
