GNU/Linux Support

[ghost]

Hey, Is there any linux support ongoing or planned? I guess your renderer is GL/GLES based since android and OSX ire supported right? Are there any particular blockers for linux build? Something we can help with? Since it runs on OSX must be quite near I guess, something like UI? BTW, do you support 64bit? I don't seem to see any asm bits, are code emiter that are host specific. Overall your code looks quite clean, quite nice, if linux is possible I would be very happy to help(also, if anyone else has already worked on it...)

[jpd002]

Yes, I'm planning to add Linux to the supported platforms at some point. There has been some work done by @Alloyed to make the emulator compile a standard Unix box (https://github.com/jpd002/Play-/pull/314), but I didn't have time to check out his work yet. I don't think it would be too hard to make it work completely on Linux though.

And yes, x86-64 is supported, but there might be some tweaks to do inside the code generator to properly support the ABI.

[ghost]

Ok, I am looking around the project. I will try it, and see if I can help for failing tests. BIOS/ROM is HLE too? I see the code gen seems to be completely separate too, how nice :) There is some kind of IR? You generate code with standard constraint, like SSA?(I did not yet look inside code gen, mostly structure for now). If you need help with IR parts, IRs are my life, register allocation and such optimizations are also an important part of it, or at least of my readings and work ;) For plugins, you are compatible with pcsx2? GSDx OGL/liux is in very nice shape now. Factorizing work with it would be quite nice I guess, the more work goes in the same sense, the better. I see a branch name gregory, is it for gregory hainaut?

[jpd002]

Yes, the kernel is done in HLE. No BIOS is required.

The code generator does have its internal IR. It also uses a kind of SSA form to do its optimizations. The register allocator would definitively need some more love because it doesn't generate the best results.

Play! is not compatible with PCSX2 plugins. The gregory branch contains the changes needed to make Gregory's Horror Show boot.

[forcejackson]

Any chance we can see a Linux build sometime next month, maybe?

My other PC is a Linux machine and I'd do the deed of testing compatibility and even GUI stuff later on when I can manage a build or instructions on how to build for Linux.

[jpd002]

Can't guarantee anything for next month, but I've been working on making things work on Linux and FreeBSD. I'll probably merge @Alloyed's PRs very soon as I've got almost everything from his PRs working on my side.

[mrcmunir]

Compile are fine or are incomplete?

I have some issues when search pthread_create - not found

maybe cmake bug? I use archlinux

Edit : strange.. because in my computer are found

If search with nm /lib64/libpthread.so.0 | grep "pthread_create" 0000000000007780 t __pthread_create_2_1 0000000000007780 T pthread_create@@GLIBC_2.2.5

[jpd002]

I got it to compile and link on FreeBSD as of today. What's the error you're getting?

[mrcmunir]

-- Looking for pthread.h -- Looking for pthread.h - found -- Looking for pthread_create -- Looking for pthread_create - not found -- Looking for pthread_create in pthreads -- Looking for pthread_create in pthreads - not found -- Looking for pthread_create in pthread -- Looking for pthread_create in pthread - found -- Found Threads: TRUE
-- Configuring incomplete, errors occurred!

