Emulation central - recommendations in 1st post

[A user named cat]

I am not a programmer or have any knowledge of coding, much of what you're stating is alien to me and of no interest. You're continously circling yourself, eating your tail and shitting it back out. All this research for nothing.

I'm here simply stating and showing with proof the obvious. This has absolutely everything to do with your PC specs. I have now posted an audio clip and a 7 minute Desmume gameplay video, recorded at 60fps and max res showing that there are no audio glitches, no slowdown, no hiccups or any issues to speak of in Desmume. Will you stop ignoring the proof? I feel like I'm trying to convince a feminist the wage gap isn't real while you scream and clasp your hands over your ears.

I used to suffer from issues similar to yours when I was on a shitty AMD Phenom II. Framerates struggling to reach 60 let alone stay there, thus having various desyncing problems and stuttering audio even in Mednafen trying to run PS1. So the solution to all your woes here is as simple as can be. Buy/steal/pillage/build an Intel i5 or i7 PC. All your troubles will be over.

 

[sullynathan]

messing with PCSX2 more and I find that I can get better performance (20 frames more) with frameskipping. How much will this impact gameplay? For Tekken tag tournament, the screen looks blurry at times after I did this, but the game runs closer to 90%.

 

[Hirato]

messing with PCSX2 more and I find that I can get better performance (20 frames more) with frameskipping. How much will this impact gameplay? For Tekken tag tournament, the screen looks blurry at times after I did this, but the game runs closer to 90%.

I don't think frameskipping impacts gameplay much.
In my experience trying to use this feature just causes the entire rendering pipeline to break irrecoverably almost immediately; which left me with a black screen.

I am not a programmer or have any knowledge of coding, much of what you're stating is alien to me and of no interest.

And yet you see fit to comment.

You're continously circling yourself, eating your tail and shitting it back out.

Citation fucking needed.

All this research for nothing.

I like understanding the "why" of things - but true enough i suppose, since I won't be fixing it.

I'm here simply stating and showing with proof the obvious.

Your proof stems from an illogical basis.
To put in in the form of a metaphor: You're comparing an apple to an orange, then placing the blame of the apple not tasting like an orange on my tastebuds, as opposed to the reality in that an apple is simply not an orange.

The facts that I have already revealed, which you are ignoring;
1. The audio is WITHOUT ANY GLITCHES in libretro,
2. audio only glitches within standalone Desmume - despite it not missing a single frame.
3. I'm a linux fag, and SDL is the only audio output option available; There is no XAudio, there is no DirectSound; these are the apples and the oranges of the metaphor.

and a fact I have not yet revealed,
1. Desmume has 0 audio glitches when running in wine (and also has about 50x as many configuration options)

This has absolutely everything to do with your PC specs.

It has absolutely nothing to do with my PC, and everything to do with desmume audio output via SDL 1.2 being faulty; see above

I have now posted an audio clip and a 7 minute Desmume gameplay video, recorded at 60fps and max res showing that there are no audio glitches, no slowdown, no hiccups or any issues to speak of in Desmume.

And I have posted an audio clip that demonstrates things are not fine, but again you're comparing apples to oranges, see above.

Will you stop ignoring the proof?

I am ignoring your proof, because you are again, comparing apples to oranges; see above.

I feel like I'm trying to convince a feminist the wage gap isn't real while you scream and clasp your hands over your ears.

Not an apt comparison at all, as the disagreement stems from you failing your reading comprehension rolls; again, see above.

I used to suffer from issues similar to yours when I was on a shitty AMD Phenom II. Framerates struggling to reach 60 let alone stay there, thus having various desyncing problems and stuttering audio even in Mednafen trying to run PS1.

The make of my CPU (which is AMD), is not irrelevant,
Desmume standalone has no issue reaching and maintaining 60 FPS with 0 frameskipping, even with the software renderer.
And I can run other versions, including an emulated version (in wine) and the libretro version with 0 audio issues.
So again, see above.

