Emulators Optimization

[ahahah]

hi

i've just wondered if existent emulators are programmed just to be sufficient to run games without worried about optimization of code for better speediness and smoothness, or are they optimized?

thanks for answers

 

[Mr B]

Right now we are mainly looking at "best effort" ports. Not said as disrespect, but stating the obvious. Everyone has pulled arse, to get something out there, that will do the job, to please the crowd. As time goes they will go back and optimize code where needed. Somehow i don't think there will be as much effort put in to optimizing 8-bit NES as 64-bit, since the 8-bit one would play smoothly pretty much no matter what. If we are really lucky, someone goes back to small and low impact emulators, and optimize them while thinking it's going to improve battery time, but somehow i think they will put more demanding emulators higher up on the todo list, so to speak.
B!

 

[CPUnltd]

I'm assuming Mr. B's explanation will probably be most accurate.

slightly off-topic, I wonder if anyone has put together a list for currently working emulators stating the rough battery life you would get from playing JUST that emulator. if it's there somewhere, a link would be nice... if not, it would be cool for someone to compile this info for future reference... would also be nice to have to look back on and keep track of for optimization efforts... just a thought.

 

[fusion_power]

At the Moment, underclocking or overclocking does not have a huge effect to the Battery life. So it seems not that high priority to optimize programs to save some MHz. Even if a program does only run overclocked, it has not a huge Battery drain. So I guess the motivation for coders to squeeze out the last bit of speed fromj their stuff has not top priority.

BUT I guess in the future, things could change if the Firmware supports the full power-saving features of the OMAP Processor. Maybe then it could make a big difference in battery life when a game can run with only 150MHz instead of 500MHz. At least, I hope so.

And to be honest, It is not really an art to have a Pac-Man like game that needs 600MHz to run smooth. :lol: Nobody needs to optimize his stuff to death but maybe sometimes it couldn't hurt to spend some hours and speed up some things if possible When I see what was possible onto older and younger Consoles/Handhelds that are all less powerful than the Pandora and "translate" this potential 1:1 to our Handheld, I'm sure we not even touched the surface of what could be possible with 500+ MHz and all the Stuff into the Pandora Chips.

 

[Letalis Sonus]

Even if a program does only run overclocked, it has not a huge Battery drain.

You're mixing things up. The whole discussion about different clocks not having any influence on the battery drain is about idling, but putting the CPU on heavy load on different clocks is a completely different story. If something only runs when the CPU is overclocked, it obviously stresses the CPU even more which means it will drain more energy.

 

[Prometheus]

Somehow i don't think there will be as much effort put in to optimizing 8-bit NES as 64-bit, since the 8-bit one would play smoothly pretty much no matter what.

NesEmu currently requires overclocking to 850MHz to run at full-speed. (Curiously, the speed the PND recommends is 600MHz, but this is actually too slow.)

 

[fusion_power]

Even if a program does only run overclocked, it has not a huge Battery drain.

You're mixing things up. The whole discussion about different clocks not having any influence on the battery drain is about idling, but putting the CPU on heavy load on different clocks is a completely different story. If something only runs when the CPU is overclocked, it obviously stresses the CPU even more which means it will drain more energy.

Of course it drains more energy but not so to much I guess. increasing the CPU at the factor 1.5 does not automaticly mean it also drains the batery at this factor.

 

[b._.o._.b]

I am not very concerned about the general status (performance, compatibility) of the emulators. GP2X has shown that emulators tend to become better and better as long as there are some devs that care enough about the platform.
There are quite some great devs busy porting and polishing great stuff for the Pandora. Power to them

The problem is imo how and what everybody is porting. Why isn't GMenu2X used as UI? This would be excellent for the Pandora. Let the devs create command line capable emulators and Gmenu2X does the rest. Wouldn't it be great to have GMenu2X to start your NES, SNES, gameboy, MSX, C64, ST, Amiga, PSX etc roms and savestates.

GMenu2X can do it, and a lot of emulators are already capable for command line input. Devs don't need to create a fancy UI and they can spend their time optimizing.
It will make the Pandora feel a lot more integrated and user friendly.

 

[emcee]

NesEmu currently requires overclocking to 850MHz to run at full-speed. (Curiously, the speed the PND recommends is 600MHz, but this is actually too slow.)

Which I guess makes PocketNES seem that much more amazing. Full speed NES emulation with sound on the GBA's 16.78MHz processor.

 

[ahahah]

NesEmu currently requires overclocking to 850MHz to run at full-speed. (Curiously, the speed the PND recommends is 600MHz, but this is actually too slow.)

it's a bit pity.
we have a console potentialy more powerful than many others, and we have to overclock it (what about the warranty if any overclock problem) to run an emulator of a machine that can be run easily on other consoles.

 

[Exophase]

Which I guess makes PocketNES seem that much more amazing. Full speed NES emulation with sound on the GBA's 16.78MHz processor.

Not a fair comparison because on GBA it doesn't need to render pixels to the screen. For video it just has to translate NES tiles and sprites to GBA tiles and sprites, which works out without very much overhead. It does the same thing with sound (where a few deficiencies actually do appear). PocketNES still has a nice ARM ASM CPU interpreter, though.

