What about gaming on FreeBSD?

kpedersen said:
I thought I should attach an image of my current project.

It runs *exclusively* on FreeBSD 10 (basically I haven't bothered even trying to compile it on any other OS ;) (I probably will at some point as a way to catch bugs).

View attachment 5119

For all intents and purposes it is basically just an arcade "Light gun" game I am developing as part of a contract with The Tank Museum to allow guests to play with real weapons from WW2 and shoot virtual targets on a screen.

It works out where on the screen they are aiming via a small webcam in the front and OpenCV to process the LCD screen position. The 3D engine is custom (written in C++ using OpenGL) to run on low spec machines (Intel NUC) and because at the time UE4 wasn't available for FreeBSD (malavon is doing a great job though!).

(Through this project, I now have a great appreciation and respect for any device that uses a coin slot machine. Who the hell decided that the British pound should no longer be round! Calibrating and communicating with this thing is a nightmare.).

This gun is a Lee-Enfield Rifle (decommissioned obviously. Which also worked well so I can get my cables in there. I am crap at guns but pretty good with an RS-232 haha).
I am also working on a similar setup for a Bren Gun and PIAT (anti-tank.).

Oops.. and I almost forgot my original prototype gun. I still keep him around because he doesn't weigh a frigging tonne during testing:

View attachment 5121
Click to expand...
Looking good! I'm glad that someone is working on a FreeBSD based game setup. If there's anyone else working on FreeBSD game development, please post it here!
 
I still feel windows is the best platform for gaming although Wine has been bridging the gap by adding more games into their database. There is also crossover the paid version of wine, I've not tried it thou and I can't say how effective it is compared to wine. Virtual Box is another way to go but most users complain they are RAM and CPU hungry application.
 
dexter234 said:
I still feel windows is the best platform for gaming although Wine has been bridging the gap by adding more games into their database. There is also crossover the paid version of wine, I've not tried it thou and I can't say how effective it is compared to wine. Virtual Box is another way to go but most users complain they are RAM and CPU hungry application.
Click to expand...

Yes, we know that Windows is currently the best computer platform for gaming. That's never been the question. The question is how to make FreeBSD (or any *BSD for that matter) a better gaming platform? At the very least, we should at least be able to make it a better gaming platform that either Linux or MacOS X. That's what the goal should be, NOT praising other platforms, as if ours doesn't matter.
 
A. D. Sharpe Sr. Until "we" create a game as good and as popular as those Windows games and requires a high end graphics card, nVidia and the like will not provide drivers native to FreeBSD. And "we" won't create a game for BSD until nVidia and the like provide native drivers for FreeBSD that run as well as on Windows.
 
drhowarddrfine said:
A. D. Sharpe Sr. Until "we" create a game as good and as popular as those Windows games and requires a high end graphics card, nVidia and the like will not provide drivers native to FreeBSD. And "we" won't create a game for BSD until nVidia and the like provide native drivers for FreeBSD that run as well as on Windows.
Click to expand...

NVidia has been providing native FreeBSD drivers with full 3d acceleration for years, now. Where've you been?
 
I wonder. What's stopping the developers from including X in base? The OpenBSD guys have been doing this for years now; so there's some example of viability here. As cynical as i can be sometimes; unless FreeBSD ships with at least a basic X/DE stack, there's no hope for attracting those types (gaming, creative media) of developers.

The FreeBSD graphics team comprises of, what, 6 developers? If that team were bigger, would this be even feasible?
 
Why do you think X11 was ousted out of the base system? It was strictly to draw a firm line between the base operating system and 3rd party applications.

FreeBSD also has something called "stable ABI" and maintaining those X11 libraries in base (yes, if you include any library ín base with a public API it automatically becomes part of the stable ABI promise) was a nightmare for everyone involved because any little change could invalidate the ABI compatibility. It's still hard enough for the developers to keep this promise with the lot smaller set of APIs currently offered by the base system.

OpenBSD happens to get away with X11 in base only because they make zero promises about ABI compatibility, every time you upgrade your OpenBSD system you're expected to recompile all your own custom made software. Binary only software doesn't exist on OpenBSD because of this.
 
A. D. Sharpe Sr. said:
NVidia has been providing native FreeBSD drivers with full 3d acceleration for years, now. Where've you been?
Click to expand...
My memory does not serve me well but I am not sure their highest end cards make all the features available to FreeBSD. Those drivers might also be convoluted Linux drivers but I have not looked into this in years.
 
drhowarddrfine said:
A. D. Sharpe Sr. Until "we" create a game as good and as popular as those Windows games and requires a high end graphics card, nVidia and the like will not provide drivers native to FreeBSD. And "we" won't create a game for BSD until nVidia and the like provide native drivers for FreeBSD that run as well as on Windows.
Click to expand...
Or "we" :) may also port free nvidia video driver — nouveau,
it is working pretty well on GNU/Linux, also it is available on NetBSD also,
it should be fully usable in NetBSD 8.0.
 
