Pcsx2 mac os x mavericks

Already on GitHub? Sign in to your account. This leads to the suspicion that a proper port to OSX wouldn't be a herculanean task. The free OSX Given the fact that Instead of plowing through the codebase, I'd like to ask the devs: Porting gsdx ogl to osx won't be difficult. It mostly need the bits to create the ogl surface and context. Then various ifdef linux must be checked. It would also need pthread or a port to std:: In my own projects I tend to use SDL2 to get a surface.

I've noticed in build. A bit of googling says that it doesn't, but I could be wrong. Is the --sdl2 option actually in use? And after trying to build it I suddenly realize why this might be harder than anticipated: That usually causes no end of troubles on systems where bit is uncommon such as OSX Porting to X64 would have exactly the same issue as porting to ARM: There may be LESS work involved in porting to x64, but it would still be a huge project. I wasn't advocating porting to bit despite possible dis advantages, as it would be a lot of work as you said.

Just mentioning to myself and others who would want to attempt the same that this might be one of the reasons why pcsx2 doesn't have an up-to-date OSX build. Same here, I was just mentioning, in case anyone wondered, that the porting would require a huge effort. I guess I should have specified ;P.

You get the glx file and you replace glx with the name of osx api. It took me 1 or 2 days to port linux ogl to windows and I'm not even sure I booted on a win machine to test the code. Besides you can based the code on zzogl mac. But we don't want an extra dependency on windows. Besides it creates subtle issues for packaging. After looking at the situation a bit more, I agree.

By the way: I usually prefer sdl2 because I like to avoid working with Objective C whenever I can. What do you mean by extra dependency? If people don't want to, sdl2 doesn't need to be included for windows. Not sure what packaging issues you guys face, but in my projects I just statically link with sdl2, no problems afterwards.

All that seems to be just peanuts in comparison to the bit issue though, that's the real killer because it touches the most complex part of the code. Wx just use std os api as sdl. However wx could potentially depend on sdl. That mean you also need to package wx. Anyway it isn't the linux way. By the way when I said surface, I meant the gl back buffer not the window. The window is already created by wx. So it only miss CGL hum maybe C stand for cocas: Either you copy the one from zzogl and you rename a couple of variable.

Or you could use sdl on mac. Possibly, although in the age of OSX It wouldn't matter anyway. Since modern OSX is very bit focused, you don't generally have something like multi-arch. Moreover, OSX So you can't use the same trick as on linux:. Running bits code seems to be more or less ok, at least for console programs. I'm not sure how GUI programs deal with it, I don't know if apple still deploys bit.

For a simple console program one just needs to supply the -m32 flag to both the linker and the compiler. I just tested with a very simple AppKit binary, and it still seems to work with the -m32 flag, which probably means that apple distributes some important. It gets a bit nastier when you're using lots of libraries though. This basically means that for a bit OSX build, all libraries would have to be compiled on the spot by the buildsystem instead of downloaded with a package manager like the populer homebrew.

A bit like neovim does when it can't find the right dependencies libuv and luajit. As far as I know you can still compile code for i in clang with -arch i The system shared libraries e. You'd just need to explicitly compile any 3rd-party dependencies for i and it would work just fine. Exactly, compiling every non-system dependency is definitely a prerequisite.

In my very simplistic tests with some Cocoa things I only needed to specify -m32 , how is -arch i different? Gl must be fine. I used various gl4 functions but they aren't yet mandatory. Actually I managed to run gsdx on gles3 on the past. Extension checking is done on GLLoader. If you can generate me a list of extension supported I can tell you the limitation.

Is the list provided by chrisballinger not sufficient? Should I check on my Mavericks unit? Presentation of the list suck. They could have sorted it by gl version. Anyway it would be fine, it will use several slower code path but nothing critical. However I do hope they release a newer version that support a better glsl syntax.

So I can drop various useless code. Note for debugging: Just disable geometry shader and enable shader debug too. Could you detail what that is please? I'm curious. As I understand you now, version is not enough?

• delete skype chat logs mac!
• Tutorial: How to get PCSX2 to run on Mac (without BootCamp).
• download subversion 1.6 for mac.
• install windows 10 on mac without bootcamp.

Most "modern" glsl features do seem to work in my tests. See that http: For example it allow to set an index of various parameter. Current method is to let the compiler set a random position. Then get current location of the parameter program, and then set it. Lots of work for nothings.

Those extensions are only useful to make the code faster and cleaner. It would work flawlessly without them. However it doesn't seem to be possible with uniform buffers yet, you would need OpenGL 4. As far as I can see, OSX You're right, I had misread, explicit uniforms are indeed an OpenGL 4.

PS2 Emulator for Mac OS X

