latest svn on xbox questions

This is for people involved in the developement of Snes9x, or SNES emulators in general.
BUG REPORTS BELONG IN TECH SUPPORT/BUG TRACKING!
Post Reply
Madmab
Snes9x White Belt
Posts: 27
Joined: Wed Apr 13, 2011 9:06 am

latest svn on xbox questions

Post by Madmab »

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!
User avatar
OV2
Official Win32 Porter/Dev
Posts: 679
Joined: Thu Aug 30, 2007 10:15 pm

Post by OV2 »

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).
Madmab
Snes9x White Belt
Posts: 27
Joined: Wed Apr 13, 2011 9:06 am

Post by Madmab »

OV2 wrote: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.
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?
OV2 wrote: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).
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!
User avatar
OV2
Official Win32 Porter/Dev
Posts: 679
Joined: Thu Aug 30, 2007 10:15 pm

Post by OV2 »

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.
Madmab
Snes9x White Belt
Posts: 27
Joined: Wed Apr 13, 2011 9:06 am

Post by Madmab »

OV2 wrote: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. :D
Xtras! We do the systems others dare not!
Madmab
Snes9x White Belt
Posts: 27
Joined: Wed Apr 13, 2011 9:06 am

Post by Madmab »

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). :lol:
Xtras! We do the systems others dare not!
Madmab
Snes9x White Belt
Posts: 27
Joined: Wed Apr 13, 2011 9:06 am

Post by Madmab »

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!
Madmab
Snes9x White Belt
Posts: 27
Joined: Wed Apr 13, 2011 9:06 am

Post by Madmab »

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!
SparroHawc
Official Android Porter
Posts: 303
Joined: Mon Feb 07, 2011 9:20 pm
Location: All up in your business

Post by SparroHawc »

Madmab wrote: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..
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.
Post Reply