I updated the core in snes9xbox to the latest on the SVN (1.53 whatever)..

Anywho the port went fairly well. But there are a few issues I was hoping to possibly get suggestions on.

1) Speed is a bit slower in some games.

In particular SMW2, and SM_RPG whereas they ran in a previous version of snes9xbox just fine. I presume this is due to no more ASM code. However what concerns me is they run at a perfectly decent speed on the Wii. So I'm wondering if I missed something optimization wise.

2) I activated the NTSC filters, however they are a bit of a speed killer as well. Is there anything I can do with these?

Thanks

_________________
Xtras! We do the systems others dare not!

1.)
The wii port does not include the latest changes to the SA-1 core / IRQ code (i.e. commit 82435ab5db52b5e523951aa278fbc3ddc25cc173).
This might give you some performance.

2.)
The NTSC filter is very cpu intensive, I don't think you can do very much about that (other than hoping that someone creates a shader that does the same).

Whoops.. sorry I should have mentioned that. I noticed they backed out of the SA-1 core / IRQ code changes for performance reasons and that was one of the first things I did. Looking at that I noticed the ZSnes ASM core was removed. I gather the Wii port does not even use that right?


Drat.. I was hoping someone wouldn't say that... But from my experience of implementing an NTSC filter in atarixlbox (aka Atari 5200 and 8-bit machines) it was a noticeable performance hit.

_________________
Xtras! We do the systems others dare not!

The Wii has a PowerPC cpu, so it wouldn't even be able to use the x86 asm.
Only the SuperFX and C4 asm cores were remaining in 1.52, and the official ports did not use them / no one was maintaining them.

They might give you a speed up in SMW2, but SMRPG uses SA-1 which lost its asm some time after 1.43.

Crap.. I was afraid you were gonna say that. Ok well thanks for the info. I'll see what I can drum up based on that.

_________________
Xtras! We do the systems others dare not!

ok. Well I managed to get 1.52 working with the SuperFX and C4 ASM cores. Took a little bit of finagling to get it to compile but it finally did. So SMW2 seems to run a fair bit better. Also threw in the EWJ 2 sound fixes too boot. Plus for some reason SM RPG seems to be going at a fair speed as well. In fact I noticed some mistakes I made when doing the svn (1.53 whatever) so I might go back over that one again with those changes just to see how it performs.

Had a bit of a scare there when I noticed the messed up background tiles in Donkey Kong Country.. but I found the fix in the fix4 fix.. fix.. fix..

NTSC filters still pretty much suck but they do run pretty fair on PAL roms.. (talk about iron).

_________________
Xtras! We do the systems others dare not!

I know this is a rather odd question but is there anything used by snes9x core that I can temporarily dealloc when emulation is paused, and then reallocate without affecting the currently running game?

Thanks..

_________________
Xtras! We do the systems others dare not!

ok now for a question a little more in the "sane" realm. I've set up the sound for the xbox to run off of the callback and for the most part it works really well with soundsync on and autoframeskip set to max.

However on games where the framerate drops a lot (typically special chip games) the sound gets a little choppy. Is there anything I can do to help reduce this choppiness? Or am I pretty much out of luck? I've tinkered around with different ideas to no avail. It'd be nice to get it to just run a little more smoothly in these slowdown situations.

Thanks.

_________________
Xtras! We do the systems others dare not!

Probably not. The state of the game involves all of the memory used by it and where in the emulation cycle the game currently is. If there's a value in memory anywhere it's probably going to be used again, and there's no good way to know what isn't going to be needed any more. It's possible that there's a minimal audio buffer or something like that which could be dealloc'd without issue, but it'd be pretty minimal. You'd have to write the memory contents to storage before dropping it - which is pretty much what save states do anyways. If you really needed to, you might be able to finagle something that wrote a save state, and then resumed from state when you wanted to play again.

As for the framerate drops ... there may be something, but it's possible there isn't much. Sound stuttering in that instance is a result of the computer not emulating the hardware fast enough to fill the audio buffer. There's just not enough sound being made to play back without gaps. You could try increasing the buffer size and decreasing the output rate.