Hacking [Plugin]SNES Emulator ver1.05 for DSTWO

[9th_Sage]

Actually, except for a couple of weird (interleaved) formats the only difference is how the header is formatted. Back in the old days, many backup units had their own header format so you needed to use a tool like ucon64 to convert between them. Fortunately, most emulators (including NDSSFC) don't care about the header at all. Of course, if you have a problem with a ROM you can always try stripping the header (use ucon64 -lsv romname.smc to see if there is a 512 byte header and if so, use ucon64 -stp romname.smc to remove it).

Interleaving is another story altogether. @_@ I *think* any decent (recent) ROM auditing tool will either flag or deinterleave games that are interleaved at least. Another good and easy one for messing with headers is NSRT, btw. Especially if a person would rather use a GUI interface.

 

[campbell00]

Can anyone confirm that the games are ALL running on frameskip? I don't see any options to change it, and yet the games run nowhere NEAR as fluid as they should. It's not lag that's doing it...

 

[YayMii]

Can anyone confirm that the games are ALL running on frameskip? I don't see any options to change it, and yet the games run nowhere NEAR as fluid as they should. It's not lag that's doing it...

What do you have your 'CPU frequency' setting on? Because a lot of my games don't have any frameskip (my CPU frequency is set to 4).

 

[Covarr]

For a first release it's pretty good, I tried Chrono trigger
If you've got a DS, and you've got a flash cartridge that plays commercial ROMs, why on earth would you emulate Chrono Trigger? The DS port was REALLY DAMN GOOD.

QUOTE(Rankio @ Sep 10 2010, 08:47 PM) I don't know why they can not resize the screen correctly. You can have the same SNES aspect ratio but adding black bars to the sides.

The performance hit would be greater, as copying from one buffer to another would have to go pixel-by-pixel, vs the line-by-line they are doing now.

Let me give the world a little lesson about SNES aspect ratio:

The SNES renders at a resolution of 256x224. With square pixels, that would be an 8:7 aspect ratio. The only thing is, the games were never meant to have square pixels. The SNES was designed to output to a television, which would display non-square pixels, stretching the games to fit its 4:3 aspect ratio. Game developers knew this, and so all the art, assets, etc in a game was intended to be stretched in this manner.

The DS renders and displays at a resolution of 256x192. It has square pixels, and an aspect ratio of 4:3, same as a TV. A SNES game has to be squished and lose some pixels to display on a DS, but it's the right aspect ratio. Cropping the top and bottom is a LESS accurate image in that regard.

Any questions?

 

[nl255]

Can anyone confirm that the games are ALL running on frameskip? I don't see any options to change it, and yet the games run nowhere NEAR as fluid as they should. It's not lag that's doing it...

What do you have your 'CPU frequency' setting on? Because a lot of my games don't have any frameskip (my CPU frequency is set to 4).

Same here and while the frameskip is much less, it is noticable in some cases such as All-Stars. If there are any games that require precise timing to do certain things (such as Mother 3 combos or other games with timed hits) it will be much harder if not impossible. Keep in mind that almost all emulators have input lag even without frameskip (so good luck with Mother 3 combos on any GBA emulator). Until the emulator gets speedhack support I would stick with slower moving games, such as RPGs. On the bright side, except for Star Ocean (and yes, I tried the 12MB uncompressed version) all of my favorites from Japan work fine, including SMT.

 

[9th_Sage]

A note to anyone wanting to play Terrenigma (the english European version): It seems the emulator doesn't handle PAL all that well (at least Terrenigma seemed to play music a bit fast to me). Use the NTSC patch you can find on romhacking.net and this will not be a problem.

I was also wondering if anyone got the decompressed SDD-1 free version of Star Ocean to work on this version of the emulator. It sounded like it DID work previously, but I can't get it to work on this release version.

 

[DiscostewSM]

I don't know why they can not resize the screen correctly. You can have the same SNES aspect ratio but adding black bars to the sides.

The performance hit would be greater, as copying from one buffer to another would have to go pixel-by-pixel, vs the line-by-line they are doing now.

Let me give the world a little lesson about SNES aspect ratio:

The SNES renders at a resolution of 256x224. With square pixels, that would be an 8:7 aspect ratio. The only thing is, the games were never meant to have square pixels. The SNES was designed to output to a television, which would display non-square pixels, stretching the games to fit its 4:3 aspect ratio. Game developers knew this, and so all the art, assets, etc in a game was intended to be stretched in this manner.

The DS renders and displays at a resolution of 256x192. It has square pixels, and an aspect ratio of 4:3, same as a TV. A SNES game has to be squished and lose some pixels to display on a DS, but it's the right aspect ratio. Cropping the top and bottom is a LESS accurate image in that regard.

Any questions?

