@Alex.: The issue though is that if you're using the 2D acceleration to blow up the image, the 2D hardware must still transfer it across the bus to the framebuffer in memory and then it must make its way to the LCD controller and be physically drawn to the display. If you're using a lower resolution to reduce bandwidth utilization and bus contention between CPUs and RAM, you wouldn't put much of a dent in it that way.
I was referring instead to using the LCD controller, which would be one of the last steps in the chain of putting an image on the screen, to blow up the image to the full size of the LCD, as the scaler block in the MMSP2 did. This is after communication between CPU/2D/3D blocks and RAM and therefore would not have a negative impact on bandwidth use/bus contention. A look through the MMSP2+ public docs show this does appear to be supported, but it's hard to make a call either way. Since it was present in MMSP2, it is
probably present in MMSP2+, but it's best not to assume.
Of course, hopefully the scaler unit in the MMSP2+ wouldn't use as much power as the one in the MMSP2 did, as it would have a highly adverse effect on battery life otherwise, potentially a very dramatic one at that.
@Squidge: My proposition regarding acceleration of the SNES' more complex PPU features like transparency are in the hypothetical, but are possible to implement as I am sure you well know. For example, SNES emulators on the Nintendo DS make use of VDP features on that system to accelerate video operations, and make gameplay acceptable even using a rather primitive (compared to the GP2X's 200 MHz+ ARM920T) 67 MHz ARM9. However such a feat would require heavy rewriting of an existing emulator that relied primarily on software rendering techniques. Even rewriting the graphical routines in an emulator like SquidgeSNES in full ARM ASM would be quite a task but provide quite a boost in performance. Easier said than done, I know. It might even be easier to work form the ground up; the end result would probably be more elegant.
Goobers said:
He meant on the GP2X- oddworld is already fullspeed
Pardon the slight tangent, but as long as we are going to be quantifying real-world application performance I feel it is important we set some standards on our terminology. What is the common definition of 'Fullspeed' on this forum exactly? In the literal sense it should be 60 FPS with no frameskip applied. However I've seen numerous interpretations of this, where 100% speed with only 1/3rd of frames displayed could be defined as "Fullspeed".
kanzlr said:
maybe i misunderstood one of the postings, but my impression was, that the magicEyes SoCs are the only ones that are affordable in small quantities. and for an independent project, you cant just buy 20.000 units in hope you can sell all these 20.000 handhelds.
Correspondence from Gamepark indicated a cost of $24 for i.MX31 SoCs in the amounts that would realistically be purchased for a niche handheld like the XGP or GP2X, etc.
QUOTE
I wonder if development of the XGP ceased because key members of the project killed themselves after your constant reiteration of most important points? wink.gif
While I cannot comment on Gamepark's financial situation prior to their shutdown, Gamepark engineers and PR personnel were very receptive to design suggestions including SoC selection, RAM speed/capacity, etc. However disputes between management, who lacked technical savvy (most notably the CEO of the company) and the engineers led to very little progress being made. Engineers would suggest a solid single machine, and the CEO would insist upon incompatible, irrationally designed units with strange feature combinations, like incompatible resolutions, RAM capacities, CPU types, and control schemes, aimed at markets that didn't always even exist (like that for the GP-KiDS). The CEO also had a tendency to become frustrated and take out his anger on his subordinates, literally screaming at them to vent anger. This led to low morale within the company and high employee turnover. I believe all of these factors led to the downfall of the company and dissolving of the XGP project(s).
Last I heard the project was being handed over to another company, who would attempt to launch the XGP KiDS and gauge public reaction to determine if the XGP/XGPmini were worthwhile investments. If I am permitted to do so and if issues develop further, and of course if there is interest, I will provide more information in the future. However for the time being that's neither here nor there so I digress.
