A separate ports tree for games? (GPorts)

[Beastie7]

From what I'm reading lately; the current gaming landscape is not looking too good. Windows 11 is a s**t show, next gen consoles aren't looking too promising, Steam is on a steady downhill (i've never really been a fan of steam anyway..), and as much as I love Apple Silicon - it doesn't provide the flexibility necessary for gaming in general. I'd like to make FreeBSD a bastion for future game players/developers; and provide a place for distribution without restrictions. The hardware support is there. A separate ports tree would make navigability/indexing easier; it's just an idea for now. One implementation detail includes using the existing ports tree hierarchy for game genres, engines, editors and emulators, etc. However, if the demand is low; I'd feel reluctant to take on this endeavor.

What do you think?

 

[Zare]

I appreciate this effort but currently, IMO, we don't have enough games, engines, or editors to warrant such a move.

The only popular contemporary engine we have access to is Godot.

 

[cracauer@]

A separate tree would play very badly with dependencies that are already in the normal ports tree.

 

[Maturin]

Maybe I missed something here.
There is /usr/ports/games/ for I don't know how long, but I bet since the dawn of FreeBSD.
Those are the games run natively on FreeBSD.

One may discuss if those are great. Some to me seem unfinished and not continued for a long time. Some others are just useless experimental garbage. Many in my eyes are worth to be removed from the ports tree, since they simply don't work. At the same time others are really worth a try, like brogue (B-rogue) to give just a single example.
Sure, only very few come optically like from commercial projects.
Don't you underestimate the effort graphics need.
But for sure there is not only garbage in this port.

Maybe the original idea of this thread was another one completely:
In my eyes games are a very important point of to make an operating system more popular, so I am convinced FreeBSD can only profit of providing more, better games. But I am also convinced of doing a professional, solid, reliable OS has more priority than make it a gaming platform.
I would never demand to bring more/better games to FreeBSD. There are way more important things to do.

I am a gamer. I knew what I give up when I switched 100% to FreeBSD. And I did it consciously.
Since then I learned to live with way less game expericence, but it makes me way more productive on other things.
I learned what I really love about computergames I can get on an even higher level with setting up my FreeBSD, and programming.
This may sound like old greybeard senior teacher tells you to eat your spinach, but it's true.

There is dosbox, wine, and all its extensions up to running steam, and VMs, and hypervisors to run games from other operating system somehow under FreeBSD. Several people work on it improving that.
You may ask how to contribute.
Also, if I'm not satisfied with the game experience under FreeBSD, I have the choice to dual-boot, or get a second machine.
Or, the third way:
Write a game that runs natively on FreeBSD yourself.

Which brings me to last point I think I read somehow between the lines of your post:
Most new computer games suck.
I agree.
And it's getting worse.
I observe that for many years. I could write a very long text about my ideas why's that so.
But, all I can say briefly is:
If FreeBSD provides more Windows/Steam games - which is almost completely in the hands of the ones writing the games, and which OS they support, than vice versa - this will not change anything.
Only writing better computer games can change that.

Or do what I do:
Play the old classics!
Before you ask you find a list of mine in
post #44, "which O.S. do you use ?"
But there are many more.

 

[mer]

I'm not sure how to feel about this proposal. probably because to me "games" means xmahjongg or xsol for graphic games, Adventure (you are in a maze of twisty passages all alike) or Wumpus.
Beyond that? Why not dedicated gaming system

 

[Jose]

Freebsd is severely understaffed already. Fragmenting the ports tree would only make it worse.

 

[cracauer@]

Freebsd is severely understaffed already. Fragmenting the ports tree would only make it worse.

Well, I guess the idea would be that there are no dependencies of main ports tree to things in the games ports tree. That way the games tree could be as broken as it wants without affecting the main ports.

 

[kpedersen]

I don't think the FreeBSD developers would be able to keep up with the demands from the "gamer community" whilst also maintaining a decent operating system.

I personally don't think we should encourage them to come here even after they have finished screwing up Linux.

 

[astyle]

I feel that FreeBSD has plenty of issues to address without taking on the extra effort of re-organizing the entire infrastructure for games. There's wifi, Wayland, and ability to upgrade easily. I once tried to figure out what it would take to automate upgrading of just KDE, while leaving the rest of the system alone. I did not worry about Wayland at the time. And - that was a plenty complex undertaking, one that I ultimately ended up shelving indefinitely.

I mean, seriously, FreeBSD's pkg infrastructure is a mess. A quarterly repo has close to 40,000 packages, including some big ones like www/chromium... Not only that, there's repos for amd64, i386, aarch64, and a few others. Not only that, each arch has 2 or 3 FreeBSD versions that are actively supported - ooh, that merits repos for each one of them. And each of them has build errors. The FreeBSD project basically keeps trying to compile all those 40,000 packages, times like 20 or so, every quarter. Just the math of maintaining quarterly repos for all the architectures, releases, and quarters - is not adding up.

I recently heard that for 14.2-RELEASE, repos were being built right up until the day 14.2-RELEASE went EoL. Yep, with all the build errors, mirror URLs not being valid, and all the supported architectures wanting a complete, finished repo with all the packages and mirrors. Not a trivial task, especially for an all-volunteer team that is backed by a small NPO. And I'm writing this on a laptop running running just fine with 14.2-RELEASE (because I'm waiting for 15.0-RELEASE to drop).

