# What about gaming on FreeBSD?



## paulfrottawa (Dec 1, 2008)

At a forum I participate I was told this.



> Gaming on any kind of "nix" is an exercise in futility. DirectX is windows only and OpenGL is becoming more irrelevant day after day.



Can anyone correct this 

What kind of cool games can you play with Freebsd?


----------



## SPlissken (Dec 1, 2008)

Well with wine you can play lot of game
Personnaly i play Warcraft III event in multi mode on Bnet


----------



## adamk (Dec 1, 2008)

I've played doom3, quake4, Neverwinter Nights, and ut2004 on FreeBSD.  There are other commercial games written for LInux that work fine on FreeBSD, and even various open source games.  Most are available via the ports tree.

Adam


----------



## lme@ (Dec 1, 2008)

Jagged Alliance 2 just kicks ass!


----------



## dap (Dec 1, 2008)

I only play OpenTTD (which is pretty good), I would also play Quake 3 if I had a suitable driver.
I quite agree on your quote, it's far easier to play games on Windows.


----------



## marius (Dec 1, 2008)

If I remember correct, Half Life 2 should work on Linux (and probably FreeBSD).

I thought people liked to run FreeBSD because they wanted a solid server or a nice workstation, but I see no reason for running FreeBSD if what you want to do is play games. Gaming isn't bad, it's not that, but why make things harder than necessary? There aren't many games out there for Linux/BSD. Anyway, Windows works fine for gaming, so that's what I use for that purpose.

To be honest I have no experience with gaming on FreeBSD. How well does it actually work?


----------



## Djn (Dec 2, 2008)

I play World of Warcraft in Wine, with ventrilo (also in wine) for voice chat.  It's markedly slower than windows, but good _enough_, and that's perhaps illustrative of the role wine plays: It means I don't have to reboot just to do a WoW raid. 

One thing openGL has going for it at the moment is that it's the only alternative on macs, and their market share is steadily (if ever so slowly) growing. 

In an entirely different direction, OpenTTD is great.


----------



## rliegh (Dec 2, 2008)

To answer Marius' question -the biggest reason to use *BSD for gaming instead of Windows is because *BSD is a vastly more secure platform than Windows is. Even with anti virus and a firewall I can't escape the feeling that I've got a huge bullseye painted on me.