Also MednafenDS when?

So the solution to all your woes here is as simple as can be. Buy/steal/pillage/build an Intel i5 or i7 PC. All your troubles will be over.

With Intel's track record, they're not going to see another cent out of me unless AMD's Zen CPUs turn out to be a total disaster.

 

[spekkio]

Get a GitHub, you two...

 

[A user named cat]

Yeah, come now. I'm not Vault Dweller and going to play quote wars here. You keep stating this sdl problem and laying the entire blame at Desmume's feet for suffering from audio headaches. I recorded a Desmume standalone video showcasing the game you mentioned. My video shows there were no glitches to speak of and the audio is fine in standalone, even while recording a raw 60fps video clip. FRAPs eats far more system resources than Desmume from both the cpu and constant writing to drive, yet even with both running for almost 10 minutes, not a single hiccup.

You just admitted you're on an AMD cpu. I am telling you as clearly as I possibly can that is the entire reason you're running into problems like this. AMD is shit, and their cpu's are terrible for emulators. I was there before and will never go back. Fuck AMD. I don't even like my r9 290 card, even their drivers are terrible. Crimson is about as poorly designed as it gets. I look forward to being back in Nvidia's arms. You need to put away your morals when it comes to making hardware purchases. Intel also sides with idiotic SJW's but at the end of the day, their processors will forever remain king and they handle every emulator with ease.

 

[spekkio]

BROS, I need help from somebody with INT high enough to compile shit from sources.
I would like to get my hands on Dosbox build for Windows with all advanced options of Daum's build, but also with the joystick-deadzone patch, so far included only in Dawid Walters' build.

Sources for both builds are available:

Daum: http://ykhwong.x-y.net/downloads/dosbox/patch/source.7z
DWD: http://www.davidwaltersdevelopment.com/tools/dosbox/custom-dosbox-r13-src.zip

I've quickly scanned contents of both archives and one thing is certain: the deadzone patch is included in /src/hardware/joystick.cpp

Example:

// DWD BEGIN
static float deadzone_inner = 0;
static float deadzone_scale = 1.0f; // = sqrt(2) / ( 1 - deadzone_inner );
static float deadzone_inner2 = 0; // = deadzone_inner * deadzone_inner
// DWD END

I don't know if simply replacing joystick.cpp from Daum's build with the one from DWD build will be enough for the deadzone patch to work. But someone l33t enough should be able to TEST it by compiling this shit.

FAQs for Dosbox compilation are available online, ofc.

Anyone?

 

[Hirato]

lame, DWD didn't provide a proper patch.


If you copied DWD's version over Daum's, it will probably work, but you'll lose any and all changes Daum did himself.
What you need to do to do this properly, is open the joystick.cpp file in Daum's build, and replace the parts of the code that DWD modified with his versions.
Then you can just build it as you would any other program.

There are Visual Studio solutions included for the 2015 edition, so just grab the fucking massive Community edition, install it (and reboot a few times) and you should be good to go.

 

[SCO]

Ignored Phantasmal

 

[A user named cat]

Sensitive Linuxtards, jewels of the internet.

BROS, I need help from somebody with INT high enough to compile shit from sources.
I would like to get my hands on Dosbox build for Windows with all advanced options of Daum's build, but also with the joystick-deadzone patch, so far included only in Dawid Walters' build.

Sources for both builds are available:

Daum: http://ykhwong.x-y.net/downloads/dosbox/patch/source.7z
DWD: http://www.davidwaltersdevelopment.com/tools/dosbox/custom-dosbox-r13-src.zip

I've quickly scanned contents of both archives and one thing is certain: the deadzone patch is included in /src/hardware/joystick.cpp

Example:

// DWD BEGIN
static float deadzone_inner = 0;
static float deadzone_scale = 1.0f; // = sqrt(2) / ( 1 - deadzone_inner );
static float deadzone_inner2 = 0; // = deadzone_inner * deadzone_inner
// DWD END

