OpenXcom issues with warp mouse, mouse wheel and sfx sound #215
Comments
|
Knowing the SDL2 version in use in each case might help understand things. |
|
@sezero I've asked for more info. I assume they're using the latest Fedora packages, which are SDL2 2.24 and sdl12-compat 1.2.56 I looked at the source code and the mouse wheel bug seems to be a behavior difference, as SDL12-compat doesn't add the mouse coordinates to wheel events (which SDL1.2 did): https://github.com/libsdl-org/sdl12-compat/blob/main/src/SDL12_compat.c#L4587 |
|
Hi. So I get these issues with all the builds I made with sdl12-compat. I don't get them with Wine or with the Appimage from the Download section. I get the same behavior on my desktop and laptop (both Fedora Linux 36) Linux a485 5.19.9-200.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Sep 15 09:49:52 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux |
|
|
|
If you need any more info, just shoot. Edit: |
|
|
Got a build of OpenXcom running here now, finally saw an app print this error: ...and I'm wondering if maybe we shouldn't be so cavalier about it and actually add some platform-specific code to kill threads. (And maybe remove the Harry Potter reference from the error message.) The game runs despite this, I haven't looked further into the thread in question yet. Still looking at the other issues. |
|
The thread in question loads the game data, and terminates on its own normally, and OpenXcode always tries to kill it when it's ready to move on (during the StartState object's destructor), but in modern times this thread is almost always going to finish and terminate itself before it can get there, making the SDL_KillThread call precautionary unless the user quit the game before the Microprose logo popped up. Maybe this gets used again later? In this case, it appears to be mostly harmless. |
|
Not seeing mouse warping issues, on X11 or Wayland, with SDL 1.2 or sdl12-compat, but maybe I'm misunderstanding the issue...moving the mouse to the edge of the window seems to scroll the map okay, and it doesn't look like the game is trying to grab the mouse input to the window. @rebsol, can I get more info on how to reproduce that specific issue? |
|
I get the same Info about the thread. I didn't think it was really connected to the issue. Open game, (either use default settings or custom), open New Battle -ok-ok-ESC- in Battlescape use the mouse wheel one time. The screen then moves to the north east. I see this on my laptop, on my desktop with different mouses as well as trackpoint and touchpad. |
|
When I'm back at home I can test it with other distros in VMs. |
Oh, yeah, that problem was fixed yesterday. It was the "Scrolling to the sides is very erratic with the mouse. (this depends on SDL_WarpMouse)" comment...scrolling seems okay to me (with the mousewheel fix or not using the mousewheel), but I might not understand what the issue is. |
|
Ah, good to know that is fixed. The other problems I had I have to investigate further. I try to look for something reproducible (I switched to Wine for my game, so this might take a bit). |
|
I got the latest sdl12_compat source running on Windows (don't have a Linux env set up at the moment) and here's what I found out:
|
@icculus Your analysis is correct, the thread is only used at the start and the force kill is just in case the app is closed early (the loading can be significantly longer with debug / modded builds). So SDL_KillThread being a no-op should be harmless. |
That can be a bug in SDL_mixer itself? Can you try building SDL_mixer from git SDL-1.2 branch (where multiple bugs are fixed since SDL_mixer-1.2.12) and test with it? EDIT: Since you said you are running on windows, here are windows x86 and x64 builds of SDL_mixer-1.2 from git: |
So: something like the following? (CC: @sulix) diff --git a/src/SDL12_compat.c b/src/SDL12_compat.c
index 3c9272f..84bc020 100644
--- a/src/SDL12_compat.c
+++ b/src/SDL12_compat.c
@@ -4538,8 +4538,10 @@ EventFilter20to12(void *data, SDL_Event *event20)
event12.motion.state = event20->motion.state;
AdjustOpenGLLogicalScalingPoint(&event20->motion.x, &event20->motion.y);
/* Clamp the absolute position to the window dimensions. */
- event20->motion.x = SDL_max(SDL_min(event20->motion.x, VideoSurface12->w), 0);
- event20->motion.y = SDL_max(SDL_min(event20->motion.y, VideoSurface12->h), 0);
+ if (VideoSurface12) {
+ event20->motion.x = SDL_max(SDL_min(event20->motion.x, VideoSurface12->w), 0);
+ event20->motion.y = SDL_max(SDL_min(event20->motion.y, VideoSurface12->h), 0);
+ }
event12.motion.x = (Uint16) event20->motion.x;
event12.motion.y = (Uint16) event20->motion.y;
if (UseMouseRelativeScaling) { |
Should we just drop the event if there's no VideoSurface12 yet? |
Well, why not. |
I suspect this is unnecessary on mainstream OSs, as long as when "the app is closed" (what does this mean specifically, the main window being Alt+F4'd?), the result is either On POSIX systems (in particular Linux and macOS), if the main thread returns from I don't develop on Windows, but MSDN documents |
|
Just as an FYI: we're at Release Candidate status for 1.2.60, so if there's something we need to change in sdl12-compat for SDL_mixer support, we should try to do it in the next few days. (or if it's just "I built it with (Visual Studio 2019/MingW/something else) and it crashes trying to load a .wav" then let me know and I'll try to reproduce it over here.) It's also worth noting that, if this is Windows-specific issue, we're a little safer in that no one will change the SDL 1.2 build out from under you, unlike a Linux distribution. |
Tried them, same issue.
I made a minimal program in Visual Studio just loading a WAV in SDL_Mixer and I keep getting the heap corruption assert (it doesn't crash though, curiously). However it comes from inside SDL_Mixer so I don't have debug symbols for it. #include <SDL/SDL.h>
#include <SDL/SDL_mixer.h>
int main(int argc, char* argv[])
{
SDL_Init(SDL_INIT_EVERYTHING);
Mix_OpenAudio(MIX_DEFAULT_FREQUENCY, MIX_DEFAULT_FORMAT, MIX_DEFAULT_CHANNELS, 2048);
SDL_Surface *video = SDL_SetVideoMode(640, 480, 24, 0);
Mix_Chunk *chunk = Mix_LoadWAV("amazing.wav");
Mix_PlayChannel(-1, chunk, 0);
SDL_Event ev;
bool quit = false;
while (!quit) {
while (SDL_PollEvent(&ev)) {
if (ev.type == SDL_QUIT) {
quit = true;
}
}
}
SDL_Quit();
return 0;
} |
|
Built SDL_mixer with debug symbols, here's where it's failing: |
|
OK, SDL_mixer-1.2 is possibly using Problem is, the audio file loaded is most possibly a wav file, and If my assumptions are correct, what is the solution here? |
One thing I can think of: rebuilding SDL_mixer-1.2 specifically against |
|
Yes please, we want to model good practices in the SDL libraries. Thanks! |
chunk->abuf allocated by SDL_LoadWAV_RW should be freed by SDL_FreeWAV. Ported from SDL-1.2 branch commit 4c47f6f for sake of being by the book. Reference issue: libsdl-org/sdl12-compat#215
OK, flipped the |
|
Okay, so, is sound still degrading with SDL_mixer+sdl12-compat, or are the sound issues shaken out at this point? |
One issue I see here is that we don't have an up-to-date SDL_mixer-1.2 |
|
Anyways, here are win32 (x86) and win64 (x64) builds of SDL_mixer from |
|
What is left unresolved for this ticket? |
|
I can't reproduce the issues on Windows at least, so should be safe to close this issue. Well at least this has prompted me to try porting OpenXcom to SDL2 again... |
If you have any questions or problems moving to SDL2, I'm always available to help! |
|
I build the latest sdl12-compat on yet another machine with Fedora 36 and load it with OpenXcom - OXCE. The scroll wheel issue is fixed, but it's still unplayable. |
Try changing the |
|
Changing the audioSampleRate seems to fix the sound, although I think it's slightly faster than it used to be. |
The last couple times I opened it, it was working again. I don't really know what triggers it, but it has something to do with scaling I think. Part of the screen is not accessible with the cursor. It's either north/west in fullscreen or south/east, when in windowed mode. |
This is probably the same thing we're tracking in #256. |
|
Was there any resolution on the audio issues, or is this still something we need to look at? (If it's still on us, try exporting the environment variable SDL12COMPAT_COMPATIBILITY_AUDIOCVT=1 and see if the problem goes away.) |
|
Here's another SDL_WarpMouse issue which I just encountered in OpenXCom (not my report).
In case it helps, I'm running sdl2 2.26.1-1 and sdl12-compat 1.2.60-1 on manjaro with i3wm (but I tested with both openbox and lxde which didn't resolve the issue). |
|
Good news! I built OpenXCom Extended again now on Fedora 37 with sdl12-compat 1.2.60 from the Fedora repository and the issues are gone in a short test. If anything pops up in play I'll check back but it seems to me it's fine now. |
|
Great, thanks! |
I am still experiencing this scrolling issue in openxcom with sdl12-compat 1.2.68-1 on Manjaro. Replacing it with the original sdl 1.2 (sdl-git from the AUR) resolved it. Not sure if I should open a new issue or request a reopening of this one. In any case, if more info is needed just let me know. |
Now that Linux distros are replacing SDL1.2 with sdl12-compat, we're getting new bug reports for features that worked fine in SDL1.2: https://openxcom.org/forum/index.php/topic,10776.0.html
The key regressions seem to be:
The text was updated successfully, but these errors were encountered: