What about gaming on FreeBSD?

Right, Mednafen is a video game console emulator. It's not a gamepad to keyboard translation program. Joytran does what you want.
 
Joytran does what you want.
I guess, I would need it to utilize my Logitech-Extreme 3D Pro in flightgear.
ATM, I'm getting (simulated) pilot training with fgfs, so the joystick would help.
I'll try the joytran and see if it works for me.
Now, I'll be waisting my time with flightgear, instead of learning FreeBSD 🙂
 
I found an old program (from the joytran docs) that I was able to compile for a GUI tester.
SDLJoytest-GL
poot@E6420:~/SDLjoy/SDLJoytest-GL # SDLJoytest-GL
Found 1 joystick(s) on this system.
Joystick 0
Name:.........Game_Pad (0)
Axes: 6
TrackBalls:...0
Buttons: 11
Which Joystick do you want to use(0 - 0):
0
Joystick 0:Game_Pad (0) selected.
Screen resolution set to: 640x480x32bpp
SDL-Joytest-GL.png
 
I guess, I would need it to utilize my Logitech-Extreme 3D Pro in flightgear.
ATM, I'm getting (simulated) pilot training with fgfs, so the joystick would help.
I'll try the joytran and see if it works for me.

Note that joystick reports position, while mouse reports relative movement. They do not map cleanly to each other. On other hand, the pointer on the screen does have a pair of absolute coordinates, so if you can map the joystick position directly to the pointer position you should be ok.
 
…10 months. Does anybody here actually want WoW64 Wine or not?

Of course I do, if my modest opinion counts. FreeBSD is my OS of choice, I would never want to switch to Linux or go back to Windows again, just to be able to play some games. So yes, I would like to see all the advancements of wine for Linux to be available for FreeBSD as well. So please, anyone who can do something to port all necessary stuff for wine, please do. I am only an end-user without the skills to contribute.
 
So yes, I would like to see all the advancements of wine for Linux to be available for FreeBSD as well. So please, anyone who can do something to port all necessary stuff for wine, please do.

Every improvement from the Valve's Wine fork is eventually submitted to upstream Wine if applicable. The only stuff we aren't getting are esync/fsync patches.
 
Ah, you are actually aren't talking about Proton… WoW64 doesn't need any porting from Linux, it's an inherent part of 64-bit Wine. It's not enabled simply because our Ports Collection build process for Wine is a mess.
 
I guess, I would need it to utilize my Logitech-Extreme 3D Pro in flightgear.
ATM, I'm getting (simulated) pilot training with fgfs, so the joystick would help.
I'll try the joytran and see if it works for me.
Now, I'll be waisting my time with flightgear, instead of learning FreeBSD 🙂


I'd like to play Falcon 4.0 that I played on Win98. I had a 500MHz PIII Katmai with a GeForce2 and 256MB RAM then. Now I have a Intel Core i7-2760QM @ 2.40GHz with Nvida Optimus and 8GB RAM. I have a joystick. I think if you read the manual you could probably fly one, it's that extensive.

I had a spare Win10 HDD I played Elder Scrolls: Oblivion on, the only PC game I care about, but think that's the HDD installed in my FreeBSD box right now. I have little experience with or desire to run Wine and if the mood strikes me will install Win7 on a spare HDD, swap it out and use another FreeBSD laptop.
 
Ah, you are actually aren't talking about Proton… WoW64 doesn't need any porting from Linux, it's an inherent part of 64-bit Wine. It's not enabled simply because our Ports Collection build process for Wine is a mess.

The second sentence "It's not enabled ..." is the problem then I am talking about. So is something being done / can something be done to solve the problem in order to enable WoW64 in 64-bit wine? At this point I would also like to ask, now that you have mentioned it: What about proton and dxvk? Does that work on FreeBSD and what is the status of those two things on FreeBSD?
 
The second sentence "It's not enabled ..." is the problem then I am talking about. So is something being done / can something be done to solve the problem in order to enable WoW64 in 64-bit wine? At this point I would also like to ask, now that you have mentioned it: What about proton and dxvk? Does that work on FreeBSD and what is the status of those two things on FreeBSD?

DXVK works if wine was compiled with the VULKAN flag.

This only works for the wine-devel package.

But my 64bit games are crying for xact and other libs that can be fixed with winetricks but winetricks was only ported for i386-wine-devel or wine-devel on i386. So either way it's then useless.
 
So is something being done / can something be done to solve the problem in order to enable WoW64 in 64-bit wine?

Well, had you taken your time to read and understand the discussion(s) I referred earlier in this thread, specifically D14721 and D16830, then you would know that I'm already sitting on what I consider a complete and proper solution to the WoW64 Wine problem for quite some time. Patches, however, do not commit or review themselves.

At this point I would also like to ask, now that you have mentioned it: What about proton and dxvk? Does that work on FreeBSD and what is the status of those two things on FreeBSD?

dxvk and d9vk work fine for me, no Proton for now.
 
Well, had you taken your time to read and understand the discussion(s) I referred earlier in this thread, specifically D14721 and D16830, then you would know that I'm already sitting on what I consider a complete and proper solution to the WoW64 Wine problem for quite some time. Patches, however, do not commit or review themselves.

Well then thank you so much for working on that! So when do you think that great work of yours will be done and available to the end-user? Half a year or year maybe? I am really looking forward to it!

dxvk and d9vk work fine for me, no Proton for now.

Is that saying out of the box with one of the available wine-packages, or something you have figured out / compiled for yourself?
 
Well then thank you so much for working on that! So when do you think that great work of yours will be done and available to the end-user? Half a year or year maybe? I am really looking forward to it!