ILUXA said:
Or "we" :) may also port free nvidia video driver — nouveau,
it is working pretty well on GNU/Linux, also it is available on NetBSD also,
it should be fully usable in NetBSD 8.0.
Click to expand...

Yeah, that page is a bit outdated; currently Nouveau on NetBSD 8.0 supports up to 9xx (tested on 7xx, worked well, even for gaming), with upcoming 8.1 having drivers from Linux3.8 (better performance), while on HEAD DRM/KMS drivers are from, Linux4.4, so 10xx should
supported (even though I have a doubt about support having been included on Linux starting with 4.10 and later only).
 
Last edited by a moderator:
dexter234 said:
I still feel windows is the best platform for gaming although Wine has been bridging the gap by adding more games into their database. There is also crossover the paid version of wine, I've not tried it thou and I can't say how effective it is compared to wine. Virtual Box is another way to go but most users complain they are RAM and CPU hungry application.
Click to expand...
Don't forget about what is arguably the most important gaming-related news in years: Valve is now supporting wine through Steam using their own port called Proton (GitHub).
If this is developed further, it will impact gaming on operating systems other than windows.

As far as the (binary or open source) NVidia driver goes, to my knowledge they support pretty much everything that current game engines use.
I've used the official driver to run tech demo's of the Unreal Engine (see this forum for more information) without any issues.
The only thing we, FreeBSD people, don't have (without workarounds) is vulkan. I hope this changes soon, since Proton uses it as the default backend to translate DirectX calls to.
 
drhowarddrfine said:
My memory does not serve me well but I am not sure their highest end cards make all the features available to FreeBSD. Those drivers might also be convoluted Linux drivers but I have not looked into this in years.
Click to expand...
The core of their driver is 100% the same for Windows, Linux, FreeBSD and Solaris. It's only the kernel interface that's different. Because these drivers are all the same they support the same cards and features for all supported operating systems.

The LINUX option you can enable on the FreeBSD driver is only for supporting Linux binaries, it is not required for the driver to work.
 
SirDice said:
The core of their driver is 100% the same for Windows, Linux, FreeBSD and Solaris. It's only the kernel interface that's different.
Click to expand...

Notably, the shared libs supplied with the driver are different for each supported OS. The Linux driver also has nvidia-drm and nvidia-uvm kernel modules which are not provided for FreeBSD or Solaris.

malavon said:
The only thing we, FreeBSD people, don't have (without workarounds) is vulkan. I hope this changes soon
Click to expand...

The reason behind Vulkan absence might be as simple as, say, build environment lacking appropriate header files. We really have no idea because Nvidia's driver devs don't seem to be talking to anyone, including actual FreeBSD devs. Same goes for the infamous vt bug.
 
Half life running on i386-wine with OpenGL
6134
 
Since you post screenshots,....

A "peaceful" Alice running on the desktop...

6135


Crossfire has a possible server, easy to configure.

