What about gaming on FreeBSD?

A. D. Sharpe Sr.
Maybe the right place is to start here? on this forum? :)

That sounds good. But I'm hoping that something is starting that'll eventually expand to the point where it's too big to be contained in this forum & will have to eventually move to its own space.

I am not so sure whether it's the right path to make separate BSD gaming world in addition to the Linux one.
Maybe the focus should be more how to make BSD more game-friendly, i.e. Linux game stuff compatibility and Wine configuration details.
I remember there is some good site which collects compatibility data for games on unixoids. Including reports how they work on various distros. And detail infos what to do to get the stuff running on particular OSes. I hope I find that site again.

IDK, I think it might be prudent to make a separate gaming world for us from Linux simply because I don't like the prospect of developers deciding to just release it on Linux & expect us to run their games through system emulation. We've already seen what happens when we try to share components with Linux. And to be honest, I've been feeling like maybe we should split more & more from Linux, anyway. After all, look at what's happened to the graphics stack. They've completely monopolized it. It seems that the moment something is working great (for us) they change it in ways that're incompatible simply to use some new feature of their kernel which doesn't actually help us. I've been thinking about the need for s completely separate graphics stack. However, I don't think that the FreeBSD organization would go for that. Incidentally, OpenBSD already has their own.
 
....maybe a "Gaming" subforum of the Multimedia forum could help to make FreeBSD more popular with gamers?

I like that idea. I have a particular interest in FreeBSD based game servers.

EDIT - whoops I now see this category falls under desktop. o_O
 
Does anyone have an idea for what the next step should be? Are there any porting efforts underway to build native BSD versions of current games, or even to develop purely BSD games?
 
Does anyone have an idea for what the next step should be?
This thread motivated me to take a first personal step by reading this instruction and then to play a game I loved in the 8088 CGA era.
Screenshot:

ibmcats.png


Yes... IBM produced even a few games back then.
 
It strikes me that there needs to be at least 2 different focuses to building a sustainable interest in gaming on FreeBSD. The two key initiatives are hardware and software. There's been talk in this (and another) thread about the software side of things, but what about the hardware?

To get a significant base of players (which would make developing game that support FreeBSD) there also needs to be hardware for them to play on. While we all do run FreeBSD today, do we have good sound support? I don't see great graphics support at the low end (Intel Integrated) but gaming may be more interested in the high-end side of things. How is high-end nVidia and AMD support these days?

Also, to expand the user base with a focus on gaming would (probably) require much more user-friendly installation options. By that I mean very easy install options that give a usable GUI. Possibly even something that has a focus on gaming by creating a console like UI so it could be connected to a TV. Sort of a DIY console.

Beyond graphics, what is the state of game controller and joystick support?

Personally, if I could (easily) install games and reliably use a bluetooth game pad (or even better 2) and hook the system up to my TV, I would consider building something as long as the cost of the hardware was on-par with consoles. Sadly, that probably means a focus on lower end hardware (Atom, Celeron, probably topping out with an i3) and integrated graphics. An entry level NUC (or other small form factor pc) would fit in nicely beside the Roku in my living room.

Point is, creating a developer community needs to be considered along side developing a user community.
 
Newer AMD graphics cards will depend upon the newer driver for FreeBSD 12, which is still unannounced, and I hope for good reason.

Joystick input works, but configuring buttons is ugly and not standard. sysutils/uhidd is the driver for non-Bluetooth devices. uhid(4) in base is not as capable or compatible for extensive devices. I've heard that uhidd will replace uhid in the base for future FreeBSD releases.

There needs to be a standard Bluetooth 4 (and in the distant future, version 5) driver available across many BSD's, which I know is a lot to ask for. Bluetooth 3 and unfinished Bluetooth 2 dongle drivers are not worth supporting. The price of Bluetooth 4 dongles is cheap and backward compatible, so supporting problematic and faulty 2 and 3 version dongles are unneeded. FreeBSD has standard Bluetooth version 1 support, and sporadic Bluetooth 2 support. Hardly any gamepads and joysticks are for version 1 only.

I created a new thread about potentially usable game engines. You can find it at: https://forums.freebsd.org/threads/63720/
This is not related, but it did remind me of the emulator MEKA, http://www.smspower.org/meka/, for Sega Master System, Game Gear and older systems. I'm surprised it never made its way into ports. I've never used it, but I've been aware of it for a while.
 
Last edited:
It strikes me that there needs to be at least 2 different focuses to building a sustainable interest in gaming on FreeBSD. The two key initiatives are hardware and software. There's been talk in this (and another) thread about the software side of things, but what about the hardware?

