Quoth Anthony J. Bentley <bentley@openbsd.org>:
> izzy Meyer writes:
> > On Sat, 10 Jan 2026 21:56:18 -0600
> > izzy Meyer <izder456@disroot.org> wrote:
> >
> > > On Sat, 10 Jan 2026 15:39:33 -0800
> > > Thomas Frohwein <tfrohwein@fastmail.com> wrote:
> > >
> > > > On Fri, 09 Jan 2026 20:28:40 +0100
> > > > Kirill A. Korinsky <kirill@korins.ky> wrote:
> > > >
> > > > > On Thu, 08 Jan 2026 23:18:57 +0100,
> > > > > Thomas Frohwein <tfrohwein@fastmail.com> wrote:
> > > > > >
> > > > > > PS: there is a precedent: games/devilutionx also has Sustainable
> > > > > > Use License 1.0 and is PERMIT_PACKAGE=Yes
> > > > >
> > > > > I see, when it seems that I had too pesimistic view for the world.
> > > > >
> > > >
> > > > I reviewed the port fallout1-ce. It works here, but only with the
> > > > included CFLAGS=-O1 -pipe, which bugs me that it's not clear why -O2
> > > > crashes. I'm attaching the backtrace from the corefile, in case
> > > > anyone can make sense why only O2+ crashes here.
> > > >
> > > > In general, it's probably easier to figure out the open questions
> > > > for one of the ports first, rather than discussing both together.
> > > > Once we got it sorted out, knowing how to deal with the other port
> > > > will probably be more straightforward, given the similarities.
> > > >
> > > > Regarding the other issues that have been raised:
> > > >
> > > > 1) I'm in favor of CATEGORIES=games x11, as it puts the most
> > > > relevant category first.
> > > >
> > > > 2) I don't have an opinion on fpattern as a port. For sake of moving
> > > > things along, I'd suggest that we consider importing fallout1-ce
> > > > with the bundled fpattern first. We can later see after a possible
> > > > fpattern port about using that rather than the bundled one.
> > > >
> > > > 3) README is clear enough for me as is.
> > > >
> > > > 4) We should be able to do just PERMIT_PKG=Yes like
> > > > games/devilutionx which has the same license.
> > > >
> > > > From my side ok thfr@ to import fallout1-ce, with the change to
> > > > CATEGORIES in 1).
> > >
> > > Attached is a cleaned up fallout1-ce port with the above suggestions,
> > > as well as me added as a maintainer as I forgot to add myself
> > > there earlier.
> > >
> > >
> >
> > Ping!
>
> I have a rule of thumb: if a port has ever crashed for anyone for any
> reason, even if that reason has been fixed or worked around, I set
> DEBUG_PACKAGES. thfr@ reported a crash with -O2, so this one qualifies.
>
> (I would probably set DEBUG_PACKAGES for any graphics-heavy port anyway.
> A crash in such a port is likely to be GPU-dependent, so we want full
> backtraces to be easy to get since it might be hard for another person
> to reproduce.)
>
> However, DEBUG_PACKAGES doesn't work out of the box on this port since
> you override CFLAGS thus overriding -g, you need to change the lines to:
>
> # -O2+ causes instability and segfaults
> CFLAGS = -O1 -pipe ${DEBUG}
> CXXFLAGS = -O1 -pipe ${DEBUG}
>
> Testing was sorta successful. Fallout 1 is in my GOG library twice for
> some reason. One title provides setup_fallout_1.2_(27130).exe and
> setup_fallout_1.2_(27130)-1.bin as downloads, and the other provides
> setup_fallout_2.1.0.18.exe. I ran innoextract against both. This port
> seems to work with 2.1.0.18 but not with 1.2_(27130). With 1.2_(27130)
> I got a fullscreen "Please stand by", but then got kicked back to the
> desktop, with the process still running (not crashed). Weird. I think
> it's worth mentioning in the README that not all versions work even
> when downloaded straight from GOG.
>
IDK where your "setup_fallout_2.1.0.18.exe" comes from tbh. Here're
the files I got from my GOG for reference:
Fallout (https://www.gog.com/en/game/fallout):
setup_fallout_1.2_(27130).exe
setup_fallout_1.2_(27130)-1.bin
fallout_manual.zip
Fallout 2 (https://www.gog.com/en/game/fallout_2):
setup_fallout_2_1.02_gog_v1_(77792).exe
setup_fallout_2_1.02_gog_v1_(77792)-1.bin
fallout_2_manual.zip
fallout_2_refcard.zip
I got the same problem and was gonna report it but forgot. It also
depends on whether you run it under FVWM/TWM or CWM (tested with
setup_fallout_1.2_(27130).exe and setup_fallout_1.2_(27130)-1.bin):
$ sysctl kern.version kern.version=OpenBSD 7.8-current (GENERIC.MP)
#234: Wed Feb 4 13:18:55 MST 2026
deraadt@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
$ xrandr | head -3 Screen 0: minimum 320 x 200, current 1920 x 1080,
maximum 16384 x 16384 eDP-1 connected primary 1920x1080+0+0 (normal
left inverted right x axis y axis) 309mm x 174mm
1920x1080 60.02*+ 48.00
FVWM:
A. Reproduction:
1. $ cd /home/games/fallout
2. $ fallout-ce
3. screen crops to a small rectangle at the top-right, everything
zoomed in and blurry, and you can you can interact and type into that
part of the desktop. the screen stays this way for around 10 seconds.
4. The screen then goes black and returns to how it was with the
"fallout-ce" command still running (no output in terminal), and a
"FALLOUT" icon (with question marks) appearing on the bottom-left
corner.
5. clicking on the new icon brings up the zoomed-in cropped top-right
of the screen again, this time it doesn't disappear by itself. If you
move the mouse to the bottom-right corner of the zoomed-in cropped
section, the game intro's soundtrack plays as normal but you're still
on the desktop, no graphics. If you make any movement of the mouse
from the bottom-right corner, you go back to step 4. You can even
resume the intro sound from where you left off to repeat this again.
6. you can kill it anytime with ^C: exits without output
B. Workaround:
1. $ cd /home/games/fallout
2. $ cp __support/app/f1_res.ini .
3. now you still get a cropped upper-right corner of the screen, but
this time, the game opens up in a window that's centered on the
screen. It's not fully visible. Sound and graphics work and the
intro rolls. you can use the keyboard and mouse too, but because the
game captures the mouse, you can't drag the window into view
4. ESC, then sed -i 's/^WINDOWED=0/WINDOWED=1/' ./f1_res.ini, run the
game again: it runs windowed without trouble but still keeps the mouse
hostage.
note: I tried WINDOWED_FULLSCREEN=1 and ALT_MOUSE_INPUT=1 and they
don't disable capturing of the mouse.
TWM: same as FVWM
CWM:
A. Reproduction:
1. $ cd /home/games/fallout
2. $ fallout-ce
3. screen crops to a small rectangle at the top-right, everything
zoomed in and blurry, and you can you can interact and type into that
part of the desktop. the screen stays this way for around 2 seconds.
4. The screen then goes black and returns to how it was with the
"fallout-ce" command still running (no output in terminal).
5. you can kill it anytime with ^C: exits without output
B. Workaround:
1. $ cd /home/games/fallout
2. $ cp __support/app/f1_res.ini .
3. game loads up in fullscreen without problems but still takes the
mouse hostage. changing options in f1_res.ini like with FVWM doesn't
fix it.
Misc:
1. maybe recommend in the pkgreadme that the user also looks at
SCALE_X2 because the game window is too small by default
2. report to upstream that setting SCALE_X2=1 without modifying
SCR_WIDTH and SCR_HEIGHT to be at least 1280x960 leads to segfault.
/usr/local/share/doc/pkg-readmes/fallout1-ce does mention that the
user can configure fallout via f1_res.ini and fallout.cfg but as it
doesn't well work out of the box, I think it should also mention the
mouse stealing on FVWM and CWM, the need to copy over f1_res.ini, and
to also ad WINDOWED=1 for FVWM. (unless it's solvable in the port or
with upstream).
Let me know if you need any further info about my machine.
Thanks for the port :)
-- noodle
No comments:
Post a Comment