09-21-2010 #141eventum Guest
I wouldn't mind 2-3x larger font when browsing files. I'm climbing towards 40 and my eye sight is not what it used to be.
Great work guys in any case!
09-21-2010 #142squarepusher2 Guest
[Register or Login to view code]
I'm running this on a Windows box running Msys since this build that is publicly available does not have PPU GCC/G++ binaries for Linux (don't ask me why, since the official SDK comes with both host-linux and host-win32 folders, yet it's missing PPU binaries for Linux - I'm guessing this is something that got left out of the leaked SDK release.)
Is there any chance you could provide a diff in the future to get around the GCC 4.4 requirement, or is this not a trivial task? I'm guessing this would help out people on other platforms as well.
09-21-2010 #143byuusan Guest
What a shame, I was hoping the PS3 devkit was at least semi-up to date.
Well, the thing is there's a lot of C++0x code. Porting it every time I release a new build would be way too much work, may as well not use it, but I use it because it makes writing the emulator much easier.
The main areas:
- foreach macro relies on auto keyword for type deduction (will have to add type parameter to every call in the cartridge/xml.cpp mapper)
- string, vector and array classes use move semantics and perfect forwarding (can be removed, core emulation do not use them so no performance penalty)
- most classes use = delete; on unused copy constructors (can be removed, they are just safeguards)
Probably a weekend task, or you could use v060 directly which is almost exactly the same in terms of accuracy, but lacks the faster performance core. I'm not huge on doing the backport myself, because I'm crazy busy with other things at the moment, but I'd be willing to help with any parts you don't understand, since few people know C++0x already.
09-22-2010 #144squarepusher2 Guest
[Register or Login to view code]
Basically, this succeeds up until a point - it errors out at a specific point (at the SDSP part - it complains about sDSP being undeclared.
As a second experiment, I also tried taking the bSNES makefile, this time retaining all the parts of your Makefile, but commenting out/editing out everything having to do with the GUI (such as 'include lib/nall/Makefile), ui := ui_qt, most of the platform stuff) and then executing make as follows:
make compiler=ppu-lv2-gcc-4.1.1 (notice I've omitted platform since I totally edited/commented all that stuff out)
This gives me even more spectacular errors.
Lastly, I also tried to do it the even more rough way - basically go over every directory inside the src folder structure, and put every file ending with .CPP inside PPU_SRCS. This also ended in failure.
Do you have any ideas? Once again, sorry for the general display of ignorance here (both on a language level (C++) and understanding of bSNES) - but it's quite hard to wrap my head around what might be wrong here. I don't think I'm omitting anything that is crucial.
Lastly, thanks for the advice on the sound APU. Just with the port of SNES9x alone, I tried out a wide range of input frequencies - I noticed that at a certain point, the crackling appeared to drown out, but on the minus side I started to notice frame skips / missed frames which previously weren't there - so I had to move the input frequency up again. Here's a list of values I had tried out with SNES9x:
31690 (starting to notice the crackling starting to subside, but on the flip side slowdown seems to be setting in)
31680 (same, if not worse slowdown)
31670 (and on)
31660 (and on)
Perhaps try what you seemed to hint at - if SNES9x generates 10 samples more than what is needed due to the PS3's display frequency and output frequency, perhaps start with an input rate of 32040 and subtract by 10 until I finally arrive at an ideal value?
Do you suppose we'll be running into the same problems with bSNES? While I'm on the subject, while I was able to get sound working just fine with previous versions of bSNES on my Opensuse 11.3 Core 2 Duo system, as of version 0.68 sound crackling also started to appear in a manner similar to that seen in this PS3 version of SNES9x - so I'm guessing that with the new APU core, this fiddling around with the Sound input frequency is part of a ritual that you have to endure once with every PC configuration because of the level of accuracy aimed at or something? This never seemed to be much of a problem with zSNES and SNES9x in the late '90s and on - I take it that was because of accuracy not being much of an issue.
Just to add to this - I also tried to exclude ruby from PPU_SRC since that is also platform-dependent - didn't change anything.
09-22-2010 #145deadpixel99 Guest
Hey squarepusher , you seem pretty smart but you do realize that it will not compile for the PS3 if the bsnes source code wasn't recoded for the PS3... You can't just take some random source code and try to compile it for a different system... Did you do anything to the source code first... doesn't seem like it.
09-22-2010 #146ionbladez Guest
09-22-2010 #147squarepusher2 Guest
Snes9x as it is was compiled unchanged with no PS3-specific changes.
09-22-2010 #148eventum Guest
Do you guys have any idea of how much system resources the current version of Snes9X consumes on the PS3? Is there any way to tell? With regard to CPU and RAM utilization.
09-22-2010 #149squarepusher2 Guest
09-22-2010 #150cvp Guest
Bro, VERY NICE WORK!!!! Donkey Kong haves Sound and Saving/Load States is possible!
one question, will be coming upscalling to 720p/1080p ?