To get a significant base of players (which would make developing game that support FreeBSD) there also needs to be hardware for them to play on. While we all do run FreeBSD today, do we have good sound support? I don't see great graphics support at the low end (Intel Integrated) but gaming may be more interested in the high-end side of things. How is high-end nVidia and AMD support these days?

For graphics, nVidia cards are still supported under FreeBSD using nVidia's proprietary driver & OpenGL. For AMD, I've been pondering whether or not to attempt to make contact with AMD developers who work on the Linux drivers to find out what it would take to get AMD to port their amdgpu-pro driver over, so I might as well look into the open source amdgpu driver to see what it would take for an individual to port that over.

Also, to expand the user base with a focus on gaming would (probably) require much more user-friendly installation options. By that I mean very easy install options that give a usable GUI. Possibly even something that has a focus on gaming by creating a console like UI so it could be connected to a TV. Sort of a DIY console.

That seems to be something that the overall FreeBSD project is against, which is why I was previously shipping with PCBSD as the preinstalled OS of my systems. Now that they've transitioned into TrueOS, I've exploring the option of rolling our own FreeBSD derivative or maybe even standardizing on GhostBSD. Sadly, such measures are what would be required to gain a more user friendly installation. It seems that the FreeBSD project only cares about the server market. And it makes sense, since most of their money probably comes from corporate entities that primarily use FreeBSD in headless scenarios.

Beyond graphics, what is the state of game controller and joystick support?

From what I've seen, the uhidd driver (https://wiki.freebsd.org/uhidd) seems to be the only game in town. Unfortunately, it seems to suffer from the same problem that most of FreeBSD suffers from -klunky & error-prone setup that must be done manually. In that regards, it feels rather unpolished. Also is the issue that it doesn't seem to be a part of the base system, so it's not guaranteed to be on any system.

Personally, if I could (easily) install games and reliably use a bluetooth game pad (or even better 2) and hook the system up to my TV, I would consider building something as long as the cost of the hardware was on-par with consoles. Sadly, that probably means a focus on lower end hardware (Atom, Celeron, probably topping out with an i3) and integrated graphics. An entry level NUC (or other small form factor pc) would fit in nicely beside the Roku in my living room.

I've been eyeballing the NUC (& other such setups) for use in a new product line. However, the same issues that you've mentioned are what've been stopping me from moving forward with those types of plans. Undoubtedly, FreeBSD needs a massive update when it comes to drivers needed by regular users for the desktop. These types of modifications would definitely need to be applied to a more user-centric derivative of FreeBSD.

Point is, creating a developer community needs to be considered along side developing a user community.

There's also the issue that our development tools leave much to be desired. Even now, I've had to drop Code::Blocks, because the FreeBSD version suffers from a bug that's related to that project's usage of wxWidgets 2.8. The workaround listed by that project entails building C::B with wxWidgets 3.0. However, that fails miserably, because portions of the code seemly refuse to build correctly. I switched to Codelite recently, but I'm having problems getting it to even locate some of my headers (for wxWidgets & its relatives), despite creating a link to get a working wx-config (which works from the commandline). There's an enormous amount of work ahead of us, if we're going to get this thing off the ground.

Additionally, there's the OSS sound driver setup, which compiles natively for FreeBSD. I haven't gotten a chance to see if OpenAL-Soft (the only actively developed OpenAL implementation) can interface directly to it to create a solid sound stack.

And then, there's SDL, which I haven't had a chance to check it's functionality on FreeBSD. Not only am I interested in how it's sound support holds up, I'm also interested to check it's input support.

Ideally, this is what I'd like things to look like:

For gaming:
Graphics: SDL->OpenGL->accelerated 3d driver
Sound: SDL->OpenAL->OSS driver
Input: SDL->uhidd driver

For the OS:
User friendly installation (with OEM customization available)
Easy configuration preference panels (that include driver setups & tests)
Faster booting to desktop

For developers:
Solid IDE that's centered around FreeBSD's filesystem layout
Libraries that have a standard configuration for FreeBSD & don't have to be massaged into place before usage

That's just the short list.
 
...

Ideally, this is what I'd like things to look like:

For gaming:
Graphics: SDL->OpenGL->accelerated 3d driver
Sound: SDL->OpenAL->OSS driver
Input: SDL->uhidd driver

For the OS:
User friendly installation (with OEM customization available)
Easy configuration preference panels (that include driver setups & tests)
Faster booting to desktop

