Jump to content

  • Log in with Facebook Log in with Twitter Log In with Google      Sign In   
  • Create Account

Help Building a Custom Wine Engine (winmm joystick Wine 1.9.10)


  • Please log in to reply
21 replies to this topic

#1 davidl42

davidl42

    Regular Member

  • Members
  • Pip
  • 15 posts
  • Graphics Card:NVIDIA 780M
  • Operating System:Other OS/Not specified

Posted 03 June 2016 - 01:28 AM

I'd like to test out some custom joystick code, but I'm having trouble building a custom wine engine in Wineskin. I've outlined the problem in the post below.

While I try to figure this out (any help on that front would be appreciated), would someone mind building a custom wrapper for me? I noticed that last year Ken Thomases made a winmm joystick driver for the Mac (yay!). I've discovered a small axis mapping error where the slider is supposed to be mapped to the Z-axis (confirmed using Microsoft's directX -> winmm directions as well as the Linux version of the driver). For some really old games, you have to have a Z-axis allocated to allow the Rz axis to be mapped (later winmm games don't). I put in a small correction into joystick_osx.c for this slider to Z mapping (as well as adding multi-axis controllers) and would like to test it out (for those interested, my test case is Red Baron 3D, which is one such old game). I'm embarrassed to admit I can't figure out how to attach the file in this forum. :rolleyes: So here's a Dropbox link: https://dl.dropboxus.../joystick_osx.c

Cheers,
David

EDIT: In case someone had experience this before or had any advice on building custom wine engines in Yosemite, I moved the information about the errors I'm getting into the post below.

#2 davidl42

davidl42

    Regular Member

  • Members
  • Pip
  • 15 posts
  • Graphics Card:NVIDIA 780M
  • Operating System:Other OS/Not specified

Posted 03 June 2016 - 09:41 PM

I'm running on Yosemite 10.10.5. I installed Xcode 4.6 and installed the 10.6 SDK from the link doh123 provided in a forum thread. My current Xcode is 7.2. Installing gcc-4.2 through Wineskin didn't work out so well (created linking errors for some reason), so I followed some advice online and created sym links gcc to gcc-4.2 and g++ to g++-4.2. This seems to work. Since I was running python through anaconda, I had to comment out the prepended path to my anaconda folder because Wineskin was finding the libxml2 and libz dylbs there instead of where it should (usr/local). The default folder for libxml2 almost work except for one problem, it still has trouble finding two of the symbols for 32-bit compilation.

Undefined symbols for architecture i386:
  "_xmlBufContent", referenced from:
	  _node_transform_node_params in node.o
  "_xmlBufUse", referenced from:
	  _node_transform_node_params in node.o
ld: symbol(s) not found for architecture i386
collect2: ld returned 1 exit status
winegcc: gcc-4.2 failed

The full output from building the wrapper is here:

https://dl.dropboxus...gine_output.txt

--------
I've also tried building my own libxml and libxslt from here: ftp://xmlsoft.org/libxml2/ but no dice - interestingly Wineskin does "successfully" build a wrapper, but one lacking xml support - it can't install or run programs and the wrapper is obviously incomplete, missing a number of system files and folders. I configure the libxml and libxslt with this:

./configure CFLAGS="-arch i386 -arch x86_64" CXXFLAGS="-arch i386 -arch x86_64" LDFLAGS="-arch i386 -arch x86_64" --disable-dependency-tracking

I also tried it with adding their respective dev packages but it didn't help ...

#3 dankoB

dankoB

    Legendary Member

  • Super Moderators
  • 3011 posts
  • LocationNew Brunswick, Canada
  • Graphics Card:MacBook Pro 11,3
    Core i7 16GB
    NVIDIA GeForce GT 750M
    2GB GDDR5 vRAM
  • Operating System:macOS 10.12 (Sierra)
  • I like to play:la rockitar
Author

Posted 04 June 2016 - 06:03 AM

When you built the engine did Wineskin Winery have the --with-xml2 argument? XML is in the argument list and I have no coding ecperience so I'm not sure if that would even be necessary but I noticed --with-xml is in the pre build argument list but xml2 is not.

Posted Image
upload pic

#4 davidl42

davidl42

    Regular Member

  • Members
  • Pip
  • 15 posts
  • Graphics Card:NVIDIA 780M
  • Operating System:Other OS/Not specified

Posted 04 June 2016 - 11:37 AM

View PostdankoB, on 04 June 2016 - 06:03 AM, said:

When you built the engine did Wineskin Winery have the --with-xml2 argument? XML is in the argument list and I have no coding ecperience so I'm not sure if that would even be necessary but I noticed --with-xml is in the pre build argument list but xml2 is not.

Posted Image
upload pic

Thanks for the suggestion! I'm not 100% certain, but I think the --with-xml flag signifies to use the libxml2 library to build the fake Windows xml dlls and registry editor. It does correctly call the libxml2 library, but something seems to be wrong with my default libxml2 library and the ones I try to install on my own apparently, but don't really fix it. I did try replacing --with-xml with --with-xml2 and it looks like the same behavior as before.

I dunno - I've tried even more combinations, like compiling libxml2 only for arch-i386 and m32, 02, using an old libxml2 library (the default Mac one is old) and the newest version - no matter what the engine says it compiles but the engine is obviously broken and creates wrappers that are missing files and folders. Maybe my SDK or gcc setup is wrong? I have the 10.6 SDK in the appropriate Xcode 4.6 folder, but I don't have a Developer/SDK folder ... does that matter? The Wine logs seem to say it finds the SDK anyway ... As for gcc, in usr/bin I symlinked gcc to gcc-4.2 (and g++ to g++-4.2 for good measure) it says it is llvm-gcc4.2 when I type gcc --version. But maybe that's the problem?

I haven't tried compiling Wine *not* through wineskin. Not sure what would happen.

#5 davidl42

davidl42

    Regular Member

  • Members
  • Pip
  • 15 posts
  • Graphics Card:NVIDIA 780M
  • Operating System:Other OS/Not specified

Posted 06 June 2016 - 02:02 AM

So the programming file in question is node.c in the dll msxml3 lines 1267 to 1273.

#ifdef LIBXML2_NEW_BUFFER
		content = xmlBufContent(output->conv);
		len = xmlBufUse(output->conv);
#else
		content = xmlBufferContent(output->conv);
		len = xmlBufferLength(output->conv);
#endif

On the standard libxml dylib it defines LIBXML2_NEW_BUFFER as true but lacks xmlBufContent and xmlBufUse (at least for i386) - no idea why. I tried to replace each with xmlBufferContent and xmlBufferLength respectively and interestingly it does "successfully" compile then but in fact generates the same bad Wine engine as when I used my custom compiled libxml2 (with the default node.c) - the compressed engine is about 500kb smaller than it should be and any created wine wrappers are missing Program files, most of the system files and folders, etc ...

Does anyone else create custom Wineskin engines on Yosemite? If so, do you remember what you had to tweak, if anything, about your setup to get it to do that?

#6 davidl42

davidl42

    Regular Member

  • Members
  • Pip
  • 15 posts
  • Graphics Card:NVIDIA 780M
  • Operating System:Other OS/Not specified

Posted 06 June 2016 - 03:40 AM

Alright - I figured a way to cheat! :) So I reasoned that the new winmm joystick driver itself was being compiled okay. So I opened up WS9Wine1.9.11.tar.7z (a precompiled engine that I downloaded through Wineskin), found the winejoystick.drv.so and replaced with one compiled from my custom Wine engine version. And it seems to work! Further the slider to control the throttle and Rz-axis seem to work in Red Baron 3D. Some more testing is necessary, but I may be submitting this as a patch!