I haven't had a lot of luck -I've tried running Alien Arena (a 50's sci-fi styled FPS based on the quake 3 source) with no luck on 7.1-PRERELEASE. But the more I can do with FreeBSD, the less I need windows for -and that's less that I have to worry about crackers.


----------



## Eponasoft (Dec 2, 2008)

&quot said:
			
		

> OpenGL is becoming more irrelevant day after day.


Umm...whatever. Whoever said that is a complete fanboy. OpenGL is only irrelevant if you're using Windows Vista. The majority of Vista installations are in business environments; Windows XP is still the dominant Windows OS for home users and will be for some time to come, much to Microsoft's dismay. OpenGL works wonderfully in Windows XP and, of course, in most flavors of Linux. Furthermore, current video game consoles also use OpenGL variants (exception: Xbox 360); I can even code in OpenGL on my Nintendo DS. Irrelevant? Hardly.


----------



## marius (Dec 2, 2008)

rliegh said:
			
		

> To answer Marius' question -the biggest reason to use *BSD for gaming instead of Windows is because *BSD is a vastly more secure platform than Windows is. Even with anti virus and a firewall I can't escape the feeling that I've got a huge bullseye painted on me.
> 
> I haven't had a lot of luck -I've tried running Alien Arena (a 50's sci-fi styled FPS based on the quake 3 source) with no luck on 7.1-PRERELEASE. But the more I can do with FreeBSD, the less I need windows for -and that's less that I have to worry about crackers.



There is nothing I want more than using a secure operating system, but at what cost... If I want to play I really just want to play, not configure and solve problems. Using an up to date version of Windows, with anti-virus and a firewall, should be decent enough for gaming. No one said that we had to have any "secret" or important documents or anything else on that Windows-computer 

But of course, I do agree with you.


----------



## Dr_Phoenix (Dec 2, 2008)

The first game I play on FreeBSD is FreeCraft, it is so cool, have many innovated features, can create own large size maps with all units ever available in the game! Try it and remember old good WarCraft 2 )


----------



## tangram (Dec 2, 2008)

I play Wolfenstein: Enemy Territory (ET). It's an online team oriented world war II multiplayer game. Been playing it for over 5 years and is actually the only game I play when I have time (not much unfortunately).

You can get it at /usr/ports/games/linux-enemy-territory/.


----------



## MorgothV8 (Dec 2, 2008)

Played Starcraft - Broodwar few times...
it was long time ago, using wine, and game was really slow but gaming was hardly possible


----------



## Elwood (Dec 2, 2008)

What's about /usr/ports/games/warzone2100 ? GPLed Game by EIDOS.
See also: http://wz2100.net/

Elwood


----------



## graudeejs (Dec 2, 2008)

```
OpenGL is becoming more irrelevant day after day.
```
That is nonsense.
OpenGL is used by HighTech design programs (cad/cam....)
for example i know for 100% that SolidWorks use OpenGL, i'm not 100% sure about MasterCam and AutoCad

As far as i know, OpenGL is much more preferred in commercial cad/cam software. 
OpenGL will play important role in 3D as long as there is no better alternative


----------



## lazyBSD (Dec 2, 2008)

Funny time eater â€” games/bzflag.


----------



## Djn (Dec 2, 2008)

lazyBSD said:
			
		

> Funny time eater â€” games/bzflag.



Hah, I think I have a copy of the IRIX version on my O2


----------



## Dr_Phoenix (Dec 3, 2008)

Linx's Quake3 works very pretty on FreeBSD with linux_base enabled and Video Card OpenGL drivers installed, network playing supported great too...


----------



## kamikaze (Dec 3, 2008)

ioquake3 works very well, without the Linux stuff.


----------



## hugo (Dec 4, 2008)

I play neverwinter nights, enemy territory, and quake 3. Also ran warsow for awhile.


----------



## arust (Dec 5, 2008)

I play some emulator game on FreeBSD, like FC, SFC, MD


----------



## paulfrottawa (Dec 5, 2008)

Thanks for answering this was very useful for another thread I started at thepeacearch (my favorite forum.

This place is good to but not for everyday politics and stuff.


----------



## hemi (Dec 8, 2008)

There's an OpenArena port...I'm going to update it to the latest version sometime this week.


----------



## morbit (Jan 5, 2009)

I recently installed OpenArena 0.8.1 from zip file, (http://openarena.ws/files.html  , http://openarena.wikia.com/wiki/FAQ#How_do_I_install_it_under_FreeBSD_.3F) runs nice on FreeBSD 7.1-PRERELEASE, would prefer port installation though.


----------



## ale (Jan 5, 2009)

tangram said:
			
		

> I play Wolfenstein: Enemy Territory (ET).


I was an ET player too. It's incredible how addictive it could be. I remember that I was able to spend 6+ hours playing it continuously. And sometimes I was playing a map or two before going to work. I was also in a clan but the server of my mates disappeared.
Unfortunately last time I checked I didn't find the servers where  I was used to play.
Anyway I have installed
games/linux-quake4
games/linux-doom3
games/linux-rtcw
games/linux-enemyterritory
games/vavoom (doom1/2/final-hexen-heretic-strife)
games/quakeforge
games/ultimatestunts
but I also have
emulators/xmame (arcade games emulator)
emulators/vice (to feel nostalgia for the times when I was kid)


----------



## tangram (Jan 5, 2009)

Yeah I also played competitively on a couple of clans but real life caught up eventually 

Nowadays I just play it occasionally namely on 195.4.17.142:27960 which is http://enemy-territory.4players.de:1041/index.php game server and sometimes of Portuguese servers. I go by the name of tangram"FreeBSD~.

Also have installed RTCW and Quake3. On Linux I also used to play RTCW: Demo for a while and tried Tremulous which has a port I think.


----------



## jsa@ (Jan 6, 2009)

http://www.vendetta-online.com/

The Linux version runs smooth in emulation. I've been meaning to write a how-to for a while. It's really about as simple as your linux-base port, linux-gtk2, and the linux-dri. Doesn't matter which linux kernel you emulate or base port version you choose.

If enough people like it, help me show the head of the company (John Bergman aka Incarnate of Guild Software) that there is enough demand for a FreeBSD native version.


----------



## nakal (Jan 7, 2009)

The best 3D-shooter I've ever played is Unreal Tournament (games/linux-ut).

I played it regularly, but it's not possible anymore. :\ I have bought an RV630-based card and am waiting for DRM since a couple of months already. Fortunatelly, Mr. Robert Noland (who is my personal hero at the moment, see link to his email on freebsd-stable@) announced that he works at it and is waiting for the docs from AMD at the moment.


----------



## hugo (Jan 10, 2009)

tangram said:
			
		

> Yeah I also played competitively on a couple of clans but real life caught up eventually
> 
> Nowadays I just play it occasionally namely on 195.4.17.142:27960 which is http://enemy-territory.4players.de:1041/index.php game server and sometimes of Portuguese servers. I go by the name of tangram"FreeBSD~.
> 
> Also have installed RTCW and Quake3. On Linux I also used to play RTCW: Demo for a while and tried Tremulous which has a port I think.



Were you tangram GNU/Linux before? If that is so, I've seen you on the battlefields a couple of times


----------



## cajunman4life (Jan 10, 2009)

I tried warzone2100 the other day, and during a battle it crashes. I'm going to run it through gdb when I get a chance and try to figure out why... but otherwise, this thread has been full of good ideas of games to try.


----------



## ter2007 (Jan 11, 2009)

I want to try the original Falcon 4. (wine). I have my doubts but you never know it might work. If it ever does work under wine, it will almost certainly run better than it ever did under Winblows 98.


----------



## tangram (Jan 11, 2009)

hugo said:
			
		

> Were you tangram GNU/Linux before? If that is so, I've seen you on the battlefields a couple of times



Yup 

Those were the times I used Gentoo to play ET, nowadays it's tangram"FreeBSD~ 

You go by which nick?


----------



## ale (Apr 10, 2009)

This has just been committed
games/rigsofrods

Looking at the video here http://www.rigsofrods.com/ , it looks funny, for a while


----------



## tangram (May 18, 2009)

In an attempt to not this thread die... there's an HOWTO: Install and setup Wolfenstein Enemy Territory over at the Howtos & FAQs corner of the forum .


----------



## Nokobon (May 18, 2009)

tangram said:
			
		

> In an attempt to not this thread die... there's an HOWTO: Install and setup Wolfenstein Enemy Territory over at the Howtos & FAQs corner of the forum .



Soon I'm going to use PCBSD instead of openSUSE as desktop,
is there any difference between installing ET on standard FreeBSD and PCBSD?


----------



## tangram (May 18, 2009)

I don't use PC-BSD so I'm not 100% sure whether there is already an ET PBI. If there is one use it, else the posted HowTo should work just fine.


----------



## Nokobon (May 18, 2009)

Okay, I'll see.
And thank you for the HowTo!


----------



## tangram (May 18, 2009)

No problem 

My pleasure.


----------



## Crestfallen (May 28, 2009)

World of Warcraft runs with 50+ FPS

AMD Athlon 3600
1.5 GB DDR2
Nvidia GeForce 5700FX


----------



## copypaiste (Jun 23, 2009)

I used to run windows psx emulator in wine to play Metal Gear Solid. It preforms better than linux version of ePSXe from ports. Wine, dosbox and scummvm are enough to play some good ol' games like Nox, Rune, Scorched earth and various adventures ^_^v


----------



## amdmi3@ (Jul 21, 2009)

(after adding 3 more games to ports)

If you ask me, FreeBSD is an excellent gaming platform. Emulators for many many gaming platforms, dosbox and wine (now also virtualbox), Linux binary support and of course extensive collection of native (f/oss) game ports which I and many other committers and contributors are trying best to keep up to date and expand even further.

There are some problems, of course, but these mostly originate from proprietary hardware/software, not FreeBSD itself, and I believe will be solved rather sooner than later.

Also see my games-related page on wiki:
http://wiki.freebsd.org/DmitryMarakasov/Games


----------



## ericbsd (Jul 22, 2009)

When I have time to play I shooters game like:
games/sauerbraten
games/cube
games/nexuiz
games/quake3
games/alienarena
games/linux-quake4

and sometime I play games/warsow.


----------



## drhowarddrfine (Jul 22, 2009)

Eponasoft said:
			
		

> The majority of Vista installations are in business environments;



Whenever anyone brings up games on BSD, and that they can't play Windows games or as many games as Windows, makes me say the same thing. The majority of BSD installations are in business environments and BSD is for professionals. If you want to play games, get a Playstation.


----------



## gr1ml0ck (Aug 10, 2009)

COUNTER STRIKE SOURCE + WINE * FREEBSD = FTW!!!!!!!!!!!

I've been a player of CS since beta and can't have a computer that wont play it in my house!!!


On an Asus M50sv in 64bit Windows I get 145 fps in max settings.
On an Asus M50sv in 64bit Linux I get 30 fps in max settings.
On an Asus M50sv in i386 FreeBSD CURRENT I get 140 fps using wine with everything maxed out and running in windowed mode 1440x900!!!!!

Audio works, I don't random crashes anymore.  The whole wine project is slowly becoming polished enough to handle these windows games.

I would find it hard to truly enjoy any computer system which limits my abilities to have fun.. even if it does mean that I have uber stability and power.. I want both pies.. and that cake over there.. in fact.. just push the trolley this way and i'll eat the lot!!! ROFL!!


----------



## Deleted member 48958 (Jun 6, 2017)

Personally, I like to play doom and its wad-s with games/prboom.

Also, one of my favourite cli games is   games/moon-buggy.






Also I like very much 2048 cli game, it is posible to build it on FreeBSD:

```
% wget https://raw.githubusercontent.com/mevdschee/2048.c/master/2048.c
% cc -o 2048 2048.c
% ./2048
```
It is possible to move ./2048 to /usr/local/bin/, also, or to /home/user/.local/bin/, for example,
(you need to add .local/bin to your path, add "`set path = ( $path $HOME/.local/bin )`" to your ~/.tcshrc),
and start it like this:
`% 2048`





It is possible to use different colors:
`% 2048 blackwhite`





`% 2048 bluered`.


----------



## Spartrekus (Jul 7, 2017)

Grand Theft Auto !!! 

It is great !


----------



## Deleted member 30996 (Aug 24, 2017)

I've played games/ioquake3, games/HeroesOfMightAndMagic, games/warzone2100, games/ufoai (which is pretty cool and a take on Xcom UFO Defence), and some of the games/bsdgames. 

Right now all I have installed are games/heretic, games/xinvaders and games/moria. I save my games/moria files from one build to the next but haven't played it for a while

Not really games, but ones I have built that fall into that category are games/cowsay and games/asciiquarium.


----------



## aimeec1995 (Sep 7, 2017)

On 32bit freebsd you can get a wide range of games to run via wine-staging.


----------



## Sensucht94 (Sep 7, 2017)

I think we can agree on Windows sadly being the only good plaform for gaming. A pity as I'm not going to buy a Win copy. Mac strikes second, with good native software support, various porting database (like PortinTeam or PortinKit), especially if you like indie games.
Linux is not a good platform and FreeBSD all the more, as it lacks native support for commercial products. That said, a casual gamer, especially a retro gamer, can really have fun playing on FreeBSD, which is what I always do... given same hardware, performance is amazing while launching the same games.

Wine adds many more possibilities, though trying  to install a 64-bit only game on a amd64  FreeBSD is like suicide.
emulators/playonbsd makes life easier sometimes, while hacking with wine. But in other occasions it's better to do things on one's own.
For instance PlayonBSD provides a good, almost working, Steam wine-port, although it's worth trying a native install with: https://github.com/SteamOnFreeBSD/SteamOnFreeBSD ( I had a hard time installing it, and was on the edge of giving up,  but finally did it)

Anyway, latest news about games being built and ported to BSD, have a look to: 
http://www.bsdgaming.com
 Or
https://www.freebsdnews.com/category/miscellaneous/gaming/

I really like strategy games like games/0ad (really much similar to Age of Mythology), games/wesnoth, games/freeciv (Civilization2 opensource remake, but I personally like Sid Meyer's Colonization Best), games/dunelegacy (dun2 clone),games/HeroesOfMightAndMagic, games/openttd, and games/openxcom (if you own a copy of Xcom:Enemy Unknown you can't miss this, it's one of the best 90's games ever made)

If  anyone likes RPGs, then there's games/openmv (but you have to own a copy of TES3:Morrowind, in my opinion the best TES bethesda produces a game no other RPG can keep up with); opnmw project (https://openmv.io/) really enhances game's experience and made me fall in love once again with this awesome game, as I literally grew up with it.

Moreover, an opensource 1st-person-view RPG with great graphics is WorldForge (https://www.worldforge.org/index.php/develop/technical-overview/), it's playable with FreeBSD through Ember client: games/ember

For people who like more classical-style RPGs (like Dragon Age to make myself clear), then there's games/arch-libertatis (http://arx-libertatis.org): it is even better than its commercial version (Arc Fatalis) which takes after. 

Nonetheless, if anyone is interested on even more classical role play games, 3rd person -2D (like Fallout1-2 or Diablo) I think games/flare-game can be a wise choice

Holding on speaking of RPG, planeshift (http://www.planeshift.it/About) has been partially ported to FreeBSD in the past, and despite there's a some sort of official support, as stated in their main page, still you have to compile it.

For what regards shooters, Ericturgeon named some very good titles. I would add games/openarena (still more active than Quake Live, and you do not have to pay for it), games/assaultcube and the fantastic, more modern games/xonotic, as well as the similar, wonderful games/nexuiz



			
				gr1ml0ck said:
			
		

> COUNTER STRIKE SOURCE + WINE * FREEBSD = FTW!!!!!!!!!!!


yes and I can confirm it works like a charm!!!



			
				nakal said:
			
		

> The best 3D-shooter I've ever played is Unreal Tournament (games/linux-ut).


I completely agree with you. It's the first game I've ever played in my life. Quite violent for a little child, but hell, how good is it????

Epic Games has released the new Unreal Tournament 2017 as pre-Alpha. If interested anyone can become a tester and play it for free (https://www.epicgames.com/unrealtournament/), as well as give a look to the new unreal engine, available for download. It's not bad, but I just spent a couple of hours playing it at a friend's place, as I'm really in lack of time recently.


Action games:
- I think any Tomb Raider lover misses somehow the first series (TR I to V), and the opentomb project (https://opentomb.github.io/) is one more reason to bring old memories back:
games/opentomb
- Shadow Warrior is one of those game you can't stop starting over and over again.  So why do not give a try to games/jfsw? The newer remakes of the game (https://en.wikipedia.org/wiki/Shadow_Warrior) are a rare example of something that takes the pros of a prequel and use it as  source of inspiration in order to make it better (tried it on Mac); however I doubt wine would work with something like that.
- games/eduke32 old but gold
- games/endless-sky is an interesting futuristic space-based action game (somehow resembles X-wing)


A great game, really, is games/supertuxkart (mario kart-like game with tons of maps, addons, and opensource project's mascottes as characters). If you can get access to a LAN then you can play smoothly with your friends, while if you know their nick, you can ask as well to any online friend to play with you in multiplayer, though online-multiplayer support is still incomplete.
Another really worthy racing game is games/vdrift



			
				ILUXA said:
			
		

> Personally, I like to play doom and its wad-s with games/prboom.
> 
> Also, one of my favourite cli games is games/moon-buggy.



A thumb up for this. Other CLI-based games I can't miss wherever I go are:
- games/nsnake
- games/nInvaders
- games/0verkill
- games/bastet
- games/gnuchess
- games/nethack
- and bsdgames

I still play Doom. It's one of the few games I've never stopped playing. Just perfect. Online-multiplayer community is still active, in contrast to many other modern games (like DOOM (2017) itself). Mods are so complex that can give a completely new game experience. Plying online on a community-made map within a community-made mode, with a brutaldoom20 mod is incredibly fun. Zandronum+Doomseeker is the default build to attend online matches (https://doomwiki.org/wiki/How_to_play_Doom_online_multiplayer)
There's a Zandronum/Doomseker official port for BSD with good support, and I manged to make it work: https://wiki.zandronum.com/Zandronum_Server_on_FreeBSD

In Addition, It's notable that, provided one owns a copy of Doom3, games/linux-doom3 allows to easily installed it in FreeBSD without any need of wine.

And finally we shouldn't forget about dosbox! Personally, I make dosbox mount the folder with all DOS programs and then make it launch FreeDOS (all done by editing the dosbox configuration file), in order to have my own environment with all the utilities FreeDOS provides (included the Unix-like ones which are really appreciated). On rare occasions I even make FreeDOS launch Win3.11 for workgroups in enhanced mode from within dosbox, thus to play games natively made for win 3 (chessmaster 4000, dark seeds 2, etc), or win 95 games (with 32bit-support patch for win 3)


----------



## Deleted member 48958 (Sep 7, 2017)

aimeec1995 said:


> On 32bit freebsd you can get a wide range of games to run via wine-staging.



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
```


----------



## aimeec1995 (Sep 8, 2017)

ILUXA said:


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



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 (Sep 8, 2017)

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 (Sep 8, 2017)

ILUXA said:


> 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 (Sep 8, 2017)

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 (Sep 9, 2017)

ILUXA said:
			
		

> . 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 (Sep 9, 2017)

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 (Sep 9, 2017)

ILUXA said:


> 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 (Sep 9, 2017)

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 (Sep 9, 2017)

Sensucht94 said:


> 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 (Sep 9, 2017)

Sensucht94 said:


> 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 (Sep 10, 2017)

aimeec1995 said:


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



ILUXA said:


> 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 (Sep 10, 2017)

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 (Sep 10, 2017)

ILUXA said:


> 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 (Sep 17, 2017)

Sensucht94 said:


> Hi aimeec1995. Yes it is indeed.
> View attachment 3973
> 
> Works so far, but only with older games
> ...



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

Thanks, I would love to try it for myself.


----------



## Sensucht94 (Sep 17, 2017)

aimeec1995 said:


> 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 (Sep 17, 2017)

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 (Sep 18, 2017)

Sensucht94 said:


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



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 (Sep 18, 2017)

aimeec1995 said:


> 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 (Sep 18, 2017)

Sensucht94 said:


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




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. (Dec 13, 2017)

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 (Dec 13, 2017)

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 (Dec 13, 2017)

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


A. D. Sharpe Sr. said:


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


Snurg said:


> 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 (Dec 13, 2017)

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 (Dec 13, 2017)

Snurg said:


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



Snurg said:


> 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 (Dec 13, 2017)

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


----------



## A. D. Sharpe Sr. (Dec 14, 2017)

Snurg said:


> 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?



Indeed. I like the sound of that. Who's able to make that happen?


----------



## A. D. Sharpe Sr. (Dec 14, 2017)

Snurg said:


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


----------



## A. D. Sharpe Sr. (Dec 14, 2017)

Just so everyone knows, this exists: http://www.bsdgaming.com. It's kind of dead, because of a lack of content. However, it may be a great place to use as a focal point for all things dealing with BSD gaming.

Just a thought.


----------



## PacketMan (Dec 14, 2017)

Snurg said:


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


----------



## Snurg (Dec 14, 2017)

PacketMan said:


> EDIT - whoops I now see this category falls under desktop.


The forum gods have heard us 
Thanks!!


----------



## A. D. Sharpe Sr. (Dec 14, 2017)

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?


----------



## Snurg (Dec 14, 2017)

A. D. Sharpe Sr. said:


> 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:






Yes... IBM produced even a few games back then.


----------



## A. D. Sharpe Sr. (Dec 15, 2017)

I browsed through some of the code for the Torque3d game engine (by Garage Games). It seems that there's at least some FreeBSD support, but I'm not sure how well it's been exercised. Here's the directory for it's Unix support: https://github.com/GarageGames/Torque3D/tree/development/Engine/source/platformX86UNIX.


----------



## A. D. Sharpe Sr. (Dec 15, 2017)

I created a new thread about potentially usable game engines. You can find it at: https://forums.freebsd.org/threads/63720/


----------



## ekingston (Dec 15, 2017)

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.


----------



## sidetone (Dec 15, 2017)

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.



A. D. Sharpe Sr. said:


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


----------



## A. D. Sharpe Sr. (Dec 15, 2017)

ekingston said:


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


----------



## ekingston (Dec 15, 2017)

A. D. Sharpe Sr. said:


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



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


----------



## sidetone (Dec 15, 2017)

A. D. Sharpe Sr. said:


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





A. D. Sharpe Sr. said:


> Ideally, this is what I'd like things to look like:
> 
> For gaming:
> Graphics: SDL->OpenGL->accelerated 3d 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._


----------



## ekingston (Dec 15, 2017)

A. D. Sharpe Sr. said:


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





sidetone said:


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


----------



## A. D. Sharpe Sr. (Dec 16, 2017)

sidetone said:


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


----------



## A. D. Sharpe Sr. (Dec 16, 2017)

ekingston said:


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


----------



## A. D. Sharpe Sr. (Dec 16, 2017)

sidetone said:


> uhidd will likely replace uhid in base for future releases.



Is there a source reference for this?


----------



## sidetone (Dec 18, 2017)

sidetone said:


> I've heard that uhidd will replace uhid in the base for future FreeBSD releases.





A. D. Sharpe Sr. said:


> Is there a source reference for this?


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.


----------



## A. D. Sharpe Sr. (Dec 18, 2017)

sidetone said:


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


----------



## sidetone (Dec 18, 2017)

A. D. Sharpe Sr. said:


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


----------



## A. D. Sharpe Sr. (Dec 18, 2017)

sidetone said:


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


----------



## A. D. Sharpe Sr. (Dec 19, 2017)

sidetone said:


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


----------



## A. D. Sharpe Sr. (Jul 11, 2018)

Just a heads up, I came across an OpenBSD gaming channel on IRC. If they can organize themselves for this, surely we can.


----------



## kpedersen (Jul 11, 2018)

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



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:


----------



## A. D. Sharpe Sr. (Jul 11, 2018)

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


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!


----------



## dexter234 (Sep 15, 2018)

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.


----------



## A. D. Sharpe Sr. (Sep 16, 2018)

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.



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.


----------



## drhowarddrfine (Sep 16, 2018)

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.


----------



## A. D. Sharpe Sr. (Sep 16, 2018)

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.



NVidia has been providing native FreeBSD drivers with full 3d acceleration for years, now. Where've you been?


----------



## Beastie7 (Sep 16, 2018)

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?


----------



## kpa (Sep 16, 2018)

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.


----------



## drhowarddrfine (Sep 16, 2018)

A. D. Sharpe Sr. said:


> NVidia has been providing native FreeBSD drivers with full 3d acceleration for years, now. Where've you been?


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.


----------



## Deleted member 48958 (Sep 17, 2018)

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.


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.


----------



## Sensucht94 (Sep 17, 2018)

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.



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


----------



## malavon (Sep 24, 2018)

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.


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.


----------



## SirDice (Sep 24, 2018)

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.


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.


----------



## shkhln (Sep 24, 2018)

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.



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



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.


----------



## shkhln (Sep 25, 2018)

shkhln said:


> including actual FreeBSD devs



By the way, 410.57, released 5 days ago, ships libglvnd-compatible libs instead of a regular libGL.so.


----------



## Beastie7 (Sep 25, 2018)

What's the difference between 'mesa3d' and the whole drm thing? I'm having a hard time grasping the purpose of the two.


----------



## Sensucht94 (Feb 23, 2019)

Half life running on i386-wine with OpenGL


----------



## Spartrekus (Feb 23, 2019)

Since you post screenshots,....

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





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 ';'


----------



## shkhln (Feb 23, 2019)

Since you insist on posting screenshots…



Steam, Serious Sam Fusion (benchmark mode, I don't actually play that game much), Nvidia, Vulkan.


----------



## electricdawn (Mar 2, 2019)

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


----------



## drhowarddrfine (Mar 2, 2019)

electricdawn You should start your own thread and not hijack this one.


----------



## electricdawn (Mar 2, 2019)

drhowarddrfine said:


> electricdawn You should start your own thread and not hijack this one.


Since this is about gaming on FreeBSD, I thought this would be on-topic. But no problem, I can start a new one.


----------



## Spartrekus (Mar 2, 2019)

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.


----------



## shkhln (Mar 3, 2019)

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.



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.


----------



## electricdawn (Mar 4, 2019)

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.


----------



## olli@ (Mar 4, 2019)

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.


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 …


----------



## CrowdedNewt (Mar 5, 2019)

I have been trying to get Final Fantasy XIV to run. No luck so far.. I can only get so far as to finish patching. 

Sucks because it runs on Linux with the same methods, I guess it is an issue with 32bit and64bit wine being seperate


----------



## CrowdedNewt (Mar 5, 2019)

shkhln said:


> Since you insist on posting screenshots…
> 
> View attachment 6144
> 
> Steam, Serious Sam Fusion (benchmark mode, I don't actually play that game much), Nvidia, Vulkan.



Hey, how are you running the 64bit version? 
thanks


----------



## shkhln (Mar 6, 2019)

CrowdedNewt said:


> Hey, how are you running the 64bit version?



See this patch, which in turn is based on https://reviews.freebsd.org/D16830. Although I would rather recommend you to try my previous approach to enabling wow64 since it doesn't require custom patches:

build _i386-wine-devel_ port and install it;
build _wine-devel_ port and copy it to /opt/wine without installing;
add /opt/wine/usr/local/bin to $PATH;
before using Wine start 64-bit wineserver explicitly with `env WINEPREFIX=whatever /opt/wine/usr/local/bin/wineserver --foreground --persistent`
Remember to keep _i386-wine-devel_ and _wine-devel_ versions in sync.


----------



## CrowdedNewt (Mar 7, 2019)

shkhln said:


> See this patch, which in turn is based on https://reviews.freebsd.org/D16830. Although I would rather recommend you to try my previous approach to enabling wow64 since it doesn't require custom patches:
> 
> build _i386-wine-devel_ port and install it;
> build _wine-devel_ port and copy it to /opt/wine without installing;
> ...



thanks


----------



## fasxmt (Mar 10, 2019)

Playing games on FreeBSD has no problems. It is your freedom to do or not. I am playing games/nexuiz, games/alienarena.


----------



## SirDice (Mar 11, 2019)

Hopefully I have some time to test emulators/mame this week. The version in the ports tree is still 0.200. I've managed to get the port updated to 0.207. The port builds, some patches were required and I needed to adjust pkg-plist. Poudriere's 'testport' is happy with it. I have an extensive ROM collection for 207 ready to go. But need to see if it actually works before I can submit patches for it.

Getting MAME roms is the tricky bit. But if you have good sets you can play quite a lot of games, including classics like "Donkey Kong", "Space Invaders" or "Galaga". And I don't mean remastered or remade stuff, I mean the actual original arcade games.


----------



## Sevendogsbsd (Mar 11, 2019)

Just bought (rebought) Diablo I on GOG - runs with wine but not yet playable because the menus are black. Lots of discussion about it on GOG forums so perhaps someone will come up with a fix. The scenematics (?) run fine ,odd that the menus don't.


----------



## D-FENS (Mar 11, 2019)

paulfrottawa said:


> At a forum I participate I was told this.
> 
> 
> 
> ...



Simply install emulators/dosbox, emulators/zsnes, emulators/gens, emulators/stella, emulators/mame.
Then download thousands and thousands old DOS games, SEGA, Nintendo, Arcade, ATARI or whatever your heart wishes and dive into the exciting and endless world of retro gaming.

Who needs DirectX, when you can play Super Mario or digger?


----------



## shkhln (Mar 12, 2019)

Both ZSNES and Gens are no longer developed. And they are not particularly accurate emulators either, so no reason to stick with them.



roccobaroccoSC said:


> exciting and endless world of retro gaming ... Who needs DirectX



Please, don't take it personally, but I really hate this kind of well-meaning advice. You are essentially burying any useful information about current multimedia/gaming situation (wine, linuxulator, fnaify, widevine, etc) under piles of pointless "you don't need it" arguments.


----------



## CrowdedNewt (Mar 12, 2019)

roccobaroccoSC said:


> Simply install emulators/dosbox, emulators/zsnes, emulators/gens, emulators/stella, emulators/mame.
> Then download thousands and thousands old DOS games, SEGA, Nintendo, Arcade, ATARI or whatever your heart wishes and dive into the exciting and endless world of retro gaming.
> 
> Who needs DirectX, when you can play Super Mario or digger?



This post excited me but then I remembered I have no idea where to get games for these.


----------



## D-FENS (Mar 12, 2019)

CrowdedNewt said:


> This post excited me but then I remembered I have no idea where to get games for these.



Just search on the web for ROMs. The systems are Sega MegaDrive, SuperNintendo, Atari and DOS. There are tons of sites.


----------



## sidetone (Mar 13, 2019)

roccobaroccoSC said:


> Just search on the web for ROMs. The systems are ...


Those comments bring negative attention.


----------



## shkhln (Mar 13, 2019)

roccobaroccoSC, I think you are a bit confused. The only way to legally download Nintendo's first-party titles is through their Virtual Console service available on their own hardware. With the exception of redumping original cartridges, anything else is strictly illegal. As for abandonware, it doesn't have any legal definition, so it still constitutes copyright infringement, although usually it is "nobody cares" type of situation.


----------



## D-FENS (Mar 13, 2019)

shkhln said:


> roccobaroccoSC, I think you are a bit confused. The only way to legally download Nintendo first party titles is through their Virtual Console service available on their own hardware. Anything else is strictly illegal, except maybe redumping original cartridges. As for abandonware, it doesn't have any legal definition (allowing redistribution), so it's still constitutes copyright infringement, although usually it is "nobody cares" type of situation.


I will not debate the legal topics here. That was exactly the reason I did not want to cite URLs. The web sites have owners and those owners are responsible for ensuring the published content is legal. It is impossible as a web user to verify the legality of every file my browser downloads. This is off-topic.
I removed the post with the URLs to avoid future confusion.

Fact is - the metioned emulators are playable on FreeBSD, with thousands of titles to play. Sourcing the ROMs from a legal distributor is a completely separate topic. For what I am concerned, you just go to GameStop and buy the ROMs on a DVD.


----------



## SirDice (Mar 13, 2019)

Yes, same holds true for MAME roms. They're easy enough to find but have dubious legality. There are even shops that sell complete sets on disk but none of them are legal (although lots of shops claim they are).


----------



## sidetone (Mar 13, 2019)

They're only legal if you own the cartridge, cd or arcade case. The owners of those websites say that you must or should own the game in order to download the rom.

Authors still have a desire to still make money off of abandonware too. Some companies don't care, but Nintendo sues rom websites, because they want to sell old NES games on Switch. The MAME website says that ROM downloading and abandonware software is not in gray area. Talking about it brings unwanted attention.


----------



## SirDice (Mar 19, 2019)

SirDice said:


> But need to see if it actually works before I can submit patches for it.


My test machine turned out to be a bit underpowered but everything worked. Slowly, but working. In any case: PR 236621


----------



## D-FENS (Mar 19, 2019)

SirDice said:


> My test machine turned out to be a bit underpowered but everything worked. Slowly, but working. In any case: PR 236621


The emulators discussed above (incl. mame) work on 1,4 GHz single core CPU with 256 MB RAM. Anything better than that should have no problems.


----------



## CrowdedNewt (Apr 21, 2019)

shkhln said:


> See this patch, which in turn is based on https://reviews.freebsd.org/D16830. Although I would rather recommend you to try my previous approach to enabling wow64 since it doesn't require custom patches:
> 
> build _i386-wine-devel_ port and install it;
> build _wine-devel_ port and copy it to /opt/wine without installing;
> ...



I do not see how I would use that patch...?
Could you be more in depth with your steps please?


----------



## shkhln (Apr 21, 2019)

CrowdedNewt said:


> I do not see how I would use that patch...?



You shouldn't. You only need this patch _if_ you want to _work_ on it. Otherwise you should wait for the port maintainer to do something about building wow64 Wine.



CrowdedNewt said:


> Could you be more in depth with your steps please?



I completely suck at explaining things from scratch, sorry.


----------



## Spartrekus (Apr 21, 2019)

Maybe the PS4 is one of the best example of BSD gaming 
Ever played NFS Payback?


----------



## shkhln (Apr 22, 2019)

Spartrekus said:


> Maybe the PS4 is one of the best example of BSD gaming
> Ever played NFS Payback?



No and no.


----------



## Spartrekus (Apr 22, 2019)

ok

i tried wine with gta vc on 12 freebsd. i.e. vice city.
it turns around

question
is the game pad working in gta vc


----------



## shkhln (Apr 22, 2019)

Spartrekus said:


> is the game pad working in gta vc



Wine has an evdev gamepad backend, an SDL 2 gamepad backend and some kind of an HID backend. The first two aren't compiled by default on FreeBSD and I'm not quite sure what the last one actually does. Your best bet is recompiling Wine with SDL 2.


----------



## shkhln (Apr 22, 2019)

shkhln said:


> Your best bet is recompiling Wine with SDL 2.



On a second look, I don't see SDL 2 gamepad events being routed to dinput. Might want to borrow some bits from the Valve's Wine fork.


----------



## ultrageranium (Jun 23, 2019)

shkhln said:


> build _i386-wine-devel_ port and install it;
> build _wine-devel_ port and copy it to /opt/wine without installing;
> add /opt/wine/usr/local/bin to $PATH;
> before using Wine start 64-bit wineserver explicitly with `env WINEPREFIX=whatever /opt/wine/usr/local/bin/wineserver --foreground --persistent`
> Remember to keep _i386-wine-devel_ and _wine-devel_ versions in sync.



Thanks for sharing this, could you suggest a way to keep these versions in sync?


----------



## shkhln (Jun 23, 2019)

ultrageranium said:


> could you suggest a way to keep these versions in sync?



I don't quite understand that question.


----------



## Vallenhack (Jun 23, 2019)

http://www.wine-reviews.net/2019/01/wine-stable-release-40-is-now-available.html - someone tried?


----------



## shkhln (Jun 23, 2019)

Vallenhack said:


> http://www.wine-reviews.net/2019/01/wine-stable-release-40-is-now-available.html - someone tried?



Tried what?


----------



## Vallenhack (Jun 23, 2019)

https://dl.winehq.org/wine/source/4.0/wine-4.0.tar.xz - compiling this.


----------



## shkhln (Jun 23, 2019)

I don't have any issues compiling Wine. Why do you think it's a problem?


----------



## Vallenhack (Jun 23, 2019)

Because always is problem. However this is a Valve version of wine. In FreeBSD repository is exist a older version without Vulcan support and DX12.


----------



## shkhln (Jun 23, 2019)

The _i386-wine-devel_ official repo package is dead. It should be possible to build one from ports, however.


----------



## Vallenhack (Jun 23, 2019)

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.


----------



## shkhln (Jun 23, 2019)

Vallenhack said:


> But ports do not have a newest 4.0, 4.2 WINE



https://www.freebsd.org/cgi/ports.cgi?query=wine-devel



Vallenhack said:


> And FreeBSD need a dedicated driver for Graphic.



This doesn't make sense.



Vallenhack said:


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



I have no idea what you are talking about.


----------



## shkhln (Jun 23, 2019)

Vallenhack said:


> https://svnweb.freebsd.org/ports/head/emulators/i386-wine-devel/ - AGE.



It's a so-called slave port with two (!) distinct package building paths in Makefile.inc and Makefile.i386. First one actually builds the package (with the same version as _wine-devel_, 4.10 as of now) and another does repackaging for the official repo.


----------



## Vallenhack (Jun 23, 2019)

Newest version of WINE is a 4.2. It have Direct3D and Vulkan support and probably Valve Inc. working on it, because steam. And FreeBSD do not have it.


----------



## Vallenhack (Jun 23, 2019)




----------



## kpedersen (Jun 23, 2019)

Vallenhack; Many games do not use Vulkan yet. Direct3D is very well supported. Are you just wanting 4.3 because the numbers are higher or is there an actual reason for your concern?


----------



## shkhln (Jun 23, 2019)

kpedersen said:


> Vallenhack; Many games do not use Vulkan yet. Direct3D is very well supported. Are you just wanting 4.3 because the numbers are higher or is there an actual reason for your concern?



Sounds like Vallenhack has a few facts mixed up. Last year Valve introduced Steam Play, which a way of playing Windows games under the Linux Steam client. The actual tool, Proton, consists of Steam integration (obviously); Valve's Wine fork, currently at version 4.2; dxvk and a few more libs. Dxvk is a d3d11-to-vulkan translation layer, which development Valve sponsors.

Now, why would someone expect anything of that to be available under FreeBSD is beyond me. We don't even have a proper automatic procedure for building _i386-wine-devel_ package, it has to be uploaded to the repo by the maintainer.


----------



## malavon (Jun 23, 2019)

Vallenhack said:


> Newest version of WINE is a 4.2. It have Direct3D and Vulkan support and probably Valve Inc. working on it, because steam. And FreeBSD do not have it.


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


----------



## shkhln (Jun 23, 2019)

malavon said:


> shkhln … Also, you have a double post



I don't think so. Probably XenForo ajax magic breaking.


----------



## shkhln (Jun 23, 2019)

malavon said:


> 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



There is no point in working on that until FreeBSD Wine packaging issues are solved.


----------



## shkhln (Jul 3, 2019)

shkhln said:


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



…10 months. Does anybody here actually want WoW64 Wine or not?


----------



## malavon (Jul 3, 2019)

shkhln said:


> …10 months. Does anybody here actually want WoW64 Wine or not?


I for one do, but I don't have commit power nor am I involved in any of the Wine ports. I guess that's true for most people who'd like to see that.


----------



## shkhln (Jul 4, 2019)

Well, it's not happening. What would be the reasonable course of action?


----------



## malavon (Jul 9, 2019)

I wish I knew. I remember seeing this on the mailing list once, so I'm guessing you already tried that. If I'm wrong, that's probably still the best bet.


----------



## shkhln (Jul 9, 2019)

malavon said:


> I remember seeing this one the mailing list once, so I'm guessing you already tried that.



Definitely wasn't me. For what it's worth, I dislike (mostly for inability to edit typos) and usually ignore mailing lists.


----------



## christhegeek (Jul 15, 2019)

gaming on FreeBSD ? you are so optimistic you people !
I want to save my time from gaming so I have no problem with that.


----------



## shkhln (Jul 15, 2019)

I can't tell whether this was encouraging or dismissive comment.


----------



## malavon (Jul 15, 2019)

shkhln said:


> Definitely wasn't me. For what it's worth, I dislike (mostly for inability to edit typos) and usually ignore mailing lists.


The thing is that the only possibility to reach developers is through the mailing lists. The forum is for users, but if you want to have deep-going technical discussions the mailing lists are definitely the place to go.


----------



## shkhln (Jul 15, 2019)

malavon said:


> The thing is that the only possibility to reach developers is through the mailing lists.



D16830 already has the i386-wine port maintainer as an author and the wine port maintainer as a reviewer. Could it possibly benefit from more eyes? There aren't that many developers interested in multilib.


----------



## malavon (Jul 15, 2019)

shkhln said:


> D16830 already has the i386-wine port maintainer as an author and the wine port maintainer as a reviewer. Could it possibly benefit from more eyes? There aren't that many developers interested in multilib.


It's a longshot, I know, but it might draw some attention back to it. It also might not  The bugzilla however generally only draws attention from the people specifically looking at X like wine.
In the end, even though only wine would benefit from it, it would be a change to the general ports system and thus might interest other people beyond only wine-interested ones. It also might draw critique/reviews to the bugzilla.


----------



## shkhln (Jul 15, 2019)

malavon said:


> The bugzilla however generally only draws attention from the people specifically looking at X like wine.



Oh, it's not Bugzilla. I believe the FreeBSD bug tracker is actually supposed to have some formal escalation rules with maintainer-feedback/maintainer-timeout. There are zero expectations for Phabricator reviews. It's more like personal working space as I understand it.



malavon said:


> In the end, even though only wine would benefit from it, it would be a change to the general ports system and thus might interest other people



Or it could attract more elaborate proposals that would take too much effort to implement and thus postponed indefinitely. I kind of suspect this might already be the case considering the most prominent multilib implementation is (quite obnoxious) Debian's multiarch.


----------



## malavon (Jul 16, 2019)

For the record and to be complete, the mailing list mails that I spoke of earlier can be found online. They didn't attract a lot of attention as they were.


----------



## CraigHB (Jul 16, 2019)

I do like to browse the lists, that's a nicer format than the one I normally go to at the FreeBSD Archives.  I don't like to sign up for the lists because I find them hard to deal with in the flat way posts appear in my inbox (not threaded).  So I subscribe when I want to post something then unsubscribe when I'm done with the thread.

Edit:  looking around more at that site I see it allows you to participate in a list similar to the way a forum works.  You can even shut off getting emails to your inbox.  Man I've been wanting to access the lists like that for ages, well at least since I've been using FreeBSD, a couple years now.


----------



## shkhln (Jul 16, 2019)

To be clear, we are not discussing the mailing lists here. You might want to look at a few preceding posts for context.


----------



## takem3h0me (Jul 18, 2019)

I know that gaming on FreeBSD is like gaming on Linux ~7 years ago, we have most opensource emulators (Reicast, Mednafen, Dolphin, RPCS3, mupen64-plus, DOSBox, DGen, Snes9x, FceuX, PPSSPP, Yabause, PCEmu, MAME, UAE, Hatari, Vice, GNUBoy, mGBA). It means that with those we can play all PSX/PSP/PS3, Genesis/Saturn/Dreamcast, NeoGeo, NES/SNES/N64/GameCube/Wii, Gameboy/GBC/GBA, DOS/Win9x, Amiga/C64 games. Can you guys suggest some exciting titles to play, not a relative to Android games because I think I've already played all the Android games on Apknite.


----------



## toorski (Jul 18, 2019)

Just got done looking at my 2005 *nix archives on an old HD full of dust, circa 2007 
There, I found native linux installation binaries/scripts for retail games of: *Doom3, Quake4, UT2004, ETQW and Prey.*
Now, I'm thinking of creating debjail to see if those good'n old games would even install without the old libgc* and others.


----------



## shkhln (Jul 18, 2019)

takem3h0me said:


> Can you guys suggest some exciting titles to play



Frankly, no. Use https://www.mobygames.com or ask on some gaming community site.


----------



## shkhln (Jul 18, 2019)

toorski said:


> Doom3, Quake4



dhewm3 port, linux-quake4 port



toorski said:


> UT2004



Runs acceptably under Wine. It's a D3D-first game, the Linux port is likely to provide worse experience.


----------



## toorski (Jul 18, 2019)

shkhln said:


> dhewm3 port, linux-quake4 port
> 
> 
> 
> Runs acceptably under Wine. It's D3D-first game, the Linux port is likely to provide worse experience.



I'm not into gaming in FreeBSD, so I never looked@games port.
Some time, long ago, I did try linux-ut2004-demo port, in FreeBSD, to test performance of my GTX960/4GB-VRAM.
The game ran very well actually, so I was happy with 3D performance of the GTX960.
I don't see the game in ports anymore, I guess due to lack of maintainer.
But, I just installed linux-doom3-demo (the FreeBSD port) to test It perfroms and plays very well!
Thanks for the hints


----------



## Sevendogsbsd (Jul 18, 2019)

I game on FreeBSD but no steam obviously.  I use 32 bit wine and the older games I play work perfectly.


----------



## shkhln (Jul 18, 2019)

Sevendogsbsd said:


> I game on FreeBSD but no steam obviously.



You mean Linux Steam?


----------



## Sevendogsbsd (Jul 18, 2019)

Yeah, but I could try and run windows steam on FreeBSD via wine. I have just never tried it. I could try Linux steam using the Linux emulation in FreeBSD but I've never done that. Just need to figure it out.


----------



## shkhln (Jul 18, 2019)

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.


----------



## Sevendogsbsd (Jul 18, 2019)

No complaint and I didn't expect anything different. I have never tried either one so didn't know the challenges for either choice. My guess would be windows steam in wine is easier.


----------



## shkhln (Jul 18, 2019)

Sevendogsbsd said:


> My guess would be windows steam in wine is easier.



Quite a bit in fact as you don't have to fight each game individually.

Ironically, I'm actually thinking about getting the Linux Steam client and Proton working. Proton is basically a Wine distribution integrated with the Linux Steam client, so it should be useful for tracing Windows games (with WINEDEBUG) without trace output from the Windows Steam client getting in the way. Intermixed client/game trace output is a real PITA.


----------



## Sevendogsbsd (Jul 18, 2019)

Interesting.  I would be happy to do some testing if you need a Guinea pig. Are you planning on using Linux emulation for the solution?


----------



## shkhln (Jul 18, 2019)

Sevendogsbsd said:


> Are you planning on using Linux emulation for the solution?



At least the Valve's Wine fork can be compiled natively. I haven't looked into other parts of Proton yet. The Linux client obviously requires Linux emulation.

As you can see, currently I'm busy meta-complaining about the lack of complaints for zero attention given to the lack of multilib support in ports. Which is a prerequisite for both WoW64 Wine _and_ Proton. I do not plan to work on anything until that issue is resolved.


----------



## Phishfry (Jul 18, 2019)

What about joystick and gamepad controller GUI applications?
All I can find is jstest and I could never seem to get a /dev/js0 found.  I had linux enabled, cuse, webcamd.
I thought it should have worked. Anybody used this? How can I map gamepad controls to old games like games/xinvaders?
sysutils/jstest-gtk


----------



## shkhln (Jul 18, 2019)

Applications using SDL 2 should work with HID controllers without any setup. Mapping gamepad to X11 keyboard and mouse input might be a bit tricky, I need to look into it. https://www.freshports.org/emulators/joytran/ maybe?


----------



## Phishfry (Jul 18, 2019)

I would be happy with keyboard -to-gamepad mapping.
As per this post I tried this program with no luck. I could not figure how it works.
Seemed to be more about ROM's and emulation. Inputs are there but I cant figure it out.


Shadow53 said:


> I've got the F310 and it works fine with Mednafen.


emulators/mednafen


----------



## shkhln (Jul 18, 2019)

Phishfry said:


> emulators/mednafen



See https://mednafen.github.io/documentation/#Section_using:


> ALT + SHIFT + [_n_]Configure buttons for emulated device on input port _n_(1-8).


----------



## Phishfry (Jul 18, 2019)

Yes but how to fire up game with it.
`mednafen xinvaders`
Does the app run under it like this?
Usage: mednafen [OPTION]... FILE


> Starting Mednafen 1.22.1
> Build information:
> Compiled with gcc 4.2.1 Compatible FreeBSD Clang 6.0.0 (tags/RELEASE_600/final 326565)
> Compiled against zlib 1.2.11, running with zlib 1.2.11(flags=0x000000a9)
> ...


----------



## shkhln (Jul 18, 2019)

Right, Mednafen is a video game console emulator. It's not a gamepad to keyboard translation program. Joytran does what you want.


----------



## toorski (Jul 19, 2019)

shkhln said:


> 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


----------



## Phishfry (Jul 19, 2019)

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


----------



## shkhln (Jul 19, 2019)

toorski said:


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


----------



## shkhln (Jul 25, 2019)

shkhln said:


> See this patch, which in turn is based on https://reviews.freebsd.org/D16830. Although I would rather recommend you to try my previous approach to enabling wow64…



I feel a bit bad about linking (more than once) an obnoxiously large patch in a gist, so now that thing lives in its own public repo. Still _not_ recommended for general use.


----------



## cabriofahrer (Sep 5, 2019)

shkhln said:


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


----------



## shkhln (Sep 5, 2019)

cabriofahrer said:


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


----------



## shkhln (Sep 5, 2019)

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.


----------



## Deleted member 30996 (Sep 5, 2019)

toorski said:


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


----------



## cabriofahrer (Sep 5, 2019)

shkhln said:


> 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?


----------



## Alexander88207 (Sep 5, 2019)

cabriofahrer said:


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


----------



## shkhln (Sep 5, 2019)

cabriofahrer said:


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



cabriofahrer said:


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


----------



## cabriofahrer (Sep 6, 2019)

shkhln said:


> 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!



shkhln said:


> 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?


----------



## shkhln (Sep 6, 2019)

cabriofahrer said:


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


----------



## cabriofahrer (Sep 6, 2019)

shkhln said:


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


----------



## shkhln (Sep 6, 2019)

cabriofahrer said:


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


----------



## cabriofahrer (Sep 6, 2019)

malavon said:


> From the FreeBSD ports repository
> i386-wine-4.0.1,1
> i386-wine-devel-4.11,1
> wine-4.0.1,1
> ...



I do not understand this. I get:


```
$ 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?


----------



## shkhln (Sep 6, 2019)

shkhln said:


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



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.


----------



## shkhln (Sep 6, 2019)

Also, while we are at it, there is apparently a no-sound-whatsoever issue with some Unity engine games under Linuxulator. It's tracked as https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240043. Some minor linux-c7-alsa-plugins-oss package problems are tracked there as well.


----------



## abishai (Sep 7, 2019)

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.


----------



## shkhln (Sep 7, 2019)

_In comparison with Wine_ it's absolutely bad and that includes Linux as well. Just look at all excitement Proton has generated.



abishai said:


> Even gaming on CentOS is a lottery as some games want newer libstdc++.



FTFY


----------



## cabriofahrer (Sep 7, 2019)

shkhln said:


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


----------



## cabriofahrer (Sep 7, 2019)

shkhln said:


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


----------



## shkhln (Sep 7, 2019)

cabriofahrer said:


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



cabriofahrer said:


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



cabriofahrer said:


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


----------



## christhegeek (Sep 12, 2019)

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



Vallenhack said:


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


----------



## eax.qbyte (Oct 26, 2019)

Has anyone played this little addicting game? games/tomatoes
Try it, you wont forget it. It has various cool tools to blow tomatoes.
My highscore is 501. Here I'll tell you how to rock. keep rolling(orbiting) around a smallest square you find and place bombs.

# = bomb
O = You

#1...________
.......|.............|O
.......|________|
#2.................#3


"You" is waiting for bomb #1 to blow and place next bomb above. That is the best method I've found to make highest score.


----------



## shkhln (Oct 30, 2019)

Either I'm imagining things or Wine is slightly more junky under 12.1. This doesn't look good :/


----------



## Alexander88207 (Oct 30, 2019)

shkhln said:


> Either I'm imagining things or Wine is slightly more junky under 12.1. This doesn't look good :/



What do you mean with more junky?


----------



## shkhln (Oct 30, 2019)

I mean lots of "nested exception" errors. On the positive side, I finally forced myself to actually read this code and apparently that happens when Wine is crashing with segfault in one of its signal handlers. Wouldn't ever guess it from the message.


----------



## Alexander88207 (Oct 31, 2019)

It seems that the steam legacy client is since today officially not longer available, the client downloads straight the newer client and says that winxp is no longer supported, damn.. The problem is that the store and the friends functions don't work with the newer client. This kills playing with friends etc... 

I have found out that downloading a copy of the legacy client before that day and blocking the package folder seems to be the workaround for now. Let's see how long that lasts.


----------



## shkhln (Oct 31, 2019)

Alexander88207 said:


> The problem is that the store and the friends functions don't work with the newer client.



The browser component under Wine shifts between broken and working states all the time. Probably with each CEF update. That is where the Linux client has a slight edge, although unfortunately UI performance is noticeably worse.


----------



## drozdowsky (Nov 1, 2019)

how about running new client with 
	
	



```
-no-browser +open steam://open/minigameslist
```
 params?


----------



## Alexander88207 (Nov 1, 2019)

drozdowsky said:


> how about running new client with
> 
> 
> 
> ...



Thanks, thats it!


----------



## shkhln (Nov 15, 2019)

shkhln said:


> At least the Valve's Wine fork can be compiled natively. I haven't looked into other parts of Proton yet. The Linux client obviously requires Linux emulation.



Ok, so apparently Proton loads lsteamclient.dll.so, which in turn loads steamclient.so, which is a closed source binary distributed with the Linux Steam client. This is rather inconvenient.


----------



## cabriofahrer (Nov 15, 2019)

shkhln said:


> Ok, so apparently Proton loads lsteamclient.dll.so, which in turn loads steamclient.so, which is a closed source binary distributed with the Linux Steam client. This is rather inconvenient.



Why is that inconvenient? Isn't nvidia-driver closed source, too? If it is for legal reasons, then wouldn't it be possible to ask for permission? As far as I know there are ports that require clicking some acknowledgement in order to install them. So could this not be done in this case as well?


----------



## malavon (Nov 15, 2019)

shkhln said:


> Ok, so apparently Proton loads lsteamclient.dll.so, which in turn loads steamclient.so, which is a closed source binary distributed with the Linux Steam client. This is rather inconvenient.


I haven't been able to look at Proton in detail (still on todo list), but isn't that library this code in the valve git repo?


----------



## shkhln (Nov 15, 2019)

cabriofahrer said:


> Why is that inconvenient?



It's a Linux library, which means we must either run Proton entirely under Linuxulator or deal with the same technique (glibc shim) I'm using for Vulkan libraries to be able to load it with natively compiled Wine.



malavon said:


> I haven't been able to look at Proton in detail (still on todo list), but isn't that library this code in the valve git repo?



That's only lsteamclient.dll.so.


----------



## christhegeek (Nov 17, 2019)

I was born at 1976 at that time we played games like leisure suit larry 1 and other fantastic adventures like monkey island etc
Simple platform games like nicky boom ! Or more advanced games like alone in the dark , i don't know if we had more fantasy 
but i prefered those games rather than these modern games like the latest wolfestain , no fantasy at all metro was better but 
all more or less the new games are like they copied each other and their stories are not interesting like for example bioshock !
I mean i had more fun with pixelated games like stardew valley and isaac or lakevew cabin, zomboid or zombie night terror than
the new AA Game titles i have played. 
For me if freebsd can run these pixelated game titles its more than i need to have ! (or other light multiplayer games like mount and blade , counter strike the old one , battlefield vietnam -old version of battlefield) these games were cool !


----------



## Alexander88207 (Nov 17, 2019)

christhegeek said:


> I was born at 1976 at that time we played games like leisure suit larry 1 and other fantastic adventures like monkey island etc
> Simple platform games like nicky boom ! Or more advanced games like alone in the dark , i don't know if we had more fantasy
> but i prefered those games rather than these modern games like the latest wolfestain , no fantasy at all metro was better but
> all more or less the new games are like they copied each other and their stories are not interesting like for example bioshock !
> ...



Diablo II <3


----------



## shkhln (Dec 3, 2019)

shkhln said:


> It's a Linux library, which means we must either run Proton entirely under Linuxulator or deal with the same technique (glibc shim) I'm using for Vulkan libraries to be able to load it with natively compiled Wine.



I managed to start 4 (out of 7 tested) games with the latter method, so it actually works to an extent.


----------



## shkhln (Dec 14, 2019)

Win32 on macOS | Hacker News
					






					news.ycombinator.com
				



That's very impressive. I didn't realize CodeWeavers were crazy enough to pull this off.


----------



## eax.qbyte (Dec 14, 2019)

Recommending some games I didn't see them in thread.
games/openttd Pretty famous and popular clone of the old Transport Tycoon Deluxe game with active developement team with online servers and many nice players.
games/7kaa This award winning strategy game is rather hard and violent, but it has great features worth spending some time to play.
games/hedgewars A Worms like game with funy hogs fighting with their weapons, dev team is active and it's very easy to join online servers and fine some cool dudes to play.
games/minetest I really really recommend this one since it is similar to minecraft and is totally free. there are also online servers and active players.
games/corsix-th A clone of old DOS Theme Hospital, but you need to have a copy of original game. I really enjoyed playing this game.
games/pingus Another popular game, similar to lemmings in NES. It's very old but worth spending some time.
games/colobot Again strongly recommended, It's a 3D astronaut game about how to program bots with Java, It's both learning programing and playing game with 3D features which helps you understand more how to program robots. It has recently added to ports system.


----------



## christhegeek (Dec 15, 2019)

with Homura you can play 32bit windows games on freebsd but i don't know if vulkan is supported or you have to use 32bit freebsd to take advantage of that.


----------



## shkhln (Dec 15, 2019)

Vulkan is disabled by default in the port options.


----------



## cabriofahrer (Dec 15, 2019)

christhegeek said:


> with Homura you can play 32bit windows games on freebsd but i don't know if vulkan is supported or you have to use 32bit freebsd to take advantage of that.



Homura is just a launcher that works on top of i368-wine-devel, right? So what are the differences/advantages of using homura compared to just using i386-wine-devel? And what I would also like to ask in that context: Why is i386-wine-devel stuck to version 4.0.r1_1,1 for such a long time now? Is it not being developed anymore?


----------



## Alexander88207 (Dec 15, 2019)

cabriofahrer said:


> Homura is just a launcher that works on top of i368-wine-devel, right? So what are the differences/advantages of using homura compared to just using i386-wine-devel?



There is no difference or adveantage in general, with Homura i only ship the required fixes and workarounds to get stuff easily working.



cabriofahrer said:


> Why is i386-wine-devel stuck to version 4.0.r1_1,1 for such a long time now? Is it not being developed anymore?



The maintainer of i386-wine[devel] seems to do nothing more in general since April.


----------



## shkhln (Dec 15, 2019)

We don't really have a maintainer for _i368-wine_ at the moment. And even if somebody replaces dbn@, I wouldn't expect any updates for that stupid package.


----------



## malavon (Dec 15, 2019)

shkhln said:


> We don't really have a maintainer for _i368-wine_ at the moment. And even if somebody replaces dbn@, I wouldn't expect any updates for that stupid package.


I was rather oblivious to this myself apparently, I thought it was still maintained. I've been toying around with it for a while, building more recent versions (it's not difficult, just update the version number).
I guess if this state persists I'll have to take it up myself somewhere in the future when I'm a bit less busy. I'd rather see a different solution (as in your GitHub repo), but I haven't looked into any requests for that.
Which reminds me: if you'd like people to step up somehow to talk about this on the mailing list, feel free to ask. I'm sure there are a few people who'd love to see 32-bit libraries on amd64 just to be able to use wine.


----------



## shkhln (Dec 15, 2019)

malavon said:


> I was rather oblivious to this myself apparently, I thought it was still maintained.



_i386-wine(-devel)_ is written in a way that is difficult to break, so it doesn't require much maintenance _except_ for the very obnoxious package publishing procedure. That part borders on self-abuse.



malavon said:


> I've been toying around with it for a while, building more recent versions (it's not difficult, just update the version number).



Well, numbers are in _wine(-devel_), which is maintained by gerald@. No trouble there, although I've got the impression that gerald@ would rather maintain something else.


----------



## shkhln (Dec 15, 2019)

By the way, if you would like to compile WoW64 Wine, but the lib32 patch looks too intimidating, try PR 242625.


----------



## cabriofahrer (Dec 15, 2019)

shkhln said:


> We don't really have a maintainer for _i368-wine_ at the moment. And even if somebody replaces dbn@, I wouldn't expect any updates for that stupid package.



That is bad news... But why stupid package? It's the only package I know that enables me to play old windows games at the moment. And sometimes you really need the latest one to be even able to play games that are more than 10 years old and then you do not even have directx10. Very sad.



shkhln said:


> By the way, if you would like to compile WoW64 Wine, but the lib32 patch looks too intimidating, try PR 242625.



I guess that here lies the solution, that we someday finally get WoW64 Wine, so that we will be able to play both 64 and 32-bit titles. But until then, I am happy if I can play some older titles with i386-wine, like right now, I am playing STALKER - Call of Pripyat. And for that I had to install d3dx9 with winetricks...


----------



## Alexander88207 (Dec 15, 2019)

cabriofahrer said:


> And sometimes you really need the latest one to be even able to play games that are more than 10 years old and then you do not even have directx10. Very sad.



DirectX10 works i was playing HELLDIVERS™ Dive Harder Edition and it worked perfectly.


----------



## shkhln (Dec 15, 2019)

cabriofahrer said:


> But why stupid package? It's the only package I know that enables me to play old windows games at the moment.



I don't know what to tell you. Why must you always interpret everything literally when every common word has at least a dozen of different meanings in English? "stupid" in the sense that it has been a source of constant annoyance to me for at least 3 years. More than one dictionary confirms I'm not straying far from the normal usage of the word.


----------



## cabriofahrer (Dec 16, 2019)

Alexander88207 said:


> DirectX10 works i was playing HELLDIVERS™ Dive Harder Edition and it worked perfectly.



I am saying this because in the video settings menu of TF2 I could only see "directx9" greyed out, without the possibility of selecting anything else.
BTW, have you ever managed to play "Bioshock2" or "Call of Juarez"? Do you have any recommendations which winetricks to use to achieve maximum possible compatibility for any games?

And how do I know which directx version is supported anyway? Dxdiag.exe does not work:


```
$ wine dxdiag.exe
0009:fixme:wbemprox:wbem_services_CreateInstanceEnum unsupported flags 0x00000030
0009:fixme:ntdll:create_logical_proc_info stub
0009:fixme:wbemprox:enum_class_object_Next timeout not supported
0009:fixme:win:EnumDisplayDevicesW ((null),0,0x33e7d0,0x00000000), stub!
0009:fixme:win:EnumDisplayDevicesW ((null),0,0x33e590,0x00000000), stub!
0009:fixme:ddraw:ddraw7_Initialize Ignoring guid {aeb2cdd4-6e41-43ea-941c-8361cc760781}.
0009:err:avicap:query_video_device Video 4 Linux support not enabled
0009:err:winediag:MIDIMAP_drvOpen No software synthesizer midi port found, Midi sound output probably won't work.
0009:fixme:dxdiag:wWinMain Information dialog is not implemented
$
```


----------



## Alexander88207 (Dec 16, 2019)

cabriofahrer said:


> And how do I know which directx version is supported anyway? Dxdiag.exe does not work:



DXDiag works but the informations are useless, i have set the operation system to win10 and it says win7.

There is also written DirectX 9.0c but 10 or higher is supported. I can confirm that by playing Clone Hero.






You also can see in the folders that wine ships DX 9,10 & 11 out of the box







cabriofahrer said:


> have you ever managed to play "Bioshock2" or "Call of Juarez"?



I dont own the 2 games.

But:

Bioshock 2: (Not the remastered one) uses GFWL, you may want to try XLiveless. I have used that for Grand Theft Auto IV but dont know if it works for other games too.

Call of Juarez: Many people have told that DirectX10 is not working for this game, you should try to use DirectX 9. I guess it should be enough to start CoJ.exe instead of CoJ_DX10.exe.


----------



## vchan (Dec 17, 2019)

I am currently working to get WoW64 working with wine. I haven't made much progress yet, but I will try to keep everyone updated when I have something to share.

Also, I had the old maintainer of the i386-wine port send me his build information, and if anyone would like to get a copy just PM your email address.


----------



## shkhln (Dec 17, 2019)

Can you please elaborate on that? There can't be a clean solution not involving portmgr@ in some way. If you are simply talking about getting WoW64 to work, that never was the issue. The hard part is reaching consensus on how to build it in an amd64 poudriere jail in a fully automated way.

Plus I personally consider the inability to compile Wine straight from the git checkout to be an important UX issue. Have ever you tried bisecting commits with i386-wine-devel and chroot build? It's unbelievable the upstream project still tolerates us.


----------



## vchan (Dec 18, 2019)

shkhln said:


> Can you please elaborate on that? There can't be a clean solution not involving portmgr@ in some way. If you are simply talking about getting WoW64 to work, that never was the issue. The hard part is reaching consensus on how to build it in an amd64 poudriere jail in a fully automated way.
> 
> Plus I personally consider the inability to compile Wine straight from the git checkout to be an important UX issue. Have ever you tried bisecting commits with i386-wine-devel and chroot build? It's unbelievable the upstream project still tolerates us.



Elaborate on what exactly? I want Wine to work on BSD just like it does on Linux. If I have to build it from source then I can do that, but there is no good documentation on making that work. I'm working to make it easier for everyone to have a properly working Wine installation.


----------



## shkhln (Dec 18, 2019)

You've seen https://reviews.freebsd.org/D16830, right? Now, _what_ are working on?


----------



## vchan (Dec 18, 2019)

shkhln said:


> You've seen https://reviews.freebsd.org/D16830, right? Now, _what_ are working on?


I have not seen that. However, that hasn't solved the issue yet.


----------



## shkhln (Dec 18, 2019)

Because it's not a technical issue, it's a buy-in issue.


----------



## shkhln (Dec 18, 2019)

You are also only 5 messages apart from the post where I linked a minimal WoW64 patch for the i386-wine-devel port, implying I need some feedback. (Yes, this solution sucks, but that is about as far as the existing port can be pushed.)


----------



## cabriofahrer (Dec 19, 2019)

In my lack of expertise on this matter I can only say that I am happy to see that you guys are trying to continue with this. I think it is important that you find a common strategy and procedure here and if necessary, get involved or make aware the others responsible for the issues / impedements to continue implementing wine / wow64 on FreeBSD.


----------



## shkhln (Jan 1, 2020)

https://www.theverge.com/good-deals...alve-steam-controller-discontinued-sale-price

Oh, how fucking nice of them. I didn't even manage to complete a basic mapper I was trying to write for the damn thing and it's already discontinued.


----------



## vchan (Jan 3, 2020)

shkhln said:


> https://www.theverge.com/good-deals...alve-steam-controller-discontinued-sale-price
> 
> Oh, how fucking nice of them. I didn't even manage to complete a basic mapper I was trying to write for the damn thing and it's already discontinued.


It's been out for a while, but I assume there is a new controller in the works. I think I have 2 or 3 laying around the house.


----------



## Sevendogsbsd (Jan 3, 2020)

Slightly off topic but has to do with gaming so I am going with it: wife got me a PS4 last year and I have been gaming using a keyboard and mouse since 1988. Using the controller is like handing me a cantelope and saying "game with this". I am learning slowly but die a lot


----------



## shkhln (Jan 3, 2020)

vchan said:


> It's been out for a while, but I assume there is a new controller in the works.



I wouldn't assume anything without a statement from Valve.



Sevendogsbsd said:


> Using the controller is like handing me a cantelope and saying "game with this".



Steam Controller behaves more like a weird gaming mouse rather than a traditional gamepad.


----------



## shkhln (Jan 11, 2020)

shkhln said:


> to compile WoW64 Wine, ..., try PR 242625.



Anyone? The maintainer won't even consider merging the patch unless a third party confirms that it actually works.


----------



## Sevendogsbsd (Jan 11, 2020)

Are you asking someone to build wow64 or for someone who has a Steam controller?


----------



## shkhln (Jan 11, 2020)

Did you miss the cited part? Somebody messed the default forum style a while ago, it might not be immediately noticeable.

I'm definitely not referring to any controller patches.


----------



## Sevendogsbsd (Jan 11, 2020)

The PR, right? I saw it, let me read through it to get a better understanding of what it is asking. Not a developer so not used to reading these.


----------



## malavon (Jan 14, 2020)

shkhln said:


> Anyone? The maintainer won't even consider merging the patch unless a third party confirms that it actually works.


I'm off of UE4 "duty" for now until Epic releases a new one  I'll give it a go, probably tomorrow or maybe this evening if possible.


----------



## shkhln (Jan 14, 2020)

To be clear, I'm not promising the patch will be merged, this is just a prerequisite for reviewing it. (If that sounds a bit ridiculous, well, yes, I'm not happy about such hoops either.)


----------



## aimeec1995 (Feb 22, 2020)

I had no idea some of these source ports existed, they are really cool. 
I refer to things like.. dhewm3, devilutionx, regoth, fnanify 

I see there is one for gta 3 as well (openrw) but I don't see any ports to freebsd. 

Anyone got a list of source ports like this?


----------



## shkhln (Feb 23, 2020)

The term "source port" is reserved for the projects derived from the original source code. Openrw is an independent game engine implementation, it's very far from playable state.



aimeec1995 said:


> Anyone got a list of source ports like this?



https://emulation.gametechwiki.com/index.php/Game_Engine_Recreations_and_Source_Ports, https://en.wikipedia.org/wiki/List_of_game_engine_recreations


----------



## shkhln (Mar 23, 2020)

Apparently, SDL 2 now has drivers for Xbox, Playstation and Nintendo gamepads (available on FreeBSD through the non-default _hidapi_ port option). I wonder why evdev wasn't sufficient for those.


----------



## Jose (Jun 3, 2020)

shkhln said:


> As you can see, currently I'm busy meta-complaining about the lack of complaints for zero attention given to the lack of multilib support in ports. Which is a prerequisite for both WoW64 Wine _and_ Proton. I do not plan to work on anything until that issue is resolved.


Suggest multilib support as something the core team should look at in question 45 of the Freebsd 2020 community survey. I did.


----------



## shkhln (Jun 3, 2020)

Jose said:


> Suggest multilib support as something the core team should look at in question 45 of the Freebsd 2020 community survey. I did.



You might be interested in the whole D16830 thread if you haven't already seen it.


----------



## Jose (Jun 3, 2020)

I read it, thanks. FWIW, the way this was handled in Gentoo was to add an `abi32` option (USE flag in Gentoo parlance) to the port. Not sure if that's a reasonable suggestion. I honestly couldn't follow all of the discussion at the link you posted.


----------



## shkhln (Jun 4, 2020)

Well, there are more than a few solutions to this problem. The gist of the issue is that patches need reviewers (portmgr@ in this case) and committers, and apparently nobody wants to touch this one. I won't be surprised if portmgr@ decided to outwait the whole multilib issue entirely until it's no longer relevant in 10 years or so.


----------



## Jose (Jun 4, 2020)

Gawd, I hope not. Unlikely that we'll get core's attention on this, but it's worth a try. Strikes me this is definitely in their wheelhouse. Twist arms to make needed changes happen.


----------



## Phishfry (Jun 10, 2020)

olli@ said:


> By the way, a nice example for a simple but addictive game that uses Mesa is “Crack Attack” (port games/crack-attack).


Very Addictive Game Indeed.


----------



## cabriofahrer (Jun 30, 2020)

What about Quake2xp? I found this where it says that there is experimental support for FreeBSD:









						quake2xp mod
					

This is another hd graphical mod for Quake2, with advanced glsl render.




					www.moddb.com
				




But I do not find any further information on this, only some instructions for Linux are mentioned here:






						quake2xp -  Browse /linux release at SourceForge.net
					

QuakeIIxp is a multi-platform (windows, linux and freeBSD (experemental)) graphics port of the game Quake II developed by Id Software. Completely…




					sourceforge.net
				




So is this supposed to work with Linuxulator on FreeBSD, too? And do these instructions even apply or do have to do something else? It would be great to get this running, as the graphics seem to be much better than kmquake2.


----------



## shkhln (Sep 10, 2020)

Re: Google Season of Docs/WINE Handbook Chapter - Aaron Peters - org.freebsd.freebsd-doc - MarkMail


----------



## shkhln (Sep 20, 2020)

Made a convenience wrapper script for DIY WoW64 Wine package mashup.


----------



## Captaincrunch333 (Jan 17, 2021)

I have gotten stormworks to work with homura and fallout new vegas they run perfectly under freebsd.


----------



## Crivens (Mar 26, 2021)

I just installed _Codename 47_ and started playing it. To install the second part I had to fall back to twm as window manager as one dialog of the installer did not show correctly.


----------



## SteamBSD (Apr 18, 2021)

Try

```
pkg ins alienarena
```

--- SteamBSD © is FREE operating system.
YouTube: https://www.youtube.com/channel/UC8wwRY8yGWiJ-bIQlK0wvUA/videos
Site (download ISO/IMG): https://lpros.blogspot.com
Github (internet installer): https://github.com/steambsd/os
Email: steambsd@gmail.com


----------



## debguy (May 7, 2021)

paulfrottawa said:


> At a forum I participate I was told this.
> 
> 
> 
> ...


Both are true.  It is a chess game played out that last longer than many people live.  You are so lucky to be both Grey and still wise and asking.

Why does Win10 insist on using '\' not '/' still?  Aren't all these intel binaries should there really be an issue 30 years later?  Will china really take over USA tech if everything goes "compile it yourself" china gets the code and forced ARM into all USA websites and (stores if any are left open after covid).  Or is it china's drivers the source is really missing not Microsoft's?  Or are china's ARM pc's already winning and we just don't know it yet.  And what will they do if china says "hey btw bsd and win10 are out, we don't support that" ?

Try FreeBSD 13

--- SteamBSD © is FREE operating system.
YouTube: https://www.youtube.com/channel/UC8wwRY8yGWiJ-bIQlK0wvUA/videos
Site (download ISO/IMG): https://lpros.blogspot.com
Github (internet installer): https://github.com/steambsd/os
Email: steambsd@gmail.com


----------



## fernandel (May 15, 2021)

I like AGS games and I am playing now


----------



## Crivens (May 16, 2021)

fernandel said:


> I like AGS games and I am playing now


Looks good, I will give that one a try.


----------



## tankist02 (May 16, 2021)

Latest Fedora 34 broke Doom, but it works on FreeBSD just fine.


----------



## Minbari (May 16, 2021)




----------



## fernandel (Jul 8, 2021)

Crivens said:


> Looks good, I will give that one a try.


Any recomendations for the old adventure game, please?


----------



## Crivens (Jul 9, 2021)

Baldurs Gate used to work in wine.


----------



## Deleted member 30996 (Jul 9, 2021)

MindGuard fascinated me to no end. 







> MindGuard protects your mind by jamming and/or scrambling psychotronic mind-control signals and removing harmful engrammic pollutants from your brain. It also has the ability to scan for and decipher into English specific signals so you can see exactly Who wants to control you and what They are trying to make you think.
> 
> With MindGuard, you can rest assured that your most valuable possession - your mind - is safe from the nefarious tinkering of evil-doers.



Unfortunately, games/mindguard was taken from me when I needed it most and I fell victim to the Antarctic Relay...


----------



## tankist02 (Jul 9, 2021)

Doom works great, nothing else is needed!


----------



## fernandel (Jul 9, 2021)

Crivens said:


> Baldurs Gate used to work in wine.


Than you. I play just AGS games .


----------



## kpedersen (Jul 9, 2021)

Speaking of Baldur's Gate. GemRB worked really well last time I tried: https://gemrb.org/

BG2 was very completable and apparently now most of the games on Bioware's infinity engine (Icewind Dale, Planescape: Torment) are in good shape.

For multiplayer you do have to stick with Wine though.


----------



## Deleted member 30996 (Jul 10, 2021)

games/ufoai is like X-Com UFO Defense which I had on PSII. I couldn't reset it every time I got killed and cheat on the Aliens to slaughter them mercessly like I could PSII and what fun is that?

games/endgame-singularity is the kind of strategy game I like but never got into it.

games/gnugo much harder than Reversi/Othello which I'm a Wiz at.

games/moria is one I liked and have a saved game to start with but it's from years ago and never play anymore.


----------