I don't know if simply replacing joystick.cpp from Daum's build with the one from DWD build will be enough for the deadzone patch to work. But someone l33t enough should be able to TEST it by compiling this shit.

FAQs for Dosbox compilation are available online, ofc.

Anyone?

You could try asking on their forums though they don't appear very active. Maybe pester some of the devs there with PM's? https://www.vogons.org/viewforum.php?f=32

 

[Epsilon]

Hirato did you try the command line arguments for desmume? I'm sure I removed the laggy audio by specifying audio flags and jit that way. You can't set those in the GUI, but you can with arguments. I will verify tonight.

 

[Hirato]

Hirato did you try the command line arguments for desmume? I'm sure I removed the laggy audio by specifying audio flags and jit that way. You can't set those in the GUI, but you can with arguments. I will verify tonight.

I've been passing --enable-jit --jit-size 12 --3d-render GL --preload-rom.
They don't have any effect on the audio clarity, but they do allow me to uncap the framerate at 110FPS instead of 70 FPS

I've done a little bit more playing around, I think the SPU unit might be filling up the buffer with empty audio when no emulation is running - in this state the SDL playback is paused so the buffer's never emptied.
I added a few hacks
1. I made the buffer very large, about 16384
2. I started the write offsets at 1024 (this variable also isn't initialised ever, oh dear)
3. if soundpos (played bytes) and the offset (written bytes) match, play the last 2 bytes and don't advance the position

1. Made the audio glitching loopy (this kind of confirms my theory)
2. Seemingly had no effect, in theory this should've added a smaller period of silence at the front which would give me a small buffer against the underruns, but it didn't
3. I just got silence; this means 1 of 2 things; a) the buffer was filled up by the SPU before playback started and because of an off-by-one error the offset and position matched, b) soundoffset is initialised via an extern declaration elsewhere, I consider this very unlikely as the variable is defined in sndsdl.cpp and this approach wouldn't work with both XAudio and DirectSound backends.

Also very curiously if I change the sync method after starting a game, it pauses briefly, then audio plays back glitch free, which lends some credence to my other theory that the buffer is being filled up ahead of time with silence via the SPU.

 

[Epsilon]

Hirato I've now had a look, and the run script I have just says "desmume --spu-mode=1 --spu-method=2 --spu-advanced=1 --num-cores=12 --cpu-mode 1 --jit-size 100" and it does produce faulty audio! which I'm sure it didn't in the past, so something must've changed on the recent update. If I change the audio synchronization method in the gui, it does indeed sort itself out, even if I go to one method and then back to the original one that produced bad audio. So I agree with your findings.
My test was conducted on a system with Intel Haswell-e Core i7 5820k and an nvidia 980 gtx card and blob.

Oddly though, after having run desmume a couple of times now and closing it a couple of times too... it no longer produces faulty audio, don't have to change synchronization method either.
Tried shutting off the pc, and starting again. No audio problems anymore. So it leads me to believe that config files have been generated that stores the information, that it lacks on the first run.
But then again
"[Audio]
Enabled=true
Synchronization=3
Interpolation=1"
Surely it can't be that simple.

 

[A user named cat]

If anyone using PPSSPP has encountered game freezes and you're on a cursed AMD graphics card, then change your backend to Direct3D and all will be well. Found this out the hard way yesterday after repeated hard freezes as apparently opengl is now borked for AMD card users especially with Crimson drivers. Really need to go back to Nvidia, fucking AMD can't do anything right.

 

[tuluse]

If anyone using PPSSPP has encountered game freezes and you're on a cursed AMD graphics card, then change your backend to Direct3D and all will be well. Found this out the hard way yesterday after repeated hard freezes as apparently opengl is now borked for AMD card users especially with Crimson drivers. Really need to go back to Nvidia, fucking AMD can't do anything right.

I just did some quick testing, ppsspp 1.3 opengl is working for me. I'm on an R9 285. Retroarch version has always worked, but it's well behind at this point. I'm still on the 16.10 drives through, 16.11 might break it.

 