Xboard best game ever.
If you would like to fix the bug , existing for years from FreeBSD 10.
remove ;firstChessprogramm with adding ';'
6140
6139
6135
6141



6147


6147
 
Last edited:
Hi, everybody and my apologies if this is the wrong forum to post this to.

I'm running FreeBSD 12.0 stable and KDE5/SDDM. So far, so good. Now I've been trying to install Wine, both the x64 and i386 variant, and it seems due to version conflicts I can only install either one of them.

Wine is on 4.0, i386-Wine is on 3.0.4.
Wine-devel is on 4.2, i386-Wine-devel is on 4.0.rc1.

None of these match. I tried both pkg and ports, to no avail. Do I simply have to live with the fact that I just can't get a match for 32bit and 64bit together, or is there some "secret" sauce I have to apply? Unfortunately I couldn't find any assistance on the https://www.freshports.org/emulators/wine/ page.

My apologies again if this seems confusing. I am confused. I have some experience as a Linux/BSD user, but I still feel like a beginner here.

Thank you very much for your assistance.
-e

PS: I think I can answer my own question. It seems like the i386-wine and 64bit wine flavors have two different maintainers... :p
 
I try to reply to your hijack post, so, that you can have an answer, or hints.
I guess that wine will work with 32bits very well on host machine : x86 32bits.
If you have a pi, or arm, go for qemu system 386, this will work flawlessly, actually, easier for beginners:
but, easier, dosbox is a cool alternative, which is readily working. Actually, it will be easier to run dosbox with old windows 3.1, and an appropriate graphic card like et4000.
 
electricdawn said:
Now I've been trying to install Wine, both the x64 and i386 variant, and it seems due to version conflicts I can only install either one of them.
Click to expand...

Yes, they are not meant to work together. The build process for the i386- package is a bit nasty since it involves i386 chroot and that places it at odds with the existing infrastructure. The i386-wine-devel-4.0.r1_1,1 package you see in the official repos hasn't been built on the FreeBSD port building cluster, but rather uploaded by the maintainer.

This is obviously suboptimal and David Naylor (i386-wine-* maintainer) started working on automating chroot build in D14721. That effort is abandoned in favor of D16830, which I think is a superior solution, but it didn't receive any further work and basically just sits there for 6 months without any changes.

For what it's worth, dbn doesn't have any activity on reviews.freebsd.org for the last 2 months. This starts to look a bit worrying. Let's hope it's not burnout, otherwise you are going to wait for a while for your combined 32+64 Wine package.
 
Last edited:
Thank you very much for your reply. I appreciate your explanation. It's really too bad, since it's just one download for both i386 and x64 under Linux and macOS, where it works totally transparent for the user. Let's hope this gets resolved eventually.

Thank you again.
 
Replying to an older question, but I think it hasn't been answered yet, so …
Beastie7 said:
What's the difference between 'mesa3d' and the whole drm thing? I'm having a hard time grasping the purpose of the two.
Click to expand...
Those are different things.
  • Mesa is a software library for rendering 3D graphics. It is an open source implementation of the OpenGL API.
  • DRM / DRI (Direct Rendering Module / Interface) is an interface to access hardware acceleration features of graphics cards.
Software can use both, or just one of them. Roughly said, from the software's point of view, Mesa is the “front-end” that is used to create 3D graphics. It is device-independent. Mesa, in turn, can use various “back-ends” to actually get the pixels onto the screen: it can do all the rendering in software, which is slow, or it can use a hardware-accelerated back-end like DRM. You can think of this as a driver for your 3D hardware.

You can use the command line tool xdriinfo (port x11/xdriinfo) to check if hardware acceleration is available on your system.

By the way, a nice example for a simple but addictive game that uses Mesa is “Crack Attack” (port games/crack-attack). With DRM it is perfectly smooth even in the highest detail level. With software rendering (i.e. without DRM) it is not as much fun …
 
You must log in or register to reply here.
Back
Top