What about gaming on FreeBSD?

[aimeec1995]

By the way, yes, after emulators/i386-wine port was updated to 2.*.*, it doesn't work anymore, at least on FreeBSD amd64,
tested on my FreeBSD 11.1 pc with nvidia gpu and on FreeBSD 10.4 Beta3 laptop with intel integrated graphics (both amd64),
it shows critical error when start any 3D wine game. The latest version that working fine for me is i386-wine-1.8.6,1.
It can be installed using ports-mgmt/portdowngrade:

% portdowngrade emulators/i386-wine r429248
% cd ~/i386-wine
# make deinstall install clean

But you need the latest wine-staging from the ports tree for using Steam.
Is that why wine doesn't work on freebsd amd64? I thought it was because of a lack of hardware accelerated graphics stack for multilib.

 

[Deleted member 48958]

It is because new i386-wine versions (2.*,*) are buggy (I think),
because emulators/i386-wine before 2.0 used to work fine.

P.S.: I don't use steam, sometimes I play only few favorite old games, like Hitman Blood Money.

 

[Sensucht94]

It is because new i386-wine versions (2.*,*) are buggy (I think),
because emulators/i386-wine before 2.0 used to work fine.

What kind of error are you receiving?
It's a little bit I wonder what's going on with wine, since when I first started seeing complaints on the forum.
For me it's working just fine, and I use it to launch:
- Rome Totalwar
- Deus Ex Invisible war
- Max Payne
Version is 2.0.1
That's really weird

 

[Deleted member 48958]

What GPU you're using? Just tested again, tried to use "i386-wine-2.0.2,1" and "wine-devel-2.15,1" from the "latest" repo.
Whenever I start any 3D game with i386 wine 2.*.*, it crashes and show critical error. Also, it seems,
I am not the only one, who can't use it.

UPDATE:
Just tried i386-wine 2.0.1 version from "quarterly" repository,
the results are the same:

 

[Sensucht94]

. What GPU you're using?

Hi ILUXA, I've got a Nvidia GTX Geforce 1060 6Gb.
As for me, I forgot mentioning I'm not free from vice. I didn't encounter any particular runtime error, though seldom does wine hang and freeze up while running a 3D game. Is that Max Payne2 you're trying to run? if you tell me about any problematic software to run, I can try installing it as well and the post here any eventual error log.

 

[Deleted member 48958]

Hello. ANY 3D APPLICATION doesn't work for me with i386-wine-2.*.*
on a pc with nvidia 9600gt (FreeBSD 11.1 amd64), and on a laptop with intel graphics (FreeBSD 10.4 BETA3 amd64).
But i386-wine-1.8.6,1 works very well. That was the point. If I'm not the only one who encountering this, then bug report should be created…

 

[aimeec1995]

Hello. ANY 3D APPLICATION doesn't work for me with i386-wine-2.*.*
on a pc with nvidia 9600gt (FreeBSD 11.1 amd64), and on a laptop with intel graphics (FreeBSD 10.4 BETA3 amd64).
But i386-wine-1.8.6,1 works very well. That was the point. If I'm not the only one who encountering this, then bug report should be created…

Same, but it works for me on the i386 release of FreeBSD.

 

[Sensucht94]

Hi guys and good morning, just tried launching Deus Ex (wine specs on bottom left corner). I'd be better attaching the screenshot here before being suspected of lying!:

In light of what you and aimeec1995 stated. now I think it the only reason why it keeps working, along with Rome TotalWar, is that they're both very old pieces of software, and I tweaked a little bit with video options/compatibility mode, as I remember colours not being displayed correctly in Deus EX, and game crashing after start up with Rome.

Nonetheless, I didn't succeed in an Unreal Tournament 2004 installation a while ago, so after all, maybe it's time to really forward a bug report

 

[aimeec1995]

Hi guys and good morning, just tried launching Deus Ex (wine specs on bottom left corner). I'd be better attaching the screenshot here before being suspected of lying!: View attachment 3963 In light of what you and aimeec1995 stated. now I think it the only reason why it keeps working, along with Rome TotalWar, is that they're both very old pieces of software, and I tweaked a little bit with video options/compatibility mode, as I remember colours not being displayed correctly in Deus EX, and game crashing after start up with Rome.