#7 NRG

NRG

    Champion Member

  • Members
  • 679 posts
  • Graphics Card:Nvidia 9800m GTS
  • Operating System:OS X 10.10 (Yosemite)

Posted 06 June 2016 - 09:50 AM

winm joystick patch, if I'm not wrong, should be contained also into all CX Engines..

Edit: If you want to test it, this is the winejoystick.drv.so taken from latest WS9WineCX15.1.0 engine

#8 davidl42

davidl42

    Regular Member

  • Members
  • Pip
  • 15 posts
  • Graphics Card:NVIDIA 780M
  • Operating System:Other OS/Not specified

Posted 07 June 2016 - 09:22 AM

View PostNRG, on 06 June 2016 - 09:50 AM, said:

winm joystick patch, if I'm not wrong, should be contained also into all CX Engines..

Edit: If you want to test it, this is the winejoystick.drv.so taken from latest WS9WineCX15.1.0 engine

Thanks! Using your file, I can confirm that CX engine behaves the same way as the standard Wine engine - i.e. in Red Baron (and other Winmm games) the joystick slider will not function to control throttle as it should, but overall the joystick works. Which makes sense since Ken Thomases who wrote the latest patch works for Codeweavers who make the Crossover engines. :)

#9 davidl42

davidl42

    Regular Member

  • Members
  • Pip
  • 15 posts
  • Graphics Card:NVIDIA 780M
  • Operating System:Other OS/Not specified

