SiENcE
Member
thx. i will try it.
Snes9X4C (For Caanoo) V20101010 - Beta Release
- Thread starter SiENcE
- Start date
Exophase
Nothing good will ever come of Exophase.
If you can combine the swizzling into a scanline renderer you might be able to get it close to free, depending on how the rest of the renderer works.
The best thing that can be done to optimize SNES9x (and this goes for any of the ports, even the PocketSNES tree) is for a new renderer to be done, preferably with the inner chunks having ARM ASM versions. I've looked through the stock SNES9x renderer (as of 1.52, the version used here) and it can't be very fast. I don't recall exactly what changes PocketSNES made, but I seem to remember it having the same sorts of problems. The SquidgeSNES renderer avoided some of them and had some of its own optimizations, but at some expense of accuracy. I don't think this renderer is available for PocketSNES, but I could be wrong.
Here are some of the issues:
- Tile rendering goes through function pointers per-tile which involves a lot of parameter passing and loading global arrays. This eliminates opportunity to perform optimizations such as strength reduction on loops and hurts register allocation, especially hard on RISC platforms. It's not too bad in the typical cases where you can render an entire tile at a time, but where the tile is forced to be broken up line by line, like when scroll or palette is changed every line, you'll feel a lot of pain from this. It's better for the switching to be done per-line instead of per-tile, even at the expense of having to generate more code.
- Z-comparisons are done on every pixel for priority sorting. This is especially expensive here because screen-wide z-buffers are used, which will cause a data cache miss on every new cache line from the z-buffer (for 32-byte lines that's every 16 pixels).. on platforms like Caanoo a cache miss can be over 70 cycles. It'd be better to split the BG layers into separate priorities, draw them in sorted order, draw OBJ, and combine OBJ. But there are other methodologies which I think are better than that too, they're just too long to describe here.
- Color math is done on every layer pixel write. This both wastes cycles on overdraw and causes another obligatory cache miss into the screen-wide sub-screen buffer. It'd be better to do it in a post-processing pass per-scanline.
- Main screen and sub screen are drawn in completely separate passes, which means twice the work is done when color math or hires is turned on. It'd be better if the line renderers drew two pixels where necessary. Especially if Z-combining isn't necessary per-layer.
- Mode 7 rendering would usually be (probably significantly) faster if they cached current tile pointers and only reloaded when offsets moved outside of the tile.
bsnes avoids some of these problems in its line-based renderer, but has some of its own unique problems, so I wouldn't necessarily recommend trying it.
I've got some rendering methodologies in mind that I hope to describe soon. They might be useful for making fast renderers for a lot of platforms, including SNES. But writing new rendering code would be a ton of work and I doubt anyone will do it.
The best thing that can be done to optimize SNES9x (and this goes for any of the ports, even the PocketSNES tree) is for a new renderer to be done, preferably with the inner chunks having ARM ASM versions. I've looked through the stock SNES9x renderer (as of 1.52, the version used here) and it can't be very fast. I don't recall exactly what changes PocketSNES made, but I seem to remember it having the same sorts of problems. The SquidgeSNES renderer avoided some of them and had some of its own optimizations, but at some expense of accuracy. I don't think this renderer is available for PocketSNES, but I could be wrong.
Here are some of the issues:
- Tile rendering goes through function pointers per-tile which involves a lot of parameter passing and loading global arrays. This eliminates opportunity to perform optimizations such as strength reduction on loops and hurts register allocation, especially hard on RISC platforms. It's not too bad in the typical cases where you can render an entire tile at a time, but where the tile is forced to be broken up line by line, like when scroll or palette is changed every line, you'll feel a lot of pain from this. It's better for the switching to be done per-line instead of per-tile, even at the expense of having to generate more code.
- Z-comparisons are done on every pixel for priority sorting. This is especially expensive here because screen-wide z-buffers are used, which will cause a data cache miss on every new cache line from the z-buffer (for 32-byte lines that's every 16 pixels).. on platforms like Caanoo a cache miss can be over 70 cycles. It'd be better to split the BG layers into separate priorities, draw them in sorted order, draw OBJ, and combine OBJ. But there are other methodologies which I think are better than that too, they're just too long to describe here.
- Color math is done on every layer pixel write. This both wastes cycles on overdraw and causes another obligatory cache miss into the screen-wide sub-screen buffer. It'd be better to do it in a post-processing pass per-scanline.
- Main screen and sub screen are drawn in completely separate passes, which means twice the work is done when color math or hires is turned on. It'd be better if the line renderers drew two pixels where necessary. Especially if Z-combining isn't necessary per-layer.
- Mode 7 rendering would usually be (probably significantly) faster if they cached current tile pointers and only reloaded when offsets moved outside of the tile.
bsnes avoids some of these problems in its line-based renderer, but has some of its own unique problems, so I wouldn't necessarily recommend trying it.
I've got some rendering methodologies in mind that I hope to describe soon. They might be useful for making fast renderers for a lot of platforms, including SNES. But writing new rendering code would be a ton of work and I doubt anyone will do it.
Jengo
Member
im pretty sure someone will come a long with the motivation and skills required to make new rendering optimizations, as well as other optimizations for Caanoo and its Arm architectures soon. But we will have to wait and see, but most of all hope!! 
Exophase
Nothing good will ever come of Exophase.
Jengo said:im pretty sure someone will come a long with the motivation and skills required to make new rendering optimizations, as well as other optimizations for Caanoo and its Arm architectures soon. But we will have to wait and see, but most of all hope!!
I'm pretty sure it won't happen, because it hasn't for GP32, GP2X, Wiz, or any of the smartphones that got PocketSNES. You'd need someone like notaz doing it.
Last edited by a moderator:
Jengo
Member
Notaz we need your help!!!
But in the end, im sure SiENcE does know what hes doing. Heres for wishing him the best of luck!!
But in the end, im sure SiENcE does know what hes doing. Heres for wishing him the best of luck!!
Exophase
Nothing good will ever come of Exophase.
notaz has said before he's not interested in working on SNES emulation.
Not a lot of people are really up to the task of rewriting a big chunk of an emulator for performance. Most people porting emulators stay away from the core for the most part. If anything is done it usually comes in the form of relatively small modifications. IMO SNES9x on handhelds (at least below Pandora's performance level) would benefit most from a renderer written completely from scratch.
Maybe when I describe the techniques I have in mind and the particular methodologies for adapting them to SNES someone will be willing to try it. I can describe the whole thing top to bottom and I don't think I'd be missing any details but I'm not writing any code.
Not a lot of people are really up to the task of rewriting a big chunk of an emulator for performance. Most people porting emulators stay away from the core for the most part. If anything is done it usually comes in the form of relatively small modifications. IMO SNES9x on handhelds (at least below Pandora's performance level) would benefit most from a renderer written completely from scratch.
Maybe when I describe the techniques I have in mind and the particular methodologies for adapting them to SNES someone will be willing to try it. I can describe the whole thing top to bottom and I don't think I'd be missing any details but I'm not writing any code.
Jengo
Member
All i know is that i am really impressed with what i have seen already (from an end-user standpoint, because im no dev), SiENcE is really making some great progress. Much props to SiENcE!!
RupeeClock
Member
- Joined
- Jun 7, 2009
- Messages
- 394
I'm glad this emulator was released, I just tried it and it works nicely, playing Super Mario All Stars on my Caanoo 1.06
The interface needs some work though, file selection doesn't work smoothly
The interface needs some work though, file selection doesn't work smoothly
renejr902
Active Member
Exophase said:
if someone or Science himself release a fast caanoo port of the current pocketsnes wiz version, Will it be fast like the wiz version ? how many hours could take a fast port of pocketsnes for the caanoo ?
Last edited by a moderator:
Exophase
Nothing good will ever come of Exophase.
A port of PocketSNES for Caanoo should be easy, and almost as fast as the Wiz version. Probably easier to do than this port was.
renejr902
Active Member
interesting. (i have to study the C++ book i bought recently, maybe someday i will port some emulator. lol i dont know if i will be able. i only studied turbo pascal 10 years ago)
thanks for answer exophase
thanks for answer exophase
I have a small suggestion that I'd like to run past everyone else here.
Does anyone else feel that the joystick's "diagonal" response could be a little more sensitive?
Think of the stick in degrees. If straight up is 90 degrees and straight right is 0 degrees, it seems like the diagonals only register from like 40-50 degrees, which is a fairly small area. I think the range that the emulator recognizes as "diagonal" could be a little tiny bit larger without making the controls feel inaccurate.
What do you guys think?
Does anyone else feel that the joystick's "diagonal" response could be a little more sensitive?
Think of the stick in degrees. If straight up is 90 degrees and straight right is 0 degrees, it seems like the diagonals only register from like 40-50 degrees, which is a fairly small area. I think the range that the emulator recognizes as "diagonal" could be a little tiny bit larger without making the controls feel inaccurate.
What do you guys think?
SiENcE
Member
hi ozzuneoj,
i'm not an joypad expert. Please do more testing and report problems to me. I will fix it in an upcomming release.
Today my PS2->USB and Snes->USB Adpaters arrieved. Now i add USB-Joypad support to Snes9x4C.
Does the limited ROM-Browser works ok for everyone, or should I add directory switching support?
cheers
i'm not an joypad expert
. Please do more testing and report problems to me. I will fix it in an upcomming release.Today my PS2->USB and Snes->USB Adpaters arrieved. Now i add USB-Joypad support to Snes9x4C
.Does the limited ROM-Browser works ok for everyone, or should I add directory switching support?
cheers
I'm having a wee bit of trouble just getting this going I'm afraid. Everytime I start it the Caanoo loading screen comes up then it goes blank for a split second and returns to the Caanoo Menu. I'm not sure whats causing this, I've tried re-downloading both Snes9x4c and the latest firmware update but still no luck. I even removed Gmenu2x to see if that was the problem. I would appreciate any help you could provide especially as the Snes was one of my favorite systems.
Popcorn Dave
Member
- Joined
- Oct 10, 2010
- Messages
- 187
GreenBoy, check the file names in your ROM folder. I had the same problem, and I found it was because I had some file names with the Spanish "Ñ" letter in them; the program just didn't know what to do with that symbol. Maybe you should check you haven't got any unusual letters or symbols in your rom folder.
traylorpark
Very Active Member
- Joined
- Sep 30, 2008
- Messages
- 593
SiENcE said:Today my PS2->USB and Snes->USB Adpaters arrieved. Now i add USB-Joypad support to Snes9x4C
Does the limited ROM-Browser works ok for everyone, or should I add directory switching support?
cheers
Good lord I love you! USB pad support! Time for some Mario Kart parties?
Directory switching is always awesome as well.
Last edited by a moderator:
Popcorn Dave
Member
- Joined
- Oct 10, 2010
- Messages
- 187
Multiple directories would be a nice touch! It would also be nice if you could load a new rom without quitting the program, if that's possible.