Nonetheless, I didn't succeed in an Unreal Tournament 2004 installation a while ago, so after all, maybe it's time to really forward a bug report

Is that steam for windows?
I wasn't able to get it to even launch in the 64 bit release.
Does it work for you?

 

[Deleted member 48958]

Hi guys and good morning, just tried launching Deus Ex (wine specs on bottom left corner). I'd be better attaching the screenshot here before being suspected of lying!: In light of what you and aimeec1995 stated. now I think it the only reason why it keeps working, along with Rome TotalWar, is that they're both very old pieces of software, and I tweaked a little bit with video options/compatibility mode, as I remember colours not being displayed correctly in Deus EX, and game crashing after start up with Rome.

Nonetheless, I didn't succeed in an Unreal Tournament 2004 installation a while ago, so after all, maybe it's time to really forward a bug report

Nobody says you're lying! I believe that it work for you, but I don't think that it is related to kind of game, it's because,
it seems, you're using the same or similar GPU as i386-wine port maintainer use

 

[Sensucht94]

Is that steam for windows?
I wasn't able to get it to even launch in the 64 bit release.
Does it work for you?

Hi aimeec1995. Yes it is indeed.

Works so far, but only with older games

For 64bit release I assume you mean amd64 FreeBSD, as Steam exists as a 32bit-only software, hence in order to make it run you have to install emulators/i386-wine and not emulators/wine. Also, I built the package from ports with gecko and mono support.
Unfortunately, steam in BSD works decently only with Nvidia GPU with , but in order to make my video card correctly launch 3D programs and games with wine, I had to patch it:

sudo /usr/local/share/wine/patch-nvidia.sh

Finally, having 8Gb of physical RAM, and a ZFS filesystem, I still have by default around 4Gb to freely start even the haeviest process, as stated in https://www.freebsd.org/doc/handbook/zfs-advanced.html.
However, with, let's say, 4Gb of physical, you might want to adjust:

vfs.zfs.arc_max