[A user named cat]

If anyone using PPSSPP has encountered game freezes and you're on a cursed AMD graphics card, then change your backend to Direct3D and all will be well. Found this out the hard way yesterday after repeated hard freezes as apparently opengl is now borked for AMD card users especially with Crimson drivers. Really need to go back to Nvidia, fucking AMD can't do anything right.

I just did some quick testing, ppsspp 1.3 opengl is working for me. I'm on an R9 285. Retroarch version has always worked, but it's well behind at this point. I'm still on the 16.10 drives through, 16.11 might break it.

It may depend on the game, I'm not entirely sure. Test Star Ocean 1 or 2, it locked up for me in both. Let the opening gay anime cutscenes play in either game. Soon as they finish and you're about to enter the game, the screen should freeze with garbled graphics and you'll get an error about emuload. You'll notice even after closing the exe in task manager, your gpu fan will continue cranking up and you'll need to reboot. This is with very latest Crimson drivers and latest PPSSPP build, but I tried various older versions and it still happened. This was mentioned all the way back in 2013 and still in 2016:

http://forums.ppsspp.org/showthread.php?tid=4279 (mentions disabling catalyst AI which I did with regedit, made no difference)

http://forums.ppsspp.org/showthread.php?tid=18878

"Seems to be a failry common problem for me as well on 1.1 and above. SRT Z2-1 crashes right after the intro with the message "AMD video driver successfully restarted", AND YET SRT Z2-2 works as well as it has been.
Switching to D3D works, so i guess the OpenGL is screwed for the time being. Probably because of Vulkan (which also doesnt seem to work)."

 

[tuluse]

AMD has always had poor opengl support, so it's not too surprising. Ironically their open source initiative on linux might end up improving this.

 

[A user named cat]

Either way, I'm probably going to grab a GTX 1060 6gb as PNY has a pretty cheap one at the moment, then just sell this r9 290 on ebay. It's been nothing but problems and missing driver options since day one, then worsened with the introduction of Crimson. Even AMD's stupid External Events service that is installed and enabled by default causes a 5+ second delay when booting in Win 7. But with it disabled, your game profile settings get reset every boot. Plus this opengl headache, poor AA performance and other quirks. Nothing but problems.

 

[tuluse]

Found a neat utility to add roms to Steam https://scottrice.github.io/Ice/

It's nice if you're like me and want controller friendly front end, for which I don't believe a good one exists for PCSX2 or Dolphin. Everything else is through retroarch anyways.

It was the missing puzzle piece to complete my livingroom experience (short of retroarch cores for those two).

 

[sullynathan]

a good one exists for PCSX2

PCSX2Bonus is pretty good and controller friendly. It also allows for custom configurations.

 

[A user named cat]

Found a neat utility to add roms to Steam https://scottrice.github.io/Ice/

It's nice if you're like me and want controller friendly front end, for which I don't believe a good one exists for PCSX2 or Dolphin. Everything else is through retroarch anyways.

It was the missing puzzle piece to complete my livingroom experience (short of retroarch cores for those two).

Why not use a proper frontend? Hyperspin, Gameex and Launchbox are the best options. They're all controller-friendly too.

I'm a longtime Hyperspin user and contributor but I'd ward people off from it if they don't have the time to set it all up as it's more of a hobby than anything. The end result is worth it though. However Launchbox is much simpler and won't require you to have per-system themes. If you do go this route, I'd highly recommend using RocketLauncher as well to set up all your systems. Having an Emumovies account won't hurt either if you want gameplay snaps, many of which I recorded for them.

 

[an Administrator]

Guys what's the best emulator for PS Vita? Do i need Win10 for it?!

 

[spekkio]

L2R / GTFO.

 

[an Administrator]

There was nothing for PS Vita in the first post.

 

[spekkio]

Well, you are halfway there, Andy...

 

[flyingjohn]

Guys what's the best emulator for PS Vita? Do i need Win10 for it?!