Next Generation Emulation banner
1 - 18 of 1133 Posts

· Registered
Joined
·
47 Posts
@oleg5891 I have done some work on fixing the problem you have encountered as well as updating the UI with the needed configuration options for PGXP on my own fork. You can find it in the pull requests in @iCatButler 's GitHub repository or you could go directly here. You will have to compile it yourself though and if you do, you will need to compile it for 32bit as it doesn't include @MrLavender 's changes.

@MrLavender, I have tested your changes with a x86_64 build on linux and they do not work. PCSXR segfaults on a failed assert. I have not investigated any further for now but when I do I will report back on your PR, if that is ok with you.
 

· Registered
Joined
·
47 Posts
Sure :) I didn't actually test the code on Linux myself, I just assumed that since everyone except Microsoft uses the same 64-bit calling convention that it would work there too.

Out of interest, what assert does it fail on?
It fails with this message
Code:
pcsxr: ix86_64/ix86-64.c:160: MEMADDR_OP: Assertion `!isreg || reg != X86_TEMP' failed.
This is the result of a 64bit build, with either gcc or clang.

On a sidenote, I would like to point out that the segmentation fault might or might not be directly related to this because different compinations of compilers, architecture, optimization options or even sound plugin backends have been yielding different results on the mainline PCSXR too. My working testing compination so far has been
Code:
gcc, -O2, 32bit, openal
because clang and any other sound backend fails. I don't have an exhaustive list of all the combinations that work or fail yet.
 

· Registered
Joined
·
47 Posts
@MrLavender, thanks for looking into this further. Tbh, I suspected that it was something about the implementation, because of the erratic behaviour with different compiler opts, but I had nothing as substantial or verified as you do. It would be nice to have x64 support, but only because we wouldn't have to rely on multilib. Otherwise, I believe there are no perceivable performance gains from it at this time. Also, as you mention, plugin compatibility might be more important.

I might look into it when I find the time and willingness, but I doubt it will be a fruitful endeavour anyways :(
 

· Registered
Joined
·
47 Posts
No, it is not supported directly to launch per-game configuration for plugins. You can work around that by using multiple configuration files for PCSXr and using separate plugin directories for each different configuration, since plugins save their cfgs in the same directory they reside.
 

· Registered
Joined
·
47 Posts
Yes it is possible but it requires quite some manual work to bring all three (Linux(GTK), Windows(Native), MacOS(no idea, something else)) interfaces on par (that means, working consistently and in the same way) and people that have access to each system. Over the top of my head, someone could try to compile the GTK3 interface on Windows but surely he will encounter a number of problems as many things are specific to linux in there. Also, he will lose access to some Windows plugins. Imho, it is not a viable thing to do.

It might be better overall to move to a new UI for all 3 platforms (Qt maybe?). I also remember @iCatButler mentioning in an issue in beetle-psx repo, that he wanted to port his work to libretro, which would be a fourth interface basically.

@TheDimensioner, thanks for asking the important question. I would like to explain the issues I have encountered with syncing of the two code repositories but that is a long post with information I should verify first. Maybe later.
 

· Registered
Joined
·
47 Posts
There should be none. This is basically @iCatButler 's fork in sync with the last changes on codeplex. My own further changes were mostly on the linux specific code and I wanted to test if I introduced any issues in producing or running the windows binaries. I thought it would be nice to share. You can check the complete commit history on github if you like.
 

· Registered
Joined
·
47 Posts
Just wanted to thank you for all your hard work. I found this error after 8 hours of tinkering with icatbutler's source until I finally got it to build in Linux so I really understand the tremendous effort you put into this.
Well thanks! It was a rather interesting exercise on how to sync two repos that had drifted apart and see how everything was done at the same time. To give credit where it's due, @MrLavender was the one who fixed the dynarec to work on x64, I just found out why it would fail on linux.

Because @MrLavender 's fix is an open pull request in @iCatButler 's repo, I haven't included it in my published branches to avoid merge conflicts. You will need to download it as a patch and apply it manually before compiling.
 

· Registered
Joined
·
47 Posts
First of all, you seem to make too many assumptions. You assumed that I was telling you to be happy about it and you assumed that you should not report any issues or criticize it. What I actually told you, and you didn't pay attention to it, is that it is OPEN SOURCE, and it is made/fixed/improved by people who voluntarily have worked on it, and they also offer the code for everyone else to see it and play around with it. So instead of vending your frustration, you could very well report the issues, document them correctly and thoroughly or even lend a helping hand into fixing them by improving the code. None of us here created PCSXR, we merely tested it, improved it or adapted it.

And since you mention something about the world becoming a better place to live in, you should pay attention to the difference between criticizing and attacking something. Calling it crap is the latter rather than the former.
 

· Registered
Joined
·
47 Posts
Ok, let's stop before this thread gets polluted with arguments and goes completely off-topic.

@Quaoar, we cannot understand the nature of the slowdowns unless you provide us with some basic details. Your initial post was more of a rant with occasional hypotheses about why it is happening rather than actual information. That is hardly helpful to anyone who might want to take a look at those issues. The information we would like to see instead of how crap it is, would be things like, but not limited to, your system configuration, your operating system, what plugins you are using, where did you get your binaries from, did you compile them or did you download them, what bios version are you using, what is the region of the games you have issues, what settings are you using or what have you tried to remedy the situation.
 
1 - 18 of 1133 Posts
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Top