No detected undefined reference `pthread_create'

but the pthread library is found at: $ locate libpthread /usr/lib/libpthread-2.21.so /usr/lib/libpthread.a /usr/lib/libpthread.so /usr/lib/libpthread.so.0 /usr/lib/libpthread_nonshared.a

the parameter -lpthreads has an 's' too many maybe this a problem?

[Zer0xFF]

I was looking into how i could add a linux UI for Play! since we can already compile the project for linux and to my surprise how ready everything was, if anything this is a testomy to how clean the code is written, add that was need was just few lines to create a OpenGL window and the emulator was alive.

if you'd like to test it, you can just try this branch, you'd need few more libraries which you can get with (ubuntu): sudo apt-get install libmysqlclient-dev libbz2-dev libglew-dev xorg-dev libglu1-mesa-dev -y;

git clone https://github.com/glfw/glfw.git
cd glfw
mkdir glfw-build
cd glfw-build
cmake ..

make
sudo make install

if you don't have boost setup already https://sourceforge.net/projects/boost/files/boost/1.60.0/ i usually use the tar.gz version

tar xvf boost_1_60_0.tat.gz
cd boost*
./bootstrap.sh
./b2 -mt
sudo ./b2 -mt install

Edit3: Almost there, you need to add #include <GLFW/gflw3.h> to Framework/include/opengl/OpenGLDef.h to linux section.

cd Play-Build/Play/build_unix/
./build.sh
./build/mainui

this is very permeative, i've 'hacked' a way to add some control to see how far into the game this would run and everything seems in order so far, I couldn't figure out how to use the current method with glfw, so i found it easier to do this for now, currently the location of iso is hard coded, so you'd need to edit that to find your game.

although this isn't my area of programming, summer break is soon here ( 2 more weeks), and i plan on doing a lot of reading in regards to this area in an attempt to get a linux client up to current standard.

FFXII, FFXII some rendering issue FFXII ran with a slow FPS, nothing to surprising, but navigating the menus, 2D, was really smooth, considering that, i know you've been testing Odin Sphere a lot, and its a 2D game, so i gave it a go, and it ran really well. Odin Sphere

Edit: I was going to test Tekken 5, but to my disappointment it had the fifa 08 disc inside the case :( anyhow, i added a fps counter into stdout.

Odin Sphere runs at 60fps in the menu, level selection screen, then drops to 30fps in gameplay, its a consistent drop so i think that might be hard coded?

FFXII, runs 20-24fps in intro video, 44fps in the menus, and drops to 10fps during gameplay.

side note, both games ran better on my ubuntu desktop then my OSX mac air although i5 should have been stronger CPU/GPU, ill see if i have the time to test ubuntu on the mac air, to test Play's performance too. http://cpuboss.com/cpus/Intel-Core-i5-4250U-vs-AMD-Athlon-II-X2-245 http://gpu.userbenchmark.com/Compare/Intel-HD-5000-Mobile-1011-GHz-vs-ATI-Radeon-HD-4200/m8536vsm8091

Edit2: if you're testing this, you should look at this to know which controls are mapped to which

[jpd002]

Nice work! I have a Qt UI in the works (it's incomplete and haven't touched it recently), but I've only got rendering working so far (no input at the moment). I will push my branch later.

[Zer0xFF]

Qt isn't a bad idea, since it's cross platform, you can eventually have a single uniform UI between linux/osx/windows.

Edit: I've also ran copy of ubuntu on my mac, Play!'s performance was better on it than osx and on par with my ubuntu desktop, not sure if its due to osx specific code, or compiler specific, since Xcode has stripped down compilers compared to gnu/linux, as such compiling boost on mac always throws few, lack of XY optimisation warnings. Edit2: with that said, i see no difference in performance between android built through ubuntu or osx.

just a side note, Qt and glfw don't work together, but thats fine, i choose glfw for convince as a test run.

[Zer0xFF]

whenever I'm free, I've been experimenting with the UI. I tried Qt and WxWidgets, both with similar results, that is, I couldn't use their native OpenGL widget with Play, both similar problem, in that Play! OpenGL rendering thread seems to start (printf insider PresentBackbuffer()), but nothing would display on the widget (WxWidget complaining about multithreading), however, using something such as xcreatewindow which created a completely different window worked, but you end up with something like PCSX2, with 1 window with the menu bar, another for rendering and a 3rd for logging. since thats all back to personal preference, and if this is what you're going for then we can work with that.

personally I'd prefer to have menu bar and the rendering window as one window, (and maybe a separate logger if you want one), and i managed to get that to work, although, this seems to be a bit 'hacky' but i also think it's a reasonable way to get it done, i basically used a wxglcanvas, (but that also works with wxwindow), and use its native handler when creating OpenGL context.

wxwidget

I'd say this would work the same with Qt as well, but I've noticed that a lot of the emulators are using wxWidget over qt, perhaps because you can just skip the IDE which is 700mb(upto 2gb vs 100mb for wxwidgets).

whats your experience with it? did you have better luck with that?

[jpd002]

I ran into the same problem while experimenting with Qt. I had to go through some hoops to get the emulator's OpenGL output to display inside a Qt window, but it works fine. I was also able to create a Vulkan swap chain hosted in a QWindow.

I haven't tried wxWidgets but I don't have a preference for Qt over wxWidgets. I think it would be as good as Qt if it's also possible to create a Vulkan swap chain hosted in a wxWidgets widget.

My only requirement would be to have everything inside a single window (like you mentioned: menubar + rendering as one window).

[Zer0xFF]

I'd imagine you're still using the same GSH_OpenGL class format for vulkan, at which i see no reason why it wouldn't also work with WxWidgets.

but in the long run, i don't think either or will really make much difference, and few gb these days shouldn't really be a deal breaker. so to list few pros and cons and to be honest, they seem rather subjective.

Qt

• IDE+Debugger is a small bonus if needed, though i don't see a complex design to justify it either.
• Size 700mb+
• include collision? (due to class extension)
• Multiplatform.

WxWidgets

• Small size 100mb
• no include collision
• No IDE or Debugger
• Multiplatform. https://wiki.wxwidgets.org/WxWidgets_Compared_To_Other_Toolkits#Qt

I'll push my work of wxwidgetx to a separate branch so you can compare how they both work, around this time tomorrow night hopefully.

[jpd002]

It's a bit different, you need an xcb_connection_t* and xcb_window_t to create the Vulkan swap chain. Qt provides a pointer to the connection through QX11Info and the window can be obtained by casting a QWindow's winId member.

[Zer0xFF]

Display * m_display = XOpenDisplay(NULL); // will work on independent of Qt/WxWidget
//xcb_connection_t *m_ xcb_connection_t = xcb_connect (NULL, NULL);  // will also work on independent of Qt/WxWidget

Window m_window = (Window)GDK_WINDOW_XID(gtk_widget_get_window((GtkWidget*) glcanvas->GetHandle()));
//xcb_window_t m_ xcb_window_t = (xcb_window_t)GDK_WINDOW_XID(gtk_widget_get_window((GtkWidget*)glcanvas->GetHandle()));

//GDK_WINDOW_XID returns XID which can be casted to either types

glXSwapBuffers(m_display, m_window); //<-- this is what I'm doing in wxwidget which is actually independent of Qt/WxWidget

passing xcb_window_t / Window to CGSH_OpenGLUnix::GetFactoryFunction() will allow you to keep the context creation and swap completely independent of Qt/WxWidget as well.

Link:You can now mix calls to XCB and Xlib. The datatypes of the two systems are somewhat interoperable; for example, you can use an Xlib Window anywhere an xcb_window_t is required. In general, XID types like Window (X.h:typedef XID) are synonymous with their XCB equivalents.

More: https://xcb.freedesktop.org/xlibtoxcbtranslationguide/

Edit: don't think ill be able to push wxwidget today, have an exam tomorrow, and i know me, a 2 minute cleanup will turn into a 2 hours ui building :/

Edit2: wxwidgets branch, just basic input, sound, rending and file selector. to test this branch you'd need gtk3 dev and latest stable wxwidget. (just a fair call, current context creation code was taken from PCSX2, there is nothing unique about it, but to speed getting this set, but just mentioning this for fairness sake).

@jpd002 ^branch there, its your call now, Qt/Wxwidget once you decide, you can either push the Qt branch so i can build on it, if there is anything more to add that is, or I could start from scratch, or I clean up this branch for a PR.

[jpd002]

Thanks! Can't really build it at the moment, but I'll take a look this week-end when I get back home.

[Zer0xFF]

to have an educated opinion about Qt vs widgets, I've setup qt and started working on the UI. needless to say, I found it much easier working with qt, because of the IDE, so much so, I ended up continuing the work until i got a working settings dialog. the ui can also be built using IDE or terminal.

you can find qt branch here and I'll send a PR tomorrow or the day after, after I prepare a small write up of the needed packages for the build.

edit: also before i send a PR, you never said, if you'd like to push your work to build on, or if i should push mine.

[mdeguzis]

Does the Unix/Linux build require a minimum versions of standards? (-DCMAKE_CXX_FLAGS="-O2 -g -stdlib=libc++"). Build log: http://sprunge.us/TiEY

[Zer0xFF]

I'm not sure whats causing your error, i couldn't find any reference to change in static_assert between 4.9 and 5.4, however, I couldn't get travis to work using gcc 4.8.4 but worked with gcc 5.4, they're different errors but perhaps its worth a shot.

[mdeguzis]

Debian Jessie is way old with gcc unfortunately, but I play on putting together a test Arch Linux AUR package as well. I wonder if this will build ok with clang/clang++?

[Zer0xFF]

@jpd002 last commit to master was "fix build on clang", so I guess it would. I know Ubuntu has a test repo with upto date gcc for older distros, maybe debian does too?

[mdeguzis]

Yea using clang seems to do the trick for those not on GCC5. I'll know if GCC5 is good as well when I test out an AUR package. See debian/rules for Debian' folk.

[mdeguzis]

Ok, built the project with clang 3.8. Is ./Play/build-ui/Play-Ui the executable/binary I am looking for? Do I need to include any other directories for run-time?

[Zer0xFF]

Ya that's it, what do you mean by other directories? That's the only bin you'd need, framework, CodeGen, play library are all statically linked, I think qt and boost are dynamically linked.

[mdeguzis]

If they are staic, that's what I mean, if installed to /usr/games or /usr/bin, I might need to include those directories in /usr/share/games/play for modular use.

[Zer0xFF]

You can use ldd to confirm the dependencies.

[mdeguzis]

Oh I know that part, i meant more along the lines of assets. I typically like lddtree for lib checks.

[jpd002]

Closing this, the Linux port is working now.