Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unreal Tournament 1999 is too fast #283

Open
OlegAckbar opened this issue Feb 1, 2025 · 10 comments
Open

Unreal Tournament 1999 is too fast #283

OlegAckbar opened this issue Feb 1, 2025 · 10 comments
Assignees

Comments

@OlegAckbar
Copy link

Unreal Tournament 1999 is too fast even with framerate cap applied. I'm using it in conjuncture with sdl12-compat and sdl2-compat, but there was no such problem with just sdl2.

ut99fast.webm
@slouken slouken modified the milestones: 2.30.52, 2.30.54 Feb 1, 2025
@icculus icculus self-assigned this Feb 2, 2025
@icculus
Copy link
Collaborator

icculus commented Feb 3, 2025

Downloading the (now actually legal!) .isos from archive.org. :)

I haven't looked at this specific bug yet, but I remember at some point UT99 did something similar to this if your FPS was really high...some delta time calculation would go to zero and everything would just go into fast-forward.

So I'm wondering if vsync accidentally got turned off for a game that was designed to run well on an ATI Rage128.

I could be totally wrong, I'll know more soon though.

@icculus
Copy link
Collaborator

icculus commented Feb 3, 2025

This is working for me (at 1000fps, lol) using sdl2-compat with the latest OldUnreal patch, but if my initial idea is right, it's 100% possible they fixed this. Is there a good place to get an older UT99 binary?

@madebr
Copy link
Contributor

madebr commented Feb 3, 2025

Looks like the video was created with patch 436: https://unrealarchive.org/unreal-tournament/patches-updates/patches/patch-436/index.html

@icculus
Copy link
Collaborator

icculus commented Feb 3, 2025

...that would be SDL 1.2, though. @OlegAckbar, is this chaining through sdl12-compat, too?

@OlegAckbar
Copy link
Author

...that would be SDL 1.2, though. @OlegAckbar, is this chaining through sdl12-compat, too?

My version is using sdl12-compat, haven't tried the latest one, will check it out

@icculus
Copy link
Collaborator

icculus commented Feb 3, 2025

Okay, I tried this with the final 436 binaries from Loki.

I'm getting this problem with sdl12-compat (not even chaining through sdl2-compat), so I think this is the bug I described and not something we can fix (beyond maybe adding a quirk to force vsync on).

This bug appears to be fixed in UT99 itself if you use OldUnreal's Linux binaries, which also gets you x86-64 binaries (and wow, ARM64, too) ... https://github.com/OldUnreal/UnrealTournamentPatches

@icculus
Copy link
Collaborator

icculus commented Feb 3, 2025

Exporting the SDL12COMPAT_SYNC_TO_VBLANK=1 environment variable fixes it, of course. Should we add this as a quirk to sdl12-compat for binaries named ut-bin?

@slouken
Copy link
Collaborator

slouken commented Feb 3, 2025

Exporting the SDL12COMPAT_SYNC_TO_VBLANK=1 environment variable fixes it, of course. Should we add this as a quirk to sdl12-compat for binaries named ut-bin?

Yes, that seems like a good idea.

@OlegAckbar
Copy link
Author

OlegAckbar commented Feb 3, 2025

Exporting the SDL12COMPAT_SYNC_TO_VBLANK=1 environment variable fixes it, of course. Should we add this as a quirk to sdl12-compat for binaries named ut-bin?

Setting SDL12COMPAT_SYNC_TO_VBLANK=1 didn't fix it for me, although I'm using KWin Wayland from cachyos repos which is compiled with fifo-v1. Maybe it has something to do with it? No, it has nothing to do with it I just checked.
OldUnreal libraries indeed don't have that issue

icculus added a commit to libsdl-org/sdl12-compat that referenced this issue Feb 4, 2025
@icculus
Copy link
Collaborator

icculus commented Feb 4, 2025

I added the vsync stuff to sdl12-compat; I'm not really sure what else to do with this in sdl2-compat, and OldUnreal has binaries available for modern systems with a ton of good fixes, making further research on this low priority.

@slouken slouken removed this from the 2.30.54 milestone Feb 4, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants