[gpsp] Exophase Has Done It Again! Incredible!

[starpause]

Ohh I'm going to have to test Sonic Battle now! I forgot about that one!

how did it fare? it's one of the few games i've got a cart and sp around for

 

[Exophase]

Basically I got zodttd to agree not to touch the code for 2 weeks while I worked on it.

Stuttery sound means it isn't running fullspeed (ie, a "logical" 60fps, although frame skipping may be on), it isn't really a separate issue. There isn't anything that can be done to improve this, if the audio thread has nothing to play it'll have to wait for there to be something from the emulator, and if the emulator isn't running fullspeed it'll eventually fall behind.
Changing from auto to manual frameskip would help simply because the auto frameskip doesn't work correctly right now.

Of course different games and different circumstances will perform differently. A lot of blending on screen or affine transformations (especially with backgrounds or several large sprites) will cause a much greater load. Higher frameskip diminishes said load, of course.

Hopefully by the time the dynarec is more optimized and IWRAM code thrashing is handled more efficiently (some games do this) most games will run fullspeed with high enough frameskip. Improving video render speed is another issue entirely. I don't know if much can be done for the C code to make it faster, at least not in interesting cases (fade performance can probably be improved but they're hardly used). Me and zodttd are going to look at the ASM the compiler generates for a few functions and see if there are any obvious improvements that can be made.

 

[cowai]

I'm always smiling reading these posts..
A quick question: Will rewriting some code into arm asm be a huge speed boost? Or is this some super optimized C code that wont get better?

Awesome work, really cool to hear that FF6 is now working/better, as I read some whining about it on some forum...

 

[DaveC]

Stuttery sound means it isn't running fullspeed (ie, a "logical" 60fps, although frame skipping may be on), it isn't really a separate issue. There isn't anything that can be done to improve this, if the audio thread has nothing to play it'll have to wait for there to be something from the emulator, and if the emulator isn't running fullspeed it'll eventually fall behind.
Changing from auto to manual frameskip would help simply because the auto frameskip doesn't work correctly right now.

That makes sense. I guess it is just the way the emu handles the sound or maybe the way the GBA does it's sound then is that true?

I notice that in DrPocket SNES (and some other emus as well) even when the framerate drops in some games the sound will not stutter, it remains pretty consistant. Is that maybe because of a difference in the way the SNES and GBA handle sound?

Thanks again for the great work on this. It is pretty impressive.

 

[purple_goat]

So glad to see that the emu hasn't been left alone (as I was afraid of)

If this was a move it would be an action movie/porn

 

[Blah]

I notice that in DrPocket SNES (and some other emus as well) even when the framerate drops in some games the sound will not stutter, it remains pretty consistant. Is that maybe because of a difference in the way the SNES and GBA handle sound?

Since the SNES' sound is done by a dedicated chip, the sound thread can run mostly independant of the CPU. So they gave the sound thread higher priority. It will slow down if the CPU gets bogged down but it will not stutter. This is not possible on the GBA becuase, like the GP32, much of the sound processing is handled by the CPU (though the GP32 is a more extreme case).

 

[Exophase]

Stuttery sound means it isn't running fullspeed (ie, a "logical" 60fps, although frame skipping may be on), it isn't really a separate issue. There isn't anything that can be done to improve this, if the audio thread has nothing to play it'll have to wait for there to be something from the emulator, and if the emulator isn't running fullspeed it'll eventually fall behind.
Changing from auto to manual frameskip would help simply because the auto frameskip doesn't work correctly right now.

That makes sense. I guess it is just the way the emu handles the sound or maybe the way the GBA does it's sound then is that true?

I notice that in DrPocket SNES (and some other emus as well) even when the framerate drops in some games the sound will not stutter, it remains pretty consistant. Is that maybe because of a difference in the way the SNES and GBA handle sound?

Thanks again for the great work on this. It is pretty impressive.

Yeah, GBA is primarily streaming audio while SNES is purely sequenced audio. However, dropped frames doesn't mean that the emulated speed is below full speed, so to speak. Rather, the frames are dropped to prevent this from happening, so one frame from the game's perspective is still taking as long as it should, and hence everything is synchronized to real time although some frames aren't being rendered. On the SNES video rendering is very expensive, whereas CPU emulation is not nearly as much so (but sound is somewhat) so frame skipping can make a tremendous difference. But keep in mind that every additional frame skipped saves you less and less overall time, and it hits diminishing returns pretty quickly. If you don't hit ideal speed within 4 frames skipped you probably won't ever.

For platforms with sequenced audio, if you don't hit full speed/synchronization with the machine then it's possible for the sound to not stutter, but to play more slowly. On emulators for NES, SNES, Genesis, SMS, PS1, etc it may sound like someone slowed the music down, but the notes themselves will still play at the correct pitches because the sound hardware performs that. The commands to play things will just come at incorrect intervals.

 

[cowai]