Posted 07 June 2016 - 09:37 AM

I've made a new version of the joystick driver. Full patch notes are here:


This should add support for steering wheels w/ attached accelerators/brakes, 6-axis controllers, multiple sliders/dials/wheels, attached rudder pedals, and attached throttles.  It fixes Slider and Ry/Rx mapping to Z, U/V respectively.

Adds:

OS X Winmm driver will find "multi-axis controller" type in addition to gamepad and joystick.

Add Generic Desktop page:
Adds Dials (Z, Ry, Rx) and Wheels (Z, Ry, Rx)

Add Simulation page:
Adds Rudder (Rz), Throttle (Z), Steering (X), Accelerator (Y), Brake (Rz)

Fixes:
Slider (Z, Ry, Rx)
Ry -> U
Rx -> V

Windows defines Winmm U as Dinput Ry and V as Dinput Rx. Original joystick_osx.c mapping was other way around. This is also a bug in the Linux Winmm joystick version (not fixed with this patch).

This patch allows for multiple sliders, dials, and/or wheels up to 3. First Slider/Dial/Wheel (Z), Second (U), Third (V). In original joystick_osx.c mapping, sliders were not mapped.

https://msdn.microsoft.com/en-us/library/windows/hardware/ff543445(v=vs.85).aspx
https://msdn.microsoft.com/en-us/library/windows/hardware/ff538338(v=vs.85).aspx
https://msdn.microsoft.com/en-us/library/windows/hardware/ff538340(v=vs.85).aspx
http://opensource.apple.com//source/IOHIDFamily/IOHIDFamily-315.7.16/IOHIDFamily/IOHIDUsageTables.h