For developers:
Solid IDE that's centered around FreeBSD's filesystem layout
Libraries that have a standard configuration for FreeBSD & don't have to be massaged into place before usage

That's just the short list.

I think, for a user friendly installation, one would need to either enhance the current FreeBSD installer or (more likely) build a new installer. Done right, a lot of the work could be done by putting key components (the UI for example) into packages so that modifications to the current installer could be used to build a less user-interactive install that automatically adds all the needed packages once the base OS is setup. Done right, all the everything that diverges from the stock FreeBSD should be done in ports so that one could install vanilla FreeBSD and then simply add the necessary ports to turn it into a "game console".

I imagine the hardest part of that will be probing hardware and installing the graphics and sound drivers. This might be simplified by starting on a restricted set of reference hardware (such as Intel NUC or Zotac zBox mini PCs, I think there are some Gigabyte options too). These would limit complexity of hardware probing as it limits the possible options. Although it would eliminate the high-end GPU options too.

User friendliness (in terms of simple GUI tools) would need development.

I don't even know where to start for developers. But as the developers are likely to be the most technically savvy, their needs could be tied to packages and ports.

Your skills are so far beyond mine that, while I understand what you said, I don't know how to achieve most of it.


[edit] P.S. I agree with sidetone, effort on this front should focus on FreeBSD 12 and future. That is where effort to support more modern hardware is and is also where people who can introduce improved code into the core FreeBSD would be able to do so (like better game pad support, etc).
 
That seems to be something that the overall FreeBSD project is against, which is why I was previously shipping with PCBSD as the preinstalled OS of my systems. Now that they've transitioned into TrueOS, I've exploring the option of rolling our own FreeBSD derivative or maybe even standardizing on GhostBSD. Sadly, such measures are what would be required to gain a more user friendly installation. It seems that the FreeBSD project only cares about the server market. And it makes sense, since most of their money probably comes from corporate entities that primarily use FreeBSD in headless scenarios.
...
Additionally, there's the OSS sound driver setup, which compiles natively for FreeBSD. I haven't gotten a chance to see if OpenAL-Soft (the only actively developed OpenAL implementation) can interface directly to it to create a solid sound stack.
Ideally, this is what I'd like things to look like:

For gaming:
Graphics: SDL->OpenGL->accelerated 3d driver
Sound: SDL->OpenAL->OSS driver
Input: SDL->uhidd driver
They've made plenty of strides in improving this. OSS, Portaudio and Sndio frontends use FreeBSD's OSS driver/backend. uhidd will likely replace uhid in base for future releases. There is an unfinished driver for newer AMD cards.
For the OS:
User friendly installation (with OEM customization available)
Easy configuration preference panels (that include driver setups & tests)
Faster booting to desktop.
This part is your job, not the developers. The information is available for you to customize your product. I don't think you've been learning about FreeBSD enough, to know how to configure well enough a system.

* Edit - Faster booting to desktop is a general FreeBSD issue that is in the whole community's interest, but customization can vastly improve it immediately.
 
...
For the OS:
User friendly installation (with OEM customization available)
Easy configuration preference panels (that include driver setups & tests)
Faster booting to desktop

...
This part is your job, not the developers. The information is available for you to customize your product. I don't think you've been learning about FreeBSD enough, to know how to configure well enough a system.

FreeBSD actually has a pretty user-friendly installation process. It is text console, not graphical, but you can more or less just select yes/continue and have a server installed. You can even choose a GUI to install but the default is no GUI. In my opinion, the weakness (for non-techies) is the lack of a GUI as a default.

I agree that work could be done to simplify core system preferences (as it relates to drive setup) but I can't imagine a scenario where this is both easy and complete. It could be made easy if a lot of assumptions are made (which would negate it being used by most system administrators). I doubt there is interest in this being part of the core OS.

I don't know what your experience is with booting FreeBSD, but my server takes about 15 seconds on a cold boot. Admittedly, this does not include a GUI but years ago when I did run FreeBSD on the desktop, the difference between system boot and GUI showing up on the console was under a second.
 
This part is your job, not the developers. The information is available for you to customize your product. I don't think you've been learning about FreeBSD enough, to know how to configure well enough a system.

I think you may be misunderstanding my role & who I’m expecting to do the work. As I stated, these customizations aren’t what I’m expecting for the project developers to do & what I’d expect an end user to do. In this conversation, I’m also wearing the hat of “system integrator”. Which means that I can’t solely rely on what base FreeBSD will include. Understand that if this takes off, more users will come from other platforms & they’re not looking for excuses from their vendor about how hey have to do special customizations to get better boot times and immediate access to features that they’re getting automatically on other platforms. This has to be done a certain way, because I don’t have the luxury of only targeting current BSD users.