Exophase: Does the gp2x's arm cpu give us an advantage without virtualisation? Or will the psp have greater advantage in having more registers?

Mario Kart!

 

[sam fisher]

Exophase: Does the gp2x's arm cpu give us an advantage without virtualisation? Or will the psp have greater advantage in having more registers?

Mario Kart!

I too wonder if ARM --> ARM translation provides a better turn around than ARM --> MIPS?

 

[fusion_power]

Yeah, GBA is primarily streaming audio while SNES is purely sequenced audio. However, dropped frames doesn't mean that the emulated speed is below full speed, so to speak. Rather, the frames are dropped to prevent this from happening, so one frame from the game's perspective is still taking as long as it should, and hence everything is synchronized to real time although some frames aren't being rendered. On the SNES video rendering is very expensive, whereas CPU emulation is not nearly as much so (but sound is somewhat) so frame skipping can make a tremendous difference. But keep in mind that every additional frame skipped saves you less and less overall time, and it hits diminishing returns pretty quickly. If you don't hit ideal speed within 4 frames skipped you probably won't ever.

For platforms with sequenced audio, if you don't hit full speed/synchronization with the machine then it's possible for the sound to not stutter, but to play more slowly. On emulators for NES, SNES, Genesis, SMS, PS1, etc it may sound like someone slowed the music down, but the notes themselves will still play at the correct pitches because the sound hardware performs that. The commands to play things will just come at incorrect intervals.

Yes, try my Metroid Fusion Savegame. In slow Areas, the sound is a little bit broken because of this issue. (I think it's called "Raster effect" what kills the most FPS in GBA games like animated Water whobbling or heat flirring over the whole screen)
When not much happen ingame, FPS increase and Sound is ok. I only tested everything with FS 1 manual, because FS 2 manual is to slow and choppy for my taste (yes, and auto is nearly useless )
But why is there no FPS increase, when I turn Sound OFF? I didn't notice a big difference while playing unlike in other Emulators -Strange.

 

[Exophase]

Yes, try my Metroid Fusion Savegame. In slow Areas, the sound is a little bit broken because of this issue. (I think it's called "Raster effect" what kills the most FPS in GBA games like animated Water whobbling or heat flirring over the whole screen)
When not much happen ingame, FPS increase and Sound is ok. I only tested everything with FS 1 manual, because FS 2 manual is to slow and choppy for my taste (yes, and auto is nearly useless )
But why is there no FPS increase, when I turn Sound OFF? I didn't notice a big difference while playing unlike in other Emulators -Strange.

gpSP uses a purely scanline based rendering engine, so raster effects come for free. Those areas probably use heavy color effects which weighs the engine down.

Sounds off doesn't improve anything because it doesn't really turn anything off. It just writes zeros to the audio. It was added so people could play other audio in the background (on PSP), not to improve performance. Even if certain sound related things were turned off it wouldn't offer much improvement because most of the audio rendering on GBA is done by the CPU then streamed to the audio chip via DMA.

For the others asking, yes, ARM->ARM translation offers benefits over ARM->MIPS, although the extra registers is in MIPS favor. The MIPS immediate format also occasionally benefits it (and occasionally hurts it).

 

[Tobriand]

I must admit I was wondergin how on earth Gpsp was the only emu where if you turn load a savestate saved when sound was switched off, and turn sound back on, it actually does turn on. Very rare to get that (though cool) - now it makes sense

 

[sam fisher]

I was wondering that aswell Explains it fairly well What do I mean "fairly well", it provides definitive proof lol

 

[whiskthecat]

Does anyone's stop randomly after about 10mins of gameplay? It might be a bad bios?

 

[FarazParsa]

Damnit, Zotdd, are you TRYING to give us heart attacks?

 

[zodttd]

Exophase is keeping us all in suspense.
No new news yet.

I'll fill some space with some news that Unai, Exophase, and I spoke and we were discussing video rendering on gpSP and the psx4all dynarec. In a weird swap Unai is taking a look at the video rendering, and I'm taking a look at the psx4all dynarec again and see if I learned enough from gpSP to help with that project. Even if psx4gp2x doesn't work well enough on the gp2x, the psx4gp2x port might still be useful afterall.
I just compiled psx4all and there's a lot of work to do but I suppose that's a good thing. If I looked at it and didnt see anything I'd think would improve things, then I would of hit a bad wall in the projects development.
Although I'll be working on psx emulation again, it won't be at the same fast pace as most high priority projects of mine. But I'll keep everyone updated as needed.

More news as it comes.

 

[shinneri]

Although I'll be working on psx emulation again, it won't be at the same fast pace as most high priority projects of mine. But I'll keep everyone updated as needed.

:wub: :wub:

 

[sam fisher]

Hopefully when GPH release a new GP console, PSX4ALL will run full speed on it

 

[cowai]

Everythings perfect!

 

[Khan]

I'll be working on psx emulation again

Dosbox, GBA, Mega-CD...
2007 it´s truly gonna be a great year