. For gaming purposes, I found that useful sometimes on another PC, especially with wine, which apparently seems so eat up more memory compared to a native BSD/Linux process. Nonetheless it's naturally better to change the value back for the next boot after having played, thus to avoid slowing down your computer.
On that laptop (a 32 Intel Celeron powered 2007 Acer with 2Gb RAM), I installed the Steam port available on Github (https://github.com/SteamOnFreeBSD/SteamOnFreeBSD), that I already mentioned above in this thread. It DOES work indeed (after many attempt and time spent figuring out problems), but I was unable to install it on this new desktop, for the fact the install script tries to fetch some libraries from the Ubuntu repository that are no longer available (or supposedly they are referred with other names). I'll be checking that port again from time to time, since I thinks it's on the right path to be correctly developed. Hopefully, if more people become interested in it, we can get this come to light (I always regret not being a pro, as I can't be of any help in that, but sooner or later I'll learn some programming language so as to try to port something).

Nobody says you're lying! I believe that it work for you, but I don't think that it is related to kind of game, it's because,
it seems, you're using the same or similar GPU as i386-wine port maintainer use

Hi ILUXA thanks for you're reply, I was ironic so truly do not worry
Well this sounds like a logic explanation. Case is unbelievable sometimes, and then, I really need to consider myself lucky.

As I said to aimeec, It's true as well I stopped receiving MANY of my runtime errors after having installed the patch for wine. Did you try doing that too?
Hope this help

Anyway, Speaking of Steam, I really like it for the fact I can have a library with an index of all my games, that stores save data on a cloud, lets me read reviews and share opinions, and offers great discounts (you see something's for real convenient sale, you buy it and, best odds, you do not install it for the following 2 years, like 2/3 of games you can see on the screenshot. Or, when you try it with wine, you sadly understand you made the wrong deal ahahah).
So, whether one is a true pro gamer or plays from time to time, steam or G.O.G. are useful, even to buy old games no one cares about any longer. There are moments in your life you feel you're just wasting time (when you're alone on a train, or during breaks) and steam can prove really useful in those cases.
However steam is interested only in those who want to buy the latest titles at modicum price of 60-70$, serious gamers who own a windows or almost a Mac, and thus BSD is nowhere going to be officially supported.
I hear people who claim Linux is good for playing commercial, closed-source games, due to steam's support. I think any veteran Linux user would disagree on that and think Linux more or less shares the same bitter destiny as BSD.
The systems that are well supported are Mint, Ubuntu, Debian (and these almost cover all of the 2% slice of desktops linux has stably occupied for years). I believe the steam port is therefore directed toward people who migrate to Mint from Windows (to nerd around with Linux) and expect to have the same proprietary software, as well as they're games.
Old Linux desktop users, if not Debian, tend to prefer Slackware, ArchLinux, PCLinux, Gentoo, NixOS and others, while servers run SuSE, Tail, CentOS, UbuntuServer etc..
In my experience, outside Ubuntu and similar, Steam does not work well at all. In Slack I had serious problems installing it and in ArchLinux it's just unstable.
Forgive the long talk, but, to sum up, I really do not think Linux is a better Gaming platform than BSD, outside freeware/opensource software, for which they're both good the same way

 

[Deleted member 48958]

Patch is only required when you have an nvidia gpu, and it is required with every i386-wine version, for intel graphics no patches needed.

 

[Sensucht94]

Patch is only required when you have an nvidia gpu, and it is required with every i386-wine version, for intel graphics no patches needed.

Sorry ILUXA, I forgot about the laptop you had mentioned earlier and didn't thought you were speaking of it

 

[aimeec1995]

Hi aimeec1995. Yes it is indeed.
View attachment 3973

Works so far, but only with older games

For 64bit release I assume you mean amd64 FreeBSD, as Steam exists as a 32bit-only software, hence in order to make it run you have to install emulators/i386-wine and not emulators/wine. Also, I built the package from ports with gecko and mono support.
Unfortunately, steam in BSD works decently only with Nvidia GPU with , but in order to make my video card correctly launch 3D programs and games with wine, I had to patch it:

sudo /usr/local/share/wine/patch-nvidia.sh

Finally, having 8Gb of physical RAM, and a ZFS filesystem, I still have by default around 4Gb to freely start even the haeviest process, as stated in https://www.freebsd.org/doc/handbook/zfs-advanced.html.
However, with, let's say, 4Gb of physical, you might want to adjust:

vfs.zfs.arc_max

. For gaming purposes, I found that useful sometimes on another PC, especially with wine, which apparently seems so eat up more memory compared to a native BSD/Linux process. Nonetheless it's naturally better to change the value back for the next boot after having played, thus to avoid slowing down your computer.
On that laptop (a 32 Intel Celeron powered 2007 Acer with 2Gb RAM), I installed the Steam port available on Github (https://github.com/SteamOnFreeBSD/SteamOnFreeBSD), that I already mentioned above in this thread. It DOES work indeed (after many attempt and time spent figuring out problems), but I was unable to install it on this new desktop, for the fact the install script tries to fetch some libraries from the Ubuntu repository that are no longer available (or supposedly they are referred with other names). I'll be checking that port again from time to time, since I thinks it's on the right path to be correctly developed. Hopefully, if more people become interested in it, we can get this come to light (I always regret not being a pro, as I can't be of any help in that, but sooner or later I'll learn some programming language so as to try to port something).



Hi ILUXA thanks for you're reply, I was ironic so truly do not worry
Well this sounds like a logic explanation. Case is unbelievable sometimes, and then, I really need to consider myself lucky.

As I said to aimeec, It's true as well I stopped receiving MANY of my runtime errors after having installed the patch for wine. Did you try doing that too?
Hope this help

Anyway, Speaking of Steam, I really like it for the fact I can have a library with an index of all my games, that stores save data on a cloud, lets me read reviews and share opinions, and offers great discounts (you see something's for real convenient sale, you buy it and, best odds, you do not install it for the following 2 years, like 2/3 of games you can see on the screenshot. Or, when you try it with wine, you sadly understand you made the wrong deal ahahah).
So, whether one is a true pro gamer or plays from time to time, steam or G.O.G. are useful, even to buy old games no one cares about any longer. There are moments in your life you feel you're just wasting time (when you're alone on a train, or during breaks) and steam can prove really useful in those cases.
However steam is interested only in those who want to buy the latest titles at modicum price of 60-70$, serious gamers who own a windows or almost a Mac, and thus BSD is nowhere going to be officially supported.
I hear people who claim Linux is good for playing commercial, closed-source games, due to steam's support. I think any veteran Linux user would disagree on that and think Linux more or less shares the same bitter destiny as BSD.
The systems that are well supported are Mint, Ubuntu, Debian (and these almost cover all of the 2% slice of desktops linux has stably occupied for years). I believe the steam port is therefore directed toward people who migrate to Mint from Windows (to nerd around with Linux) and expect to have the same proprietary software, as well as they're games.
Old Linux desktop users, if not Debian, tend to prefer Slackware, ArchLinux, PCLinux, Gentoo, NixOS and others, while servers run SuSE, Tail, CentOS, UbuntuServer etc..
In my experience, outside Ubuntu and similar, Steam does not work well at all. In Slack I had serious problems installing it and in ArchLinux it's just unstable.
Forgive the long talk, but, to sum up, I really do not think Linux is a better Gaming platform than BSD, outside freeware/opensource software, for which they're both good the same way

Could you post exactly what you did to make SteamOnFreeBSD work, please?

Thanks, I would love to try it for myself.

 

[Sensucht94]

Could you post exactly what you did to make SteamOnFreeBSD work, please?

Thanks, I would love to try it for myself.

Hi, aimeec, I'm really sorry to disappoint you this time, but most of things I did have been already fixed meanwhile, one way or another. Partially the port was fixed due to people posting negative feedback and opening issues, partially through the developer's own work.
However, as I mentioned in my previous post, and as you have probably noticed already, the port has been broken for some while now, since so many libraries the install.sh script tries to fetch from Ubuntu repository have likely been moved/renamed/deleted. Trying to seek them out on Ubuntu or elsewhere, locating the new files' names, and updating the urls in the install.sh script is going to be a hard cat & mouse hunting challenge, and personally I wouldn't venture in something like that. I wonder if the developer thinks the same and lost interest in it: I really hope that's not the case (it was such a nice idea and worked better than wine in my opinion), but he/her hasn't been seen for quite some time, and, what's more, not many people seemed interested into maintaining it. Let's keep an eye ope and let's try to build it again from time to time

Anyway, I wouldn't be able to remember the few steps I followed nor would this be worthwhile, but I can give you some tips: next time, try changing permissions and owner to files that broke the installation with a permission denied error, then edit the install script and
- change broken urls, if you're lucky, looking up on Ubuntu
- when receiving no such file or directory, change paths to where files are pasted, according to the path pointed out by the error
Then ,in order to avoid doas permission errors, edit /usr/local/etc/doas.conf and adjust the entry according to the FreeBSD reference for the OpenBSD's doas sudo-like utility: doas.conf()
Something like this, if you're a wheel member

permit nopass keepenv :wheel
permit nopass keepenv username as root

It's a pity, since it just needed a maintainer, but I can fancy it's far too much work for one only person to keep up with repositories' updates, steam updates, FreeBSD updates.
If I will ever have the knowledge to accomplish such a task surely that's one of the first things I'll try doing.

By the way, if you want steam, don't want to buy Window, and don't mind being able to play only about 1/3 of new games, than I strongly suggest you to run Mint/Debian/Ubuntu/Fedora on a hypervisor like bhyve() (https://www.freebsd.org/doc/handbook/virtualization-host-bhyve.html), or QEMU or Vbox. I would reserve 4-5/8 Gb of RAM or 8/16 for a modern gaming platform. In the former risky case, just open a Xorg with a light WM and kill any unneeded process before playing (I do it).

Slackware in virtualbox isn't the maximum for graphics so I discourage you from ever trying that path.

Guess if SteamOS runs in bhyve, or otherwise emulated, it would be fabulous.

 

[sidetone]

On FreeBSD, I used to play Command and Conquer on DosBox, King's Quest VI on Wine, Humans on Wine, and Street Fighter II (distributed by HannaHo) on Wine. For Street Fighter IV, only the video in the intro would work on Wine. I don't remember correctly if I was able to play Age of Empires on Wine.

I even ran DosBox to play that Mickey Mouse game I played as a child to remind me of its game play and ending. Dosbox and Wine are perfect for computer games from the 80's, 90's and early 2000's.

From FreeBSD ports: Flight of the Amazon Queen (games/fotaq, an RPG), boswars, lincity-ng and Bzflag.

 

[aimeec1995]

Hi, aimeec, I'm really sorry to disappoint you this time, but most of things I did have been already fixed meanwhile, one way or another. Partially the port was fixed due to people posting negative feedback and opening issues, partially through the developer's own work.
However, as I mentioned in my previous post, and as you have probably noticed already, the port has been broken for some while now, since so many libraries the install.sh script tries to fetch from Ubuntu repository have likely been moved/renamed/deleted. Trying to seek them out on Ubuntu or elsewhere, locating the new files' names, and updating the urls in the install.sh script is going to be a hard cat & mouse hunting challenge, and personally I wouldn't venture in something like that. I wonder if the developer thinks the same and lost interest in it: I really hope that's not the case (it was such a nice idea and worked better than wine in my opinion), but he/her hasn't been seen for quite some time, and, what's more, not many people seemed interested into maintaining it. Let's keep an eye ope and let's try to build it again from time to time

Anyway, I wouldn't be able to remember the few steps I followed nor would this be worthwhile, but I can give you some tips: next time, try changing permissions and owner to files that broke the installation with a permission denied error, then edit the install script and
- change broken urls, if you're lucky, looking up on Ubuntu
- when receiving no such file or directory, change paths to where files are pasted, according to the path pointed out by the error
Then ,in order to avoid doas permission errors, edit /usr/local/etc/doas.conf and adjust the entry according to the FreeBSD reference for the OpenBSD's doas sudo-like utility: doas.conf()
Something like this, if you're a wheel member

permit nopass keepenv :wheel
permit nopass keepenv username as root

It's a pity, since it just needed a maintainer, but I can fancy it's far too much work for one only person to keep up with repositories' updates, steam updates, FreeBSD updates.
If I will ever have the knowledge to accomplish such a task surely that's one of the first things I'll try doing.

By the way, if you want steam, don't want to buy Window, and don't mind being able to play only about 1/3 of new games, than I strongly suggest you to run Mint/Debian/Ubuntu/Fedora on a hypervisor like bhyve() (https://www.freebsd.org/doc/handbook/virtualization-host-bhyve.html), or QEMU or Vbox. I would reserve 4-5/8 Gb of RAM or 8/16 for a modern gaming platform. In the former risky case, just open a Xorg with a light WM and kill any unneeded process before playing (I do it).

Slackware in virtualbox isn't the maximum for graphics so I discourage you from ever trying that path.

Guess if SteamOS runs in bhyve, or otherwise emulated, it would be fabulous.

Thanks for replying.

Runs better you say? I thought the games had no sound.
Also, games under bhyve? I wasn't aware you could do 3d acceleration under it.
Would that really be faster than wine?

 

[Sensucht94]

Runs better you say? I thought the games had no sound.

They don't. But shame on me, I do not see the difference, as I haven't managed to make sound correctly work, or work at all on wine-BSD. I edited the register keys with no luck, so I thought it were a common issue. Now I understand it's not.

Also, games under bhyve? I wasn't aware you could do 3d acceleration under it.
Would that really be faster than wine?

Well, I use bhyve with on laptop with Debian to run a couple of programs from their repository. I admit I hadn't tried the path of gaming on that machine, but since emulation ran that smooth and had such a good performance I assumed 3d acceleration had already been implemented, provided also that bhyve is ''somehow similar to KVM'', which has been used thoroughly for Windows gaming. Again, I assumed wrong and apologize for not being informed.

On the other hand, I have Arch as guest on QEMU, on my desktop, and is my main gaming platform: I only installed and use it for gaming and playing commercial titles on Steam.
If whether QEMU or VirtualBox is better as gaming platform (speaking of emulation versatility and performance), has been a matter of large debate, and I would say, stick with the one you like better. I've use them both throughout years, and each has its good pros.

What is important is that, with a good RAM and a good video, emulation runs almost flawlessly and saves me lot of pain, anger and time I would waste with wine.

It's true I jerk around with wine from time to time (like install some PC-only game), but it always shows some error, always requires something to be fixed, always have to find the correct version of the game known to be stable on wine.
I really do not like wine, and It's not a matter of platform. I used it for yeas on a 2011 Macbook air (my previous gaming platform), and it was probably worse the BSD.

Speaking of performance, did you ever succeed into correctly installing on wine a game released after around half of 00s? For me it's always been almost impossible, and whenever I did, performance was orrible.


As opposite emulation on a VM allows one to install later games, and does it well, with decent performance, to the point I'm already satisfied with it (obviously I"m not speaking of installing SW Battlefront and playing it with ultra graphic options).
I'd be truly curious of hearing your point of view and experience.

 

[aimeec1995]

They don't. But shame on me, I do not see the difference, as I haven't managed to make sound correctly work, or work at all on wine-BSD. I edited the register keys with no luck, so I thought it were a common issue. Now I understand it's not.



Well, I use bhyve with on laptop with Debian to run a couple of programs from their repository. I admit I hadn't tried the path of gaming on that machine, but since emulation ran that smooth and had such a good performance I assumed 3d acceleration had already been implemented, provided also that bhyve is ''somehow similar to KVM'', which has been used thoroughly for Windows gaming. Again, I assumed wrong and apologize for not being informed.

On the other hand, I have Arch as guest on QEMU, on my desktop, and is my main gaming platform: I only installed and use it for gaming and playing commercial titles on Steam.
If whether QEMU or VirtualBox is better as gaming platform (speaking of emulation versatility and performance), has been a matter of large debate, and I would say, stick with the one you like better. I've use them both throughout years, and each has its good pros.

What is important is that, with a good RAM and a good video, emulation runs almost flawlessly and saves me lot of pain, anger and time I would waste with wine.

It's true I jerk around with wine from time to time (like install some PC-only game), but it always shows some error, always requires something to be fixed, always have to find the correct version of the game known to be stable on wine.
I really do not like wine, and It's not a matter of platform. I used it for yeas on a 2011 Macbook air (my previous gaming platform), and it was probably worse the BSD.

Speaking of performance, did you ever succeed into correctly installing on wine a game released after around half of 00s? For me it's always been almost impossible, and whenever I did, performance was orrible.


As opposite emulation on a VM allows one to install later games, and does it well, with decent performance, to the point I'm already satisfied with it (obviously I"m not speaking of installing SW Battlefront and playing it with ultra graphic options).
I'd be truly curious of hearing your point of view and experience.

I have ran games like ...

- Crysis 1 & 2
-NieR: Automata
-Metal gear rising: revengeance
-Shadow warrior, the new one.
-S.T.A.L.K.E.R: Call of Pripyat

and more under wine-staging on FreeBSD.
I have never actually tried gaming in a VM because I am not sure how to pass my graphics card through to one?
You make it sound so flawless, I'd love to give it a try.

I believe in the past there was a port for steam/srcds for FreeBSD, for hosting source dedicated servers under FreeBSD's linux "emulation" layer, but was taken down due to having no maintainer/being broken.

It is a real shame we could likely have a working steam client for FreeBSD that ran a lot of linux titles, like metro 2033: Last Light with some work. I think a working project like that would bring a lot of users to FreeBSD, but probably not the kind the community wants.

 

[A. D. Sharpe Sr.]

Has anyone considered starting up a grassroots BSD gaming campaign? It seems that Linux had to do the same thing, so maybe it's time for us to start consolidating efforts to improve BSD's gamine potential & find out what's necessary for developers to target us. Even if we could get up & coming developers to target us, that would be something. Creating a BSD indie game developer community might also help.

Just a thought...

 

[Snurg]

Regarding the comment A. D. Sharpe Sr. above, maybe a "Gaming" subforum of the Multimedia forum could help to make FreeBSD more popular with gamers?

And to the gamers here, I have a problem and a question:
Problem: I have a few games from the 1980s and early 1990s (DOS based).
Particularly with the old 8088 games, there is a big problem: their timing is closely coupled to the actual processor's speed.
For example, if I try Zaxxon, past then a popular game, on Wine, when I start, it's over in a fraction of a second because of the incredible game speed.

So I'd like to ask, are there any 8088 emulators or the like that are able to adapt their execution speed to about a 4.77MHz 8088 PC?

 

[sidetone]

For a Gaming system, it would be ideal for there to be a standard Bluetooth version 4 driver, and forget about Bluetooth versions 2 and 3. Bluetooth 4 (a dongle of it) is backward compatible with (non-dongle) devices on previous versions and has less problems.
.......

Has anyone considered starting up a grassroots BSD gaming campaign? It seems that Linux had to do the same thing, so maybe it's time for us to start consolidating efforts to improve BSD's gamine potential & find out what's necessary for developers to target us. Even if we could get up & coming developers to target us, that would be something. Creating a BSD indie game developer community might also help.

Just a thought...

There's GameBSD referred to in Thread GameBSD.57825
.......

Particularly with the old 8088 games, there is a big problem: their timing is closely coupled to the actual processor's speed.

Perhaps that can be treated as a bug, so they can slow down the emulation for those games? It is common for newer computers to run games made for older hardware faster.

 

[Snurg]

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

sidetone
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.

Another thing I ask myself...
Imagine somebody runs some malware-infected windows or mac games.
it could maybe wise to jail wine? Do you know whether this is possible?

 

[sidetone]

sidetone
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.

There's no right or wrong about that. It's a matter of resources, and if the people who want that are able to do it.
Linux compatibility on FreeBSD is a mess, only because in ports, there are full Linux versions and no minimized port for it, such as a Slackware or a non-dogma based one, that mostly does not duplicate FreeBSD binaries.
that mostly runs on FreeBSD's binaries,

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.

Some projects are made like that, but it's how a lot more projects should be done.

Another thing I ask myself...
Imagine somebody runs some malware-infected windows or mac games.
it could maybe wise to jail wine? Do you know whether this is possible?

A lot of programs should be run in jails. It can be done, but it is difficult, as I've seen many guides on jails (usually incomplete), but I haven't seen anything complete or standard that satisfies everything from emulated access to the Internet to device drivers.
Wine and Dosbox actually need to become more standardized, (IMO) like having their own configuration directory that is outside of the home directory, and works as a subset of /etc/ and /usr/local/etc/ configurations. same for Linux compatibility. Linux compatibility already does this. This is an upstream issue, however.
Usually games that are bought on CD aren't known for having malware.

Regarding the comment A. D. Sharpe Sr. above, maybe a "Gaming" subforum of the Multimedia forum could help to make FreeBSD more popular with gamers?

Eventually, FreeBSD will need something like that. Then again, it may overlap a lot with other subjects.

 

[Snurg]

sidetone
Sounds really like jails should be more popular than they are already.
I'll look more into that the near future.
Browsers and Wine should really always be jailed, for example. But as you say correctly - it's badly documented and hard to set up.
The issue with the Wine config writable by Wine, thats really ugly. I hope there will be a workaround.

(And regarding my old games... sure, their CDs are virus-free. But some of them actually need updates to not crash etc, and so you never know whether the stuff you got from the internet is really safe. This is why I want Wine in jail.)