Well, if OP has a proof-of-concept implemented, it would be interesting to see how it might work (hopefully without reinventing the wheel).

 

[Beastie7]

Well, I guess the idea would be that there are no dependencies of main ports tree to things in the games ports tree. That way the games tree could be as broken as it wants without affecting the main ports.

I wasn't clear enough in my OP. I was thinking something along the lines of ravenports; something that's not entirely anchored to the system and can be distributed separately. A community led effort.

I personally don't think we should encourage them to come here even after they have finished screwing up Linux.

The Linux developer community ruined Linux; not gamers.

 

[ralphbsz]

Or, the third way:
Write a game that runs natively on FreeBSD yourself.

That's actually remarkably easy. Any text-only game that is written in a common language, such as Fortran (empire, the 550 point adventure) or Java (ladder) can be easily ported to FreeBSD. Usually, it just takes a compile.

On the other hand, I'd rather play empire on a VAX, or ladder on a cp/m machine. I have all the required hardware at home, I just need a lot of time to get the machines set up again.

 

[Espionage724]

The Linux developer community ruined Linux; not gamers.

I feel it could go deeper than that with more of a willingness to accept mediocrity (I've seen "gamers" praising Wayland within the 8+ year period I've been wondering how any gamer dealt with >125Hz mice on Wayland); and there's unrelated PCVR where higher-latency wireless and muddy-encoded video streams is more-popular when VR's all-about low-latency and clarity (Rift CV1/S -> Quest and standalone boom; and seeing one of my favorite games get downgraded on PCVR to accommodate standalone lower-specs and easier cross-dev).

I personally don't think we should encourage them to come here even after they have finished screwing up Linux.

I came over willingly As long as an OS has Wine, I can pull-off whatever I want to play! (kind-of curious about SteamVR though when I get PCVR hardware)

---

The games I usually play I do self-hosted servers for too; it's particularly interesting being able to set servers up on FreeBSD, and the experience with that carries over to more important stuff (I learned MySQL and Node.js tricks from game servers that I later-used with websites using the same tech). Gaming can be more than just playing games

I'd rather not see games second-class'd because of a stereotype of games not being productive.

---

I'm not sure about a separate ports tree, but don't particularly want to separate games unless everything also has some kind of categorization (like mousepad and ee being text editors and LO being an office suite but not directly a text editor). Technically most of my games are under Wine, but Wine's not just for games.

There's also FlightGear that I kind-of wonder if it could be categorized as a game; it's a simulator

 

[T-Aoki]

