Observations Regarding Xgp Product Line Componentry ...

[Epicenter]

There are some major discrepancies in the product description from GamePark and MagicEyes/MES Digital, maker of the SoC units that will be used in the XGP. As is known, the GP2X utilizes MES' 'MMSP2' line of SoC (system on a chip), housing a 200 MHz ARM920T and 940T microprocessor, video decoding hardware, 2D blitter unit, memory controller and some reader hardware, e.g. SD/CF/PCMCIA controllers, LCD handling hardware, the works-- all on one unit. A similar unit will power the XGP and XGP-Mini. Since the specs are in line with the MMSP2 in the GP2X with the addition of 3D capability, and statements by MES, the safe determination is the XGP/XGP-Mini will use the VRENDER-3D SoC from MES.

Now, this unit has a 200 MHz ARM920T, not a 266 MHz one as mentioned by GamePark. No SoC from MES is rated for 266 MHz. It would appear the spec is determined in much the way Craigix calls the GP2X's ARM920T '240 MHz'-- he's not encountered one that didn't overclock that far. This tells me, GamePark's prototypes made it to 266 MHz stably so they listed this as the rating. It is extremely unlikely overclocking efforts will yield far past the ~300-315 MHz range GP2X users have achieved with stability, without voltage modification or other end-user warranty-voiding hacks. Therefore, CPU horsepower will remain about the same as what we presently experience on GP2X units.

GPU performance appears 'good' but not spectacular. 3D performance was demonstrated in Quake 3. Seemingly due to performance issues, the display was zoomed with the 'FOV x' console command to show less of the 3D scene, decrease 3D workload and improve framerate. Graphical quality was at the least as low as it will go on the PC builds of Quake 3, except in all likelihood, drawing to a 320x240 frame. No shaders appeared present; there are no shader units present in the 3D core on the VRENDER-3D and software shaders would be much too slow to run on the ARM920T. Framerate appeared to be in the 20s or lower. Very poor performance in Quake 3, in short. Quake 2 and 1's performance would probably be very good on this GPU, however. It would also provide significant performance gains to PSX emulation, though CPU capability limitations will prevent it from making N64 emulation feasible. It would significantly aid development of 3D games, if homebrew capabilities are made feasible by GamePark. Overall VRENDER-3D rendering performance is likely similar to that of an old GeForce 1 (or earlier) graphics adapter, but will maintain OpenGL compatibility so operation with existing PC 3D games that have Linux/SDL ports should be fairly painless. Depending on the implementation, perhaps overclocking of the 3D engine is possible.

Addition of the VRENDER-3D's GPU entailed removal of the 940T coprocessor. In the GP2X this coprocessor served in a support role for video decoding/playback. I am unclear on the significance in this process and if its absence in the VRENDER-3D chipset will limit video playback performance. It is my personal opinion the 940T's removal could be compensated for with the other components included, but we'll really need to see. Software that is later developed (like MadDog's K9 3D engine) would not be able to take advantage of this processor, as it would not longer be present (obviously.)

Interfaces-- GamePark has described support for SD cards much akin to the GP2X. There is a discrepancy here-- MMSP2 units are listed as supporting SD, CF, PCMCIA and other interfaces. VRENDER-3D has CF and PCMCIA support but NO listing of any SD card interface. Unless this is implemented in other means or via an external IC is unknown, but there is not core functionality for it in the VRENDER-3D SoC.

RAM changes between the XGP and XGP-Mini will clearly be performed with external RAM chip size changes akin to the implementation in the GP2X. This makes little sense to me, as purchasing ONE type of RAM IC in larger quantity would in all likelihood cost significantly less, especially from ONE distributor/manufacturer.

Controls (analog/digital, d-pad, stick, whatever the choice) and LCD type, as well as means of powering the units (GP has claimed the use of Lithium Polymer rechargable cells internal to the unit) are design/engineerign decisions to be made by GP themselves and I can't really speculate on any of them due to lack of information. I'd lean towards something digital due to the machine's aforementioned very-limited 3D nature.

