Discussion in 'General Discussions' started by WarmFluffyUK, Aug 13, 2007.
Yes I read that too, the memory of 926 core is shared with GPU, but like you have already write for homebrew we can use 400*240 resolution and keep high resolution for apps like (browser, launcher, frontend, sound player, picture viewer ...) which need generaly less cpu power than game
What might be a problem with voluntarily using a lower resolution, however, is that there would be about half of the screen real estate wasted. Unlike an analog display you can't specify a custom resolution and have the display adapt to fill all empty space with it, you'd need to have the 400x240 area and then blank space all around it. Unless, the image could be blown up to full size (albeit with some potential loss of quality) after the fact, thus still sparing memory bandwidth.
I too like it. Just a sidenote though that since with a true 2D GPU, there would be no need to implement transparency in software, rather in hardware, so it wouldn't cost CPU time and properly implemented, work without slowing down emulation one iota.
Someone obviously hasn't written a SNES emulator
There are quite a few sources- pricing of i.MX31 parts for example, was roughly $25 when purchased in a quantity appropriate for a device like the GP2X
and the prices of the Magiceyes part were approximately? I've no idea myself, so if you could give a clue between the two price points rather than "a very small increase" it would be interesting.
this was per correspondence I was provided during talks with GamePark regarding development of the XGP series
I wonder if development of the XGP ceased because key members of the project killed themselves after your constant reiteration of most important points?
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.
and for that you get a big fat red 'X' and zero points
Unless, the image could be blown up to full size (albeit with some potential loss of quality) after the fact
Of course it can! Do you think we are still in the 90's or something?
The screen is 800x480. Any 2d acceleration worth its salt should be able to scale a 400x240 image to fullscreen for little to no cost. There wouldn't be any loss of visual quality, either, because a 4.3" 800x480 screen has very small pixels, and the doubled pixels are probably about the same size as a single pixel on the Gp2X's screen.
@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.
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".
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.
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.
When I suggested in the other thread using 400x240 as a resolution for high-update-rate action type games I was assuming the LCD controller could do this simple pixel-doubling type of scaling to help free up the memory bus for other work. I don't have specific information about it though.
I see all of you guys point in one way or another. At this time I'm thinking about how easy it will be to access and tweak each component and power consumption management once they put all the pieces together. I know wifi components (at least from other hardware devices) have gone down in manufatcuring cost, as more different devices use them, however the whole damend for parts may bring the prices back up or at least push it towards the enduser. This is just an unarticulated thought of mine that I will make clear when I stop eating this chicken.
Ok. I just meant that I doubt that the MMSP2+ has three separate address/data busses coming off the chip in order to provide three external RAM banks. I could be wrong.
Does the MMSP2+ use the MBX (Lite) core?
Knowing GamePark, they planned at least 100.000 of XGPs because they were sure it will be the new uber-system.
Thanks for the prices of the i.MX31, so we now have $24 and $25 for that, but still have no prices for the MMSP2+. I assume you have these prices also and just forgot to quote on that part of the post?
SNES emulation on Nintendo DS is done at a compatibility hit because the 2D hardware of the DS just can't match the SNES exactly. Even then it's a much closer fit than standard 3D acceleration.
Accurate SNES emulation must be capable of rendering on a scanline basis. So you can't just blit a bunch of 8x8 blocks. I only see two ways around this. One is to blit 8x1 blocks, which are most likely not worth it because you have to set up too much in CPU for each tile (unless your GPU is capable of running shaders that can decode tilemaps). The other is to preprocess the maps to 2D bitmaps and composite them in hardware with full length strips (256x1). The problem with this approach is that it requires extensive tracking and caching management - if one tile of the background changes then you'll probably have to update at least significant portions of the background. The other problem is that it's a lot less cache friendly.
Then you have to consider that SNES supports subtractive blending, which may not be a feature of the 3D acceleration used. And if it's anything like GBA it'll have blending conditions, which would at least need sophisticated blend tests to handle, much more than what OpenGL offers.
I believe it was running fullspeed if not faster before frameskipping was even implimented in the emulator
Could be wrong though.
Hehehe. Still denying you're Epicenter?
At least you're trying to "behave" in this thread -- thanks.
Separate names with a comma.