Can anyone help me? I’m running the 32-bit version of RetroArch Phoenix and the game runs smoothly until about five minutes in, the emulator starts to chug as if it were constantly being paused. It stops when I quit the game, only for the same problem to reoccur when I play something else. Any help would be greatly appreciated.
It is possible that the log is being spammed down. This will cause it to grind to a halt. Could you check if it’s constantly being spammed down with something?
How do I check for that?
File -> Show log
Ok, I’d like to post my log, but the forum tells me it’s too large to post.
post it somewhere like pastebin and copy the link here
Ah, you’re using an outdated RetroArch build. You’re using an updated PCE core which tries to use very recent retroarch functionality, and it logs an error each time it tries to use it.
I don’t understand. I just redownloaded the latest version through the official website and check for updates within Phoenix, and it STILL acts up.
I’m hijacking this thread because it’s tangentially related and because I’m sick of this. So sick. The issue is that the Windows binary never gets updated, but the cores do so the entire package is fundamentally broken unless you compile it by hand. Okay, great. So I download msysgit which I had assumed would have been a very small package, but when it’s all said and done it weighed in at about 1.6gb on my harddrive just so I can download from github. The issue is that it won’t even build for me regardless of whatever I try. RetroArch needs zlib.h (WHICH IT HAS) but refuses to acknowledge its existence, and Phoenix needs dinput.h. Going to Microsoft’s site reveals that the DirectX SDK is 500mb, and I sure as hell don’t trust downloading just dinput.h by itself… I can’t do this, it’s just too irritating.
Simmer down, bro. A lot of things have been in flux lately, and we’re right on the cusp of a new release, so some things are on the new paradigm and some aren’t just yet. It happens sometimes.
If your system is 64-bit, you can use these (drop them into your folder with the last official release and overwrite): https://s3.amazonaws.com/Emulation/RetroArch/retroarch-git-Apr16-2013.zip
If you’re on 32-bit, perhaps someone else can step in and provide some binaries. Otherwise, sit tight for just a bit until the new release is ready.
Vista
Although this isn’t the cause of the problem, I would suggest upgrading. Windows 7 is great, and if your system is very low end, you can put linux on it. There’s no reason to use Vista in 2013.
I apologise if I come off as rash, but this is something that continues to give me trouble. Nevertheless, I took a deep breath and started poking around with what limited knowledge I have. I think I’m quite close to completing the compile but it continues to elude me. Mucking about with SDL and SDL_image was more or less mere tedium, but now I seem to have hit a brick wall.
I get up to gfx/gl.c and I just get spammed with a ton of error messages. I tried looking around for OpenGL headers because that is what I had been doing up until this point, but apparently this is not the solution, as I could not find them on the internet. It was at this point that I remembered that there was a setting in Makefile.win for disabling D3D, so why not disable OpenGL support? That works well enough, but now input/overlay.c is giving me headaches, spouting such errors as:
input/overlay.c:71:4: error: unknown type name ‘video_overlay_interface_t’ input/overlay.c: In function ‘input_overlay_set_scale_factor’: input/overlay.c:184:13: error: request for member ‘vertex_geom’ in something not a structure or union
And so on. With all of the other stuff that I had faced prior to this, I at least had an idea of what to correct, but this is proving to be quite cryptic. I think I’ll just leave it up to the people who know what they’re doing.
You don’t have to hunt down libraries yourself. If you read the compilation guide, I’ve compiled headers + libs for MinGW (32-bit and 64-bit). Anyways, 0.9.9-wip1 is out now.
hahaha So that’s what I was missing the second time around. What had lead to my first post was following the compilation guide to the letter, and the second time was me completely abandoning msysgit in lieu of just hitting “zip” on the github page, but unfortunately I forgot to add the libs+headers that I so desperately needed. Downloading a repository via HTTP seems to work better for me, but I can’t be absolutely sure that it would be the same for other people. Is there some sort of advantage to using git instead of github’s zip functionality?
In any case, I wish to thank all of the fellows in this thread for their time and patience spent. Just in general.
@rainirm
I’m glad you got it sorted out 
The only advantage to using git is that it can track the remote repository. In that case, you can use ‘git pull’ to just download changes (instead of downloading the entire repo again) and, if you made any useful changes to the source (hypothetically), you could submit a pull request and easily merge it into the official source tree (rather than making a patch, which is often fiddly).
For most simple download-and-compile situations, the zip method is just fine.