Not strictly my work, a derivative of a patch from dbn@, on which he obviously doesn't intend to work any further. It's available at freebsd-lib32-companion-ports git repository. You can even point a Poudriere/Synth setup to it. It's not going to be in the Ports tree any time soon, if ever. As I said, patches do not commit or review themselves. There do exist, of course, methods of getting committer attention to it, but they are not very nice and also somewhat antagonizing.
 
Well, what things you are actually expecting to get from the Linux client (as opposed to running its Windows counterpart under Wine)? This is often repeated complaint, but I don't really understand the motivation.

The Windows Steam Client works under wine, that is true, but if games once installed work or not is another thing. It can be quite frustrating to install games through steam just to learn that in the end they don't work. TF2 and so it seems, all hl2-based games seem to work, I have also tried some old demos, but the newer the games, the less they work. It looks to me that Directx10 is not even working in i386-wine or i386-wine-devel, only DirectX9.

On the other hand, Linux games under FreeBSD work so well and with astonishing performance in comparison to DirectX games in wine, that the desire to have the linux steam client working under FreeBSD is not only understandable but also rather promising in the sense that the games would actually work (not just the client) and with much better performance.
 
On the other hand, Linux games under FreeBSD work so well and with astonishing performance in comparison to DirectX games in wine, that the desire to have the linux steam client working under FreeBSD is not only understandable but also rather promising in the sense that the games would actually work (not just the client) and with much better performance.

That's completely untrue. Anyway, if you personally want to see just how much Linux games suck under FreeBSD (and in general), today is your lucky day: https://github.com/shkhln/linuxulator-steam-utils.
 
From the FreeBSD ports repository
i386-wine-4.0.1,1
i386-wine-devel-4.11,1
wine-4.0.1,1
wine-devel-4.11,1

From the Wine website
Latest Releases
Stable:
Wine 4.0.1 (shortlog)
Development:
Wine 4.11 (shortlog)

So, the latest wine version can be compiled and run on FreeBSD. Both version numbers are in sync (cfr. your earlier question).
Why do you want wine 4.2 if you can have wine 4.11? For the record I don't know if it has vulkan support, but just saying that it is the latest version.

This isn't talking about Proton though, which is a Valve distribution of Wine with DXVK and some other changes.
That piece of software isn't ported to FreeBSD, probably in part because it uses a lot of Linux-centric scripts to do the building. Reminds me of Google projects :(

shkhln we were basically typing the same things so I cut it off here. Also, you have a double post You were right about that ajax issue :)

I do not understand this. I get:

Code:
$ pkg search wine
i386-wine-3.0.4_1,1            32-bit Microsoft Windows compatibility environment for 64-bit FreeBSD
i386-wine-devel-4.0.r1_1,1     32-bit Microsoft Windows compatibility environment for 64-bit FreeBSD
py27-twine-1.13.0_1            Collection of utilities for interacting with PyPI
py36-twine-1.13.0_1            Collection of utilities for interacting with PyPI
wine-4.0.2,1                   Microsoft Windows compatibility environment
wine-devel-4.15,1              Microsoft Windows compatibility environment
wine-gecko-2.47                Gecko Layout Engine for Wine (HTML support)
wine-gecko-devel-2.47          Gecko Layout Engine for Wine development branch (HTML support)
wine-mono-4.7.5                Mono .NET implementation for Wine development branch (HTML support)
wine-mono-devel-4.9.2          Mono .NET implementation for Wine development branch (HTML support)
winetricks-20190615            Easy way to work around problems in Wine
$

You also get the same version numbers when doing a search in freshports.org. What is the above quoted "FreeBSD ports repository" then?
 
Actually, it's not as bad, especially if you consider that we have incomplete 2.6.32 emulation. Even gaming on CentOS is a lottery as some games want newer libc.
 
That's completely untrue. Anyway, if you personally want to see just how much Linux games suck under FreeBSD (and in general), today is your lucky day:

I was referring to Linux Games like Doom3, Quake4, UT2004, linux-et, ETQW, etc. I am still a ETQW player. To me performance is far superior to wine. Also with the Linuxulator and my former HDA-Soundchip (the mainboard does not exist anymore) I could even get 5.1-sound while with wine I could not. That has nothing to do with the Linux-Steam-Client. Maybe I was misunderstood by you by you shkhln. My thought was that, if in my experience those games directly installed work so well, than it could be worth to have the Linux-Steam-Client working. It is only a wishful thought, though.
 
It is amusing how often people claiming "I need X by yesterday!" drop the subject entirely when offered "Here's how to do X" advice.

Sorry, I did not have the time to be online for the last two days, so I had no time to thank you for that info. I am not dropping the subject, but as I can see from the description it looks that in the end games do not work, right? Maybe it would be another solution to install Linux with Steam in a virtual machine? I do not know how good 3D-acceleration in e.g. virtualbox would be, though...
 
I was referring to Linux Games like Doom3, Quake4, UT2004, linux-et, ETQW, etc.

You are extrapolating quite a bit from playing 4 games based on 2 distinct engines.

That has nothing to do with the Linux-Steam-Client.

The part where you quoted me was specifically about the Linux Steam client. I don't doubt the games in our Ports Collection work very well, that's the whole point of it. Nonworking software simply gets removed.

I am not dropping the subject, but as I can see from the description it looks that in the end games do not work, right?

It's a tongue-in-cheek reference.
 
It can run games made for windows and it can do it so well !!! its completely mindblown !
I think proton uses dxvk too from what i know just an older version thats why it performs a little worse than dxvk
I hope that would come to freebsd too .... but then productivity would go through the window.....

But ports do not have a newest 4.0, 4.2 WINE with Vulkan or DX12 support. And FreeBSD need a dedicated driver for Graphic.

And how about "borrowed" games you know, securities.

View: https://www.youtube.com/watch?v=TYmSoEhJL18
- IDK.
 
Back
Top