That said, these things aren't the most important missing things, they can be fixed with some boiler-plate on the client-side and by using fixed names in the shaders which is a good idea anyway. I'm more "worried" about features in 4. Deps brew install cmake brew install wxwidgets --universal brew install glew --universal brew install portaudio --universal. As for the gtk dialogs, TBH they're just dialogs to end up with a gsdx. One could as well make the config a stand alone application which gsdx invokes and then waits for it to complete, then read the ini file. Here, send a pull request to the homebrew repo https: On what system do you compile and which XCode version?

What builds successfully? PCSX2 itself? Does it run? Any other info? Do you have patches you're happy with and can do a PR?

1. !
2. PCSX2 Ultimate for MAC.
3. !

First of all, apologies for my long silence. I have a new job and I've moved countries. Things are still not as quiet as they should be and I've still got much to learn at work so I don't expect to have loads of free time. So I started my porting work by wholesale porting the codebase to work on bit OSX PR , in the top post you can see what's "done", e. Needless to say, this means I'm unable to test anything at all until I get a binary compiled. And most likely when that happens, the binary will instantly crash.

To counteract the fact that my approach is the crazier one, I'm trying to create small, focused commits so they're easily reviewable. That doesn't really offset anything of course. Here is now latest status: I have not been able to solve mmap problem in 32bit OSX. It causes random runtime pagefaults and GSdx cannot even execute properly.

Any help on this topic really much appreciated. Little bits: GSdx still requires OpenGL 4. There is gtk-mac-integration that makes GTK applications seamless with the Mac desktop, so we don't need to write new GUIs for the plugins. Posted 20 January - Posted 04 February - Community Forum Software by IP. Board Licensed to: The Porting Team. Porting Team v3. Community Status Updates: Javascript Disabled Detected You currently have javascript disabled.

OS X I want to give this to devilhunter for inspiring me to take a look at this kind of stuff. I also want to give this to Iska because if he hadn't posted this I wouldn't have done this. P CSX2Ultimate. E xtraPlugins. I need to find a place to upload it. Mac OS X Quote There are over plugins for you to use. Sadly, I am not active here on the Porting Team anymore, and therefore I cannot give support or answer questions to any of my posted Ports or posted topics.

There are the best GSdx plugins in there. I can guarantee that every one of them works. The only problem is that GSdx10 plugins don't work.



I had left them in there in case that someone hopefully manages to make them work. I guess for now macs only support that. I put in a lot of ZeroGS plugins are in too.

PS2 Emulator for Mac OS 10.8+ - How To (PCSX2 Tutorial)

I will edit my post soon about which plugins work and which don't work. I will also seperate the files. I'm also glad you took a look, I hope that this will satisfy you and all other fans or pcsx2. I will stay on hunt for better plugins. I don't know but it doesn't work for me. I might work for people who has the latest desktop mac that is out. I have managed to get one to work but don't remember which one it was and Btw, the plugins are new: Stein Kama.

Does this use bit or multiprocessing or any other optimisations that PCSX2 has? D Perhaps someday Sorry I wrote a whole post and it accidently went back a page and clicked foward and erased everything but getting to the point The "chinese" plugins are not fake and work very well. The developers and coders are doing the best they can to make the plugins better and faster.

PCSX2 Emulator for PS2 on Mac OS X | Emuparadise

I am trying to fix that. I don't have everytime in the world to do this so if I am taking a little long sorry. D I forgot to mention that if you are clicking settings and trying to get the best graphics it is expected to get slower. HQ or you can just call it "HD" if you want but incase you wanted to know mostly the plugins take up the space aswell as the programs.

I will try to make it much smaller and takes out all the multiple plugins but the point of that was to be that if those plugins work on your mac have fun if they don't work on someone elses that is just a letdown. So can you give me some suggestions on what to do? I have Bleach: Versus Crusade running full speed at the highest graphic settings, and also have Naruto Shippuuden: Though what you are saying has a point.

This has already been posted but here are the latest builds for mac. Snow Leopard http: I know obviously it uses it in windows I know it greatly benefits from bit in particular. I see I also heard but is a mac already overclocked when you buy it? Quote I also heard but is a mac already overclocked when you buy it? What I meant was that it takes up the memory you are using on your computer. I noticed that when I was using pcsx2.

Then following it by we need a better Graphics Card. Other than what I said is there anything I must explain for you to understand? O should I go into it that deeply. My mouth had dropped when I read that. That little? How do they do it?? I found that quite interesting and looked that up and found something interesting. Z Buffer Dolby Digital 5. It seems the PS2 required some overclocking too. It also shows "48" hardware channels. Thats just ridiculous.

Why the need? They also managed to get it running the way they wanted it with AA 2x with Billinear filtering and more?