In conventional NES emulation the PPU takes way more time to emulate than other things. The exact amounts can vary based on how accurate the emulator is.

But I don't know why NesEmu is so slow, it doesn't look like it's on the bleeding edge of accuracy or anything (but of course it's not nearly as optimized for ARM, or in general, as notaz's FCEU work has been)

 

[Loon]

From a personal viewpoint I find the current state of the emulators on Pandora pretty amazing.

Considering there are less than 1000 units in the wild, the work done by the devs is awesome. Just wait until the user base is 10,000 strong.

If things develop as they did for the GP2X then it won't be for a couple of years that we see what the Pandora is really capable of.

 

[CPUnltd]

I'm just looking forward to the time we have full hardware access as far as raw power goes... roughly translated, I am under the impression that we are lacking software of various types to truly unlock the power of the Pandora (in other words, it still has most of it's 'limiters' on)... so once we get past that point, things will be MUCH more interesting...

 

[Mr B]

I'm not really aware of any limiters that are in place. While a few things are still out of reach, none of these things have really been put in place to limit the device capabilities, the lack of ability is to be blamed on poor development tools. Mainly then, the SDK. But this was perhaps what you were hinting at?
B!

 

[CPUnltd]

I didn't mean it in the respect of the device being purposely limited... my choice of words could have been better, but my mind was on anime at the time I was writing that post, so 'limiters' was the appropriate term for that moment. I wouldn't say the development tools are poor... just, well... under-developed. And that's not to say that OP is doing a bad job, just that they haven't "unlocked" all of what the hardware is capable of yet. Again, I have to emphasize that all developers have done phenominal given the fact that the hardware isn't being fully implemented. To have so much and be so capable while not being maxed out physically is a great accomplishment. I'm just one who wonders and imagines what the Pandora will be like once it's at "full power"... subsequently, I wonder how that will effect things like battery life... Didn't wanna "piss on my own parade" per-say, but had to be honest on that one.

 

[WizardStan]

And that's not to say that OP is doing a bad job, just that they haven't "unlocked" all of what the hardware is capable of yet.

eh, not really. The only thing not being used yet is the DSP, and I'm not sure there's a lot it would do to speed up emulation. That's not to say there isn't room for improvement, just that it will come in the form of software fixes, nothing to do with hardware acceleration or whatever you want to call it.

 

[ahahah]

And that's not to say that OP is doing a bad job, just that they haven't "unlocked" all of what the hardware is capable of yet.

eh, not really. The only thing not being used yet is the DSP, and I'm not sure there's a lot it would do to speed up emulation. That's not to say there isn't room for improvement, just that it will come in the form of software fixes, nothing to do with hardware acceleration or whatever you want to call it.

so how do you explain this prometheus quote:

NesEmu currently requires overclocking to 850MHz to run at full-speed. (Curiously, the speed the PND recommends is 600MHz, but this is actually too slow.)

whereas some consoles that are less powerful than the pandora run the nes emulator more easily?

 

[Prometheus]

^ I'd say the explanation for my quote is pretty obvious: NesEmu is probably not very well optimised for ARM. I'm not too sure what that has to do with what Stan said.

I'm only not using GPFCE, which is, I'm guessing, far more optimised, because I don't much like the non-toggleable 2xSaI-style graphical filter that it currently has. Once that's gone, I will drop NesEmu in a heartbeat, because it's given me a ton of hassle.

 

[WizardStan]

so how do you explain this prometheus quote:

NesEmu currently requires overclocking to 850MHz to run at full-speed. (Curiously, the speed the PND recommends is 600MHz, but this is actually too slow.)

whereas some consoles that are less powerful than the pandora run the nes emulator more easily?

I don't see how the two are mutually exclusive. The NES emulator probably doesn't have a dynamic recompiler for the Pandora yet, which means it is doing emulation in the slowest possible way. Nothing magic about the hardware is going to change that, just someone taking the time to write an ARM recompiler.

 

[Exophase]

so how do you explain this prometheus quote:

NesEmu currently requires overclocking to 850MHz to run at full-speed. (Curiously, the speed the PND recommends is 600MHz, but this is actually too slow.)

whereas some consoles that are less powerful than the pandora run the nes emulator more easily?

You're comparing different emulators. To start with, they aren't all emulating exactly the same thing... some are more accurate than others, and more accuracy dan require more overhead.. either the overhead goes up a lot or the complexity of the emulator goes up a lot, and usually it's some amount of both.

But the real issue here isn't accuracy, because as far as I can tell NesEmu isn't that accurate as far as NES emulators go. It's just an inefficient emulator, and possibly an inefficient port. That it needs > 600MHz is rather astonishing since it doesn't look THAT inefficient, but sometimes little things can come up that will surprise you. It needs to be profiled to really discover what's going on. It isn't the Pandora hardware that's holding it back. If you took an equivalent port and ran it on the Wiz it'd almost definitely run much worse and have no hope of achieving full speed.

DSP could probably speed up a lot of emulators if you decouple video emulation from CPU emulation and put the former on the DSP, but doing this is difficult and requires a bunch of deep queues, where it's even possible. There are few platforms where this would be necessary, even PS1 should achieve good baseline speeds w/o resorting to something like this.