I merged the code in svn://svn.pspdev.org/pspware/trunk/snes9x with my own 0.02y11j3a5 code and renamed the project 0.02pd... Since y has refused to release the source code for his newer versions, the fork was necessary.
Most importantly, aside from the name change and open source nature, the new version adds a sceGu bit blit backend. It's still experimental, and has been known to mess up the GUI among other things, but it's much more advanced than the traditional pg bit blit backend. Many thanks to crazyc and chp for the original patch to use sceGu based blitting.
If you're daring enough to try the sceGu blit backend, it's an option in the display config menu. Once you enable it, the screen may stop updating altogether, this happens if the menu code has swapped the back buffer with the front... Press 'O' a couple of times to fix it. Obviously that needs to be fixed and I'm looking into it right now :)
You can enable HiRes mode (typically pointless, since very few SNES games ever utilized this and those who did only used it for short periods of time, such as title screens... the flicker from interlacing annoyed most players) which renders to a 512x512 texture, rather than the standard 256x256, and change the filter technique. There really is no measurable performance hit for enabling bilinear filtering, but point filtering is the default because that was the normal behaviour for older versions. And since the sceGu blit code isn't double buffered right now, you will notice annoying artifacts at moments - I'll fix that soon. Also, the 'Fit' screen mode becomes 4:3 with the sceGu blit backend enabled.
I also changed the state compress/decompress code so that it will not modify the state save timestamp anymore.
The menu is opened with L Trigger + R Trigger + Select now... If anyone wants to make this a configurable option, by all means feel free. I'm too busy working on the sceGu blit code right now to address this.
See the new CHANGELOG.txt file for any additional info.
uo_Snes9x 0.02pd1
No, it's just the source code...emumaniac wrote:is there a download ?
I'll put a build up on my website though:
http://psp.nothing-inc.com/uo_Snes9x-0. ... 15.tar.bz2
I fixed all of the GUI issues mentioned in this snapshot, and in the SVN code.
* BTW, this is not an official release, pd1 is still in development... Once I make the sceGu blit code double buffered I'll formally release pd1.
'y' has released version y28's source code on his website ..
I'm not sure if you missed it or what, but the source code for y28 is posted on 'y''s website.
Check out http://ypspdev.hp.infoseek.co.jp/cgi-bi ... cgi?y28src for the source.
Thanks,
Check out http://ypspdev.hp.infoseek.co.jp/cgi-bi ... cgi?y28src for the source.
Thanks,
... anyone up for some l33th4x?
;)
;)
Re: 'y' has released version y28's source code on his websit
Thanks, I'll look into it. I contacted him a while back asking if he could release the source code but he never responded :-\n1ckn4m3 wrote:I'm not sure if you missed it or what, but the source code for y28 is posted on 'y''s website.
Check out http://ypspdev.hp.infoseek.co.jp/cgi-bi ... cgi?y28src for the source.
Official release
I have officially released 0.02pd1 now. Everything's working well enough to make the sceGu bit blit backend default.
From the readme.txt:
Binary: http://psp.nothing-inc.com/uo_Snes9x-0.02pd1.zip
Obviously you can get the latest source code from SVN ([url]svn://svn.pspdev.org/pspware/trunk/snes9x[/url])... But the final pd1 source code is also available in tarball form.
Source Code: http://psp.nothing-inc.com/uo_Snes9x-0. ... rc.tar.bz2
From the readme.txt:
Code: Select all
uo_Snes9x 0.02pd1
-----------------
This is the first version of the PSP Dev. unofficial Snes9x PSP port... It is
based off of uo_Snes9x 0.02y11J3a5.
-*- To Open The Menu: (Left Trigger + Right Trigger + Select) -*-
Most importantly in this release, a new bit blit backend has been added. This
new backend allows the viewport to be stretched without any performance hit, and
also allows for extremely fast bilinear filtering and HiRes mode.
The new bit blit backend is enabled by default, if for some reason you want to
use the old backend (pg), you may select it from the display config menu.
Bilinear filtering is available (and enabled by default) if you're using the
sceGu bit blit backend. Do not worry, enabling this has no impact on perform-
ance at all - it is merely an asthetic preference.
The 'Fit' screen size becomes '4:3' (and is the new default) when using the
sceGu bit blit backend. Again, when using the sceGu bit blit backend, changing
the screen size will not impact performance.
HiRes mode is not suggested, very few games use this feature... The ones that do
typically only use it for short periods of time during gameplay, like the title
screen. If you don't know what this is, you probably don't need to enable it.
The battery info text has been translated to English, the confirmation dialogs
will be translated in 0.02pd2.
Compressing or Decompressing an existing state save will no longer change its
timestamp.
See the included CHANGELOG.txt file for any additional changes... Note that most
of the info in there is pretty technical.
Binary: http://psp.nothing-inc.com/uo_Snes9x-0.02pd1.zip
Obviously you can get the latest source code from SVN ([url]svn://svn.pspdev.org/pspware/trunk/snes9x[/url])... But the final pd1 source code is also available in tarball form.
Source Code: http://psp.nothing-inc.com/uo_Snes9x-0. ... rc.tar.bz2
Andon:
Thanks for the great work! It's awesome to see such incredible progress with projects like this. I can't wait to try this out once I get home!
Keep up the great work and thanks again for dedicating your free time to our pleasure :D
EDIT: Played around with it, again, great job! Seeing the different as far as FPS goes on graphically intensive games is impressive! As far as I'm concerned this version of the emulator has the most potential. Utilizing the sceGu is a great step forward. Again, keep up the great work and know that people appreciate your work!
Thanks for the great work! It's awesome to see such incredible progress with projects like this. I can't wait to try this out once I get home!
Keep up the great work and thanks again for dedicating your free time to our pleasure :D
EDIT: Played around with it, again, great job! Seeing the different as far as FPS goes on graphically intensive games is impressive! As far as I'm concerned this version of the emulator has the most potential. Utilizing the sceGu is a great step forward. Again, keep up the great work and know that people appreciate your work!
Last edited by n1ckn4m3 on Sat Jul 16, 2005 12:46 pm, edited 1 time in total.
... anyone up for some l33th4x?
;)
;)
-
eddyjackson
- Posts: 2
- Joined: Sat Jul 16, 2005 10:15 am
Nice work, although
Y posts the source with every release on his webpage.Since y has refused to release the source code for his newer versions, the fork was necessary.
Did you email him in Japanese?[/url]Thanks, I'll look into it. I contacted him a while back asking if he could release the source code but he never responded :-\
-
eddyjackson
- Posts: 2
- Joined: Sat Jul 16, 2005 10:15 am
sceGu
Correct me if I am wrong. I have not looked at the source code to the new gu blit backend. But, if the blit was implemented using palettized 8-bit textures, each texture being an 8x8 tile, and rendering the tilemaps on screen as such--wouldn't this run at far beyond 60 fps? I've seen the snes9x gu blit backend, and I wasn't all that impressed. With the gu acceleration, I would assume that drawing gfx would be a non-issue, even with transparencies.
Again, correct me if I am wrong on this.
Again, correct me if I am wrong on this.
Yes, that's indeed a possibility. I've actually been looking into that recently. The majority of the CPU cycles are spent drawing the tiles, without profiler support for the current PSP toolchain I've lost hope trying to optimize the code - all I can go by is the number of cache misses, cpu stalls, etc. between time A and time B, so it's still very much a guess and check process.
I'm going to finish up pd2 before I put any significant effort into optimizing the tile drawing. But it looks like that's our only hope of ever getting the emulator to run at "full speed" on the PSP.
I'm going to finish up pd2 before I put any significant effort into optimizing the tile drawing. But it looks like that's our only hope of ever getting the emulator to run at "full speed" on the PSP.
Last edited by Andon on Thu Jul 21, 2005 3:52 pm, edited 1 time in total.
One challenge here is to properly support HDMA effects while getting optimal performance. Basically, most backgrounds and sprites can be blitted "straight up", ie. the whole tile or sprite in one fast blit. However, as soon as you use HDMA to dynamically alter PPU registers during the screen drawing process that approach won't suffice. Any sprites, backgrounds or windowing effects that's effected by HDMA must be drawn on a line-by-line basis.
A solution that might gain considerable speed is to "log" the HDMA actions for the current frame, and delay all drawing until vblank is reached. Then you decide which components of the screen can use fast blitting, and which need line-based rendering. Since HDMA action often is delayed for large portions of the screen (for example the ground in Street Fighter 2, where the channel that controls the scrolling only is active for ~1/4 of the screen), there are further optimizations to do if HDMA channels that use delays are treated with line-rendering only for those lines where it's active.
This would require a rewrite of the entire PPU core, though. The SNES9X team (Anomie, really) are currently doing a rewrite with optimal compability in mind (perhaps it's already in use? I haven't kept up with SNES news for some months), I guess there's very little chance of getting that up to speed on the PSP. That might be incentive enough to code an alternative, hi-speed hardware accelerated, PPU core for machines such as the PSP.
A solution that might gain considerable speed is to "log" the HDMA actions for the current frame, and delay all drawing until vblank is reached. Then you decide which components of the screen can use fast blitting, and which need line-based rendering. Since HDMA action often is delayed for large portions of the screen (for example the ground in Street Fighter 2, where the channel that controls the scrolling only is active for ~1/4 of the screen), there are further optimizations to do if HDMA channels that use delays are treated with line-rendering only for those lines where it's active.
This would require a rewrite of the entire PPU core, though. The SNES9X team (Anomie, really) are currently doing a rewrite with optimal compability in mind (perhaps it's already in use? I haven't kept up with SNES news for some months), I guess there's very little chance of getting that up to speed on the PSP. That might be incentive enough to code an alternative, hi-speed hardware accelerated, PPU core for machines such as the PSP.
Indeed, that was one thing I was concerned with. Another is the way depth values can be per-pixel... The PSP doesn't have a programmable fragment pipeline, which would make that difficult to deal with as well. But then again we don't even know how to use its programmable vertex pipeline yet :)
Also, I wanted to point out that I really wasn't expecting the sceGu blit to speed anything up; except for scaling the SNES display and applying bilinear filtering. There's additional overhead every frame when the data cache has to be cleared and the GPU/CPU synchronization (though, I think I disabled that in pd1?), so it runs a slight bit (1 FPS or so) slower than pg would at its "Normal" size. If you compare the pg Fit and sceGu Fit modes on the other hand there's no contest, and if you throw in the software bilinear filtering y ported, it's a truly pathetic comparison :)
Also, I wanted to point out that I really wasn't expecting the sceGu blit to speed anything up; except for scaling the SNES display and applying bilinear filtering. There's additional overhead every frame when the data cache has to be cleared and the GPU/CPU synchronization (though, I think I disabled that in pd1?), so it runs a slight bit (1 FPS or so) slower than pg would at its "Normal" size. If you compare the pg Fit and sceGu Fit modes on the other hand there's no contest, and if you throw in the software bilinear filtering y ported, it's a truly pathetic comparison :)
I have no idea if that would help, but you could get yourself one of those cheap (=25 euro for 4Mbps, multiple standard, etc.) IrDA USB plugs for your PC, and then write a simple debug printf that outputs to the IrDA port. Then you just need something on the PC to make the incoming IrDA bytes visible.Andon wrote:Yes, that's indeed a possibility. I've actually been looking into that recently. The majority of the CPU cycles are spent drawing the tiles, without profiler support for the current PSP toolchain.
I don't know if the speed of IrDA is enough for all profiling purposes, but I think it should be a very good way to get a runtime debug output screen for your PSP and you should be able to do at the very least basic profiling with it.
GREAT WORK!
This is definately a HUGE improvement over the other SNES emulators ive found. However aside from sound (which is understandable) there is one effect that KILLS performance. Transparency.
Seems to me a lot of games I try to play use transparency in one form or another. If I turn it off I have solid textures over my screen and I cant see whats going on, if I turn it on the game slows to a crawl. Theres gota be a way to optimise transparency :)
At the very least you could put in an option like ZSNES has where you can toggle on and off the seperate layers so you could turn off the transparency layer entirely so you wouldnt have the opaque textures covering the screen. This applys to games with fog effects, or more importantly maridia in super metroid where the whole dang zone is covered with transparent water and is impossible to play without transparency turned on.
Other than that it looks great and keep up the good work, using PSP hardware in the emulator is definately the way to go!
Seems to me a lot of games I try to play use transparency in one form or another. If I turn it off I have solid textures over my screen and I cant see whats going on, if I turn it on the game slows to a crawl. Theres gota be a way to optimise transparency :)
At the very least you could put in an option like ZSNES has where you can toggle on and off the seperate layers so you could turn off the transparency layer entirely so you wouldnt have the opaque textures covering the screen. This applys to games with fog effects, or more importantly maridia in super metroid where the whole dang zone is covered with transparent water and is impossible to play without transparency turned on.
Other than that it looks great and keep up the good work, using PSP hardware in the emulator is definately the way to go!
Omg, start reading last posts on a thread (or at least take a short glimpse at the date of the last post of the author) and get it! This emu was last updated Jul 2005 and is OUT OF DATE!
Use SNES9X_TYL. It's more compatible and faster. Period.
Sorry if this sounds rude, it isn't. It's just annoying how people don't read anything before asking questions that are already answered in the last 1-line post :/
Use SNES9X_TYL. It's more compatible and faster. Period.
Sorry if this sounds rude, it isn't. It's just annoying how people don't read anything before asking questions that are already answered in the last 1-line post :/
Omg, start reading last posts on a thread (or at least take a short glimpse at the date of the last post of the author) and get it! This emu was last updated Jul 2005 and is OUT OF DATE!
Sorry if this sounds rude, it isn't. It's just annoying how people don't read anything before asking questions that are already answered in the last 1-line post :/
Before you start running your mouth why not ask what version i am using , I AM USING snes9xTYL 0.2c
My question stands as asked!
I have tried sensi soccer looks great but every time i touch a button it goes back to the games menu screen any ideas anyone or what games actually work
Thanks
Asking in a outdated thread on "uo_Snes9x 0.02pd1" and asking a question about compatibility of a completely different snes emu without explicitly naming it and then mocking that someone misunderstood you is.... let's keep it friendly - not that foreseeing.
If you have questions on SNES9xTYL, better ask in the appropriate forum in the appropriate thread, or start a new one here. I don't think that many people who could answer your question with TYL will read this thread anyway.
To at least try to answer your question partially: I don't know about sensible soccer, but it run's all games I tried so far very well playable if you run PSP at 333Mhz and set sound to 11khz or turn it completely off (not emulated/no-output). The only games that are slow are games with additional chips on the cartridge, like starfox (FX-Chip) and games that use mode-7 (Mario Kart). If however game xy won't run, it would probably be best to tell the author(s) of the emu about it, with explicit explanation how to replicate the error.
So sorry again if my first post sounded rude.
@Mods:
I'd say this thread should be closed.
If you have questions on SNES9xTYL, better ask in the appropriate forum in the appropriate thread, or start a new one here. I don't think that many people who could answer your question with TYL will read this thread anyway.
To at least try to answer your question partially: I don't know about sensible soccer, but it run's all games I tried so far very well playable if you run PSP at 333Mhz and set sound to 11khz or turn it completely off (not emulated/no-output). The only games that are slow are games with additional chips on the cartridge, like starfox (FX-Chip) and games that use mode-7 (Mario Kart). If however game xy won't run, it would probably be best to tell the author(s) of the emu about it, with explicit explanation how to replicate the error.
So sorry again if my first post sounded rude.
@Mods:
I'd say this thread should be closed.