* Edit - Faster booting to desktop is a general FreeBSD issue that is in the whole community's interest, but customization can vastly improve it immediately.

Which is why I probably won’t be shipping stock FreeBSD.
 
FreeBSD actually has a pretty user-friendly installation process. It is text console, not graphical, but you can more or less just select yes/continue and have a server installed. You can even choose a GUI to install but the default is no GUI. In my opinion, the weakness (for non-techies) is the lack of a GUI as a default.

Yeh, we’re going to have to do better than that for the desktop. That’s one of the attractions that leads people to TrueOS, GhostBSD, & the now defunct DesktopBSD, rather than vanilla FreeBSD. People simply don’t want to deal with that on the desktop, especially when they don’t have to deal with it on other popular platforms. And as an integrator, I don’t want to have to deal with it, either.

I agree that work could be done to simplify core system preferences (as it relates to drive setup) but I can't imagine a scenario where this is both easy and complete. It could be made easy if a lot of assumptions are made (which would negate it being used by most system administrators). I doubt there is interest in this being part of the core OS.

Agreed.

I don't know what your experience is with booting FreeBSD, but my server takes about 15 seconds on a cold boot. Admittedly, this does not include a GUI but years ago when I did run FreeBSD on the desktop, the difference between system boot and GUI showing up on the console was under a second.

Things are a bit different, now. Desktops & all of the other cruft makes booting take awhile. That’s one of the benefits of TrueOS’s switch to OpenRC & rolling their own GUI. Of course, SSDs will also alleviate some of that.
 
I thought I saw one before, but it's possible I misread. I've searched. I'll continue looking over several days for a dated reference, then update, to make corrections.

At the very least, if this turns out to be unsubstantiated, you’ve given me an idea of what needs to happen. Perhaps it’s something I should consider, if I end up having to roll a special FreeBSD derivative.
 
At the very least, if this turns out to be unsubstantiated, you’ve given me an idea of what needs to happen. Perhaps it’s something I should consider, if I end up having to roll a special FreeBSD derivative.
Apart from uhidd, you can have a customized distribution CD set to install on the computer what is needed for gaming, with little user intervention. Enable all modern drivers that are available: ATI, Radeon, Intel. Perhaps they should be required to have those, and not VESA for gaming, if it is for fullscreen games or even full screen video. In /usr/src/release/ you can build a distribution according to the arguments in Makefile. You may need to set PORTS_MODULES in make.conf, for it to make ports. The other thing, that would be difficult, is keeping up your customers' systems to the current FreeBSD distribution, unless it will be insecure once it is depreciated. The original medium will be obsolete, unless it offers a workaround: you will need your own server or other solution.
 
Apart from uhidd, you can have a customized distribution CD set to install on the computer what is needed for gaming, with little user intervention. Enable all modern drivers that are available: ATI, Radeon, Intel. Perhaps they should be required to have those, and not VESA for gaming, if it is for fullscreen games or even full screen video. In /usr/src/release/ you can build a distribution according to the arguments in Makefile. You may need to set PORTS_MODULES in make.conf, for it to make ports. The other thing, that would be difficult, is keeping up your customers' systems to the current FreeBSD distribution, unless it will be insecure once it is depreciated. The original medium will be obsolete, unless it offers a workaround: you will need your own server or other solution.

Agreed.
 
Apart from uhidd, you can have a customized distribution CD set to install on the computer what is needed for gaming, with little user intervention. Enable all modern drivers that are available: ATI, Radeon, Intel. Perhaps they should be required to have those, and not VESA for gaming, if it is for fullscreen games or even full screen video. In /usr/src/release/ you can build a distribution according to the arguments in Makefile. You may need to set PORTS_MODULES in make.conf, for it to make ports. The other thing, that would be difficult, is keeping up your customers' systems to the current FreeBSD distribution, unless it will be insecure once it is depreciated. The original medium will be obsolete, unless it offers a workaround: you will need your own server or other solution.

We have the means to cover hosting & distribution of updates. Honestly, I'm not sure what the future will hold. If this works, we'll have to decide whether to constantly rebase on FreeBSD or to spin off into a separate project. Only time will tell.

*Edit*
For now, let's just see if we can beat FreeBSD into proper gaming desktop condition.
 
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).

tmgg_ss.jpg

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:

IMG-20180711-00007.jpg
 
Back
Top