You are correct, but you are not understanding Rankio's suggestion. He's talking about the aspect ratio of the SNES, not the aspect ratio of the TVs back in the day. He suggested squishing the display horizontally so that it matches the internal 8:7 ratio the SNES displays at (he made sure to include adding bars to the sides in his post for clarification). Most people nowadays that play SNES games are not playing on an actual SNES, but an emulator that is played on a system who's display doesn't take into account a TV's aspect ratio.

My response was that it would create a performance hit because the number of operations to handle the same amount of data would be much greater. As it is right now with Display Mode 0, it repeats the copying of a block of 6 pixel lines (256 pixels each), which is about 1536 pixels a go while skipping a full line of pixels. With trying to achieve the SNES aspect ratio via software, copying would be forced to about 6 pixels per go while skipping one pixel alongside for each line being copying from the earlier example. The amount of data having to be copied shows the latter method as less, but because of the great inclusion in CPUs known as Block Copying, large chunks of sequential data become faster to copy because of no need to stop as often when skipping a set of data. An example would be that in the amount of time it took to copy 6 pixels (12 bytes in this case), the version of copying 48 bytes could take just as much time, possibly less because it was optimized to handle large amounts of data. We could go into further detail, such as problems when copying from a non 4-byte aligned memory location, but no one needs to know that stuff.

 

[SpaceJump]

Played through the complete Super Metroid and it's perfectly finishable. No layer issues (even in the fight against Draygoon). Now if it ran smooth it would be perfect. In some of the later rooms in lower Norfair the framerate really goes down.

 

[Glitchy]

In game save Vs real-time save states

Basically I am using my DSTwo SNES emulator to play Super Metroid and as we all know this game has an in game save function. The emulator has the facility for real time save states, however, I noticed that the emulator automatically loads the most recent real time save state when a game is loaded up and if this is before the latest in game save then the in game save is over-written and lost - Is this the intended functionality or am I doing something wrong?

Glitchy

 

[dhjohn]