In the end, we're looking at the same hardware as the GP2X with the removal of the ARM940T coprocessor, some simple 3D capability, and some changes external to the SoC such as RAM, LCD, and controls. Not a dramatic difference, but I am interested to see how well it handles some scenarios which don't play out as well as hoped on the GP2X (most of these being 3D, but there is potential for improvement of say, SNES emulation, and perhaps some more advanced 2D acceleration through creative exploitation of OpenGL functionality in the GPU.)

My two cents.

 

[Godmil]

Fascinating analysis. very enjoyable read, thanks
I'm curious where did you see this footage of Q3 running. I'd love to check that out.
a wee opinion of mine... and I'm not talking from any knowlegable postions... now that it's looking more and more likely that there will be good PSX emulation on the GP2X (something I wouldn't have thought possible a few months ago), I dont think N64 emulation on the XGP is sounding too impossible. Someone will always come along and show you something that you couldn't have anticipated.

 

[Radek]

There are some major discrepancies in the product description from GamePark and MagicEyes/MES Digital, maker of the SoC units that will be used in the XGP. As is known, the GP2X utilizes MES' 'MMSP2' line of SoC (system on a chip), housing a 200 MHz ARM920T and 940T microprocessor, video decoding hardware, 2D blitter unit, memory controller and some reader hardware, e.g. SD/CF/PCMCIA controllers, LCD handling hardware, the works-- all on one unit. A similar unit will power the XGP and XGP-Mini. Since the specs are in line with the MMSP2 in the GP2X with the addition of 3D capability, and statements by MES, the safe determination is the XGP/XGP-Mini will use the VRENDER-3D SoC from MES.

Now, this unit has a 200 MHz ARM920T, not a 266 MHz one as mentioned by GamePark. No SoC from MES is rated for 266 MHz. It would appear the spec is determined in much the way Craigix calls the GP2X's ARM920T '240 MHz'-- he's not encountered one that didn't overclock that far. This tells me, GamePark's prototypes made it to 266 MHz stably so they listed this as the rating. It is extremely unlikely overclocking efforts will yield far past the ~300-315 MHz range GP2X users have achieved with stability, without voltage modification or other end-user warranty-voiding hacks. Therefore, CPU horsepower will remain about the same as what we presently experience on GP2X units.

GPU performance appears 'good' but not spectacular. 3D performance was demonstrated in Quake 3. Seemingly due to performance issues, the display was zoomed with the 'FOV x' console command to show less of the 3D scene, decrease 3D workload and improve framerate. Graphical quality was at the least as low as it will go on the PC builds of Quake 3, except in all likelihood, drawing to a 320x240 frame. No shaders appeared present; there are no shader units present in the 3D core on the VRENDER-3D and software shaders would be much too slow to run on the ARM920T. Framerate appeared to be in the 20s or lower. Very
poor performance in Quake 3, in short. Quake 2 and 1's performance would probably be very good on this GPU, however. It would also provide significant performance gains to PSX emulation, though CPU capability limitations will prevent it from making N64 emulation feasible. It would significantly aid development of 3D games, if homebrew capabilities are made feasible by GamePark. Overall VRENDER-3D rendering performance is likely similar to that of an old GeForce 1 (or earlier) graphics adapter, but will maintain OpenGL compatibility so operation with existing PC 3D games that have Linux/SDL ports should be fairly painless. Depending on the implementation, perhaps overclocking of the 3D engine is possible.

Imho 20fps for Q3 in 320x240 and with crippled settings isn't good. It's very poor and hardy at level of GF1. I could on weaker Voodoo4 play Q3 in 800x600 rather easily.

If it will be really so 3D perromance wise for XGP it's not standing any chance against PSP. It might have problems even with DS...

As I know XGP will have 32bits wide DDR memory interface. It should give it twice a bandwith the GP2x has. So around 800MB/s-1GB/s - it's in a teritorry of Voodoo1 class 3D accelerators.

 

[moz]

the console is doomed if its trying to take on nintendo/sony if it doesnt have a decent software company behind it supplying good or crappy games ie EA etc.

it doesnt matter how good the hardware is.

 

[DaveC]

Controls (analog/digital, d-pad, stick, whatever the choice) and LCD type, as well as means of powering the units (GP has claimed the use of Lithium Polymer rechargable cells internal to the unit) are design/engineerign decisions to be made by GP themselves and I can't really speculate on any of them due to lack of information. I'd lean towards something digital due to the machine's aforementioned very-limited 3D nature.

They already stated what the controls will be for the XGP etc. Unless they change them the XGP will have an analog controller and a 16:9 480 x 272 LCD. Very similar to the PSP except that the screen is a bit smaller and lacks a d-pad.

 

[OMars]

This is overly reminiscent of what happened to the gizmondo.........but it's starting to get great homebrew so I might just pick one up....

 

[Radek]

the console is doomed if its trying to take on nintendo/sony if it doesnt have a decent software company behind it supplying good or crappy games ie EA etc.

it doesnt matter how good the hardware is.

It doesn't as long it wouldn't be much worse than in the PSP. But if it will be so weak (barely running Q3 in a very crippled conditions) then better GP deosn't position the XGP as "3D handheld" unless they want to generete some laughs.

Are there any fillrate claims for the XGP? I couldn't find any so far.

 

[moz]

.l

 

[Epicenter]

This is true about relative performance to a 3D GPU; GeForce 1 is a bit of an overestimation; the GPU of the old 2 and 4MB graphics adapters from the early days of PC 3D acceleration are really better estimations. That really is awful about the resolution of the XGP; if I port Stargazer over we'll have to just center it or skew it out to the full screen resolution SNES or GB-style. That wouldn't look too good. I suppose it'd fit better on the XGP-Mini which IIRC was spec'ed by GP as a 320x240 display. But then we have half the RAM of the GP2X to play with! How confusing.

Now, this hardware is probably better explotable through software really geared for its strengths and weaknesses-- Quake 3 is NOT the game to do that! It's the most CPU-bound of any recent 3D game I can think of. It relies on the CPU for all sorts of tasks; IIRC all shaders are done in software, even (this may be why they're disabled in GamePark's demo.) Everything is extremely floating-point heavy; the game 'script' (gamex86 DLL) doesn't even contain an integer type for variables.. all math done for game logic outside the core engine functionality is floating point, and most engine code I'm sure is too.. and the XGP units won't have a floating point unit available. The GPU *and* CPU are probably struggling terribly in that Q3 demonstration. With massive modification to make most of the engine fixed-point there'd probably be significant gains but that's quite a colossal task.

 

[nubie]

I assume the reason for using any of these mesdigital (MagicEyes) chips is because they are cheap and have many functions?

When will AMD and/or Nvidia get off their asses and do a "real" SOC (VIA doesn't count; I built two mini-itx boards and they both lacked features I felt were necessary, like getting all the way through the Windows XP professional install without crashing.)

Features I want in my SOC:

TV-Out,
USB 2.0 host,
real 3d chip (thus the nVidia 7 series)
a power saving process, 35nm ideally, 65nm would be fine (the MMSP2 is archaic at 180nm or 130nm or whatever it is, even 90nm is out of hand in a portable nowadays, and anything else for that matter)

POWER, at least 500mhz, I don't care about the architecture, we can underclock to 100mhz or overclock to 600mhz, I want handheld games that kick ass.

 

[DaveC]

This is true about relative performance to a 3D GPU; GeForce 1 is a bit of an overestimation; the GPU of the old 2 and 4MB graphics adapters from the early days of PC 3D acceleration are really better estimations. That really is awful about the resolution of the XGP; if I port Stargazer over we'll have to just center it or skew it out to the full screen resolution SNES or GB-style. That wouldn't look too good. I suppose it'd fit better on the XGP-Mini which IIRC was spec'ed by GP as a 320x240 display. But then we have half the RAM of the GP2X to play with! How confusing.

That is why the XGP would make a horrid emu system. Stretching everything to that resolution and then playing the messy results with an analog? For what? maybe a few more frames per second here and there, why not just stick with the GP2X?

As far as Stargazer, why not just stay with the GP2X? Why bother stretching it all out to 16:9 and doing all kinds of pixel doubling and filtering ruining the look of it?

I suppose the attraction is just too great with the XGP for many because well, I guess because, "it is new". People love to just jump to the next thing whether it makes sense or not it seems. If the XGP was out first, then the GP2X came out later I guess everyone would be going mental over the GP2X. I guess it is the psychology of "newer is always better".

This bit about Gamepark releasing 3 systems all incompatible with different HW configurations just makes no sense, they are just competing with themselves.

 

[OMars]

That is why the XGP would make a horrid emu system. Stretching everything to that resolution and then playing the messy results with an analog? For what? maybe a few more frames per second here and there, why not just stick with the GP2X?

As far as Stargazer, why not just stay with the GP2X? Why bother stretching it all out to 16:9 and doing all kinds of pixel doubling and filtering ruining the look of it?

I suppose the attraction is just too great with the XGP for many because well, I guess because, "it is new". People love to just jump to the next thing whether it makes sense or not it seems. If the XGP was out first, then the GP2X came out later I guess everyone would be going mental over the GP2X. I guess it is the psychology of "newer is always better".

This bit about Gamepark releasing 3 systems all incompatible with different HW configurations just makes no sense, they are just competing with themselves.

My friend, DaveC , I think that you should stop telling devs what to do with systems. I like you criticism and all, but some devs want to work on other consoles as well. I know you think that they might abandon the gp2x, but there are a lot of devs out there who could work on the gp2x and losing a few wont hurt(if they actually abandon it...... ). I don't want to start an argument, because I know what happens after that so just calm down dude.

P.S. Take a break and play some games on your GP2X. B)

 

[Epicenter]

I assume the reason for using any of these mesdigital (MagicEyes) chips is because they are cheap and have many functions?

When will AMD and/or Nvidia get off their asses and do a "real" SOC (VIA doesn't count; I built two mini-itx boards and they both lacked features I felt were necessary, like getting all the way through the Windows XP professional install without crashing.)

Features I want in my SOC:

IIRC, nVidia is considering working on something, or entering into a deal, to provide decent 3D acceleration to SoCs mostly for the PocketPC realm of the industry. Regardless, an AMD K7 or K8 processor will use far, FAR more power than any ARM chip. For comparison, AMD's mobile processor designs go down to about 25-35W at the lowest with the existing product line; that's 35 watts of power in and dissipated. The 200 MHz part in the GP2X uses/dissipates 50 THOUSANDTHS of ONE watt yet packs considerable punch. A 200 Mhz Pentium I/Pro/MMX or K6 used/dissipated enormously more, too. ARM makes better mobile processors than any other company, period. This is only further driven home by their new clockless processor architecture. A desktop processor in an SoC just plain doesn't make sense. If you have a problem with the lack of a dedicated hardware floating point unit, the ARM11 series would satisfy this need.

That is why the XGP would make a horrid emu system. Stretching everything to that resolution and then playing the messy results with an analog? For what? maybe a few more frames per second here and there, why not just stick with the GP2X?

As far as Stargazer, why not just stay with the GP2X? Why bother stretching it all out to 16:9 and doing all kinds of pixel doubling and filtering ruining the look of it?

I suppose the attraction is just too great with the XGP for many because well, I guess because, "it is new". People love to just jump to the next thing whether it makes sense or not it seems. If the XGP was out first, then the GP2X came out later I guess everyone would be going mental over the GP2X. I guess it is the psychology of "newer is always better".

This bit about Gamepark releasing 3 systems all incompatible with different HW configurations just makes no sense, they are just competing with themselves.

My friend, DaveC , I think that you should stop telling devs what to do with systems. I like you criticism and all, but some devs want to work on other consoles as well. I know you think that they might abandon the gp2x, but there are a lot of devs out there who could work on the gp2x and losing a few wont hurt(if they actually abandon it...... ). I don't want to start an argument, because I know what happens after that so just calm down dude.

P.S. Take a break and play some games on your GP2X. B)

Definitely no intention of abandoning the GP2X. I'd like to port Stargazer to the XGP and/or XGP-Mini to expand the audience and exploit possibly enhanced graphical processing capabilities in 2D due to the GPU (OpenGL functionality can accelerate 2D operations as well.) The game is also planned to be ported to the Dreamcast, PCs, X86 and PowerPC Macs with varying upgrades to match their platform. The '2x right now is really the best balance for it, though, the XGP platforms both have issues (Mini has a rather low RAM ceiling, though I could probably work within it) .. and the standard XGP has a jacked-up screen resolution so we'd need to scale the game to match the screen or put a border around it Super Game Boy / SquidgeSNES style.

 

[Yono]

That is why the XGP would make a horrid emu system. Stretching everything to that resolution and then playing the messy results with an analog? For what? maybe a few more frames per second here and there, why not just stick with the GP2X?

As far as Stargazer, why not just stay with the GP2X? Why bother stretching it all out to 16:9 and doing all kinds of pixel doubling and filtering ruining the look of it?

I suppose the attraction is just too great with the XGP for many because well, I guess because, "it is new". People love to just jump to the next thing whether it makes sense or not it seems. If the XGP was out first, then the GP2X came out later I guess everyone would be going mental over the GP2X. I guess it is the psychology of "newer is always better".

This bit about Gamepark releasing 3 systems all incompatible with different HW configurations just makes no sense, they are just competing with themselves.

My friend, DaveC , I think that you should stop telling devs what to do with systems. I like you criticism and all, but some devs want to work on other consoles as well. I know you think that they might abandon the gp2x, but there are a lot of devs out there who could work on the gp2x and losing a few wont hurt(if they actually abandon it...... ). I don't want to start an argument, because I know what happens after that so just calm down dude.

P.S. Take a break and play some games on your GP2X. B)