Intermediate idea (not sure it's technically possible or not).
Making commit bits for games/ physical category only, which cannot commit outside games/ subdirectory of ports tree.

And stop building games category for official pkg repo.
As ports framework itself is BSD licensed, anyone can make in-the-wild pkg builder dedicated for games category (of course, restrictions by upstream matters!).

 

[Maturin]

something that's not entirely anchored to the system and can be distributed separately.

That was a fork of FreeBSD to start an own, independent OS.
Otherwise that would mess up FreeBSD.

Maybe there are some things need to be seen.
One core job of an OS is to provide ways to install and run software. It's not its job to provide the software itself (besides such that is a necessary part of the OS itself.)
To produce software is the job of other software developers. And they decide which OS their software runs on. The commercial ones simply decide by where the most customers are, or if the effort it takes to port their software to another OS brings enough profit in return.
Almost all non commercial but free games are already available in /ports/games/.
If you want more commercial software seen on FreeBSD, you need to rise the amount of users to some millions.

Plus there is a technical issue.
Windows is a gaming platform. As a single user OS it can step aside, place itself almost completely stand-by into the background, and just provide what a game needs to run almost like it ran bare-metal. So the game has almost the full hardware power a machine provides (CPU, RAM, GPU) to its disposal.

Besides they were never designed to primarly provide games, by their very original nature unix[like] operating systems are multiuser systems. Which does not mean what it is under Windows: There can be several user accounts.
It means several (many) users can actually work on the same machine at the same time. Even if only one real human user has access to it via keyboard and a monitor attached to it directly, if there is only one keyboard attached to it. So even if they are used as single user workstations they act as servers. They permanently do a lot of jobs in the background, like grooming the filesystems on the storages.
If you want to give a game full hardware access, so it runs smoothly, you need to make the rest of the OS to step aside, fall into hibernation, to do nothing. Besides that's only possible on a machine whith a single user only - imagine all jobs running halt, and all working of a dozen people suddenly freezes just because one hero now runs through dungeons hunting orcs - you need to have root's access to set the OS in such a state - and the system capable to do so.

So it's not just done by porting the games you see under Windows to FreeBSD as long as FreeBSD machine's hardware ain't by magnitudes that more powerful, so the OS could handle the game easily as some sideshow - which also simply ain't no guarantee it runs smoothly lag free.

Bottom line:
One either have to be satisfied with the situation as it is (and it cannot be compared by far to the situation fifteen years ago), live with a lesser choice of games, look for other things you enjoy instead of computer games, or simply chose other platforms (dual boot/additional machine(s)).
Or write games directly for FreeBSD - but don't expect them to become the same graphics quality you see on Windows.

 

[Espionage724]

If you want to give a game full hardware access, so it runs smoothly, you need to make the rest of the OS to step aside, fall into hibernation, to do nothing. Besides that's only possible on a machine whith a single user only - imagine all jobs running halt, and all working of a dozen people suddenly freezes just because one hero now runs through dungeons hunting orcs - you need to have root's access set the OS in such a state.

Why would a game be treated differently vs anything using high-GPU load like compute?

Resources should be allocated and balanced: Users not using GPU I don't think should notice if 1 user is using GPU for something. The OS should be out of the way and prioritize foreground apps requiring performance and fast-interaction times.

If anything, that becomes more-noticeable with GTK and etc defaulting to Vulkan or GL to render 2D windows with unnecessary GPU use vs all-CPU; but I question that efficiency at the OS-level more (I use GSK_RENDERER=cairo globally since mainstream Linux distros started defaulting vulkan)

 

[Maturin]

It's not the question about to give a task a high priority. For a game to run smoothly lag free it needs the high priority constantly.
If a job lags for several tenths of a second, or even full seconds, while it's in the background the user will not even recognize it. But if the user is directly life, real-time interacting with an UI any reaction taking longer than app. ~8 ms (milliseconds) is recognized as a lag.

 

[astyle]

Besides, what OP is proposing - that was already done. It's called Sony PlayStation. It's based on FreeBSD, and Sony maintains games for PlayStation 3, 4, and 5.

Seriously, it takes someone of Sony's stature to successfully pull off what OP is proposing.

I see this as just another case of attempting to reinvent the wheel without having much to bring to the table in the first place.

 

[Dereckson]

Let's think about your goals.

If it's to coordinate ports about gaming available for FreeBSD, what you need is a games@freebsd.org mailing list, like we've for Perl, Python, etc. and a group of ports tree committers willing to take care of games ports and coordinates changes like bumps of OpenGL libraries.

With that setup, there is no real advantage to do that in a separate tree than in games/ category: you'll have a dedicated group of interested people for games ports, and a place to publish games ports.

 

[T-Aoki]

Let's think about your goals.

If it's to coordinate ports about gaming available for FreeBSD, what you need is a games@freebsd.org mailing list, like we've for Perl, Python, etc. and a group of ports tree committers willing to take care of games ports and coordinates changes like bumps of OpenGL libraries.

With that setup, there is no real advantage to do that in a separate tree than in games/ category: you'll have a dedicated group of interested people for games ports, and a place to publish games ports.

In such a case, overlays would be useful rather than full ports tree.

Example of overlay use-case by Ken DEGUCHI.
And my personal document describing a bit about overlay vs poudriere.

 

[Maturin]

what you need is a games@freebsd.org mailing list

I don't get that neither.
There also already is this mailing list:
freebsd-games@FreeBSD.org

 

[Beastie7]

If it's to coordinate ports about gaming available for FreeBSD, what you need is a games@freebsd.org mailing list, like we've for Perl, Python, etc. and a group of ports tree committers willing to take care of games ports and coordinates changes like bumps of OpenGL libraries.

The idea here is to provide an autonomous distribution utility that's not entirely anchored to the system and/or the main ports tree. This frees up the ports committers from doing the heavy lifting; as I imaging this sort of thing would evolve and change rapidly. A community led effort with a separate medium of communication and advertising.

I do see your point - maybe a fancy site indexing that part of the tree would suffice. But I doubt the wider game dev/user community are going to want to scour FreeBSD mailing lists/forums for coordination.

In such a case, overlays would be useful rather than full ports tree.

Example of overlay use-case by Ken DEGUCHI.
And my personal document describing a bit about overlay vs poudriere.

I hadn't gone into implementation details yet but i'd like the tools to be a little more intuitive than poudriere. Tooling should be bundled in with the service. (ie. ravenports).

I don't get that neither.
There also already is this mailing list:
freebsd-games@FreeBSD.org

You've been living under a rock. Nobody uses mailing lists for anything gaming related.

 

[Jose]

Or, the third way:
Write a game that runs natively on FreeBSD yourself.

No need to work that hard. Find an old game that has been open-sourced, and get it to work on FBSD:

K

Thread 'Half-Life - In 4 easy steps'

May 12, 2021

Hi all,

If you are a fan of Half-Life, you can now easily play this on FreeBSD. I have forked a number of projects in an attempt to make things easier to get up and running without relying on a port (which due to licensing is unlikely to be an option for binary distribution).

The following commands should fetch, build and run Half-Life. You may need to tweak the PYTHON environment variable to match the version installed.

# pkg install xorg git sdl2 mono cmake pkgconf
$ git clone https://github.com/osen/openhl.git
$ PYTHON=python3.7 sh build.sh
$ export/bin/hl

It will take about...

• kpedersen
• first-person battle games games/gaming
• Replies: 83
• Forum: Multimedia/Gaming

• 
• 

Thread 'Any interest in Tribal Trouble 1?'

May 8, 2020

GitHub - sunenielsen/tribaltrouble

Contribute to sunenielsen/tribaltrouble development by creating an account on GitHub.

github.com

I got it to work under Freebsd 12.1, but I need motivation to work on it further.

• Jose
• Replies: 9
• Forum: Multimedia/Gaming

I need to find the motivation to look into this:

Thread 'UZDoom (successor to GZDoom) is looking for maintainers for the BSDs'

Tuesday at 4:05 PM

The UZDoom (forked from GZDoom, now the successor to it) team is looking to improve UNIX support for UZDoom, but they don't have any maintainers for the BSDs. I don't have enough experience with the way UZDoom works internally (kind of a messy project as it was forked from a complete mess) and I am way too busy, scatterbrained, and generally incompetent at everything I do to maintain a port and keep it up to date. They said they are open for a port, if they can find a maintainer. GZDoom is basically dead, as the entire development team left, and all features that were planned for the...

• RetroComputingCollector
• doom first-person battle games games/gaming gzdoom port uzdoom
• Replies: 2
• Forum: Porting New Software

• 

 

[T-Aoki]

I hadn't gone into implementation details yet but i'd like the tools to be a little more intuitive than poudriere. Tooling should be bundled in with the service. (ie. ravenports).

Overlay is an existing functionality of ports framework. Just still not yet well-documented (officially).
See this thread including links there, too, for help.

 

[kpedersen]

If it's to coordinate ports about gaming available for FreeBSD, what you need is a games@freebsd.org mailing list

I'm not trying to be derogative (I play the occasional game myself) but the majority of the gaming community are not likely to subscribe to a mailing list. That isn't to say they can't learn but I am fairly certain it will be a blocker for a large proportion of them.

Maybe just links to the subsection in this forum and a very simple single page webpage with links and images for a little bit of hype/examples could be better received.

Perhaps joining up with playonbsd.com.

 

[astyle]

Sony already did the heavy lifting, but I'm in no rush to buy a PS6. I don't have the money for a new toy like that, and I don't have political motivations to do that just because PlayStation is based on FreeBSD. Send me a PS6 for Christmas, buy me some sushi to snack on in between gaming sessions, teach me how to cheat their billing system, and then I'll think about joining the efforts to entertain the masses that can't pay upwards of $1,000 USD to be entertained for hours and days while waiting for the next handout from the rich and generous.