I just noticed this, and if someone can prove me right or wrong that would be great (can't do too much testing as I only have two games), but it seems like the emulator auto loads the last save state if you load it from the Recently Played Games list, but does not if you load it from Select Games. If this is true, it would be very useful to people (like me) that use save states every once and a while, but mostly stick to the in game saving.

 

[9th_Sage]

I just noticed this, and if someone can prove me right or wrong that would be great (can't do too much testing as I only have two games), but it seems like the emulator auto loads the last save state if you load it from the Recently Played Games list, but does not if you load it from Select Games. If this is true, it would be very useful to people (like me) that use save states every once and a while, but mostly stick to the in game saving.

Yep. If it's in the Recently Played menu and you've got a save state, it automatically loads the highest numbered save state you've got saved. I've used it that way a few times, I'm glad it doesn't do it except when you go to the Recently Played menu.

Works better that way.

 

[Covarr]

I don't know why they can not resize the screen correctly. You can have the same SNES aspect ratio but adding black bars to the sides.

The performance hit would be greater, as copying from one buffer to another would have to go pixel-by-pixel, vs the line-by-line they are doing now.

Let me give the world a little lesson about SNES aspect ratio:

The SNES renders at a resolution of 256x224. With square pixels, that would be an 8:7 aspect ratio. The only thing is, the games were never meant to have square pixels. The SNES was designed to output to a television, which would display non-square pixels, stretching the games to fit its 4:3 aspect ratio. Game developers knew this, and so all the art, assets, etc in a game was intended to be stretched in this manner.

The DS renders and displays at a resolution of 256x192. It has square pixels, and an aspect ratio of 4:3, same as a TV. A SNES game has to be squished and lose some pixels to display on a DS, but it's the right aspect ratio. Cropping the top and bottom is a LESS accurate image in that regard.

Any questions?

You are correct, but you are not understanding Rankio's suggestion. He's talking about the aspect ratio of the SNES, not the aspect ratio of the TVs back in the day. He suggested squishing the display horizontally so that it matches the internal 8:7 ratio the SNES displays at (he made sure to include adding bars to the sides in his post for clarification). Most people nowadays that play SNES games are not playing on an actual SNES, but an emulator that is played on a system who's display doesn't take into account a TV's aspect ratio.

My response was that it would create a performance hit because the number of operations to handle the same amount of data would be much greater. As it is right now with Display Mode 0, it repeats the copying of a block of 6 pixel lines (256 pixels each), which is about 1536 pixels a go while skipping a full line of pixels. With trying to achieve the SNES aspect ratio via software, copying would be forced to about 6 pixels per go while skipping one pixel alongside for each line being copying from the earlier example. The amount of data having to be copied shows the latter method as less, but because of the great inclusion in CPUs known as Block Copying, large chunks of sequential data become faster to copy because of no need to stop as often when skipping a set of data. An example would be that in the amount of time it took to copy 6 pixels (12 bytes in this case), the version of copying 48 bytes could take just as much time, possibly less because it was optimized to handle large amounts of data. We could go into further detail, such as problems when copying from a non 4-byte aligned memory location, but no one needs to know that stuff.

I understand what he was suggesting. My point was that it's a bad suggestion, since the games were not intended to be played that way. Not only would it be slower, but it would look worse and be further from how the games were MEANT to be played. If you've got the resolution to manage it, it's always better to display at the intended display aspect ratio, even if it means non-square pixles, rather than the internal aspect ratio which was not how the games were meant to be looked at.

Beyond that, most emulators DO stretch to 4:3. Hell, if you're using Blargg's NTSC filter (which I recommend if you're using a PC, since most PC SNES emulators have built in support for it and it looks more like a TV), it automatically stretches to 4:3.

 

[DiscostewSM]

It's too bad that the current implementation of DSTWO applications can't have a configurable DS-side application to handle data being sent/received to/from the DSTWO, as that could help in both aspect ratios by taking the output, and using the 2D hardware for backgrounds to scale and offset it, rather than having the DSTWO process it all via software. If they were able to do that, then they could possibly move the audio core to the DS and have the ARM7 handle the processing (since the SPC700 is literally self-containing, and data to it is slow) like PocketSPC does.

 

[tsukael]

OMG I have been waiting for this. Now I can play FFVI!!!

Yes, I haven't played FFVI please don't yell at me =(

 

[keine]

My supercard shipped from ShopTemp very fast.
and GBA and SNES on my pearly white DS will be MINE ALL MINE!!!!! MUHhahahaha
I'm thinking its about time I played Earthbound followed by Mother 3.....oh, supercard..you make things so easY.

 

[Paarish]

Compared to Snemulds, its pretty decent. It can just barely play Mario RPG (to play battles you need to keep entering and exiting the in-game menu) and i was quite surprised that the sound quality for Tales of Phantasia surpassed that of the PSP SNES emulator so this emulator is a win ^^.

 

[keine]

I mean even to have Super Mario RPG kinda sorta....thats HUGE. From my experience in SNES Emu that is the #1 hardest game to emulate...or at leas the most intense. I believe in SuperCard team. They'll have ficking Super Mario RPG playable on the DS soon.

 

[9th_Sage]

It's too bad that the current implementation of DSTWO applications can't have a configurable DS-side application to handle data being sent/received to/from the DSTWO, as that could help in both aspect ratios by taking the output, and using the 2D hardware for backgrounds to scale and offset it, rather than having the DSTWO process it all via software. If they were able to do that, then they could possibly move the audio core to the DS and have the ARM7 handle the processing (since the SPC700 is literally self-containing, and data to it is slow) like PocketSPC does.

The thing about having the sound on a different CPU is that we would probably end up with odd sound issues and the compatibility issues some games have because of them due to the SNES' CPU and the SPC700 not syncing up quite right (like SnemulDS, Archeide has talked about it, so I swear I'm not making it up

). If something could be figured out to fix that issue though, I don't see why not. Using the ARM CPUs for scaling is a pretty interesting idea too (scaling would look far better with flicker scaling or even alpha-lerp as in NesDS). Kinda makes me wonder what else could be done...I wasn't sure how much the DS cpus and the DSTwos mips CPU could communicate with one another. Offloading some of the work would surely help speed things.

 

[Covarr]

It can just barely play Mario RPG (to play battles you need to keep entering and exiting the in-game menu)

Battles in that game are an interesting beast in this emulator.

When the emulator is running normally, it goes at full speed and with sound, but the screen won't refresh, it stays black. You can refresh it by going into the menu. However, you can get the game to work somewhat properly, albeit losing sound, by putting the video into fastforward mode. It's choppy, but you can see what you're doing. It's pretty much necessary for timed hits.

 

[macgeek417]

Can anyone confirm that the games are ALL running on frameskip? I don't see any options to change it, and yet the games run nowhere NEAR as fluid as they should. It's not lag that's doing it...

What do you have your 'CPU frequency' setting on? Because a lot of my games don't have any frameskip (my CPU frequency is set to 4).

Same here and while the frameskip is much less, it is noticable in some cases such as All-Stars. If there are any games that require precise timing to do certain things (such as Mother 3 combos or other games with timed hits) it will be much harder if not impossible. Keep in mind that almost all emulators have input lag even without frameskip (so good luck with Mother 3 combos on any GBA emulator). Until the emulator gets speedhack support I would stick with slower moving games, such as RPGs. On the bright side, except for Star Ocean (and yes, I tried the 12MB uncompressed version) all of my favorites from Japan work fine, including SMT.

The 6MB version of Star Ocean works great - the emulator has support for the S-DD1