I think that was pretty unwise. I think DaveC's response should be pretty interesting.

 

[Epicenter]

I hate the resolution selection, but honestly, the analog stick will probably be OK. I know we could put together solid and smooth movement code using a wide range of directions for great dodging and maneuvering ability in StarGazer and an analog stick makes great sense for AOA-G as it IS a first-person shooter after all.

I think I will e-mail GP about the machines and see if they will contemplate some hardware changes before any sort of mass production starts... the machines could probably accomodate some alteration.

 

[nubie]

I assume the reason for using any of these mesdigital (MagicEyes) chips is because they are cheap and have many functions?

When will AMD and/or Nvidia get off their asses and do a "real" SOC (VIA doesn't count; I built two mini-itx boards and they both lacked features I felt were necessary, like getting all the way through the Windows XP professional install without crashing.)

Features I want in my SOC:

IIRC, nVidia is considering working on something, or entering into a deal, to provide decent 3D acceleration to SoCs mostly for the PocketPC realm of the industry. Regardless, an AMD K7 or K8 processor will use far, FAR more power than any ARM chip. For comparison, AMD's mobile processor designs go down to about 25-35W at the lowest with the existing product line; that's 35 watts of power in and dissipated. The 200 MHz part in the GP2X uses/dissipates 50 THOUSANDTHS of ONE watt yet packs considerable punch. A 200 Mhz Pentium I/Pro/MMX or K6 used/dissipated enormously more, too. ARM makes better mobile processors than any other company, period. This is only further driven home by their new clockless processor architecture. A desktop processor in an SoC just plain doesn't make sense. If you have a problem with the lack of a dedicated hardware floating point unit, the ARM11 series would satisfy this need.

real 3d chip (thus the nVidia 7 series)

- A GeForce *7* GPU?! That's about *90-130* Watts of power and heat right there! The machine would have to be huge and use a large heatsink/fan assembly, and it would tear through a small LiIon battery in minutes, or a pair of high-capacity AAs in minutes. In fact, a high-end LiIon cell like that in a laptop that can supply 12v to be stepped down to levels the card would use might even be necessitated-- even 2800MAh is probably nowhere near enough to even begin to drive a monster GPU like that.

POWER, at least 500mhz, I don't care about the architecture, we can underclock to 100mhz or overclock to 600mhz, I want handheld games that kick ass.

Older larger processes make sense in an SoC where extreme low-level fabrication like that to make the entire unit 90nm, much less *65nm* or *35nm* aren't practical or available to the companies DOING fabrication. High-end PC microprocessors don't even utilize 35nm! And this would just reduce power/heat, it wouldn't do much good on a mobile platform where you'd never be using a processor that would not dissipate or utilize nearly enough to justify it. Chip yields would decrease as the parts became harder to make and more parts came out faulty, making the units far more expensive. In fact there's only a few places in the world, IIRC, that can even FABRICATE at 65nm, most of these in all likelihood being Intel and AMD plants!

POWER, at least 500mhz, I don't care about the architecture, we can underclock to 100mhz or overclock to 600mhz, I want handheld games that kick ass.

Define "kick ass". If you think all the GP2X is capable of is the emulators that presently exist and homebrew games of the quality/speed that have been released so far, you're underestimating its abilities. Bear in mind that your average 2D Playstation 1 or Saturn game had more advanced algorithmic and graphical prowess than most of the homebrew titles out for the machine so far (no offense to any developers of course) but these machines used ancient sub-30 MHz processors and tiny amounts of RAM-- the GP2X's CPU is over 200 Mhz and of a superior architecture, and capable of running up to 240 or even *320* MHz (I can run most programs at 312 MHz), and there is about 48MB of usable RAM compared to just a handful of kilobites on those machines. The capabilities of this machine is staggering, and I learn more about just how much it can accomplish every day I work with it. You'll be seeing much more impressive things in the future. Now, if you're looking for Doom 3 or Half-Life 2 or F.E.A.R. 3D graphics on a handheld game system .. well, I guess you should be looking for a PC laptop.

If MagicEyes could do a real nVidia accelerator in a SoC I would like that then in place of the 940t and then just clock up the 920T core.

I meant the geForce 7300 series, same architecture on a 65nm bus, very low power consumption, half of that would stun on this system, I suppose I am wrong and a goforce 5500 would do just as well . (for cellphones and pocket PC's )

Define kick ass? I suppose I mean kick-ass 3D games, I know they are coming, I just haven't seen any yet.

The work that optimus is doing is giving me hope though, I certaintly didn't mean to imply all the rest of the work being done is not cool, I just want to see the snes, PSX and 3D going faster. (I suppose we just need Firmware 4.0 when they finally let us at all 64MB of ram in one chunk and the Divx player doesn't lock up every other video)

Any clue as to the quality of the RAM we have and/or its performance when clocked or with altered timings?

I will be waiting, I think I am going to be selling my mk2 soon because I am so far in debt right now (car troubles, 3 cars went down lately), If I do I will buy a MK3 if they are out when I have money again, that way I will have owned all four models (FE, MK1, MK2, and MK3 ).

 

[Epicenter]

If MagicEyes could do a real nVidia accelerator in a SoC I would like that then in place of the 940t and then just clock up the 920T core.

That's exactly what VRENDER-3D is, it replaces the 940T with the 3D accelerator. It's just not a very powerful 3D accelerator, and it's not from nVidia. I believe it's their own design. I don't really see a small Korean company teaming up with nVidia.

I meant the geForce 7300 series, same architecture on a 65nm bus, very low power consumption, half of that would stun on this system, I suppose I am wrong and a goforce 5500 would do just as well . (for cellphones and pocket PC's )

You'll still see massive power usage that would annihilate AAs or a small LiIon cell. The ARM9's power draw would be nothing in comparison.

Define kick ass? I suppose I mean kick-ass 3D games, I know they are coming, I just haven't seen any yet.

The work that optimus is doing is giving me hope though, I certaintly didn't mean to imply all the rest of the work being done is not cool, I just want to see the snes, PSX and 3D going faster. (I suppose we just need Firmware 4.0 when they finally let us at all 64MB of ram in one chunk and the Divx player doesn't lock up every other video)

We can do that already, it's what Squidge's MMU hack does. We don't need any firmware upgrade for that, though it'd be nice if it was integrated into the kernel as a module in a future firmware and it didn't then need to be added to programs indiviudally. The video player .. well, that's just a rushed, faulty program that needs work or replacement.

Any clue as to the quality of the RAM we have and/or its performance when clocked or with altered timings?

I wouldn't expect incredible performance gains when timings or clockrates are changed; but it does run at its rated speed (133 MHz) only when the ARM920T is going at 266 MHz. Above that goes above spec and overclocks the RAM, though you can prevent this via the new CPU and LCD Tweaker tool.

 

[DaveC]

Definitely no intention of abandoning the GP2X. I'd like to port Stargazer to the XGP and/or XGP-Mini to expand the audience and exploit possibly enhanced graphical processing capabilities in 2D due to the GPU (OpenGL functionality can accelerate 2D operations as well.) The game is also planned to be ported to the Dreamcast, PCs, X86 and PowerPC Macs with varying upgrades to match their platform. The '2x right now is really the best balance for it, though, the XGP platforms both have issues (Mini has a rather low RAM ceiling, though I could probably work within it) .. and the standard XGP has a jacked-up screen resolution so we'd need to scale the game to match the screen or put a border around it Super Game Boy / SquidgeSNES style.

Wider audience? Maybe but I would bet that it would probably be the same exact GP2X audience. Most XGP users will mostly be ex-GP2X users that jumped ship for the "next new shiny gadget" but do what you need to.

The others make more sense such as Dreamcast, PC etc. Maybe the PSP and/or DS would make more sense than the XGP too.

Fractional scaling on a fixed pixel device such as an LCD? That is probably the biggest atrocity to visuals ever since the invention of the "RF-switch"

Many multi-platform games suffer from the fact that they can't take advantage of the target hardware. For example if you have to start cutting out sprite animation frames and make the sprites smaller on the GP2X version to keep memory requirements down for ease of porting to the lowest common denominator Mini with its less RAM that is when multi-platform starts to get to be a bad thing.

 

[Radek]

Many multi-platform games suffer from the fact that they can't take advantage of the target hardware. For example if you have to start cutting out sprite animation frames and make the sprites smaller on the GP2X version to keep memory requirements down for ease of porting to the lowest common denominator Mini with its less RAM that is when multi-platform starts to get to be a bad thing.

Better is to just reduce bitdepth from 16bpp to 8bpp. Or even implement some kind of bitmap compression (4bit CLUT wouldn't be so bad for individual sprites). So functionally a game would be the same but of course machines with fewer resources would get worse quality.

Eventually sprites could be stored as vectors then just rendered into target res of any given machine.

 

[Epicenter]

I did consider 8bit but we'll probably end up using more colors than that in some areas, even though we are keeping an old-school artistic style by keeping it looking palletized. Honestly, if all 32MB can be accessed by the 3D engine in the VRENDER-3D on the XGP-Mini, it should be sufficient-- especially since we can stream music from faster SD cards (preloading to RAM will be an option.) So, the game would not need to be limited to fit the hardware.

Probably the biggest gains would come on the XGP/XGPMini from using OpenGL-ES functionality to handle more stressful visual elements; e.g. more sprites onscreen at once with high framerate in the more insane difficulty levels, fancier alpha blending effects, etc. Maybe scaling/rotation can be done on the GPU as well. I worry this may be too specific a function and best done on MagicEyes/MES Digital's 2D accelerator, which is not included at all in these machines apparently due to the VRENDER-3D's specs. I don't see an MES SoC that sports the 2D Accelerator except VRENDER-0 at all, and that has a rather anemic CPU.

I hate how scaling looks; so we'd probably make it just an option, and when off, it'd fill the screen with a very nice-looking border like Super Game Boy, SquidgeSNES and GnuBoy2x can do, specific to the character you are utlizing. Perhaps we could relocate HUD elements out to that area and unclutter the gameplay area a bit so it's not a total waste, even if main game graphics don't exceed a 320x240 area. On the Mini, it'd match the res, but the tinyness of that display and segmented D-pad might drive me nuts. I'd see myself buying the full-blown XGP if anything.

Not to mention that AOA-G, being a first-person shooter, would thrive best on the XGP with integrated 802.11x wireless multiplayer capability...