Originally Posted by
hungryduck 
I noticed some framerate dips when playing Yoshi's Island. Can this be fixed?
At 480p mode? Which level?
I'm already aware of level 1-7 when you touch one of those swirlies that makes Yoshi run around like he's on LSD - that slows down massively - but the funny thing is that Snes9x's FPS counter stays put at 60/60fps, so could be emulator-related.
Not sure though.
Copy and paste from another forum: I will respond to dlanor's post some more later today, and he is of course totally right that it is an embarrassing leak. There are a couple of things about the way Snes9x deinitializes itself that are not entirely clear to me and the Porting document doesn't exactly address - I'll go over these issues later, as it's close to bedtime over where I live.
Basically, I tried to resolve this issue by doing some Snes9x callbacks after exiting the ROM, but this did not solve the problem.
Code:
Memory.Deinit(); //
S9xGraphicsDeinit();
S9xDeinitAPU();
This is the function that gets called when SNES9x is about to be started:
Code:
void start_snes9x(int videomode)
{
bool snes9x_loaded = false;
if (!(snes9x_loaded = init_snes9x(videomode))) {
Settings.Paused = TRUE;
}
int count = 0;
init_sound();
S9xSetSoundMute(FALSE);
memset(display, 0, color_buf[0].height * color_buf[0].pitch);
memset(display_back, 0, color_buf[0].height * color_buf[0].pitch);
while (is_running) {
read_pad();
if (!Settings.Paused) {
make_noise();
if (S9xSyncSound())
S9xMainLoop();
}
if (debug_text)
debugOutStr(100, 100, debug_text);
render(false);
}
if (snes9x_loaded)
Memory.SaveSRAM(S9xGetFilename(".srm", SRAM_DIR));
snes9x_loaded = false;
// With or without, this does not seem to fix the crash upon trying to load the fifth ROM into the emulator
Memory.Deinit(); //
S9xGraphicsDeinit();
S9xDeinitAPU();
is_running = true;
} My main sources of information on Snes9x are these two documents:
http://www.hackchina.com/en/r/70799/HOW2PORT.TXT__html
https://code.google.com/p/snes9x-gtk...s/porting.html
Interesting to note BTW is that (if you remove the ugly hack that makes it quit after having loaded the fourth ROM) if you load the fifth ROM and you have set Settings.DisplayFrameRate to TRUE, you will see the FPS display counter but it will lock up after that - so it gets to the emulator, it even does the S9xDeinitUpdate apparently, but it locks up after that.
Any ideas on how to debug this stuff properly given that we lack the Debugging Station?
I would like to state upfront that I am not the master programmer that guys like dlanor and byuu is. Writing something like bSNES or Open PS2 Loader is beyond my skills to be honest. All of my cumulative efforts has simply been in the spirit of being a proactive user that happens to take the effort to delve headfirst into something that might be beyond his capabilities. So far, the emulator has been progressing well, so forgive the really sloppy code and the really ugly hacks so far.
Snes9x Build 4.3.1 (With source)
Code:
CHANGES in 4.3.1:
* There's now a 720p build and a 480p one. This is only temporary until I find a way to manually set resolutions without the PS3 making its own inferences as to what resolution I would like based on the display settings toggled in PARAM.SFO.
* Got rid of a duplicate cellGcmFlush(); at the very start of the flip function - it should not be at the start of the function according to examples shown in the SDK. cellGcmFlush basically forces the RSX to process all the GCM commands buffered in the command buffer - however, in the same method, this function is already called after resetting the flip status. Since all of this has to do with V-syncing, if this should have any detrimental effects, I should have noticed it already since I'm very pedantic about screen tearing - doesn't seem to be the case.
* Made preliminary steps to sort out the PAL problems by allowing the user to load a ROM with the Triangle button that sets ForcePAL and the refresh rate to 50Hz. However, there should be a way to get at the region of the ROM using some sort of Snes9x function call without having to start the actual ROM that has been loaded. This way, I could set this automatically.
In any case, PAL ROMs still display wrong. More and more I'm starting to think this is a SNES9x issue since this only started occurring after I did the APU patches from snes9x-gtk (which were absolutely necessary as the sound was totally distorted and crackled in the first few releases, which was stock SNES9x 1.52).
Anyway, the latest build is a bit bigger in that I was forced to basically make two packages - one for 480p and one for 720p. I will have to do more research in how I can manually define resolutions without PARAM.SFO dictating which resolution should be the most ideal for me. For instance, if 720p/1080p is ticked and if I were to initialize a CellVideoOutState with resolution CELL_VIDEO_OUT_RESOLUTION_480, it would not switch the resolution back to 480p. I have found some SDK samples that might go some way towards demystifying this for me, but at the moment I had to resort to creating two separate PARAM.SFOs for both 480p and 720p.
All of this of course stems from my relative ignorance of the SDK at the moment and the fact that there is no real solid documentation besides the CHM that comes packaged with the 'leaked' SDK (the only other place that served as a developer venue, scedev.net, is locked down entirely - developers probably receive SSL certificates to visit certain login pages, because you don't even get to the SSL login page basically). Similarly, there's like zero libgcm documentation out on the Internet.
Anyway, in terms of functionality, I tested 720p mode and the results were much more favorable compared to 960x1080 upscaled to 1080p.
SNES9x PS3 - 1280x720 @ 59.94Hz (drawing/output resolution - 1280x720 )
Normal games (without special chips) - probably around 95% of all games: 60fps constant. Perfect
Cx4 games (Mega Man X2/Mega Man X3): 60fps constant. Perfect
SDD-1 games (Star Ocean): 60fps constant. Perfect.
DSP-1 games (Super Mario Kart): 60fps constant. Perfect.
SuperFX-2 / Yoshi's Island: A lot better than 960x1080, but still some frequent and irritating sound pops and slowdown. Snes9x's FPS counter says it stays at 60fps, but you will see otherwise.
Something strikes me the reason why SuperFX games seem to suffer in terms of performance on PPC is because on x86 systems there is the option to compile Snes9x with a SuperFX assembler core that was (if I read correctly) written by zsKnight (zsNES).
SuperFX-1 / Star Fox: Heavy sound pops and what appears to be slodown, yet FPS counter stays at 60fps. It's still laggy at 480p mode.
SA-1 / Super Mario RPG: 60fps constant (only played brief intro sequence with Bowser - might have to test further, but looks good so far.
Seiken Densetsu 3: 60fps constant
Secret of Mana/Seiken Densetsu 2: 60fps constant.
Anyway, there is a lot still left to be done. At the moment, the screen is basically taken raw from Snes9x's GFX.Screen memory buffer - using libgcm, there should be some method to resize it (but haven't found anything so far). Perhaps a solution would be to go with PSGL (which is OpenGL ES built on top of libgcm, so really an abstraction layer) - since libGCM is really low-level and might be too esoteric at the moment.
Another problem I have been experiencing is with Seiken Densetsu 2/Secret of Mana and Seiken Densetsu 3. This problem is by far more serious with Seiken Densetsu 3 - what it does is switch to 512x448 (hi-res interlaced mode) whenever it renders text to the screen or whenever it enters a menu. At the moment, 512x448 screens are not aligned well with the way 256x224 are normally aligned on the screen, so what happens is that this screen gets rendered ontop of the 256x224 screen, then instead of 'blanking' the previous frame, it simply stays there (sometimes blinking) until the next time it renders a 512x448 screen.
Obviously, the solution to that would be to do a blanking of the screen as soon as it's rendered and output - Snes9x has a callback called ContinueUpdate, which is specifically intended for these high-res screens (512x448). There is also another callback, called DeinitUpdate, that gets called whenever a 256x224 screen has been stored in GFX.Screen and can be outputted to the screen. Any ideas there? I haven't really seen any implementations from other Snes9x ports dealing with this specific issue - perhaps take another look at the snes9x-gtk source?
Reply With Quote
as someone cleverer than me would probably have implemented it before I got it working !