This should add support for steering wheels w/ attached accelerators/brakes, 6-axis controllers, multiple sliders/dials/wheels, rudder pedals, and throttles.  It fixes Slider and Ry/Rx mapping to Z, U/V respectively. Some of this brings the Mac driver up to parity with the Linux winmm driver, some of it surpasses the latter. (Note: if in the player's setup, the joystick, rudder, and throttle all connect separately to the computer USB ports, then the user will still have to create a virtual merged joystick as in general Winmm only looks at the first HID controller. However, if a joystick identifies one of its element as a throttle instead of a slider or as a rudder instead of Rz, the joystick element *should* now be properly accounted for.)

While the original Rx -> U and Ry -> V found in the current Linux setup and the old OS X setup according to the Microsoft documentation I dug up on translating Dinput to Winmm and back Rx is actually V and Ry is actually U. Go figure ... (unless someone reads it differently?)

Games tested:

Red Baron 3D
X-Wing Alliance (has unrelated graphical issues which only go away running in virtual desktop with X11 - well there are still a couple, but almost entirely goes away)
X-wing vs Tie Fighter

Joystick tested:

Logitech Extreme 3D Pro (12 buttons, X, Y, Rz, Z (slider))

On these games, the slider now controls engine throttle, which it didn't before. In X-wing vs Tie Fighter Rz control was never enabled (as in previous X-wing and Tie Fighter). In X-wing Alliance, the Rz axis always worked to spin. Red Baron 3D, as an older game, assumes that if you don't have a Z-axis, you also must not have an Rz-axis. Thus mapping the slider to the Z-axis for throttle control, enables the Rz-axis for rudder control. Thus it seems to work for my purposes!

Would anyone like to help battle test the new code with their setup/games? It would be good if before I submit that I iron out any bugs (most of the changes are small, so *shouldn't* be any ... but always good to check!). I'd be especially interested if anyone has any 6-axis mice or joysticks with multiple dials/sliders. Of course, it also necessary to have a winmm application/game that supports multiple sliders/dials or a 6-axis controller which is probably a long shot - some of the old flight sims might support that. So I understand if this is difficult to test. Beyond the slider and Rz axis, I cannot test the extra changes with my games/setup. Racing controllers/games should be supported through Winmm too now (if they weren't already covered by the gamepad/joystick routines which they might've been!). So that'd be cool to test as well.

https://dl.dropboxus.../joystick_osx.c
https://dl.dropboxus...joystick.drv.so
https://dl.dropboxus...stomJoy2.tar.7z

These files replace dll/winejoystick.drv/joystick_osx.c and winejoystick.drv.so respectively. The latter can be replaced in wswine.bundle/lib/wine/ folder of a compiled engine to simply drop it in to a current Wineskin engine, tar and 7z everything back up and your good to go! Or if you prefer the simplest way ... you can just download the 1.9.11customJoy2 engine. :) I forgot to update the version file inside the wswine.bundle so it still says 1.9.11 inside wineskin, but it is the customJoy2 version.

Cheers,
David

P.S. Since it seems the Linux version has a bug, though not a very serious one (simply two rarely used axes mis-mapped), should I message someone?

P.S.S. However, if anyone figures out why I can't make full Wineskin engines, it would still be nice to find out! ;)

P.S.S. What would be really cool would be to create Windows registry entries to turn off buttons (or remap them) and axes as some really old games (like Red Baron 3D) have button defaults that you can't override. Of course, I could simply create a version of the driver (for myself) that doesn't recognize any button above the first and then use ControllerMate to map the buttons - but it would be cool to do it inside Wine. I think doing this custom/registry mapping is currently beyond me as an exercise.

#10 ovvldc

ovvldc

    Master Member

  • Members
  • 1255 posts
  • LocationEurope
  • Graphics Card:Intel Iris Plus
  • Operating System:Other OS/Not specified
  • I like to play:stories

Posted 07 June 2016 - 09:51 AM

I know that there is work discussed on the Wine developer email list to have a new joystick/gamepad/input driver. You may want to write to them about your patch and have a look at previous emails (I think it started with this post: https://www.winehq.o...rch/112074.html)

#11 davidl42

davidl42

    Regular Member

  • Members
  • Pip
  • 15 posts
  • Graphics Card:NVIDIA 780M
  • Operating System:Other OS/Not specified

Posted 07 June 2016 - 11:05 AM

View Postovvldc, on 07 June 2016 - 09:51 AM, said:

I know that there is work discussed on the Wine developer email list to have a new joystick/gamepad/input driver. You may want to write to them about your patch and have a look at previous emails (I think it started with this post: https://www.winehq.o...rch/112074.html)

Will do. Based on that first port, that looks to be about a new Xinput driver (the newest of Microsoft's input drivers - used for Xbox controllers and so forth). The winmm input is very old, pre-dinput, so I think they are probably not dealing with it in that particular thread. That said, those are probably people who might also be interested in testing old input drivers! :) There are currently 3 Wine input drivers: Winmm, Dinput, and Xinput - the last I think was still being developed the last time I checked (which was awhile ago) and is what that thread is about. However, they also talk about allowing joystick mapping and overrides in the Wine registry for Xinput and Xbox controllers - if that could be made relevant for Dinput and Winmm, that would be cool!

#12 davidl42

davidl42

    Regular Member

  • Members
  • Pip
  • 15 posts
  • Graphics Card:NVIDIA 780M
  • Operating System:Other OS/Not specified

Posted 07 June 2016 - 11:14 AM

View Postdavidl42, on 07 June 2016 - 09:37 AM, said:

Would anyone like to help battle test the new code with their setup/games? It would be good if before I submit that I iron out any bugs (most of the changes are small, so *shouldn't* be any ... but always good to check!). I'd be especially interested if anyone has any 6-axis mice or joysticks with multiple dials/sliders. Of course, it also necessary to have a winmm application/game that supports multiple sliders/dials or a 6-axis controller which is probably a long shot - some of the old flight sims might support that. So I understand if this is difficult to test. Beyond the slider and Rz axis, I cannot test the extra changes with my games/setup. Racing controllers/games should be supported through Winmm too now (if they weren't already covered by the gamepad/joystick routines which they might've been!). So that'd be cool to test as well.

Actually I was able to test some of this! Even though Red Baron 3D doesn't use all the axes in the game, it does signal to Winmm to read them in. In ControllerMate I was able to create a virtual joystick with 5 axes + slider (X*,Y*,Z*(slider*),Rx*,Ry*,Rz*) using my Logitech (X,Y,slider,Rz) as a base (X*<-X,Y*<-Y,Z*(slider*<-slider),Rx*<-Y,Ry*<-X,Rz*<-Rz). Everything seems to work: Ry is mapped to U and Rx is mapped to V (which I still think is odd, but that's what the Windows documentation said to do ...).

I also created a six-axis controller + slider (X*,Y*,Z*(Z**/slider*),Rx*,Ry*,Rz*) ... since ControllerMate reports the Z**-axis before the slider* it takes precedence and gets mapped to the Z*. I think the Windows documentation expects that in that scenario the joystick would slider* would often be found by the driver first, before the Z**-axis - however, that is not what happened in this case and the documentation doesn't seem to expect that mapping in all cases. (That's one corner case where having registry overrides would be useful so no matter which mapping comes out 'default' based on the controller, the user could always respecify as they wish.)

ControllerMate doesn't have the ability to suppress non-virtual joysticks once a virtual one is created, so winmm sees both the virtual and real joysticks and reads info from both. However, I think the game only reads input from the "first" joystick it finds (the real one). I wonder how to set one USB HID as the "primary"/"first" one in either Wine or in my Mac ... EDIT: actually I'm not sure about that - which one is discovered first, virtual or real joystick, seems to be random ... it is possible the game is reading from the virtual and real joystick at the same time ... hard to tell ... EDIT2: actually I think it might be listening to both! though the from "first" primarily then winmm is also feeding it input from the other joystick and the game accepts the second stream of input too. Interesting ...

One thing I don't take into account is the following note in Microsoft's Winmm documentation:

Note  Mappings for the R, U and V axes fall through to the next axis if a mapping is not found, whereas X, Y and Z mappings are completely independent of each other. This is because VJoyD.VxD only supports contiguous sets of axes (for example, X, Y, Z, R is supported, but X, Y, Z, U is not). The only exceptions to this rule are made for joysticks that use the precise combinations of X, Y and R, or X, Y, Z, R and V. This method of mapping helps to avoid the possibility that JoyHID.VxD makes axis assignments that VJoyD.VxD cannot tolerate.

I don't have the axis map for R look for U and V mappings or U look for V (neither does the Linux code I think), but that's a pretty rare corner case (e.g. joystick tries to map to U but doesn't have an R or map to V but doesn't have a U or R, etc ...).

#13 ovvldc

ovvldc

    Master Member

  • Members
  • 1255 posts
  • LocationEurope
  • Graphics Card:Intel Iris Plus
  • Operating System:Other OS/Not specified
  • I like to play:stories

Posted 10 June 2016 - 08:02 AM

Thanks for submitting the patch, I hope the Wine developers either take it on as is or incorporate it somehow.

#14 davidl42

davidl42

    Regular Member

  • Members
  • Pip
  • 15 posts
  • Graphics Card:NVIDIA 780M
  • Operating System:Other OS/Not specified

Posted 10 June 2016 - 06:09 PM

View Postovvldc, on 10 June 2016 - 08:02 AM, said:

Thanks for submitting the patch, I hope the Wine developers either take it on as is or incorporate it somehow.

Thanks! It looks like I made some whitespace formatting errors. Hopefully I can get it cleared up relatively easily.

#15 ovvldc

ovvldc

    Master Member

  • Members
  • 1255 posts
  • LocationEurope
  • Graphics Card:Intel Iris Plus
  • Operating System:Other OS/Not specified
  • I like to play:stories

Posted 10 June 2016 - 08:35 PM

Alexandre is notorious for taking only correct patches. I think the idea is that fixing people's submissions leads to lost time for experienced developers and the original authors won't learn from it. Don't take it personally, they just want everyone to get into the habit of using their code style when writing patches for their project :).

#16 davidl42

davidl42

    Regular Member

  • Members
  • Pip
  • 15 posts
  • Graphics Card:NVIDIA 780M
  • Operating System:Other OS/Not specified

Posted 10 June 2016 - 08:55 PM

View Postovvldc, on 10 June 2016 - 08:35 PM, said:

Alexandre is notorious for taking only correct patches. I think the idea is that fixing people's submissions leads to lost time for experienced developers and the original authors won't learn from it. Don't take it personally, they just want everyone to get into the habit of using their code style when writing patches for their project :).

Oh absolutely, I understand that with a huge code base like Wine's and so many contributors keeping it all straight under the best of circumstances must be a nightmare. I have to admit, I come from the scientific programming discipline which tends to be much more slapdash/ad hoc for formatting and code maintenance (even when we shouldn't be) - do whatever works for you. Thus, despite having programmed for a number of years, I only recently learned that spaces vs tabs was a programmers' holy war. :)  Heck it wasn't that long ago that I heard about the vi vs emacs wars! Programmers argue about the strangest things ... :P  

So I resubmitted - I think it was a fairly easy fix. We'll see if I got the formatting right (and if there are no other errors of course!).

#17 davidl42

davidl42

    Regular Member

  • Members
  • Pip
  • 15 posts
  • Graphics Card:NVIDIA 780M
  • Operating System:Other OS/Not specified

Posted 10 June 2016 - 11:52 PM

Interesting ... folding back to the topic of missing libraries, I installed the winehq-devel-1.9.11.pkg to see how it fares. When I install a game, I got the following error message:

err:module:load_builtin_dll failed to load .so lib for builtin L"msxml3.dll": dlopen(/Users/****/Applications/Wine Devel.app/Contents/Resources/wine/lib/wine/msxml3.dll.so, 258): Library not loaded: @loader_path/../libxml2.2.dylib
  Referenced from: /Users/*****/Applications/Wine Devel.app/Contents/Resources/wine/lib/wine/msxm

Looking this up, I'm not the only with this issue, though for me, things generally still worked for me.

https://forum.winehq...pic.php?t=12530
http://wineskin.urge...1&display=print

Again, this seems to be related to my inability to build custom Wine engines. Maybe I should bite the bullet and install Macports and wine-dependencies to see if THAT finally downloads a libxml2.2 that Wine recognizes ... very strange

#18 davidl42

davidl42

    Regular Member

  • Members
  • Pip
  • 15 posts
  • Graphics Card:NVIDIA 780M
  • Operating System:Other OS/Not specified

Posted 13 June 2016 - 10:08 AM

More interesting info ... so wineskin will build engine 1.3.18 on my computer using the standard Mac libxml2.2 library. Later wine engines will not build using that, they get the error in post #2 (not sure when the crossover happens). However, like those later engine compiled against the custom libxml2.2 library I built, the wineskin engine doesn't generate a complete wineskin wrapper - they are missing Program files, most of the system files and folders, etc ...

#19 ovvldc

ovvldc

    Master Member

  • Members
  • 1255 posts
  • LocationEurope
  • Graphics Card:Intel Iris Plus
  • Operating System:Other OS/Not specified
  • I like to play:stories

Posted 13 June 2016 - 03:03 PM

Are you sure it is not just your standard Mac libxml2.2 library that is slightly corrupted? Just thinking sideways...

#20 davidl42

davidl42

    Regular Member

  • Members
  • Pip
  • 15 posts
  • Graphics Card:NVIDIA 780M
  • Operating System:Other OS/Not specified

Posted 13 June 2016 - 04:01 PM

View Postovvldc, on 13 June 2016 - 03:03 PM, said:

Are you sure it is not just your standard Mac libxml2.2 library that is slightly corrupted? Just thinking sideways...

Perhaps, but even when I roll my own libxml library, while the engine "successfully" compiles, it doesn't create a truly functional wineskin engine. So even if part of the problem were localized to my Mac's libxml, there must also be other problems with my setup. I'm just not sure what they are. Do you build custom engines on Yosemite/ElCap?

#21 ovvldc

ovvldc

    Master Member

  • Members
  • 1255 posts
  • LocationEurope
  • Graphics Card:Intel Iris Plus
  • Operating System:Other OS/Not specified
  • I like to play:stories

Posted 13 June 2016 - 09:16 PM

Sorry, I can't be of any help there. I was just trying to take a different angle, thinking you might be able to extract a copy with Pacifist or copy and compare with a copy from another computer. Easy thing to try.

As for the compilation, I don't do those. I'm sure it is doable, and I have a PhD even if it is not in computer science. I just have too much stuff on my plate to dive deeply into engines and there is no point in learning if I would only compile vanilla engines (doh123 does that just fine).

I've heard more reports here about building problem, though. There might be a time where the entire build system could do with an overhaul. Various libraries could do with an update, as could the custom XQuartz, and maybe dropping support for a few versions of OS X macOS that haven't had a security update in years is not so bad. But again, someone needs to make that effort and I am not that person so I have no right to gal if it does not happen, only gently encourage someone who might be willing to do it.

#22 davidl42

davidl42

    Regular Member

  • Members
  • Pip
  • 15 posts
  • Graphics Card:NVIDIA 780M
  • Operating System:Other OS/Not specified

Posted 14 June 2016 - 07:23 AM

View Postovvldc, on 13 June 2016 - 09:16 PM, said:

Sorry, I can't be of any help there. I was just trying to take a different angle, thinking you might be able to extract a copy with Pacifist or copy and compare with a copy from another computer. Easy thing to try.

As for the compilation, I don't do those. I'm sure it is doable, and I have a PhD even if it is not in computer science. I just have too much stuff on my plate to dive deeply into engines and there is no point in learning if I would only compile vanilla engines (doh123 does that just fine).

I've heard more reports here about building problem, though. There might be a time where the entire build system could do with an overhaul. Various libraries could do with an update, as could the custom XQuartz, and maybe dropping support for a few versions of OS X macOS that haven't had a security update in years is not so bad. But again, someone needs to make that effort and I am not that person so I have no right to gal if it does not happen, only gently encourage someone who might be willing to do it.

I totally understand, if it weren't for the joystick issue, I wouldn't be doing this either! :) Of course now I might be hooked on solving some of these small, niggling issues in Wine :) ... although I'm not sure I'm actually capable of doing any more than I have. My training isn't computer science either and while I have a lot of programming experience, what I do normally is quite different from this kind of stuff.

I should probably install Macports and the wine-devel toolkit through that and then built the engines from source that way to see what happens. It's just odd, because I did it once or twice on my old laptop years ago (pre-Yosemite). Someone on these forums must use a newer machine/OS X macOS to make custom wineskin engines, so eventually I figure they'll see this thread and go, "oh I know what you need to do!" :) Well, that's what I'm hoping for anyway! (maybe I should repost in a different sub-forum? I'm already on doh123's support forum on the Wineskin site - though I've put much more info here than there ... and this may not necessarily be a Wineskin issue)




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users