rockdoom question

[everett1911]

I was wondering, is there any possible way to listen to music while playing rockdoom?

because as soon as I launch rockdoom from the plugins menu, all music stops playing (aside from the radio, though it also stops when you start the game) and it's kinda annoying.

my mp3 player is a iriver h10 5gb. would it have anything to do with this?

[AlexP]

Nope, Rockdoom requires too many resources to be able to play music at the same time.

[josh.e]

Well ummmm... what would be the stipulation to rockboy i know the reasoning for a nonexisting rockboy for gba is not enough memmory can music be ran in background of current rockboy or can we step up the RAM

[torne]

The limiting factor is not really memory but processing power; running Rockboy stretches the CPU on almost all of the supported players to the limit (and beyond, in fact, which is why it doesn't run many games at full speed on most of them). Playing music in the background as well would need even more CPU power.

The GBA would require even more processing power; many of the targets have enough memory for it, but are far from being fast enough.

[kkurbjun]

To follow on torne's response:

Rockboy does allow music to continue while playing a game on the Gigabeat F/X as long as the ROM is small enough to fit in the plugin buffer. 

Other targets do not have enough processing power for this feature.

Fullspeed GBA 'emulation' could be possible on most/all of the ARM targets since the code could partially be executed natively, but it would require writing an 'emulator' from scratch.

-Karl

[saratoga]

Processing power and also not being able to share IRAM between the codec and plugin.

[torne]

Fullspeed GBA 'emulation' could be possible on most/all of the ARM targets since the code could partially be executed natively, but it would require writing an 'emulator' from scratch.

No, not really, I'm afraid; the GBA's processor is a minor part of the problem, it's only a 16Mhz ARM7TDMI crippled by a slow 16-bit external bus with a large number of wait states. The big problem with GBA emulation is the 2D graphics hardware, which is spectacularly powerful for such a tiny system and requires the majority of the processing time when emulating it on a PC.

Using native execution of instructions gains you very little, because you'll have to stop executing them natively *very* frequently every time there is a peripheral register read/write, and this happens *constantly* because of the heavy dependence on accelerated hardware. The actual CPU is idle a lot in most games.

[kkurbjun]

Processing power and also not being able to share IRAM between the codec and plugin.

That too, I had forgotten about that part.

Using native execution of instructions gains you very little, because you'll have to stop executing them natively *very* frequently every time there is a peripheral register read/write, and this happens *constantly* because of the heavy dependence on accelerated hardware. The actual CPU is idle a lot in most games.

I agree that the video emulation would take a significant amount of processor time, but the CPU is still a significant contributor in games (at least in gpsp) (http://gpsp-dev.blogspot.com/2007/04/profiling-performance_02.html). 

Igpsp was able to get 50-80% full speed at 81 MHz on the Ipods (http://ipodlinux.org/wiki/Igpsp), so with significant work on the CPU I still think it /could/ be possible to get at least some games running full-speed (probably without sound).  The effort required to do so would be tremendous though.

[torne]

Hmm, that's interesting. A lot of games that I've looked at don't actually idle the processor, which doesn't help I guess: they sit busy-waiting on a variable which will be set by an interrupt handler. The emulator will have to emulate this because it's difficult to recognise that it's pointless.